Oracle core factor table

-

What is oracle core factor?

Oracle core factor refers to a weightage of licensing that oracle enforce on its software, based on the underlying server infrastructure it is running on. A simple example is when running Oracle database on 4 core AIX POWER 8 system customer should license for 4 database core licenses where as if the database software is running on 4 core SPARC T4 server, customer should only license for 2 database core licenses. This is because core factor for SPARC is 0.5 and it is for POWER is 1. Below is the full core factor table published by Oracle on 29th July 2019. http://www.oracle.com/us/corporate/contracts/processor-core-factor-table-070634.pdf

Why core factor is important?

Given the enormous cost involved with Oracle licensing (e.g List price for Oracle enterprise edition database per core is $47,500), it is vital to plan the correct hardware infrastructure considering all the aspects of a deployment. Even with the engineered systems such as Exadata Oracle does have a core factor of 0.5.

Oracle core factor and hyperthreading

Above table does include all core factor values for each hardware platform. But in order perform oracle licensing calculation it is required to identify the exact number of cores we are utilizing. This becomes bit complex with all the virtualization technologies and processor threading technologies. If we take an Oracles own SPARC T7-2 server which comes with 64 M7 cores, normally this box will be split in to multiple logical domain (LDOMS). And if the Oralce database is running on one particular LDOM which is hard partitioned with 8 SPARC cores we only need to procure 4 Oracle database licenses.

License Calculation = (Number of core assigned to db ldom) * (core factor) = 8 * 0.5 = 4 

 If the LDOMS are (Or LPARS if IBM) hard partitioned as per the Oracle requirements, (Basically if the LDoms are hard partitioned you cannot increase the cores assigned to a logical domain without a restart) it is not required to license the whole box or the all 64 cores. Oracle Licensing with hyperthreading also needs to be reviewed carefully. Normally intel processers with hyperthreading enabled still considered as 1 core in physical level (Even though they can have multiple threads). But it is always a good idea to confirm that your configuration for license compatibility with Oracle it self or from a third party SAM (Software Asset Management) consultant.

Oracle core factor in AWS cloud

How to calculate the Oracle core factor in AWS? Well It depends on the licensing method you have chosen and the cloud implementation methodology you are using. In case of AWS, if you are doing Oracle database installation on top of AWS IaaS layer, i.e ec2 it is basically similar to licensing calculation to be done on on prem server with extra consideration to number of vCPUs allocated to the ec2 instance. If implementation is using AWS Oracle RDS which is Oracle PaaS offering then there are two options. If you choose the BYOL (Bring your own license) option where again oracle licensing calculation needs to be done based on the RDS instance class and the number of cores allocated. Other wise you can opt to pay AWS including the Oracle licensing cost, so AWS will bill you including the required licensing cost based on your RDS usage.

Conclusion

Oracle Licensing calculation can be tricky and complex area considering all the effecting metrices including the Oracle core factor table, virtualization, cpu core threading and cloud implementation. As mentioned above it is always better to periodically verify and confirm license compliance of Oracle implementation stack with help of Oracle or third party which does provide SAM consultation services.
Oracle Core Factor Table
Oracle Core Factor Table

Comments

Post a Comment

Popular posts from this blog

ORA-16433: The database or pluggable database must be opened in read/write

-
Image
ORA-16433 is an error returned when a database cannot be opened. This can be a result of multiple conditions including, The inconsistency of the database Physical corruption Loss of dependent files or access issues etc.. More often than not the solution is to recover from available backups, but there can be situations where backups are not available, specially on UAT or Test setups. Although not the ideal scenario, in this type of situation you might want to open the databases even with inconsistency.  In Comes --> _ALLOW_RESETLOGS_CORRUPTION First, if you are in a position to use _ALLOW_RESETLOGS_CORRUPTION=TRUE, that means it has to be a critical moment, and when you come across more ora- errors while you are trying to reopen the databsae, that can be annoying. Note - _ALLOW_RESETLOGS_CORRUPTION=TRUE must only be used after Oracle support confirmation as a last resort. Also make sure to take cold backup before proceeding. Basic steps to be followed to resolve ORA 16433 af...
Read more

Oracle Multitenant - Create new service for PDB using DBMS_SERVICE

-
Image
When an Oracle PDB is created it starts up a default service with the PDB name. For direct connections to    PDB this service can be used. But there are situations where new service name is required in PDB level, common example is after a PDB restoration/clone, in order to enable application connections without changes in connection string. Setting service_names parameter in PDB level is not possible hence it is not an option in multitenant setup. How to create a new PDB service on Oracle 12C Check the current services, here only the default service is running, SQL> show pdbs; CON_ID CON_NAME OPEN MODE RESTRICTED ---------- ------------------------------ ---------- ---------- 3 NFACTORPDB READ WRITE NO SQL> select service_id, name, pdb from dba_Services; SERVICE_ID NAME PDB ---------- ---------------------------------------- ---------- 7 nfactorpdb NFACTORPDB SQL> ...
Read more

Wait for unread message on broadcast channel - Blocking Sessions

-
Image
What is Wait for unread message on broadcast channel wait event? Wait for unread message on broadcast channel is a wait event where source destination communication is involved and the database is waiting for a reply from remote party. Mostly this wait is seen related to data pump export (expdp) or import (impdp) operations. Although categorized in idle wait class "Wait for unread message on broadcast channel" can become the blocking session for some other sessions. Common causes for stuck sessions waiting on this wait event includes, Broken databases links, where remote database is not responding. Abnormally killed remote processes causing the sessions to wait. When a session is waiting on "Wait for unread message on broadcast channel" it can become a blocking session for dependent sessions. Most probably these sessions will be waiting on "library cache pin" or related concurrency wait events. The blocking_session column of (g)v$session view...
Read more