Appendix A: Glossary of Terms

• The main host or server that runs the primary Oracle database. Dbvisit Standby will be installed on this server.

• The remote, secondary or standby server, which runs the Oracle standby database. This can also be the reporting server that runs the reporting (standby) database. Dbvisit Standby will be installed on this server.

• The directory where Dbvisit Standby will be installed. It is recommended to keep this location the same on the primary and the standby servers.

• The Default installation directory for Dbvisit Standby version 7 is on Linux:

  /usr/dbvisit

  and on Windows Operating Systems:

  C:\Program Files\dbvisit

• The directory where the Oracle software also known as the Oracle executables, are installed.

• This is where the administration files are kept for each database. This contains the diagnostic destination or admin directory containing the bdump, udump and cdump directories of each database.

• The ORACLE_BASE is not strictly necessary to configure Dbvisit Standby. Dbvisit Standby uses the ORACLE_BASE to determine where some of the database files are located during the setup.

• This is the Windows user or Unix account that owns the Oracle Software. In most cases this is the user "oracle". This should be the user used when installing Dbvisit Standby.

• Oracle Archive log files are "archived/backup" copies of the database Online Redo logs. Dbvisit Standby is using these files to recover and keep the standby database up to date.

• The difference between the last archived sequence on the primary and the last applied sequence on the standby database. This figure should be near 0 (except when a delay is put in place on the standby using the APPLY_DELAY_LAG_MINUTES parameter in the Dbvisit Standby configuration file).

• The difference between the last archived sequence on the primary and the last archived sequence transferred to the standby server. The transfer log gap should be near 0.

log_archive_dest_n

(n can be 1-31)

• Parameter in Oracle that determines where the Log files are kept on the server. This is also known as the Oracle Database Archive Log Destination.

• The value of this parameter can be shown by the SQL command:

  SQL> show parameter log_archive_dest

• DDC stands for: Dbvisit Database Configuration and refers to the “DDC name”

• Most Dbvisit Standby commands require the DDC name, or simply DDC.  In most cases this is the same as the database name or ORACLE_SID. 

• The DDC refers to the Dbvisit Database Configuration file which is in the form:

  dbv_DDC.env

• This file contains the Dbvisit Standby settings for a particular primary and standby configuration. 

• The DDC name and the ORACLE_SID can be different. 

• The ORACLE_SID is a variable setting contained within the DDC file and is not linked to the DDC name. 

• However in most cases the DDC and the ORACLE_SID are the same.

• Example:
  If the database name (or ORACLE_SID) is PROD, then the DDC is PROD and the DDC file is dbv_PROD.env

• A Dbvisit Standby created text file, which contains all the settings for each database. There will be a DDC file for each database or instance that has Dbvisit Standby configured. 

• The DDC file contains all the necessary configuration information to keep the standby database up to date. The file(s) will be in the Dbvisit Standby Base (Install) directory and has the format: 

  dbv_<DDC>.env

• The default location for this file is: 

  DBVISIT_BASE/standby/conf/

   

  • Example:

     /usr/dbvisit/standby/conf/dbv_testdb.env

• Where DDC is the name of the Dbvisit Database Configuration. In most cases this is the same as the database name. The DDC refers to the DDC file name which is in the form: dbv_DDC.env and contains the Dbvisit Standby settings for a particular primary and standby configuration.

• For RAC the name of the DDC file is associated with the instance name and not the ORACLE_SID. Example a RAC Database PROD on node 1 can have a DDC file called dbv_PROD1.env and on node 2 the file name can be dbv_PROD2.env.

• For multiple standby databases, each standby database must have a unique DDC file name.  

• The DDC file can be manually edited and updated; this should only be done on the primary server. 

• The updated DDC file will be automatically transferred to the standby server. Any manual changes to the DDC file on the standby server will be lost as the primary DDC file is seen is the master configuration file. 

• The template to create the DDC file for each database is dbv_ORACLE_SID.env. This file should never be modified unless instructed by Dbvisit Support.

• The installation location of the Dbvisit Standby software.

• Also known as the DBVISIT_BASE directory.

• Configuration of Dbvisit Standby for a specific primary database so that Dbvisit Standby will keep the standby database up to date. 

• Dbvisit Standby setup for a specific database will create the following:

  • A Dbvisit Standby Database Configuration (DDC) file

  • Dbvisit Standby database repository (DDR) 

• Dbvisit Standby setup is initiated with command:

  DBVISIT_BASE/standby/dbvisit_setup

• As part of the Dbvisit Standby setup, Dbvisit Standby will create an Oracle account that contains tables and objects. Dbvisit Standby uses this to internally keep track of the transfer process.

• The Dbvisit Standby database repository is a small repository taking up approximately 10Mb space. The default Dbvisit Standby version 7 schema name is "dbvisit7".

• Optional module that comes with Dbvisit Standby to manage the database archive logs.

• Management and monitoring of the Oracle archive log space on either the primary, standby server or both.

• The AMM is configured through the command:

  DBVISIT_BASE/standby/dbvisit_setup

• The AMM settings are contained within the Dbvisit Standby Database Configuration (DDC) file.

• In the event of a disaster, the standby database is activated to become the new primary database. The original primary database is no longer available.

• To activate the standby database use the command:

  dbv_oraStartStop activate <DDC>

• Activation cannot be reversed. A new standby database will have to be built.

• Both the primary and standby database must be available. 

• Reverses the roles between the primary and standby databases without data loss.

• The primary database becomes the standby database and the standby database becomes the primary database.

• Graceful Switchover is used to switch back to the original primary database after a disaster in which the standby database has been activated (failover).

• Graceful Switchover may also be used for planned outages to perform an upgrade on the primary site by switching over the database users to the standby site as hardware or software is upgraded on the primary site. It may also be used to test the Disaster Recovery scenario. 

• See Graceful Switchover.

• See Graceful Switchover.

• See failover.

• Transportable Media (TM) is an external device such as a USB drive that can be used to create the standby database. 

• The TM is first plugged into the primary server and then manually transferred to the standby site and plugged into the standby server to complete the standby database creation process.

• Using a TM is advantageous if the database is very large or the network is slow since the network is no longer used to transfer the copy of the database to create the standby database.

• Dbvserver is the Web server that provides the web interface to Dbvisit. This component is optional and only required if:

  • Dbvisit Standby is configured and run through a web browser.

  • Dbvisit Standby is to be scheduled using the built in web based scheduler. 

• The default http port for Dbvserver is 8081 and for https the port is 8443.

• Dbvisit Standby provides its own built in web based scheduler and is part of the Dbvserver web server. The Dbvserver process must be running for the scheduler to function.

• Dbvisit Standby can be configured and run through a command line interface (CLI) or a web-based interface (GUI).