Initiates database replication operations.
1 – Description
To start database replication, you can enter the Replicate After_
Journal Start command on both the standby node and the master
node. Although you can initiate replication operations on either
node, Oracle Corporation 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:
o The standby database creates the network connection
o The master database attaches to the network connection
o The master and standby databases are synchronized with regard
to committed transactions
NOTE
If you used the Replicate After_Journal Configure command
to preconfigure the master and standby database attributes
(see the Replicate_After_Journal_Commands Configure Help
topic), you can invoke a single Replicate After_Journal
Start command to start replication operations on both the
master and standby databases.
2 – Format
(B)0[mRMU/Replicate After_Journal Start database-rootfile
[4mCommand[m [4mQualifiers[m x [4mDefaults[m x[4mUsage[m
x x
/Alt_Remote_Node=nodename x None x M
/Checkpoint=checkpoint-interval x /Checkpoint=100 x B
/[No]Log x /Nolog x B
/Output=[log-filename|log-filename_PID]x None x B
/[No]Wait x /Wait x B
/Connect_Timeout=minutes x /Connect_Timeout=5 x M
/[No]Quiet_Point x /Noquiet_Point x M
/Standby_Root=standby-root-file-spec x None x M
/Synchronization=[Commit|Hot|Warm|Cold]x /Synchronization=Col x M
/Buffers=rollforward-buffer-count x /Buffers=256 x S
/Gap_Timeout=minutes x /Gap_Timeout=5 x S
/Governor=[Enabled|Disabled] x /Governor=Enabled x S
/Master_Root=master-root-file-spec x None x S
/[No]Online x /Noonline x S
/Transport={DECnet|TCP/IP} x None x M
B=Both; M=Master; S=Standby
3 – Starting Replication
You can start database replication while the master database,
the standby database, or both databases are on line (open) and
accessible for active use. There is no need to close either
database to initiate database replication.
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.
Replication operations cannot start when these conditions exist:
o Any read/write transactions, including prestarted read/write
transactions, are active on the standby database
o Any read-only (snapshot) transactions are running on the
standby database. The Log Rollforward Server waits until the
read-only transactions commit.
o The row cache feature cannot be active on the standby
database.
The row cache feature must be identically configured on the
master and standby databases in the event failover occurs,
but the row cache feature must not be activated on the standby
database until it becomes the master.
To open the hot standby database prior to starting
replication, use the NoRow_Cache qualifier on the RMU Open
command to disable the row cache feature.
o Any storage area is inconsistent (for example, if you restore
a storage area from a backup file but you have not rolled
forward after-image journals to be consistent with the rest of
the database)
NOTE
On OpenVMS systems, if you have preconfigured your Hot
Standby environment using the Replicate After_Journal
Configure command and you plan to start replication
operations remotely (for example, if you want to start
replication on the standby database from the master
database node), you must provide the SYSPRV privilege to
the DBMAIJSERVER or RDMAIJSERVER account.
4 – 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 only to
the standby database node. The following table categorizes the
qualifiers according to usage:
Table 26 Qualifier Usage for the Replicate After_Journal Start
Command
Master Node Master and
Qualifiers Standby Nodes Standby Node Qualifiers
Alt_Remote_Node Checkpoint Buffers
Connect_Timeout [No]Log Gap_Timeout
[No]Quiet_Point [No]Wait Governor
Standby_Root Output Master_Root
Synchronization [No]Online
Transport
The Hot Standby software does not allow you to use qualifiers
that are not valid for the database where you enter the command.
Therefore, when you enter the Replicate After_Journal Start
command on the:
o Master node - you can specify any of the qualifiers listed in
the first and second columns of above table
o Standby node-you can specify any of the qualifiers listed in
the last two columns of the above table
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.
5 – Parameters
5.1 – 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 list describes which database root file to specify
depending on where you enter the command:
o When you enter the command, Replicate After_Journal Start
on the standby node, specify the database root file for the
Standby database.
o When you enter the command, Replicate After_Journal Start on
the master node, specify the database root file for the Master
database.
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_Root and Standby_Root qualifiers
discussed in this Help topic.
6 – Command Qualifiers
6.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.
The RMU Replicate After_Journal Configure/Reset command clears
previously configured alternate remote node name information.
6.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 1048576 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.
6.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 27 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.
6.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.
Also, because the Connect_Timeout qualifier waits only 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 in this
Help topic for additional information.
6.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)
If a gap in the replication data sequence is not resolved in the
period of time allowed, the LRS process:
1. Assumes that the node sending the message has failed
2. Terminates replication operations immediately
You must restart replication operations manually to resolve the
situation.
6.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. With the replication governor enabled, you can
effectively ensure that:
o The master and standby databases do not get too far out of
synchronization with respect to each other
o The performance of the master database does not deviate
greatly from that of the standby database
o The peak-time database requirements are handled automatically
and dynamically by the Hot Standby software
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 Help topic.)
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 table:
If . . . Then . . .
The replication The LRS process automatically upgrades
workload increases at to a stronger synchronization mode. For
a rate that prevents example, if the Synchronization qualifier
the standby database was originally set to Cold mode, the LRS
from keeping up with would change the synchronization mode to
the master database Warm (or higher, as required).
The replication The LRS process automatically downgrades
workload shrinks or weakens the synchronization mode.
However, the synchronization mode is
never weaker than the mode (Commit, Hot,
Warm, Cold) that you specify with the
Synchronization qualifier.
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 Help topic). 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 Show Statistics command 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 Corporation recommends that you do not use
the Governor=Disabled setting until the replication performance
is well understood and constant. Severe performance deviations on
the master database could stall or stop the database replication
operations.
6.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.
Also, you can record status information to an output file by
including the Output qualifier on the Replicate After_Journal
Start command.
Reference: See the Output qualifier discussed in this Help topic.
6.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.
6.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.
6.10 – Output
Output=log-filename.out
Output=log-filename_pid.out
Identifies the name of the file where you want the Hot Standby
software to create an operational output file (log) for the LCS
or LRS process:
o Specify the Output qualifier on the master database to create
an output file and collect information about the LCS process.
o Specify the Output qualifier on the standby database to create
an output file and collect information about the LRS process.
o Optionally, include "_PID" or "_pid" when you specify the
output file name. This causes the software to create a unique
file name because it includes the process identification (PID)
number.
Applicable to: Master and standby databases
Required or Optional: Optional
Default Value: None. If you do not specify the
Output qualifier, the Hot Standby
software does not record LCS or LRS
process activities to an output file.
The Output qualifier overrides definitions you make with the
BIND_LCS_OUTPUT_FILE or BIND_LRS_OUTPUT_FILE logical name. 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:
o You must specify an output file name. When you include "_PID"
in the output file specification, the command creates a unique
file name that includes the process identification (PID).
This command line creates a unique file name, for example,
DISK1:[USER]LRS_25C02914.OUT.
o Do not include a node name designation when you specify the
output file name.
o The default location is the database root file directory. You
can optionally include a directory name when you specify a
file name.
o The directory containing the output files must be readable and
writable by all processes.
o The default file type is .out
o You can display the name of output files that you specify with
the Output qualifier using the RMU Show Users command (shown
in Example 7-1). Output file names are not displayed in Show
Users output for files specified with a logical name.
NOTE
All bugcheck dumps are written to a corresponding
bugcheck dump file. Bugcheck dumps are not written to
the Output operational log.
Although it is optional, Oracle Corporation recommends that
you use the Output qualifier, or a logical name, to collect
information about the LCS and LRS processes during replication.
You can also collect information about the ABS, ALS, DBR, and
AIJSERVER processes by defining a logical name. The following
table lists the logical names you can define to collect server
process information to an output file:
Logical Name Specifies an output file for the . . .
BIND_ABS_LOG_FILE ABS process
BIND_ALS_OUTPUT_FILE ALS process (1)
BIND_DBR_LOG_FILE DBR process
BIND_HOT_OUTPUT_FILE AIJSERVER process
BIND_LCS_OUTPUT_FILE LCS process
BIND_LRS_OUTPUT_FILE LRS process
Footnote (1):
You can also collect information about the ALS process to an
output file by including the Output qualifier on the RMU Server
After_Journal command. For more information about displaying ALS
information, refer to the Oracle RMU Reference Manual.
Defining a logical name is also useful if you omitted the Output
qualifier when you entered the Replicate After_Journal Start
command to start replication. You can define a logical name to
specify an output file while replication operations are active.
This can be done by defining the appropriate logical name, and
then invoking the Replicate After_Journal Reopen_Output command.
This allows you to create an output file so the server can start
writing to the file without you having to stop and start the
server.
6.11 – 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.
6.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.
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.
6.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.
Table 28 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).
Recommendation: For high-performance applications, Oracle
Corporation 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 synchronization.
NOTE
You can define logical names to specify the synchronization
mode, or to enable or disable the replication governor.
6.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
6.15 – Wait
Wait
Nowait
Indicates whether or not the Replicate command should wait for
activation of the replication server processes before returning
control to the user.
Applicable to: Master and standby databases
Required or Optional: Optional
Default Value: Wait
The Wait qualifier has the following effects:
o On the master database node-replication waits for activation
of the server processes on the master database node
o On the standby database node-replication waits for activation
of the server processes on the standby database node
The following list describes the [No]Wait qualifier:
o Wait (default)
The Replicate command does not return to the user until the
respective server process has successfully initiated the
database replication operation. Replication waits indefinitely
for the activation of the server process, even though
activation might take substantial time. However, the server
process might not actually start the replication operation.
o Nowait
Control should be returned to the user as soon as the LCS or
LRS server process has been invoked by the database monitor.
You can use the Connect_Timeout qualifier with the Wait qualifier
to limit the amount of time replication waits for the server
process to become active.
NOTE
You must wait for commands that include the Nowait qualifier
to complete before you enter another command. This is
because if the first command fails before the subsequent
command executes, the second command might receive the
HOTCMDPEND error. For example:
$ RMU/REPLICATE AFTER_JOURNAL START/NOWAIT mf_personnel
$ RMU/REPLICATE AFTER_JOURNAL STOP/WAIT mf_personnel
If the first command to start replication fails, the startup
error might be returned to the waiting Replicate After_
Journal Stop command.
7 – Examples
Example 1
The following example shows Replicate After_Journal Start
commands that initiate database replication. The default
qualifier values are read from the database root file header
information.
$ RMU/REPLICATE AFTER_JOURNAL START mf_personnel -
/STANDBY_ROOT=REMNOD::DISK1:[USER]standby_personnel -
/SYNCHRONIZATION=COLD -
/QUIET -
/CHECKPOINT=10 -
/CONNECT_TIMEOUT=1 -
/LOG -
/WAIT -
/OUT=REMNOD::DISK1:[USER]lcs_pid.out