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 cloud configuration consists of a primary (production) database, either on-premise or in the cloud, and one or more standby (backup) databases on AWS. 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.
