System Requirements

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)

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 Version 11 uses 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

The firewall rules need to be allowed as per this picture:

image-20240227-171758.png

 

Host

Port to whitelist

Source

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

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

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.

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

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)

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

 

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

OCI DBS (Oracle RDBMS only)

OCI Compute

OCI Autonomous

Azure VM

On-Prem

On-Prem

Supported

Not Supported

Partially Supported*

Supported

Not Supported

Supported

Supported

AWS EC2

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

OCI DBS (Oracle RDBMS only)

Partially Supported*

Not Supported

Supported

Partially Supported*

Not Supported

Partially Supported*

Partially Supported*

OCI Compute

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

Azure VM

Supported

Not Supported

Partially Supported*

Supported

Not Supported

Supported

Supported

On-Prem

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

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

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.