||10g to 12c
Standard (including Oracle RAC)
Standard Two (including Oracle RAC)
||Oracle flash recovery area
ASM file systems
||Windows: 2003 – 2016
Linux: Intel & AMD
Unix: AIX; Solaris (x86_64 and SPARC)
- Identical database management system and operating system versions on production and standby system.
- Similar storage capacity on production and standby system.
How It works
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 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 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 to a standby database and the standby database to the production database. There is no loss of data during the transition and the standby database does not have to be rebuilt. The Graceful Switchover (GS) step is performed in a controlled manner.
Maintaining your database, protecting it against failures and ensuring business continuity 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.