The following system stored procedures need to be executed to configure log shipping: On the primary server, execute the following system stored procedures: ■ master.dbo.sp_add_log_shipp
Trang 119 Once you have finished configuring log shipping, you will see a page similar to Figure 46-8.
Notice that it also has the option of scripting the log shipping configuration
If your log shipping has a number of non-default options, scripting your changes makes it easier to ensure that each time it is done the configuration stays the same.
FIGURE 46-8
Finished configuring log shipping
20 Once you click OK, the Save Log Shipping Configuration dialog box sets up the log shipping
as shown in Figure 46-9
Trang 2FIGURE 46-9
Successful completion of Log Shipping Configuration
Configuring log shipping using Transact-SQL
Like most other configurations log shipping can also be configured using Transact-SQL The easiest way
to configure log shipping using Transact-SQL is to configure it once using SQL Server Management
Studio and click Script Configuration as explained earlier (refer to Figure 46-8) The following system
stored procedures need to be executed to configure log shipping:
On the primary server, execute the following system stored procedures:
■ master.dbo.sp_add_log_shipping_primary_database: Configures the primary
database and creates the transaction log backup job
Trang 3■ msdb.dbo.sp_add_schedule: Creates the schedule for the backup job
■ msdb.dbo.sp_attach_schedule: Links the backup job to the schedule
■ msdb.dbo.sp_update_job: Enables the backup job
■ master.dbo.sp_add_log_shipping_primary_secondary: Adds an entry for the secondary database on the primary server
On the secondary server, execute the following system stored procedures:
■ master.dbo.sp_add_log_shipping_secondary_primary: Configures the primary server information and creates the copy and restore jobs
■ msdb.dbo.sp_add_schedule: Creates the schedule for the copy job
■ msdb.dbo.sp_attach_schedule: Links the copy job to the schedule
■ msdb.dbo.sp_add_schedule: Creates the schedule for the restore job
■ msdb.dbo.sp_attach_schedule: Links the restore job to the schedule
■ master.dbo.sp_add_log_shipping_secondary_database: Configures the secondary database
■ msdb.dbo.sp_update_job: Enables the copy job
■ msdb.dbo.sp_update_job: Enables the restore job
On the monitor server, execute the following system stored procedure:
■ master.dbo.sp_add_log_shipping_alert_job: Creates the alert job and adds the job
ID to thelog_shipping_monitor_alerttable
Post-log shipping configuration
As mentioned earlier, log shipping only applies the changes that are either captured in the transaction
log or in the initial full backup of the log shipping database Any database objects such as logins, jobs,
maintenance plans, SSIS packages, and linked servers that reside outside the log shipping database
need to be manually created on the warm standby server After configuring log shipping, it is very
important to synchronize the warm standby servers with all objects that live outside the log shipping
database Most of these objects can be easily scripted using Management Studio and can be applied on
the warm standby servers The frequency of applying the changes must meet the rate of changes in your
environment
One of the ways to synchronize the logins is to create an Integration Services (SSIS) job that connects to
each server and transfers the logins The frequency of this job will depend on how often new logins are
added to your primary server
Trang 4Checking Log Shipping Configuration
Once log shipping is configured, review the following checklist to verify the log shipping setup
On the primary server:
■ Right-click on the log shipping database and look at the database properties On the
Transac-tion Log Shipping page, note that the database is enabled as the primary database in the log
shipping configuration On this page you can review other log shipping details such as the
backup job schedule on the primary server, secondary server details, the copy and restore job
schedule on the secondary server, monitor server details, and whether backup compression is
being used
■ Expand SQL Server Agent and review the backup transaction log job
On the secondary server:
■ Expand SQL Server Agent and review the copy and restore transaction log backup
jobs
On the monitor server:
■ Expand SQL Server Agent and review the Alert job, the log shipping primary server alert, and
the log shipping secondary server alert
Monitoring Log Shipping
To monitor log shipping from SQL Server Management Studio, Microsoft provides a Transaction Log
Shipping Status report This report can be run on any SQL Server participating in the log shipping
con-figuration To run the Transaction Log Shipping Status report:
1 Connect to the primary, secondary, or monitor server using Object Explorer in SQL Server
Management Studio
2 Right-click the SQL Server instance, and then click Reports.
3 Click Standard Reports.
4 Click Transaction Log Shipping Status.
For a complete picture of the log shipping configuration, run this report on the monitor server, as
shown in Figure 46-10
Another method for monitoring log shipping is to directly review the status of the log shipping jobs
You can review the history of the transaction log backup job on the primary server and the history of
the copy and restore jobs on the secondary server
Log shipping can also be monitored using several monitoring tables and stored procedures The
informa-tion that can be retrieved from these sources includes the database name, last backup, last restore, time
since the last restore, and whether the alerts are enabled
Trang 5FIGURE 46-10
Executing the Transaction Log Shipping Status report on the monitor server
The following is a list of the tables that can be used to monitor log shipping These tables exist in the
MSDBdatabase (because log shipping is mainly executed by a collection of jobs) on all the servers that
are involved in the log shipping configuration:
■ msdb.dbo.log_shipping_monitor_alert
■ msdb.dbo.log_shipping_monitor_error_detail
■ msdb.dbo.log_shipping_monitor_history_detail
■ msdb.dbo.log_shipping_monitor_primary
■ msdb.dbo.log_shipping_monitor_secondary
■ msdb.dbo.log_shipping_primary_databases
■ msdb.dbo.log_shipping_secondary_databases
The following is a list of stored procedures that can be used to monitor log shipping They exist on all
the servers in themasterdatabase that are involved in the log shipping configuration:
■ master.sys.sp_help_log_shipping_monitor_primary
■ master.sys.sp_help_log_shipping_monitor_secondary
■ master.sys.sp_help_log_shipping_alert_job
■ master.sys.sp_help_log_shipping_primary_database
■ master.sys.sp_help_log_shipping_primary_secondary
■ master.sys.sp_help_log_shipping_secondary_database
Trang 6Modifying or Removing Log Shipping
After configuring log shipping you can edit, add, or remove a log shipping configuration For example,
you can add another secondary server to the log shipping configuration Or you may want to change
the schedule of the backup, copy, or restore jobs Sometimes you may need to remove a secondary
server from the log shipping configuration or remove log shipping completely from all the participating
servers
To modify or remove log shipping:
1 In the Object Explorer on the primary server in SQL Server Management Studio, right-click on
the log shipping database and look at the database properties
2 Under Select a page, click the Transaction Log Shipping page (refer to Figure 46-8).
3 To modify the parameters of the copy or restore jobs on the secondary server, highlight
the secondary server under ‘‘Secondary Server instances and databases’’ and click the
ellipses ( .).
4 To add a new secondary server, click Add under ‘‘Secondary Server instances and databases.’’
Follow steps 9 through 16 in the section ‘‘Configuring Log Shipping using Management
Studio.’’
5 To remove a secondary server, highlight the secondary server under ‘‘Secondary Server
instances and databases’’ and click Remove Log shipping will verify whether you want to
remove the secondary server, as shown in Figure 46-11 If you are sure, click Yes
FIGURE 46-11
Removing a secondary server from the log shipping configuration
When Yes is clicked, log shipping will delete the secondary database on the secondary server
as shown in Figure 46-12 Note that the copy and restore jobs on the secondary server are
deleted
6 To completely remove log shipping, clear the ‘‘Enable this as a primary database in a log
shipping configuration’’ check box Log shipping will ask you to confirm that you really want
to remove log shipping, as shown in Figure 46-13
Trang 7FIGURE 46-12
Deleting the secondary server from the log shipping configuration
FIGURE 46-13
Checking if you want to completely remove log shipping
This action will delete all jobs and history related to this log shipping configuration on all the servers involved in this log shipping configuration If you are sure, then click Yes Once it completely removes log shipping, the dialog shown in Figure 46-14 will appear
FIGURE 46-14
Completely removed log shipping configuration
Trang 8Switching Roles
Log shipping enables the capability to manually switch roles This action can be performed for
mainte-nance or in the case of a disaster Depending on the cause of the disaster and its severity, the likely first
step is to take a backup of the active transaction log, or tail of the log, on the primary server (if it is still
accessible) with theNORECOVERYoption
The next step is to transfer all the transaction log backups to the secondary server either using a SQL
Server Agent job or copying them manually Once copied, the transaction log backups need to be
restored in sequential order to the secondary server using theWITH NORECOVERYorWITH STANDBY
option for all transaction logs except the last one The last transaction log is restored using theWITH
RECOVERYoption to close any open transactions and bring the secondary database up to an online
state If all the transaction log backups have been restored using theWITH NORECOVERYorWITH
STANDBYoption, then there is no need to panic You can still recover the database using theRESTORE
DATABASE <database_name> WITH RECOVERYcommand Then disable the log shipping jobs and
alerts on the servers participating in the log shipping configuration
Next, verify that any database objects such as logins, jobs, maintenance plans, SSIS packages, and
linked servers that reside outside the log shipping database are created on the warm standby server For
example, if the logins are not created on the warm standby server, then the users will not be able to
connect and you will still have a server down situation
Finally, manually redirect the applications and users to the new primary server
Best Practice
Ihighly recommend thoroughly executing the role reversal steps and documenting them prior to needing to
failover to the warm standby server Failure to do this can significantly increase downtime and complexity
when you actually need to failover to the warm standby server
Returning to the original primary server
Once the primary server has been repaired and is ready to return to service, the following steps
reinitial-ize the primary server during a period when users are not connected:
1 Use an Integration Services job to move all the user logins from the warm standby server to
the primary server
2 Transfer the database from the warm standby server to the primary server using either a full
database backup and restore method or a detach and attach method If you had failed over
to the warm standby server in a controlled environment, you may be able to avoid taking a
complete backup and restore of the database by applying the transaction log backups from the
warm standby server to the original primary server
3 Redirect the applications and users to the original primary server.
Trang 9Availability is paramount to the success of most database projects, and it is becoming increasingly
important in regard to business requirements Log shipping, failover clustering, database mirroring, and
replication are all high-end features to provide a stable database environment for users
Log shipping is a robust and reliable high-availability disaster recovery and reporting solution that can
be implemented very easily with the hardware you already have; there is no need to purchase any new
costly hardware Log shipping backs up the transaction log on the primary server every few minutes
and restores it on the warm standby servers If the primary server stops working, you can make one of
the warm standby servers your new primary server The main problem with log shipping is that the role
change is a manual process and the DBA needs to be present to execute it It is possible to automate
most of the role change process using SQL Server Agent jobs, but some manual intervention is still
required and the clients have to be manually redirected to the new primary server
The next chapter discusses database mirroring, which provides per-database protection like log shipping
but also provides an automatic failover option
Trang 10Database Mirroring
IN THIS CHAPTER
Database mirroring overview Configuring database mirroring Monitoring database mirroring Pausing or removing database mirroring
Role switching
Achieving high database availability is one of the most important goals for
critical business applications Database mirroring is a software solution
offered by Microsoft SQL Server 2008 to achieve high database
avail-ability Database mirroring enables you to maintain a copy of your production
database that could potentially be completely synchronized on a separate server
for failover in the event of a failed production server or database Like log
shipping, database mirroring provides high availability at the database level; but
unlike log shipping, database mirroring can be configured to provide no data loss
and automatic failover
Database Mirroring Overview
Database mirroring was officially supported with SQL Server 2005 SP1 It is
avail-able in Enterprise and Developer Editions, and with some restrictions in Standard
Edition Developer Edition can be used only for development purposes and not
for production
The basic concept of database mirroring is very simple Database mirroring
maintains a hot standby database (mirror database) that is kept in sync with
the production database (principal database) by transferring transaction log
records from the principal database to a mirror database over the network, either
synchronously or asynchronously In case of a failure, the mirror database can be
quickly accessed by the clients Database mirroring has the following benefits:
■ It increases database protection by maintaining a mirror copy of your
database
■ It allows you to choose only the databases that you want to mirror