How Oracle licensing works

Oracle licensing is a complex area, and we always advise organizations to speak to a specialist to identify the right model for their requirements. However, the basic premise is that if Oracle is installed on a server, it needs to be licensed, regardless of whether the server is being used. The two main types of Oracle license are processor licenses and named-user licenses. For organizations with large numbers of users, a processor license is generally the more cost-effective. It’s also generally the approach organizations take for their DR environments. But precisely what licenses are required for the DR environments depends on how they’re set up. Let’s consider the four main approaches: backup, failover, standby and remote mirroring.

Backup

This setup involves storing a backup copy of the Oracle database on a tape. When the primary environment fails, the contents of the tape is loaded onto a secondary server, to enable operations to resume. Recovery times from tape aren’t anywhere near as quick as they are with some of the other DR setups, but this arrangement has advantages from an Oracle licensing perspective. These boil down to the simple concept that provided the customer organization adheres to certain restrictions, the backup does not require additional Oracle licenses. Those restrictions are in essence threefold. Firstly, the backup cannot be tested more than four times per calendar year. Secondly, each test cannot exceed two days. And thirdly, syncing files during testing is not allowed.

Failover

A failover setup sees two or more nodes set up in a cluster, attached to the same storage area network (SAN). Node one operates as the primary production server. If the primary node fails, one of the other nodes takes over production duties. Oracle Database licenses allow customers to run the database on one unlicensed spare server during up to 10 separate calendar days in a calendar year. The duration of use during a single day is unimportant. So if the unlicensed server is used for 20 minutes on Monday, 20 on Tuesday and another 20 on Wednesday, this uses three of those 10 days’ allowance. The workload must also be switched back to the primary server once the failure is repaired, or designate the repaired server as the new failover node. If usage of the secondary server exceeds the 10-day allowance, it needs to be fully licensed, using the same metric (processor or named user) used for the primary server.

Standby

In a standby setup, the primary database is continually replicated from the primary server to a standby server, both with Oracle installed. From a business continuity perspective, if the primary server fails, the secondary server is activated to take over production duties. A standby setup requires the secondary server to be licensed in exactly the same way as the first, using the same metric, and covering the same products, including database options.

Remote mirroring

A remote mirroring configuration sees production data stored on a local SAN, and replicated on a remote SAN in another location. When the primary server fails, data from the secondary SAN is used to spin up a remote server, which takes over production duties. The remote secondary environment must be fully licensed in the same way as the primary, if Oracle is ever “installed and/or running” on it. The one exception is that RAC does not need to be licensed on the DR server unless it’s actually used.

Time for a new approach?

Having to pay for DR environments in a data center that rarely, if ever, get used, represents a significant opportunity cost. This is why we’re seeing increasing numbers of organizations looking to switch to a subscription-based DR-inthe-cloud service. This approach sees customers pay a low monthly fee to have their Oracle data continually replicated into the cloud. In the event of a disaster, the elasticity of the cloud enables a production-grade environment to be spun up rapidly, so that the organization can resume operations.

Failover time is typically in line with a conventional ‘standby’ setup, as described above. This approach has several advantages. It eliminates the infrastructure procurement and maintenance overheads associated with traditional data-center-based DR. It also means that aside from the small subscription fee, customers only pay for their DR environments when they’re actually in use, which typically results in much lower DR costs overall. Moreover, if the cloud-based DR service costs include all the necessary Oracle licensing, this removes another set of complexities from the customer’s perspective.