1. Introduction

One of the new features introduced in Dbvisit Standby version 8 is the new Central Console, which is a web-based user interface. In previous versions of Dbvisit Standby, the user interface was installed on the database server (primary and standby) and you were only able to manage the primary and standby database from one console (either the primary one or the standby one). There was no option to use one interface to manage many standby configurations.

This changed in version 8 and further extended in version 9. The new Central Console should be installed on its own server. This does not have to be a large system with high resource specifications. The recommended resource requirements are at least 1GB of free storage, 1GB of Memory with network connectivity to all primary and standby hosts you would like to manage with the new interface. You may use physical hardware, a Virtual Machine or even Docker (as long as persistent storage are used) - but it is important that the Operating System requirements are met.

Below are a few important notes regarding the new Central Console:

The Central Console will only allow HTTPS traffic, HTTP will not be available.
The default port is 4433, this may be changed during installation.
The default Administrator username is "admin" with the default password "admin", it is recommended that you adjust this after installation.
If more than one user is expected to use the Central Console, we recommend that each user have their own login created.
All traffic between the Central Console and Dbvisit Agents are encrypted and secure.
The Central Console uses a small repository to keep track of users and tasks being performed.

Important information regarding communication:

The Central Console needs to be configured to access the hosts which run the Oracle Databases (Primary and Standby Databases).
Before you can add new hosts to the console, you must first make sure that the Dbvisit Standby version 8 Core components (which include the Dbvisit Agent) is installed on all of the Database Servers that will be managed.
When installing the Dbvisit Agent (dbvagent) you will be asked for a Passphrase. You need to make sure that a secure passphrase is used. This will be required for setting up the new hosts. Without the Dbvisit Agent or using an incorrect passphrase, the Central Console (Dbvserver) will not be able to communicate with the agents.

The following browsers are supported when using the Dbvisit Standby Web Based interface (latest versions recommended)

Firefox (Recommended)
Chrome
Safari

2. Installing the Central Console

It is recommended that the Central Console be placed on a Linux Based Operating System - Oracle Linux 6 and above is recommended.

For more detail on the Central Console Installation please see: Installing The Dbvisit Standby Central Console

On this page:

3. Stop and Start the Central Console

If you followed the recommended installation steps and are running the Central Console (Dbvserver) on a standalone environment, you should end up with the following directory structure:

[oracle@dbv3 ~]$ cd /usr/dbvisit
[oracle@dbv3 dbvisit]$ ls
dbvserver

[oracle@dbv3 dbvisit]$ tree .
.
`-- dbvserver
    |-- conf
    |   |-- dbvserver.conf
    |   `-- dbvserver.db
    |-- dbvserver
    |-- doc
    |   `-- README.txt
    `-- log
        `-- dbvserver.log

4 directories, 5 files

3.1. Starting Dbvserver (Central Console)

To start the Central Console, use the "./dbvserver -d start" command from within the DBVISIT_BASE/dbvserver subdirectory.

Once the command is executed, you can use the "ps -ef|grep dbvserver|grep -v grep" command to show the process running.

Example:

[oracle@dbv3 dbvisit]$ cd dbvserver
[oracle@dbv3 dbvserver]$ ls
conf  dbvserver  doc  log
[oracle@dbv3 dbvserver]$ ./dbvserver -d start

[oracle@dbv3 dbvserver]$ ps -ef|grep dbvserver|grep -v grep
oracle     120     0  0 11:09 ?        00:00:00 ./dbvserver -d start

3.2. Stopping Dbvserver (Central Console)

To stop the Central Console, use the "./dbvserver -d stop" command from within the DBVISIT_BASE/dbvserver subdirectory.

Once the command is executed, you can use the "ps -ef|grep dbvserver|grep -v grep" command to show if the process running. If no processes are returned, it is not running:

Example:

[oracle@dbv3 dbvisit]$ cd dbvserver
[oracle@dbv3 dbvserver]$ ls
conf  dbvserver  doc  log


[oracle@dbv3 dbvserver]$ ps -ef|grep dbvserver|grep -v grep
oracle     120     0  0 11:09 ?        00:00:00 ./dbvserver -d start
[oracle@dbv3 dbvserver]$
[oracle@dbv3 dbvserver]$ ./dbvserver -d stop
[oracle@dbv3 dbvserver]$
[oracle@dbv3 dbvserver]$ ps -ef|grep dbvserver|grep -v grep
[oracle@dbv3 dbvserver]$

3.3. Handling Dbvserver Inactivity (Central Console)

On the "Central Console" screen, a pop-up screen may appear prompting you to refresh regularly.

The parameter SESSION_TIMEOUT handles inactivity, in seconds, on the frontend to force a refresh or re-login of inactive sessions.

This parameter value can be increased in the DBVISIT_BASE/dbvserver/conf/dbvserver.conf file.

It will require the dbvserver process to be stopped and started, to take effect.

4. Central Console - Home Page

You must log in to use the Central Console - it is not possible to access any functionality without logging in. (Image 1)

As of Dbvisit Standby version 9 you can now select between English, German, French, Japanese and Spanish. This selection is done at login.

The front-end will then be displayed in the selected language, but all output from tasks will still remain in english.

In the above screen, you can login with your specified username and password. Note that the default username is "admin" and password - "admin" on a clean installation. Once logged in you will be shown the Main Dbvisit Standby screen as shown below:

Once logged in, the Main Page is the central point from which you will access all of Standby's functionality. It is divided into 10 section buttons, each of which loads the appropriate set of views/actions. When you first log in, you will notice most of these are greyed out, and you will only have access to the Hosts and Users sections. This is because you must have at least 1 valid User and 1 valid Host before being able to perform any action within Standby. After adding Hosts, you will gain access to the Configurations section, where you can either create new configurations (DDCs) or use existing ones you imported from your defined Hosts. (Image 2) When you have at least 1 Host, User and Configuration defined in the system, you will have access to all the Main Page sections until then you will see the default screen as below:

Numbers [1-13] indicate all the available sections on the Main Page. They are:

Manage Hosts
- From this menu option, you will be able to add new hosts (Dbvisit Standby Agents). Before you can manage any configuration, the host (agent) must be added to the Central Console. You will require the Dbvisit Agent to already be preinstalled on the Database Server (one agent per server even if there are many Dbvisit Standby configurations on that system).
- You will be able to import existing DDC files from this menu as well.
- Assigning specific Central Console users to only manage specific hosts can be performed under this menu option
Manage Configurations
- This menu option will contain the sections to allow you to create, update or remove Dbvisit Standby Configuration files (DDC files).
- Note that certain existing DDC values may not be updated via the Central Console. These values may, however, be changed directory in the DDC file if required or instructed by a Dbvisit Standby support team.
Create Standby Database
- It is possible to create the standby database using the Central Console. These tasks can be performed when navigating to this menu option.
- A valid DDC file must already exist before you can create a standby database.
- The creation of a standby database process is also referred to as the CSD process.
Manage Users
- The Central Console can have more than one user. This is ideal for environments where there is more than one person involved in managing the Dbvisit Standby configurations. The default user is called "admin" with password "admin". It is recommended for a new installation that this user's password is changed and that new users be created for each of the team members.
- There are two roles that can be selected: Administrator and User.
- Administrator users can perform any task in the Central Console
- Normal users are not allowed to create/add new hosts (agent) connections and may be restricted to manage only specific hosts.
Update Standby License
- From this menu option, you will be able to apply your Dbvisit Standby license key.
Database Actions
- The Database Action menu will provide you with the option to perform the following tasks:
  - Run an Archive Log Gap Report
  - Sending logs to the standby database server
  - Applying logs to the standby database
  - Start, stop, restart or perform status checks on all databases relating to a DDC file
  - Start, stop or perform status checks on the Dbvisit Standby background (Daemon) process relating to a selected DDC file
  - Recreate the standby controlfile
  - Refresh one specific data file on the standby database from the primary
  - Resend only one specific archive log from the primary to the standby database
Synchronize Standby
- This menu option will guide you through the process to re-synchronize a standby database and recover from unrecoverable (lost) archive logs or recovering a standby database from logical corruption due to nologging operations that were performed on a primary database.
Perform Graceful Switchover
- If it is required to perform a "role reversal" also known as a Graceful Switchover (GS) you will make use of this menu option.
- Switching roles between a primary and standby database are done in a controlled manner
Activate Standby Database
- In case of disaster, you might need to activate the Standby database (also known as failover to the standby database). This task can be performed here.
User Quick Guides
- This is one of the new features introduced in version 9. It provides you with a list of guided tasks you can follow. Example if you want to create a standby database (CSD) you can select the quick guide and it will then guide you through the steps.
Active Task List and Task History
1. Here you can check on their progress at a glance, having full information as to their state (active/finished), source configuration, current progress and detailed progress log.
2. The View task history button allows you to see a detailed record of all previously run tasks.
Alerts and Alert History
1. In version 9 a new Alert panel was introduced. When any "Log Gap Threshold" is breached an alert will be displayed in this section. In addition to this if any "nologging" operations is detected, an alert will also be displayed.
Support Package
1. Using the Create Support Package button you can, at any time, generate a complete support package for any PID in your system - this will be invaluable whenever you need to contact Dbvisit Support.

As you use the Central Console to complete various actions, all important tasks, such as Create Standby Database and Synchronize, will show up in the Active Task List section

5. Central Console - User Management

All the User-related actions are performed in the Users section. Here you can add, edit and delete users, as well as assign them to specific Hosts.

It is recommended that you update the default admin user password to a more complex password following a new installation

It is recommended that you update the default admin user password to a more complex password following a new installation.

Note: Only admins can perform User actions. (Image 1 below) The table [1] lists all the Users currently in the system, by login and role.

Click the NEW button [2] to create a new user. You can choose to edit or delete any existing User [3].

The fields on the Create and Edit User pages are the same. (Image below) Login [1] is the name you use to access the Console. Role [2] determines if the user has Admin or User privileges.

Admins have access to everything, Users can only access the Hosts they are assigned to, as well as the Configurations involving those Hosts.

Linked Hosts [3] is a multi-select field allowing the assignment of Hosts to a particular User. Use this to restrict Users to certain Hosts only.

A User will not have access to any Host they are not assigned to, or any Configuration (DDC) involving that Host.

It is recommended that you create a user account for each user that will be using the Central Console and the users rather use their own account than using the default admin account.

Using the "Task History" option you will then be able to monitor which user performed which task.

6. Adding New Hosts

The Hosts section contains all Host-related actions, including Host creation, editing and deletion.

In addition, from here you can check whether a Host is currently online, and Import existing DDCs from any Host. (Image 1)

When creating a new Host, or editing an existing one, the fields are the same (see Image below).

The Host field [1] is the name of your host server. This must be a DNS-resolved name, it cannot just be an IP address.

When setting the port [2], 7891 is the default value used by Dbvagent, however, you can change this if you have modified the Dbvagent configuration file.

Passphrase [3] is the password for Dbvagent - you would have defined this in the course of its installation.

After the first 3 fields are filled in, the system will attempt to automatically contact the Host and determine its operating system [4].

This should take no longer than a couple of seconds. If this is not successful for some reason, you can manually choose the correct operating system. Please ensure this selection is correct, as an incorrectly set operating system will cause critical errors when using Standby.

Authorized Users [5] is a reverse-association copy of the Linked Hosts field in the User section - this multi-select allows you to set all Users authorized to access this particular Host. Any Users not set here will not be able to perform actions on this Host.

Once a Host is defined, various options become available for it (Image below).

For each Host, you may edit it [3], delete it [4], if communication is working as expected (1) a checkmark will be displayed - in version 9 a new system load graph was added.

7. Managing Configuration (DDC) Files

Please see also this section for additional information: Creating the DDC File

Dbvisit Standby version 8.0.x allows you to create a DDC (Dbvisit Standby configuration file) for the following scenarios:

Oracle single instance database as primary with a single instance database as a standby
- The primary and standby databases can use Filesystem based storage or ASM
- If ASM is to be used on the standby it must already be configured with the required disk groups
- Primary and Standby database systems should match - especially the Oracle Database software (Including patch levels)
- Mixing Database Editions are not supported. Both primary and standby must use the same Oracle Software version and Edition.
Oracle Real Application Cluster (RAC) database as primary to a single instance standby database (with multiple threads but only one is used)
Oracle Real Application Cluster (RAC) database as primary with an Oracle RAC database as a standby

Important If using Oracle RAC configurations:
- - The primary and standby configuration should match (Operating System, Clusterware - GI, and Database software)
  - If the primary is a two-node cluster the standby Oracle RAC must also be a two node cluster
  - All RAC nodes must be running at the time of running the Dbvisit Standby - Create Standby Database option
  - Shared storage is recommended on each cluster to install and run Dbvisit Standby from
  - A Virtual IP address and name is recommended for each cluster
  - If the Standby Database is to be an Oracle RAC enabled cluster, the Oracle RAC cluster must already be configured with the required disk groups and storage available.
  - If using Oracle RAC, it is recommended to have a shared storage location for the Dbvisit Standby installation as well as for the Dbvisit ARCSOURCE and ARCHDEST locations. These locations are used by Dbvisit and are not the same as the database archive destinations and should not be located inside the database archive log destination or fast/flash recovery area.

7.1. Creating a New DDC File - Single Instance to Single Instance

This section will describe the steps to create a new DDC file for a single instance primary and standby database.

Following these steps will create the DDC file after which you can edit and add additional parameters if required (Example adding email notification configuration).

Step 1: Select "Manage Configurations"

From the main screen, select the Manage Configurations option.

Step 2: Adding a new DDC by selecting the "+" or "New" green button as highlighted.

In this example, there is no DDCs configured. To start the creation of a new DDC select the "+" new option to start the process.

Step 3: Select the Source Host - the host that is running the database we want to create a standby database from.

As shown in the screen below, we select from the dropdown option [1] the host "dbv1" which in this case have already been added as a new host.

This host must already have the Dbvisit Standby Agent (dbvagent) installed and running. See the "Managed Hosts" section for more detail.

The License will be displayed, review the license as shown in [2] below and if in agreement, select "ACCEPT" to continue.

Step 4: Select the Database for which you want to create a standby database.

Databases running on the host selected in step 3 above will be listed in the drop-down option.

If the database is not listed in the /etc/oratab file - if using Linux, or if it is not listed in the Windows registry (entry created by DBCA) - it will not be listed.

You will need to add the database manually - select the Manual entry option and specify the database SID and Oracle Home when prompted.

If the database you want to create a standby database for is listed, select it and continue to the next step.

Step 5: Specify ARCHSOURCE location and Network communication.

The next step is to confirm the ARCHSOURCE location - marked as [4] in the image below.

On the primary database server, this location will only be used as a temporary area to which archive logs are extracted - if using ASM before they are sent to the standby database.
This location is not the same as the database archive log destination and should not be located in the database archive log location or fast/flash recovery area.
Do not share this location with other databases, it must be unique to a specific DDC
If a Graceful Switchover (GS) is performed, the ARCHSOURCE and ARCHDEST locations in the DDC files are reversed - meaning the ARCSOURCE location will become the ARCHDEST and the ARCHDEST location will become the ARCSOURCE location.

The next option to review is the use of DBVNET or SSH. The default is DBVNET which is recommended. The default port will also be displayed and can be changed.

The default DBVNET port used is 7890 and for SSH 22.
SSH is still a supported option on UNIX based systems but is not available if you are using Windows-based systems.
If you do select SSH you must make sure that SSH is already configured on both primary and standby database servers with passwordless authentication.

Step 6: Select the Destination Host marked with [5] in the above image - this is the host that will run the standby database to be created

It is important that the Oracle Database software (matching the primary database software in version and edition) is already installed on this host.
From the drop-down menu select the standby database server host.
Hosts will only be listed here if they have already been configured in the Central Console.

You will now be presented the following options as marked by [5] and [6] below.

The following fields need to be reviewed and updated where needed:

1. Oracle SID

This is the Oracle SID to be used for the standby database.
This is also the value that will be used for the INSTANCE_NAME of the standby database
If you are creating two standby databases for the exact same primary on the same standby database server, the Oracle SID must be different.
If the primary and standby database servers are an exact match, leaving the Oracle SID here at the default - which is the same as the primary (source) is recommended.

2. Select if ASM to be used?

If the Standby database is to use ASM, change the selector to YES and specify the ASM instance name, example +ASM (see image below)
If the Standby database is not using ASM, leave it at the default which is NO.

3. ARCHDEST location

This is the location on the standby database server where Dbvisit Standby will copy archive logs into. This location must have sufficient disk space to keep at least two days worth of archive logs, 4 or more recommended.
This location should not be located inside the database archive log destination or fast/flash recovery area
Do not share this location with other databases, it must be unique to a specific DDC

4. Dbvisit Standby base directory on the destination (standby) server

This is the location where Dbvisit Standby is installed on the standby database server.
A default value will be provided, please make sure you have already installed Dbvisit Standby into this location and that the version match the same version used on the primary database server.

5. Oracle Home directory on the destination (standby) servers

Dbvisit Standby will provide the same location for the Destination as what was provided for the source server. Please review the location and make sure the correct Oracle Home is used for the standby database.

6. The standby database unique name (DB_UNIQUE_NAME)

Dbvisit Standby version 8 is making use of the Database Unique Name which is the database parameter DB_UNIQUE_NAME.
In most cases, this value (which is the same as what was detected on the source/primary) should be sufficient without any changes required.
If you are running more than one standby database on the standby database server for the same primary database, you must specify a different DB_UNIQUE_NAME for the standby databases.

7. The new configuration (DDC) name to be used

The last option to be provided is the Dbvisit Configuration File (DDC) name.
We recommend you provide a short name - in most cases the default value provided should be sufficient
Do not use special characters in the name - example underscore "_" or a dash "-" or any others such as $,%# etc.

8. Adding a valid License Key

The final step is to add a license key. Remember that you cannot use a v7 or v8 key for version 9.
The license key is only added during DDC creation and it will be applied on the primary node

Step 7: Submit - The DDC file is created

Once you submit, the DDC file will be validated and created in the DBVISIT_BASE/standby/conf directory on the primary and standby database servers.

At this stage, a new repository will also be created, which is located in the same directory with the name <DB_NAME>.db.

This repository will be updated on the primary database and is not used on the standby database until a Graceful Switchover or Activation is performed.

Once the DDC file is created, you will see the configuration is listed in the Central Console - see image below.

The following options are highlighted in the image above.

Delete DDC
Update (refresh) DDC (use this if you have manually altered the DDC file through Command Line to synchronise your changes with the GUI)
Edit DDC
Upgrade DDC (The green status tick will be changed to an upgrade button if it is detected that the DDC file need to be upgraded)

7.2. Create a new DDC File - Oracle RAC to Single Instance

Please see this section for more detail: Creating the DDC File#2.5.CreateaDDCFile-OracleRACprimarytoSingleInstanceStandby

7.3. Create a new DDC file - Oracle RAC to Oracle RAC

Please see this section for a detailed example: Oracle RAC Configurations#OracleRACConfigurations-5.CreatetheDbvisitStandbyDDCFile

7.4. Edit a DDC File

The GUI allows you to directly edit Configuration/DDC parameters. To do this, click the blue Edit Configuration button for the relevant Configuration on the Configurations page.

You can edit any parameter in a DDC by double-clicking on the row or clicking the blue Edit button [1]. To set the parameter, either click the green Accept button or press Enter.

You can remove any parameter from a DDC by clicking the red Delete button [2].

NOTE: You CANNOT edit OR remove special system parameters - these are highlighted in blue background rows, and have no action buttons available [4].

You can add new parameters by clicking the green New button [3] and selecting from the list of available parameters. Only one parameter can only be added ONCE, i.e. each parameter can only have a single value.

After making changes, click Submit to save the DDC [1]. Until you do this, no change is made to the DDC.

8. Dbvisit Standby License Management

In order to perform most of the actions available in Standby, your software must be licensed using a key purchased from Dbvisit. You can apply this key on the Licence page.

First, you must select the Configuration/DDC for which you wish to view/apply the license key [1].

If the Configuration is NOT licensed: Enter your key in the fields provided [1], and click the License button [2]. Note that you can copy and paste the key by right-clicking into the first text field and selecting Paste.

Upon the license being successfully applied, you will be redirected to the Main Page.

If the Configuration IS licensed: You will be shown your key, for reference purposes, as well as the expiration date [1].

You also have the option to Update your License at any time. To do this, click the Update button, and enter a key license key as per the 'Not Licensed' option described above.

9. Creating a Standby Database

Create Standby Database is one of the most important functions of Dbvisit Standby.

Begin by selecting the Configuration/DDC to work with [1]. Next, you will need to select one of three possible process options:

New Database [2]: This will allow you to set up a new Standby Database completely from scratch. You will need to review system parameters and add/edit values as necessary. This is the default CSD process mode.
Use Template [3]: Using this option you can run a CSD process using values saved from a previous successful operation. This is a good way to repeat similar/identical CSD operations without having to manually change system parameters each time.
Resume CSD [4]: Initially disabled, this option becomes available if a previous CSD operation did not fully complete for whatever reason. This could be because you are creating a Standby database using the Transportable Media option (more on this below), or because an error has occurred that you need to resolve before re-trying to restore your database logs.

After selecting this option, you will need to review the system parameters presented in the table below the option selectors [1].

Please refer to Section 7.4: Edit DDC of this guide for tips on how to use the parameter table. Parameters highlighted with a blue background cannot be altered [2].

Following the parameter table are several Options:

Perform backup, transfer and restore operations in parallel [1]: If you select this option, the backup process will start and as soon as the first file is complete, it will be transferred while the next file backup is started. On the standby once a file arrive, the restore process will begin. This new method was introduced in version 9 and should improve the speed of the Create Standby Database (CSD) process.
Transportable media [2]: Set this to Yes if you want to use a physical medium to manually move your database backup files. You may wish to do this if your database is very large and it would be faster to use a physical drive to move the data.
Windows system login: If you are using a Windows environment with Oracle 12c and above, you will need to enter the username and password of the Windows user that will run the Oracle database service.
Source and Target temp location [3]: Please ensure both of these locations have enough disk space to hold a full backup of your primary database.
Action:
- Create Standby Database [4] will start the process without saving your parameter settings.
- Create Standby Database & Template [5] will start the process AND save your parameter settings in a template. Next time you run a CSD process, you can instantly reload values from this template to speed up your work.
- Create Template Only [6] will ONLY create the template with your saved parameters. The CSD process itself will NOT be initiated.

Once all the options above are set, please click Submit [7] to initiate the Create Standby Database process.

OPTION 2: Create Standby Database Using a previously saved Template

This option works exactly the same as Option 1 above, except all the values in the parameter table are loaded from a Template created during a previous iteration of the CSD process. This can be a good way to save time by reusing previously set values for complex installations.

OPTION 3: Resume Previously started Create Standby Database (CSD) - either when transportable media is used, or if an error was fixed and process is restarted to continue where it left off (if possible)

This option, normally disabled, will only become available if a previously initiated CSD process has stopped before completion. Most often, this will be because you have chosen to use the Transportable Media option, and the system is waiting for you to move the database backup files to the correct location before proceeding. Once you have moved the files, selecting this option and clicking Submit [2] will resume the process from where it stopped. NOTE: You can also do this from within the Task Details pane of the relevant CSD task - more on this in section 10 below.

Another reason this option is available may be because an error has occurred after the primary database backup step. In this case, you may be able to modify Configuration/DDC parameters, or other system settings, to resolve the error and resume the CSD process without having to re-run the database backup step.

10. Tasks and Task Tracking

One of the central elements of the Standby GUI is the Task system. Whenever a major process is initiated, a Task is created to track every aspect of that process and make all the information available to the user.

The list of major processes is as follows:

CSD
Send/Apply Logs
Synchronize Standby
Perform Graceful Switchover
Activate Standby Database
Recreate Standby Control File
Refresh One Data file
Send One Log File

At the bottom of any screen in the Standby GUI, you will find the Active Task List pane [1]. This is where all the Tasks known to the system, across all Hosts, are displayed, in order of their updated/completed timestamps. As soon as a new process is launched (and a new Task created), it will appear here. All Task information is always updated in REAL TIME, with no more than a 1-2 seconds delay.

The Active Task List displays a maximum of SEVEN tasks at any one time. Tasks beyond this range, i.e. older, can be viewed by clicking the View Task History button [2].

Command Line Tasks

Tasks can be initiated either through the GUI, or from the CLI.

If a Task is started from command line, e.g. Recreate Standby Control File, it will also appear in this Active Task Pane. This allows the user to have a single point of reference for all the Tasks that are/were active across their Configurations.

Tasks initiated from the command line will be marked with a special "terminal cursor" icon to distinguish them from GUI-initiated Tasks.

Please note: not every Task type from the CLI is automatically displayed in the GUI. By default, the Send Logs & Apply Logs Tasks are omitted. The reason is because these are the Tasks that typically comprise Dbvisit Standby Daemon actions, and thus are performed on a frequent basis - if they were to appear in the GUI, the Task List Pane would quickly fill up with hundreds of similar Tasks.

To change the type of CLI Tasks that propagate to the GUI, you can modify the NTF_TASKS_SHOW parameter at the end of any DDC Configuration file.

10.1 Task States

A Task can be in one of four states:

Active [1] - An active task is one that is currently running. It is always shown in blue. Clicking an Active Task will produce a blue lightbox popup that displays a progress log of everything that Task has done up to the present moment. This lightbox is also Live & Real Time, i.e. you can leave this open on your screen, and it will dynamically update with new progress information while the Task is running.
Completed [2] - A completed Task is one that has finished successfully. It is always shown greyed-out, with a green success tick mark in the top right corner. Clicking on a Completed Task will produce a full progress log of everything that was done while the Task ran. As the Task is no longer running, this progress log is no longer updated.
Completed with an Error [3] - These are Tasks that have finished unsuccessfully, i.e. terminated with a fatal error. They are always shown greyed-out, with a red cross in the top right corner. Clicking a Completed with Error Task will display a red lightbox with error information at the top, followed by the progress log up to the point of failure. As these tasks have finished/terminated, they are no longer updated.
Paused/Awaiting Input [4] - Currently only relevant to Create Standby Database Task processes, these Tasks are awaiting user input. Always shown first in the list, and highlighted in yellow and grey, these Tasks are awaiting user input to continue. You will most often see a Paused Task when running CSD with the Transportable Media option enabled. Clicking on a Paused Task will bring up the progress log as usual, but with a special "Resume" command button at the top left corner, clicking this will resume the Task from its current state.

10.2 Task Interactions

You can interact with any Task in two ways:

Rollover [1] - Rolling your mouse over a Task will cause it to slide out horizontally, exposing the name of the process the Task represents, as well as the most recent progress update. This is a good way to very quickly check Task status at a glance.
Clicking into a Task will bring up the progress/details lightbox. This will contain the progress log of everything the Task has done up to the present moment, as well as any errors. If there are errors, the lightbox will be red.

10.3 Create Support Package from Task

Once a Task finishes, either successfully or with an error, you are able to quickly and easily generate a Dbvisit Support Package from within that Task's details lightbox. Should you need to contact Dbvisit Support, this will be invaluable to us to help diagnose your problem.

At the top of any completed Task's progress log, click the Create Support Package button [1] to initiate the generation of the Support Package. This will contain all the logs and configuration files relevant to the selected Task. The button text will briefly change to "Generating...", and then to "Click to Download". Clicking this button will initiate the download of the Support Package to your PC.

Support packages may also be generated for any process on any Host, even processes not displayed in the Task History, as long as the PID number of the process is known. To do this, click the Create Support Package button within the Active Task List subheader [2], choose the desired Configuration/DDC and enter the PID number.

11. Managing Databases

11.1. Overview

This page provides the user access to all the various database and daemon-related tasks that are required to keep a Source or Standby location in good operational condition.

All actions are Configuration/DDC-specific. The full list of available actions is as follows:

DDC - configuration name
Source host (status - green mean it is available)
Destination host
Time difference between source and destination databases based on log gap report details
Refresh timer (this is for visual purpose to show refresh of above time difference)
Log gap graph - this graph is based on the log gap report (time difference between source and destination)
Log gap report
Send logs
Apply logs
Database actions → (Status/Restart/Start/Stop)
Daemon actions → (Status/Start/Stop)
Recreate standby control File
Refresh one data file
Send one specific archive log file

Actions 7-11 are not considered major processes - when these are clicked/initiated, a "Working..." message appears on-screen briefly, and is then replaced by the result(s) of the action.

Actions 12-14 are considered major processes - when these are initiated, they generate Tasks that appear in the Active Task List, and can be tracked/managed by the user from there.

11.2. The Log Gap Report

The Log Gap Report allows you to quickly see at a glance the time difference and log gap between the Source and Destination Hosts.

11.3. Send Archive Logs to Standby from Primary

Launching this action will initiate the transfer of archive logs from the Primary Host. While typically done automatically on a schedule, this manual action can be useful to run, for example, before attempting to run the Synchronize process.

Clicking the button [1] starts the process. Since Send Logs counts as a major process (see the full list of major processes in section 10.0), it generates a Task object [2]. Clicking on the task object shows the live progress log [3].

11.4. Applying Archive Logs on Standby

The matching action of Send Logs above, Apply Logs causes the archive logs transferred from the Primary to the Destination Host to be applied. This should almost always be done after a successful Send Logs process.

11.5. Database Status, Restart, Start and Stop

These actions allow you to issue basic commands to the Host databases from the GUI. You must first select a Host to work with [1], and then click the button for the action you would like to take [2] and then the action to be performed [3].

11.6. Daemon Status, Start and Stop

Very similar to the Database actions above, here you can issue basic commands to the Standby Daemon process. Select the Host to contact [1], then the action to take [2].

11.6.1. Daemon Controls on a Windows Environment

If you are running Standby on a Windows environment, the available Daemon Control options are a little different. In order to work with the Daemon, Dbvisit must first install a Windows Service to manage the communication.

You can check whether the required Service is installed and/or running by selecting the host [ 1 ] and the Status is displayed for the particular host [2]. To start the daemon click on the start button [3]

This command will return whether the Service is (a) installed, and (b) running. The Service must be both installed and running to work.

If the Service is not installed, all other commands (Uninstall, Start, Stop) will fail, and may incorrectly report an error. Therefore, you should always run the Status command if in doubt over the status of the Daemon Service

To install the Service, click the Install button.

Once the Service is installed, you may use the other commands at will exactly as you would as per section 11.6.

11.7. Recreate the Standby Control File

Using this action, you can resolve problems with a corrupt/malformed Standby control file by replacing it from the Source Host.

NOTE: Initiating this action [1] will restart the standby database, and thus may take some time.

Also, because this action is considered a major process, it generates a Task once started [2].

11.8. Refresh a Standby Database Datafile

This action allows you to refresh a single database backup file, from Source to Destination. This can be extremely useful in case a single file was corrupted during transfer, and you do not have the time or network resources to perform the entire backup process again.

You will need to know the file number that you want to refresh/replace. Enter it in the input field [1], and then press Submit [2]. As a major process, this action will generate a Task object.

11.9. Send One Log File

This action allows you to re-send a single archive log file, most frequently useful in cases of data corruption. Enter the desired Sequence [1] and Thread [2] numbers, and initiate by clicking Submit [3]. As a major process, this action will generate a Task object.

12. Synchronizing a Standby Database

12.1. Recover from Unrecoverable Archivelog Gap

It may happen that an archivelog was removed by backups before it was shipped to the standby, or if the standby database is far behind the primary for some reason - it is then possible to make use of the Synchronize Standby Database feature provided by Dbvisit Standby. This method can be used instead of the traditional rebuild of the standby database using the CSD (Create Standby Database) feature.

During this process, Dbvisit Standby will perform an incremental backup on the primary database backing up the required changed blocks from the SCN number where the standby is currently and then ship this backup to the standby and then use RMAN to recover the standby using this backup. The result is that the standby database is "rolled forward" past this missing archived log. The process is easy and described in the steps below.

Please note that the backup process (step 1) may take the same amount of time as a full backup as the full primary database is scanned for the required blocks to backup. The backup file should be smaller than a full backup. The recovery process should be much faster.

Step 1: Select Synchronize Standby from the main screen

Step 2: From the drop-down option - as pointed by the arrow, select the specified DDC file. In this example, the DDC named DEV2 will be selected.

Step 3: In the next step you will be presented with a screen that will require some input.

The options above marked with arrows and numbers can be summarised as follow:

This is the DDC selected
The primary details are being displayed which include the current SCN number and Date/Time.
The standby details are displayed, this includes the current SCN the standby database is at and its Date/Time
Difference between primary and standby database is expressed as time in the format HH:MI:SS
By default, the Synchronize Lag option is selected.
Specify the temporary backup location where the incremental backup will be created on the primary database server. It is important that this location must be able to hold at least a full compressed backup of the primary database (RMAN compressed backupset). If you do not have sufficient disk space, the Synchronize Standby process will fail. Note that the backup in most cases will be much smaller than a normal full backup as only the blocks needed to recover the standby database will be backed up. Make sure this location have correct permission and that the Oracle software owner has full read/write permission on this folder.
This is the temporary location on the standby database server where the temporary incremental backup will be copied. It is recommended that this location have sufficient space to hold a full compressed backup of the primary database to ensure you do not run into any issues related to space during this process. This location must exist on the standby database server and the Oracle software owner must have full read/write permission on this folder.
Once you have provided the source and destination temporary backup locations, you can click on submit to start the process.

Step 4: An Active task is created for the Synchronize Standby Database task.

Once the task (Synchronize Standby Database) has been submitted, you will notice a new task appearing on the bottom active task list. If you hover over the task with your mouse you will get updates on the progress. You can also click on the task to get a more detailed update view.

Once selected you can specify the DDC, select to start or resume a syncronization process. A short log gap report will be displayed.

Provide a location on the primary [6] and a location on the standby [7] for the backups. Note that the backup process will take longer than the restore/recovery process.

Step 5: Task completion

Once the task is complete, the Active task will have a green checkmark next to it. This indicates a successful completion. If you click on the task you will get a full detail listing.

Once the above process is complete, it is recommended to manually ship an archive log to the standby and then apply it to make sure the primary and standby database is in sync.

You can then follow this by running an archive log gap report to review the status.

12.2. Fix Logical Corruption (No-logging Operations)

Follow the same steps as in the above 12.1 example - an extra option will be listed indicating that no logging operations were detected.

12. Performing a Graceful Switchover

The following steps will show you how you can use the Central Console to perform a Graceful Switchover (GS) - also known as a role reversal.

To perform this step the primary and standby databases must be up to date.

Select the DDC [1] and review the transfer and archive log gap [2] - these must be 0 (can be 1 if using Oracle RAC).

Once the Graceful Switchover task is started, you can review the running task - as can be seen below.

Timing of this process does depend on how big you redo logs are as well as time it takes to transfer at least one redo log and restart both primary and standby database.

Once the Graceful Switchover is complete, you will see an additional task [3] being displayed in the task window. This is just to indicate that after the Graceful Switchover process, we shipped and applied logs to make sure the primary and standby database is in sync.

13. Disaster Recovery Actions (Activation/Failover and DR Tests)

In case disaster strikes, you will want to activate (failover) to the standby database. During this process a resetlogs is performed and the standby database is opened read/write.

The standby database is then converted to a primary database and cannot be used as a standby database anymore.

In version 9 of Dbvisit Standby a number of new options have been introduced in this section. First select "Disaster Recovery Actions" from the main menu [1]

Once you select a DDC on which the operation is to be performed, there are 3 Options are now provided as listed below:

Activate Now
1. Select this option if you want to activate the standby database now - this is usually in the case when disaster happened and you need to activate (failover) to the standby database.
Perform DR Test
1. It is always recommended that sites perform DR testing, activating a standby database and making use if a disaster did happen everything work as expected. This option will allow you to perform a backup of the standby database prior to activating it.
2. Two options will be available:
  1. Create a backup to local disk using RMAN Backupsets
  2. Create a backup to local disk using RMAN Image Copies
    1. This option can be useful to quickly switch back to your image copy instead of running a restore process.
Standby Read Only Test
1. This option allows you to quickly test if your standby database can be opened read-only. This is an excellent test to see if the standby database is in a consistent state. If a standby database is not consistent, you will not be able to open it read-only or activate it. In this case you will have to send and apply more logs before you will be able to activate or open the standby read-only.

The screen capture below shows what the Perform DR Test screen look like:

Select "Perform DR Test"
If you are running this the first time you will need to select "RUN DR TEST" - if you already performed this task, you will be given the option to "REINSTATE" if you have backups (backupset or image copies) available
Confirm if you want to create a backup of the standby database prior to the test - NOTE: if you select NO, you will not have backups unless you create them manually
Select the backup method type - Image Copy or Backupset
Specify the format - this is making use of the RMAN format options - for more detail please see the Oracle RMAN documentation
Specify the location for the backup - this location must have at least enough space to hold a full copy of the standby database.
You can specify the process to stop between the backup and activation stages
Submit to continue

14. Task Management

Tasks are listed in the task panel in the main screen [1] as seen below.

You can also few the task history if you click on "View Task History" [2]

All tasks listed can be selected to display more detail. The above list will also show the "User" which performed the task. If the user is "CLI" it means the task was created from the Command Line Interface (CLI)

15. Troubleshooting - Support Packages

You can create support packages either by selecting the "Create Support Package" option on a task when it is complete,

or you can create a support package by selecting "Create Support Package" from the main screen:

Browser not supported