Tài liệu ORACLE8i- P28 docx

CHAPTER 26 • HIGH AVAILABILITY 1082 Configuring the Primary Instance To implement managed recovery, you will need to configure the primary instance to archive redo logs to the standby host. If you plan to use manual recovery, you do not need to make any configuration changes to the primary instance. To configure the primary instance to archive redo logs to the standby host, you will need to set up the init.ora file for the primary instance with information about where to archive these logs. You do not need to shut down the primary instance to enable these parameters. Instead, you can manually enable them using the ALTER SYSTEM command, as described in the “Enabling Parameters for the Primary Instance” section later in this chapter. The archive destination is specified by using the LOG_ARCHIVE_DEST_n parame- ter, where n is an integer from 1 to 5. Up to five destinations may be defined, but one destination must be a local device. When setting these parameters, the keyword LOCATION specifies a valid path for the local archive destination, and the keyword SERVICE specifies a service name referenced in the tnsnames.ora file. The SERVICE keyword must be specified for all standby archive destinations, whether local or remote. Here is an example of using the LOG_ARCHIVE_DEST_n parameters in the init.ora file of the primary instance: log_archive_dest_1 = ‘location=/u02/arch/PRMRY’ log_archive_dest_2 = ‘service=stdby’ There are several options that you can set with the LOG_ARCHIVE_DEST_n param- eter, as described in the following sections. Setting a Mandatory or Optional Destination You can specify whether a destination is mandatory or optional by using the MANDATORY or OPTIONAL keyword, respectively. Oracle recommends that you specify the local archived redo log destination as MANDATORY. The following is an example of using the MANDATORY and OPTIONAL keywords: log_archive_dest_1 = ‘location=/u02/arch/PRMRY MANDATORY’ log_archive_dest_2 = ‘service=stdby OPTIONAL’ Specifying Access after a Failed Write By default, Oracle will not attempt to access a destination following an error. You can specify that Oracle should attempt to access an archived redo log destination again after a failed write using the REOPEN keyword. The REOPEN keyword specifies the number of seconds Oracle will wait before the archiver process should attempt to access a failed destination again. The default value of the REOPEN keyword when specified without qualification is 300 seconds. (If you do not specify the REOPEN key- word, the default value is 0.) You can override the default by using REOPEN=n, where C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 1083 n is the number of seconds to wait. The following is an example of using the REOPEN keyword: log_archive_dest_2 = ‘service=stdby OPTIONAL REOPEN=60’ Setting the Minimum Successful Write Destinations The LOG_ARCHIVE_MIN_SUCCEED_DEST parameter specifies the minimum number of destinations where the archiver process must successfully write archived redo logs before the source redo log is available for new writes. When archived redo logs are written, the count of successful writes to all MANDATORY destinations and OPTIONAL nonstandby destinations is measured to satisfy the setting of the LOG_ARCHIVE_ MIN_SUCCEED_DEST parameter. The default setting for LOG_ARCHIVE_MIN_ SUCCEED_DEST is 1, and valid values are 1 through 5. Enabling or Deferring a Destination It is possible to define archived redo log destinations without enabling those destina- tions. Whether or not an archived redo log destination is enabled is specified using the LOG_ARCHIVE_DEST_STATE_n parameter, where n is an integer from 1 to 5, cor- responding to the respective LOG_ARCHIVE_DEST_n parameter. Valid values are ENABLE or DEFER. ENABLE, the default setting, tells Oracle to archive to the defined destination. The DEFER setting allows you to define the destination without actually archiving to that destination. The deferred destination can later be enabled dynami- cally using the ALTER SESSION or ALTER SYSTEM command. The following example illustrates how to define an archived redo log destination without enabling it: log_archive_dest_state_2 = DEFER log_archive_dest_2 = ‘service=stdby’ Configuring the Standby Instance You can create the initialization parameter file for the standby instance by copying the initialization parameter file from the primary instance. With a few exceptions, the initialization parameters for the primary instance and the standby instance should have the same settings. Setting Standby Initialization Parameters The following parameters are particularly important when you are configuring the standby instance: • The COMPATIBLE parameter settings should be identical for the primary and standby instances. • The DB_NAME parameter settings should also be identical in both files. • The CONTROL_FILES parameter for the standby instance should be set to the fully qualified name of the standby control file. USING A STANDBY DATABASE Oracle8i Distributed Database PART IV C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 26 • HIGH AVAILABILITY 1084 • The LOG_ARCHIVE_DEST_n (described earlier in the “Configuring the Primary Instance” section) specifies the location of the archived redo logs for manual recovery. This parameter should be set whether you are configuring managed or manual recovery. • The optional parameter LOG_ARCHIVE_TRACE causes an audit trail of archived redo logs received from the primary database to be written to a trace file. • In a managed recovery environment, the STANDBY_ARCHIVE_DEST parameter sets the location to write the archived redo logs received from the primary data- base. Set LOG_ARCHIVE_DEST_n and STANDBY_ARCHIVE_DEST to identical values for easier maintenance. Setting Parameters for a Standby on the Same Host as the Primary When the primary and standby databases reside on the same host, several other standby initialization parameters are important. These include the DB_FILE_NAME_ CONVERT, LOG_FILE_NAME_CONVERT, and LOCK_NAME_SPACE parameters. The DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT parameters in the standby initialization parameter file enable automatic name conversion of datafiles and archived redo logs, respectively. Ideally, the directory structures in the primary and standby databases should be identical. However, if they are not (because the primary and standby databases reside on the same host or for some other reason), you will need to update the standby control file with the new filenames. The DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT parameters each specify two strings. The first string is that portion of the path structure of the primary database to be converted. The second string is the new path structure to replace the structure specified by the first string. Here’s an example of the DB_FILE_NAME_ CONVERT parameter set in the standby database initialization parameter file: db_file_name_convert = /u01/oradata/PRMRY, /u01/oradata/STDBY The LOCK_NAME_SPACE parameter also must be set for the standby instance when the primary and standby databases reside on the same host, as follows: lock_name_space = stdby If this parameter is not set for the two instances, you will receive an ORA-1102 error. Mounting the Standby Database When you are ready to start the standby database, follow these steps: 1. Connect to Oracle from SQL*Plus: $ sqlplus /NOLOG SQL> CONNECT INTERNAL C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 1085 2. Start the instance without mounting the database: SQL> STARTUP NOMOUNT 3. Mount the database as a standby database: SQL> ALTER DATABASE MOUNT STANDBY DATABASE; Renaming Files on the Standby Site If you are unable to correctly rename all of the datafiles and redo log files for the standby database using conversion parameters, you will need to manually rename these files before starting recovery. For example, suppose that the DB_FILE_NAME_ CONVERT parameter was set to convert the path /u01/oradata/PRMRY to /u01/ oradata/STDBY. However, a datafile was erroneously created following the path /u01/app/oracle/admin/PRMRY, and you are unable to take the downtime to correct this error. You can still move this datafile on the standby site to the correct path, but you will need to manually rename this datafile in the standby control file. To manually rename a datafile, with the standby database mounted, use the ALTER DATABASE RENAME FILE command, as follows: SQL> ALTER DATABASE RENAME FILE 2> ‘/u01/app/oracle/admin/PRMRY/temp01.dbf’ to 3> ‘/u01/oradata/STDBY/temp01.dbf’; Enabling Parameters for the Primary Instance If you are implementing managed recovery, you have configured the initialization parameter file of the primary instance to archive redo logs to the standby site (as described in the “Configuring the Primary Instance” section earlier in this chapter). However, if you have not shut down and restarted the instance, these new settings have not taken effect. You can enable these new parameter settings dynamically with- out shutting down the instance by using the ALTER SYSTEM command. For example, suppose that you set the LOG_ARCHIVE_DEST_2 parameter as follows: log_archive_dest_2 = “service=stdby” You can now enable this parameter with the following command: SQL> ALTER SYSTEM SET log_archive_dest_2 = “service=stdby”; Enabling Recovery Your next step is to start the recovery process of the standby database. How you start the recovery depends on the type of recovery you have chosen for your environment. USING A STANDBY DATABASE Oracle8i Distributed Database PART IV C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 26 • HIGH AVAILABILITY 1086 Enabling Manual Recovery If you chose to use the manual recovery process, you can initiate recovery by issuing the following command: SQL> RECOVER STANDBY DATABASE; This command tells Oracle to use the location specified in the initialization file. Alternatively, you can start manual recovery with this command: SQL> RECOVER FROM ‘/u02/arch/STDBY’ STANDBY DATABASE; As you can see, this command gives the location of the archived log files to be used for the current recovery session. You can also use the above commands with the UNTIL CANCEL option: SQL> RECOVER STANDBY DATABSE UNTIL CANCEL; SQL> RECOVER FROM ‘/u02/arch/STDBY’ STANDBY DATABASE UNTIL CANCEL; When using this command, Oracle will prompt you for each archived redo log file that it wants to apply and wait for you to acknowledge the prompt before continuing. Enabling Managed Recovery If you are using the managed recovery option, you will first need to check to see if a gap sequence exists. Since Oracle rolls the standby database forward by sequentially applying the archived redo log files, it cannot enter into a managed recovery session if there is a missing log. A gap sequence exists when the primary database generated a log sequence that was not archived to the standby site. A gap sequence may occur for a number of reasons, such as the following: • The standby database was created from an old backup or from an inconsistent (online) backup. • You shut down the standby database(s) before shutting down the primary database. • There was a network failure. If a gap sequence exists, you will need to manually apply the missing archived redo log files to bring the standby database in synch with the primary site. You can query the standby database to see if a gap sequence exists using SQL*Plus, as follows: SELECT high.thread#, “LowGap#”, “HighGap#” FROM ( SELECT thread#, MIN(sequence#)-1 “HighGap#” FROM C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 1087 ( SELECT a.thread#, a.sequence# FROM ( SELECT * FROM v$archived_log ) a, ( SELECT thread#, MAX(next_change#)gap1 FROM v$log_history GROUP BY thread# ) b WHERE a.thread# = b.thread# AND a.next_change# > gap1 ) GROUP BY thread# ) high, ( SELECT thread#, MIN(sequence#) “LowGap#” FROM ( SELECT thread#, sequence# FROM v$log_history, v$datafile WHERE checkpoint_change# <= next_change# AND checkpoint_change# >= first_change# ) GROUP BY thread# ) low WHERE low.thread# = high.thread#; This query will generate an output similar to the following: THREAD# LowSeq# HighSeq# 1 171 174 This shows that a gap sequence exists for thread #1 and that logs 171 through 174 should be manually applied to the standby database. If the HIGHSEQ# and LOWSEQ# columns both show the same number, a gap sequence does not exist for that particu- lar thread. USING A STANDBY DATABASE Oracle8i Distributed Database PART IV C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 26 • HIGH AVAILABILITY 1088 If there is a gap sequence, query the V$ARCHIVED_LOG view in the primary data- base to obtain the names of the log files that need to be manually applied, as follows: SQL> SELECT name 2> FROM v$archived_log 3> WHERE sequence# >= 171 4> AND sequence# <= 174; NAME /u02/arch/primary/arch_PRMRY_1_171.log /u02/arch/primary/arch_PRMRY_1_172.log /u02/arch/primary/arch_PRMRY_1_173.log /u02/arch/primary/arch_PRMRY_1_174.log You will then need to copy these archived log files from the primary database’s archiving destination to the standby database’s receiving destination. After the files have been copied, issue either the RECOVER STANDBY DATABASE UNTIL CANCEL or RECOVER AUTOMATIC STANDBY DATABASE command to apply the necessary log files. Once the gap sequence has been resolved, you can initiate a managed recovery ses- sion for your standby database, as follows: SQL> RECOVER MANAGED STANDBY DATABASE; When you use this statement, Oracle will wait indefinitely for the new archived log files to be received and automatically apply them to your standby database. If you want to specify a waiting period, use the TIMEOUT option and specify the length of time to wait, in minutes: SQL> RECOVER MANAGED STANDBY DATABASE TIMEOUT 10; In this example, Oracle will wait for 10 minutes for new archived log files to arrive before it will time out and cancel the managed recovery session. Testing the Standby Database You are now ready to test the failover functionality of your newly created standby database. However, if you simply activated the standby database, you would need to open the database using the RESETLOGS command. Of course, once the standby data- base has been opened with RESETLOGS, the only way to resume in standby mode is to re-create the standby database. The solution to this problem is to test your standby database failover functionality by first using cancel-based recovery, and then starting the standby database in read-only mode. C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 1089 For a managed recovery process, cancel the recovery session and shut down the standby instance by issuing this command: SQL> RECOVER MANAGED STANDBY DATABASE CANCEL For manual recovery, use the following commands: SQL> RECOVER CANCEL SQL> SHUTDOWN IMMEDIATE Next, start the standby database and put it in MOUNT mode: SQL> STARTUP NOMOUNT SQL> ALTER DATABASE MOUNT STANDBY DATABASE; Then, in MOUNT mode, open the database in read-only mode: SQL> ALTER DATABASE OPEN READ ONLY; Once the standby database has been opened in read-only mode, you can query the standby database to verify that the transactions executed on the primary site are propagated to the standby site. Maintaining a Standby Database The previous sections walked you through a step-by-step process of creating a standby database. So now that you have a fully operational standby database, what’s next? Like everything else, your standby database will require some administration and maintenance. Generally, the only maintenance that is required for a standby database is to keep it in synch with the primary database. Some problems you may run into while managing standby databases include the need to resolve redo log sequence number gaps as they occur. Other tasks include making sure that the physical struc- ture of the standby database matches that of the primary database and manually propagating any data that was applied to the primary site via the DIRECT or UNRE- COVERABLE mode. Let’s take a closer look at these situations. TIP The standby database can also be backed up, but not while the database is in recovery mode. Either shut down the standby database or open it in read-only mode. Make the backups. Then resume recovery. Resolving Gap Sequences Common causes for gap sequences (after the standby database is operational) are net- work failures and shutting down the standby database while the primary database is still open. You will need to be aware of these situations and regularly monitor the USING A STANDBY DATABASE Oracle8i Distributed Database PART IV C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 26 • HIGH AVAILABILITY 1090 standby database to ensure that a gap sequence does not occur. If you do find a gap sequence, you will need to manually resolve it, as explained in the “Enabling Man- aged Recovery” section earlier in this chapter. Matching Changes in the Physical Structure Standby database recovery is possible only as long as the physical structure matches that of the primary database. Certain physical structure changes are transmitted auto- matically to the standby database via redo application. Such changes include renam- ing a primary database’s datafile, changing the mode of a tablespace from offline to online or vice versa, changing the status of a tablespace from read-only to read/write or vice versa, and dropping a tablespace. Other structural changes require a certain degree of manual maintenance on the standby database. Such changes include re-creating the control file and adding a tablespace/datafile to the primary database. Re-creating the Standby Control File Creating new members or groups on the primary database does not affect the standby database. Similarly, enabling or disabling threads does not affect the standby database either. However, it is recommended that if you enable or disable threads, or add or drop groups or members on the primary database, you re-create the standby control file. This keeps the redo log file configuration on the primary and the standby data- bases in synch. WARNING If for some reason, the unarchived log files need to be cleared on the pri- mary instance, you will invalidate the entire standby database. Your only option at that time will be to re-create the standby database. Changing certain initialization parameters requires re-creating the control file. If you re-create the primary database’s control file, you will invalidate the standby data- base’s control file. Therefore, you will need to re-create the standby database’s control file. Follow these steps to re-create a standby control file (note that these steps assume that the primary database’s control files have been re-created): 1. Cancel the recovery session and shut down the standby instance. • For managed recovery, issue: SQL> RECOVER MANAGED STANDBY DATABASE CANCEL • For manual recovery, use: SQL> RECOVER CANCEL SQL> SHUTDOWN IMMEDIATE C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 1091 2. Log in to the primary instance and use the following statement to create a standby control file: SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS ‘/tmp/stdby.ctl’; 3. Archive the online redo log file on the primary database: SQL> ALTER SYSTEM ARCHIVE LOG CURRENT; 4. Copy the newly created standby control file from the primary host to the standby host and start the standby instance in recovery mode: SQL> STARTUP NOMOUNT SQL> ALTER DATABASE MOUNT STANDBY DATABASE; SQL> RECOVER STANDBY DATABASE NOTE If you restored a control file from backup on the primary database or opened the primary database with the RESETLOGS command, you will need to re-create the standby database. Adding Tablespaces/Datafiles Whenever a new datafile is added to the primary site, the same file needs to be added to the standby site (or sites) as well. Suppose that you add a new datafile to the pri- mary site like this: SQL> ALTER TABLESPACE TEMP ADD DATAFILE ‘/u01/oradata/PRMRY/temp02.dbf’ SIZE 200M; Redo generated from this statement will add the name of the new datafile to the standby control file. However, in order for the standby database to continue recovery, you must copy the file to its corresponding location. You can also cancel the recovery session on the standby site and create the datafile. To switch log files on the primary site to initiate archival of the redo logs to the standby site, issue the following statement: SQL> ALTER SYSTEM SWITCH LOGFILE; Next, ensure that the standby database is running in recovery mode. Initiate man- ual recovery, if necessary: SQL> CONNECT INTERNAL SQL> STARTUP NOMOUNT SQL> ALTER DATABASE MOUNT STANDBY DATABASE; SQL> RECOVER MANAGED STANDBY DATABASE; USING A STANDBY DATABASE Oracle8i Distributed Database PART IV C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.