1. Dbvisit StandbyMP Concept
Dbvisit StandbyMP 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 provides user with no less than four user interfaces for interaction:
dbvcli (command line tool)
dbvctl (Oracle database platform specific command line tool)
API
Webserver GUI (provided by dbvcontrol)
Dbvisit uses very similar concept for standby database synchronization for Oracle, SQL Server and Postgres.
Oracle concept:
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:
.png?version=1&modificationDate=1738155203488&cacheVersion=1&api=v2&width=602&height=227)
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:
.png?version=1&modificationDate=1738155629130&cacheVersion=1&api=v2&width=580&height=226)
Dbvisit StandbyMP 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 StandbyMP, there’s no requirement for shared storage between primary and standby server. This goes for all three database platforms.
2. Dbvisit StandbyMP Components
Dbvisit StandbyMP 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 StandbyMP:
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. Considerations for users running Dbvisit Standby version 11
Dbvisit StandbyMP Version 12 shares the same code base with version 11 and if you are on version 11, there’s no immediate need for you to upgrade to version 12. Version 11 will remain supported for sufficient amount of time in the future. More details on:
https://support.dbvisit.com/hc/en-us/articles/8117254640911-Dbvisit-Standby-Version-Support-Matrix
The notable differences from version 11 and reasons for upgrade to version 12 are :
version 12 contains public API API which help users with integrating the product with existing monitoring systems or deployment flows
version 12 contains new command line interface CLI which enables users to perform complete configuration and deployment without need of interaction with GUI.
It is still needed and necessary to install and maintain dbvcontrol as it is integral part of NATS messaging system which is necessary for proper functionality of the product
version 12 will be prioritized for receiving new features and updates over version 11
4. Considerations for users running Dbvisit Standby versions 8,9 or 10
Advantages of upgrading and using Dbvisit Standby version 12
There are several very good reasons and factors which make going to version 11 benefical:
Version 12 has more mature concept than versions 8,9 or 10. It uses advanced NATS messaging system which results in much faster and hassle free task processing on database servers. The specific issue with 8,9 and 10 verions had was the task visibility / updating in the dbvserver GUI
StandbyMP has only two OS components: dbvagentmanager and dbvcontrol. You no longer need to manage separatedly dbvnet, dbvagent, daemon and dbvserver. In addition, both Version 12 components are easily integrated with Linux systemctl.
The Observer component is integrated with the control center and automatically enabled once the standby database is created. Observer component must have been separately installed and managed on V9 and V10.
The new custom script execution option can run host scripts after switchover and failover. This option enables customers to run their scripts for validation or to perform other actions.
The email notifications are centralized on the GUI. The global email settings have to be done only once. Custom email id’s can be enabled for individual configurations directly from GUI. Version 12 also has the option for slack notifications.
Simplified and improved webserver UI including better flow of various processes such as create standby database. The UI requires some time getting used to, but the learning curve is very comfortable. The GUI provides a single pane of glass view instead of having to move to different option in different pages.
Supports Microsoft SQL Server and PostgreSQL DR
Older Dbvisit Standby versions will receive only critical updates while version 12 will receive new features and improvements as well.
Compatibility Considerations when upgrading from older versions 8,9 and 10
In general, if you’re on any old version (8,9 or 10) you will be able to upgrade to version 12 without any issues. But there are few things which you should be aware of when upgrading to version 12:
Using SSH for standby database synchronization isn’t supported in version 12
You’ll find out if you’re using SSH for synchronization by looking at your DDC file on primary (/usr/dbvisit/standby/conf/dbv_prod.env) and checking your NETPORT parameter:
NETPORT = 22
If your NETPORT is 22, it means you’re using SSH and you won’t be able to use SSH synchronization with version 12. Please contact Dbvisit support if this is your case, because usually it’s no problem to use default version 12 synchronization method instead of SSH
You’re using legacy OS versions or you’re on AIX/Solaris platform
V12 doesn’t support certain old OS versions, please check following page to determine compatibility with your environment:
Operating System and Cloud Support
In addition to legacy OS versions, AIX and Solaris platforms are not supported by Dbvisit Standby Version 12.
You’re not using dbvserver webserver component (and you don’t want to)
Version 12 is built around the dbvcontrol webserver component, which is necessary for NATS communication. Verions 8,9 and 10 had webserver (called dbvserver) as an optional installation component.
Dbvcontrol webserver in Version 12 is however not optional component and must be installed even though you intend to use command line interface only. In general there’s no reason to not install dbvcontrol webserver, but if you have strict requirement about this and can’t install dbvcontrol for whatever reason, then you can’t use Version 12.
Version 12 uses a bit different ports than older versions
Please check following page to see the required open ports:
If you have firewall in your environment active, you will need to change the rules before upgrading to Version 12.
Version 12 requires slightly more disk space than older versions
There are bit more tracefiles and metadata repositories, so we recommend to reserve 15GB of space.
Crontab job synchronization isn’t supported by Version 12
Synchronization of standby database is fully managed by dbvagentmager process in Version 12. The interval is of course fully customizable.
5. Frequently Asked Questions
Is upgrade to version 12 free of charge?
Yes, as long as you have active Dbvisit Support Contract downloading and using of any new versions is included with for no added cost
Can I use my old license key for version 12?
No, you can’t. You will need to contact Dbvisit support and request new version 12 license key:
https://support.dbvisit.com/hc/en-us/articles/360000362775-How-to-create-a-support-ticket
Please include following output from your primary database:
SQL> sho parameter db_name
How to perform an upgrade?
Upgrade is described in our online documentation:
<<<< TBD >>>>
Where do I download the version 12 Installation files?
From our public webpage:
I just need to quickly re-install my Dbvisit Standby old version from the scratch, why should I bother with installing version 12 instead?
To perform any reinstallation of old Dbvisit version means lot of effort and there’s always risk of bumping into an issue or a known bug which is resolved in version 12. Some issues are resolved only in version 12 (fix is not available in versions 8,9,10 or 11).
The older version you run on may also retire very soon and won’t be supported any longer:
https://support.dbvisit.com/hc/en-us/articles/8117254640911-Dbvisit-Standby-Version-Support-Matrix
Installing newest version will save you a LOT of effort for the future and unless you have exceptionally good reason for staying on an old version, you should always go for installation of version 11.
We’re never trying to force anybody to go to new version, we just know from first-hand experience that it saves a lot problems for the future!
When will version 12 be supported on AIX and Solaris?
Unfortunately at point such support isn’t on the product roadmap. For Solaris and AIX, you’ll need to use version 9.