System Requirements
2.3. Microsoft Windows
Dbvisit Standby version 8.0.x will only support Microsoft Windows 64bit Installations.
Note that Dbvisit Standby uses IPv4 and not IPv6 - if using hostnames in the configurations, you will need to make sure that they resolve to a valid IPv4 address. If not, using the IPv4 IP address should be used.
Important
For Microsoft Windows Platforms the following is recommended:
- User Access Control (UAC) should be turned off when running Dbvisit Standby.
- The Windows Account running Dbvisit Standby 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 Dbvisit Standby 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 2008
- Windows Server 2008 R2
- Windows Server 2012
- Windows Server 2012 R2
- Windows Server 2016
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\
2.4. Solaris
As of Dbvisit Standby version 8.0.18 support is included for Solaris 10 and above.
- Solaris x86_64 10 and above
- Solaris SPARC 10 and above
Notes:
- Solaris based systems please use SSH as network communication, not Dbvnet. Dbvnet is provided with the installation but is considered experimental in this release.
- The Central Console must be installed on a Windows or Linux based system. You will not be able to install it on Solaris.
2.5. AIX
- AIX 5.3 and above
Notes:
- AIX based systems please use SSH as network communication, not Dbvnet. Dbvnet is provided with the installation but is considered experimental in this release.
- The Central Console must be installed on a Windows or Linux based system. You will not be able to install it on AIX.
3. Oracle Database Support
3.1. Supported Oracle Database Editions
Dbvisit Standby 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)
Important
Please note that the primary and standby database server Oracle Editions must match! Having mixed Oracle Database Editions are not supported.
3.2. Supported Oracle Database Versions
The following Oracle Database versions are supported with Dbvisit Standby version 8.0.x:
- Oracle Database 10g (10.2.0.5)
- Supported only from Dbvisit Standby Version 8.0.22.
- Oracle Database 11g
- 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 - excluding Oracle RAC configurations
- Oracle EE - excluding Oracle RAC configuration as well as any specific Enterprise Edition features
- Oracle Database 19c
- Oracle SE2 - excluding Oracle RAC configurations
- Oracle EE - excluding Oracle RAC configuration as well as any specific Enterprise Edition features
Important
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.
Oracle 12c Limitation
The following features are not supported in 12.1 and above of Oracle
- Flex ASM
3.3. Oracle Automatic Storage Management (ASM) Support:
- When installing Dbvisit Standby 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.
Oracle 12c Limitation
The following features are not supported in 12.1 and above of Oracle
- Flex ASM
3.4. 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.
Important:
Dbvisit Standby version 8 had a different implementation for handling Oracle RAC configurations compared to version 7. There are a few important changes you must be aware off before you install version 8 in an Oracle RAC configurations:
- Dbvisit Standby version 8 is designed to run only from one of the nodes in the Oracle RAC cluster. Dbvisit Standby resources (dbvnet, dbvagent, dbvserver and the daemon) can be configured as cluster resources attached to a Virtual IP (which will be running on the node of your choice).
- If this node fails, the Virtual IP used by Dbvisit Standby (used as the SOURCE or DESTINATION value) will fail-over to the second node, from where normal functionality will be available (you must configure the cluster resources - using action scripts) - see Oracle RAC Configurations
- It is recommended that Dbvisit Standby run of Shared Storage - example ACFS or NFS storage that is shared between the RAC nodes. This will allow Dbvisit Standby software to be available to both nodes and in the event that one of the nodes are down, Dbvisit Standby can still run on the other node. If you do not have the option to run on shared storage, you should still make use of a Virtual IP, Install Dbvisit Standby on one of the nodes and then use something like "rsync" to synchronize the folders on a regular basis between the nodes. But it means Dbvisit Standby must still run off only one node, if that node fails, you should start it on the second nodes (the rsynced folder).
- IMPORTANT: If you are upgrading from version 7 to version 8, you MUST create a new DDC, you cannot run the upgrade option on an existing version 7 installation which is using Oracle RAC as the DDC file in version 8 does require some advanced settings to be set which is not available in the version 7 DDC file. So if you are upgrading from version 7 to version 8, we recommend you switch to using shared storage, install Dbvisit Standby version 8 on this storage (you can use a different folder if you already have version 7 installed) you can then configure version 8 - create a new DDC file and once you have everything running, stop the old version 7 schedules and use the new version 8 installation.
- Version 8 does not have the parameters RAC_TAKEOVER or RAC_TAKEOVER_FORCE.
- You cannot upgrade an existing version 7 DDC file, you MUST create a new one
- For creating a new DDC file see the exampled here
- Oracle RAC primary to Single Instance standby - Creating the DDC File#2.5.CreateaDDCFile-OracleRACprimarytoSingleInstanceStandby
- Oracle RAC primary to Oracle RAC standby - Creating the DDC File#2.4.CreatingaDDC-OracleRACprimarytoOracleRACstandby
3.5. General Support Notes
In addition to the above mentioned, Dbvisit Standby version 8 supports the following options:
- Oracle Managed Files (OMF)
- The use of a Fast/Flash Recovery Area (FRA)
- Oracle Database 12c Multitenant Architecture is supported
3.6. Unsupported Configurations
Dbvisit Standby version 8.0.x does not support the following configurations/options:
- Cross-Platform Standby Database configurations
4. Storage Requirements
Dbvisit Standby is installed on all servers forming part of the Standby Database configuration.
The following system requirements are the minimum required for Dbvisit Standby installation:
- 300Mb space for the Dbvisit Standby software installation on the file system - however, 500Mb is recommended.
- Dbvisit Standby is using Archive Logs to update the standby database. There should be sufficient space on the Standby Database server to store the archive logs from the primary database server. It is recommended you have sufficient space to keep at least 1 to 2 days worth of archive logs on disk. Please make sure you cater for peak load periods during which more redo can be generated.
- IMPORTANT: The standby database server will require the same amount of storage capacity as the primary database server.
Dbvisit Standby makes use of a Dbvisit Archive Destination referred to as ARCHDEST (on the standby server) and ARCSOURCE (on the primary server)
This is used to store the archive logs shipped from the primary server to the standby server. This location is NOT the same as the database archivelog destination.
This location should be big enough to keep at least 1 to 2 day's worth of archive logs, but the capacity to store three days or more is recommended.
Example, if you generate 2GB worth of redo (archive logs) on the primary in one day, you should have at least 2GB as an absolute minimum free space on the standby in the folder specified as the ARCHDEST.
If you are using ODA machines, It is required that you create the dbstorages before creating the standby databases using Dbvisit. Please refer the blog for further details.
http://blog.dbvisit.com/configuring-dbvisit-standby-on-an-oda/
5. Network Requirements
Dbvisit Standby supports two methods of communication between the primary and standby database servers:
- Dbvnet (default) and,
- SSH (Recommended for Solaris and AIX and also fully supported for Linux based systems)
- Note that XCOPY has limited support on Windows-based systems
It is important to make sure sufficient bandwidth is available to cater for your required Recovery Point Objective (RPO) as well as the Recovery Time Objective (RTO).
Dbvisit Standby can make use of compression (highly recommended) to ensure more effective use of bandwidth. Compression can be enabled either during network transfer (making use of Dbvnet compression / or SSH compression), or you can enable compression of Archive logs prior to being copied between the primary or standby servers.
It is recommended you test your network to make sure it can handle the required redo generation rate and that you do not have any network throttling such as packet shaping causing undesirable results affecting your RPO/RTO.
IPV6 is not supported. Please, ensure you are using only IPV4 protocol.
6. Browser Requirements
The following browsers are supported when using the Dbvisit Standby Web Based interface:
- Firefox
- Chrome
- Safari
- Internet Explorer 11 + should work, but is not officially supported - it is recommended to use the latest versions of Firefox, Chrome or Safari.
Using the latest versions of the above list of browsers are recommended.
It is important to note that it might be possible that certain browser configurations or add-on installations might limit or restrict the use of the Dbvisit Standby console.
7. Other Notes
Dbvisit Standby is making use of the latest SSL versions.
From 8.0.18 TLS1.2 and above is used.