Release 7.0
A42860-1
 Library |
 Product |
 Contents |
 Index |
| Oracle Rdb7(tm) and Oracle CODASYL DBMS(tm) Guide to Hot Standby(tm) Databases Release 7.0 A42860-1 |
|
This chapter provides a step-by-step procedure to implement a Hot Standby database environment. Although the Hot Standby software performs replication activities automatically and transparently, you must perform the tasks described in this chapter to enable the master and standby databases for replication.
All discussions are based on a configuration in which two identical computing sites and databases are connected by a network. Ideally, the standby site should be identical (or nearly identical) to the master site both in configuration and available resources. Oracle Corporation recommends identical configurations so you can fail over application processing to the standby site for an unlimited amount of time.
As you set up your Hot Standby environment, consider using the DBO or RMU Dump Header command to verify database attribute information. This chapter includes displays of database header information to show you the results of the task being performed. Example 2-1 shows the header information for a master database before it is prepared for replication.
$ RMU/DUMP/HEADER=HOT_STANDBY/OUT=master.lis mf_personnel $ TYPE master.lis *------------------------------------------------------------------------------ * Oracle Rdb V7.0-00 24-MAY-1996 09:18:54.000 * Dump of Database header * Database: DISK1:[USER]MF_PERSONNEL.RDB;1 *------------------------------------------------------------------------------ Database Parameters: Root filename is "DISK1:[USER]MF_PERSONNEL.RDB;1" Hot Standby... - WARNING: After-image journaling is disabled - WARNING: Fast commit is disabled - WARNING: Log server startup is MANUAL - Informational: Operator notification is disabled - Database is not currently being replicated
Table 2-1 provides a checklist of tasks that you perform to start replication operations. Each step includes a reference to a section later in this chapter that provides additional information.
Example 2-2 shows one way to implement the procedures outlined in Table 2-1 for an Oracle Rdb database running on an OpenVMS system.
$ SQL ALTER DATABASE FILE mf_personnel JOURNAL IS ENABLED RESERVE 5 JOURNALS ADD JOURNAL AIJ_1 FILENAME `DISK1:[USER]aij_1.aij' ADD JOURNAL AIJ_2 FILENAME `DISK1:[USER]aij_2.aij' ADD JOURNAL AIJ_3 FILENAME `DISK1:[USER]aij_3.aij' ADD JOURNAL AIJ_4 FILENAME `DISK1:[USER]aij_4.aij' ADD JOURNAL AIJ_5 FILENAME `DISK1:[USER]aij_5.aij'; ALTER DATABASE FILE mf_personnel JOURNAL IS ENABLED (FAST COMMIT IS ENABLED); ALTER DATABASE FILE mf_personnel JOURNAL IS ENABLED (LOG SERVER IS AUTOMATIC); ALTER DATABASE FILE mf_personnel JOURNAL IS ENABLED (NOTIFY IS ENABLED); ALTER DATABASE FILE mf_personnel JOURNAL IS ENABLED (BACKUP SERVER IS AUTOMATIC); ALTER DATABASE FILE mf_personnel OPEN IS MANUAL; EXIT; $! $ RMU/OPEN mf_personnel $ RMU/SERVER BACKUP_JOURNAL/LOG SUSPEND mf_personnel $ RMU/BACKUP/LOG/QUIET_POINT/ONLINE mf_personnel standby_personnel.rbf $ RMU/SHOW AFTER_JOURNAL mf_personnel /OUTPUT=DISK1:[USER]aij_opt.dat $! Edit the aij_opt.dat file to change the location (for example, node, disk, $! and directory) of the backup files for the standby database. $ RMU/RESTORE/NOCDD/LOG/NEW/DIR=DISK1:- /ROOT=DISK1:standby_personnel.rdb /AIJ_OPT=aij_opt.dat - standby_personnel.rbf $! $ RMU/OPEN standby_personnel $! $ DEFINE/SYS/LOG RDM$BIND_AIJ_WORK_FILE DISK1:[USER.HOTSTANDBY] $! $ RMU/REPLICATE AFTER_JOURNAL START standby_personnel - /MASTER_ROOT=ORANOD::DISK1:[USER]mf_personnel - /BUFFERS=1000 - /CHECKPOINT=100 - /GOVERNOR=ENABLED - /ONLINE - /LOG - /WAIT - /OUT=lrs_pid.out $ RMU/REPLICATE AFTER_JOURNAL START mf_personnel - /STANDBY_ROOT=REMNOD::DISK1:[USER]standby_personnel - /SYNCHRONIZATION=COLD - /QUIET - /CHECKPOINT=100 - /CONNECT_TIMEOUT=5 - /LOG - /WAIT - /OUT=lcs_pid.out $! $ RMU/REPLICATE AFTER_JOURNAL STOP mf_personnel $ RMU/REPLICATE AFTER_JOURNAL STOP standby_personnel
Figure 2-1 provides a conceptual look at how the master and standby database are coordinated and synchronized during replication startup operations.
The following sections describe these steps in more detail. Each section includes a portion of the Oracle Rdb on OpenVMS syntax shown in Example 2-2, plus additional samples that show the commands to perform the same operations for Oracle Rdb on Digital UNIX and Oracle CODASYL DBMS.
Sections 2.3.1 through 2.3.8 describe how to set the after-image journal options to successfully set up the master database configuration. The options that you set now for the master database are eventually applied to the standby database when you create it with the Restore command in Step 6.
Reference: The following sections include examples. If you need more information about the SQL, RMU, or DBO syntax used, refer to the Oracle Rdb SQL Reference Manual, the Oracle RMU Reference Manual, or the Oracle CODASYL DBMS Database Administration Reference Manual, as appropriate.
Reserving after-image journals slots is exactly the same for Hot Standby configurations as it is for nonreplicated database environments. However, you should give careful consideration to the number of slots you need, because the same number must be configured for the after-image journals on the master and the standby databases. The number of slots must be identical on both databases, or replication operations fail and return the fatal AIJSIGNATURE error message.
Reserve journals using the same syntax for Hot Standby configurations as for nonreplicated database environments. The following examples show how to reserve after-image journal slots:
$ DBO/MODIFY/RESERVE=AFTER_JOURNAL=5 PARTS
$ SQL ALTER DATABASE FILE mf_personnel JOURNAL IS ENABLED RESERVE 5 JOURNALS
Note: Oracle Corporation recommends that you reserve a minimum of five slots when you use the Hot Standby option. By providing several extra journals, you allow adequate time to preinitialize after-image journals on the standby database. Also, this allows you to add more journals during run time, and allows the database to create "emergency" after-image journals, if necessary.
You must add journals and specify unique names for the after-image journal files. When you add journals, you can either specify a valid device and directory for the after-image journal (.aij) files or define a logical name or configuration parameter. Defining common symbols like logical names and configuration parameters can help you effectively manage the multiple files required by the master and standby directories. Storing shared information in a single, common place can also make failover easier.
Create and add after-image journals using the same syntax for Hot Standby configurations as for nonreplicated database environments. The following examples show the DBO syntax and SQL statements you use to add five after-image journals:
$ DBO/MODIFY/AIJ_OPT=(CREATE,NAME=AIJ_1)/AFTER_JOURNAL=DISK1:[USER]AIJ_1.AIJ PARTS $ DBO/MODIFY/AIJ_OPT=(CREATE,NAME=AIJ_2)/AFTER_JOURNAL=DISK1:[USER]AIJ_2.AIJ PARTS $ DBO/MODIFY/AIJ_OPT=(CREATE,NAME=AIJ_3)/AFTER_JOURNAL=DISK1:[USER]AIJ_3.AIJ PARTS $ DBO/MODIFY/AIJ_OPT=(CREATE,NAME=AIJ_4)/AFTER_JOURNAL=DISK1:[USER]AIJ_4.AIJ PARTS $ DBO/MODIFY/AIJ_OPT=(CREATE,NAME=AIJ_5)/AFTER_JOURNAL=DISK1:[USER]AIJ_5.AIJ PARTS
$ SQL ALTER DATABASE FILE mf_personnel JOURNAL IS ENABLED ADD JOURNAL AIJ_1 FILENAME `DISK1:[USER]aij_1.aij' ADD JOURNAL AIJ_2 FILENAME `DISK1:[USER]aij_2.aij' ADD JOURNAL AIJ_3 FILENAME `DISK1:[USER]aij_3.aij' ADD JOURNAL AIJ_4 FILENAME `DISK1:[USER]aij_4.aij' ADD JOURNAL AIJ_5 FILENAME `DISK1:[USER]aij_5.aij';
Enabling after-image journaling is essential to using the Hot Standby option. Replication operations are designed to use after-image journaling to maintain an up-to-date copy of the master database at another location. The standby database is updated with the changes from the master database using a continuous rollforward operation, applying after-image journal records to the standby database.
Enable after-image journaling using the same syntax for Hot Standby configurations as for nonreplicated database environments. For Oracle CODASYL DBMS, you must explicitly enable journaling with the DBO Modify command. For Oracle Rdb databases, you have already enabled journaling as a part of the SQL statements (in Section 2.3.1) to reserve after-image journal slots and (Section 2.3.2) to add journals.
The following examples show how to enable after-image journaling:
$ DBO/MODIFY/JOURNAL_OPTIONS=ENABLED PARTS
$ SQL ALTER DATABASE FILE mf_personnel JOURNAL IS ENABLED
The fast commit optimization is important for Hot Standby configurations because it provides the ability to redo after-image journal logs to update the standby database. As the master database archives and ships its after-image journal logs to the standby database, the recovery operation uses the logs to roll forward data modifications to the standby database. The log rollforward server (LRS) process applies the updates and checkpoints the online database file information to update the time that the rollforward operation occurred.
Enable the fast commit option using the same syntax for Hot Standby configurations as for nonreplicated database environments. The following examples show how to enable the fast commit optimization:
$ DBO/MODIFY/FAST_COMMIT=ENABLED PARTS
$ SQL ALTER DATABASE FILE mf_personnel JOURNAL IS ENABLED (FAST COMMIT IS ENABLED);
You must make sure that the AIJ log server (ALS) startup mode is automatic so that the database monitor automatically starts the ALS process when you manually open the master and standby databases. The ALS process is active on both the master and standby databases while the standby database is being created and the databases are synchronized.
Enable the ALS process using the same syntax for Hot Standby configurations as for nonreplicated database environments. The following examples show how to enable the ALS process:
$ DBO/MODIFY/SERVER=AFTER_JOURNAL=AUTOMATIC PARTS
$ SQL ALTER DATABASE FILE mf_personnel JOURNAL IS ENABLED (LOG SERVER IS AUTOMATIC);
The Hot Standby software terminates the ALS process on the standby database as the LRS process takes over processing transactions against the standby database. (On OpenVMS systems, the message "AIJ Log Server terminated" displays on the standby operator console to notify you of the changeover.)
When replication operations are active, the ALS process applies data modifications to the after-image journal files for the master database and sends the same modifications to the LRS process on the standby database. However, the ALS process is reactivated if nodes (other than the master database) submit read-only transactions for processing on the standby database.
Oracle Corporation recommends using the after-image journal operator notification facility on OpenVMS systems. Because replication operations are performed using detached server processes, operator notification is the only proactive mechanism available for notification in the event of a server failure or replication termination. Each server process is also capable of maintaining an output file, similar to the monitor log file, which records information about the database replication operations.
Enable system notification using the same syntax for Hot Standby configurations as for nonreplicated database environments. The following examples show how to enable operator notification:
$ DBO/MODIFY/JOURNAL_OPTIONS=(NOTIFY=OPER12) PARTS
$ SQL ALTER DATABASE FILE mf_personnel JOURNAL IS ENABLED (NOTIFY IS ENABLED)
On Digital UNIX systems, use the RMU Show Users and Show Statistics commands to monitor the current database state.
You should set up your Hot Standby system so that the AIJ backup server (ABS) process is enabled automatically. Automatically backing up the contents of after-image journal files is recommended for the Hot Standby option (and for any system that requires high availability).
Enable the ABS using the same syntax for Hot Standby configurations as for nonreplicated database environments. The following examples show how to enable the ABS:
$ DBO/MODIFY/JOURNAL_OPTIONS=SPOOLER PARTS
$ SQL ALTER DATABASE FILE mf_personnel JOURNAL IS ENABLED (BACKUP SERVER IS AUTOMATIC);
You must manually open the master and standby databases prior to starting replication operations. By opening a database manually, you prevent users with insufficient privileges from opening and accessing the database while backup and restore operations proceed.
Set the database open mode to manual using the same syntax for Hot Standby configurations as for nonreplicated database environments. The following examples show how to set the database open mode to manual:
$ DBO/MODIFY/OPEN=MANUAL PARTS
$ SQL ALTER DATABASE FILE mf_personnel OPEN IS MANUAL;
The master database must be open for access prior to starting replication operations. If the database is not already open and active on the node where you want to start replication operations, you must manually open the database using the DBO or RMU Open command.
Open the database using the same commands for Hot Standby configurations as for nonreplicated database environments. The following examples show how to open the master database:
$ DBO/OPEN PARTS
$ rmu -open mf_personnel
$ RMU/OPEN mf_personnel
Even though you just enabled the ABS process (Section 2.3.7) for automatic after-image journal backups, you must temporarily suspend after-image journal backup operations. Suspending the backup operations prevents the ABS process from competing with the log catch-up server (LCS) process for access to the after-image journal.
Note: During replication startup, the LCS process synchronizes the databases by reading the master database after-image journal and forwarding the journal records to the standby database. Because this might take considerable time, an intervening backup operation could stall replication or prevent replication commands from operating properly.
To suspend backup operations, enter the RMU or DBO Server Backup_Journal Suspend command. The following examples show how to suspend the ABS process for Oracle Rdb and Oracle CODASYL DBMS databases.
$ DBO/SERVER BACKUP_JOURNAL/LOG SUSPEND PARTS
$ rmu -server backup_journal -log suspend mf_personnel
$ RMU/SERVER BACKUP_JOURNAL/LOG SUSPEND mf_personnel
Oracle Corporation recommends including the optional Log qualifier to display the status of the suspend operation. The log displays on your default output device.
Also, you can use the RMU or DBO Show Users command to show the current status of after-image journal backup operations. The following example shows this command for an Oracle Rdb database on an OpenVMS system:
$ RMU/SHOW USERS mf_personnel Oracle Rdb V7.0-00 on node ORANOD 11-MAY-1996 08:22:53.98 - monitor log filename is "DISK1:[USER.LOGS]RDMMON701_ORANOD.LOG;28" - 255 monitor buffers available [256 maximum] database "DISK1:[USER.WORK.ALS]MF_PERSONNEL.RDB;1" - First opened 11-MAY-1996 08:22:26.65 * database is opened by an operator * After-image backup operations temporarily suspended from this node - current after-image journal file is DISK1:[USER.WORK.ALS]AIJ2.AIJ;1
Suspending after-image journal backup operations is temporary and information about the suspension is not recorded in the database root file. For example, if the node on which you enter the Server Backup_Journal Suspend command fails, the ABS process automatically resumes after-image journal backup operations.
While the backup operations are suspended, you cannot use the manual after-image journal backup operation (using the Backup After_Journal command).
Backup operations are delayed until:
You must perform a full, online backup operation on the master database. You use the resulting backup file later, in Section 2.8, to create the standby database.
Oracle Corporation recommends that you perform online, quiet-point backup operations by including the Online and Quiet_Point qualifiers on the Backup command. You must perform an online backup operation if you opened the database manually as described in Section 2.4. (If you cannot perform an online backup operation, you must close the master database before you can perform an offline backup operation. Offline backup operations require exclusive access to the database.)
You perform backup operations using the same syntax for Hot Standby configurations as for nonreplicated database environments. The following examples show some sample backup commands:
$ DBO/BACKUP/MULTITHREAD/ONLINE/QUIET PARTS STANDBY_PARTS.DBB
Note: Oracle Corporation recommends you use the /MULTITHREAD qualifier.
$ rmu -backup -quiet -online mf_personnel standby_personnel.rbf
$ RMU/BACKUP/LOG/QUIET/ONLINE mf_personnel standby_personnel.rbf
Before the database backup operation, a DBO or RMU Dump Header command displays the warning message shown in Example 2-3.
$ rmu -dump -header=hot_standby mf_personnel . . . Database Parameters: Root filename is "/hotdisk/usr/mf_personnel.rdb" Hot Standby... - WARNING: Non-journalled database modifications have been made - Informational: Database backup has not been performed since AIJ modifications - Database is not currently being replicated
After the backup operation completes, the database root file header displays information similar to what is shown in Example 2-4.
$ rmu -dump -header=hot_standby mf_personnel . . . Database Parameters: Root filename is "hotdisk//usr/mf_personnel.rdb" Hot Standby... - Database is not currently being replicated
You must save the after-image journal configuration information (in the AIJ options file) for the master database. Later, in Section 2.8, you restore the AIJ options file in conjunction with the master database backup file to create the standby database. Saving the after-image journal options to an output file is essential to ensure that the after-image journal configuration on the standby database is identical to the master database.
To save the after-image journal file, use the DBO or RMU Show After_Journal command with the Output qualifier on the master database. The following examples show some sample commands:
$ DBO/ SHOW AFTER_JOURNAL/OUTPUT=DISK1:[USER]AIJ_OPT.DAT PARTS
$ rmu -show after_journal -output=/hotdisk/usr/aij_opt.dat mf_personnel
$ RMU/SHOW AFTER_JOURNAL/OUTPUT=DISK1:[USER]aij_opt.dat mf_personnel
You create the standby database by restoring a backup copy of the master database and after-image journal options file using the RMU or DBO Restore command.
Your goal during this step is to create a standby database and environment that is identical to the master database. Differences between the databases or after-image journals between the master and standby sites could result in failure when you try to start replication operations.
To create the standby database:
The following examples show sample Restore commands, including the recommended qualifiers:
$ DBO/RESTORE/MULTITHREADED/NOCDD/NEW/DIR=DISK1:[USER] - /ROOT=DISK1:[USER]STANDBY_PARTS.ROO/LOG - /AIJ_OPT=AIJ_OPT.DAT STANDBY_PARTS.DBF
Note: Oracle Corporation recommends that you use the /MULTITHREADED qualifier.
$ rmu -restore -new -dir=hotdisk \ > -root=/hotdisk/usr/standby_personnel.rdb -log \ > -aij_options=aij_opt.dat standby_personnel.rbf
$ RMU/RESTORE/NOCDD/NEW/DIR=DISK1:- /ROOT=DISK1:[USER]standby_personnel.rdb/LOG - /AIJ_OPT=aij_opt.dat standby_personnel.rbf
The standby database must be open for access before you start replication operations. If the database is not already open and active on the node where you intend to start replication operations, you must manually open the database using the DBO or RMU Open command.
Open a database using the same command for Hot Standby configurations as for nonreplicated database environments. The following examples show how to open the standby database:
$ DBO/OPEN STANDBY_PARTS
$ rmu -open standby_personnel
$ RMU/OPEN standby_personnel
Prior to starting replication, you can predefine your Hot Standby database configuration using the Replicate After_Journal Configure command. This optional command allows you to:
When you are ready to start replication operations, you can enter the Replicate After_Journal Start command without specifying any qualifiers. Replication starts running using the previously defined qualifier values.
You can enter the Replicate After_Journal Start command once on the master database to start replication on both the master and standby database nodes. There is no need to explicitly start replication operations on the standby database node.
Reference: See the Replicate After_Journal Configure command reference section in Chapter 6 for information about the privileges required to start replication on the standby database from the master database node.
If you do not use the Replicate After_Journal Configure command to predefine your database configuration, the Hot Standby software starts replication operations using the default values defined in the master and standby database root files.
The following examples show the Replicate After_Journal Configure command:
$ DBO/REPLICATE AFTER_JOURNAL CONFIGURE PARTS - /STANDBY_ROOT=REMNOD::DISK1:[USER]STANDBY_PARTS - /SYNCHRONIZATION=COLD - /QUIET_POINT - /CHECKPOINT=10 - /CONNECT_TIMEOUT=1
$ rmu -replicate after_journal configure mf_personnel \ > -standby_root=/hotdisk/usr/standby_personnel \ > -synchronization=cold \ > -quiet_point \ > -checkpoint=10 \ > -connect_timeout=1
$ RMU/REPLICATE AFTER_JOURNAL CONFIGURE mf_personnel - /STANDBY_ROOT=REMNOD::DISK1:[USER]standby_personnel - /SYNCHRONIZATION=COLD - /QUIET_POINT - /CHECKPOINT=10 - /CONNECT_TIMEOUT=1
The first time you configure a database, you must include the Master_Root or Standby_Root qualifier to ensure that the standby database makes a network connection to the database you specify. The Master_Root or Standby_Root qualifier value is stored in the database root file. Therefore, it is optional on subsequent replication configuration commands.
Reference: See Chapter 6 for a complete description of the Replicate After_Journal Configure command. The default replication startup qualifier values are described in the reference section for the Replicate After_Journal Start command.
Before you start replication operations on the standby database, you should define the location of the after-image rollforward work files using a logical name or configuration parameter from the following table:
Oracle Corporation recommends that you use the BIND_AIJ_WORK_FILE logical names or configuration parameter to define the location. However, if you do not define the location of the temporary work files or if you specify an invalid location, the Hot Standby software locates the files in the home directory of the database monitor, as follows:
Reference: Appendix A discusses how to define the logical names and configuration parameters that are specific to the Hot Standby software.
The database software and the AIJSERVER network object server automatically facilitate communications between the master and the standby database using the default network transport protocol:
For systems on which multiple network transport protocols are installed, you can define a logical name or configuration parameter to specify the network protocol (either DECnet or TCP/IP) that you want to use for communications between the master and standby database. The following table lists the logical names and configuration parameter:
Reference: On OpenVMS systems, you must define the logical names in the LNM$SYSTEM_TABLE logical name table. See Appendix A for more information about defining the logical names and configuration parameter.
The installation procedure creates and sets up the DBMAIJSERVER or RDMAIJSERVER account automatically for DECnet objects. (Section 1.5.2 describes how the network object is installed in detail.) You do not need to perform any additional tasks to install or invoke a DECnet network object.
The installation procedure does not set up the TCP/IP network object because so many different TCP/IP network transport protocols are available. For the TCP/IP network transport protocol, the installation procedure sets up the DBMAIJSERVER or RDMAIJSERVER file, but you must define a UCX port number, as shown in the following Oracle Rdb example:
$ CONFIG UCX AIJSERVER OBJECT $ UCX SET SERVICE RDMAIJSRV /PORT=n /USER_NAME=RDMAIJSERVER /PROCESS_NAME=RDMAIJSERVER /FILE=SYS$SYSTEM:rdmaijserver_ucx.com /LIMIT=nn
In the example, set the variables n and nn as described in the following table:
To set the UCX port number for an Oracle CODASYL DBMS database, substitute "DBMAIJSRV" and "DBMAIJSERVER" for "RDMAIJSRV" and "RDMAIJSERVER" in the example.
After you set the UCX port number, you must enable the network service, as shown in the following example for an Oracle Rdb database:
$ UCX ENABLE SERVICE RDMAIJSRV
|
Note: This step is optional if you preconfigure your Hot Standby databases using the Replicate After_Journal Configure command (see Section 2.10). To configure your standby database attributes, continue reading this section. Otherwise, skip to Section 2.14. |
You start replication on the standby database by entering the Replicate After_Journal Start command. Oracle Corporation recommends that you start replication operations on the standby database before the master database. Although it is not required that you initiate replication operations on the standby database first, it is advantageous to do so for several reasons:
Starting replication is an online operation that can occur while the standby database is open. However, replication operations cannot start on the standby database when these conditions exist:
To disable prestarted transactions, define the appropriate logical name or configuration parameter from the following table:
Reference: Logical names and configuration parameter are described in the Oracle Rdb or Oracle CODASYL DBMS documentation.
Reference: Section 4.3 describes how to provide additional privileges to the DBMAIJSERVER or RDMAIJSERVER account.
When you enter the Replicate After_Journal Start command, you can specify a variety of command qualifiers to customize your standby database for the best performance and availability. However, the only qualifier you must specify (the first time you initiate replication operations) is the Master_Root qualifier; you can take the default values for all other qualifiers.
|
Note: Prior to starting replication, you can predefine the qualifier values using the Replicate After_Journal Configure command. This command allows you to establish default database configuration values without starting replication. Then, when you enter the Replicate After_Journal Start command (and do not include qualifiers), replication starts using the previously defined qualifier values. See Section 2.10 for more information. |
To illustrate the richness of the Replicate After_Journal Start command, the following command examples include several qualifiers.
$ DBO/REPLICATE AFTER_JOURNAL START STANDBY_PARTS - /MASTER_ROOT=ORANOD::DISK1:[USER]PARTS - /BUFFERS=1000 - /CHECKPOINT=100 - /GOVERNOR=ENABLED - /ONLINE - /LOG - /WAIT - /OUT=LRS_PID.OUT
$ rmu -replicate after_journal start standby_personnel \ > -master_root=/ORANOD/hotdisk/usr/mf_personnel \ > -buffers=1000 \ > -checkpoint=100 \ > -governor=enabled \ > -online \ > -wait \ > -out=lrs_pid.out
$ RMU/REPLICATE AFTER_JOURNAL START standby_personnel - /MASTER_ROOT=ORANOD::DISK1:[USER]mf_personnel - /BUFFERS=1000 - /CHECKPOINT=100 - /GOVERNOR=ENABLED - /ONLINE - /LOG - /WAIT - /OUT=lrs_pid.out
You must include the Master_Root qualifier the first time you enter the Replicate After_Journal Start command (unless you have preconfigured the Master_Root qualifier using the Replicate After_Journal Configure command). The Master_Root qualifier is necessary to ensure that the standby database makes a network connection to the master database you specify as the source of replication operations. The Master_Root qualifier is stored in the database root file. Therefore, it is optional on subsequent replication start commands.
Recommendation: By default, the asynchronous prefetch function is enabled on the standby database. For improved performance, Oracle Corporation recommends that you do not disable the detected asynchronous prefetch option.
Example 2-5 shows a portion of the Dump Header command output for the standby database. This command shows the database header after the Replicate After_Journal Start command was entered on the standby database.
$ RMU/DUMP/HEADER=HOT_STANDBY standby_personnel . . . Database Parameters: - Database has been configured as "replication standby" Master database is "ORANOD::DISK1:[USER]MF_PERSONNEL" Remote node name is "REMNOD" Replication last commenced on 15-MAY-1996 07:52:52.98 Database replication is "offline" Server checkpoint interval is 100 messages Server timeout interval is 5 minutes Server buffer count is 1000 Server 2PC transaction resolution is "commit"
You can start replication while the master database is on line, open, and active. Online database access means that other database users can actively attach to the master database before, during, and after replication starts up. There is no need to close the master database or stop user access to the database when you initiate database replication. (Section 2.13 describes restrictions for starting replication on the standby database.)
You can start replication operations by entering the Replicate After_Journal Start command on the master database. At this time, automatic backup operations that you suspended in Section 2.5 are automatically resumed.
|
Note: If you used the Replicate After_Journal Configure command to preconfigure the master and standby database attributes (see Section 2.10), the Replicate After_Journal Start command starts replication operations on both the master and standby databases when you have sufficient privileges defined. Section 4.3 describes how to provide sufficient privileges to the DBMAIJSERVER or RDMAIJSERVER account. |
When you specify the Replicate After_Journal Start command, you can include command qualifiers to customize your standby database for the best performance and availability. To illustrate the richness of the Replicate After_Journal Start command, the following command examples include a number of qualifiers:
$ DBO/REPLICATE AFTER_JOURNAL START PARTS - /STANDBY_ROOT=REMNOD::STANDBY_PARTS - /SYNCHRONIZATION=COLD - /QUIET - /CHECKPOINT=100 - /CONNECT_TIMEOUT=5 - /LOG - /WAIT - /OUT=LCS_PID.OUT
$ rmu -replicate after_journal start mf_personnel \ > -standby_root=/REMNOD/hotdisk/usr/standby_personnel \ > -synchronization=cold \ > -quiet \ > -checkpoint=100 \ > -connect_timeout=5 \ > -log \ > -wait \ > -out=lcs_pid.out
$ RMU/REPLICATE AFTER_JOURNAL START mf_personnel - /STANDBY_ROOT=REMNOD::DISK1:[USER]standby_personnel - /SYNCHRONIZATION=COLD - /QUIET - /CHECKPOINT=100 - /CONNECT_TIMEOUT=5 - /LOG - /WAIT - /OUT=lcs_pid.out
Note: You must include the Standby_Root qualifier the first time you enter the Replicate After_Journal Start command (unless you have preconfigured the Standby_Root qualifier using the Replicate After_Journal Configure command). This qualifier is necessary to ensure that the master database makes a network connection to the standby database you specify as the target of replication operations. The value of the Standby_Root qualifier is stored in the database root file. Therefore, it is optional on subsequent replication start commands.
Example 2-6 shows a portion of the output from a Dump Header command of the master database root file. The Dump Header command shows the database header after the Replicate After_Journal Start command was entered on the master database.
$ RMU/DUMP/HEADER=HOT_STANDBY mf_personnel . . . - Database has been configured as "replication master" Database is currently being replicated Master database is "MF_PERSONNEL.RDB;1" Database is local to this node ("ORANOD") Replication commenced on 15-MAY-1996 09:36:05.16 Database replication is "online" Server checkpoint interval is 100 messages Server timeout interval is 5 minutes Server buffer count is 256 Server 2PC transaction resolution is "commit" Server database access is "read-write"
