Nothing calls for disaster recovery (DR) more than 2020, which makes this the perfect time to consider disaster recovery environments.
However, when it comes to Oracle, it can be tricky to figure out what your contracts allow you to do when it comes to creating a proper DR environment for even the stickiest of situations.
The last thing you want is to run up against compliance issues with Oracle, who is known for their brutal software audits, especially in matters of disaster recovery. At MetrixData 360, we are experts in both managing our client’s compliance issues as they arise and proactively ensuring they never occur again.
Here’s what our Software Asset Management Experts have to say about how to properly license your DR environments.
What is a Disaster Recovery Environment?
Every business has mission-critical information they need to protect and keep accessible at all times. This is why every business should have some form of disaster recovery in place. Disaster recovery is a method of security planning with the goal of protecting that data from any significant negative events.
Common types of disaster scenarios are as follows:
-
Application Failure:
Commonly seen as a result of hardware or software configuration. DR solutions around this scenario involve application backups or active-to-active failovers. -
Network Failure:
When you have a full or partial Cloud environment, losing connection to this environment could be the result of power outages or performance issues. DR solutions for this scenario involve strengthening the connection to the organization’s network or creating multiple access points to the network in order to create sufficient redundancies. -
Data Center Failure:
Often seen as a result of mass power outages or natural disasters, which results in the loss of connection to whole data centers or domains. Creating a DR solution for this event involves potentially deploying applications across multiple domains if you have them. -
Region Fail:
Most likely the result of the most severe disasters, when whole regions lose either power or connection of their network. To protect against this event, you can deploy your workload over multiple Oracle Cloud infrastructures in a variety of regions.
It is the IT department’s job to ensure that this protected data is constantly updated, maintained, and easy to access, so that the organization can continue to run as normally as possible under the circumstances. Although smaller industries may be hesitant to invest in funding for a situation that has yet to occur, it is usually better to be safe than sorry.
While Disaster Recovery as a whole involves many different working elements including a DR plan, personnel, actions for dealing with financial and legal issues etc., this blog post will only be focusing on how to license the Disaster Recovery environments that organizations have built.
How to License a Disaster Recovery Environment
Since your DR environment is only used when disaster strikes, your organization (hopefully) does not have to use it constantly, in which case it may feel like you don’t have to license the environment. However, to assess whether your DR environment needs to be licensed, consider the following:
-
Check Your License Agreement and the General Terms:
All the rules that you need to adhere to can be found in your licensing agreement, or your Oracle Master Agreement (OMA) if you have one, and any other documents that the agreement refers to. There may be versions of basic contracts online, but these might be out of date and may not accommodate for any unique licensing metric you may have. For instance, some companies have a licensing metric based on your company’s annual revenue or the number of employees that you have. If there is any language in the contract that is ambiguous, you should seek out clarification from your Oracle rep. -
Remote Mirroring:
With Remote Mirroring, your data is stored in an identical storage unit or shared disk array in a dispersed location through the use of solutions like Veritas Volume Replicator, EMC SRDF, Legato Relator, and EMS StorageEdge. In this instance, both the mirrored database and the unit its replicating will need the same licenses. -
Standby:
With Standby, copies of the primary database are maintained on standby servers, which are dispersed geographically and any changes or updates the primary server experiences is replicated in the standby databases. In this situation, both the standby and the primary databases need to be fully licensed using the same metric. -
Backups:
Backups refer to a copy of a physical database structure. In the event of the loss of the original data, the backup files will be used to reconstruct the lost information. This copy may include critical elements of the database’s physical structure like control and data files and redo logs and can be stored either on a server, a storage array, a disk drive etc. Oracle will allow you to keep these copies in a storage device without needing to purchase a license but when the disaster occurs, and the data is taken from storage and installed onto the recovery server, you’ll need a license. -
Your Oracle Licenses Match:
It’s important to make sure that your DR servers have the same licensing metric (Processor or Named User Plus) as the primary server that it is supporting. DRs and their primary servers must also have matching database options and packs. When it comes to this coordination, you’ll find that Oracle is particularly unyielding and so it is important that any mismatching licensing is addressed before you are confronted with it during an audit.
Situations Where Licensing Isn’t Required for Disaster Recovery
While typically Oracle requires you to license any and all environments where their software is present, there are a few exceptions to the rule.
-
Failovers:
A failover is where a database that is running on a primary server can be moved to a secondary server in the event that the primary fails. Oracle will allow a database to be run on this unlicensed secondary server for 10 days. This scenario is allowed when both the primary and the secondary servers exist within a single cluster and share a single disk array or storage device. In this scenario only the failover server is free and once the primary server has been repaired, the database is required to switch back to the primary server. It’s also important to note that Oracle does not equate one day to 24 hours scattered over a long period of time. If the failover server is active for an hour one day and two hours another day, that counts for two days. You are only allowed to have one free failover node per cluster for up to ten separate days even if you have multiple nodes configured as failovers. This scenario also does not apply to VMware environments. If you would like to license your failover environments, you’ll need matching licenses to the databases the failovers will be supporting. -
Testing:
Oracle’s customers are allowed to use tape and disk backups of databases for the purpose of recreating that database for the use of testing. You can run this duplicated database on an unlicensed server four times per year, with a time restriction of two days for each test, at which time the database must either be removed from the server or will be considered licensable in the eyes of Oracle.
Be Ready for Anything with Properly Licensed Disaster Recovery
It’s always better to be prepared, whether that is getting your software environment ready for a natural disaster or making sure your licenses are orderly in the event of a software audit from Oracle.
It would be a terrible situation to discover that the very thing that was supposed to be there to keep your business afloat could cost you a staggering amount in compliance gap thanks to under licensed servers.
At MetrixData 360, our goal is to ensure you only pay for what you need to and to fight for your best interests when you go up against Oracle. If you’d like to know more about what our services entail when it comes to your Oracle Licensing, you can check out our Contract Negotiation page for more information.
