Q1. What is "Update Statistics"?

Update Statistics is a SQL Server command used to refresh or update the

statistical information stored for indexes and columns in a database. SQL Server
uses these statistics to optimize query execution by providing data about the
distribution of values in the columns. The more up to date the statistics are, the
better SQL Server can generate an efficient execution plan for queries.
When to Run "Update Statistics"?
1. After a Rebuild Index Operation:
o Rebuilding an index (using ALTER INDEX ... REBUILD)
automatically updates the statistics for that index with full scan, so
there’s usually no need to manually run UPDATE STATISTICS after an
index rebuild. SQL Server automatically updates statistics with a
more thorough data sampling when a full index rebuild is
performed.
2. After a Reorganize Index Operation:
o Reorganizing an index (using ALTER INDEX ... REORGANIZE) does
not update the statistics. After a reorganize operation, it's often
recommended to run UPDATE STATISTICS manually or schedule it
because the reorganize operation doesn't refresh the statistics on
the underlying data.
Why Update Statistics?
 Improved Query Performance: Updated statistics allow SQL Server to
choose the most efficient query plan. If the statistics are outdated, the
execution plan might not reflect the current distribution of data, leading to
suboptimal performance.
 Handling Data Changes: As data in tables grows, shrinks, or changes,
the distribution of values in columns can shift. Updating statistics helps
SQL Server account for these changes in its query optimization decisions.
Best Practices for "Update Statistics":
 Schedule Regular Updates: In environments with frequent data
modifications, it's recommended to run UPDATE STATISTICS regularly to
ensure queries perform efficiently.
 After Significant Data Changes: If a large number of rows have been
inserted, updated, or deleted, running UPDATE STATISTICS ensures SQL
Server reflects the changes in the query optimization process.
In summary, you run UPDATE STATISTICS after reorganizing indexes because it
doesn't automatically update statistics. It’s essential for maintaining query
performance by ensuring SQL Server has accurate information about data
distribution.
Q2. Prerequisites for Always On Availability Groups in SQL Server
Before configuring SQL Server Always On Availability Groups, certain
prerequisites need to be fulfilled, both at the infrastructure and software levels.
1. SQL Server Edition
 SQL Server Enterprise Edition: Always On Availability Groups is
available in the Enterprise edition of SQL Server. In SQL Server 2016 SP1
and later, the Basic Availability Group feature is available in Standard
edition, but it's limited to one database per availability group and lacks
some advanced features.
2. Windows Server
 Windows Server Failover Clustering (WSFC): Always On Availability
Groups require a Windows Server Failover Cluster (WSFC). You must have a
properly configured failover cluster, even if you are not using SQL Server
Failover Clustering.
3. Windows Cluster Configuration
 Windows Failover Clustering: Ensure that you have Windows Failover
Clustering set up and configured on the servers where you will deploy the
Availability Groups.
 Nodes: At least two servers (nodes) that are part of the failover cluster.
 Shared Storage: Unlike traditional failover clustering (FCI), shared
storage is not required.
4. SQL Server Instances
 All SQL Server instances that will participate in the Always On Availability
Group must belong to the same version (e.g., SQL Server 2019) and have
the Always On Availability Groups feature enabled.
5. Same Database Collation
 The databases that will be part of an Availability Group must have the
same collation on all participating SQL Server instances.
6. Domain Membership
 All participating servers (nodes) must be part of the same Windows Active
Directory Domain.
7. Database Backup
 Ensure that the database(s) to be included in the Availability Group are in
Full Recovery Model and that recent backups (full and transaction log
backups) have been taken.
8. Network Requirements
 Dedicated Network Interface: It is recommended to have a dedicated
network interface for replication traffic between the nodes in the
Availability Group.
  IP Address: For the Availability Group Listener, you need a static IP
address that will be shared between the nodes.

Step-by-Step Configuration of SQL Server Always On Availability Groups

Step 1: Install and Configure Windows Server Failover Cluster (WSFC)
1. Install Failover Clustering Feature:
o On all participating servers, open the Server Manager and install
the Failover Clustering feature.
2. Create a Cluster:
o Use the Failover Cluster Manager to create a new cluster.

o Add all SQL Server nodes to this cluster.

o Provide a cluster name and an IP address.

o Run the Validation Wizard to check for any configuration issues.

Step 2: Enable Always On Availability Groups on SQL Server Instances

1. Enable Always On in SQL Server:
o Open SQL Server Configuration Manager.

o Right-click on the SQL Server instance, go to Properties and check

the box for Enable Always On Availability Groups under the
Always On High Availability tab.
o Restart the SQL Server instance.

Step 3: Prepare the Databases for Availability Groups

1. Ensure Full Recovery Model:
o All databases that will be part of the Availability Group must be in
Full Recovery Model. You can change it by running:
ALTER DATABASE [YourDatabase] SET RECOVERY FULL;
2. Take Full and Transaction Log Backups:
o Take a full backup and transaction log backup of the database:

BACKUP DATABASE [YourDatabase] TO DISK = 'Path\To\BackupFile.bak';

BACKUP LOG [YourDatabase] TO DISK = 'Path\To\LogBackupFile.trn';
Step 4: Create an Availability Group
1. Open SQL Server Management Studio (SSMS):
o Connect to the primary SQL Server instance.

2. Launch the New Availability Group Wizard:

 o In SSMS, go to Object Explorer > Always On High Availability >
Availability Groups.
o Right-click and select New Availability Group Wizard.

3. Define the Availability Group:

o Provide a name for your Availability Group.

o Select the databases that will be part of the group.

4. Specify Replicas:
o Add the SQL Server instances (replicas) that will participate in the
Availability Group.
o Configure automatic failover and synchronous or
asynchronous replication for each replica:
 Automatic Failover: Enabled for replicas configured in
synchronous mode.
 Manual Failover: For asynchronous replicas, you will need
to manually fail over in case of failure.
5. Configure Backup Preferences:
o Decide where backups should occur (Primary or Secondary replica).

6. Listener Configuration:
o If you need an Availability Group Listener (highly recommended
for client applications), provide a listener name and IP address.
Step 5: Join the Secondary Replicas to the Availability Group
1. Data Synchronization:
o Choose the method to synchronize data across replicas:

 Automatic Seeding: SQL Server will automatically initialize

the secondary replicas.
 Full Backup and Restore: You manually restore backups on
secondary replicas before joining them to the Availability
Group.
Step 6: Verify and Test the Configuration
1. Verify Availability Group:
o After the Availability Group is created, verify that all replicas and
databases are properly synchronized.
2. Test Failover:
o Test both manual failover and automatic failover to ensure the
Availability Group is functioning as expected.
Post-Configuration Tasks:
 Monitor the Always On Availability Group: Use the Always On
Dashboard in SSMS to monitor replication health, synchronization status,
and any potential issues.
 Configure Automated Alerts: Set up alerts for replication health and
failover events.
 Backup and Maintenance: Ensure backups are configured for the
Availability Group and that regular maintenance is performed.
By following these steps, you'll have a functional SQL Server Always On
Availability Group, ensuring high availability for your databases.