1. Introduction

This page will provide you with more detail on the system requirements for Running Dbvisit Standby MultiPlatform.

This includes Operating System (OS) support as well as the Oracle Database version support matrix.

2. Dbvisit Standby Software Requirements

2.1. Storage Requirements

Dbvisit Standby is installed on all servers forming part of the Standby Database configuration.

5GB space for the Dbvisit Standby software installation on the file system - however, 15GB is recommended especially for multiple configurations and because of tracefiles.

On Linux, if you have dedicated mount for /tmp, make sure it is NOT mounted with “noexec” option. This can be verified with for example “mount -l” command.

IMPORTANT: The standby database server will require the same amount of storage capacity as the primary database server for standby database creation

2.2. CPU and Memory Requirements

Requirements are cummulative, so if you place dbvcontrol component on standby server together with dbvagentmanager, you need to sum the memory and CPU amount.

Primary Server:

Dbvagentmanager component on primary server requires minimum 1 CPU thread and minimum 1 GB of memory per primary database from which Dbvisit transfers archivelogs.

Standby Server:

Dbvagentmanager component on standby server requires minimum 1 CPU thread and minimum 1 GB of memory per standby database

Dbvcontrol Server:

Dbvcontrol (central webserver console) can be installed on separated Linux or Windows host regardless of database servers OS platform.

The dbvcontrol requirements scale with the total count of primary and standby databases:

Total Database Count	CPU Threads	Memory (GB)
2	2	2
up to 4	2	4
up to 8	4	8
up to 12	6	10

The memory consumption of dbvagentmanager and dbvcontrol entirely depends on dbvisit repository sizes. If you find the memory consupmtion above the recommended values, it’s recommended to check the repository size and purge the repositories.

To do this, on primary and standby servers check directory DBVISIT_BASE/standbymp/db and if it exceeds 500MB, reset dbvagentmanager repository on “task & events” level as described here:Reset Repository.

2.3. Network Requirements

Dbvisit Standby Multiplatform has two components: dbvagentmanager and dbvcontrol (Control Center). While dbvagentmanager must be deployed on each primary and standby server, there should be only one dbvcontrol component per whole environment. It is supported to deploy dbvcontrol on primary server or on standby server but never to both at the same time.

It is also supported to use separated host from primary or standby for dbvcontrol. This host can have independent OS Platform in relation to primary and standby server.

Dbvisit Standby Version 11 components use following ports:

DbvagentManager File transfer Port

Listens on 7890 TCP - Archivelog transfer to Standby database

ControlCenter Ports

Listens on 4433 TCP - Webserver for user access via browser

Listens on 5533 TCP - communication from dbvagentmanger

Deploying dbvcontrol on separate server

When using separate server for dbvcontrol, the firewall rules need to be allowed as per this picture:

Host	Port to whitelist	Source
ControlCenter host	5533	All primary and standby servers
ControlCenter host	4433	All administrator workstations
Primary host	7890	Standby host, Dbvcontrol host
Standby host	7890	Primary host, Dbvcontrol host

Deploying dbvcontrol on standby server

When standby server for dbvcontrol, the firewall rules need to be allowed as per this picture:

Host	Port to whitelist	Source
Standby host	5533	Primary server
Standby host	4433	All administrator workstations
Primary host	7890	Standby host
Standby host	7890	Primary host

2.3. Browser Requirements

For ControlCenter access, Dbvisit version 11 supports Chrome, Firefox, and Edge browsers.

3. Supported Operating Systems

This section will cover the supported Operating Systems for Dbvisit Standby MultiPlatform.

3.2. Linux

Dbvisit Standby MultiPlatform will only support 64bit Linux Installations.

The following Linux Distributions are supported (x86_64 / 64bit):

Supported Linux Distributions
Oracle Linux 6 Oracle Linux 7 Oracle Linux 8 Oracle Linux 9 Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Red Hat Enterprise Linux 8 Red Hat Enterprise Linux 9 SUSE Linux Enterprise Server 11 SUSE Linux Enterprise Server 12 SUSE Linux Enterprise Server 15

3.3. Microsoft Windows

Dbvisit Standby MultiPlatform will only support Microsoft Windows 64bit Installations.

Note that Dbvisit Standby MultiPlatform uses IPv4 and not IPv6. By default, during installation, the dbvagentmanager and dbvcontrol will list the IP addresses that it will listen on and also will also display the resolvable hostname for the control center.

For Microsoft Windows Platforms the following is recommended:

User Access Control (UAC) should be turned off when running Dbvisit Standby.
The Windows Account running Standby Multiplatform should be a Local or Domain account with the following group membership:
- ORA_DBA
- Local Administrators
- Oracle Home DBA group - (if using 12c make sure the user is in the new Oracle Home DBA group)

Please make sure you test Standby Multiplatform in your Development or Test environment prior to implementation into production to ensure Virus Software, Firewall, UAC and Group policies do not affect the normal operation of Dbvisit Standby.

The following Microsoft Windows versions (64bit) are supported (Base release including Service Packs are supported):

Windows Server 2012
Windows Server 2012 R2
Windows Server 2016
Windows Server 2019
Windows Server 2022

When using Windows-based systems, it is recommended not to make use of the Uniform Naming Convention (UNC) paths - example: \\server\share_name

But to make use of local filesystem naming example: c:\folder_name\

4. Oracle Database Support

4.1. Supported Oracle Database Editions

Standby MultiPlatform supports the following Oracle Editions:

Oracle Database Standard Edition (SE)
Oracle Database Standard Edition One (SE1)
Oracle Database Standard Edition 2 (SE2)
Oracle Database Enterprise Edition (EE)
Oracle Database Express Edition (XE)

Please note that the primary and standby database server Oracle Editions must match!

Having mixed Oracle Database Editions are not supported.

4.2. Supported Oracle Database Versions

The following Oracle Database versions are supported with Standby MultiPlatform:

Oracle Database 10g (10.2.0.5)
Oracle Database 11g
- 11.1.0.7
- 11.2.0.1 is the base version supported
- Oracle 11.2.0.4 and above patch level recommended
- 11.2.0.1 was released Sep 2009
- 11.2.0.4 was released Aug 2013
Oracle Database 12c
- Oracle SE/SE1 up to 12.1.0.1
- Oracle SE2 and EE 12.1.0.2 and above
- 12.1.0.1 was released June 2013
- 12.1.0.2 EE was released July 2014
- 12.1.0.2 SE2 was released Sep 2015
- Oracle SE2 and EE 12.2 is supported from Dbvisit Standby 8.0.12
- 12.2.0.1 was released May 2017
Oracle Database 18c
- Oracle SE2 (including Oracle RAC configurations starting from v9.0.04+)
- Oracle EE - excluding Oracle RAC configuration as well as any specific Enterprise Edition features
Oracle Database 19c
- Oracle SE2
- Oracle EE - excluding Oracle RAC configuration as well as any specific Enterprise Edition features
Oracle Database 21c
- Oracle SE2
- Oracle EE - excluding Oracle RAC configuration as well as any specific Enterprise Edition features
Oracle Database 23ai
- Oracle SE2

The Oracle Database software version between primary and standby servers must match.

Having different versions such as patch levels are not supported and can cause unexpected results if Graceful Switchover (GS) or Activation/Failover is attempted.

The following features are not supported:

Flex ASM in Oracle version 12.1 and above
ASM mirroring syntax for standby init parameters (e.g. db_create_file_dest=+DATA(FG$FILEGROUP_TEMPLATE_MIRROR) )

4.3. Oracle Supported Cloud and Hybrid Deployments

Below is replication support Matrix for deploying Dbvisit Standby product on Cloud, on-premise and hybrid environments.

Dbvisit Standby always requires underlying operating system, which is the reason why AWS RDS and OCI Autonomous Databases are not supported.

Source/Target	AWS EC2	AWS RDS	AWS RDS Custom	OCI DBS (Oracle RDBMS only)	OCI Compute	OCI Autonomous	Azure VM	On-Prem
On-Prem	Supported	Not Supported	Not Supported	Partially Supported*	Supported	Not Supported	Supported	Supported
AWS EC2	Supported	Not Supported	Not Supported	Partially Supported*	Supported	Not Supported	Supported	Supported
AWS RDS	Not Supported	Not Supported	Not Supported	Not Supported	Not Supported	Not Supported	Not Supported	Not Supported
AWS RDS Custom	Not Supported	Not Supported	Supported	Not Supported	Not Supported	Not Supported	Not Supported	Not Supported
OCI DBS (Oracle RDBMS only)	Partially Supported*	Not Supported	Not Supported	Supported	Partially Supported*	Not Supported	Partially Supported*	Partially Supported*
OCI Compute	Supported	Not Supported	Not Supported	Partially Supported*	Supported	Not Supported	Supported	Supported
OCI Autonomous	Not Supported	Not Supported	Not Supported	Not Supported	Not Supported	Not Supported	Not Supported	Not Supported
Azure VM	Supported	Not Supported	Not Supported	Partially Supported*	Supported	Not Supported	Supported	Supported
On-Prem	Supported	Not Supported	Not Supported	Partially Supported*	Supported	Not Supported	Supported	Supported

*Oracle enforces Advanced Security option for OCI DBS systems. Advanced Security option is Enterprise Edition feature only, making it impossible to run synchronization when Source is OCI DBS and target is On-prem Standard Edition 2 database.

4.4. Oracle Automatic Storage Management (ASM) Support:

When installing Standby Multiplatform on an environment using ASM for database storage, Oracle Grid Infrastructure version 11.2 and higher is recommended.
Recommended 11g version to use 11.2.0.4 including the latest patch updates.
Recommended 12c version 12.1.0.2 and above, including latest patch updates.
Dbvisit Standby supports database storage on ACFS on Linux platform for all OS combinations certified by Oracle

4.5. Support for Advanced Configurations - Oracle RAC

The following advanced configurations are supported:

Oracle Real Application Cluster (RAC) 11g
Oracle Real Application Cluster (RAC) 12c
Oracle Fail-Safe

If using Oracle RAC configurations, using the latest patch sets are highly recommended.

4.6. General Support Notes

In addition to the above mentioned, Standby MultiPlatform supports the following options:

Oracle Managed Files (OMF)
The use of a Fast/Flash Recovery Area (FRA)
Oracle Database 12c Multitenant Architecture is supported

4.7. Unsupported Configurations

Standby Multiplatform does not support the following configurations/options:

Cross-Platform Standby Database configurations

5. Microsoft SQL Server Supported versions.

Standby MultiPlatform supports SQLServer from version SQL Server 2012 to the latest version of SQL Server 2022. Below are the editions supported by Standby MultiPlatform.

Enterprise Edition
Standard Edition
Web Edition
Personal Edition
Express Edition

6. PostgreSQL Requirements

The supported versions of PostgreSQL are from versions 10 to 16. Supported Linux platforms are

The Red Hat family of distributions includes:

Red Hat Enterprise Linux (6,7,8,9)
Rocky Linux (8 and 9 only)
CentOS (7 and 6 only)
Fedora
Oracle Linux (6,7,8,9)

The Debian family of Linux distributions includes:

Ubuntu

The Windows-supported versions include

PostgreSQL Version	64-Bit Windows Platforms
16	2022, 2019
15	2019, 2016
14	2019, 2016
13	2019, 2016
12	2019, 2016, 2012 R2
11	2019, 2016, 2012 R2
10	2016, 2012 R2 & R1

6.1 PostgreSQL Pre-requisites

For Linux below are the basic pre-requisites

Dbvisit must be installed as the same user as the Postgresql installed user.
The permissions for the data directory tablespace directories and configuration file directories on the standby must be pre-created and adhere to permission policies of PostgreSQL (drwx------. 0700 or drwxr-x---. 0750)
The primary Postgres cluster must be up and running.
The Postgres port must be open on the standby site.

For Windows below are the basic pre-requisites

The agent service user must have permission to manage Windows services, typically a member of the Administrators group. The default “LocalSystem” user has such permissions. These permissions are required for:
- CSD:
  - Restarts the service for the primary cluster
  - Creates and starts the service for the standby cluster
- Switchover:
  - Restarts the service for the old primary cluster
The agent service user must have permission to read and write to the cluster’s data and configuration directories in order to:
- Read and edit configuration files
- Read the WAL archive files
The PostgreSQL service user must have permission to execute the dbvpgarchive.exe and dbvpgrestore.exe executables in the StandbyMP bin directory.
- This is only required if using archiving mode.
- PostgreSQL runs dbvpgarchive.exe on the primary to transfer WAL files to the standby and dbvpgrestore.exe on the standby to move the copied archives to the correct directory.
- The default permissions on these executables should allow any account in the Users or Administrators groups to execute them.
The PostgreSQL service user and the agent service user must have permission to read and write to the backup locations for any configurations involving the cluster. This is either the default backup location configured during installation, defaulting to C:\Program Files\Dbvisit\standbymp\backup, the base backup location specified during CSD, or the custom backup location specified during CSD.
- The agent installer grants access to Everyone to the default backup location.

The StandbyMP agent installer defaults to running the service as the “LocalSystem” user, granting the service permission to do everything it needs to.

The PostgreSQL installer creates a cluster that runs as the “NetworkService” user, which pretty much just has access to read and write the cluster data and access the network.

When StandbyMP creates the service for the standby cluster, it runs it as “LocalSystem”, so that it has access to everything. A future enhancement will allow the user to specify which user they want it to run as, but for now it is hard-coded to “LocalSystem”.

The StandbyMP installer grants access to Everybody to the default backup location.

If everything is left as defaults, the permissions are expected to work.

We're here to help!

System Requirements