HIGH AVAILABILITY

High availability is about a set of technologies into place before a failure occurs to prevent the failure
from affecting the availability of data. Disaster recovery is about taking action after a failure has
occurred to recover any lost data and make the data available again.

Replication

Logshipping

Mirror

Failover cluster

The High Availability requirement may differ from client to client, some clients may need the
database to be up and running 24X7 and others may require only during office hours. So based
on the client criticality need we have to choose appropriate the High Availability option.
Otherwise there will be unnecessary expenses in terms of money, performance and resource
utilization.
Later version SQL Server 2005 provides options for setting up high availability for a server,
database and object level.

The Failover Clustering supports server level high availability whereas Database Mirroring and
Log Shipping are per database and Replication is object level. The below image depicts these
breakdowns.

Failover Clustering

This provides server-level redundancy on a certified Microsoft Windows Cluster Services

Configuration. A failover cluster is setup with a minimum of two servers. In the cluster setup,
each server is called a node. All the nodes are connected to shared disk resources. Only one node
is active at a time for a SQL Server instance and serves all the requests for that instance of SQL
Server. When the active node fails, failover takes place and one of the other available nodes will
become the active node.

Use:

 This is an appropriate option for mission critical applications where automatic failover is
needed for the entire instance of SQL Server.
Recovery:

 Recovery Time Objective (RTO) - Almost immediately, because processing is handed

over to another node in the cluster.
 Recovery Point Objective (RPO) - If there is no data corruption or data loss (due to data
deletion), there is minimal to no data loss during the failover.

Pros:

 It provides automatic failover.

 It protects an entire SQL Server instance.
 Can apply service packs to one node at a time to minimize downtime.
 If secondary server is used in a passive mode (only for failover), additional SQL Server
licensing is not needed.

Cons:

 It is more expensive since it requires special hardware for the setup as well as redundant
hardware.
 It is not supported with all SQL Server editions. (see chart below)
 It is a single shared data resource.

Database Mirroring

This provides database redundancy by transferring data from the transaction log to another
instance of SQL Server.

Database mirroring is the creation and maintenance of redundant copies of a database.

Two copies of a single database reside on different computers called server instances, usually in physical
locations separated by some distance. The principal (or primary) server instance provides the database
to clients. The mirror (or secondary) server instance acts as a standby that can take over in case of a
problem with the principal server instance.

Database Mirroring Endpoints

All Database Mirroring traffi c is transmitted through a TCP endpoint with a payload of
DATABASE_MIRRORING. You can create only one Database Mirroring endpoint per SQL Server
instance.
By default, the Database Mirroring endpoint is defi ned on port 5022.
There are several operating modes that can be used such as:
high performance,

high safety with automatic failover and

high safety without automatic failover.

Use:

 This is a good option when there is the need to have automatic failover for a database. It
can be near real time failover of a database depending on the options used. Also a good
choice if there is a need to provide database connectivity with minimal downtime.

Recovery:

 Recovery Time Objective (RTO) - Depending on the options used it could be almost
immediately for a database, because the mirror copy will become the primary copy. Also,
if you use the Failover Partner option in the connection string the application should be
able to find the new server without any other configuration changes.
 Recovery Point Objective (RPO) - If there is no data loss (due to data deletion), there is
minimal to no data loss during the failover. Because this is an exact copy of the primary
database all transactions will be replicated to the mirror copy as they were done on the
primary server.

Pros:

 It provides automatic failover. (if used with a witness)

 Snapshots of the database can be created against the mirrored copy for read only access
and off-loading reporting to another server.
 It provides near real time failover of a database, depending on the options used.
 No additional cost, except for the need to have another available server for the mirror and
possibly a third for the witness.
 If secondary server is used in a passive mode (only for failover), additional SQL Server
licensing is not needed.

Cons:

 High safety without automatic failover setting may be network overhead.

  A third server is required for "automatic failover" (witness - SQL Server Express can be
used)
 Other items need to be handled outside of mirroring such as logins, SQL Agent jobs,
etc...
 Requires additional storage for mirrored copy
 If Snapshots are used for read only, the snapshot is only as current as when the snapshot
was created.

Log Shipping

It provides database redundancy by sending transactional log backups periodically to a standby

server or servers for the entire database. Transaction logs are automatically backed up, copied,
and restored on the standby server(s). If the active server goes down, the standby server can be
brought up by restoring any remaining shipped logs and then the database is recovered for use.
More info on Log Shipping can be read from this MSDN library article.

Use:

 It is good option when we want to have multiple secondary failover servers for a
database.

Recovery:

 Recovery Time Objective (RTO) - Failover is manual for this option, so this will take as
long as it takes you to get the secondary server up and running.
 Recovery Point Objective (RPO) - If there is no data loss (due to data deletion), there is
minimal to no data loss during the failover. Because transaction backups are applied to
the secondary server all transactions will be replicated as they were done on the primary
server. If you delay applying the transaction logs you could do a point in time recovery
right before an accidental deletion of data occurred.

Pros:

 Log shipping can be configured to multiple standby servers.

 Can use compressed backup feature to limit network bandwidth
 It includes all the database objects along with their schema changes.
 By specifying Log Shipping in short interval, it can be near real-time database.
 Can be setup to use secondary server for read only activity
 No additional cost, except for the need to have another available server for the secondary
copy.
 Can delay when the logs get applied to secondary server to help minimize data loss in the
event of accidental data deletion (point in time recovery)
 If secondary server is used in a passive mode (only for failover), additional SQL Server
licensing is not needed.
Cons:

 There is no automatic failover.

 Other items need to be handled outside of Log Shipping such as logins, SQL Agent jobs,
etc...
 Requires additional storage for log backups and shipped copy
 If standby copy is used for read only, SQL requires exclusive access to the database when
a log backup is restored

Replication

Replication is a set of technologies for copying and distributing data and database objects from
one database to another. Replication is a desired option when we want to have the same data on
multiple database servers.

Use:

 It is good option when we want to have multiple server updates with disconnected
options. It can be near real time. It can also be used to implement load balancing for a
database.

Recovery:

 Recovery Time Objective (RTO) - This could be immediate and only require re-pointing
your application to a different server.
 Recovery Point Objective (RPO) - If there is no data loss (due to data deletion), there is
minimal to no data loss during the failover. Because this is an exact copy of the primary
database all transactions will be replicated to the mirror copy as they were done on the
primary server.

Pros:

 Can be configured for individual database objects instead of the entire database.
 Enhanced tools available for configuration and troubleshooting.
 Provides near real time disaster recovery.
 It supports disconnected architecture, so it is beneficial for mobile users.
 Secondary copy could be used for near real-time reporting to offload reporting use on
production database.

Cons:

 Reconfiguration may require manual intervention.

 Need to rely on distributor to push changes.
  Other items need to be handled outside of Replication such as logins, SQL Agent jobs,
etc...
 It is more complicated to setup and maintain then the other options.
 SQL Server will need to be fully licensed for the secondary server.

Selecting a High Availability Solution

Each SQL Server 2008 High Availability option addresses different risks. As we know, no "one"
solution fits all. We need to review carefully the business requirements. Basically, we need to
consider a few questions like:

 Is Automatic Failover required?

 What is the data granular level for the High Availability?
 How much data loss or downtime is accepted?
 Is the standby server needed to provide read access?
 What are the budget constraints?

It is also very important to know what options are available in the different SQL Server editions
before planning for the actual implementation. The below table shows differences between
Enterprise and Standard High Availability features.

HA Options Enterprise Standard

16-node failover
Clustering 2-node failover clustering
clustering
Database Partial Support (Single Threaded, Safety Full
Full Support
Mirroring Only)
Log Shipping Full Support Full Support
Replication Full Support Oracle Publishing not supported.

To summarize:

 Failover Clustering is an ideal selection if there is no budget constraint.

 Database Mirroring is alternative choice with minimal down time, because of automatic
failover.
 Log Shipping is a good selection if we want to have multiple secondary servers.
 Replication is a good selection when there is the need to duplicate some of the data, send
the data to multiple servers or for disconnected architecture support.
 Multiple options can be used, if there is a need to further protect from failures.
 This is not a complete list of all pros and cons for each option, but I hope this gives you a
starting point on which technology to consider for your environment.
LOGSHIPPING COMPONENT

1) Log shipping is an automated way to apply a continuous

chain of transaction log
backups to one or more standby servers.
2)The primary database is online and accepting transactions.
3) The secondary database has a continuous chain of transaction
log backups applied to it.
4) The monitor server is an optional component that sends alerts
when the secondary database gets too far out of sync with the
primary database.

Primary Database
The primary database is accessible to applications and accepts transactions. Transaction
log backups are taken on a periodic basis and copied to the server hosting the secondary
database.
Secondary Database
The secondary database, also referred to as the standby, is normally inaccessible, and
transaction log backups from the primary database are restored on a continuous basis.
The secondary database can be in two different modes: Standby Mode or No Recovery
Mode. When the secondary database is in Standby Mode, users can connect to and issue
SELECT statements against the database. When the secondary database is in No Recovery Mode,
users cannot connect to the database. In either mode, you can restore transaction logs to the
secondary database. You cannot restore transaction logs when users are connected to the
database, so you should not use Standby Mode for high-availabilit architectures.
Monitor Server
The monitor server, which is optional within a log shipping architecture, contains a set of jobs
that send alerts when the log shipping session is perceived to be out of sync.
I created a database on the Principal SQL Server instance and named it TestMirror. The recovery
model is set to FULL RECOVERY.

1st step: Issue a full backup of the database.

BACKUP DATABASE TestMirror TO DISK = 'C:\Program Files\Microsoft SQL

Server\MSSQL10_50.MSSQLSERVER\MSSQL\Backup\Backup.bak';

2nd step: Issue a transaction log backup of the database.

BACKUP LOG TestMirror TO DISK = 'C:\Program Files\Microsoft SQL

Server\MSSQL10_50.MSSQLSERVER\MSSQL\Backup\Backup.trn';

Below are the two files in the file system:

3rd step: Assuming you have the backup folder shared on the Principal Server and you can
access it from the Mirror Server, you will need to restore the full backup to the Mirror server
with the NORECOVERY option.

RESTORE DATABASE TestMirror FROM DISK = N'\\Principal\Backup\Backup.bak'

WITH FILE = 1, MOVE N'TestMirror_log' TO
N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\
TestMirror_1.ldf',
NORECOVERY, NOUNLOAD, STATS = 10;

4th step: Restore log backup also with the NORECOVERY option.

RESTORE LOG TestMirror FROM DISK = N'\\Principal\Backup\Backup.trn'

WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 10;

Now it's time to dig down and configure Database Mirroring. From the Principal server, right
click the database and choose "Tasks" | "Mirror" or choose "Properties" | "Mirroring".
Click the "Configure Security" button and click "Next >" if the Configure Database Mirroring
Security Wizard intro screen appears. The next screen should be the Include Witness Server
screen:

This is where you would configure a witness server for your mirroring, but since we're just
configuring a basic mirror we will skip this part. However, if you are configuring mirroring in an
Enterprise environment it is recommended you configure a witness server because without one
you will not have synchronous automatic failover option.

Select "No", then click "Next >" to continue the process.

The next screen will give you options to configure the Principal Server Instance:

Here we will be creating our endpoint, which is a SQL Server object that allows SQL Server to
communicate over the network. We will name it Mirroring with a Listener Port of 5022.

Click the "Next >" button to continue.

The next screen will give you options to configure the Mirror Server Instance:
To connect to the Mirror server instance we will need to click the "Connect..." button then select
the mirror server and provide the correct credentials:

Once connected, we also notice our endpoint name is Mirroring and we are listening on port
5022.

Click "Next >" and you'll see the Service Accounts screen.
When using Windows Authentication, if the server instances use different accounts, specify the
service accounts for SQL Server. These service accounts must all be domain accounts (in the
same or trusted domains).

If all the server instances use the same domain account or use certificate-based authentication,
leave the fields blank.

Since my service accounts are using the same domain account, I'll leave this blank.

Click "Finish" and you'll see a Complete the Wizard screen that summarizes what we just
configured. Click "Finish" one more time.
If you see the big green check mark that means Database Mirroring has been configured
correctly. However, just because it is configured correctly doesn't mean that database mirroring
is going to start...

Next screen that pops up should be the Start/Do Not Start Mirroring screen:

We're going to click Do Not Start Mirroring just so we can look at the Operating Modes we can
use:

Since we didn't specify a witness server we will not get the High Safety with automatic failover
option, but we still get the High Performance and High Safety without automatic failover
options.

For this example, we'll stick with synchronous high safety without automatic failover so changes
on both servers will be synchronized.

Next, click "Start Mirroring" as shown below.

If everything turned out right, Database Mirroring has been started successfully and we are fully
synchronized.

If Database mirroring did not start successfully or you received an error here are a few scripts to
troubleshoot the situation:

Both servers should be listening on the same port. To verify this, run the following command:

SELECT type_desc, port

FROM sys.tcp_endpoints;

We are listening on port 5022. This should be the same on the Principal and Mirror servers:

Database mirroring should be started on both servers. To verify this, run the following command:

SELECT state_desc
FROM sys.database_mirroring_endpoints;

The state_desc column on both the Principal and Mirror server should be started:

To start an Endpoint, run the following:

ALTER ENDPOINT <Endpoint Name>

STATE = STARTED
AS TCP (LISTENER_PORT = <port number>)
FOR database_mirroring (ROLE = ALL);

ROLES should be the same on both the Principal and Mirror Server, to verify this run:

SELECT role
FROM sys.database_mirroring_endpoints;

To verify the login from the other server has CONNECT permissions run the following:

SELECT EP.name, SP.STATE,

CONVERT(nvarchar(38), suser_name(SP.grantor_principal_id))
AS GRANTOR,
SP.TYPE AS PERMISSION,
CONVERT(nvarchar(46),suser_name(SP.grantee_principal_id))
AS GRANTEE
FROM sys.server_permissions SP , sys.endpoints EP
WHERE SP.major_id = EP.endpoint_id
ORDER BY Permission,grantor, grantee;

You can see here from the State and Permissions column that the user has been Granted Connect
permissions.
CREATE DATABASE AdventureWorksDS ON
( NAME = AdventureWorks_Data, FILENAME =
'C:\Program Files\Microsoft SQL Server\
MSSQL10.MSSQLSERVER\MSSQL\Data\AdventureWorks_
data.ds' )
AS SNAPSHOT OF AdventureWorks;

GO

REPLICATION
Replication Components
The data to be replicated is defi ned by using three core components in the defi nition.
Articles
An article is the basic building block of replication and defi nes the most granular level
of data distribution. An article can be defi ned against a table, view, stored procedure, or
function.
The type of article that is most relevant for high availability is an article defi ned against a
table. The article defi nes the set of data within the table that SQL Server replicates to one or
more databases.
Publications
A publication is the most granular level within a replication architecture. Publications are
groupings of articles that define the replication set.
Filters
Replication is unique among the various high-availability technologies in that it has the ability
to make only a portion of a database redundant. You can apply one or more fi lters to each
article that restrict the set of data that is replicated.
You can fi lter articles by rows or by columns.

Replication Roles

Publisher
Distributor
subscriber
􀁑 The publisher maintains the master copy of the data within a replication architecture.
You confi gure the instance hosting the publisher database with the publication that
defi nes the set of data to be replicated.

􀁑 The distributor is the main engine within a replication architecture. The distribution
database is stored on the instance that is configured as the distributor. In any
replication architecture, the distributor is the location in which all replication agents
run by default.

􀁑 The subscriber is the database that is receiving changes from the replication engine
defi ned by the publication to which it is subscribing. A subscriber can receive changes
from more than one publication.
Central Subscriber Topology
A central subscriber topology consists of a single subscriber that has more than one publisher.
Changes are written to multiple publishers and then consolidated into a single subscriber,

Types Replication Agents

Snapshot Agent
The Snapshot Agent is actually snapshot.exe. This agent is responsible for extracting the schema
and data that need to be sent from publisher to subscriber. Snapshot.exe is used in snapshot,
transactional, and merge replication.
Log Reader Agent
The Log Reader Agent, logread.exe, is used only with transactional replication. It is used to extract
committed transactions from the transaction log on the publisher that need to be replicated.
After it extracts the committed transactions, the Log Reader Agent ensures that each transaction
is repackaged and written into the distribution database in exactly the same sequence as the
transaction was issued against the publisher. The sequencing by the Log Reader Agent is critical
to ensure that transactions are not applied to a subscriber out of order.

Distribution Agent
The Distribution Agent, distrib.exe, is used with snapshot and transactional replication. The
Distribution Agent has two functions: applying snapshots and sending transactions. The
Distribution Agent is responsible for applying each snapshot generated with snapshot or
transactional replication to all subscribers. It is also responsible for applying all the transactions
written to the distribution database by the Log Reader Agent to all subscribers.

Merge Agent
The Merge Agent, replmerg.exe, is used with merge replication. The Merge Agent applies the
snapshot generated when the subscriber is initialized. The Merge Agent is also responsible for
exchanging transactions between the publisher and subscriber.

Queue Reader Agent

The Queue Reader Agent, qrdrsvc.exe, is used only when the queued updating option for
transactional or snapshot replication has been enabled. The Queue Reader Agent is responsible
for transferring the queue on the subscriber to the publisher

Step 1: Configuring distributor and publisher

1. Take three instances

2. Go to second instance -> Right click on Replication -> Configure Distribution…
3. Next -> Select ‘SERVER2’ will act as its own distributor;

4. Next
5. Next
6. Next
7. Uncheck the check box present at Server2 -> Add

8. Select instance Server1

9. Next
10. Enter strong password. (Automatically one login is created in distributor with the name
Distributor_Admin)
11. Next
12. Next
13. Finish
Observations

1. Go to distributor -> Databases -> Find the new database “Distribution”

2. Go to Security -> Logins -> Find a new login “Distributor_admin”
3. Go to Server Objects -> Linked servers -> Find new linked server “repl_distributor”
4. Right Click on Replication -> Select distributor Properties
o Transactions stored in distribution database are removed after 72 hrs and agents history
is removed after 48 hrs.
o To view snapshot folder path -> Click on publishers -> click on browse button (…) present
to right side of publisher name.

o Go to SQL Server Agent -> Jobs -> Find 6 new jobs are created automatically.
Step 2: Creating Snapshot Publication

1. Go to publisher (Server1) -> Replication -> Right Click on Local Publications -> New publication.

2. Next
3. Select second option -> Click on Add -> Select Distributor instance (Server2)
4. Connect ? Next
5. Enter password of Distributor_admin login which we have mentioned while configuring
publisher.
6. Next
7. Select required database. For example SSISDb

8. Next
9. Select “Snapshot Publication” -> Next
10. Select required tables -> Next
11. Next -> Next
12. Select the check box to create snapshot as follows

13. Next
14. Click on security settings
15. Select as follows

16. OK
17. Next
18. Next -> Next
19. Enter publication name as follows
 20. Finish

Observations

1. Go to publisher -> Replication -> Local publications -> Find new publication is created
 2. To check snapshot was created or not -> Right click on the publication (SSISDBSP) -> View
Snapshot Agent Status
3. Go to repldata folder as follows:

4. Go to sub folders find the snapshot files (.bcp, .sch, idx, .trg)
5. Go to distributor -> SQL Server Agent -> Jobs -> Find snapshot agent job was created

FAQ: How to display database names which consists of publications?

Ans: Go to publisher -> take new query ->

Copy Code

select name from sys.databases where is_published=1 or is_subscribed=1

Creating Subscription

1. Go to publisher -> Replication -> Local Publications -> Right Click on SSISDBSP -> New
Subscription
2. Next
3. Select the publication name: SSISDBSP
4. Next
5. Select Push subscriptions

6. Next
7. Add Subscriber -> Select third instance (Server1\test) -> Connect
8. Next
9. Under Subscription Database if there is no database exists with same name -> Select New
database -> Enter Database Name -> OK -> Next

10. Click on browse button (…) under distribution agent security page.
11. Select “Run under Agent Service Account” and “By impersonating the process account” options
as both distributor and subscriber’s service accounts are same. If the service account of
subscriber is different, then create a login in subscriber with sysadmin privileges then mention
that login details.

12. Next
13. Under Agent Schedule -> Select “Run Continuously”
14. Under Initialize when select -> Immediately
 15. Next -> Next -> Finish

Observations

1. Go to subscriber -> SSISDB -> Tables -> Find two tables are created

2. Go to distributor -> SQL Server Agent -> Find new job is created, related to Distribution Agent
Verifying Replication

1. Go to publisher perform some changes in any table present in publication

2. Go to distributor run Snapshot Agent Job

3. Go to subscriber observe the changes in the respective table

Steps to Configure Log-Shipping:

1. Make sure your database is in full or bulk-logged recovery model. You can change the
database recovery model using the below query. You can check the database recovery model by
querying sys.databases

SELECT name, recovery_model_desc FROM sys.databases WHERE name = 'jugal'

USE [master]
GO
ALTER DATABASE [jugal] SET RECOVERY FULL WITH NO_WAIT
GO

2. On the primary server, right click on the database in SSMS and select Properties. Then select
the Transaction Log Shipping Page. Check the "Enable this as primary database in a log
shipping configuration" check box.

3. The next step is to configure and schedule a transaction log backup. Click on Backup
Settings... to do this.

If you are creating backups on a network share enter the network path or for the local machine
you can specify the local folder path. The backup compression feature was introduced in SQL
Server 2008 Enterprise edition. While configuring log shipping, we can control the backup
compression behavior of log backups by specifying the compression option. When this step is
completed it will create the backup job on the Primary Server.
4. In this step we will configure the secondary instance and database. Click on the Add... button
to configure the Secondary Server instance and database. You can add multiple servers if you
want to setup one to many server log-shipping.
When you click the Add... button it will take you to the below screen where you have to
configure the Secondary Server and database. Click on the Connect... button to connect to the
secondary server. Once you connect to the secondary server you can access the three tabs as
shown below.

Initialize Secondary Database tab

In this step you can specify how to create the data on the secondary server. You have three
options: create a backup and restore it, use an existing backup and restore or do nothing because
you have manually restored the database and have put it into the correct state to receive
additional backups.
Copy Files Tab

In this tab you have to specify the path of the Destination Shared Folder where the Log Shipping
Copy job will copy the T-Log backup files. This step will create the Copy job on the secondary
server.
Restore Transaction Log Tab

Here you have to specify the database restoring state information and restore schedule. This will
create the restore job on the secondary server.
5. In this step we will configure Log Shipping Monitoring which will notify us in case of any
failure. Please note Log Shipping monitoring configuration is optional.
Click on Settings... button which will take you to the "Log Shipping Monitor Settings" screen.
Click on Connect ... button to setup a monitor server. Monitoring can be done from the source
server, target server or a separate SQL Server instance. We can configure alerts on source /
destination server if respective jobs fail. Lastly we can also configure how long job history
records are retained in the MSDB database. Please note that you cannot add a monitor instance
once log shipping is configured.
6. Click on the OK button to finish the Log Shipping configuration and it will show you the
below screen.