These 4 components work together to provide a full solution that can help you manage your Oracle Standard Edition (SE1, SE and SE2) standby database environment.

In summary, these components perform the following tasks:

Component	Icon	Description
Dbvserver		Dbvserver was introduced in Dbvisit Standby version 7 and was completely rewritten in version 8 and further extended in version 9. This component is also known as the Central Console - Web-based user interface One Central Console to manage multiple Dbvisit Standby version 9 configurations Small footprint Recommended to install on its own small server (Physical, Virtual Machine or Docker Image - persistent storage required) Provides secure encrypted communication - HTTPS protocol on port 4433 Communicates to Primary and Standby Database servers via the Dbvisit Agent (dbvagent) All communication with the Dbvisit Agent is encrypted and secure using passphrase for Dbvagent supplied during initial configuration (this can be updated later) Hosts managed by the Central Console can be Windows or UNIX (see the system requirements for more detail) The Central Console does have two small repositories where information about tasks being executed are stored, including a new statistics repository in version 9. Multiple users can be created and tasks are tracked per user Using the Central Console is not required - All functions of Dbvisit Standby version 9 can be run from the Command Line Interface (Standby Core)
Dbvagent		The Dbvisit Agent (dbvagent) is introduced in Dbvisit Standby version 8 and further enhanced in version 9. This agent is the link between the Central Console and the Dbvisit Standby Core which must be installed on each database server (primary and standby) The Dbvisit Agent has a small footprint and is listening for secure connections on port 7891 from the Central Console All communication with the Central Console is secure and encrypted The Dbvisit Agent and Central console do not have to be used - some users might only want to use the Command Line Interface (Standby Core) which does not require the Central Console or the Dbvisit Agent. In this case, the Dbvisit Agent does not have to be installed or can be left shutdown. The Dbvisit Agent is compulsory to run on a host to be managed by the Dbvisit Standby Central Console A small repository is used to keep track of tasks being executed from the Central Console
Standby Core		The Dbvisit Standby Core is also known as the Command Line Interface This is where the core functions of Dbvisit Standby is performed, this include but is not limited to the following functions: Creating a Standby Database (CSD) Sending and Applying Archived Redo Performing Graceful Switchover (Role Reversal) Re-synchronize a Standby Database due to unrecoverable archive log gaps or fixing logical corruption on the standby database due to nologging operations that were performed on the primary Activate / Failover of a Standby Database when disaster strikes More than 80 command line API options The Dbvisit Standby Core is making use of the Oracle Instant Client for connecting to the Oracle Database or ASM Instance End users might perform minimal installations where only the Dbvisit Standby core is used together with SSH for network communication. In this scenario, no other component needs to be installed and this is considered a Minimal installation and is available as an option if required. Since Dbvisit Standby version 8, the previous multiple executables have been combined into one single easy to use command line utility called the Dbvisit Standby Control Utility - "dbvctl" For detail help on using the "dbvctl" command use the "-h" option or for full detail on functions use "-h,-f" Dbvisit Standby version 9 may still be scheduled, using either the Windows Scheduler or the CRON schedule. The schedule that used to be part of the Dbvserver component has been removed and is no longer available. Many of the operations that can be performed by the "dbvctl" utility now allow batch operations - this will help to streamline tasks without interactive questions being asked.
Dbvnet		Dbvnet was introduced in Dbvisit Standby version 7 and has been completely rewritten in version 8 and further extended in version 9. Dbvnet is responsible for the network communication between the Oracle Database servers (Primary and Standby). All communication between the systems are secure and encrypted (Encryption is on by default and cannot be disabled). Dbvnet may be configured to allow compression. Dbvnet has two core functions - to allow for the copy of files between servers and to allow for remote execution of commands. On Windows-based systems, Dbvnet is the default and only option, whereas Unix based systems have Dbvnet as the default option, but if required, SSH may be used instead of Dbvnet.

The diagram below provides a brief overview of how the above four components work together. The DBA (Administrator) will have the option to either run commands via the Command Line Interface (Standby Core) using the dbvctl utility - or - They can make use of the new Central Console which can be used to manage multiple installations.

Note: The above diagram is just a high-level representation of how Dbvisit Standby components communicate.

2. New Features

Dbvisit Standby version 9 new features are listed below in no particular order:

A new Central Console look and feel with a number of new features visible:
- In version 9, a number of changes and improvements were added to the Central Console, including new icons and layout.
- You will also notice one big difference at login - the option to select one of five different languages (English, French, German, Japanese and Spanish). Below is an example of the new login page.

- The above-mentioned languages are now included and you can pick at login time which language you want the Central Console (GUI) to be displayed in. Note that certain messages such as output from the Oracle Database (During Task Execution) will still be shown in English as these are passed through from the backend.
  - A number of other changes were introduced to the main screen of the Central Console:

- 1. The Activation menu option was renamed to Disaster Recovery Actions due to a number of new options being introduced under the Activation screen. More on these below.
  2. A new User Quick-Guides feature was introduced that can assist a user in getting guided assistance in performing certain tasks. For example, if you need to create a new standby database, you can select this option, and it will display a new menu including a guided process to take you through the creation of a standby database.
  3. The task history option used to take the full section at the bottom of the page, this has now been reduced to take only the bottom left portion of the screen. The latest five tasks will be displayed, with history being available under the "View Task History" menu option.
  4. A new "View Alert History", also referred to as the "alerts section", was added to the right bottom side. This area will display key alerts, which in the base version of release 9, will include alerts when the archive log gap threshold is reached or if we detect nologging operations were performed on the primary that will affect the standby database.
- A number of new options were added to the Central Console under various sections, these include:
  - Under Create Standby Database (CSD) you can now use the new default option, which is to use a more streamlined (parallel) method that will speed up the creation of the standby configuration in most environments
  - Additional database actions, including new graphs displaying the time difference between the primary and standby
  - New graphs were added to the Manage Hosts menu where you can get a quick look at the operating system load
  - Under the new Disaster Recovery Actions page, new features will be visible, these include:
    - Allowing the user to create a backup prior to performing an activation
    - Allowing the user to use this backup to re-instantiate the standby database following a disaster recovery test (activation)
    - The option to test opening the standby database read-only
Streamlined Creation of the Standby Database (CSD).
- In summary, the new default CSD process will be performing tasks in parallel, by this we mean the following:
  - When the backup is created, it is done on a file by file basis, once the first file has completed its backup, we will continue with the second file, but will also start the network transfer of that completed file. On the standby server side, once we are notified that the first file arrived, the restore process will begin. This process will continue where files are backed up, transferred when ready and restored when available on the standby server. This is much more efficient and faster than the previous method of creating the backup of the full primary database, then once complete, copy all files to the standby and once this step is complete restore (create) the standby database.
  - This process is not available when transportable media is used
  - The original method is still available if required
  - In environments with sufficient hardware and network capacity, the new method should reduce the time to establish a standby database environment.
Core Command Line Interface (CLI) tasks - such as Create Standby Database, Graceful Switchover, Resynchronise Standby Database and Activation will now push the task status directly to the Central Console which will display the progress of these tasks as if they were initiated from the Central Console.
New Alerts
- Two key alerts will be pushed to the central console - that will be displayed on the bottom right corner. These alerts will be extended in the future, but as a start include the following:
  - When the archive log gap (time difference between primary and standby) reaches a threshold - specified in the Dbvisit Standby Configuration (DDC) file an alert will be raised.
  - If Dbvisit Standby detects during the applying of logs that no-logging operations were performed on the primary that affects the standby (meaning no redo is available to recover the standby) an alert will be raised.
- The alerts raised will have an option for the user to acknowledge them and add comments.
Adding better support for Disaster Recovery (DR) Testing:
- Most companies will run DR tests on a regular basis, which includes activating a standby database (performing a failover) and running tests on this environment. Once done, they will then remove this activated database and recreate the standby database. This can be a time intensive process not to mention complex. In version 9 of Dbvisit Standby, we have now added the option to create a backup prior to Activation (Failover) to allow you to quickly re-instantiate the standby database, without running a full CSD process from the primary. During this process you can now use two backup options:
  - Backupsets
  - Image Copy
- Using the image copy option, you can create a backup of your database in a different location (must be local disk) and following the DR test, you will get the option to either restore from this image copy, or to switch to it, which is an extremely fast process that saves a lot of time.
- Another option added to this area is to open the standby database read-only. This is the ultimate test to make sure you will be able to activate a standby database and that it is consistent. This test, when executed, will perform a restart of the standby database during which it will start it in read-only mode and then place it back into recovery mode.
Two new Graph options were added and more are expected in 9.x:
- Under the Central Console hosts section, you can get a quick view of the Operating System performance by reviewing the system load. Note that these graphs are informational only, and is not there to replace full system monitoring.
- Navigating to the Database Actions section in the Central Console, you will notice that we now provide you with a quick few on the status of your configuration, this includes a quick view of the time difference between the primary and standby - as well as an additional graph that can show the time gap difference over time.
New User Quick Guide
- To help new users of the product or users that is not familiar with Oracle, we have added a quick guide process that can quickly and easily guide you through certain key functions in the Central Console. Below is an example of the options available:

If in the above example we pick option 6 - Graceful Switchover, the guided process will start, as seen below:

Automatic Failover - Observer
- Provide remote monitoring of existing DDCs, and inform the DBA of problems in close to real-time.
- Automatically perform a Failover of the DDC if previously-specified conditions are met.
Dbvisit Standby Snapshot
- Snapshot Group
  - Create the effect of a read-only database that is being updated (logical container)
  - Can be used for Reporting/data extraction
- Single Snapshot
  - Can be read-only or read-write
  - Disaster Recovery (DR) Testing
  - Application upgrade testing
  - Development or test environments
  - Reporting or data extraction
Other features include:
- Improved HTML based email notifications
- Internal improvement of Error Handling
- Additional information in the support package

SSH Support for network communication is still supported on UNIX systems, but SSH passwordless authentication must then be used.

3. Video demonstrating some of the New Dbvisit Standby version 9 features.

Browser not supported