INTRODUCTION TO ORACLE LICENSING

INTRODUCTION TO ORACLE LICENSING

INOAPPS CORPORATE OVERVIEW Oracle Platinum Partner Largest Independent Oracle Specialist Partner in EMEA Applications, BI and Technology Consultancy Expertise in Hosting, Managed Services Engineered Systems and Hardware Practice Capable of delivering the whole Red Stack Implemented and Operating Fusion Hiscox Tech Track 100 2014 Deloitte Technology Fast 500 2014 Multiple accolades from customers and Oracle Oracle Specialized Partner of the Year for Oracle Cloud 2015 UKOUG E-Business Suite Partner of the Year 2013 UKOUG Hardware Partner of the Year 2013 UKOUG Engineered Systems Partner of the Year 2013 UKOUG Small business /General Business Partner of the Year 2012 & 2013 Oracle Specialized Partner of the Year for Accelerate Solutions: EMEA 2010 & 2012 UKOUG Innovative (Product/Service) Partner of the Year 2011 & 2012

GLOBAL REACH, LOCAL EXPERTISE USA UK MALAYSIA UK OFFICES Aberdeen (Head Office) Edinburgh Derby INTERNATIONAL OFFICES Kuala Lumpur Texas Coming soon- France Platinum Partner 200 + Employees 28 M Turnover Build KL as Off Shore capability for EMEA

CORPORATE OVERVIEW KEY FINANCIALS 50 45 40 35 30 25 20 15 10 5 0 Turnover Forecasted Turnover 06/07 07/0808/09 09/10 10/11 11/12 12/13 13/14 14/15 15/16

Applications E-Business Suite Fusion JD Edwards Peoplesoft Hyperion BI Managed Services Application Technologies Operating Systems Hardware 24x7x365 Help Desk Technology Database & Middleware Service Orientated Architecture (SOA) Customer Application Development Solution Architecture & Systems Integration Business Intelligence (OBIEE) INOAPPS DIVISIONS

ORACLE LICENSING RULES ARE... Broadly scattered across many sources (not all available to customers). Often obscurely written. Open to diverse interpretations (most of which may be wrong). In many cases way behind contemporary industry practice. Therefore unless you work with them full time, they will confuse. Nevertheless, Oracle has the contractual right to audit customers estates and so you need to be vigilant. In a worst-case scenario, non-compliance could lead to back payments being demanded in respect of the non-compliant usage, AT FULL LIST PRICE. So this session is intended to help you avoid the common mistakes (or uncover them ).

THE EVOLUTION OF DEPLOYMENT ARCHITECTURE KEEPING AN EYE ON ORACLE S COMMERCIAL INTERPRETATION Physically - managed server Bare metal + native O/S Multiple cpus gradually evolved into highly-scalable Symmetric Multi-Processor architectures. For many years cpus were single core.

THE EVOLUTION OF DEPLOYMENT ARCHITECTURE KEEPING AN EYE ON ORACLE S COMMERCIAL INTERPRETATION Physically - managed server Hardware Partitioning Bare metal + native O/S Native O/S + rigidly ring-fenced set of cpu resources. Later developed migration features Framework for managing resources. Oracle recognises specific technologies as hardware partitioning. Debating the meaning is futile: these are Oracle s rules. Later developed migration features. Oracle has not accepted these as compliant with their partitioning doctrine for licensing.

THE EVOLUTION OF DEPLOYMENT ARCHITECTURE KEEPING AN EYE ON ORACLE S COMMERCIAL INTERPRETATION Physically - managed server Bare metal + native O/S Hardware Partitioning Native O/S + rigidly ring-fenced set of cpu resources. Later developed migration features Virtualised Clusters Hypervisor with multiple, varied O/S instances and live migration It would be unwise to make the general assumption that a virtual machine can be a hardware partition for Oracle licensing.

THE EVOLUTION OF DEPLOYMENT ARCHITECTURE KEEPING AN EYE ON ORACLE S COMMERCIAL INTERPRETATION Physicallymanaged server Hardware Partitioning Bare metal + native O/S Native O/S + rigidly ring-fenced set of cpu resources. Later developed migration features Virtualised Clusters Cloud Hypervisor with multiple, varied O/S instances and live migration Abstraction rather than new technique, lots of variety We ll explore types of Cloud later.

LICENSABLE ENVIRONMENT A term I created to clarify how Oracle s licensing rules play out in the real world, and how you should approach measuring compliance. The valid choices are simply these: The whole of a physically-managed server in the good old-fashioned way An approved regime of hardware partitioning. (NB on x86 kit, the only candidates are OVM for x86 (without live migration) or Solaris x86 running natively with capped Containers The whole of a virtualised cluster** Generally all the above are considered equal in licensing, and many rules apply to all of them. This has some unforeseen outcomes. ** Oracle has started to expand licensing scope for VMWare post vcenter 5.1. If one instance of vcenter manages multiple clusters, Oracle will say they are all potential migration targets and must be licensed.

LICENSING METRICS The vast majority of Oracle Technology products offer a choice of Processor or Named User Plus metrics. Virtualisation and Cloud have not generated new metrics, and bearing in mind the Licensable Environment concept, lets ensure the meaning of the available metrics is clear.

NAMED USER PLUS METRIC A user under this metric is a real individual (or an automated device) who interacts with the licensed system. It is NOT a measure of concurrency prior to Sept 2002 there was a Concurrent Device (CD) metric for which some customers still retain valid contracts. It also does not support the notion of job-sharing, ALL users must be licensed (assuming no special contract has been negotiated). You are not obliged to keep a register of names, and it is accepted that staff leave & join but if audited you must be compliant. Remember if using Oracle middleware as well as database, both tiers must reflect the relevant user community (or else use the Processor metric). Using a web-style architecture does not in itself invalidate use of NUPs (but if self-registration is possible then Processor metric is required). The OLSA/OMA document that you sign when buying licences includes table of minima for lots of technology products, so check it out.

PROCESSOR METRIC Beware, this means two entirely different things. For products with Standard Edition in the name (including SE1), a processor is counted as an occupied cpu socket WITH NO REGARD TO CORES. Otherwise, a processor in licensing terms is derived as follows:- Add up the cores in all relevant sockets. Apply Oracle s designated multi-core factor ** for the chip-type. http://www.oracle.com/us/corporate/contracts/processor-core-factor-table-070634.pdf (tip : all Intel and AMD x86 chips are 0.5 factor). E.g. 2 x quad-core Xeons = 8 cores = 4 Processor licences. For NUPs, take this result and multiply by the mandated minimum. E.g. in above case for Database Enterprise Edition 4 * 25 = 100 NUP minimum. ** Ignore the heading Effective Date : March 16th 2009. The latest changes are listed at the end.

PROCESSOR METRIC THE IMPACT OF HW CONFIGURATION There is NO fixed differential between the cost of SE and EE. Most people don t realise this. Example (List prices). 2 Intel dual-cores DB SE = 2 sockets = 22K DB EE = 4 cores * 0.5 = 2 licensable cores = 60K 2 Intel quad-cores DB SE = 2 sockets = 22K DB EE = 8 cores * 0.5 = 4 licensable cores = 120K

THE MAGIC COMBINATION The only situations where the Licensable Environment concept is not needed involve products purchased on the Named User Plus metric, and where the mandated minima are given as absolute numbers. The obvious examples are Database SE and SE1, and the Business Intelligence Suites (SE1 and EE Plus). NUPs are inherently multi-server rights, and for these products the number required is not linked to the infrastructure design, so simply license all the real individuals.

HARDWARE PARTITIONING BENEFITS The concept and valid regimes are defined in http://www.oracle.com/us/corporate/pricing/partitioning-070609.pdf. if only part of a server is used to run Oracle products, then licence costs can be reduced compared to licensing the entire physical server. Today s extreme core-densities make this more critical than ever. if multiple Oracle products are deployed on a physical server, partitions allow the licensing to reflect usage of each without overlap, e.g. you could license 2 cpus for Application Server and 2 cpus for Database, rather than covering 4 cpus for BOTH. it becomes possible to adopt different Oracle licence metrics for individual partitions, typically this might be to use Named User Plus pricing for development environments whilst Processor pricing may be mandated for production.

VIRTUALISED SERVER FARMS A typical virtualised server farm Assume that each Intel x86 server has 2 occupied cpu sockets, and that they are of quad-core design. Therefore, 48 cores in the cluster (until you extend it )

VIRTUALISED SERVER FARMS A typical virtualised server farm You plan to run a single 4-core virtual machine for Oracle DB EE. Q.1: With VMWare, how many Processor licences are required? A.1: 24. No hardware partitioning is recognised. Each server has 8 cores i.e. 4 licences. Oracle assert the whole cluster must be covered.

VIRTUALISED SERVER FARMS A typical virtualised server farm You plan to run a single 4-core virtual machine for Oracle DB EE. Q.2: With Oracle VM for x86, how many Processor licences are required? A.2: 24 (or 2) Assuming Live Migration can occur, ALL servers must be covered, and no hardware partitioning allowed. Without Live Migration one could partition the 4 cores i.e. just 2 Processor licences required.

VIRTUALISED SERVER FARMS A typical virtualised server farm You plan to run a 4-core virtual machine for Oracle DB SE (servers must have a maximum potential spec of 4 sockets). Q.3: With VMWare, how many Named User Plus licences are required? (Assume a user community of 17 users). A.3: 17. The NUP metric covers ANY NUMBER of servers. There are no per-server or per-cpu minima mandated for DB SE. This is the Magic Combination!!

CONSOLIDATION AND/OR CUSTOMISATION You may own ISV business applications that include Oracle Technology. These technology rights are acquired through ASFU licences Application Specific Full Use. The licences are limited to being used solely with the intellectual property of the specific business solution. Similarly you may own Oracle E-Business Suite licences, which provide Restricted Use rights on products such as DB EE and OAS EE. Be aware that customising beyond the permitted scope of either of the above will require Full Use licences. Be aware that consolidation or refresh projects could lead to illegal mixes of the above being placed together with other instances in a single licensed environment. This is only possible when Full Use licences are obtained.

CLOUD HOW IS ORACLE LICENSED ON THE CLOUD? WHICH CLOUD?

SIGNIFICANCE OF VARIOUS CLOUD TYPES Oracle Cloud Services Subscription based; No conventional licences needed. Authorised Cloud HOW Environments IS ORACLE ICENSED ON THE Published rules CLOUD? for AWS & Azure; Note: Amazon off subscription as well. Hosting Providers Oracle licences are owned by the hoster, not the client; Proprietary Hosting = multiple client orgs; LASEU = one client org. Note: The hoster has to provide some Intellectual Property in the service. Managed Service Providers Beware!, MSP needs to provide each client with a unique Licensed Environment that mathches the licence entitlement On Premise (Private Cloud) H/W Partitioning and / or virtualisation principles will apply; Architect carefully! WHICH CLOUD? Hybrid Cloud No special considerations; Evaulate each deployment separately

CONCLUSIONS Oracle s licensing principles take a less than intuitive position regarding virtualised and migratable environments. Today s hardware is over-burdened with core-density that was unthinkable only a few years ago. The key tool available to customers and managed service providers to retain control of licensed capacity is Oracle s concept of hardware partitioning. On commodity x86 hardware, only Oracle VM for x86 and Solaris x86 are contenders for implementing hardware partitions, no matter how much customers tend to gravitate towards VMWare or Hyper-V. Always adopt my principle of Licensable Environment as your guiding light. Cloud requirements need to be scrutinised to establish the underlying context. In some cases special principles apply, but often the matter will be resolved into the virtualisation or partitioning arenas, and rules for those must be applied.