Dbvisit Standby works with Oracle Cloud.
Dbvisit Standby can be used with the Oracle Database Cloud - Database as a Service - with either the pre-installed or the Virtual Image options.
Dbvisit Standby works with Oracle Cloud.
Dbvisit Standby can be used with the Oracle Database Cloud - Database as a Service - with either the pre-installed or the Virtual Image options.
This can be on-premise to cloud, cloud to cloud, or cloud back to on-premise configurations.
...
Once this has been enabled, you should now be able to bring up the Dbvisit Standby web interface, running on Dbvserver, which appears as below. When using the https option, you may receive a warning about a potentially unsafe connection (depending on your browser), but you can ignore this and proceed:
I mentioned this earlier but worth Worth pointing out again is that this installation process must be performed on BOTH your source and target machines; that is, the software installation and Dbvserver port configuration.
The next step then is to open ports to enable each of the VMs in the configuration to communicate with the other, by adding an entry in the /etc/hosts file. This resolves the internal IP (not the external one) for the machine on the other side to its given name, and will look something like this:
| No Format |
|---|
10.196.243.122 |
...
dbvrep-se-three |
Once added, when you ping the server names they should resolve to the internal IP, although they will not return successful as there are additional ports which are yet to be opened to enable this communication. This is also the case when running the Dbvnet connection test, which is initiated as per the following, run from the (install_location)/dbvisit/dbvnet location:
As mentioned, this result is expected at this time as we have yet to open the Dbvnet communication ports – 7890 by default. The process for doing so follows the pattern we looked at for Dbvserver, and that is first create a new Security Application for this tcp port:
Next, harness this within a new Security Rule on each of the VMs in our configuration; the primary server (dbvrep-se-two) and the standby server (dbvrep-se-three):
Once enabled, you can then run the Dbvnet utility test – from both sides – to check that the communication channel is now open and working. A successful test is as follows, and should complete very quickly:
A final step before creating a new configuration is to create the location (a directory) known as archdest on both servers. This is the location Dbvisit Standby will deliver the archive logs to (from Primary to DR) and retrieve them from on the DR side. Although this location is not technically required on the primary side initially, it pays to create it now as it will be needed should a Graceful Switchover (role reversal) action take place. I create the following, with full permissions to this directory, for the oracle user:
/u03/app/oracle/archdest
So, at this point, we have installed Dbvisit Standby on both of our servers and enabled communication on the required ports. We are now ready to create a new Dbvisit Standby configuration encompassing a primary and DR server pair, and the outcome of this is the production of the DDC file: the Dbvisit Standby Database Configuration file. The key point to make here is that, even though our servers and databases are entirely within the Oracle Cloud environment, the steps from hereon in are standard, and the same as doing this on any other on-premise/cloud/mixed system.
You have a couple of options when it comes to configuring this partnership and creating the standby database. Many users prefer the CLI interface, which is an option we offer, but in this example I will go with the web based interface, as that is perhaps slightly more intuitive for newer users.
I log into the web interface running on the primary server, dbvrep-se-two, with the default password (admin), and then to the Setup menu – option 3 “New Dbvisit Setup”:
In the following 3 short clips, I walk through aspects of configuring this new Dbvisit Standby partnership using the servers we have set up, create a new standby database, and finally run some basic operations with the application.this communication. This is also the case when running the Dbvnet connection test, which is initiated as per the following, run from the (install_location)/dbvisit/dbvnet location:
As mentioned, this result is expected at this time as we have yet to open the Dbvnet communication ports – 7890 by default. The process for doing so follows the pattern we looked at for Dbvserver, and that is first create a new Security Application for this tcp port:
Next, harness this within a new Security Rule on each of the VMs in our configuration; the primary server (dbvrep-se-two) and the standby server (dbvrep-se-three):
Once enabled, you can then run the Dbvnet utility test – from both sides – to check that the communication channel is now open and working. A successful test is as follows, and should complete very quickly:
A final step before creating a new configuration is to create the location (a directory) known as archdest on both servers. This is the location Dbvisit Standby will deliver the archive logs to (from Primary to DR) and retrieve them from on the DR side. Although this location is not technically required on the primary side initially, it pays to create it now as it will be needed should a Graceful Switchover (role reversal) action take place. I create the following, with full permissions to this directory, for the oracle user:
| No Format |
|---|
/u03/app/oracle/archdest |
So, at this point, we have installed Dbvisit Standby on both of our servers and enabled communication on the required ports. We are now ready to create a new Dbvisit Standby configuration encompassing a primary and DR server pair, and the outcome of this is the production of the DDC file: the Dbvisit Standby Database Configuration file. The key point to make here is that, even though our servers and databases are entirely within the Oracle Cloud environment, the steps from hereon in are standard, and the same as doing this on any other on-premise/cloud/mixed system.
You have a couple of options when it comes to configuring this partnership and creating the standby database. Many users prefer the CLI interface, which is an option we offer, but in this example I will go with the web based interface, as that is perhaps slightly more intuitive for newer users.
Below we log into the web interface running on the primary server, dbvrep-se-two, with the default password (admin), and then to the Setup menu – option 3 “New Dbvisit Setup”:
In the following 3 short clips, we walk through aspects of configuring this new Dbvisit Standby partnership using the servers we have set up, create a new standby database, and finally run some basic operations with the application.
Demo 1: Configuration step – setting up the partnership and generating the DDC file
| Widget Connector | ||
|---|---|---|
|
Demo 2: Creating a new standby database
| Widget Connector | ||
|---|---|---|
|
Demo 3: Using Dbvisit Standby to keep your standby database up to date
| Widget Connector | ||
|---|---|---|
|