Always On Questions
Always On Questions
Always On Questions
AlwaysOn Availability Groups feature is a high-availability and disaster-recovery solution that provides an enterprise-level alternative
to database mirroring. Introduced in SQL Server 2012, AlwaysOn Availability Groups maximizes the availability of a set of user
databases for an enterprise. An availability group supports a failover environment for a discrete set of user databases, known
as availability databases that fail over together. An availability group supports a set of read-write primary databases and one to four
sets of corresponding secondary databases. Optionally, secondary databases can be made available for read-only access and/or
some backup operations.
A container for a set of databases, availability databases, that fails over together.
A database that belongs to an availability group. For each availability database, the availability group maintains a single read-write
copy (the primary database) and one to four read-only copies (secondary databases).
The availability mode is a property of each availability replica. The availability mode determines whether the primary replica waits to
commit transactions on a database until a given secondary replica has written the transaction log records to disk (hardened the log).
Asynchronous-commit mode
Synchronous-commit mode
13. What is the Difference between Asynchronous-commit mode and Synchronous-commit mode?
Asynchronous-commit mode
An availability replica that uses this availability mode is known as an asynchronous-commit replica. Under asynchronous-commit
mode, the primary replica commits transactions without waiting for acknowledgement that an asynchronous-commit secondary
replica has hardened the log. Asynchronous-commit mode minimizes transaction latency on the secondary databases but allows
them to lag behind the primary databases, making some data loss possible.
Synchronous-commit mode
An availability replica that uses this availability mode is known as a synchronous-commit replica. Under synchronous-commit mode,
before committing transactions, a synchronous-commit primary replica waits for a synchronous-commit secondary replica to
acknowledge that it has finished hardening the log. Synchronous-commit mode ensures that once a given secondary database is
synchronized with the primary database, committed transactions are fully protected. This protection comes at the cost of increased
transaction latency.
The availability replica that makes the primary databases available for read-write connections from clients and, also, sends
transaction log records for each primary database to every secondary replica.
An availability replica that maintains a secondary copy of each availability database, and serves as a potential failover targets for the
availability group. Optionally, a secondary replica can support read-only access to secondary databases can support creating
backups on secondary databases.
A server name to which clients can connect in order to access a database in a primary or secondary replica of an AlwaysOn
availability group. Availability group listeners direct incoming connections to the primary replica or to a read-only secondary replica.
Directing read-only connections to readable secondary replicas provides the following benefits:
Offloads your secondary read-only workloads from your primary replica, which conserves its resources for your mission
critical workloads. If you have mission critical read-workload or the workload that cannot tolerate latency, you should run it
on the primary.
Improves your return on investment for the systems that host readable secondary replicas.
In addition, readable secondaries provide robust support for read-only operations, as follows:
Temporary statistics on readable secondary database optimize read-only queries. For more information, see Statistics for
Read-Only Access Databases, later in this topic.
Read-only workloads use row versioning to remove blocking contention on the secondary databases. All queries that run
against the secondary databases are automatically mapped to snapshot isolation transaction level, even when other
transaction isolation levels are explicitly set. Also, all locking hints are ignored. This eliminates reader/writer contention.
We can have up to 2 synchronous replicas, but we are not required to use any. We could run all Secondaries in Async mode if
desired
Yes. An active secondary can be used to offload read-only queries from the primary to a secondary instance in the availability
group.
BACKUP DATABASE supports only copy-only full backups of databases, files, or filegroups when it is executed on
secondary replicas. Note that copy-only backups do not impact the log chain or clear the differential bitmap.
Differential backups are not supported on secondary replicas.
Yes, we can take transaction log backups on the secondary replicas without COPY_ONLY option.
Three forms of failover exist—automatic, manual, and forced (with possible data loss). The form or forms of failover supported by a
given secondary replica depends on its availability mode,
A manual failover occurs after a database administrator issues a failover command and causes a synchronized secondary replica to
transition to the primary role (with guaranteed data protection) and the primary replica to transition to the secondary role. A manual
failover requires that both the primary replica and the target secondary replica are running under synchronous-commit mode, and
the secondary replica must already be synchronized.
An automatic failover occurs in response to a failure that causes a synchronized secondary replica to transition to the primary role
(with guaranteed data protection). When the former primary replica becomes available, it transitions to the secondary role.
Automatic failover requires that both the primary replica and the target secondary replica are running under synchronous-commit
mode with the failover mode set to “Automatic”. In addition, the secondary replica must already be synchronized, have WSFC
quorum, and meet the conditions specified by the flexible failover policy of the availability group.
29. Can we configure Automatic failover of Availability Groups with SQL Server Failover cluster instances?
SQL Server Failover Cluster Instances (FCIs) do not support automatic failover by availability groups, so any availability replica that
is hosted by an FCI can only be configured for manual failover.
30. What are the Failover types supported by under asynchronous-commit mode?
Only form of failover is forced manual failover (with possible data loss), typically called forced failover. Forced failover is
considered a form of manual failover because it can only be initiated manually. Forced failover is a disaster recovery option. It is the
only form of failover that is possible when the target secondary replica is not synchronized with the primary replica.
Database administrators use the AlwaysOn Dashboard to obtains an at-a-glance view the health of an AlwaysOn availability group
and its availability replicas and databases in SQL Server 2012. Some of the typical uses for the AlwaysOn Dashboard are:
Choosing a replica for a manual failover.
Estimating data loss if you force failover.
Evaluating data-synchronization performance.
Evaluating the performance impact of a synchronous-commit secondary replica
References: Thanks to the all the SQL Server techies who wrote and shared the valuable information in the below blogs which
helped me a lot to prepare this series of Questions. Also big thanks to Microsoft Documentation which contains each and everything
about their product.
I hope you enjoyed my last post on Always On. Here goes the final post on Always On feature.
Availability Group Wizard is a GUI using SQL Server Management Studio to create and configure an AlwaysOn availability group in
SQL Server 2012.
3. What are the minimum requirements of a database to be part of the Always ON Availability Group?
Availability groups must be created with user databases. Systems databases can’t be used.
Databases must be read-write. Read-only databases aren’t supported.
Databases must be multiuser databases.
Databases can’t use the AUTO_CLOSE feature.
Databases must use the full recovery model, and there must be a full backup of them.
A given database can only be in a single availability group, and that database can’t be configured to use database
mirroring.
4. How many read-write and read only databases replica can be configure in SQL Server 2012 and 2014?
Yes, It is possible.
Yes, it is supported.
Yes, it is supported.
Yes, it is supported.
No.
11. Suppose primary database became in suspect mode. Will AG have failover to secondary replica?
Issues at the database level, such as a database becoming suspect due to the loss of a data file, deletion of a database, or
corruption of a transaction log, do not cause an availability group to failover.
13. Is AG support automatic page repair for protection against any page corruption happens?
No.
Session-timeout period is a replica property that controls how many seconds (in seconds) that an availability replica waits for a ping
response from a connected replica before considering the connection to have failed. By default, a replica waits 10 seconds for a
ping response. This replica property applies only the connection between a given secondary replica and the primary replica of the
availability group.
As part of the availability group creation process, We have to make an exact copy of the data on the primary replica on the
secondary replica. This is known as the initial data synchronization for the Availability Group.
22. How many types of Data synchronization preference options are available in Always ON?
There are three options- Full, Join only, or Skip initial data synchronization.
Yes.
24. Can I redirect the read-only connections to the secondary replica instead of Primary replica?
Yes, we can specify the read_only intent in the connection string and add only secondaries (not the primary) to the
read_only_routing list. If you want to disallow direct connections to the primary from read_only connections, then set its
allow_connections to read_write.
25. If a DBA expands a data file manually on the primary, will SQL Server automatically grow the same file on secondaries?
It will be automatically expanded on the Secondary replica.
26. Is it possible to create additional indexes on read-only secondary replicas to improve query performance?
27. Is it possible to create additional statistics on read-only secondaries to improve query performance?
No. But we can allow SQL Server to automatically create statistics on read-only secondary replicas.
Yes. If the secondary is in synchronous-commit mode and is set to “SYNCHRONIZED” you can manually fail over without data loss.
If the secondary is not in a synchronized state then a manual failover is allowed but with possible data loss
There are two options to configure secondary replica for running read workload. The first option ‘Read-intent-only’ is used to provide
a directive to AlwaysOn secondary replica to accept connections that have the property ApplicationIntent=ReadOnly set. The word
‘intent’ is important here as there is no application check made to guarantee that there are no DDL/DML operations in the
application connecting with ‘ReadOnly’ but an assumption is made that customer will only connect read workloads.
30. Does AlwaysOn Availability Groups repair the data page corruption as Database Mirroring?
Yes. If a corrupt page is detected, SQL Server will attempt to repair the page by getting it from another replica.