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

ORA-14126 - While splitting max value partition

-
Oracle version -- Oracle 9i to 11g While splitting partitions, SQL> alter TABLE ARBOR.CDR_BILLED split PARTITION CDR_BILLED_MAXVALUE at (TO_DATE('2014-09-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN')) into (partition CDR_BILLED_01SEP14,partition CDR_BILLED_MAXVALUE) TABLESPACE "C01_CDR_BILL" update global indexes; 2 into (partition CDR_BILLED_01SEP14,partition CDR_BILLED_MAXVALUE) TABLESPACE "C01_CDR_BILL" update global indexes * ERROR at line 2: ORA-14126: only a <parallel clause> may follow description(s) of resulting partitions 4:58:56 PM The reason for above error is while splitting max value partition, it is not allowed to explicitly provide a tablespace. The splitted partition will be reside on the same tablespace as the max value partitions. Below can be used without the tablespace clause to split the max value partition, alter TABLE ARBOR.CDR_BILLED split PARTITION CDR_BILLED_
Read more