Skip to content
Get a quote

Try Standby

Download a fully-featured free 10-day trial of Standby™ software.

Try Standby for free

Try a fully-featured 10 day trial of the latest version of Standby™ software in your own environment. 

Enterprise-class disaster recovery for Oracle SE that prioritizes database integrity, disaster resiliency, recovery speed, and ease of use. 

Available on-premise, in the cloud, or as a hybrid.


Installing your Standby trial

How does licensing work?

Pricing is per database with a minimum configuration of one primary database, one secondary database and one year of support.


Perpetual licenses and Term licenses are available:


Perpetual licenses -  Purchaser owns and retains the license permanently. Support is an additional cost and support renewal is required each year.


Term licenses -  Purchased for a predefined period (1, 2 or 3 years) and can be extended at any time during the term. Support is included in the price. The flexibility of Term licenses makes them beneficial for computing environments that may change over the next few years or for limited life projects.


Contact us for a quote

Can the trial be extended longer than 10 days?

Yes, we can send you another 10 day trial key to extend the trial to 20 days.

Do we need to reinstall the software or just update the key when we buy the software?

Just update the trial key to the permanent key. 

Can we have primary database as on-premise and standby in the cloud?

Yes, this is possible and the below user guide link talks about this in detail. User guide: example cloud configurations

Is ARCHSOURCE and ARCHDEST the same as Oracle Archive Log destination?

No, it should never be the same. ARCHSOURCE and ARCHDEST variables should contain the same directory on primary and standby server. On the standby server, this directory is used to receive archive logs from the primary. On the primary server, this directory is not used, but when the primary server switches role and becomes the standby, then this directory will be used to receive archive logs from the primary database.

Can archivelogs still be applied when the standby database is in Read Only mode?

When the standby database is in READ ONLY mode, archived logs can be transferred from primary to standby, BUT the archived logs can’t to be applied till the standby database is in managed recovery mode.

Is running the FORCE LOGGING option recommended for the primary and why?

The FORCE LOGGING option is the safest method to ensure all the changes made in the primary database will be captured and available for recovery.

If the number of archives on the primary side is not too big , once you set LOGGING, that signifies a large number of NOLOGGING are being performed on the primary database. The end result is that these operations are not applied to the standby due to no redo information being available for these transactions.

The standby will appear to be up to date, but when these objects are accessed – when standby is open in READ-ONLY mode, roles were changed with the primary or it is activated – you will receive unrecoverable errors.

Our recommendation setting and keeping FORCE LOGGING on primary to protect your standby.

Can we have Oracle Enterprise Edition as primary and Standard Edition for DR and does Standby work with this configuration?

We have done internal testing and StandbyTM works with the above configuration. You need to ensure that you don’t use any Enterprise Edition features in your primary and moreover it defeats the purpose of having a DR which is not exactly matching your primary database. So we strongly recommend against this strategy.

Is it necessary to install Dbvserver in a separate machine?

No, but it is recommend since if you have multiple configurations it would be easier to manage with a single Dbvserver installation and manage all the primary and standby pairs. If you have only single configuration and cannot afford to have a separate machine, you could still install the Dbvserver in standby machine thereby in case of a true DR scenario the central console GUI is still available and you can use it to activate.

How is the RPO and RTO impacted when deploying Standby?

When scheduling StandbyTM there are a few key factors to consider

such as the Recovery Time Objective (RTO) and Recovery Point Objective (RPO) of your environment. This is a business decision, but certain factors play a key role.

These are:

  • Speed of the network

  • Activity on the database

  • Speed of the disks

  • Compression method chosen and CPU power to compress and uncompress archive log files.

The schedules can be customized based on requirements. There is continuous monitoring which can set up to get notified for any delay. The daemon process automatically detects the archivelog in the primary and forces a logswitch in primary when it does not see a new archivelog for a certain period, by doing this it makes sure that the delay between primary and standby are minimum.

Find a local partner

We work with partners around the world to give you the best advice and world-class local support.

Mask Group 59
Mask Group 184-1
Mask Group 209-1

Standby Suite 8

Overview of Standby 8. Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

Group 781
Group 528

Let’s talk

Find out about our continuous database protection for yourself and see how you can keep your world in motion.