The new version of Dbvisit Standby is released, so I will take this cause to describe the “Smart Alternative” in detail. Of course this release will bring us also new features. Now we do not only create a standby database with some clicks by minutes. With the new version we can define an exact point in time, which our standby database shall reflect. Altogether the DBA gets a simple opportunity to provide reporting and testing databases. In the next lines I will give an overview how you can create a new database composed of your existing data within 10 minutes. The rest is up to your amount of data.
Of course there must be made some preparations in the form of installation and configuration. But when you’re familiar with Dbivsit, it will make the administration tasks much easier. Now some specialists will say “All that is also running with Oracle own board resources…” most of all RMAN is to mention here “… I can do it all by myself.” And actually Dbvisit uses available Oracle built-in features. But this is not the point. You can be sure that Oracle knows the insides of his own product the best. What Dbvisit does is that it facilitates the DBA’s work. Another point is that Dbvisit Standby is an alternative for Oracle Data Guard, not only under cost aspects. Not every DBA has an Enterprise Edition with Data Guard Option, but every DBA has to ensure that the database is backed. Concerning this aspect Dbvisit offers also a version for the Standard Editions.
The installation of Dbvisit Standby 7.0 is really easy and self-explaining so I can leave it in your hand. What I present is the Windows variation with 11gR2 database, but the Linux-Version do only differ in minimal OS specific oddities. The only important fact is that you have to do as much as possible identically on the source server as on the target server. What I mean is mainly the Oracle-RDBMS installation, the mounted drives, the availability of the particular Oracle destinations and in case of the Dbvisit installation the installation directories. In opposite to the old releases we can realize a really good improvement on the installation process. Now Dbvisit built-in its own network service. Configuration problems with WinSSHD are history. No more problems with that, so please forget that as fast as you can.
Next to the main Standby program Dbvisit comes with its own webserver. A web based user interface is realized with that. This web interface is accessible around the network and brings you every functionality in a click friendly way. I recommend the Mozilla Firefox for an effective usage. I tested it and Firefox won the challenge in point of speed and illustration. The web interface is by default accessible by http://hostname:8081 after installation. Everybody who don’t like clicking and prefer the old school method can choose the Dbvisit command console. Advantage is, that the connection will never interfere, but I don’t know any other implicit arguments for using the console. To each what he deserves.
The choise is yours.
So far so good. If everything is installed, we can configure, given that we have an Oracle database in Archive-Log-Mode on the source side and an appropriate Oracle RDBMS on the target side. But before we can start to create a standby we have to create a configuration. This configuration will be saved in a configuration file called DDC. If you want it’s possible to edit this file directly later on, don’t going the way over the interface. For the first time I recommend the easiest way by using the web interface with Setup > New Dbvisit Setup. Everything else is demanded through all necessary and really understandingly inputs. Explanations will be given directly. The capabilities of configuration is enormous and should fulfil everybody’s wishes. We can set up all details, in addition RAC is supported. We can define the mail setting in case of alerting and define the archive log file management right down to the last detail. There should be no question unanswered with the necessary database know how which only could be answered by testing. In doubt you can find an extensive Administration Guide on the Dbvisit website or you can ask me.
If you passed the seven steps and the configuration is successfully created you can continue with the creation of the standby database. That is much faster done than the configuration, but these had to be done for one source database only one time, maybe some adjustments. The standby creation can also be done convenient with the web interface over Setup > Create Standby Database. Dbivist takes over work in the background. Here you have the decision to compress your data for the transfer or you can send them to an external device firstly and load them separately, for not stressing your network. Finally you can adjust the parameter file for your needs in all aspects, for example change file destinations, NLS parameters or what else. The rest takes Dbvisit and builds you a fully functional standby database until the mount.
What we need to do now is to define how often our standby and our production shall be synchronized. For that we need to know how Dbvisit works in this point. First Dbvisit creates own, compressed archive logs from the given (archived) redo-log information (that’s why the Archive-Log-Mode) these logs will be simply sent to the target server across the network. On the target server they will be decompressed and loaded – applied. Altogether we get a TRANSFER process on the source side and a APPLY process on the target side. According to the frequency we transfer or apply or both together we stress the network and the database more or less intensive. The most common recommendation you can read in the context of Oracle standby database, speaks of a time range of 15 minutes. This regards not only Dbvisit. By that you will have a data loss of 15 minutes in case of a disaster. On the other hand you will not have any trouble and the production will run performant when there are queue up some days without disaster. If that is not enough you can test your environment with 10 or even 5 minutes or you can look for another high availability solution. The configuration for that you can find under Run > Set Schedules.
So, that’s it, or not? Of course we forgot a really important aspect. The Gracceful Switchover or in worst case the Failover. Dbvisit is handling with that absolutely reliable too. The only condition is that you worked accurate at the installation and configuration and established your Standby as a one-to-one copy (not only for the worst case). By given that you can keep up production during maintenance on the primary server or at the datacentre in general. The switchover can also be done with the web interface. Secured by a unique key which has to be entered both on the source and target side. The rest is up to Dbvisit. After some minutes you can enable productive access to your previously standby. That’s not a one-way, so you can always switch back. Nevertheless I recommend to test the whole process to get familiar with the matter. For the worst case, what means your production isn’t accessible anymore or didn’t exists for whatever reason, you can transform your PHYSICAL STANDBY into a PRIMARY, over web interface. The show must go on.
Finally Dbvisit offers some really nice visualised reportings about our standby configuration, plus transfer and sync status.
Access to log files is also granted over web interface.
