Replication Commands

This chapter provides the syntax and semantics for the following Replicate commands and their parameters and qualifiers:

These commands are available using either Oracle RMU (the Rdb database manament utility) or the DBMS Database Operator utility (DBO). The RMU and DBO command syntax described in this chapter follows the conventions provided in the following Oracle documentation:

Privileges

 You must have the following privileges to use the Replicate commands:

Server Names and Acronyms

 The discussions in this chapter sometimes use acronyms to refer to the Hot Standby servers. The following list shows the server names and their acronyms, and the database where each server runs:

Default Command Qualifiers

 The Hot Standby supplies default values for most of the master and standby database attributes and maintains them in the database root file. Optionally, you can change one or more of the database attributes using qualifiers on the Replicate commands. When you specify a database attribute, the Hot Standby software updates the database root file so that the database root file always contains the most up-to-date qualifier values for the database.

You can specify database attributes using qualifiers on either of the following Replicate commands:

Whenever you enter the Replicate After_Journal Start command, the Hot Standby software initiates database replication using:

Therefore, you do not need to respecify the qualifier values except to change a qualifier setting. For example, the following command examples show the Replicate After_Journal Start command the first time you enter it on the master database node:

Oracle CODASYL DBMS 

$ DBO/REPLICATE AFTER_JOURNAL START ORANOD::PARTS - 

     /STANDBY_ROOT=REMNOD::DISK$:[DIRECTORY}STANDBY_PARTS -

     /SYNCHRONIZATION=HOT

Oracle Rdb on Digital UNIX 

$ rmu -replicate after_journal start ORANOD::MF_PERSONNEL \

> -standby_root=/hotdisk/STANDBY_PERSONNEL \

> -synchronization=hot

Oracle Rdb on OpenVMS 

$ RMU/REPLICATE AFTER_JOURNAL START ORANOD::MF_PERSONNEL -

     /STANDBY_ROOT=REMNOD::STAMDBY_PERSONNEL -

     /SYNCHRONIZATION=HOT
The Hot Standby software saves the qualifier settings in the database root file (in this case, the database attributes are saved in the master database root file). The next time you start replication operations, you could enter the command line without the qualifier, as shown in the following Oracle CODASYL DBMS example:

$ DBO/REPLICATE AFTER_JOURNAL START ORANOD::PARTS
The following examples show the header information from Oracle Rdb master and standby database root files.

Header Information From the Master Database Root File 
Hot Standby...

- Database is currently being replicated

    Master database is ``_$111$DUA15:[ORACLEUSER]MF_PERSONNEL.RDB;1''

    Database is local to this node (``ORANOD'')

    Replication commenced on 15-JUN-1996 09:36:05.16

    Database replication is ``offline''

    Server checkpoint interval is 100 messages

    Server timeout interval is 5 minutes

    Server buffer count is 256

    Server 2PC transaction resolution is ``commit''
Header Information From the Standby Database Root File 
Hot Standby...

- Database replication is currently active

    Standby database is ``_$111$DUA15:[ORACLEUSER]MF_PERSONNEL.RDB;1''

    Database is local to this node (``STNDBY'')

    Replication commenced on 15-JUN-1996 09:36:15.75

    Synchronization obtained via no-quiet-point

    Server checkpoint interval is 100 messages

    Server wait interval is 5 minutes

    Replication synchronization is ``cold''

Replicate After_Journal Configure

 Allows you to preconfigure master and standby database attributes and stores them in the database root file. The replication attributes do not take effect until you start replication operations with the Replicate After_Journal Start command.

Format

Oracle CODASYL DBMS: 

DBO /Replicate After_Journal Configure database_rootfile

Rdb7 on OpenVMS: 

RMU /Replicate After_Journal Configure  database_rootfile

Rdb7 on Digital UNIX: 

rmu -replicate after_journal configure  database_rootfile

Description

 You can optionally use the Replicate After_Journal Configure command to configure the Hot Standby database attributes for either the master or standby database. You should use the Replicate After_Journal Configure command if you want to:

The values you specify become the new default qualifier values that are stored in the database root file.

If you preconfigure the master and standby databases, you can start replication for both databases by entering one Replicate After_Journal Start command on either the master or the standby database.

The following lists show the qualifiers you can preset using the Replicate After_Journal Configure command:

Checkpoint
Connect_Timeout
Gap_Timeout
[No]Quiet_Point
Standby_Root
Synchronization

Buffers
Checkpoint
Master_Root
[No]Online
Resolve

The master database attributes are stored in the master database root file, and the standby database attributes are stored in the standby database root file. For example, if you use the Replicate After_Journal Configure command to preconfigure the master and standby database configurations and then invoke the Replicate After_Journal Start command on either a master or standby database node, the Hot Standby software:

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.

Command Parameter

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.

Command Qualifiers

The command qualifiers are the same ones described for the Replicate After_Journal Start command. See Section 5.3 for qualifier information.

Usage Notes

You cannot invoke the Replicate After_Journal Configure command when replication operations are active.

You can override the default values stored in the database root file by specifying qualifiers on the Replicate After_Journal Start command.

You cannot specify the Output qualifier on the Replicate After_Journal Configure command. Therefore, if you need to record LRS information to an output file when you start replication operations from the master database, define the RDM$BIND_LRS_OUTPUT_FILE or DBM$BIND_LRS_OUTPUT_FILE logical name or the RDB_BIND_LRS_OUTPUT_FILE configuration parameter (see Appendix C).

Example

The following examples show how to use the Replicate After_Journal Configure command to start replication on the master and standby database:

Oracle CODASYL DBMS 

$ DBO/REPLICATE AFTER_JOURNAL CONFIGURE ORANOD::PARTS - 

    /STANDBY_ROOT=REMNOD::STANDBY_PARTS -

    /SYNCHRONIZATION=COLD -

    /QUIET_POINT -

    /CHECKPOINT=10 -

    /CONNECT_TIMEOUT=1

Oracle Rdb on Digital UNIX 

$ rmu -replicate after_journal configure ORANOD::MF_PERSONNEL \

> -standby_root=REMNOD::STANDBY_PERSONNEL \

> -synchronization=cold \

> -quiet_point \

> -checkpoint=10 \

> -connect_timeout=1

Oracle Rdb on OpenVMS 

$ RMU/REPLICATE AFTER_JOURNAL CONFIGURE ORANOD::MF_PERSONNEL - 

    /STANDBY_ROOT=REMNOD::STAMDBY_PERSONNEL -

    /SYNCHRONIZATION=COLD -

    /QUIET_POINT -

    /CHECKPOINT=10 -

    /CONNECT_TIMEOUT=1

Replicate After_Journal Reopen_Output

 Closes the current informational file and re-opens it as a new file. You can enter this command on either the master database node (to reopen the output file that records LCS information) or the standby database node (to reopen the output file that records LRS information).

Format

Oracle CODASYL DBMS

 
 DBO /Replicate After_Journal Reopen_Output master_rootfile

Rdb7 on OpenVMS

 
RMU /Replicate After_Journal Reopen_Output  master_rootfile

Rdb7 on Digital UNIX

 
rmu -replicate after_journal reopen_output master_rootfile

Description

 The Replicate After_Journal Reopen_Output command:

You can enter the Replicate After_Journal Reopen_Output command on either the master or standby node as follows:

Note that you must have explicitly enabled writing replication startup information to an output file by using the Output qualifier when you started replication operations. (See the Replicate After_Journal Start command for more information.)

The Replicate After_Journal Reopen_Output command is useful when:

For example, as the output file grows large over time, you might run out of disk space or notice that the database performance is slow. You can use the Replicate After_Journal Reopen_Output command to free up space on the disk. Once the new output file is open, you should relocate the old output file to a new location or delete the file.

If the disk that contains the output file becomes full, the Hot Standby software stops writing information to the file and sends a message to the system operator. Note that replication operations continue, even when write I/O to the output file stops.

You cannot view the file unless you close it first. Because the output file is opened for exclusive access by the server process, this is the only way to view the current output file. By using the Replicate After_Journal Reopen_Output command, you can capture a snapshot of the output file and examine replication operations without interrupting processing.

The Hot Standby software dynamically and transparently transitions from writing to the original output file to the new file. There is no need to stop or interrupt database replication operations during the transition to the new output file.

The new output file is written as follows:

Command Parameter

master-rootfile

 Specifies the name of the master or standby database root file.

Usage Notes

To write replication information to an output file, specify the Log and Output qualifiers on the Replicate After_Journal Start command. If you enter the Replicate After_Journal Reopen_Output command on a node where logging is not enabled, the Hot Standby software ignores the command; it does not return an error message if the Replicate After_Journal Reopen_Output command does not find an output file.

The Replicate After_Journal Reopen_Output command is applicable only to the files that record activities for the LCS process or the LRS process. If you want to reopen or view the output file that records information about the ALS process, use the RMU Server After_Journal Reopen_Output command or the DBO Server After_Journal Reopen_Output command, as appropriate.

Reference: For more information about displaying ALS information, refer to the:

Example

 The following command reopen the output file for the Oracle Rdb personnel database:

Oracle CODASYL DBMS

$ DBO /Replicate After_Journal Reopen_Output PARTS.ROO

Oracle Rdb on Digital UNIX

 
$ rmu -replicate after_journal reopen_output mf_personnel.rdb

Oracle Rdb on OpenVMS

 
$ RMU /Replicate After_Journal Reopen_Output MF_PERSONNEL.RDB

Replicate After_Journal Start

Initiates database replication operations.

Format

Oracle CODASYL DBMS on OpenVMS

 
DBO /Replicate After_Journal Start database_rootfile

Rdb7 on OpenVMS

 
RMU /Replicate After_Journal Start database_rootfile

Rdb7 on Digital UNIX

 
rmu -replicate after_journal start database_rootfile

Qualifiers

 Buffers=rollforward-buffer-count
Checkpoint=checkpoint-interval
Connect_Timeout=minutes
Gap_Timeout=minutes
Governor=[Enabled orDisabled]
[No]Log
Master_Root=master-rootfile
[No]Online
Output=log-filename
[No]Quiet_Point
Resolve=[Commit or Abort or Ignore]
Standby_Root=standby-rootfile
Synchronization=[Commit or Hot or Warm or Cold]
[No]Wait

Description

To start database replication, you can enter the Replicate After_Journal Start command on both the standby node and the master node. Although it does not matter on which node you first initiate replication operations, Oracle recommends that you start replication on the standby node before you start it on the master node. This is because replication activity does not begin until:

Note: If you used the Replicate After_Journal Configure command to preconfigure the master and standby database attributes (see Section 5.1), you can invoke a single Replicate After_Journal Start command to start replication operations on both the master and standby databases.

Starting Replication

You can start database replication while either the master database, the standby database, or both databases are online (open) and accessible for active use. There is no need to close either database in order to initiate database replication. The databases can process transactions during replication start up, as follows:

Applications and users can continue to access data and make modifications to the master database whether or not replication activity has started. Waiting for the replication activity to begin does not inhibit access to, or interrupt modifications on the master database.

Starting replication is an online operation that can occur while the standby database is open. However, database users must not actively attach to the standby database prior to starting database replication if you perform offline backup operations.

In addition, replication operations cannot start when these conditions exist:

To disable prestarted read/write transactions, use the BIND_PRESTART_TXN logical name or configuration parameter.

For Oracle Rdb databases, you can also use the PRESTARTED TRANSACTIONS ARE DISABLED clause on the SQL IMPORT statement.

Reference: Appendix C discusses how to define the logical names and configuration parameters that are specific to the Hot Standby software.

Qualifier Usage

Some of the qualifiers for the Replicate After_Journal Start command are applicable only when you start replication operations on the master database node while others are applicable to the standby database node. The following lists categorize the qualifiers according to usage:

The Hot Standby software does not allow you to use qualifiers that are not valid for the node where you enter the command. If you use an inapplicable qualifier (for example, if you use the Connect_Timeout qualifier when you start replication on the standby node), the Hot Standby software returns an error message.

Note: Whenever you specify a qualifier on the Replicate After_Journal Start command line, you must also include the Master_Root or Standby_Root qualifier, as appropriate, on the command line. For example, to change the value of the Synchronization qualifier on a master database node, you must specify both the Synchronization and Standby_Root qualifiers, as shown in the following example:

$ DBO /Replicate After Start MF_PERSONNEL /Synch=Cold -

_$ /Standby=REMOTE::DISK$:[DIRECTORY]PARTS

Command Parameters

database_rootfile

 Indicates the root file specification for either the master or standby database where you want to start database replication.

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.

The following table describes which database root file to specify depending on where you enter the command. When you enter the Replicate After_Journal Start command:

To ensure that the standby database accesses the correct master database as the source of replication operations, include the Master_Root qualifier on the command line. Similarly, to ensure that the master database accesses the correct standby database as the target of replication operations, include the Standby_Root qualifier on the command line.

Reference: See the Master and Standby qualifiers discussed later in this chapter.

Command Qualifiers

Buffers=rollforward-buffer-count

 Specifies the number of buffers available to roll after-image journals forward to the standby database. This qualifier is:

During replication operation, replication servers on the standby database receive after-image journal records from the master database and roll them forward to the standby database. By default, the standby database has 256 buffers available to perform the rollforward operation.

You can use the optional Buffers qualifier to override the default number of 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:

(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 (multiply 10 by 100) at any one time. To ensure that you have an adequate number of buffers, add another 20 percent (200 buffers) for a total of 1200 buffers.

Note: The LRS server ignores the Buffers qualifier if you defined global buffers on the standby database using either of the following methods:

The LRS server uses the number of buffers specified in the database, or specified when you open the database. The LRS process takes maximum advantage of the standby system by using the largest number of buffers possible to maximize replication performance and throughput.

Note that the replication servers on the standby database do not use buffer values defined by the following:

Checkpoint=checkpoint-interval

 Specifies, in terms of processed messages, how frequently the Hot Standby servers update state information in the database root file. This qualifier is:

By default, the Hot Standby servers automatically perform checkpoint operations on both the master and standby databases after every 100 messages are processed. Checkpointing is essential to database availability because it:

Note: In addition to the Checkpoint qualifier, the replication servers on the master database also checkpoint automatically after the following events:

On the standby database, the LRS process checkpoints after two minutes of inactivity if some data has been processed since the last checkpoint.

These automatic checkpoints advance the oldest active checkpoint indicator for the purpose of making 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 either 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 the state information in the standby database root file after every 300 messages are exchanged between the master and the standby database.

The following describes how the frequency of the checkpoint operation can affect database synchronization. If you specify:

In addition, the value you set for the checkpoint interval:

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 .aij file that is required for process recovery or replication restart.

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 Statistic utility and examining the Checkpoint Information screen.

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. This qualifier is:

When you start replication on the master database (before starting it on the standby database):

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.

Also, because the Connect_Timeout qualifier only waits for the network connection, you might consider using the Wait qualifier in addition to the Connect_Timeout qualifier. The Wait qualifier causes the Replicate After_Journal Start command to wait for the server processes to be activated. See the Wait qualifier later in this chapter for additional information.

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. This qualifier is:

If a gap in the replication data sequence is not resolved within the period of time allowed, the LRS process:

You must restart replication operations manually to resolve the situation.

Governor=Enabled

Governor=Disabled

 Enables or disables the replication governor. This qualifier is:

The purpose of the replication governor is to coordinate database replication operations automatically between the master and the standby databases. With the replication governor enabled, you can effectively ensure that:

The replication governor allows the ALS process on the master database and the LRS process on the standby database to automatically choose the synchronization mode that provides the best performance and ensures database replication synchronization.

To use the replication governor most effectively, ensure the Governor qualifier is Enabled and include the Synchronization=Cold qualifier when you start replication operations on the standby database. (Also, see the Synchronization qualifier discussed later in this section.)

Oracle Corporation recommends that you set the Synchronization qualifier to Cold mode. This setting is most effective because of the way the LRS process monitors its replication workload from the master database, as described in the following list:

Because the synchronization mode changes dynamically, the LRS process transmits the current synchronization mode to the ALS process (on the master database) at every checkpoint interval (see the Checkpoint qualifier earlier in this chapter). For example, if the replication governor upgrades the synchronization mode from Cold to Warm, the LRS process transmits the information to the ALS process. Then, the ALS process uses the stronger mode on all subsequent messages to the standby database. (Note that the LRS process maintains a different synchronization mode for each master database node.)

Use the RMU or DBO Show Statistic utility on the master database to monitor the dynamically changing synchronization mode required by the actual work load, and compare that to the mode you specified with the Synchronization qualifier.

Recommendation: Oracle recommends that you do not use the Governor=Disabled setting until the replication performance is fairly well understood and constant. Severe performance deviations on the master database could result in stalling or stopping the database replication operations.

Reference: See Section 3.2 for more information about Hot Standby synchronization algorithms.

Log

NoLog

 Indicates whether or not to log the status of, and information about, replication startup operations. This qualifer is:

If you specify the Log qualifier, output showing the status of the replication startup is logged to:

Oracle Corporation recommends that you specify the Log qualifier.

Whereas the Log qualifier records information about the Replication After_Journal Start command, you also can include the Output qualifier to record information about replication activities performed by the LCS or LRS processes. Include the Output qualifier on the command line if you want to write operational information about the LCS or LRS server to an output file.

Reference: See the Output qualifier discussed later in this chapter.

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. This qualifier is:

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 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 (see Examples 5-1and 5-2.

Whenever you specify the Master_Root qualifier, you must do the following to ensure the command executes successfully:

Note: 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 describes how the Hot Standby software chooses the method of communication:

The Hot Standby software compares and verifies the master database (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). The purpose of this verification is to ensure that both databases are identical transactionally.

Online

Noonline

 Allows or disallows users and applications to be online (actively attached) to the standby database. This qualifier is:

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.

Note: If row caching is enabled on the standby database, the Hot Standby software assumes the Online setting. Because row caching requires the row cache server to be an online server, you cannot override the online setting. Specifying the Online qualifier on the Replicate After_Journal Start command line has no effect.

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), the Oracle Corporation recommends that you choose the Nonline (default) setting.

Note: The server processes on the standby database cannot perform replication operations if any read/write transactions, including prestarted read/write transactions, are in progress. To disable the ability to prestart transactions, use the following:

The Online and Noonline qualifiers do not affect access to the master database.

Output=log-filename.out

Identifies the name of the file where the Hot Standby software creates an operational log. This qualifier is:

Oracle recommends that you use the Output qualifier. If you enable replication operations for multiple databases, there will be multiple operational output files.

The purpose of the operational log is to record the transmittal and receipt of network messages, and to provide administrative and diagnostic information.

Note the following when you specify the Output qualifier:

Note: All bugcheck dumps are written to a corresponding bugcheck-dump file. Bugcheck dumps are not written to the Output operational log.

Alternatively, you can use a logical name or configuration parameter to specify an output log file.

See Appendix B for sample output of the standby database server (LRS) information.

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. This qualifier is:

Oracle Corporation recommends using the Quiet_Point qualifier because it makes it easier to restart replication operations.

Resolve=keyword

Specifies whether unresolved distributed transactions should be aborted, committed, or ignored. This qualifier is:

The following list describes the keywords you can set with this qualifier:

Note: Use the Ignore keyword only when the standby database is local to
the master database node. :

The Hot Standby software does not record the resolution of the prepared transaction in the standby database after-image journal. This is because there may not be enough available free space in the journal to write the commit or rollback records

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. This qualifier is:

You must include the Standby_Root qualifier the first time you enter the Replicate After_Journal Start command. This ensures that the master database communicates with the standby database you specify as the recipient of replication operation. 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 (see Examples 5-1and 5-2.

Whenever you specify the Standby_Root qualifier, you must do the following to ensure the command executes successfully:

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.

Prior to starting replication operations on the master database, the standby database must be opened (manually) for access.

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 describes how the Hot Standby software chooses the method of communication:

The Hot Standby software compares and verifies the master database (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.

If replication operations are not started on the standby database when you invoke the Replicate After_Journal Start command on the master database, the Hot Standby software attempts to start replication on the standby database using the default replication attributes configured in the database root file before starting replication on the master database.

Synchronization=keyword

Specifies the degree to which you want to synchronize committed transactions on the standby database with committed transactions on the master database. This qualifier is:

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 journalling depending on the mode you have set with the Synchronization qualifier. Table 5-4 describes the keywords you use to set the synchronization mode.

Note: For high-performance applications, Oracle recommends that you do not specify both the Synchronization=Cold and the Governor=Disabled qualifiers when you start replication on the standby system. This is because the master database can possibly outperform the standby database during updates. The replication governor should be enabled to prevent the master and standby databases from getting too far out of synch.

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 best performance for the master database, but the lowest level of master and standby database synchronization. However, in some business environments, this tradeoff might be acceptable. In the event of failover, it may be preferable to risk losing recent transactions to gain faster master database performance. Business models are such that the value of individual after-image journal records (transactions) are minimal, but the system throughput has greater financial importance and impact.

Wait

NoWait

 Indicates whether or not the Replicate command should wait for activation of the replication server processes before returning control to the user. This qualifier is:

The Wait qualifier has the following effects:

The following describes the [No]Wait qualifier:

You can use the Connect_Timeout qualifier in conjunction with the Wait qualifier to limit the amount of time replication waits for the server process to become active.

Examples

The following Replicate command initiates database replication on an Oracle Rdb for OpenVMS standby database:

$ RMU/REPLICATE AFTER START MF_PERSONNEL -

$ /MASTER=REMOTE::DISK$:[DIRECTORY]MF_PERSONNEL
The following Replicate command initiates database replication on an Oracle CODASYL DBMS master database:

$ DBO/REPLICATE AFTER START MF_PERSONNEL -

_$ /STANDBY=REMOTE::DISK$:[DIRECTORY]PARTS
The following Replicate command initiates database replication on an Oracle Rdb (Digital UNIX) database. The default qualifier values are read from the database root file header information.

$ rmu -replicate after start mf_personnel

Replicate After_Journal Stop

 Terminates database replication operations.

Format

Oracle CODASYL DBMS on OpenVMS

 
DBO /Replicate After_Journal Stop database_rootfile

Rdb7 on OpenVMS

 
RMU /Replicate After_Journal Stop database_rootfile

Rdb7 on Digital UNIX

 
rmu -replicate after_journal stop database_rootfile

Qualifiers

 [No]Abort
[No]Log
[No]Wait

Description

You can enter the command on either the master node or the standby node. Replication operations are stopped as described in the following:

You can stop database replication while either the master database, the standby database, or both databases are online (open) and accessible for active use. There is no need to close either database in order to stop database replication.

If the database is not manually opened on the node where you entered the RMU Replicate After_Journal Start command, you must enter the Replicate After_Journal Stop command on the node where the corresponding replication server is running or first open the database manually.

When replication operations stop, the Hot-Standby software automatically restarts the AIJ log server (ALS) processes on the standby node.

Command Parameter

database_rootfile

 Specifies the database root file for which you want to stop replication operations..

Command Qualifiers

Abort

Noabort

 Indicates whether pending after-image journal information is rolled forward on the standby database before database replication operations are shut down. The following list describes the qualifiers:

Log

Nolog

 Enables or disables logging the results of the Replicate After_Journal Stop operation. This qualifier is:

If you specify the Log qualifier, the log file output is written to:

Wait

NoWait

 Indicates whether or not the Replicate command should wait for activation of the replication server processes before returning control to the user. This qualifier is:

The Wait qualifier has the following effects:

The following list describes the [No]Wait qualifier:

Last Modified: 07:39am EDT, June 11, 1996