Wednesday, March 4, 2009

Partitioning: Oracle Licensing Terms & Agreements

When questions about Oracle licensing comes up, things can get rather puzzling.

How is one to determine license liability?

Single-Core vs Multi-Core Processors

Sometimes, there are web pages which help to determine liability with single and multi-core processors.
http://www.orafaq.com/wiki/Oracle_Licensing

Multi-core processors are priced as (number of cores)*(multi-core factor) processors, where the multi-core factor is:

  • 0.25 for SUN's UltraSPARC T1 processors (1.0 GHz or 1.2 GHz)
  • 0.50 for other SUN's UltraSPARC T1 processors (e.g. 1.4 GHz)
  • 0.50 for Intel and AMD processors
  • 0.75 for SUN's UltraSPARC T2 processors
  • 0.75 for all other multi-core processors
  • 1.00 for single-core processors
This may help guide towards a decision (i.e. if you need half of T2 processor for an application, there is a 50% discount when one purchases a system with a T1 processor for running Oracle.)
  • 8 (T1 cores) * .25 (multi-core 1.2 GHz T1 factor) = 2 (pricing factor)
  • 8 (T2 cores) * .75 (multi-core 1.2 GHz T2 factor) = 6 (pricing factor)
Examples of low-end T1 based systems include:
A T1 platform is a GREAT platform for deploying a basic development or test environment or a development or test clustering environment, where full fledged performance is not required, but binary compatibility is desired with SPARC applications.

Building applications which scale well on a T1 platform will offer excellent performance when the application needs to scale up with larger number of cores or processors, since it will be more likely to scale linearly since the CoolThreads cores will scale linearly in performance.

Partitioning Technologies

There are three primary partitioning technologies with Open platforms:
  • Dynamic System Domains
    Available for mid-range to high-end SUN and Fujitsu systems
    Allows for Solaris 8, Solaris 9, Solaris 10, and Solaris Express operating systems
    M4000 for up to 2 Dynamic System Domains
    M5000 for up to 5 Dynamic System Domains
    M8000 for up to 16 Dynamic System Domains
    M9000 for up to 24 Dynamic System Domains

  • Logical Domains or LDOM's
    Available for low-end to mid-range SUN and Fujitsu systems
    T1 Processors for up to 32 LDOM's
    T2 Processors for up to 64 LDOM's
    T2+ Processors for up to 256 LDOM's

  • Solaris 10 (capped) Conainers
    Solaris 10 Containers are available across all SUN & Fujitsu platforms
    Using BrandZ - Linux, Solaris 8 and Solaris 9 Operating Systems can run in Solaris Branded Zones
Partitioning with Oracle

There is a lot of mis-information about partitioning flooding the internet. The best place to go for information regarding partitioning is Oracle's web site. The following document is dated from 2002 and is still posted as current, as of the publishing of this blog entry.
http://www.oracle.com/corporate/pricing/partitioning.pdf

(page 1)
Soft Partitioning
...
As a result, soft partitioning is not permitted as a means to determine or limit the number of software licenses required for any given server.

(page 2)
Hard Partitioning

Hard partitioning physically segments a server, by taking a single large server and separating it into distinct smaller systems. Each separated system acts as a physically independent, self-contained server, typically with its own CPUs, operating system, separate boot area, memory, input/output subsystem and network resources.
Examples of such partitioning type include: Dynamic System Domains (DSD) -- enabled by Dynamic Reconfiguration (DR), Solaris 10 Containers (capped Containers only)...

Partitioning Examples:
A server has 32 CPUs installed, but it is hard partitioned and only 16 CPUs are made available to run Oracle. The customer is required to license Oracle for only 16 CPUs.

Very clearly, costs can be reduced by using Dynamic System Domains of high-end SPARC systems as well as Solaris 10 (capped) Containers on low-end to mid-range systems.

Other Helpful Oracle Guides
Partitioning & Architecture for Disaster Recovery and Development

With a T2 system being roughly twice the throughput of a T1 system, a low-end T2 makes a good production system which can scale up with a lower initial cost, leveraging hard partitioning options like LDOM's or Solaris 10 (capped) Containers.

For example, the following systems offer similar performance (omitting floating point applications):
  • 8 (T1 cores) * .25 (multi-core 1.2 GHz T1 factor) = 2 (pricing factor)
    A full system, no partitioning
  • 4 (T2 cores) * .75 (multi-core 1.2 GHz T2 factor) = 3 (pricing factor)
    Solaris 10 (capped) Container used to provide half the number of cores, leaving half the cores for later expansion
  • 4 (T2 cores) * .75 (multi-core 1.2 GHz T2 factor) = 3 (pricing factor)
    SPARC CoolThreads LDOM's used to provide half the number of cores, leaving half the cores for later expansion
As greater performance is needed with applications, the appropriate number of cores can be added to a T2 system, in order to provide higher capacity in affordable quantities.
  • 1 (T2 cores) * .75 (multi-core 1.2 GHz T2 factor) = 0.75 (pricing factor) = 1 (rounded up)
  • 2 (T2 cores) * .75 (multi-core 1.2 GHz T2 factor) = 1.50 (pricing factor) = 2 (rounded up)
  • 3 (T2 cores) * .75 (multi-core 1.2 GHz T2 factor) = 2.25 (pricing factor) = 3 (rounded up)
  • 4 (T2 cores) * .75 (multi-core 1.2 GHz T2 factor) = 3 (pricing factor)
  • 5 (T2 cores) * .75 (multi-core 1.2 GHz T2 factor) = 3.75 (pricing factor) = 4 (rounded up)
  • 6 (T2 cores) * .75 (multi-core 1.2 GHz T2 factor) = 4.50 (pricing factor) = 5 (rounded up)
  • 7 (T2 cores) * .75 (multi-core 1.2 GHz T2 factor) = 5.25 (pricing factor) = 6 (rounded up)
  • 8 (T2 cores) * .75 (multi-core 1.2 GHz T2 factor) = 6.00 (pricing factor)
As you can see, scaling up or down an LDOM or Solaris 10 (capped) Container to isolate Oracle license costs can be very effective to control business costs according to capacity need... except some choices may not make a good decision from an economic standpoint (i.e. 3 or 7 cores.)

The T2 may make a great consolidation platform for a Disaster Recovery platform, that could double as a Development Platform, by "scaling down" the number of cores in a container.

No comments:

Post a Comment