Architecting a highly available SQL
Server is not a simple click of a check box in SSMS. There are a number
of different features and each one has its own pros and cons for a
given situation. In the following sections, we will examine each of
these major features.
1. Backup and Restore
Backup and Restore has been around since the
first versions of SQL Server. As a DBA, being able to backup and
restore your database is a key skill to master. From a high
availability standpoint, database backups are usually the last line of
defense against total data loss. It is critical that they are a part of
your disaster recovery plan.
2. Log Shipping
There are three types of database backups that
you may incorporate into your disaster recovery plan: full,
differential, and transaction logs. A full database backup is a point-in-time backup of all objects and
data that reside in the database. A differential backup is a backup of
the changes made to the database since the last differential or full
database backup. In both of these backup types, it is important to note
that, even though we are backing up the contents of the database within
the data files, the information that is stored in the transaction log
of the database is not backed up. There is a third backup type that is
called transaction log backup. A transaction log backup does what its
name implies; it backs up the transaction log of a particular database.
Having a transaction log backup in addition to a full or differential
allows us the most granular point-in-time restoration option available.
Log shipping is the automated process of
continually backing up the transaction log from the primary server,
copying the backup to a secondary or remote server, and restoring the
database in either STANDBY or NORECOVERY mode. Using NORECOVERY puts the secondary servers in a state where no users can connect to that specific database. The STANDBY
mode allows users connections, but these connections will be dropped
when a new transaction log is applied to the database. You can
configure this mode when you configure log shipping in SSMS.
Configuration
In this example we have two instances of SQL Server installed: ROB-DENALI-1 and ROB-DENALI-1\INST2.
We have a database called UsedCars that we will create and use to
configure log shipping. First, let’s connect to the first instance and
create our database.
To create the UsedCars database connect to the default instance via SSMS and open a new query editor window. Type the following code:
USE MASTER
GO
CREATE LOGIN BobLogin WITH PASSWORD='pass@word1'
GO
CREATE DATABASE UsedCars
GO
USE UsedCars
GO
CREATE USER Bob FOR LOGIN BobLogin
GO
CREATE SCHEMA Sales
AUTHORIZATION Bob
GO
CREATE SCHEMA Product
AUTHORIZATION Bob
GO
CREATE TABLE Product.Inventory
(car_id INT NOT NULL PRIMARY KEY,
car_make VARCHAR(50) NOT NULL,
car_model VARCHAR(50) NOT NULL,
car_year SMALLINT NOT NULL)
GO
CREATE TABLE Sales.Orders
(order_id INT NOT NULL PRIMARY KEY,
order_date DATETIME NOT NULL,
order_carsold INT REFERENCES Product.Inventory(car_id),
order_saleprice SMALLMONEY NOT NULL)
GO
INSERT INTO Product.Inventory VALUES (1,'Saab','9-3',1999),
(2,'Ford','Mustang',2003),(3,'Nissan','Pathfinder',2005)
GO
To configure log shipping
in SSMS, right-click the UsedCars database, and select Ship Transaction
Logs from the Tasks context menu. This will launch the UsedCars
Database Properties dialog with the Transaction Log Shipping panel
open. This context menu is just a shortcut to the panel in the Database
Properties dialog, shown in Figure 1.
Figure 1. Transaction Log Shipping panel in Database Properties dialog
When the “Enable this as a primary database in
a log shipping configuration” check box is checked, the Backup Settings
button will be enabled. There are not a lot of default settings, so to
enable transaction log shipping, you will have to supply a lot of
answers to the dialog. The Backup Settings dialog is shown in Figure 2.
Figure 2. Transaction Log Backup Settings dialog
This dialog requires the following information:
- “Network path to backup folder”: This location needs to be a
network share so that the secondary servers can connect and copy the
transaction log backup. You need to make sure there are read
permissions on this share for the SQL Server Agent account on the
secondary machine. Alternatively, you can define a proxy account on the
secondary server so that you do not have to use the SQL Server Agent
account. For this particular configuration we are log shipping between
two instances on the same machine and our SQL Server Agent account is
running as the Network Service account. We do not have to worry about
any additional permissions for this configuration. To create a share,
you can use Windows Explorer or open a Command Shell and type NET SHARE Backup=C:\backup.
- Local path to the backup folder: If the backup folder is on the same server as the primary server, type in the path. In our case, it’s C:\Backup.
As soon as those two pieces of information are
entered, the OK button is enabled. There are default settings for the
other information in this dialog that are important to note. Backing up
the transaction log, in most cases, doesn’t take much disk space.
However, over time, a bunch of transaction log backups can take a lot
of space. By default, a SQL Server Agent job will delete transaction
log backup files older than 72 hours. Also, you will be alerted by
default if, for any reason, a transaction log backup fails to happen
within an hour.
The Schedule button will launch the schedule dialog of the SQL Server Agent. By default, the job will execute every 15 minutes.
Starting in SQL Server 2008, database backups can be compressed. The Transaction Log shipping feature leverages the same BACKUP DATABASE
statement and can thus compress the transaction logs before they are
written to the file share. The “Set backup compression” drop-down will
allow you to either force compression or just do whatever is already
defined at the server instance.
Clicking OK on this dialog will enable us to
add secondary servers. We can add a secondary server by clicking the
Add button under the “Secondary server and instances” grid control.
Adding a secondary server launches the dialog shown in Figure 3.
Figure 3. The Secondary Database Settings dialog’s initialize panel
To add a secondary
database, connect to the SQL Server instance by clicking the Connect
button. This will launch a connection dialog. Once connected to the
secondary server, we can enter a name for the database in the Secondary
Server combo box.
The Secondary Database Settings dialog has
three panels: Initialize Secondary Database, Copy Files, and Restore
Transaction Log. In the Initialize Secondary Database panel, shown in Figure 3,
you can tell SSMS to take a full backup now or use an existing backup.
In order for Transaction Log Shipping to start, a backup of the
database needs to exist on the secondary.
Transaction Log Shipping is a three-step
process: backup, file copy, and restore. Details about the File Copy
process are defined in the Copy Files panel shown in Figure 4.
Figure 4. Secondary Database Settings dialog’s Copy Files panel
In this panel, we define the destination folder
where the secondary server will restore the transaction logs. We can
also specify the time to automatically delete files and schedule the
job that performs the file copy itself.
In the Restore Transaction Log panel, shown in Figure 5, we can specify how we want the secondary database to act with regard to clients.
Figure 5. Secondary Database Settings dialog’s Restore Transaction Log panel
If we specify “No recovery mode”, the database
will not be available to clients on the secondary servers. If we select
“Standby mode”, users can make active connections to the database on
the secondary server.
We can make one more configuration decision
regarding Transaction Log Shipping and that is if we want to have a
monitor server. By default, SQL Server Agent job information is stored
on the primary and secondary servers. A monitor server stores the same
information in a central place for easy reporting. In the scenario
where we have one secondary, it’s not that useful. However, if we have
multiple secondaries and multiple transaction log shipping sessions, a
monitor server is useful. To configure a monitor server, check the “Use
a monitor server instance” check box, and click the Connect button to
configure the monitor server. The monitor server can be any SQL Server
server; it does not have to be a separate installation of SQL Server.
Now that we have answered all the questions, we can go ahead and start transaction log shipping by clicking the OK button.
A few tables and stored procedures provide
status and configuration information on your log shipping
configuration.
SQL Server also has an out-of-the-box report
available to view the status of your transaction log shipping jobs. To
access this report, select the Transaction Log Shipping Status report
from the Standard Reports menu of the Reports menu of the SQL Server
instance context menu. A sample report is shown in Figure 6.
Figure 6. Sample Transaction Log Shipping Status report showing an alert
