Oracle Corporation offers an optional Hot Standby software
solution that you can use to implement a standby database for
mission-critical and disaster recovery functions.
A standby database is a second running database that is created
from and transactionally consistent with the primary or master
database. Data modifications that are made to the master database
are made simultaneously to the secondary database. The secondary
database is sometimes referred to as a hot standby database
because it is available immediately to pick up application
processing if the primary database system fails.
The Hot Standby software prevents your Oracle Rdb database or
Oracle CODASYL DBMS database from becoming a single point of
failure by replicating the master database to a standby database.
The Hot Standby software automatically performs coordinated
database synchronization and verification with high performance
and minimal impact on the master system resources.
1 – Replicate After Journal Commands
This topic provides the syntax and semantics for the following
Replicate commands and their parameters and qualifiers:
o Replicate After_Journal Configure
o Replicate After_Journal Reopen_Output
o Replicate After_Journal Start
o Replicate After_Journal Stop
These commands are available using either Oracle RMU (the Oracle
Rdb database management utility) or DBO, the Oracle CODASYL DBMS
Database Operator utility. This Help utility describes the Oracle
RMU command syntax only.
1.1 – Configure
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.1.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.
1.1.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
1.1.3 – Parameters
1.1.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.
1.1.4 – Command Qualifiers
1.1.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.
1.1.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.
1.1.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.
1.1.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.
1.1.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)
1.1.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.
1.1.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.
1.1.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.
1.1.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.
1.1.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.
1.1.4.11 – Reset
Resets previously configured information.
Applicable to: Master and standby database
Required or Optional: Optional
1.1.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.
1.1.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).
1.1.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
1.1.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.
1.1.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
1.2 – Reopen Output
Closes the current informational file and reopens 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).
1.2.1 – Description
The Hot Standby software dynamically and transparently switches
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 Replicate After_Journal Reopen_Output command performs the
following steps to reopen the output file:
1. Closes the current output file in which information about
replication operations is recorded.
2. Reopens the output file by opening a new file using the
original output file name. On OpenVMS systems, the Hot
Standby software opens a new output file using the originally
specified file name and a new version number. Thus, you can
view the original output file by specifying the older version
number. If disk space is a problem, relocate the old output
file to another disk.
You can enter the Replicate After_Journal Reopen_Output command
on either the master or standby node as follows:
Enter the
command . . . To reopen the output file for the . . .
On the master LCS server on the master database
database node
On the standby LRS server on the standby database
database node
You must explicitly enable the ability to write replication
startup information to an output file by including the Output
qualifier when you start replication operations (see the
Replicate_After_Journal_Commands Start command for more
information), or by specifying the BIND_ALS_OUTPUT_FILE, BIND_
HOT_OUTPUT_FILE, BIND_LCS_OUTPUT_FILE, or BIND_LRS_OUTPUT_FILE
logical name.
The Replicate After_Journal Reopen_Output command is useful when:
o The output file becomes too large
For example, as the output file grows 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 on OpenVMS systems, a message is sent to the system
operator). Note that replication operations continue, even
when write I/O to the output file stops.
o You want to view the currently open 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. You
can also view the contents of the current output file using
the Type command at the OpenVMS system prompt.
NOTE
You cannot use the Replicate After_Journal Reopen_Output
command to change the size or location of the output
file; the command is intended to create a new version of
an existing output file.
o You want to open an output file for a server process that is
actively performing replication operations
Defining a logical name is 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. The advantage to
defining a logical name is that you do not need to stop and
restart the server.
Reference: See the Output qualifier discussion under the
Replicate_After_Journal_Commands Start Help topic.
1.2.2 – Format
(B)0[mRMU/Replicate After_Journal Reopen_Output database-rootfile
1.2.3 – Parameters
1.2.3.1 – database-rootfile
Specifies the name of the master or standby database root file.
1.2.4 – Usage Notes
o 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.
o The Replicate After_Journal Reopen_Output command is
applicable only to the files that record activities for the
LCS process or the LRS process. To reopen or view the output
file that records information about the ALS process, use the
RMU Server After_Journal Reopen_Output command.
Reference: For more information about displaying ALS
information, refer to the Oracle RMU Reference Manual.
1.2.5 – Examples
Example 1
The following command example shows how to reopen an output file:
$ RMU /REPLICATE AFTER_JOURNAL REOPEN_OUTPUT mf_personnel.rdb
1.3 – Start
Initiates database replication operations.
1.3.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.
1.3.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
1.3.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.
1.3.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.
1.3.5 – Parameters
1.3.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.
1.3.6 – Command Qualifiers
1.3.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.
1.3.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.
1.3.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.
1.3.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.
1.3.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.
1.3.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.
1.3.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.
1.3.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.
1.3.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.
1.3.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.
1.3.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.
1.3.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.
1.3.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.
1.3.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
1.3.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.
1.3.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
1.4 – Stop
Terminates database replication operations.
1.4.1 – Description
You can enter the command on either the master node or the
standby node.
When you enter the command on the master database, replication
is terminated immediately. Active transactions are handled
differently depending on whether you specify the Abort qualifier
or take the default (Noabort).
When you enter the command on the standby database, replication
is terminated after any pending after-image journal records are
completely rolled forward. Any active transactions on the standby
database are rolled back.
You can stop 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 stop database replication.
If the database is not manually opened on the node where you
entered the 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.
1.4.2 – Format
(B)0[mRMU/Replicate After_Journal Stop database-rootfile
[4mCommand[m [4mQualifiers[m x [4mDefaults[m
x
/[No]Abort[={Forcex | Delprc}] x /Noabort
/[No]Log x /Nolog
/[No]Wait x /Wait
1.4.3 – Parameters
1.4.3.1 – database-rootfile
Specifies the database root file for which you want to stop
replication operations.
1.4.4 – Command Qualifiers
1.4.4.1 – Abort
Abort=Forcex
Abort=Delprc
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:
o Abort=Delprc
The Abort=Delprc qualifier closes the database, and recovery
unit journals (RUJ) are not recovered. The processes and any
subprocesses of all Oracle Rdb database users are deleted.
o Abort=Forcex
The Abort=Forcex option closes the database, and recovery unit
journals (RUJ) are recovered and removed.
o Abort
When the Abort qualifier is specified without a keyword,
database replication shuts down as quickly as possible.
Any after-image journal information waiting to be rolled
forward on the standby database is discarded, and all active
transactions on the standby database are rolled back.
o Noabort (default)
Database replication shuts down after all after-image journal
information waiting to be rolled forward on the standby
database is completed. Note that this type of shutdown could
still result in active transactions being rolled back on the
standby database.
1.4.4.2 – Log
Log
Nolog
Enables or disables logging the results of the Replicate After_
Journal Stop operation.
Applicable to: Master and standby databases
Required or Optional: Optional
Default Value: Nolog
If you specify the Log qualifier, the log file output is written
to SYS$OUTPUT on OpenVMS.
1.4.4.3 – 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 deactivation
of the server processes on the master database node
o On the standby database node-replication waits for
deactivation of the server processes on the standby database
node
The following list describes the Wait and Nowait qualifiers:
o Wait (default)
The Replicate command does not return to the user until
the respective server process has successfully stopped the
database replication operation. Replication waits indefinitely
for the termination of the server process, even though
termination might take substantial time. However, the server
process might not actually stop the replication operation.
o Nowait
Control should be returned to the user as soon as the LCS or
LRS server process has been stopped by the database monitor.
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.
2 – Privileges
On OpenVMS systems, you must have the RMU$OPEN privilege in the
root file ACL for the database or the OpenVMS WORLD privilege to
use the Replicate commands.
3 – Server Names and Acronyms
The discussions in Replicate_Commands Help topic sometimes use
acronyms to refer to the Hot Standby servers. The following table
shows the server names and their acronyms, and the database where
each server runs:
Server Acronym Database
AIJ log server ALS Master
Log catch-up server LCS Master
Log rollforward server LRS Standby
AIJSERVER - Standby
4 – Default Command Qualifiers
The Hot Standby software 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:
o Replicate After_Journal Configure-Preconfigures the master
and standby database attributes without starting replication
operations. This optional command allows you to preset
database attributes that do not take effect until the next
time you start replication operations using the Replicate
After_Journal Start command.
o Replicate After_Journal Start-Configures database attributes
at the same time you start replication for a database. If you
preconfigured your database previously using the Replicate
After_Journal Configure command, you can override the default
settings by including one or more qualifiers on the Replicate
After_Journal Start command.
Whenever you enter the Replicate After_Journal Start command,
the Hot Standby software initiates database replication using
the qualifier values specified on the Replicate After_Journal
Start command line. If you do not specify qualifier values on the
command line, the Hot Standby software uses values stored in the
database root file or the default value for the qualifier.
Therefore, you do not need to respecify the qualifier values
except to change a qualifier setting. For example, the following
command example shows the Replicate After_Journal Start command
the first time you enter it on the master database node:
$ RMU/REPLICATE AFTER_JOURNAL START mf_personnel -
/STANDBY_ROOT=REMNOD::DISK1:[USER]standby_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.
5 – Examples
The following are examples of the header information from Oracle
Rdb master and standby database root files:
Example 1 Header Information from the Master Database Root File
Hot Standby...
- Database is currently being replicated as "Master"
Standby database is "_DISK1:[USER]STANDBY_PERSONNEL.RDB;1"
Remote node name is "REMNOD"
Replication commenced on 5-AUG-1996 08:13:30.57
Synchronization obtained via quiet-point
Server checkpoint interval is 100 messages
Server connection-timeout interval is 5 minutes
Replication synchronization is "hot"
Example 2 Header Information from the Standby Database Root File
Hot Standby...
- Database is currently being replicated as "Standby"
Master database is "_DISK1:[USER]MF_PERSONNEL.RDB;1"
Remote node name is "ORANOD"
Replication commenced on 5-AUG-1996 08:13:23.91
Database replication is "online"
Server checkpoint interval is 100 messages
Server gap-timeout interval is 5 minutes
Server buffer count is 256
Server 2PC transaction resolution is "commit"