Dbvisit Concepts and Best Practice

Guide

www.dbvisit.com
Oracle is a registered trademark of Oracle Corporation. Dbvisit is a registered trademark of Avisit Solutions Limited
Except as specifically set out the Dbvisit license agreement, nothing in this Documentation constitutes a warranty as to the operation
of the Dbvisit software.
 Dbvisit Customers
Some of the companies who entrust the security of their data to Dbvisit include:
Trusted by companies across the world:
 Dbvisit Features
• Supports Oracle from 8i to 11gR2
• Supports Oracle RAC, OMF, ASM
• Simple Failover, Graceful Switchover
• Multiple standby databases
• Secure and robust (set and forget)
• Creates the standby database
• Advanced database features
• Manages archive log files
Dbvisit is the proven alternative to Data Guard
 Dbvisit components
Dbvisit software. The Dbvisit software consists of the following executables:
dbvisit - The main Dbvisit executable.
dbv_oraStartStop - Executable to start, stop, failover and switchover the databases.
dbvisit_setup - Menu driven wizard to configure Dbvisit and to create the standby database.
dbv_functions - Executable to provide extra tools and functionality.

Dbvisit Database Configuration (DDC) file. This is similar to the init.ora parameter file and contains
the Dbvisit settings for a specific database. The DDC file is generated during setup for each
database. The DDC file can be edited with any text editor or through running dbvisit_setup. The DDC
file should only be edited on the primary server.

Dbvisit Database Repository (DDR). This is a schema in the database that contains the Dbvisit
tables. The DDR is created during setup for each database.

Dbvisit trace files. Each time Dbvisit executes, a trace file is generated. This trace file contains
information about Dbvisit processing and its environment. This trace file is used by the Dbvisit
support team to quickly diagnose issues. When an alert or error notification is sent by Dbvisit, the
trace file will be attached to the email so that this can be forwarded to Dbvisit support if needed.
 Dbvisit concepts
● The Dbvisit environment will be the same on both the primary and the standby
server.
● Each time Dbvisit executes, the DDC file on the primary server is compared
with the DDC file on the standby server. If there are any differences, the DDC
file on the standby server will be overwritten with the DDC file of the primary
server. This is why the DDC file should only be edited on the primary server.
● Dbvisit is scheduled on both the primary and the standby server. The schedule
determines the maximum lag of the standby database. For example, if Dbvisit
is scheduled every 5 minutes, then the maximum time the standby database is
behind the primary database is 5 minutes.
● Dbvisit is always called with a DDC. Example:
dbvisit prod01
Where dbv_prod01.env is the DDC file name. The DDC is in most cases the same as
the ORACLE_SID but it does not have to be.
 Dbvisit Best Practice (i)
● Schedule Dbvisit on both the primary and standby servers.
● Schedule the Dbvisit log gap report (dbvisit -i)every hour on the
primary server.
● Use Dbvisit Archive Log Management Module (AMM) to manage the
archive log files on both the primary and standby servers.
● Use RMAN to backup database and archive log files as normal.
● Use the Dbvisit default settings in most cases.
● Review DDC file and understand the advanced settings available.
 Dbvisit Best Practice (ii)
● Once Dbvisit has been tested and configured:
Change SUCCESSMAIL=Y to SUCCESSMAIL=N
This will ensure only exception alerts are sent.
● Use Dbvisit to start and stop databases on boot. Dbvisit will start and
stop database correctly. Replace Oracle commands with Dbvisit
commands: dbv_oraStartStop start <database>
● Use Oracle scripts to start listener and other components.
● Hook Dbvisit log into existing monitoring tools. Dbvisit logging (JOBHIST)
is kept to a minimal. Once an error is detected, logging is elaborate.
● Review extra functionality available with dbv_functions
(dbv_functions -h)
 Primary Database NOLOGGING
Oracle strongly recommends that all NOLOGGING operations be
avoided in the primary database. Oracle will not be able to keep the
standby database consistent with the primary database during nologging
operations.
Enable the following parameter to force database to override all
NOLOGGING operations:
SQL> ALTER DATABASE FORCE LOGGING;
Ensures all operations are logged (Oracle 9i and above)
 Adding datafiles
Adding datafiles and tablespaces to primary database.
Will not be added to the standby automatically (resizing datafiles is fine).

Solution: Set Oracle parameter on standby database (from

version 10g)
SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT = AUTO SCOPE = BOTH;

If above parameter is not set, Dbvisit will add the datafile.

 Standby Database Best Practice
Open standby database in READ ONLY mode and add
tempfiles.

SQL> startup open read only;

SQL> alter tablespace temp add tempfile
'/oracle/oradata/dbvisitp/temp01.dbf' size 100m reuse

Tablespace altered.

Tempfiles that exist on the primary database are not

automatically added to the standby database. These need to
be added manually.
 Dbvisit and RMAN
● Use Dbvisit Archive Management Module (AMM) to manage the archive
logs on both primary and standby server. Dbvisit will ensure the
archives logs are transferred and applied to the standby server before
they are removed.
● Use RMAN to backup the archive logs, but not delete them.
● Let RMAN know that the archives have been managed. Run the
following on a daily basis:
RMAN> crosscheck archivelog all;
RMAN> list expired archivelog all;
RMAN> delete expired archivelog all;
● Dbvisit by default leaves the archive logs compress. If they are
compressed, then RMAN may not find them.
To leave the archive logs uncompressed set:
LEAVE_COMPRESS_SOURCE = No
LEAVE_COMPRESS_DEST = No
 Dbvisit and RAC
● Schedule Dbvisit on all primary RAC nodes.
● Schedule Dbvisit on one standby RAC node.
● Standby Database can be single or multiple instance database.
● To allow for redundancy when a RAC node is down, Dbvisit will take
over log transfer processing for the failed node. Set:
RAC_TAKEOVER_SID
 Network
For slower networks or less stable networks increase Dbvisit network
setting thresholds:
TRANSFER_RETRIES
Number of time Dbvisit will retry transfer operation before terminating (default 2).
RETRIES_WAIT_IN_SEC
Wait in seconds before a retry attempt of TRANSFER_RETRIES (default 5).
 Locking settings
For databases with a lot of activity, the archive log file may still be in the
middle of transferring while Dbvisit is attempting to apply the archive.

Dbvisit uses a sophisticated locking mechanism to ensure archives are

not applied while still being transferred.

The locking mechanism is controlled by:

LOCK_MAX_TIME_SEC
Wait in seconds before Dbvisit will raise an alert if the file is still locked.
LOCK_RETRY_TIMEOUT_MILLISEC
Wait in milli seconds before retrying the lock.
 New in Dbvisit 5.3
 ASM support. The standby database can now be created in ASM, Oracle’s proprietary file system
format. This completes the types of standby databases that can be created with Dbvisit.

 Templates. To make the disaster recovery process simpler, faster and more convenient for DBAs
the Dbvisit standby database creation wizard now includes the option to create a template. This
template stores all the information on how the standby database was created. When the standby
database needs to be recreated, for example after a failover situation, this template can be used
for fast and simple recreation.

 Transportable Media support. Some databases are too large to transfer across the network.
Now the Dbvisit standby database creation process includes an option to interface with a local
removable disk. This disk can then be manually transported to the remote site where the creation
of the standby database can be restarted and completed.

 Ability to customize the standby pfile/spfile settings before creation of the standby database.
These settings will be saved in the template for easy recreation of the standby database.

 Dbvisit installation, upgrades and creation of standby databases can now be scripted to run in
batchmode.
 Where to find more information?
Full Dbvisit documentation is available at:
www.dbvisit.com/documentation.php

Dbvisit forums:
www.dbvisit.com/forums

Dbvisit blog for tips and tricks:

blog.dbvisit.com/category/dbvisit-tips/

Receive notification of new releases:

Sign up at blog.dbvisit.com
Rss: www.dbvisit.com/forums/external.php?forumids=3
 Dbvisit support

Online Dbvisit Service Desk available at:

www.dbvisit.com/support.php
 Dbvisit roadmap
Dbvisit:
● Ongoing R&D to deliver more features.

● Dbvisit Web based version (GUI).

● Snapshot standby database (to allow full DR testing).

● Improved integration with RMAN.

● Cross platform support.

Dbvisit Summary
 Satisfied customers:

“We’ve been using Dbvisit for almost three years. Yes – it functions exactly as
advertised. And it saved us: Our internal Oracle database server failed and we
had to failover to the standby server. The failover was entirely
successful...they’ve been excellent: responsive and helpful. As you can tell,
we’re happy with the product. It provides strong functionality at a value price.
Highly recommended.”
Michael J Muha, Ph.D | Manager, Systems and Hosting | Workforce Software
– Winner of the Inc. 5000, Entrepreneur’s Hot 500, Software Magazine’s
Software 500, and Deloitte’s Technology Fast 500.

Visit www.dbvisit.com for more testimonials

 Thank you

www.dbvisit.com
Oracle is a registered trademark of Oracle Corporation. Dbvisit is a registered trademark of Avisit Solutions Limited
Except as specifically set out the Dbvisit license agreement, nothing in this Documentation constitutes a warranty as to the operation
of the Dbvisit software.