AlwaysOn Availability Groups

Interview Questions and Answers Part 1

sql dba alwayson interview questions 1

One of the best known feature introduced in SQL Server 2012 is AlwaysOn which makes
use of existing HA/DR features and provide additional features like Availability Groups. This
article is for SQL Server DBAs who are preparing for interviews, this include basic and
advanced level sql dbaAlwaysOn Interview questions 1.

sql dba alwayson interview questions 1

Q. What is AlwaysOn in SQL Server?

Ans:

AlwaysOn Availability Groups feature is a highavailability and disasterrecovery solution that

provides an enterpriselevel 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 asavailability databasesthat fail over together. An availability group supports
a set of readwrite primary databases and one to four sets of corresponding secondary
databases. Optionally, secondary databases can be made available for readonly access and/or
some backup operations.

Q. What are Availability Groups?

Ans:
A container for a set of databases,availability databases, that fails over together. Lets consider
a scenario where a set of 3 databases are interlinked based on application requirement. Now we
need to setup HA for these 3 databases. If we choose mirroring we need to have a separate
mirroring setup for these 3 databases where as in AlwaysOn Availability Groups easier the job by
grouping all these 3 databases.

Q. What are Availability Databases?

Ans:

A database that belongs to an availability group. For each availability database, the availability
group maintains a single readwrite copy (theprimary database) and one to four readonly copies
(secondary databases).

Q. Which SQL/Windows Server Editions include AlwaysOn Availability Group functionality?

Ans:

SQL Server Enterprise Edition and Windows Enterprise Edition

Q. How many replicas can I have in an AlwaysOn Availability Group?

Ans:

Total 51 Primary and up to 4 Secondarys.

Q. How many AlwaysOn Availability Groups can be configured in Always ON?

Ans:

Up to 10 availability groups is the recommendation, but its not enforced

Q. How many databases can be configured in an AlwaysOn Availability Group?

Ans:

Up to 100 is the recommendation, but its not enforced

Q. What are the Restrictions on Availability Groups?

Ans:

Availability replicas must be hosted by different nodes of one WSFC cluster

 Unique availability group name: Each availability group name must be unique on the WSFC
cluster. The maximum length for an availability group name is 128 characters.
Availability replicas: Each availability group supports one primary replica and up to four
secondary replicas. All of the replicas can run under asynchronouscommit mode, or up to
three of them can run under synchronouscommit mode.
Maximum number of availability groups and availability databases per computer: The actual
number of databases and availability groups you can put on a computer (VM or physical)
depends on the hardware and workload, but there is no enforced limit. Microsoft has
extensively tested with 10 AGs and 100 DBs per physical machine.
Do not use the Failover Cluster Manager to manipulate availability groups.

Q What are the minimum requirements of a database to be part of the Always ON Availability
Group?

Ans:

Availability groups must be created with user databases. Systems databases cant be used.
Databases must be readwrite. Readonly databases arent supported.
Databases must be multiuser databases.
Databases cant use the AUTO_CLOSE feature.
Databases must use the full recovery model, and there must be a full backup available.
A given database can only be in a single availability group, and that database cant be
configured to use database mirroring.

Q. How many readwrite and read only databases replica can be configure in SQL Server
2012 and 2014?

Ans:

SQL Server 2012 supported a maximum of four secondary replicas.

With SQL Server 2014, AlwaysOn Availability Groups now supports up to eight secondary
replicas.

Q. Is it possible to setup Log Shipping on a database which is part of Availability Group?

Ans:

Yes, it can be configured.

Q. Is it possible to setup Replication on a database which is part of Availability Group?

Ans:
Yes, it is possible.

Q. Does FILESTEAM, Change Data Capture and Database Snapshot supported are supported by
Availability Group?

Ans:

Yes, all these features are supported by AlwaysOn Availability Group.

Q. Can system database participate in AG?

Ans:

No.

Q: What version of Windows do I need for AlwaysOn AGs?

Ans:

We highly recommend Windows Server 2012R2 and above.

Q: Can I have different indexes or tables on my replicas?

Ans:

No, the replica database contents will be exactly the same as the primary.

Q. What is Availability mode in Always ON?

Ans:

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). AlwaysOn supports
below modes:

Asynchronouscommit mode: Primary replica commits the transaction on a database without

waiting for the conformation from the secondary replica.

Synchronouscommit mode: Primary replica does not commit the transaction on a database
until it gets the confirmation (written the transaction log records to disk on secondary) from
secondary replica.
Q. Do we need SQL Server Cluster instances to configure Always ON?

Ans:

No we dont need SQL Server Cluster instances to configure Always ON.

Q. Do we need shared storage to configure Always ON?

Ans:

No, we dont need shared storage.

Q. What is the Difference between Asynchronouscommit mode and Synchronouscommit

mode?

Ans:

Asynchronouscommit mode:

An availability replica that uses this availability mode is known as an asynchronouscommit

replica. Under asynchronouscommit mode, the primary replica commits transactions without
waiting for acknowledgement that an asynchronouscommit secondary replica has hardened the
log. Asynchronouscommit mode minimizes transaction latency on the secondary databases but
allows them to lag behind the primary databases, making some data loss possible.

Synchronouscommit mode:

An availability replica that uses this availability mode is known as asynchronouscommit replica.
Under synchronouscommit mode, before committing transactions, a synchronouscommit
primary replica waits for a synchronouscommit secondary replica to acknowledge that it has
finished hardening the log. Synchronouscommit 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.

Q. What is called Primary replica?

Ans:

The availability replica that makes the primary databases available for readwrite connections
from clients is called Primary Replica. It sends transaction log records for each primary database
to every secondary replica.

Q. What is called Secondary replica?

Ans:

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 readonly access to secondary databases can support creating backups on secondary
databases.

Q. What is Availability Group listener?

Ans:

Availability Group Listeneris 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 readonly secondary replica.

Q. What are Readable Secondary Replicas?

Ans:

The AlwaysOn Availability Groups active secondary capabilities include support for readonly
access to one or more secondary replicas (readable secondary replicas). A readable secondary
replica allows readonly access to all its secondary databases. However, readable secondary
databases are not set to readonly. They are dynamic. A given secondary database changes as
changes on the corresponding primary database are applied to the secondary database.

Q. What are the benefits of Readable Secondary Replicas?

Ans:

Directing readonly connections to readable secondary replicas provides the following benefits:

Offloads your secondary readonly workloads from your primary replica, which conserves its
resources for your mission critical workloads. If you have mission critical readworkload 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 readonly operations, as follows:

Temporary statistics on readable secondary database optimize readonly queries. For more
information, see Statistics for ReadOnly Access Databases, later in this topic.
Readonly 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.

Q. How many synchronous secondary replicas can I have?

Ans:

We can have up to 2 synchronous replicas, but we are not required to use any. We could run all
Secondaries in asynchronous mode if desired

Q. Can we use a secondary for reporting purpose?

Ans:

Yes. An active secondary can be used to offload readonly queries from the primary to a
secondary instance in the availability group.

Q. Can we use secondary replicas to take the db backups?

Ans:

Yes. An active secondary can be used for some types of backups

Q. What all types of DB backups are possible on Secondary Replicas?

Ans:

BACKUP DATABASE supports only copyonly full backups of databases, files, or filegroups
when it is executed on secondary replicas. Note that copyonly backups do not impact the log
chain or clear the differential bitmap.
Differential backups are not supported on secondary replicas.

Q. Can we take Transaction log backups on the secondary replicas?

Ans:

Yes, we can take transaction log backups on the secondary replicas without COPY_ONLY option.

Q. What is Failover in Always ON?

Ans:
Within the context of a session between the primary replica and a secondary replica, the primary
and secondary roles are potentially interchangeable in a process known as failover. During a
failover the target secondary replica transitions to the primary role, becoming the new primary
replica. The new primary replica brings its databases online as the primary databases, and client
applications can connect to them. When the former primary replica is available, it transitions to
the secondary role, becoming a secondary replica. The former primary databases become
secondary databases and data synchronization resumes.

Q. How many types of Failover are supported by Always ON?

Ans:

Three forms of failover existautomatic, manual, and forced (with possible data loss). The form
or forms of failover supported by a given secondary replica depends on its availability mode.

Q. What are the Failover types supported by Synchronouscommit mode?

Ans:

Planned manual failover(without data loss)

Automatic failover(without data loss)

Q. What is planned manual failover?

Ans:

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
synchronouscommit mode, and the secondary replica must already be synchronized.

Q. What is Automatic failover?

Ans:

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
synchronouscommit 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
theflexible failover policyof the availability group.
Q. Can we configure Automatic failover of Availability Groups with SQL Server Failover
cluster instances?

Ans:

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.

Q. What are the Failover types supported by under asynchronouscommit mode?

Ans:

Only form of failover is forced manual failover (with possible data loss), typically calledforced
failover.Forced failoveris 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.

Q. What is the use of AlwaysOn Dashboard?

Ans:

Database administrators use the AlwaysOn Dashboard to obtains an ataglance 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 datasynchronization performance.
Evaluating the performance impact of a synchronouscommit secondary replica

References:

We should be thankful for the authors who has given an excellent explanations on AlwaysOn
topics from SQL Server 2012 and SQL Server 2014. Here is the list of top references: