May 9, 2011 2 Comments
By Paul Bullen, Technical License Consultant at Rocela
Last time we looked why the ‘multi-server’ domain may require more management. Today, we’re going to look at database editions and options.
Database editions and options
It’s worth pointing out here that there are further complexities to consider – each Named User should be allocated a license for each product they use. So, if a user is accessing an Oracle Enterprise Edition database with the partitioning option, they need a license for both products.
Likewise, Named Users accessing Standard Edition (or Standard Edition One) databases will need both a Standard Edition and Enterprise Edition database license if they have access to each edition.
Combining these database options and editions with server-based minimums (below) and multi-server access only serves to make managing Named Users even harder!
The best approach for database options is to consider teams of people by role. This can be done by grouping people by their access to services. You can map those services to database servers, determine what products each role will require a license for and then consider whether these users access other systems with the same, or lesser options.
Going back to our database administrators we mentioned earlier—as they have access to all database servers in the estate, they will need a license for every product in use across that estate.
This process is not trivial, and unfortunately this is one of the most complicated aspects of Named User licensing. As with all Oracle licensing, the onus is on the licensee to ensure access is controlled, monitored and managed appropriately—you must understand how your Named User licenses map to your user estate and the products actually in use.
The diagram below shows a simple example of this with two role-based groups of users. In the middle are three different database servers these users can potentially access, each with a slightly different combination of Oracle database and options.
The call centre staff on the left are only able to access the top system (according to their licenses—there is nothing technically stopping their access but this would be against their entitlement), however the data warehouse users are able to access all three systems. Should all the call centre staff require access to either of the other systems, their entire user population would need the additional purchase of Partitioning and possibly Data Mining.
Oracle, famous for its complex licensing models, has added an associated minimum on these metrics based on hardware specifications, an element which must be measured and tracked in order to track correct usage.
The minimum Named User Plus for Oracle Enterprise Edition Database is 25 per ‘processor’. The word processor here refers to an Oracle calculated processor—this is a function of the number of cores per processor, the total number of processors and the type of processor (we’re ignoring anything like virtualisation at this stage). Once this value is calculated, each server must have at least the minimum of 25 per processor applied.
So, let’s take a ‘simple’ example. I have a Sun M3000 server, with 4xSPARC VII processors. Each processor has 2 cores. So there are a total of 8 cores in this server. According to Oracle’s core-factor table, the SPARC VII processor has a core factor of 0.75. So 8 cores with a core factor of 0.75 gives 6 Oracle ‘processors’.
With a minimum of 25 Named User Plus per ‘processor’, this server would be subject to a minimum of 150 Named User Plus. We cannot allocate any less than 150 Named User Plus to this server, even if the user population for the database(s) on this server is less. However, if there are 200 individuals (as defined by the Named User Plus metric) for these databases on this server, we would have to purchase 200 Named User Plus to the server.
Named User minimums and Oracle ‘processors’ are a separate subject in themselves, however the above gives some guidelines as to what must be allocated.
Summary of Named User licensing
Over the course of four blog entries we have looked at Oracle’s Named User metrics. This should give an indication of the amount of effort and understanding required to properly use this metric.
We have not considered all aspects of these metrics in these posts—there are plenty more nuances (such as batching, minimums according to database editions, older metrics) – but Named User Plus licensing offers some huge cost benefits if used properly, however this comes at the cost of managing the user population and ensuring correct levels of coverage. The key messages to take away from this is:
- Named User metrics can be much cheaper than processor
- Named User metrics need management
- Named Users can rarely be accurately measured from your databases
- Count individual people or devices, group them by role and the services/products they have access to
- Manage these users and your pool of licenses
- Seek expert advice to understand your usage and license entitlement better
It’s clear that the Named User metric is extremely complicated. But there is potential for your organisation to reduce its financial risk by ensuring Oracle licence compliance. By know how the Name User metrics work you can also place yourself in a better position to negotiate with Oracle and ultimately manage your investment better. If in doubt, there are always expert consultants available to help you and your organisation.