Dbvisit Standby is built on top of the tried and proven Oracle redo/archive logging mechanism, and provides a complete tool for delivering disaster recovery databases.
A Dbvisit Standby configuration consists of a primary (production) database and one or more standby (backup) databases. The primary and standby databases connect using a secure mechanism (SSH) over TCP/IP, allowing databases to exist anywhere provided they can communicate with one another via TCP/IP.
Once the standby database is available (and Dbvisit Standby includes tools to create this), Dbvisit Standby is scheduled to synchronize the databases by transmitting the archive logs from the primary database and applying them to each of the standby databases.
Oracle archive logs are periodically picked up, optionally compressed, and transferred securely to the standby databases. The frequency of this transmission is determined by configuration, with the processes on the primary and standby sites independently scheduled, providing a high degree of control over when data is extracted and when it is applied.
In the event of communication failure, logs are accumulated at the primary site until Dbvisit Standby determines that the network connection has been re-established. Once this happens, Dbvisit Standby transmits the available updates to the secondary sites in the correct sequence.
Replication monitoring sends alerts when it identifies exceptions outside of the configured acceptable bounds, providing advance warning to operators of a failure or disaster. Once failure of the primary site is identified, a single command on the standby server is all that is required to force it to take over as primary database.
Dbvisit Standby assists with the recovery process, providing tools that enable the creation of new databases from the operational production database. This process is highly automated and can be used to quickly establish new standby databases at one or more sites.
Graceful switchover is used to switch roles, transitioning the production database (operating at the standby site during DR operation) to a standby database and the standby database (newly created at the primary site) to the production database. There is no loss of data during the transition and the standby database does not have to be rebuilt
Maintaining your database and protecting it against failures is an essential part of the DBA's job. Without the right tools it can prove to be the most unproductive part of it too. Because Dbvisit Standby gives you control over your database environment it makes managing it less of a chore and frees up more time to focus on other activities. Additionally, the savings on license costs and maintenance fees are significant (up to 80%), as there is no need to upgrade to Enterprise Edition to utilise Data Guard.