Executing (run) the default Dbvisit Standby commands from the command line can be done by running the following:

./dbvisit <DDC>

This command is the same for Sending and Applying logs. Dbvisit Standby will know what operation to perform depending on which environment is it executed from.

Below are two examples, showing the sending and the applying of logs. In this example the database is called “proddb” and this is also the name of the DDC. The DDC file name is:

dbv_proddb.env

Important Change in version 7

In Dbvisit Standby version 7 the Archive logs are renamed when they are copied to the standby server (in the Dbvisit ARCHDEST location). Before upgrading, make sure the standby have already applied all the archive logs that was available in the Dbvisit standby ARCHDEST. New archive logs in this location will have the new naming convention.

<thread>_<sequence>_<resetlogs_id><STANDBY_ARCHIVELOG_NAME_EXTENSION>

Where STANDBY_ARCHIVELOG_NAME_EXTENSION defaults to .arc

Example: 1_45628_ 812975118.arc

For more details on Sending and Applying logs in Oracle RAC environments please see Sending and Applying logs in RAC Environments

Sending Logs (Primary Server)

The example below show how to execute Dbvisit Standby on the Primary Server from where logs are shipped to the standby server.

oracle@dbvlin501[/usr/dbvisit/standby]: ./dbvisit proddb
=============================================================
Dbvisit Standby Database Technology (7.0.01.11254) (pid 10632)
dbvisit started on dbvlin501: Thu Aug 22 23:12:11 2013 ()
=============================================================

>>> Obtaining information from standby database (RUN_INSPECT=Y)...

>>> Checking Dbvisit Standby for configurational differences between dbvlin501 and
    dbvlin502...

    No configurational differences found between dbvlin501 and dbvlin502.

>>> Log file(s) for proddb will be transferred from dbvlin501 to dbvlin502...

  > Transferring 'o1_mf_1_5437_91fnr2k9_.arc.gz' to server dbvlin502:7890
    Progress: 0%...20%...40%...60%...80%...100% [2725 KB/s] - done.
  > Transferring 'o1_mf_1_5438_91fnr2yf_.arc.gz' to server dbvlin502:7890
    Progress: 0%...20%...40%...60%...80%...100% [1513 KB/s] - done.
  > Transferring 'o1_mf_1_5439_91fnr3bw_.arc.gz' to server dbvlin502:7890
    Progress: 0%...20%...40%...60%...80%...100% [1708 KB/s] - done.

    3 archive log transfers to dbvlin502 for proddb completed.
    Last sequence was 5439.

>>> Dbvisit Archive Management Module (AMM)

    Config: number of archives to keep      = 0
    Config: number of days to keep archives = 7
    Config: archive backup count            = 0
    Config: diskspace full threshold        = 80%

    Current disk percent full (/u01/app/oracle/flash_recovery_area) = 24%

    Current disk percent full (FRA) = 76%

    Number of archive logs deleted = 0

=============================================================
dbvisit ended on dbvlin501: Thu Aug 22 23:12:27 2013
=============================================================

When using Oracle RAC

When running Dbvisit Standby on an Oracle RAC environment, you will need to run the sending of archive logs on each of the primary RAC Nodes. Example, if you have a database called PROD with instance PROD1 on node 1 and PROD2 on node 2 you will end up with a DDC file per node, example:

Node 1: dbv_PROD1.env

Node 2: dbv_PROD2.env

When scheduling or running Dbvisit on the RAC nodes, you will run Dbvisit Standby as follow:

On Node 1 execute the command: dbvisit PROD1

On Node 2 execute the command: dbvisit PROD2

It is recommended that when you schedule Dbvisit Standby on the RAC nodes to schedule them at least 1 minute apart and not at the exact same time.

When Dbvisit Standby is executed to send Archive Logs to the Standby database the process can be summarised as follow:

If RUN_INSPECT=Y is set in the DDC file, Dbvisit Standby will execute a "silent" log gap report, where it will connect to the standby database and obtain the current status (Archive and Transfer log gap information). This information is then stored in the internal Dbvisit Standby Repository (located in the primary database). This information is used for reporting purpose and this option can be disabled by setting RUN_INSPECT=N in the DDC file for the database. This can improve the speed of running Dbvisit as these steps will be excluded, But by disabling this reporting data (GRAPHS) used in the GUI (Dbvserver) reporting section will not have sufficient information.

Dbvisit Standby will next inspect the DDC file and compare it with the DDC file located on the Standby server. Note that the primary database server DDC file is seen as the master copy, and if it is found that the standby database server DDC file is different, it will be overwritten with a copy from the primary server.

This can be disabled by setting SYNCH_DBVISIT_INSTALL=N and SYNCH_ENV_FILE_ONLY=N in the database configuration (DDC) file.

IMPORTANT: Setting the above values to N is not recommended and should only be done on recommendation from Dbvisit Support

Dbvisit Standby will start sending the required archive logs to the standby server in sequential format (based on sequence number).
- By default:
  - If an archive log was generated since the last run this log will be shipped to the standby database and no additional "logswitch" will be performed.
  - If NO archivelogs were generated since the last run, a "logswitch" will be executed on the database which will start the creation of a new archivelog that will then be transferred to the standby server.
- Forcing a logswitch:
  - If you want to ensure the gap between the primary and standby server is similar to the scheduled gap, you can set the LOGSWITCH=Y in the DDC file. This will force Dbvisit Standby to execute a logswitch on every execution on the primary server. Note that this can cause additional overhead on the database server depending on current system load and I/O subsystem (especially slow I/O subsystem - storage)
- Archive logs will be compressed before being send to the standby server if the COMPRESS variable is set in the DDC file.
  - Compression:
    - By default compression of the archive logs are enabled
    - gzip is used for compression on Linux (COMPRESS=/bin/gzip) and Dbvisit Standby's internal compression "dbvisit" is used on Windows (COMPRESS=dbvisit)
    - The default uncompress values will be set to gunzip (UNCOMPRESS=/bin/gunzip) on Linux and Dbvisit Standby's internal uncompress will be used on Windows (UNCOMPRESS=dbvisit)
    - To disable compression, set COMPRESS=N
    - The compression settings are specified in the DDC file on the primary server.
  - ARCHDEST
    - The ARCHDEST location is used by Dbvisit Standby and is not the same location as the database Archive Destination or Recovery Area.
    - This location should be created on both the Primary and Standby servers and should have read/write permission for both the "oracle" and "grid" accounts if ASM role separation is used.
    - ARCHDEST must be on an Oracle supported filesystem type, i.e. ext3/ext4. Common Internet Filesystem (CIFS) is not supported.
    - Dbvisit Standby will transfer the Archive logs to the ARCHDEST location on the standby server as specified in the DDC file.
    - If ASM storage is used on the primary:
      - Archive logs will be copied out of the ASM storage to the ARCHTMP directory as specified by the DDC file. ARCHTMP will be the same as the specified ARCHDEST location by default, but can be specified to be a different location if required.

Once the transfer is complete, the Dbvisit Standby Archivelog Management Module (AMM) will start
- This process will review the AMM settings (as specified in the DDC file) and this process will execute the required steps.
- For more details see the AMM section later in this guide.

Archive logs must be shipped (copied) to the standby using Dbvisit Standby as the archive logs are renamed during this process.

If archive logs are not copied to the standby using Dbvisit Standby, the archive logs might not be in the correct naming format as mentioned above and the recover process will not pick up the correct archive logs - unless they are renamed.

This approach of not using Dbvisit Standby to send (copy) archive logs to the standby is not recommended.

Applying Logs (Standby Server):

The example below shows how you can execute Dbvisit Standby on the Standby server. During this process archive logs will be applied to the standby database.

oracle@dbvlin502[/usr/dbvisit/standby]: ./dbvisit proddb
=============================================================
Dbvisit Standby Database Technology (7.0.01.11254) (pid 7358)
dbvisit started on dbvlin502: Fri Aug 23 11:15:53 2013 ()
=============================================================

>>> Log file(s) for proddb from dbvlin501 will be applied to dbvlin502
201308231115 - Log seq 5436 thread 1 applied to standby database proddb.
201308231115 - Log seq 5437 thread 1 applied to standby database proddb.
201308231115 - Log seq 5438 thread 1 applied to standby database proddb.
201308231115 - Log seq 5439 thread 1 applied to standby database proddb.

>>> Dbvisit Archive Management Module (AMM)

    Config: number of archives to keep      = 0
    Config: number of days to keep archives = 7
    Config: diskspace full threshold        = 80%

Processing /u01/app/oracle/archive/proddb...
    Archive log dir: /u01/app/oracle/archive/proddb
    Total number of archive files   : 22
    Number of archive logs deleted = 0
    Current Disk percent full       : 22%

=============================================================
dbvisit ended on dbvlin502: Fri Aug 23 11:16:05 2013
=============================================================

When executed on the standby server to apply the logs the process can be summarised as follow:

Archive logs located in the Dbvisit ARCHDEST location will be applied to the standby database
- If the archive logs are compressed (based on the COMPRESS value in the DDC file), they will be automatically uncompressed (based on the UNCOMPRESS value in DDC file) after which they will be applied to the standby database.
Once all archive logs available in the ARCHDEST location was applied, will Dbvisit Standby execute the Dbvisit Standby Archivelog Management Module (AMM) which will manage the ARCHDEST location on the standby database server.

When using Oracle RAC on the Primary

When using Oracle RAC as the primary environment, it is important to note that you only have to run Dbvisit Standby on the standby server for ONE of the DDC files and you do not have to run it for both.

Example:

If you have a 2 node primary RAC environment, with dbv_PROD1.env and dbv_PROD2.env as the DDC files for the RAC database called PROD. You will run Dbvisit Standby on both primary RAC nodes to ship each node's respective archive logs (archive logs for that thread) to the standby. But on the standby server, you only have to run Dbvisit Standby for one of the DDC files. Dbvisit Standby will apply all logs from both threads during recovery. In this case you can run only "dbvisit PROD1" to apply all the logs on the standby.

Running Dbvisit (Sending and Applying Logs)

Sending Logs (Primary Server)

Applying Logs (Standby Server):