Having a data recovery strategy in place is critical to ensuring business continuity in the event of an outage or disaster. When developing a data recovery strategy, it is essential to take into consideration the different licensing rules when deploying backups, failover (active/passive), and high-availability (active/active) scenarios.
Many of our customers remain confused regarding the licensing requirements for Oracle data recovery environments. As a result, this could cause the organization to be out-of-compliance and fail an audit. Therefore, it is important to understand these differences as there are specific occasions when Oracle licensed customers do not have to purchase licenses for every server/node.
The following are common misconceptions our customers have encountered in regard to licensing Oracle data recovery environments:
1. Nightly Backup
Oracle customer copies/stores a nightly backup copy of the production database data to the test/development server not knowing that from an Oracle licensing perspective, this would be interpreted as a standby configuration and therefore the licensing metric (including options and management packs) for this server must match the associated production server.
2. Unlimited Testing and Validation
Oracle customer believes that the testing and validation of database backups is unlimited and has no restrictions; however, from an Oracle licensing perspective, customers are allowed to restore the database to an unlicensed server (for the purpose of testing the physical copies of the backups) up to four times, not exceeding two days per test, in a given calendar year.
3. Monthly Maintenance
Oracle customer has an accepted failover configuration and brings down the production server once a month for maintenance not knowing that from an Oracle licensing perspective, downtime for maintenance purposes counts towards the ten-day policy for failover and therefore must be fully licensed.
4. Standby vs. Production Licensing Metrics
Oracle customer has different licensing metrics applied to their standby server than their corresponding production server; however, in terms of licensing, Oracle requires that customers apply the same metric to both production and standby servers (including options and management packs).
5. Data and Binaries on a Single Array
Oracle customer copies/stores a backup copy of the database data on a disk array that also includes Oracle binaries, which has access to the same data; however, from an Oracle licensing perspective, this would be interpreted as a standby configuration and therefore must be fully licensed. Additionally, the licensing metric (including options and management packs) for this server must match the associated production server.
6. Failover Definition
Oracle customer configures what they believe is a “failover” environment based on the vendor’s technical whitepaper; however, the term “failover” is a general industry term that is often used to describe a solution that is considered a standby configuration according to Oracle Data Recovery Methods.
7. Real Application Clusters (RAC) Configuration
Oracle customer believes that one of the servers/nodes in a Real Application Clusters (RAC) configuration can be considered as failover (active/passive) server/node; however, from an Oracle licensing perspective, an Oracle RAC environment is considered high-availability (active/active) and therefore all servers/nodes must be licensed.
8. Failover Limitations per Cluster
Oracle customer has a failover configuration with multiple failover servers accessing a single storage array; however, from an Oracle licensing perspective, only one failover server in the cluster can be unlicensed.
9. Multiple Storage Arrays
Oracle customer has a failover configuration with two servers accessing different storage arrays; however, from an Oracle licensing perspective, this would be considered a remote mirroring configuration and therefore both servers must be fully licensed. Additionally, the same licensing metric (including options and management packs) must be applied to both servers.
10. Data Guard
Oracle customer believes that since Data Guard is included with Oracle Database Enterprise Edition, the standby server does not need to be licensed; however, from an Oracle licensing perspective, any Data Guard scenario would be interpreted as a standby configuration and therefore must be fully licensed. Additionally, the licensing metric (including options and management packs) for this server must match the associated production server.
Summary
The following is a recap of Oracle’s licensing rules when deploying backups, failover (active/passive), and high-availability (active/active) scenarios:
Backups/Testing
In this type of data recovery, Oracle permits customers to store a backup copy of the database data on storage devices (tape, disk, cloud) without the purchase of additional licenses. In the event of a failure, the backup files can be used to reconstruct the Oracle database.
Oracle permits a licensed customer, for the purpose of testing physical copies of backups, to restore the database to an unlicensed server up to four times, not exceeding two days per test, in a given calendar year. When testing is complete, the restored database must be removed from the unlicensed server; otherwise, the server must be licensed.
Failover (Active/Passive)
In this type of data recovery, servers/nodes are configured in a cluster and are connected to a single disk array. The production server/node acts as a primary node. The Oracle database software is installed on both the production and failover server(s)/node(s); however, the database is installed on the shared disk array. In the event of a failure, the clustering software will switch control from the primary server/node disk subsystem to the secondary (failover) server/node.
From an Oracle licensing perspective, failover applies to an active/passive clustered environment where only the primary (production) server/node is actively running Oracle software and the failover server/node is effectively idle (not running) and will only be used in the event that a failure occurs or maintenance is required. Therefore, Oracle permits a licensed customer to run a failover server/node without any additional licenses on the condition that the failover period does not exceed a maximum of ten days in a given calendar year.
This failover period also includes downtime for maintenance. Once the failover/maintenance period has exceeded ten days, the failover server/node must be licensed. Oracle only permits one failover server/node per cluster. Therefore, if additional servers/nodes are configured as failover, those servers/nodes must be licensed. When licensing this type of scenario, the same license metric must be applied to both production and failover servers/nodes.
High-Availability (Active/Active)
In this type of data recovery, the Oracle database software and the database are installed on both the production and standby/data recovery servers, which are usually located in different geographic locations. The data at the standby/data recovery server is kept in sync with production through some form of data replication, mirroring, or copying. In the event of a failure or disaster, the standby/data recovery server can be activated as the primary with little or no disruption or data loss.
From an Oracle licensing perspective, both the production and standby/data recovery servers must be fully licensed. This rule also applies when Oracle software can access the data that is located on separate servers, sites, or storage devices. With a high-availability (Active/Active) configuration, the ten-day policy does not apply. When licensing this type of scenario, the same license metric must be applied to both production and standby/data recovery servers.
Conclusion
In general, all Oracle installations must be licensed; however, there are a few exceptions. It is important to understand these licensing rules and exceptions to avoid costly non-compliance penalties. Please contact your trusted Miro Analyst or Miro Account Manager if you are considering or have a data recovery strategy in place. Miro can assist your organization with assessing all of the risks and opportunities to maximize your software investment while ensuring a fully compliant environment.