how to license oracle database programs in dr...

How to license Oracle Database programs in DR environments

Author: Andra Tarata

It is commonly known that the use of almost any Oracle software program requires a license. But how does that work when you only install the Oracle software for disaster recovery (DR) purposes? You don’t use the software, so you probably don’t need to license it, right? The objective of this whitepaper is to bring clarity on the different licensing scenarios applicable when Oracle software programs are deployed in disaster recovery environments.

HOW TO LICENSE ORACLE DATABASE PROGRAMS IN DR ENVIRONMENTS

Contents Introduction ....................................................................................................................................... 3

Data recovery methods .................................................................................................................... 4

Data recovery licensing policy for technology products – by metric ............................................. 13

Oracle Databases on VMware Best Disaster Recovery Practices ................................................ 14

Conclusions and Recommendations ............................................................................................. 17


Introduction It is commonly known that the use of almost any Oracle software program requires a license. But how does

that work when you only install the Oracle software for disaster recovery (DR) purposes? You don’t use the

software, so you probably don’t need to license it, right? Or if you use the Oracle software as installed on

the DR server, then you’d think you can re-allocate the licenses from your production server to the secondary

DR server, since you are only using the software on the DR server.

Oracle classifies different DR scenarios as “cold-standby”, “warm-standby” or “hot-standby”, right? Well, we

heard different stories in our day-to-day practice that showed that end users don’t have a clear view on how

licensing of Oracle’s software in a DR environment works. Therefore, the objective of this whitepaper is to

bring clarity on the different licensing scenarios applicable when Oracle software programs are deployed in

disaster recovery environments.


Data recovery methods

Data Recovery represents the process of retrieving inaccessible, lost, corrupted, damaged or formatted data

from secondary storage, removable media or files, when the data stored in them cannot be accessed in a

normal way. The most common data recovery scenario involves an operating system failure. An unfortunate

aspect of every database system is the possibility of a system or hardware failure. The main types of

failure are:

• Server failure

• User or application error

• Media (disk) failure

• Disasters

The most common data recovery methods are:

• backup

• standby

• remote mirroring

• failover

They are all described in the Oracle “Licensing Data Recovery Environments” policy, available here.

http://www.oracle.com/us/corporate/pricing/data-recovery-licensing-070587.pdf


Backup

Through backup, a copy of the physical database structure is made. When the original data is lost, the

backup files can be used to reconstruct the lost information that constitutes the Oracle Database. This

backup copy includes the main parts of the physical structure, such as: control files, redo logs and data files.

These physical files can be stored on a server, storage array, disk drive(s), or Compact Disc(s). Solutions

like Recovery Manager/RMAN(included with Oracle Database Enterprise Edition or Standard Edition) and

Oracle Secure Backup or operating system utilities are used to create copies of physical files, as shown in

below picture:

Oracle permits end users to store a backup copy of the database physical files on storage devices, such as

tapes, without purchasing additional licenses. In an event of failure, when the Oracle data is restored from

tape or media, end users may use the following scenarios to license the recovery database:

Scenario 1:

• Production Database: Oracle Database is installed and/or running

• Recovery Database: Oracle Database is installed and/or running. Tapes are used to update the recovery site

Licensing Policy:

• Both Production and Recovery databases need to be licensed

Scenario 2:


• Production Database: Oracle Database installed and/or running

• Recovery Database: Server is switched off Oracle Database is installed but not running. Tapes are used to update the Recovery site

Licensing Policy:

• Both Production and Recovery databases need to be licensed

Scenario 3:

• Production Database: Oracle Database installed and/or running

• Recovery Database: Server is switched off. Oracle Database is not installed. During the time of recovery, the Oracle Database is installed to recover the information from the backup tapes.

Licensing Policy:

• Production Database needs to be licensed

• Recovery Database: o When the server is switched off and the Oracle Database is not installed, the Oracle

Database does not need to be licensed. o During the time of recovery, when the Oracle Database is installed to recover the

information from the backup tapes, then the Recovery Database needs to be licensed.

Scenario 4:

• Production Database: Oracle Database is completely unavailable due to a destruction of the hardware

• Recovery Database: During the time of recovery, the Oracle Database is installed to recover the information from the backup tapes

Licensing Policy:

• Production Database: Licensed and completely unavailable beyond repair

• Recovery Database: In this situation, the customer is allowed to transfer the Production database license set, provided that the primary database is completely unavailable and inaccessible.


Standby

Through standby, one or more copies of a primary database are maintained on a standby server (or on

multiple standby servers). As the primary database is modified, log pieces of information generated by the

changes are sent to the standby database(s) and subsequently applied to the standby database. If the

primary database fails, a standby database can be activated to be the new primary database. Solutions like

Oracle Data Guard (included with Oracle Database EE) or customer-generated scripts can be used, as

shown in the below picture:

In this disaster recovery environment, both the primary and the standby databases must be fully licensed.

Additionally, the same metric must be used to license both databases.

• When licensing Oracle Database options on a standby environment, the options must match the

number of licenses/users of the associated database where the option is installed and/or running.

• End users who have already licensed the Oracle Database for their primary environment using an

old metric (such as: Concurrent Device, Named User Single Server, Named User Multi Server,

Universal Power Unit, Power Unit etc.) can buy additional licenses for their standby environment,

without necessarily migrating. The following rules apply:

o If the primary environment is licensed with a multi-server metric such as Concurrent Device,

Named User and Named User Multi-server and the customer has not met the minimum

licensing requirement on all of the boxes, which include the Standby server, the customer

can license his standby environment by Named User Plus, without migrating his existing

licenses from the other multi-server metrics. If the standby environment is licensed by

Named User Plus, then the minimum on the standby server must be met.


o If the primary environment is licensed with a hardware-based metric such as UPU, Power

Unit, Power Unit - RISC, Power Unit - Intel, then the customer may license his standby

environment with the Processor metric, without migrating his existing licenses that are

assigned to his primary environment. If licensing by Processor, all processors where the

standby database is installed and/or running must be counted.


Remote Mirroring

Remote Mirroring involves the mirroring of the storage unit or shared disks arrays. Remotely mirrored

storage units may be geographically dispersed and not in the same location as the primary unit, but they

share the same disk array. To set up a remote mirroring environment, the Oracle data files, executables,

binaries and DLLs are replicated to the mirrored storage unit. Solutions like Veritas Volume Replicator,

EMCSRDF, Legato Replistor, and EMS StoreEdgeare used to mirror the data stored on the disk arrays,

as shown in below picture:

In this environment, both the primary and the remote mirrored databases must be fully licensed.

Additionally, the same metric must be used to license both databases.

• If the Oracle Database is accessing the data from the primary disk array and it is not accessing the

mirrored disk array, but it is installed on the mirrored network storage unit, then both databases must

be fully licensed and the same metric must be used.

• If a failure occurs in the primary storage unit and the Oracle Database can no longer access the

data from the primary disk array, but it is still installed on the primary unit and data can only be

accessed from the remote mirrored disk array, then both databases must still be fully licensed and

the same metric must be used.

Exception to this rule: if the failure in the primary disk array causes the Oracle Database to be no longer

installed, for example in case of an explosion, then the licenses from the primary Database can be allocated

to the Database that is accessing the remote mirrored unit.


The Licensing Policy that applies to different remote mirroring scenarios is described in the below table:


Failover

In this disaster recovery method the nodes are configured in "clusters". A failover cluster is a group of

systems, bound together into a common resource pool. In this type of recovery method the Production node

acts as the primary node. If the primary node fails, one of the surviving nodes in the cluster acts as the

primary node. Solutions like Oracle Failsafe (included with Oracle Database EE or SE, SE1), or third-party

vendor solutions (e.g. Veritas, HP Service Guard, HACMP, Linux HA - Heartbeat) are used to manage

Failover environments, as shown in below picture:

Restrictions and Conditions:

• Only one failover node per clustered environment is free for up to 10 days - even if multiple nodes

are configured as failover.

• The metric matching rule only applies to all the servers in a given clustered configuration.

• Ten days are counted as ten separate days of failover occurrences. For example: if failover node is

down for two hours on Tuesday and three hours on Friday, it counts as two days.

• When licensing by Named User Plus, minimums are waived on one failover node only.

• Switching back to the production node is mandatory. When the production node fails, the failover

node acts as the primary node. Once the production node is repaired, switching back to it is required.

If the failover period has exceeded ten days, the failover node will need to be licensed. The customer

must not operate beyond the number of licenses granted or purchased.

• Downtime for maintenance purposes counts towards the ten days.

• When licensing options on a failover environment, the options must match the number of licenses

of the associated database.

• The failover policy does not apply to Oracle Database Lite and Personal editions.


Subject to the conditions that described above, your license for the Technology programs listed on

the Technology Price List includes the right to run the licensed program(s) on an unlicensed spare computer

in a failover environment for up to a total of ten separate days in any given calendar year (for example, if

a failover node is down for two hours on Tuesday and three hours on Friday, it counts as two days).

The above right only applies when a number of machines are arranged in a cluster and share one disk array.

When the primary node fails, the failover node acts as the primary node. Once the primary node is repaired,

you must switch back to the primary node. Once the failover period has exceeded ten days, the failover

node must be licensed. In addition, only one failover node per clustered environment is at no charge for up

to ten separate days even if multiple nodes are configured as failover.

Downtime for maintenance purposes counts towards the ten separate days’ limitation (this includes any kind

of downtime like systems failure, disasters, system maintenance). When licensing options on a failover

environment, the options must match the number of licenses of the associated database. Additionally, when

licensing by Named User Plus, the user minimums apply on one failover node only. Any use beyond these

rights must be licensed separately. In a failover environment, the same license metric must be used for the

production and failover nodes when licensing a given clustered configuration.

The 10-day failover policy can be granted to each of the customer's potential environments: production,

development, and test/staging, provided that all these environments are on totally separate clustered

environments. The 10-day failover right is only granted per clustered environment. The clustered

environment can include any combination of environments like production, development etc.

Example: If a customer has 3 separate clusters (production, dev, test) supporting a single application, and

each cluster has a failover node assigned, then three nodes (one from each cluster) would be eligible for

the 10-day failover policy.

Testing - For the purpose of testing physical copies of backups, your license for the Oracle Database

(Enterprise Edition, Standard Edition or Standard Edition One) includes the right to run the database on an

unlicensed computer for up to four times, not exceeding 2 days per testing, in any given calendar year. The

aforementioned right does not cover any other data recovery method - such as remote mirroring - where the

Oracle program binary files are copied or synchronized.

http://www.oracle.com/us/corporate/pricing/technology-price-list-070617.pdf


Data recovery licensing policy for technology products – by metric

Licensing using the Processor metric: All processors where the Oracle program is installed and/or running

must be licensed. This includes test, stage, development and data recovery servers. Metrics on production

and data recovery servers must match.

Licensing using the Named User Plus (NUP) metric: Since the NUP metric is a multiserver metric, it allows

a named user access to multiple servers; this includes test, stage, development and data recovery servers.

Minimums must be met. Metrics on production and data recovery servers must match.

Restricted Use (RU) or Runtime Technology Licenses: The following usage and customizations trigger

an upgrade from Restricted Use License to a Full Use License of the technology program included with

Application Products:

• Use of Data Guard to synchronize Production and Standby servers.

• A modification of the tables or any database structures supporting the application covered by the

RU license.


Oracle Databases on VMware Best Disaster Recovery Practices

The type of replication of data from the primary to the disaster recovery site often depends on the business'

Service Level Agreement (SLA), the network bandwidth between the two sites, and the software currently

in use to perform the replication.

Replication can be broadly performed on three different levels:

• Application

• vSphere

• Storage

Application based replication

At the top of the IT stack is the application that the end user interfaces with and that is most likely to be down

in the event of an outage. Because it is the application that is being protected against a disaster, it makes

sense to leverage any built-in options for data replication on an application level.

• Oracle Data Guard - Oracle Data Guard is the premier Oracle data replication tool for disaster

recovery. Oracle Data Guard ensures data protection and disaster recovery for Oracle Enterprise

data. Oracle Data Guard provides a comprehensive set of services that creates, maintains,

manages, and monitors one or more standby databases to enable production Oracle databases to

survive disasters and data corruptions.

Oracle Data Guard maintains these standby databases as copies of the production database. If the

production database becomes unavailable because of a planned or an unplanned outage, Oracle

Data Guard can switch any standby database to the production role, minimizing the downtime

associated with the outage. A standby database can either be a single-instance Oracle database or

an Oracle RAC database.

Two types of standby databases are implemented as follows:

• Physical standby database which provides a physically identical copy of the primary database, with

on-disk database structures that are identical to the primary database on a block-for-block basis. A

physical standby database is kept synchronized with the primary database, through Redo Apply,

which recovers the redo data received from the primary database and applies the redo to the

physical standby database.

• Logical standby database which contains the same logical information as the production database,

although the physical organization and structure of the data can be different. The logical standby


database is kept synchronized with the primary database through SQL Apply, which transforms the

data in the redo received from the primary database into SQL statements and then executes the

SQL statements on the standby database.

An Oracle Active Data Guard standby database can be used to offload a primary database of reporting, ad-

hoc queries, data extracts, and backups, making it a very effective way to insulate interactive users and

critical business tasks on the production system from the overhead of long-running operations.

Oracle Active Data Guard provides read-only access to a physical standby database while it is synchronized

with a primary database, enabling minimal latency between reporting and production data.

Oracle Active Data Guard automatically repairs physical corruption on either the primary or standby

database, increasing availability and maintaining data protection at all times.

The steps for setting up an Oracle Data Guard on vSphere are the same as setting it up on a physical

environment. VMware recommends referring to Oracle best practices as documented in the Oracle

documentation available here.

VMware vSphere Replication

VMware vSphere Replication is a virtual machine data protection and disaster recovery solution that is fully

integrated with vCenter Server and vSphere Web Client, providing host-based, asynchronous replication of

virtual machines.

Because vSphere Replication is host-based replication, it is independent of the underlying storage and it

works with a variety of storage types including Virtual SAN, traditional SAN, NAS, and direct-attached

storage (DAS), and enables virtual machine replication between same or heterogeneous storage types.

vSphere Replication does not use VMware snapshots to perform replication. After replication has been

configured for a virtual machine, vSphere Replication begins the initial full synchronization of the source

virtual machine to the target location. A copy of the VMDKs (Virtual Machine Disks) to be replicated can be

created and shipped to the target location and used as “seeds,” reducing the time and network bandwidth

consumed by the initial full synchronization. After the initial full synchronization changes to the protected

virtual machine are tracked and replicated on a regular basis. The transmissions of these changes are

referred to as “lightweight delta syncs.” The transmission frequency is determined by the RPO that is

configured for the virtual machine. An RPO (recovery point objective) is the maximum targeted period in

which data might be lost from an IT service due to a major incident. A lower RPO requires more frequent

replication.

vSphere Replication cannot provide the application-level replication that Oracle Data Guard provides

because it is not a native Oracle tool.

https://docs.oracle.com/database/121/SBYDB/concepts.htm#SBYDB00010


vSphere Replication can be used to replicate virtual machines housing Oracle databases based on the RPO

settings. The Oracle database on the target site can be recovered through an Oracle crash consistent

recovery because the database is crash consistent at the point of the replication cycle.

Using vSphere Replication consistency groups and queuing the Oracle database before every replication

cycle is not acceptable in any Oracle production database environment because it introduces database

performance issues. This results in business SLA deficiencies and therefore many DBAs choose to use the

crash consistent copy of the database on the target site.


Conclusions and Recommendations One of the best ways to reduce downtime is incorporating operational best practices. You can often prevent

problems and downtime before they occur by rigorously testing changes in your test environment, following

stringent change control policies to guard your primary database from harm, and having a well-validated

repair strategy for each outage type.

A monitoring infrastructure such as Grid Control is essential to quickly detect problems. Having an outage

and repair decision tree and an automated repair facility reduces downtime by eliminating or reducing

decision and repair times.

Some recommendations to prevent such problems and outages include:

• Create test environments: a test environment that mimics the production environment is useful to

test changes and prevent issues such as power outages, OS failures, file deletion, Oracle instance

failures, terrorist or malicious attacks, etc.

• Implement change control and security procedures to ensure that no changes are incorporated in

the primary database unless they have been rigorously evaluated on the test systems

• Create and follow security best practices: a well-defined security policy can help protect your

systems from unwanted access and protect sensitive corporate information from sabotage. Proper

data protection reduces the chance of outages due to security breaches

• Use Grid Control or another monitoring infrastructure to detect and react to potential failures and

problems before they occur.

©2018 B-lay BV. All rights reserved.


About the author – Andra Tarata "Shoot for the moon. Even if you miss, you'll land among stars!"- Les Brown

Andra has been working in the Software Licensing industry for the last 8 years, analyzing and understanding licensing business practices & product development from multiple software vendors and helping clients to better manage their software entitlements.

Andra leverages her experiences of working within Oracle’s License Management Services team to educate, equip and enable end-users to understand their enterprise software license entitlements. Andra holds a bachelor degree in Project Management from the National School of Political and Administrative Studies of Bucharest.

Contact Andra: [email protected]

We share our knowledge, so you can focus on the facts! Do you want to know more about different related license management topics, we have a selection of white papers available through www.b-lay.com. If you are in need of extra expertise and a structured approach, feel free to contact B-lay. We will help you make software compliance an exciting opportunity to improve your business!

About B-lay B-lay is a specialist in software license management and provides services around software compliance, software audits, software asset management tools and insight in software spend. Our services offer organizations worldwide insight into the risks associated with software licenses, help prevent license compliance issues and help create considerable cost savings by optimizing their licensing position. B-lay was founded in 2008 and has offices in the Netherlands, Romania and the US.

B-lay BV | Maliebaan 79 | 3581 CG Utrecht | The Netherlands | [email protected] | www.b-lay.com | +31 88 0233 700

mailto:[email protected]

how to license oracle database programs in dr...

Documents