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 10. 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:
Important information regarding communication:
The following browsers are supported when using the Dbvisit Standby Web-Based interface (latest versions recommended)
|
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: |
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 | |-- ca.pem | |-- cert.pem | |-- dbvserver-stat.db | |-- dbvserver-stat.db.20201127112531 | |-- dbvserver.conf | |-- dbvserver.db | |-- dbvserver.db.20201127112530 | |-- dbvserver.pid | `-- prikey.pem |-- dbvserver |-- doc | |-- README.CONFIG.txt | `-- README.txt |-- log | `-- dbvserver.log `-- www 5 directories, 13 files |
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 www [oracle@dbv3 dbvserver]$ ./dbvserver -d start Dbvserver daemon started. [oracle@dbv3 dbvserver]$ ps -ef |grep dbvserver |grep -v grep oracle 91 1 2 01:34 ? 00:00:00 ./dbvserver -d start [oracle@dbv3 dbvserver]$ |
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]$ ./dbvserver -d stop Stop signal has been sent to pid: 56 |
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.
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 11 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:
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
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.
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.
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:
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.
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.
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
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
2. Select if ASM to be used?
3. ARCHDEST location
4. Dbvisit Standby base directory on the destination (standby) server
5. Oracle Home directory on the destination (standby) servers
6. The standby database unique name (DB_UNIQUE_NAME)
7. The new configuration (DDC) name to be used
8. Adding a valid License Key
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.
Please see this section for more detail: Creating the DDC File#2.5.CreateaDDCFile-OracleRACprimarytoSingleInstanceStandby
Please see this section for a detailed example: Oracle RAC Configurations#OracleRACConfigurations-5.CreatetheDbvisitStandbyDDCFile
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.
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.
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:
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 the grey background cannot be altered [2].
Following the parameter table are several Options:
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.
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:
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].
Tasks can be initiated either through the GUI or from the CLI. If a Task is started from the 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 that 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. |
A Task can be in one of four states:
You can interact with any Task in two ways:
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.
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:
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.
The Log Gap Report allows you to quickly see at a glance the time difference and log gap between the Source and Destination Hosts.
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. 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].
Clicking the button [1] starts the process. 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].
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.
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].
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].
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.
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].
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.
This action allows you to re-send a single archive log file, most frequently use 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.
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:
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 synchronization 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 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.
Follow the same steps as in the above 12.1 example - an extra option will be listed indicating that no logging operations were detected.
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). Observe monitoring must be disabled before proceeding [ 3 ]. All the read replicas and snapshots must be removed before GS can be started [ 4 ].
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 your redo logs are as well as the 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.
In case of 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 10 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:
The screen capture below shows what the Perform DR Test screen looks like:
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)
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: