Hướng dẫn học Microsoft SQL Server 2008 part 113 pot

Nielsen c46.tex V4 - 07/21/2009 3:17pm Page 1082 Part VI Enterprise Data Management 19. 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. 1082 www.getcoolebook.com Nielsen c46.tex V4 - 07/21/2009 3:17pm Page 1083 Log Shipping 46 FIGURE 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 1083 www.getcoolebook.com Nielsen c46.tex V4 - 07/21/2009 3:17pm Page 1084 Part VI Enterprise Data Management ■ 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 the log_shipping_monitor_alert table 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. 1084 www.getcoolebook.com Nielsen c46.tex V4 - 07/21/2009 3:17pm Page 1085 Log Shipping 46 Checking 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. 1085 www.getcoolebook.com Nielsen c46.tex V4 - 07/21/2009 3:17pm Page 1086 Part VI Enterprise Data Management FIGURE 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 MSDB database (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 the master database 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 ■ master.sys.sp_help_log_shipping_secondary_primary 1086 www.getcoolebook.com Nielsen c46.tex V4 - 07/21/2009 3:17pm Page 1087 Log Shipping 46 Modifying 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. 1087 www.getcoolebook.com Nielsen c46.tex V4 - 07/21/2009 3:17pm Page 1088 Part VI Enterprise Data Management FIGURE 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 1088 www.getcoolebook.com Nielsen c46.tex V4 - 07/21/2009 3:17pm Page 1089 Log Shipping 46 Switching 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 the NORECOVERY option. 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 the WITH NORECOVERY or WITH STANDBY option for all transaction logs except the last one. The last transaction log is restored using the WITH RECOVERY option 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 the WITH NORECOVERY or WITH STANDBY option, then there is no need to panic. You can still recover the database using the RESTORE DATABASE <database_name> WITH RECOVERY command. 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 I highly 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. 1089 www.getcoolebook.com Nielsen c46.tex V4 - 07/21/2009 3:17pm Page 1090 Part VI Enterprise Data Management Summary Availability 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. 1090 www.getcoolebook.com Nielsen c47.tex V4 - 07/21/2009 3:19pm Page 1091 Database Mirroring IN THIS CHAPTER Database mirroring overview Configuring database mirroring Monitoring database mirroring Pausing or removing database mirroring Role switching A chieving 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 a nd 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 from one SQL Server instance to another. There is a 1:1 ratio from the principal server to the mirror server. Multiple databases in a SQL Server instance can be mirrored. 1091 www.getcoolebook.com . 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. 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. that you want to mirror from one SQL Server instance to another. There is a 1:1 ratio from the principal server to the mirror server. Multiple databases in a SQL Server instance can be mirrored. 1091 www.getcoolebook.com