Allows you to preconfigure many of the master and standby database attributes (using qualifiers available with the Replicate After_Journal Start command) without starting replication operations. You enter the Replicate After_Journal Configure command: o On the master database to prespecify the Replicate After_ Journal Start command qualifiers that are valid for the master database and store the qualifier settings in the master database root file o On the standby database to prespecify the Replicate After_ Journal Start command qualifiers that are valid for the standby database and store the qualifier settings in the standby database root file Because the database attributes are stored in the respective database root files, the settings do not take effect until you start replication operations with the Replicate After_Journal Start command.
1 – Description
The Replicate After_Journal Configure command is an optional command you can use to preconfigure the master and standby databases, one database at a time. NOTE You cannot preconfigure both the master and standby database attributes in a single Replicate After_Journal Configure command. Moreover, you cannot enter the Replicate After_ Journal Configure command on the standby database to preconfigure master database attributes, or preconfigure standby database attributes from the master database. You can specify one or more of the following qualifiers when you enter the Replicate After_Journal Configure command on the master database: Master Database Qualifiers Alt_Remote_Node (1) Checkpoint Connect_Timeout [No]Log [No]Quiet_Point Reset Standby_Root (2) Synchronization Transport Footnote (1): You must also specify the Standby_Root qualifier. Footnote (2): You must specify the Standby_Root qualifier the first time you configure the master database. The master database attributes that you specify are stored in the master database root file. (You cannot specify the Wait, NoWait, and Output qualifiers on the Replicate After_Journal Configure command. You can specify these qualifiers when you invoke the Replicate After_Journal Start command.) You can specify one or more of the following qualifiers when you enter the Replicate After_Journal Configure command on the standby database: Standby Database Qualifiers Buffers Checkpoint Gap_Timeout Governor [No]Log Master_Root (1) [No]Online Reset Footnote (1): You must specify the Master_Root qualifier the first time you configure the standby database. The standby database attributes that you specify are stored in the standby database root file. (You cannot specify the Wait, NoWait, and Output qualifiers on the Replicate After_Journal Configure command. You can specify these qualifiers when you invoke the Replicate After_Journal Start command.) You should use the Replicate After_Journal Configure command if you want to: o Preset qualifier values that you typically specify on the Replicate After_Journal Start command, but without starting replication operations. The values you specify become the new default qualifier values that are stored in the database root file. o Be able to quickly start replication operations by invoking a single Replicate After_Journal Start command on the master database. If you use the Replicate After_Journal Configure command to preconfigure the master and standby databases, you can start replication for both databases by entering one Replicate After_Journal Start command on the master database. For example, if you have preconfigured both the master and standby databases and then invoke the Replicate After_Journal Start command on the master database node, the Hot Standby software: 1. Starts replication operations on the master database using default qualifier values from the master database root file 2. Creates the network connection to the standby database 3. Attaches the master and standby databases to the network 4. Starts replication operations on the standby database using default qualifier values in the standby database root file 5. Synchronizes committed transactions on the master and standby databases NOTE If you have not preconfigured database attributes using the Replicate After_Journal Configure command, the Hot Standby software uses either the system-supplied defaults or the values that you specified on a previous Replicate After_Journal Start command.
2 – Format
(B)0[m [4mCommand[m [4mQualifiers[m x [4mDefaults[m x [4mUsage[m x x /Alt_Remote_Node=nodename x None x M /Buffers=rollforward-buffer-count x /Buffers=256 x S /Checkpoint=checkpoint-interval x /Checkpoint=100 x B /Connect_Timeout=minutes x /Connect_Timeout=5 x M /Gap_Timeout=minutes x /Gap_Timeout=5 x S /Governor=[Enabled|Disabled] x /Governor=Enabled x S /[No]Log x /Nolog x B /Master_Root=master-root-file-spec x None x S /[No]Online x /Noonline x S /[No]Quiet_Point x /Noquiet_Point x M /Reset x None x B /Standby_Root=standby-root-file-spec x None x M /Synchronization=[Commit|Hot|Warm|Cold]x /Synchronization=Coldx M /Transport={DECnet|TCP/IP} x None x M B=Both;M=Master;S=Standby
3 – Parameters
3.1 – database-rootfile
Specifies the name of the target database root file. For example, if you want to preconfigure the master database attributes, specify the master database root file. Similarly, you can specify the standby database root file to preconfigure the standby database. NOTE Do not include a node name when you specify the database- rootfile parameter. This parameter must specify a locally accessible database root file; the parameter cannot include a remote file specification.
4 – Command Qualifiers
4.1 – Alt Remote Node
Identifies an available secondary link to the standby database. Applicable to: Master database Required or Optional: Optional Default Value: None The Alt_Remote_Node qualifier is used to provide the master database with uninterrupted hot standby replication in case of network failure where multiple network links are available. It can only be used in conjunction with the Standby_Root qualifier, which specifies the standby database node name. The Alt_Remote_Node qualifier identifies the alternate remote node name of the standby database. Following network failure, the master database automatically attempts to reconnect to the standby database using the alternate remote node name information. If the Alt_Remote_Node qualifier is not specified, the master database does not automatically attempt to reconnect to the standby database using the orginal remote node name specified using the Standby_Root qualifier. The alternate node name can be the same as the node name specified with the Standby_Root qualifier. The node name specified by the Alt_Remote_Node qualifier must identify the same standby database on the same remote node as originally specified using the Standby_Root qualifier. The maximum length of the alternate remote node name is 31 characters. At run-time, the RDM$BIND_HOT_NETWORK_ALT_NODE logical name can be defined in the LNM$SYSTEM_TABLE table to override any alternate remote node name information specified at hot standby startup. The logical must be specified on all nodes where the master database is open.
4.2 – Buffers
Buffers=rollforward-buffer-count Specifies the number of database buffers available to roll after- image journals forward to the standby database. Applicable to: Standby database Required or Optional Optional: Local Global Buffers Buffers Default Value: 4096 4096 or Global Buffer USER LIMIT, whichever is smaller Minimum Value: 2 2 Maximum Value: 1,048,576 1,048,576 or Gloal Buffer USER LIMIT, whichever is smaller During replication operations, the LRS process on the standby node receives after-image journal records from the master database and rolls them forward to the standby database. You can use the optional Buffers qualifier to override the default number of database buffers. For optimal performance, you should allocate a sufficient number of buffers so that the server process can roll the after-image journal records forward with a minimum number of I/O operations. To estimate an appropriate number of buffers, use the following equation as a starting point: (Number of Modified Buffers per Transaction * Number of Users) + 20% For example, if the average number of modified buffers per transaction is 10 and there are 100 users on the database, then the server process needs 1000 buffers at one time. To ensure that you have an adequate number of buffers, add another 20 percent (200 buffers) for a total of 1200 buffers. The number of buffers can impact the time it takes for the LRS process to checkpoint. When a checkpoint occurs, the LRS must write all modified buffers to disk. For example, if the LRS is using 2000 buffers, and it takes one second for 2000 disk writes to complete, the LRS will be stalled for one second while those writes are being done. This could cause the Hot Standby governor to increase the synchronization mode if there is a lot of update activity occurring while the LRS is checkpointing. For some applications this could impose a practical limitation in the number of buffers allocated to the LRS. NOTE The LRS process on the standby database does not use buffer values defined by the following: o DBM$BIND_BUFFERS logical name o RDB_BIND_BUFFERS configuration parameter o RDM$BIND_BUFFERS logical name When replication operations are active, you can use the RMU or DBO Show Users command to see the current number of database buffers allocated. If replication operations are not active or if you want to see the buffer value that was set on a previous Replicate After_Journal Start command (stored in the database root file), you can also use the Header and Dump_Select_Type=Hot_ Standby qualifiers on the RMU or DBO Dump command.
4.3 – Checkpoint
Checkpoint=checkpoint-interval Specifies, in terms of processed messages, how frequently the Hot Standby servers update information in the database root file. This qualifier can be set to different values on the master and standby databases. Applicable to: Master and standby database Required or Optional: Optional Default Value: 100 messages Minimum Value: 1 message Maximum Value: 1024 messages By default, the Hot Standby servers automatically perform checkpoint operations on both the master and standby databases after every 100 messages are processed. Checkpoints are essential to database availability because they: o Enable the Hot Standby software to restart database replication operations more quickly in the event of a failure because frequent checkpoints limit the number of transactions that must be redone if a process or system fails. o Cause all modified database cache buffers on the standby database to be flushed to the disk, making the buffers available for access by other users (when online database access is enabled). o Improve the redo performance of the database recovery (DBR) process. o Allow after-image backup operations to back up older after- image journals on the master database. NOTE In addition to performing checkpoint operations specified by the Checkpoint qualifier, the replication servers on the master database also checkpoint automatically after the following events: o After two minutes of inactivity o After a switchover to a new after-image journal (when you are using circular after-image journals) o After an AIJ backup operation (when you are using extensible after-image journals) On the standby database, the LRS process checkpoints after two minutes of inactivity if data has been processed since the last checkpoint. These automatic checkpoints advance the oldest active checkpoint indicator to make older after-image journals available for backup operations. You cannot change or override these checkpoint intervals. The default checkpoint interval usually is sufficient to effectively maintain synchronization between the master and standby database root files. However, you can override the default checkpoint interval by specifying the Checkpoint qualifier when you start replication on the master database, the standby database, or both. For example, if you specify the qualifier Checkpoint=300 on the standby database, the LRS server process updates information in the standby database root file after every 300 messages are exchanged between the master and the standby database. The following table describes how the frequency of the checkpoint operation can affect database synchronization. Table 24 Setting the Frequency of Checkpoint Intervals If you specify . . . Then . . . A small checkpoint The Hot Standby software synchronizes the interval database root files more often, but uses less time to restart replication because fewer transactions need to be redone. A large checkpoint The Hot Standby software synchronizes the interval database root files less frequently, but requires more time to restart replication because more transactions must be redone. In addition, the value you set for the checkpoint interval: o Controls replication restart in the event of a failure on the master database. A side effect of this is that the ABS process cannot back up after-image journals that are needed to restart replication operations. o Affects how the after-image journals on the master database become available for backup. Specifying a large value for the checkpoint interval can cause after-image journal backup operations to stall until the appropriate after-image journal file becomes available for a backup operation. This is because the after-image journal backup operation cannot back up any after-image journal file that is required for process recovery or replication restart. o Affects the reinitialization of after-image journals on the standby database. o Affects the manner in which the LRS process on the standby database: - Releases page locks - Responds to page lock conflict messages from another attached database process Oracle Corporation recommends that you set a reasonably small checkpoint interval for the standby database. Specifying a checkpoint interval that is too large can prevent the LRS process from responding to requests for pages, and it is possible for other processes to become stalled. For Oracle Rdb databases, you can monitor the effectiveness of the current setting of the Checkpoint qualifier by using the RMU Show Statistics command and examining the Checkpoint Information display.
4.4 – Connect Timeout
Connect_Timeout=minutes Specifies the maximum number of minutes that the LCS process on the master database waits for a network connection to the LRS process on the standby database. Applicable to: Master database Required or Optional: Optional Default Value: 5 minutes Minimum Value: 1 minute Maximum Value: 4320 minutes (3 days) When you start replication on the master database (before starting it on the standby database): 1. The Hot Standby software invokes the log catch-up server (LCS) process on the master database. 2. The LCS process invokes its corresponding network AIJSERVER process on the standby node. 3. The AIJSERVER process attempts to create a network connection to the LRS process on the standby node. By default, the LCS process allows 5 minutes for the AIJSERVER to connect to the LRS process. You can override the default by specifying the Connect_Timeout qualifier when you start replication on the master database. (Note that if you specify the Connect_Timeout qualifier, you must specify a time value (in minutes).) The Connect_Timeout qualifier is useful when you start replication operations on the master database before you start replication on the standby database. This is because the Connect_Timeout qualifier allows sufficient time for the network connection to be made before the LCS process begins sending after-image journal records across the network. NOTE While the LCS process on the master database waits for the replication activity to begin on the standby database, users and applications can continue to access and modify data in the master database.
4.5 – Gap Timeout
Gap_Timeout=minutes Specifies the maximum number of minutes that the standby database (LRS process) should wait for a gap in the replication data sequence to be resolved. Applicable to: Standby database Required or Optional: Optional Default Value: 5 minutes Minimum Value: 1 minute Maximum Value: 4320 minutes (3 days)
4.6 – Governor
Governor=Enabled Governor=Disabled Enables or disables the replication governor. Applicable to: Standby database Required or Optional: Optional Default Value: Governor=Enabled The purpose of the replication governor is to coordinate database replication operations automatically between the master and the standby databases. For more information see the Governor qualifier discussion under the Replicate_After_Journal_Commands Start Help topic.
4.7 – Log
Log Nolog Indicates whether or not to log the status of, and information about, activities when you start replication operations. Applicable to: Master and standby database Required or Optional: Optional Default Value: Nolog If you specify the Log qualifier, output showing the status of the replication startup is logged to SYS$OUTPUT on OpenVMS systems. Oracle Corporation recommends that you specify the Log qualifier.
4.8 – Master Root
Master_Root=master-rootfile Identifies the name of the master database root file from which the replication servers on the standby database receive replication data. Applicable to: Standby database Required or Required the first time you enter the Optional: Replicate After_Journal Start command and any time you specify other Replication Startup qualifiers. Optional on all subsequent invocations. Default Value: None. 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 Replication After_Journal Configure command). This ensures that the standby database uses the master database you specify as the source of the replication operations. If you omit the Master_Root qualifier on subsequent Replicate After_Journal Start commands, the Hot Standby software retrieves the master database name from the header information in the database root file. Whenever you specify the Master_Root qualifier, you must do the following to ensure the command executes successfully: o Specify the name of the master database root file. Do not specify the name of the standby database on the Master_ Root qualifier. Any attempt to use a restored database as a master database causes replication startup operations to fail. o Include a node name and directory path for remote network communications. You can define a logical name to identify the master node. o Be able to access the master database. When the master database node is configured in a VMScluster system, the node name you specify with the Master_Root qualifier can be any participating node from which the master database can be accessed. Cluster aliases are acceptable when you use the Master_Root qualifier. The master and standby databases communicate using network communications (for remote database access) or interprocess communications (for local database access) according to how you specify the master database name. The following table describes how the Hot Standby software chooses the method of communication: If . . . Then . . . You include a node The Hot Standby software uses remote name when you specify network communications to receive the the master database after-image journal log changes, unless root file the specified node is the current node You do not include The Hot Standby software uses local a node name when you interprocess communications to receive specify the master the after-image journal log changes database root file The Hot Standby software compares and verifies the master database (that you specify with the Master_Root qualifier) against the standby database (that you specify with the Standby_ Root qualifier when you start replication operations on the master database). This verification ensures that both databases are identical transactionally.
4.9 – Online
Online Noonline Allows or disallows users and applications to be on line (actively attached) to the standby database. Applicable to: Standby database Required or Optional: Optional Default Value: Noonline Online database access means that database users and applications can be actively attached (and perform read-only transactions) to the standby database before, during, and after replication operations. The default setting (Noonline) disallows applications and users from attaching to the standby database during replication operations. However, if the standby database is open on another node (thus, an ALS process is active on that node), the LRS process cannot start replication on the standby database and the error message STBYDBINUSE is returned. NOTE If record caching is enabled on the standby database, the Hot Standby software assumes the Online setting. Specifying the Noonline qualifier on the Replicate After_Journal Start command has no effect. Because record caching requires the record cache server to be an online server, you cannot override the Online setting. Because the Replicate After_Journal Start command fails if you enter it on a standby node where read/write transactions are in progress (including prestarted read/write transactions), Oracle Corporation recommends that you choose the Noonline (default) setting. The Online and Noonline qualifiers do not affect access to the master database.
4.10 – Quiet Point
Quiet_Point Noquiet_Point Determines whether or not the log catch-up server (LCS) process acquires a transactional quiet point during the database synchronization phase of the replication restart procedure. Applicable to: Master database Required or Optional: Optional Default Value: Noquiet_Point Oracle Corporation recommends using the Quiet_Point qualifier because it makes it easier to restart replication operations.
4.11 – Reset
Resets previously configured information. Applicable to: Master and standby database Required or Optional: Optional
4.12 – Standby Root
Standby_Root=standby-rootfile Identifies the name of the standby database root file to which the replication servers on the master database send replication data. Applicable to: Master database Required or Required the first time you enter the Optional: Replicate After_Journal Start command and any time you specify other Replication Startup qualifiers. Optional on all other invocations. Default Value: None 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 Replication After_Journal Configure command). This ensures that the master database communicates with the standby database you specify as the recipient of replication operations. If you omit the Standby_Root qualifier on subsequent Replicate After_Journal Start commands, the Hot Standby software retrieves the standby database name from the header information in the database root file. Whenever you specify the Standby_Root qualifier, you must do the following to ensure the command executes successfully: o Specify the name of the standby database root file. o Include a node name and directory path for remote network communications. (You can define a logical name to identify the master node.) NOTE When the standby database is configured in a VMScluster system, the node name you specify with the Standby_Root qualifier cannot be a cluster alias. o Be able to access the standby database. o Ensure that the standby database is opened for access prior to starting replication operations on the master database. You must open the standby database manually unless you preconfigured the standby database. If you preconfigured the database, you can start replication on both the master and standby databases by entering a single Replicate After_Journal Start command on the master database. The master database automatically opens the standby database, if necessary. The master and standby databases communicate using network communications (for remote database access) or interprocess communications (for local database access) according to how you specify the database name. The following table describes how the Hot Standby software chooses the method of communication: If . . . Then . . . You specify a node The Hot Standby software uses remote name (for access to a network communications to ship the after- standby database on a image journal log changes, unless the remote node) specified node is the current node You do not specify a The Hot Standby software uses the node name following communications to ship the after-image journal log changes: o Local interprocess communications on the local node o Remote network communications on all other nodes and across the cluster The Hot Standby software compares and verifies the master database (that you specify with the Master_Root qualifier) against the standby database (that you specify with the Standby_ Root qualifier). The purpose of this verification is to ensure that both databases are identical transactionally.
4.13 – Synchronization
Synchronization=keyword Specifies the degree to which you want to synchronize committed transactions on the standby database with committed transactions on the master database. Applicable to: Master database Required or Optional: Optional Default Value: Synchronization=Cold When you enable replication operations, server processes on the master database write transactions to the after-image journal for the master database and send them across the network to the after-image journal for the standby database. The standby database acknowledges the receipt of the transactional message and handles after-image journaling depending on the mode you have set with the Synchronization qualifier. The following table describes the keywords you use to set the synchronization mode. Table 25 Keywords for the Synchronization Qualifier Performance Impact Equivalence on of Committed Master Standby Database Keyword Transactions Database Recoverability Commit When the standby Highest The standby database is database transactionally identical receives the and recoverable with respect AIJ information to the master database. from the master database, the servers on the standby database: 1. Write it to the after- image journal on the standby system 2. Apply the AIJ to the standby database 3. Send a message back to the master database acknowledging the successful commit of the transaction Hot When the standby High The standby database is database extremely close to being receives the transactionally identical to AIJ information the master database. from the master database, the After-image journal records servers on the in transit are received standby database: and committed. Some restart processing may be required 1. Write it to to synchronize the database. the AIJ on the standby system 2. Send a message back to the master database before applying the transaction to the standby database Warm When the standby Medium The standby database is database transactionally close to receives the the master database, but the AIJ information databases are not identical. from the master database, the There may be transactions servers on the rolled back on the standby standby database: database that have been committed on the master o Send a message database. back to the master database before applying the transaction to either the AIJ or the standby database o Might not commit after- image journal records to the database Cold When the standby Low The standby database is (de- database not immediately recoverable fault) receives the transactionally with respect AIJ information to the master database. from the master database: After-image journal records in transit could be lost. o The servers never return a message acknowledging the receipt of the AIJ information o In failover situations, it is possible that transactions rolled back on the standby database were committed on the master database For each level of database synchronization, you make a trade-off between how closely the standby and master databases match each other in regard to committed transactions against performance. For example, the Synchronization=Cold level provides the fastest performance for the master database, but the lowest level of master and standby database synchronization. However, in some business environments, this trade-off might be acceptable. In such an environment, the speed of master database performance outweighs the risk of losing recent transactions in the event of failover; system throughput has greater financial importance and impact than the value of individual aij records (transactions).
4.14 – Transport
Transport=DECnet Transport=TCP/IP Allows you to specify the network transport. The specified transport, DECnet or TCP/IP, is saved in the database. Applicable to: Master database Required or Optional: Optional The following example shows the use of this feature: $ RMU/REPLICATE AFTER CONFIGUIRE /TRANSPORT=TCPIP - _$ /STANDBY=REMNOD::DEV:[DIR]STANDBY_DB M_TESTDB
5 – Usage Notes
o The first time you configure the standby database, you must include the Master_Root qualifier, and you must include the Standby_Root qualifier the first time you configure the master database. You must preconfigure the Master_Root or Standby_Root qualifiers because these qualifiers identify the "alternate" database for the database being configured. These qualifiers also identify whether a master or standby database is being configured (if the Replicate After_Journal Configure command includes the Master_Root qualifier, a standby database is being configured). The Master_Root and Standby_Root qualifiers are optional on subsequent replication configuration commands because the value is stored in the database root file. o You can include a node name with the Master_Root or Standby_ Root qualifiers. o You cannot invoke the Replicate After_Journal Configure command when replication operations are active. o The RMU Backup command with the Continuous qualifier is not supported when replication operations are active. o You can override values you define with the Replicate After_ Journal Configure command (and other the default values stored in the database root file) by specifying qualifiers on the Replicate After_Journal Start command. o You cannot specify the Output qualifier on the Replicate After_Journal Configure command. Therefore, if you need to record Hot Standby server information to an output file when you start replication operations from the master database, specify an output file by: - Including the Output qualifier on the Replicate After_ Journal Start command - Defining the BIND_ALS_OUTPUT_FILE, BIND_HOT_OUTPUT_FILE, BIND_LCS_OUTPUT_FILE, or BIND_LRS_OUTPUT_FILE logical name NOTE If you plan to start replication operations remotely (for example, to start replication on the standby database from the master database node), you must have GROUP, WORLD, and SYSPRV privileges on OpenVMS systems.
6 – Examples
Example 1 The following example shows how to use the Replicate After_ Journal Configure command to configure replication attributes for the master database: $ RMU/REPLICATE AFTER_JOURNAL CONFIGURE mf_personnel - /STANDBY_ROOT=REMNOD:::DISK1:[USER]standby_personnel - /SYNCHRONIZATION=COLD - /QUIET_POINT - /CHECKPOINT=10 - /CONNECT_TIMEOUT=1