Introduction

1. Dbvisit Standby Concept

Dbvisit Standby product manages the complete lifecycle (standby database creation, synchronization, activation and more) of standby database for Oracle, SQL Server and Postgres database platforms with RPO and RTO measured in minutes.

Dbvisit uses very similar concept for standby database synchronization for Oracle, SQL Server and Postgres.

Oracle concept:

Demo_Transfer.drawio.png

Oracle Standby database is always in MOUNT status during synchroniation. It can be opened READ-ONLY, but in this state, apply of archivedlogs is paused

SQL Server concept:

Similar to Oracle, SQL Server Standby database is always in RESTORING status during synchroniation. It can be opened READ-ONLY, but in this state, apply of archivedlogs is paused

Postgres Streaming concept:

Dbvisit Standby allows to create Postgres Standby cluster in HOT mode (read-only access is possible during synchronization) or WARM mode (read-only access can’t be obtained).

For postgres platform, Dbvisit offers also support for WAL shipping replication mode.

For Dbvisit Standby, there’s no requirement for shared storage between primary and standby server. This goes for all three database platforms.

2. Dbvisit Standby Components

Dbvisit Standby must be installed directly on primary and standby database servers, it’s not possible to deploy it to environment without direct operating system access.

There are two main components for Dbvisit Standby MultiPlatform:

dbvagentmanager

(Dbvisit Agent)

This component should be installed once on each database server. The Dbvisit Agent is responsible for connecting to the Oracle and/or SQL Server databases, and communicating with the Dbvisit Control Center.

dbvcontrol

(Dbvisit Control center/GUI)

This component should be installed once only, ideally on a 3rd server separate from either the primary or standby database server. It is also possible to install this on the standby server. The Dbvisit Control Center contains the communication hub, logic center, the user interface, and the Observer. In simple terms, the Control Center is the brains behind the operation - it is through the Control Center that you will interact with the product the vast majority of the time.

Example architecture with 2 primary and 2 standby database servers with separate host for dbvcontrol:

It is important to note that the user running Dbvisit components on Unix-based systems MUST be the same user used to install and run the Oracle/SQLServer Database software. But, the services are stopped and started using the root user.
On Windows-based systems, the installation user for Dbvisit components does not have to be the same user as the Oracle Home Owner, but MUST be in the ORA_DBA and Local Administrators group with "Log on as a service" permission.

Dbvisit installation is very small (~ 500MB), but we require and recommend to have at least 10GB of free space per server for tracefiles and Dbvisit internal repositories.

3. Using Dbvisit Standby

After the installation of the Dbvisit Standby MultiPlatform, you will be able to use four user interfaces:

dbvcli (command line tool)
dbvctl (Oracle database platform specific command line tool)
API
Webserver GUI (provided by dbvcontrol)

Each installation and deployment of Dbvisit by default and always contains all four methods. You’ll be free to switch among using all four interfaces after installation freely.