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:

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

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