Replicating and Restoring Microsoft SQL Databases with VERITAS Storage Replicator 2.1

Transcription

1 Replicating and Restoring Microsoft SQL Databases with VERITAS Storage Replicator 2.1 V E R I T A S W H I T E P A P E R March 4, 2002

2 Table of Contents Introduction Safe Replication of Live Databases Phases of a replication job Scheduled vs. Continuous Replication Replicating SQL Data SQL to SQL: SQL to File Server: Replication Coverage Replicating a User-Created SQL Database Example Multiple data files and log files Replicating all SQL databases Notes on SQL Server Post Replication Tasks Starting a Standby SQL Server Attaching a Replicated Database Attaching a database using the sp_attach_db Stored Procedure: Attaching a Database using SQL Enterprise Manager (SQL 2000) File Server Replication Client Connectivity Update ODBC on clients: Rename standby SQL Server: Microsoft SQL Server 7.0: Microsoft SQL Server 2000: Reverting to Primary SQL Server ( Failback ) Reverting all SQL databases Migrating a User-Created Database Back to the Original Server Considerations for reverse replication of live database files Detach the database: Perform one-time replication while database remains online: Configure SQL file locations to allow continuous replication: Additional applications for SQL replication with VSR Off-host Centralized Backup Migrating a Database to a New Server Publishing Copies of a Database

3 Introduction Corporate needs for storage and access of critical data demand that data be available at all times with little or no downtime. Many of the corporate environments today make use of Microsoft SQL Server to maintain storage of such critical data. This document outlines the replication of SQL databases using VERITAS Storage Replicator 2.1. Storage Replicator can be used to maintain real-time copies of databases stored in a safe location on the network. When the need arises, a standby SQL Server can be brought online, or Storage Replicator can be used to replicate the data to a working SQL server with minimal downtime. Storage Replicator can be used to migrate data from one SQL Server to another. It is also possible to use a product such as VERITAS NetBackup to back up copies of the database files from the standby server. This capability is known as off-host backup. This document describes several different approaches to replicating data maintained by SQL Server version 7.0 and SQL Server It describes the steps needed to replicate one or more databases, as well as the procedures to bring a database online on a standby server. It also outlines the steps needed to migrate the data from one or more databases back to a primary server when it comes back online. Safe Replication of Live Databases VERITAS Storage Replicator is a file replication product. It creates faithful copies of source files on one or more target systems. Storage Replicator has no explicit knowledge of databases such as those maintained by Microsoft SQL Server. However, it can still be used to make accurate copies of SQL databases on one or more target systems. It is important to note that Storage Replicator can make a faithful copy of a collection of files, even while these files are being updated on the source system. For a database product, such as Microsoft SQL Server, this means that Storage Replicator can be used to replicate all the files making up one or more databases, even while the databases are being updated. It is not necessary to shut down a SQL Server database in order to use Storage Replicator to copy it to a remote system. This section outlines the steps Storage Replicator takes to ensure a faithful, consistent copy of a database on a remote system. Phases of a Replication Job There are two phases to a Storage Replicator replication job the synchronization phase and the dynamic phase. These phases cooperate to guarantee a faithful replica of a collection of files on the target system. When a replication job first starts, it synchronizes copies of files between the source and target server. If a file exists on the source system but not on the target, the file is simply copied to the target system. If the file exists on both systems, Storage Replicator analyzes the differences in the files, and either sends the target a new copy of the file (if the file is smaller than 1 MB) or sends the target updated portions of the source file (if the file is larger than 1 MB). Of course, for large database files, synchronization may take a relatively long time. If there is update activity in the source database during this time, the files may be updated on the source, so the synchronized copies may contain stale data at the end of the synchronization phase. Storage Replicator protects against this mismatch by using the dynamic phase of replication. At the same time the source and target files are being synchronized, Storage Replicator also starts the dynamic phase of replication. The dynamic phase tracks changes to the files as they occur on the source system. At the end of the synchronization phase, changes that occurred to the source files are sent to the target system and are used to update the copies of the files on the target. The dynamic phase tracks changes to the source files in the order that they occur on the source system. Files on the target system are updated in the same order, maintaining write order fidelity. In this way, the relationships between write operations to different files on the source system are preserved on the target. This is important, for instance, in preserving the order SQL Server uses to write to its database log and data files to guarantee transactional consistency of a database. Scheduled vs. Continuous Replication There two main ways that Storage Replicator can be used to replicate files. With scheduled replication, Storage Replicator starts a replication job at a user-specified time. This job synchronizes the source and target files, as described above. When the synchronization phase finishes, and dynamic updates have been applied, the job terminates. It is possible to configure a replication schedule to ensure the source and target files are synchronized on a periodic basis. Page 1

4 Using this method, the files on the target system represent snapshots of the source files at the time of job termination. This can be useful, for instance, to make daily or hourly copies of important database files. If a Storage Replicator replication job is configured for continuous replication, changes made to the source files are replicated and also applied to the target files. Using continuous replication, the copies of the files on the target system represent live copies of the source files. A continuous replication job starts in the same way as a scheduled job. Source and target files are first synchronized, and then updates recorded by the dynamic phase of replication are applied to bring the target files up to date. At this point, the synchronization phase is finished. With a continuous replication job, the dynamic phase continues forever, recording all changes to source files and applying them to the target files. No further synchronization is needed. Either method of replication can be used with SQL Server data files. Replicating SQL Data There are two methods of using Storage Replicator replication to safeguard SQL data: SQL to SQL: Have a second, standby SQL Server on the network to which the data will be replicated (Target Server). Server A (Source SQL Server) Data Replication Server B (Target SQL Server) Data Figure 1 Server A Purpose: SQL Dir: Service Acct: Source Dir: Online SQL Server C:\Program Files\Microsoft SQL Server\MSSQL DomainA\Administrator C:\Program Files\Microsoft SQL Server\MSSQL\Data (The directory that will be replicated to the target) Server B Purpose: SQL Dir: Service Acct: Target Dir: Standby SQL Server C:\Program Files\Microsoft SQL Server\MSSQL DomainA\Administrator C:\Program Files\Microsoft SQL Server\MSSQL\Data (The directory where the replicated data will reside) Page 2

5 Note: Source Dir and Target Dir must be the same if replicating all SQL databases. If Server A fails in this scenario, replicated databases can be brought online by attaching them on Server B, or the entire SQL Server installation on Server B can be brought online (by starting the MSSQLServer Service on Server B). SQL to File Server: Replicate to and store the SQL data directory on a target server until the time for using the safeguarded information becomes necessary. The data can then be replicated to an operational SQL server. Server A (Source SQL Server) Data Replication Server B (Target File Server) Figure 2 Server A Purpose: SQL Dir: Service Acct: Source Dir: Online SQL Server C:\Program Files\Microsoft SQL Server\MSSQL DomainA\Administrator C:\Program Files\Microsoft SQL Server\MSSQL\Data (The directory that will be replicated to the target) Server B Purpose: SQL Dir: Service Acct: Target Dir: File Server SQL is not installed <N/A> D:\VSR\replica\MSSQL\Data (The directory where the replicated data will reside) Note: Source Dir and Target Dir do not have to be the same. With this scenario, if Server A fails, a new SQL Server will have to be brought online, and the data will then have to be replicated from Server B to the new SQL Server. Both methods reduce the amount of downtime that can be caused by a system failure. SQL to SQL replication will obviously have less downtime, but another Microsoft SQL Server license will be needed for this type of replication. SQL to File Server replication eliminates the need for an additional Microsoft SQL Server license, but because the data stored will have to be replicated again (to a SQL Server), the downtime is longer (See the File Server Replication section for additional steps that Page 3

6 are required). The corporate needs have to be explored before determining which method of replication is best suited for your environment. For a walkthrough of creating a SQL Replication job, see the sections below. Replication Coverage There are three main ways of protecting SQL data. The first method replicates one or more user-created databases to a standby system running SQL Server. This method uses SQL 7.0 and 2000 Server s ability to attach a database while SQL Server is running. The second method replicates all SQL Server databases, including system databases containing SQL configuration information, to a standby server. With either of these methods, SQL Server software is installed on two servers. The first, or primary, server is the one normally used to provide client access to the databases. The second, or standby, server can be used to provide access to a replicated copy of the data in the event of problems with the primary server. When using Storage Replicator to replicate SQL Server data files, a database using these files is only accessible on one server at a time. The third method replicates SQL Server data files to safe location on a file server. In this case, the file server does not run SQL Server software, but provides safe storage for a copy of data that can be recopied to restore access to databases in the event of a SQL Server failure. With any of these methods, it is also possible to perform off-host backup of the replicated data files. There are different considerations to keep in mind for each method, so they will be described separately in the following sections. Note: If you plan to use Storage Replicator to replicate SQL data in a primary/standby server configuration, the version of SQL Server software should be the same on both the primary and secondary server. While it is possible to attach a SQL 7.0 database with a SQL 2000 server, you cannot attach a SQL 2000 database with a SQL 7.0 server, since the internal database formats are slightly different. If you plan to use Storage Replicator to replicate SQL data in order to permanently migrate it to another server, the replication target system must run a version of SQL Server equal to or greater than the original source system. Thus, you can use Storage Replicator to migrate data from a SQL 7.0 server to a SQL 2000 server, but not the reverse. Replicating a User-Created SQL Database There are many cases where replicating all SQL Server databases is not needed. In those cases, you can configure Storage Replicator to replicate one or more user-created databases. One advantage of this approach is the ability to run SQL Server on both the original source server and on the standby server at the same time. Although the replicated databases will not be available on the standby server during replication, the standby server can serve other databases while replication proceeds. In the event the source server fails, the standby server can take over serving the replicated databases. Example Multiple Data Files and Log Files SQL installations can vary dramatically from network to network. It is very rare that the default setup of SQL will be followed. For performance/fault-tolerance reasons, the data files making up a database may be spread across multiple disks, and the transaction log files are usually kept on a different disk from the data files. The following procedure explains how to create a replication job to ensure all needed data is replicated in this type of scenario. This will include creating a job with multiple source directories, and replicating this information to the same directory structure on the target server.the steps to set up the replication job are as follows: The steps to set up the replication job are as follows: Page 4

7 Figure 3 Creating a new replication job 2. On the New Job Wizard Job Type screen, choose Standard (one to one) and click Next (4). Figure 4 Selecting a job type Page 5

8 3. On the Replication Options screen (Figure 5), check the Prescan and No Changes on Target options. You may also choose continuous replication by selecting the Exact Replica on Target, and the Continue Replicating After Synchronization. Once the appropriate options are selected, click Next to continue. Figure 5 Selecting job options 4. On the Replication Pairs screen, click Add Pair and select the current SQL Server as the Source and the standby SQL Server or file server as the Target. Figure 6 Configuring a replication pair Page 6

9 5. On the Replication Rules screen, select the first database directory path on the source machine. Highlight the directory that holds database files, and click the Add Rule button. Figure 7 Selecting a source directory 6. On the Rule screen, click Add in the Inclusions and Exclusions section and select the default filter (*.*) to replicate all files in this directory. It is also possible to select individual files to replicate by specifying their exact names for inclusion. Once set, click OK. In the Target Path section, click Edit and type the target path (where the data will be replicated to). Figure 8 Including files to be replicated Page 7

10 Once set, click OK to add the rule. If your database is made up of files in multiple directories, repeat Steps 5 and 6 to add any additional database directories, and/or database log directories to the replication job. If all the files are contained in a single directory, proceed to step 7. Note: When you replicate only user-created databases, the directory structure on the target does not have to be the same as the source. Because the master database is not being replicated, the master database on the target server will not hold the path information of the replicated database. When the replicated database is attached to the standby SQL Server, the target master database will then be updated with the correct path(s). If the database being replicated exists in multiple directories, it is easier to keep the target paths the same as the source. If this is not followed, additional steps will need to be taken to bring the replicated database online. Steps on how to attach a SQL database are outlined in the Attaching a Replicated Database section below. Once this is complete, select Rule List from the View As drop-down menu. This will show all source directories that are to be replicated. Verify all needed directories appear, and select Next. Figure 9 Confirming replication rules Page 8

11 7. On the Replication Schedule screen, select the days and hours the replication job should run, and, if wanted, check the Enable Scheduled Starts box. Click Finish to create the Replication Job. Figure 10 Setting a replication schedule Note: In this example, replication is set to run at all times. (Replication runs during all times highlighted in blue.) If you do not wish replication to run constantly, use the Clear All button to clear all times, and set the times you wish replication to run. For continuous replication jobs, you should make sure that all times are enabled. If you want the replication process to kick off automatically, select the Enable Scheduled Starts check box. If this is not selected, the job will have to be started manually using the Storage Replicator console. Once the schedule is set, select Finish to create the replication job. The master database is responsible for knowing which databases exist, and where they are located. Because the master database was not replicated, the Target SQL Server is unaware of these new databases. In order for a database to be available on the target server, it must be attached. The steps on how to do this can be found in the Attaching a Replicated Database section below. See the Post Replication Tasks section for steps that must be followed after a successful replication has occurred when you want to make the replicated databases available on a standby server. If replicating from SQL to a File Server, see the File Server Replication section for post replication tasks. Replicating All SQL Databases In some cases, it may be best to replicate all SQL Server databases, including system databases containing SQL configuration information. One reason to replicate all databases is if you make frequent changes to system tables, such as adding users to the syslogins table in SQL s master database. If you replicate all databases, changes to system tables will be reflected in the replicated data files. Page 9

12 There are several rules to follow when replicating all SQL databases. Because the master database contains information concerning the structure of the SQL installation, it is important to follow all steps listed below. Replicating databases is much like replicating any kind of data. With SQL Server, some measures must be taken to ensure the data is replicated safely and can be restored to a working state: If the installation of SQL Server on Machine A was given the path C:\Program Files\Microsoft SQL Server\MSSQL, then the installation of the SQL Server on Machine B must also be given the path C:\Program Files\Microsoft SQL Server\MSSQL. (If the installation paths vary between servers, the master database will contain incorrect path information after the replication, and the SQL Service on the standby server will fail to start.) All login credentials supplied during the original SQL installation must be supplied during the installation of the standby SQL Server. The MSSQLServer Service must be stopped on the target machine while the replication job is active. This will allow the current information stored on the target to be overwritten without causing any problems. If the MSSQLServer Service is running on the target machine when you start the replication job, the replication job will fail because the MSSQLServer Service has the database files open on the target machine. Note: On the source machine, the replication job is able to read the database files, even though the MSSQLServer Service may have them open. This allows Storage Replicator to replicate live databases, as described in a previous section of this paper. Creating a Storage Replicator job to replicate the all SQL databases is very similar to creating a job to replicate user-created databases. Follow the same steps as described in the previous section. The only difference is that the job must be configured to replicate all directories containing SQL database files, including the directory containing the master database. Remember also in this case that all source and target directory paths must match. To make the replicated data available to clients via the standby SQL Server, first wait for the replication job to finish. If you have enabled continuous replication for the job, wait until the Storage Replicator Console Monitor display shows that the job has permanently entered the dynamic replication phase. Then stop the replication job. Now the MSSQLServer Service on the standby server can be restarted to restore the replicated data to a working state. The result will be a replica of the original SQL Server, including all databases. After a successful replication of all SQL databases, additional steps are required, and are outlined in the How to section. Notes on SQL Server 2000 Considerations to take when replicating Microsoft SQL Server 2000: With Microsoft SQL Server 2000, the replication follows the same steps as for SQL Server 7.0. However, there is a new feature available with Microsoft SQL 2000 that allows for a more definable replication: Multiple instances in SQL 2000 create multiple data directories with names corresponding to the name of the instance within the server. Example: Two SQL Servers have been installed and registered on one machine, named CHEMIST. The first installation of SQL Server is known as the default server named CHEMIST, and the other server is called CHEMIST\SQL2. Both servers will show up in the server tree within the Enterprise Manager console, and each will have its own unique directory structure in the following format: C:\Program Files\Microsoft SQL Server\MSSQL\DATA (The first, or default, SQL server.) C:\Program Files\Microsoft SQL Server\MSSQL$SQL2\DATA (The second server instance, named SQL2.) Page 10

13 Each instance creates and runs a separate MSSQLServer service. Services for each consecutive instance will contain the name of the instance (example shown below): Using the same example as above, the two Servers have been installed and registered on one machine. Each will have its own MSSQLServer Service in the following format: MSSQLServer - (For the default server.) MSSQL$SQL2 - (For the SQL2 installation.) Post Replication Tasks There are a few steps that must be done before replicated databases can be brought online. This sections outlines the procedures that must be followed in order to bring the standby replicated data online successfully. This section also covers client connectivity and gives some suggestions on how clients can connect to the standby SQL Server. Starting a Standby SQL Server If you replicated all SQL Server databases to a standby SQL Server, there are two simple steps to follow to bring up the standby server: 1. If it is still running, stop the replication job. Stopping the replication job allows the files on the target system to be written, which is necessary for the correct operation of SQL Server. 2. Start the MSSQLServer service on the standby server. The MSSQLServer service will automatically bring all the replicated databases online. Attaching a Replicated Database If you replicated files for an individual database to a standby SQL server, the standby instance of SQL Server is unaware of the new database. In order for the new database to be available, the master database must be updated. Attaching the database does this. With SQL 7.0 or SQL 2000, you can use the sp_attach_db stored procedure to attach the database. With SQL 2000, you can also attach the database using the SQL Enterprise Manager. Instructions for each method are listed below: Attaching a Database Using the sp_attach_db Stored Procedure: Make sure to stop the replication job before attempting to attach the database. Syntax (See SQL Server Books Online for further information.): Arguments sp_attach_db [@dbname=]'dbname', = ] 'filename_n' [,...16 ] [@dbname =] 'dbname' is the name of the database to be attached to the server. The name must be unique. dbname is sysname, with a default of NULL. Page 11

14 =] 'filename_n' is the physical name, including path, of a database file. filename_n is nvarchar(260), with a default of NULL. There can be up to 16 file names specified. The parameter names start and increment Note: The file name list must include at least the primary file, which contains the system tables that point to other files in the database. The list must also include any files that were replicated to a different directory than the source. If the directory structure of the replicated data on the target is the same as the source, only the primary file needs to be specified. If the target directory structure does not match the source, you must specify all database files. Return Code Values Remarks 0 (success) or 1 (failure) If more than 16 files must be specified, use CREATE DATABASE with the FOR ATTACH clause. Permissions Needed Examples Only members of the sysadmin and dbcreator fixed server roles can execute this procedure. Attaching a database with multiple data and log directories that was replicated to a different directory structure on the Target Server: If the database is replicated to the same location on the Target (Source and Target directories are the same), the primary file will contain correct information about where the other files (data or log) exist on the Target Server. If the location is different (Source and Target directories are different), each file will need to be listed within the Stored Procedure (see example below). This example attaches a spanning database1 (4 data files and 1 log file) to the SQL Server: EXEC sp_attach_db Bank, 'E:\data1\Bank_branch_data.mdf', 'E:\data1\Bank_teller_data.ndf', 'E:\data1\Bank_account_data.ndf', 'E:\data1\Bank_history_data.ndf', 'E:\log1\Bank_log.ldf' Page 12

15 Attaching a Database using SQL Enterprise Manager (SQL 2000) With SQL 2000, you can use the SQL Enterprise Manager to attach a database, as in this example. Figure 11 Attaching a database using SQL Enterprise Manager File Server Replication If replicating from SQL to a File Server, and the source SQL Server fails, a new SQL Server will have to be brought online, and the data will then have to be replicated to the new SQL Server. When the new SQL Server is brought online, the following steps must be taken in order to replicate the safeguarded information: 1. If you replicated all SQL Server databases, stop the MSSQLServer service on the new server. If you are restoring an individual database, make sure the new SQL Server does not already have a database of the same name online. 2. Create a replication job to copy the data from the file server target directory (Ex: D:\VSR\replica\MSSQL\Data) to the appropriate directories (Ex: C:\Program Files\Microsoft SQL Server\MSSQL\Data) on the new SQL Server. Since this will be a one-time replication, do not select the continuous replication option for this job. Note: If the master database was replicated, the new SQL Server still must have the same directory structure as the original. If the standby SQL Server is installed with an alternate path, the SQL Services will fail to start. 3. Start the replication job. Since you did not configure continuous replication for this job, the job will expire after it has finished synchronizing all of the database files. Wait for the job to finish before proceeding to the next step. 4. If you replicated all SQL Server databases, restart the MSSQLServer service on the new server. Otherwise, follow the steps outlined in the previous section to attach the restored databases. Client Connectivity When the new standby Server is brought online, the clients must be able to access the new SQL Server. A couple of options have been listed below: Page 13

16 Update ODBC on clients: The server name for an ODBC connection is a registry value. A registry file can be created and distributed to clients to update the DSN value, and point to the new SQL Server. The best way to distribute this would be through a logon script. The problem is this will most likely require either a logoff/logon or a reboot in order to kick off the registry file merge. The DSN registry entry can be found in one of the following locations: User DSN: HKEY_CURRENT_USER\Software\ODBC\ODBC.INI System DSN: HKEY_LOCAL_MACHINE\Software\ODBC\ODBC.INI Rename standby SQL Server: This would definitely be the easiest solution, but other problems can arise from this. If the standby machine is used only for SQL Server, renaming the server will most likely not cause a problem. If other software is installed on this system, renaming it could potentially cause problems. The procedure for renaming the server varies between versions. Below are the steps to follow in order to rename the machine SQL Server is installed on: Microsoft SQL Server 7.0: If you change the computer name of the server, you cannot start Microsoft SQL Server until you run SQL Server Setup. You will be prompted to upgrade, and the necessary SQL Server options will be reset with the new computer name. After you ve upgraded, you can exit Setup. Your databases will not be affected by this procedure. Microsoft SQL Server 2000: When you change the name of the computer that is running Microsoft SQL Server 2000, the new name is recognized during SQL Server startup. You do not have to run Setup again to reset the computer name. You can connect to SQL Server using the new computer name after you have restarted the server. However, to correct the sysservers system table, you should manually run these procedures (Note: Make sure the replication job is stopped before running the sp_dropserver stored procedure): sp_dropserver <old_server_name> go sp_addserver <new_server_name> go Issues with Remote Logins: If the computer has any remote logins, sp_dropserver may generate an error similar to this: Server: Msg 15190, Level 16, State 1, Procedure sp_dropserver, Line 44 There are still remote logins for the server '<server_name>'. To resolve the error, you may need to drop remote logins for this server. Reverting to Primary SQL Server ( Failback ) The previous sections describe situations where the primary SQL Server has failed, and replicated copies of one or more databases are brought online on a standby server to resume service. In most cases, the primary server will then be repaired, and you may want to resume serving the databases from the primary server. However, while the primary server was offline, the databases may have been updated on the standby server. In order to preserve all the updates, you must replicate the standby copies of the databases back to the original server. The easiest way to do this is to create a reverse replication job to replicate the database files back to the original server. As with the original database file synchronization, Storage Replicator analyzes the differences between the two copies of the database files, and sends only the updated portions from Page 14

17 the standby server to the original server. Reverting All SQL Databases If you replicated all SQL Server databases to a standby SQL Server, there are two simple steps to follow to bring up the standby server: If your original replication job was configured to replicate all SQL databases, including system database files, to a standby server, the process for creating and running a reverse replication job is simple. 1. Using the Storage Replicator console, follow the steps as described in Figure 3 and Figure 4 to create a new replication job. 2. On the replication options screen, shown in Figure 5, select all the options, including the Exact Replica on Target and Continue Replicating options. These options allow you to keep the standby SQL Server online while the reverse replication proceeds. Updates to the databases on the standby server will still be allowed during reverse replication, and the updates themselves will be replicated back to the original server. 3. When you create the replication pair for the new job, reverse the order of source and target systems. The standby SQL server should now be selected as the source of replication, and the original SQL Server should be selected as the new target. 4. Follow the steps outlined in Figure 7 and Figure 8 to add all the directories containing SQL database files to the replication job. Since you are replicating all SQL databases, the source path must be the same as the target path for all files. 5. Review the selected paths by using the rule list view as shown in Figure If it is running, stop the MSSQLServer service on the original SQL Server system. This will allow the database files to be written back to the original system. 7. Start the replication job. 8. When the replication job has finished the synchronization phase and entered the dynamic-only phase of replication, stop the MSSQLServer service on the standby server. For a short period of time, the databases will be unavailable to clients. 9. After all the dynamic data has been replicated back to the original server, stop the replication job in preparation for starting MSSQLServer on the original system. Stopping the replication job allows the replicated files to be modified on the target (original server) system. 10. Finally, start the MSSQLServer service on the original server, following the steps described in Post Replication Tasks. Now that the original SQL Server is running again, you may restart the forward replication job to provide protection for the database files, just as when you started. Migrating a User-Created Database Back to the Original Server If you used Storage Replicator to protect one or more user-created databases, but not the system databases, the steps to migrate the databases back to the original server are slightly different than the method described above. As in the previous example, you will create a reverse replication job to synchronize the updated database files with the originals. However, in this case, you must be particularly aware of the effects of the Exact Replica on Target setting of a replication job. For example, let s say the original server had two databases, named BankOne and BankTwo. BankOne is made up of two files: E:\Data\BankOne.mdf E:\Log\BankOne_log.ldf Page 15

18 The database named BankTwo is also made up of two files: E:\Data\BankTwo.mdf E:\Log\BankTwo_log.ldf Notice the data files for the two databases share common directories. If you want to migrate vthe database named BankOne back to the original server, you must not use the Exact Replica on Target option when creating the reverse replication job. Otherwise, Storage Replicator will delete the BankTwo files (if they were not replicated in the original job), or will mistakenly replicate the BankTwo files back to the original server along with the BankOne files. Here are the steps to replicate only the BankOne files from the standby server, BLACKBIRD back to the original server, CHEMIST : 1. Use the Storage Replicator console to create a new one-to-one replication job: Figure 12 Page 16

19 Figure On the Replication Options screen, select only the Prescan and No Changes on Target options: Figure 14 Page 17

20 3. Configure the replication pair, setting the new source system to be the standby SQL Server, and the new target system to be the original SQL Server: Figure Create rules to replicate the individual files making up the database. First, select the source directory containing the data file: Figure 16 Page 18

21 5. Create a selection rule to replicate only the file for the database you are migrating: Figure Specify a custom path to restore the database back to its original directory on the original server: Figure 18 Page 19

22 7. Repeat steps 4 through 6 for each file to be replicated. In this example, we add the log file path. 8. Use the Source Tree view to confirm the files to be replicated. The selected source directories and files will be highlighted. Files that are not selected for replication will appear with a lighter file icon: Figure 19 Page 20

23 9. Since this replication will be a one-time replication, you may select Clear All to clear the schedule for this job. The job will be started manually in this case: Figure 20 Setting an empty schedule for manual replication job start 10. If there is a copy of the BankOne database currently online on the original SQL Server, detach it using the SQL Enterprise Manager or the sp_detach_db stored procedure so the copy from the standby SQL Server can be replicated back to the original server: Figure 21 Detaching a database Page 21

24 Considerations for Reverse Replication of Live Database Files Because this replication job was configured as a one time job without continuous replication, Storage Replicator will replicate updates to the database that occur only during the progress of the replication job. As soon as the replication job finishes, Storage Replicator will stop recording updates to the database on the standby server. Thus, the back replicated copy of the database on the original SQL Server will not reflect changes to the standby database made after replication job finishes. There are several alternatives for dealing with this problem: Detach the database: If possible, you should detach the database on the standby system before starting the replication job. This guarantees that no updates will be made to the database while it is being back-replicated. Unfortunately, the database will not be available to clients during the time the replication job is running. Perform one-time replication while database remains online: If the database must stay online on the standby server during replication, you should checkpoint the database before starting the replication job, if possible. Checkpointing the database before replication will flush all committed transactions to disk, making SQL recovery faster on the original SQL Server system when the database is finally put online there. If you cannot checkpoint the database, SQL recovery may take somewhat longer while SQL Server replays its transaction log to make the copy of the database consistent. If the database is to stay online during replication, you should monitor the progress of the replication job and detach the database as soon as the replication job finishes. This will prevent the standby copy of the database from being updated after the files have been replicated back to the original server. Unfortunately, there is still a small window where the standby database may be updated without the updates being replicated back to the original system. These updates are lost, and will not appear in the copy of the database on the original system. Configure SQL file locations to allow continuous replication: The best alternative is to configure the replication job in a way that allows you to do continuous replication, yet avoid deleting files from the original SQL Server directories. With continuous replication, you can keep the database online on the standby server until the synchronization phase of the replication job finishes. Then, you can safely detach the database on the standby server, giving only a short interruption to client service. Finally, you can attach the database and put it online on the original server. With a little planning, you can easily configure your SQL Servers to allow this kind of back-replication. The easiest way is to set up your original and standby SQL Servers so the files making up different databases are stored in different directories. This way, you can configure separate replication jobs for each database and the jobs can run as continuous replication jobs. When configured this way, back-replication will not delete any files from the target directories, since the directories contain only files related to a single database. Configuring a back-replication job in this case is very similar to the procedure described in the section entitled Replicating a User-Created SQL Database, with a few minor changes: 1. Since the replication will go in the reverse direction now, reverse the source and target system names when creating the replication pair. 2. Since the back-replication job will be a one-time job, use the Clear All button to clear the entire replication schedule. The back-replication job will be started manually. 3. Make sure that the target directories on the original SQL Server contain only files associated with a single database. It is also OK if the target directories are empty, since the reverse replication job will copy the standby server s database files to them. Start the reverse replication job. When the job finishes the synchronization phase, you should detach the database on the Page 22

25 standby SQL Server. The database will be unavailable for client access for a short time. Then follow the steps described in the section on Post Replication Tasks to bring the database online on the original server. Remember to stop the reverse replication job as described in that section of the paper. After you have stopped the reverse replication job and attached the database on the original server, you may restart the forward replication job to resume protecting the database. Additional Applications for SQL Replication with VERITAS Storage Replicator So far, this paper has discussed the use of Storage Replicator to replicate SQL database files to standby servers to protect against loss of a primary server. There are several other interesting uses for Storage Replicator replication of SQL databases, which will be outlined here. Off-host Centralized Backup Although replication can be used to protect against server failures, it is also generally good practice to perform periodic backups of SQL databases. These backups can be used to restore a database in the event of data corruption or server failure. In an enterprise with many SQL Servers deployed over a distributed area, it is usually desirable to employ a centralized backup strategy. It is often impractical to attach a device containing backup media, such as a tape library, to each SQL Server. With a centralized backup strategy, one or more backup servers collect and backup data from the SQL servers. These backup servers often have powerful tape libraries attached to them, and can be managed from a central location. One way of moving the SQL data from remote SQL servers to a central location is by using Storage Replicator to replicate the data from the SQL servers to the central backup server. With this kind of configuration, you set up a many-to-one replication job, or multiple one-to-one jobs. In either case, the central backup server is configured as the replication target for all the SQL servers. The central backup server then maintains copies of all the SQL data files from all the SQL servers, and can easily backup the files to a tape library or other media. SQL Server SQL Server Replication Pair Backup Server Replication Pair SQL Server Replication Pair Replication Pair SQL Server Figure 22 - Centralized backup configuration Page 23

26 With this method of centralization, running a backup job on the central backup server does not impact the performance of the SQL Servers. Migrating a Database to a New Server Sometimes, in order to expand capacity, you may want to move a database from its original server to a new one. This way, you can spread out the server load among more systems. You can use a Storage Replicator replication job to move the files making up a SQL database from the original machine to a new one. The steps are exactly the same as described in the section entitled Replicating a User-Created SQL Database, except now the target server becomes the new server for the selected database, instead of just being a standby server. Publishing Copies of a Database You can use a Storage Replicator replication job to publish copies of database files to remote servers on a regular basis. In this application, you would configure a one-to-many replication job to distribute database files from a central SQL server to several remote servers. The steps involved are almost the same as configuring a one-to-one replication job, except you will specify multiple replication pairs for the job. This type of replication is often used to provide read-only copies of databases to alternate servers for uses such as data mining or reporting. With this kind of a replication job, it is important to make sure you detach the database on the target server while the replication job is running. Otherwise, the data cannot be properly replicated. When the job is finished, you can reattach the database on the target server. Also, since you never back-replicate the data in this kind of job, any database updates on the remote system will simply be discarded the next time the replication job is run. (Storage Replicator does not enforce read-only semantics on the replicated database.) Page 24

27 VERITAS Software Corporation Corporate Headquarters 350 Ellis Street Mountain View, CA or For additional information about VERITAS Software, its products, or the location of an office near you, please call our corporate headquarters or visit our Web site at V E R I T A S W H I T E P A P E R Copyright 2002 VERITAS Software Corporation. All Rights Reserved. VERITAS, VERITAS Software, the VERITAS logo, and all other VERITAS product names and slogans are trademarks or registered trademarks of VERITAS Software Corporation in the US and/or other countries. Other product names and/or slogans mentioned herein may be trademarks or registered trademarks of their respective companies. Specifications and product offerings subject to change without notice. Printed in the USA. March