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.
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.
3 – Checkpoint
Checkpoint=checkpoint-interval
Specifies, in terms of processed messages, how frequently the
Hot Standby servers update information in the database root file.
This qualifier can be set to different values on the master and
standby databases.
Applicable to: Master and standby database
Required or Optional: Optional
Default Value: 100 messages
Minimum Value: 1 message
Maximum Value: 1024 messages
By default, the Hot Standby servers automatically perform
checkpoint operations on both the master and standby databases
after every 100 messages are processed. Checkpoints are essential
to database availability because they:
o Enable the Hot Standby software to restart database
replication operations more quickly in the event of a failure
because frequent checkpoints limit the number of transactions
that must be redone if a process or system fails.
o Cause all modified database cache buffers on the standby
database to be flushed to the disk, making the buffers
available for access by other users (when online database
access is enabled).
o Improve the redo performance of the database recovery (DBR)
process.
o Allow after-image backup operations to back up older after-
image journals on the master database.
NOTE
In addition to performing checkpoint operations specified
by the Checkpoint qualifier, the replication servers on
the master database also checkpoint automatically after
the following events:
o After two minutes of inactivity
o After a switchover to a new after-image journal (when
you are using circular after-image journals)
o After an AIJ backup operation (when you are using
extensible after-image journals)
On the standby database, the LRS process checkpoints
after two minutes of inactivity if data has been
processed since the last checkpoint.
These automatic checkpoints advance the oldest active
checkpoint indicator to make older after-image journals
available for backup operations. You cannot change or
override these checkpoint intervals.
The default checkpoint interval usually is sufficient to
effectively maintain synchronization between the master and
standby database root files. However, you can override the
default checkpoint interval by specifying the Checkpoint
qualifier when you start replication on the master database,
the standby database, or both.
For example, if you specify the qualifier Checkpoint=300 on the
standby database, the LRS server process updates information
in the standby database root file after every 300 messages
are exchanged between the master and the standby database. The
following table describes how the frequency of the checkpoint
operation can affect database synchronization.
Table 24 Setting the Frequency of Checkpoint Intervals
If you specify . . . Then . . .
A small checkpoint The Hot Standby software synchronizes the
interval database root files more often, but uses
less time to restart replication because
fewer transactions need to be redone.
A large checkpoint The Hot Standby software synchronizes the
interval database root files less frequently, but
requires more time to restart replication
because more transactions must be redone.
In addition, the value you set for the checkpoint interval:
o Controls replication restart in the event of a failure on the
master database. A side effect of this is that the ABS process
cannot back up after-image journals that are needed to restart
replication operations.
o Affects how the after-image journals on the master database
become available for backup.
Specifying a large value for the checkpoint interval can
cause after-image journal backup operations to stall until
the appropriate after-image journal file becomes available for
a backup operation. This is because the after-image journal
backup operation cannot back up any after-image journal file
that is required for process recovery or replication restart.
o Affects the reinitialization of after-image journals on the
standby database.
o Affects the manner in which the LRS process on the standby
database:
- Releases page locks
- Responds to page lock conflict messages from another
attached database process
Oracle Corporation recommends that you set a reasonably small
checkpoint interval for the standby database. Specifying a
checkpoint interval that is too large can prevent the LRS
process from responding to requests for pages, and it is
possible for other processes to become stalled.
For Oracle Rdb databases, you can monitor the effectiveness of
the current setting of the Checkpoint qualifier by using the RMU
Show Statistics command and examining the Checkpoint Information
display.
4 – 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.
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)
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.
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.
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.
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.
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.
11 – Reset
Resets previously configured information.
Applicable to: Master and standby database
Required or Optional: Optional
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.
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).
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