Les comparto este interesante artículo de nuestro amigo Alex Gorbachev sobre el manejo de licenciamiento en caso de una replicación utilizando un método físico de un tercero.
Conclusión, todos los ambientes se licencian.
While doing my high availability deep dive at Collaborate 12 few weeks ago, I stated that storage replication qualifies for the cold failover licensing rules (see slide #128).
During the collaborate, I spoke to one person at Oracle who definitely knows the rules. Simon Haslamalso reached out to me by email pointing out that things might not be that rosy. After my session, Arjen Visser from Dbvisit also noted that they’ve seen Oracle sales pushing for a different strategy.
Simon referred to Oracle’s Software Investment Guide:
Remote Mirroring – This method 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 setup a remote mirroring environment, the Oracle data
files, executables, binaries and DLLs are replicated to the mirrored storage
unit. Solutions like Veritas Volume Replicator, EMC SRDF, Legato Replistor, and
EMS StoreEdge are used to mirror the data stored in on the disk arrays. 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 database 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, however 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. In this environment,
Oracle must be fully licensed at the primary site, and if it is ever installed
and/or run at the secondary site, it must also be fully licensed there.
The key there is that “the Oracle data files, executables, binaries and DLLs are replicated”. If you only replicate data files, then you can likely avoid a licensing mirrored site. However, it will, of course, impact your speed when getting back in business on the mirrored site. On the flip side, the way to avoid remote site licensing is to make sure it qualifies as a backup. From the same document:
Backup – In this method, a copy of the physical database structures of the
database 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 important parts of the physical structures 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 EE or SE) and Oracle Secure
Backup or operating system utilities are used to create copies of physical files.
Oracle permits customers to store a back up 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,
and the Oracle Database is installed on the recovery server, licensing is
required. See illustration #3.
Note how it specifically distinguishes the situation with restore in the new hardware that requires installing the Oracle binaries. So, if you install or restore Oracle binaries in the new hardware, you have to license it separately unless you decommission your old hardware. This means that it could really only work if you lose your primary site completely and move to the DR site for good. It does fit some business continuity scenarios, but it’s definitely different from cold failover scenarios, and the 10 days rule is not applicable.
I also wanted to find the reference for RAC One Node and one stating that Cold Failover licensing rules can be applied. Oracle Database Licensing Guide doesn’t have this information (or at least I couldn’t locate it), but here is the statement from Oracle’s presentation. (Note that it doesn’t really have the legal status as does your licensing agreement):
All nodes on which RAC One Node is installed must be licensed for RAC One Node
* Exception: One spare node for cold failover/Online Database Relocation need not be licensed under the 10-day use rule
* Example: In a two-node cluster, customers can license RAC One Node on ONE node; 10-day rule applies for spare node
I used to be able to find standard OLSA (Oracle License and Service Agreement) at oracle.com in the past, but these days I only get here and can’t locate the OLSA. In any case, make sure to read your OLSA — it will have the definition of cold failover similar to what you see in the SIG I referred above.
Failover – In this type of recovery, nodes are arranged in a cluster and share
one disk array. 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. When 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. In this type of environment, Oracle permits
licensed Oracle customers to run some Technology Programs on an
unlicensed spare computer for up to a total of ten separate days in any given
calendar year. 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. Any other use requires the
environment to be fully licensed. . In a failover environment, the same license
metric must be used for the production and failover nodes when licensing a
given clustered configuration. Additionally, when licensing options on a
failover environment, the options must match the number of licenses of the
associated database.
I will update the slides accordingly. In any case, please do your own homework and don’t trust my conclusions here. Don’t take this as licensing advice by any means. It’s been on my TO-DO list for a couple weeks now, and while I wanted to put a bit more effort before I blog about it, the reality is that the more I delay, the less likely I post it at all. That would be devastating. Your comments are more than welcome, whether they’re pointing out any errors, adding some info, or sharing your experience.
