Home > Storage > PowerStore > Databases and Data Analytics > Dell PowerStore: SQL Server High Availability on VMware > SQL Server HA limitations
The availability features within SQL Server offer various ways to minimize disruption to business applications. If a failover is required between SQL Server instances whether stand-alone or as part of an FCI or AG, it often results in a disruption of service. The following sections describe a few of the reasons and the possible results of these disruptions.
One of the main limitations of features in the Always On architecture is that when a failover occurs, active database connections are terminated and need to be reestablished. When using FCI, the active instance is terminated, and the SQL Server instance is started on another cluster node. With AGs, a role change occurs in which a secondary database assumes the primary role, and database connections reconnect to the SQL Server instance that is hosting the primary. Depending on the method used (whether they are read-only or read/write, and how the application connects to SQL Server) will determine whether the application experiences a disruption of service. Graceful handling of a failover scenario requires careful planning and application changes, which may not be possible when using third-party applications. For business continuity, it is best to avoid failovers whenever possible, especially unplanned failovers.
When a SQL Server instance is started or restarted, crash recovery is performed on every database in the SQL Server instance. Depending on the database recovery model, the amount of activity in the database, and several other factors, database recovery time can take seconds, or even hours in extreme cases. Accelerated Database Recovery was a feature introduced in SQL Server 2019 to accelerate this process and improve the experience. However, the best way to maximize uptime is to avoid a failover event if possible.
There is often critical application data that lives outside of the database. This data can consist of configuration files, large image files (such as FILESTREAM), and so on. This critical application data that is stored outside of the database needs to be protected, but because it is not included with SQL Server HA features, another method must be used.
Following a failover event, the data needs to be synchronized to the original primary and possibly a failback event is required to the original primary and secondary roles. Often resynchronization needs to be done manually or through custom scripts.