Organizations of every kind rely on readily available access to their data. For this reason, sound data recovery plans are essential to ensure that crucial information is not lost in the event of a disaster. While implementing this type of plan is vital, it is also important that organizations are properly licensed for the software required for these plans. When it comes to Oracle Database, many customers remain confused about what licensing is required for their disaster recovery installations. This confusion can lead customers to overspend on Oracle, or, conversely, can lead to license shortfalls that may be costly should Oracle decide to audit. Understanding how to properly license Oracle is a key step in your disaster recovery plan.
When it comes to Oracle Database, an important concept to remember is that all processors where Database is installed and/or running must be licensed, regardless of the installation’s purpose. From a licensing perspective, Oracle makes no distinction between production, test, development…..or disaster recovery. When customers maintain copies of primary databases on standby servers, those standby servers must be licensed. Similarly, when customers replicate Oracle Database data files, binaries, and executables from a primary storage device to a remote device, servers connected to that remote device are licensable as well. In fact, even if a disaster recovery server is completely switched off (and the database is not running) licensing for Oracle Database is still required so long as it is installed. Oracle has proven inflexible about this during their audits. The main takeaway here is that Oracle’s default position is that all installations require licensing.
Exceptions to the rule
Oracle does, however, make a couple of exceptions for very specific disaster recovery scenarios. Customers that are vaguely aware of these exceptions, but don’t know the details, often mistake them for a free pass to install Oracle for DR. Understanding these exceptions can help customers avoid costly non-compliance issues.
Oracle uses the term ‘failover’ to describe a scenario where, within a cluster of servers, a database running on a primary server could move to a secondary server when the primary server fails. Oracle allows for the database to run on the secondary server for up to 10 days without additional licensing requirements. The failover allowance only applies when the primary and failover servers are arranged in a single cluster and share one disk array or storage device.
Additionally, in order to fall within the bounds of this exception, only one failover server in the cluster is free. Once the primary server is repaired, switching back to the primary server is mandatory.
Finally, this failover exception does not apply to VMware environments. Customers should remain aware of these restrictions in order to properly assess their licensing needs and compliance position.
Oracle allows customers to use tape or disk backups to recreate the database for test purposes. Customers may run the database on an unlicensed server up to four times per year, with each test not to exceed 2 days in duration. When testing is done, the database must be removed from the server. Otherwise, Oracle would deem the server to be licensable.
Matching Oracle Licensing Metrics
Oracle requires that customers license a primary server and it’s corresponding DR server with the same metric (i.e. either Processor or Named User Plus). Additionally, the DR server must be licensed for the same database options (such as Partitioning) and packs (such as Tuning Pack) as the primary server. This is another area where Oracle has proven to be inflexible and customers can avoid future headaches by licensing accordingly.
Protect Your Data and Stay Compliant
Oracle is forthcoming about their positions around licensing DR, and they do provide customers with leeway through their failover and testing exceptions. But it is often these very allowances that create confusion for customers, who often try to apply these exceptions to an architecture that is in violation of them. Knowing what does and does not require a license is key in achieving and maintaining Oracle compliance.