How to license Oracle Database programs in DR environments

Size: px

Start display at page:

Download "How to license Oracle Database programs in DR environments"

Meredith Lester
5 years ago
Views:

But how does that work when you only install the Oracle software for disaster recovery (DR) purposes?

1 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.

2 Contents Introduction... 3 Data recovery methods... 4 Data recovery licensing policy for technology products by metric Oracle Databases on VMware Best Disaster Recovery Practices Conclusions and Recommendations... 17

3 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.

4 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.

5 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:

6 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.

7 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.

8 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.

9 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.

10 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.

11 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.

12 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.

13 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.

14 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

15 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, adhoc 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.

16 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.

17 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.

18 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: andra.tarata@b-lay.com 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 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 CG Utrecht The Netherlands info@b-lay.com B-lay BV. All rights reserved.

Oracle MySQL Free vs. commercial

Oracle MySQL Free vs. commercial Author: Andra Tarata Do you want to understand why you need a license to make use of MySQL? Or what license types are available and which specific editions of the MySQL