HELPLIB.HLB  —  RMU72  Hot Standby, Replicate After Journal Commands, 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  –  Description

    The Replicate After_Journal Configure command is an optional
    command you can use to preconfigure the master and standby
    databases, one database at a time.

                                   NOTE

       You cannot preconfigure both the master and standby database
       attributes in a single Replicate After_Journal Configure
       command. Moreover, you cannot enter the Replicate After_
       Journal Configure command on the standby database to
       preconfigure master database attributes, or preconfigure
       standby database attributes from the master database.

    You can specify one or more of the following qualifiers when you
    enter the Replicate After_Journal Configure command on the master
    database:

    Master Database
    Qualifiers

    Alt_Remote_Node (1)
    Checkpoint
    Connect_Timeout
    [No]Log
    [No]Quiet_Point
    Reset
    Standby_Root (2)
    Synchronization
    Transport

    Footnote (1): You must also specify the Standby_Root qualifier.
    Footnote (2): You must specify the Standby_Root qualifier the
    first time you configure the master database.

    The master database attributes that you specify are stored in the
    master database root file. (You cannot specify the Wait, NoWait,
    and Output qualifiers on the Replicate After_Journal Configure
    command. You can specify these qualifiers when you invoke the
    Replicate After_Journal Start command.)

    You can specify one or more of the following qualifiers when
    you enter the Replicate After_Journal Configure command on the
    standby database:

    Standby Database
    Qualifiers

    Buffers
    Checkpoint
    Gap_Timeout
    Governor
    [No]Log
    Master_Root (1)
    [No]Online
    Reset

    Footnote (1): You must specify the Master_Root qualifier the
    first time you configure the standby database.

    The standby database attributes that you specify are stored in
    the standby database root file. (You cannot specify the Wait,
    NoWait, and Output qualifiers on the Replicate After_Journal
    Configure command. You can specify these qualifiers when you
    invoke the Replicate After_Journal Start command.)

    You should use the Replicate After_Journal Configure command if
    you want to:

    o  Preset qualifier values that you typically specify on the
       Replicate After_Journal Start command, but without starting
       replication operations.

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

    o  Be able to quickly start replication operations by invoking
       a single Replicate After_Journal Start command on the master
       database.

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

    For example, if you have preconfigured both the master and
    standby databases and then invoke the Replicate After_Journal
    Start command on the master database node, the Hot Standby
    software:

    1. Starts replication operations on the master database using
       default qualifier values from the master database root file

    2. Creates the network connection to the standby database

    3. Attaches the master and standby databases to the network

    4. Starts replication operations on the standby database using
       default qualifier values in the standby database root file

    5. Synchronizes committed transactions on the master and standby
       databases

                                      NOTE

          If you have not preconfigured database attributes using
          the Replicate After_Journal Configure command, the Hot
          Standby software uses either the system-supplied defaults
          or the values that you specified on a previous Replicate
          After_Journal Start command.

2  –  Format

  (B)0
  Command Qualifiers                     x Defaults             x Usage
                                         x                      x
  /Alt_Remote_Node=nodename              x None                 x M
  /Buffers=rollforward-buffer-count      x /Buffers=256         x S
  /Checkpoint=checkpoint-interval        x /Checkpoint=100      x B
  /Connect_Timeout=minutes               x /Connect_Timeout=5   x M
  /Gap_Timeout=minutes                   x /Gap_Timeout=5       x S
  /Governor=[Enabled|Disabled]           x /Governor=Enabled    x S
  /[No]Log                               x /Nolog               x B
  /Master_Root=master-root-file-spec     x None                 x S
  /[No]Online                            x /Noonline            x S
  /[No]Quiet_Point                       x /Noquiet_Point       x M
  /Reset                                 x None                 x B
  /Standby_Root=standby-root-file-spec   x None                 x M
  /Synchronization=[Commit|Hot|Warm|Cold]x /Synchronization=Coldx M
  /Transport={DECnet|TCP/IP}             x None                 x M

  B=Both;M=Master;S=Standby

3  –  Parameters

3.1  –  database-rootfile

    Specifies the name of the target database root file. For example,
    if you want to preconfigure the master database attributes,
    specify the master database root file. Similarly, you can specify
    the standby database root file to preconfigure the standby
    database.

                                   NOTE

       Do not include a node name when you specify the database-
       rootfile parameter. This parameter must specify a locally
       accessible database root file; the parameter cannot include
       a remote file specification.

4  –  Command Qualifiers

4.1  –  Alt Remote Node

    Identifies an available secondary link to the standby database.

    Applicable to:              Master database
    Required or Optional:       Optional
    Default Value:              None

    The Alt_Remote_Node qualifier is used to provide the master
    database with uninterrupted hot standby replication in case of
    network failure where multiple network links are available. It
    can only be used in conjunction with the Standby_Root qualifier,
    which specifies the standby database node name.

    The Alt_Remote_Node qualifier identifies the alternate remote
    node name of the standby database. Following network failure,
    the master database automatically attempts to reconnect to
    the standby database using the alternate remote node name
    information. If the Alt_Remote_Node qualifier is not specified,
    the master database does not automatically attempt to reconnect
    to the standby database using the orginal remote node name
    specified using the Standby_Root qualifier.

    The alternate node name can be the same as the node name
    specified with the Standby_Root qualifier. The node name
    specified by the Alt_Remote_Node qualifier must identify the
    same standby database on the same remote node as originally
    specified using the Standby_Root qualifier. The maximum length
    of the alternate remote node name is 31 characters.

    At run-time, the RDM$BIND_HOT_NETWORK_ALT_NODE logical name
    can be defined in the LNM$SYSTEM_TABLE table to override any
    alternate remote node name information specified at hot standby
    startup. The logical must be specified on all nodes where the
    master database is open.

4.2  –  Buffers

    Buffers=rollforward-buffer-count

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

    Applicable to:   Standby
                     database
    Required or      Optional
    Optional:

                     Local          Global Buffers
                     Buffers
    Default Value:   4096           4096 or Global Buffer USER LIMIT,
                                    whichever is smaller
    Minimum Value:   2              2
    Maximum Value:   1,048,576      1,048,576 or Gloal Buffer USER
                                    LIMIT,
                                    whichever is smaller

    During replication operations, the LRS process on the standby
    node receives after-image journal records from the master
    database and rolls them forward to the standby database.

    You can use the optional Buffers qualifier to override the
    default number of database buffers.

    For optimal performance, you should allocate a sufficient number
    of buffers so that the server process can roll the after-image
    journal records forward with a minimum number of I/O operations.
    To estimate an appropriate number of buffers, use the following
    equation as a starting point:

    (Number of Modified Buffers per Transaction * Number of Users) + 20%

    For example, if the average number of modified buffers per
    transaction is 10 and there are 100 users on the database, then
    the server process needs 1000 buffers at one time. To ensure that
    you have an adequate number of buffers, add another 20 percent
    (200 buffers) for a total of 1200 buffers.

    The number of buffers can impact the time it takes for the LRS
    process to checkpoint. When a checkpoint occurs, the LRS must
    write all modified buffers to disk. For example, if the LRS
    is using 2000 buffers, and it takes one second for 2000 disk
    writes to complete, the LRS will be stalled for one second while
    those writes are being done. This could cause the Hot Standby
    governor to increase the synchronization mode if there is a lot
    of update activity occurring while the LRS is checkpointing. For
    some applications this could impose a practical limitation in the
    number of buffers allocated to the LRS.

                                   NOTE

       The LRS process on the standby database does not use buffer
       values defined by the following:

       o  DBM$BIND_BUFFERS logical name

       o  RDB_BIND_BUFFERS configuration parameter

       o  RDM$BIND_BUFFERS logical name

    When replication operations are active, you can use the RMU or
    DBO Show Users command to see the current number of database
    buffers allocated. If replication operations are not active or
    if you want to see the buffer value that was set on a previous
    Replicate After_Journal Start command (stored in the database
    root file), you can also use the Header and Dump_Select_Type=Hot_
    Standby qualifiers on the RMU or DBO Dump command.

4.3  –  Checkpoint

    Checkpoint=checkpoint-interval

    Specifies, in terms of processed messages, how frequently the
    Hot Standby servers update information in the database root file.
    This qualifier can be set to different values on the master and
    standby databases.

    Applicable to:              Master and standby database
    Required or Optional:       Optional
    Default Value:              100 messages
    Minimum Value:              1 message
    Maximum Value:              1024 messages

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

    o  Enable the Hot Standby software to restart database
       replication operations more quickly in the event of a failure
       because frequent checkpoints limit the number of transactions
       that must be redone if a process or system fails.

    o  Cause all modified database cache buffers on the standby
       database to be flushed to the disk, making the buffers
       available for access by other users (when online database
       access is enabled).

    o  Improve the redo performance of the database recovery (DBR)
       process.

    o  Allow after-image backup operations to back up older after-
       image journals on the master database.

                                      NOTE

          In addition to performing checkpoint operations specified
          by the Checkpoint qualifier, the replication servers on
          the master database also checkpoint automatically after
          the following events:

          o  After two minutes of inactivity

          o  After a switchover to a new after-image journal (when
             you are using circular after-image journals)

          o  After an AIJ backup operation (when you are using
             extensible after-image journals)

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

          These automatic checkpoints advance the oldest active
          checkpoint indicator to make older after-image journals
          available for backup operations. You cannot change or
          override these checkpoint intervals.

    The default checkpoint interval usually is sufficient to
    effectively maintain synchronization between the master and
    standby database root files. However, you can override the
    default checkpoint interval by specifying the Checkpoint
    qualifier when you start replication on the master database,
    the standby database, or both.

    For example, if you specify the qualifier Checkpoint=300 on the
    standby database, the LRS server process updates information
    in the standby database root file after every 300 messages
    are exchanged between the master and the standby database. The
    following table describes how the frequency of the checkpoint
    operation can affect database synchronization.

    Table 24 Setting the Frequency of Checkpoint Intervals

    If you specify . . .   Then . . .

    A small checkpoint     The Hot Standby software synchronizes the
    interval               database root files more often, but uses
                           less time to restart replication because
                           fewer transactions need to be redone.

    A large checkpoint     The Hot Standby software synchronizes the
    interval               database root files less frequently, but
                           requires more time to restart replication
                           because more transactions must be redone.

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

    o  Controls replication restart in the event of a failure on the
       master database. A side effect of this is that the ABS process
       cannot back up after-image journals that are needed to restart
       replication operations.

    o  Affects how the after-image journals on the master database
       become available for backup.

       Specifying a large value for the checkpoint interval can
       cause after-image journal backup operations to stall until
       the appropriate after-image journal file becomes available for
       a backup operation. This is because the after-image journal
       backup operation cannot back up any after-image journal file
       that is required for process recovery or replication restart.

    o  Affects the reinitialization of after-image journals on the
       standby database.

    o  Affects the manner in which the LRS process on the standby
       database:

       -  Releases page locks

       -  Responds to page lock conflict messages from another
          attached database process

       Oracle Corporation recommends that you set a reasonably small
       checkpoint interval for the standby database. Specifying a
       checkpoint interval that is too large can prevent the LRS
       process from responding to requests for pages, and it is
       possible for other processes to become stalled.

    For Oracle Rdb databases, you can monitor the effectiveness of
    the current setting of the Checkpoint qualifier by using the RMU
    Show Statistics command and examining the Checkpoint Information
    display.

4.4  –  Connect Timeout

    Connect_Timeout=minutes

    Specifies the maximum number of minutes that the LCS process on
    the master database waits for a network connection to the LRS
    process on the standby database.

    Applicable to:              Master database
    Required or Optional:       Optional
    Default Value:              5 minutes
    Minimum Value:              1 minute
    Maximum Value:              4320 minutes (3 days)

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

    1. The Hot Standby software invokes the log catch-up server (LCS)
       process on the master database.

    2. The LCS process invokes its corresponding network AIJSERVER
       process on the standby node.

    3. The AIJSERVER process attempts to create a network connection
       to the LRS process on the standby node.

    By default, the LCS process allows 5 minutes for the AIJSERVER
    to connect to the LRS process. You can override the default
    by specifying the Connect_Timeout qualifier when you start
    replication on the master database. (Note that if you specify
    the Connect_Timeout qualifier, you must specify a time value (in
    minutes).)

    The Connect_Timeout qualifier is useful when you start
    replication operations on the master database before you
    start replication on the standby database. This is because the
    Connect_Timeout qualifier allows sufficient time for the network
    connection to be made before the LCS process begins sending
    after-image journal records across the network.

                                   NOTE

       While the LCS process on the master database waits for the
       replication activity to begin on the standby database, users
       and applications can continue to access and modify data in
       the master database.

4.5  –  Gap Timeout

    Gap_Timeout=minutes

    Specifies the maximum number of minutes that the standby database
    (LRS process) should wait for a gap in the replication data
    sequence to be resolved.

    Applicable to:              Standby database
    Required or Optional:       Optional
    Default Value:              5 minutes
    Minimum Value:              1 minute
    Maximum Value:              4320 minutes (3 days)

4.6  –  Governor

    Governor=Enabled
    Governor=Disabled

    Enables or disables the replication governor.

    Applicable to:              Standby database
    Required or Optional:       Optional
    Default Value:              Governor=Enabled

    The purpose of the replication governor is to coordinate database
    replication operations automatically between the master and the
    standby databases.

    For more information see the Governor qualifier discussion under
    the Replicate_After_Journal_Commands Start Help topic.

4.7  –  Log

    Log
    Nolog

    Indicates whether or not to log the status of, and information
    about, activities when you start replication operations.

    Applicable to:              Master and standby database
    Required or Optional:       Optional
    Default Value:              Nolog

    If you specify the Log qualifier, output showing the status
    of the replication startup is logged to SYS$OUTPUT on OpenVMS
    systems.

    Oracle Corporation recommends that you specify the Log qualifier.

4.8  –  Master Root

    Master_Root=master-rootfile

    Identifies the name of the master database root file from
    which the replication servers on the standby database receive
    replication data.

    Applicable to:     Standby database
    Required or        Required the first time you enter the
    Optional:          Replicate After_Journal Start command and
                       any time you specify other Replication
                       Startup qualifiers. Optional on all subsequent
                       invocations.
    Default Value:     None.

    You must include the Master_Root qualifier the first time you
    enter the Replicate After_Journal Start command (unless you have
    preconfigured the Master_Root qualifier using the Replication
    After_Journal Configure command). This ensures that the standby
    database uses the master database you specify as the source of
    the replication operations. If you omit the Master_Root qualifier
    on subsequent Replicate After_Journal Start commands, the Hot
    Standby software retrieves the master database name from the
    header information in the database root file.

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

    o  Specify the name of the master database root file.

       Do not specify the name of the standby database on the Master_
       Root qualifier. Any attempt to use a restored database as a
       master database causes replication startup operations to fail.

    o  Include a node name and directory path for remote network
       communications.

       You can define a logical name to identify the master node.

    o  Be able to access the master database.

       When the master database node is configured in a VMScluster
       system, the node name you specify with the Master_Root
       qualifier can be any participating node from which the master
       database can be accessed. Cluster aliases are acceptable when
       you use the Master_Root qualifier.

    The master and standby databases communicate using network
    communications (for remote database access) or interprocess
    communications (for local database access) according to how you
    specify the master database name. The following table describes
    how the Hot Standby software chooses the method of communication:

    If . . .               Then . . .

    You include a node     The Hot Standby software uses remote
    name when you specify  network communications to receive the
    the master database    after-image journal log changes, unless
    root file              the specified node is the current node

    You do not include     The Hot Standby software uses local
    a node name when you   interprocess communications to receive
    specify the master     the after-image journal log changes
    database root file

    The Hot Standby software compares and verifies the master
    database (that you specify with the Master_Root qualifier)
    against the standby database (that you specify with the Standby_
    Root qualifier when you start replication operations on the
    master database). This verification ensures that both databases
    are identical transactionally.

4.9  –  Online

    Online
    Noonline

    Allows or disallows users and applications to be on line
    (actively attached) to the standby database.

    Applicable to:              Standby database
    Required or Optional:       Optional
    Default Value:              Noonline

    Online database access means that database users and applications
    can be actively attached (and perform read-only transactions)
    to the standby database before, during, and after replication
    operations.

    The default setting (Noonline) disallows applications and
    users from attaching to the standby database during replication
    operations. However, if the standby database is open on another
    node (thus, an ALS process is active on that node), the LRS
    process cannot start replication on the standby database and
    the error message STBYDBINUSE is returned.

                                   NOTE

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

    Because the Replicate After_Journal Start command fails if you
    enter it on a standby node where read/write transactions are in
    progress (including prestarted read/write transactions), Oracle
    Corporation recommends that you choose the Noonline (default)
    setting.

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

4.10  –  Quiet Point

    Quiet_Point
    Noquiet_Point

    Determines whether or not the log catch-up server (LCS) process
    acquires a transactional quiet point during the database
    synchronization phase of the replication restart procedure.

    Applicable to:              Master database
    Required or Optional:       Optional
    Default Value:              Noquiet_Point

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

4.11  –  Reset

    Resets previously configured information.

    Applicable to:              Master and standby database
    Required or Optional:       Optional

4.12  –  Standby Root

    Standby_Root=standby-rootfile

    Identifies the name of the standby database root file to which
    the replication servers on the master database send replication
    data.

    Applicable to:     Master database
    Required or        Required the first time you enter the
    Optional:          Replicate After_Journal Start command and
                       any time you specify other Replication Startup
                       qualifiers. Optional on all other invocations.
    Default Value:     None

    You must include the Standby_Root qualifier the first time you
    enter the Replicate After_Journal Start command (unless you have
    preconfigured the Standby_Root qualifier using the Replication
    After_Journal Configure command). This ensures that the master
    database communicates with the standby database you specify
    as the recipient of replication operations. If you omit the
    Standby_Root qualifier on subsequent Replicate After_Journal
    Start commands, the Hot Standby software retrieves the standby
    database name from the header information in the database root
    file.

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

    o  Specify the name of the standby database root file.

    o  Include a node name and directory path for remote network
       communications. (You can define a logical name to identify the
       master node.)

                                      NOTE

          When the standby database is configured in a VMScluster
          system, the node name you specify with the Standby_Root
          qualifier cannot be a cluster alias.

    o  Be able to access the standby database.

    o  Ensure that the standby database is opened for access prior to
       starting replication operations on the master database.

       You must open the standby database manually unless you
       preconfigured the standby database. If you preconfigured the
       database, you can start replication on both the master and
       standby databases by entering a single Replicate After_Journal
       Start command on the master database. The master database
       automatically opens the standby database, if necessary.

    The master and standby databases communicate using network
    communications (for remote database access) or interprocess
    communications (for local database access) according to how you
    specify the database name. The following table describes how the
    Hot Standby software chooses the method of communication:

    If . . .               Then . . .

    You specify a node     The Hot Standby software uses remote
    name (for access to a  network communications to ship the after-
    standby database on a  image journal log changes, unless the
    remote node)           specified node is the current node

    You do not specify a   The Hot Standby software uses the
    node name              following communications to ship the
                           after-image journal log changes:

                           o  Local interprocess communications on
                              the local node

                           o  Remote network communications on all
                              other nodes and across the cluster

    The Hot Standby software compares and verifies the master
    database (that you specify with the Master_Root qualifier)
    against the standby database (that you specify with the Standby_
    Root qualifier). The purpose of this verification is to ensure
    that both databases are identical transactionally.

4.13  –  Synchronization

    Synchronization=keyword

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

    Applicable to:              Master database
    Required or Optional:       Optional
    Default Value:              Synchronization=Cold

    When you enable replication operations, server processes on the
    master database write transactions to the after-image journal
    for the master database and send them across the network to
    the after-image journal for the standby database. The standby
    database acknowledges the receipt of the transactional message
    and handles after-image journaling depending on the mode you
    have set with the Synchronization qualifier. The following table
    describes the keywords you use to set the synchronization mode.

    Table 25 Keywords for the Synchronization Qualifier

                                Performance
                                Impact
             Equivalence        on
             of Committed       Master   Standby Database
    Keyword  Transactions       Database Recoverability

    Commit   When the standby   Highest  The standby database is
             database                    transactionally identical
             receives the                and recoverable with respect
             AIJ information             to the master database.
             from the master
             database, the
             servers on the
             standby database:

             1. Write it to
                the after-
                image journal
                on the standby
                system

             2. Apply the AIJ
                to the standby
                database

             3. Send a message
                back to
                the master
                database
                acknowledging
                the successful
                commit of the
                transaction

    Hot      When the standby   High     The standby database is
             database                    extremely close to being
             receives the                transactionally identical to
             AIJ information             the master database.
             from the master
             database, the               After-image journal records
             servers on the              in transit are received
             standby database:           and committed. Some restart
                                         processing may be required
             1. Write it to              to synchronize the database.
                the AIJ on the
                standby system

             2. Send a message
                back to
                the master
                database
                before
                applying the
                transaction
                to the standby
                database

    Warm     When the standby   Medium   The standby database is
             database                    transactionally close to
             receives the                the master database, but the
             AIJ information             databases are not identical.
             from the master
             database, the               There may be transactions
             servers on the              rolled back on the standby
             standby database:           database that have been
                                         committed on the master
             o  Send a message           database.
                back to
                the master
                database
                before
                applying the
                transaction to
                either the AIJ
                or the standby
                database

             o  Might not
                commit after-
                image journal
                records to the
                database

    Cold     When the standby   Low      The standby database is
    (de-     database                    not immediately recoverable
    fault)   receives the                transactionally with respect
             AIJ information             to the master database.
             from the master
             database:                   After-image journal records
                                         in transit could be lost.
             o  The servers
                never return
                a message
                acknowledging
                the receipt
                of the AIJ
                information

             o  In failover
                situations,
                it is
                possible that
                transactions
                rolled back
                on the standby
                database were
                committed on
                the master
                database

    For each level of database synchronization, you make a trade-off
    between how closely the standby and master databases match each
    other in regard to committed transactions against performance.

    For example, the Synchronization=Cold level provides the fastest
    performance for the master database, but the lowest level of
    master and standby database synchronization. However, in some
    business environments, this trade-off might be acceptable. In
    such an environment, the speed of master database performance
    outweighs the risk of losing recent transactions in the event of
    failover; system throughput has greater financial importance and
    impact than the value of individual aij records (transactions).

4.14  –  Transport

    Transport=DECnet
    Transport=TCP/IP

    Allows you to specify the network transport. The specified
    transport, DECnet or TCP/IP, is saved in the database.

    Applicable to:              Master database
    Required or Optional:       Optional

    The following example shows the use of this feature:

    $ RMU/REPLICATE AFTER CONFIGUIRE /TRANSPORT=TCPIP -
    _$ /STANDBY=REMNOD::DEV:[DIR]STANDBY_DB M_TESTDB

5  –  Usage Notes

    o  The first time you configure the standby database, you must
       include the Master_Root qualifier, and you must include the
       Standby_Root qualifier the first time you configure the master
       database.

       You must preconfigure the Master_Root or Standby_Root
       qualifiers because these qualifiers identify the "alternate"
       database for the database being configured. These qualifiers
       also identify whether a master or standby database is being
       configured (if the Replicate After_Journal Configure command
       includes the Master_Root qualifier, a standby database is
       being configured). The Master_Root and Standby_Root qualifiers
       are optional on subsequent replication configuration commands
       because the value is stored in the database root file.

    o  You can include a node name with the Master_Root or Standby_
       Root qualifiers.

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

    o  The RMU Backup command with the Continuous qualifier is not
       supported when replication operations are active.

    o  You can override values you define with the Replicate After_
       Journal Configure command (and other the default values stored
       in the database root file) by specifying qualifiers on the
       Replicate After_Journal Start command.

    o  You cannot specify the Output qualifier on the Replicate
       After_Journal Configure command. Therefore, if you need to
       record Hot Standby server information to an output file when
       you start replication operations from the master database,
       specify an output file by:

       -  Including the Output qualifier on the Replicate After_
          Journal Start command

       -  Defining the BIND_ALS_OUTPUT_FILE, BIND_HOT_OUTPUT_FILE,
          BIND_LCS_OUTPUT_FILE, or BIND_LRS_OUTPUT_FILE logical name

                                         NOTE

             If you plan to start replication operations remotely
             (for example, to start replication on the standby
             database from the master database node), you must
             have GROUP, WORLD, and SYSPRV privileges on OpenVMS
             systems.

6  –  Examples

    Example 1

    The following example shows how to use the Replicate After_
    Journal Configure command to configure replication attributes
    for the master database:

    $ RMU/REPLICATE AFTER_JOURNAL CONFIGURE mf_personnel -
        /STANDBY_ROOT=REMNOD:::DISK1:[USER]standby_personnel -
        /SYNCHRONIZATION=COLD -
        /QUIET_POINT -
        /CHECKPOINT=10 -
        /CONNECT_TIMEOUT=1
Close Help