How to manage Named Users (Part 2)
March 8, 2011 2 Comments
By Paul Bullen, Technical License Consultant at Rocela
In the last post, we started to explain the Named User-type licenses by defining the term. And we also started to look at how understanding it’s measurement can make all the difference to taking full advantage of this Oracle licensing metric.
In this post, we move on to consider some of the complexities of this licensing metric in more detail. We look into questions such as; how do you measure Named Users, and what is the best way to track Named Users?
Hopefully, you’ll remember from the last post that Named User licenses apply to individuals or devices interacting with the Oracle software on your servers. So you should be able to measure them easily from your databases, right?
Well, despite appearing easy and intuitive, measuring Named Users generically based on databases is actually a dead-end. We’ll look at why in a second.
Oracle databases have a users table (dba_users). You may think that you can simply find out the number of users recorded in this table and use it as your Named User count for that database. Unfortunately, as with many things Oracle, it’s not that simple. These database user accounts do not map 1:1 with Named Users, and there is no flag to classify users.
In order to prove this, we’ve just logged on to a small test database. In this database I’m the only Named User, however it has 21 database user accounts. The example below demonstrates what a list of database users could look like in this instance:
- app_user: used by an application server, which actually allows 250 Named Users to connect as one user identifier (this is a ‘multi-plexing front-end’ in Oracle’s terminology)
- app_object_owner: an account which stores application objects, and could be used by anyone in the application support team or the database administration team
- system: an account which is used for database administration, so there could be a number of people using this single account
- paul_bullen: maybe this is an account that maps to a single Named User account. However, if this user was to give his password to someone else, two Named User licenses would be required
- paulbullen02: this may be the same Named User as ‘paul_bullen’ but there may be an additional user
This example should point out that you cannot reliably or generically measure Named Users from a database. You may be lucky and have an application, which holds Named User-type information (SAP is a good example), but you still need to consider the non-application user accounts in the database.
If you really want to get your measurement and reporting on this licensing metric up to scratch, it’s time to start looking at users in more detail on an application basis. To do this you have to realise that counting Named Users is a matter of knowing your application architecture and the individual users of the application thoroughly.
Your knowledge of application architecture and the individual users of applications is what Oracle is gambling against with its licensing metrics. And this is exactly how you can win, by making a few strategic decisions up front. You should ask yourself; am I going to be able to accurately count and track Named Users? You need to be clear on the answer, as Oracle requires you to purchase the (typically) more expensive processor license if you cannot count your Named Users properly.
A simple example of how it should be done:
The diagram above shows the way you should approach simple Named User calculations: count the users of the system (including devices which access the database) and any people who have access to the database. All of them have to be counted regardless of the architecture of the infrastructure.
In this instance, the diagram indicates that you will need licenses for 68 Named Users (ignoring minimums). It is critical that the number of people using the system in each department is tracked. So, you have to be very clear on how you’ll monitor things such as employees leaving or joining the company. You will also have to take into account things such giving an additional department access to the application: each ‘user-related’ decision will have an effect on the total number of Named Users licenses.
This is just a simple example, and you have to remember with more systems, more users, more servers and user minimums to consider it can be very complicated to keep track of Named Users. But doing so is vital in order to understand your compliance position, not to mention save costs.
In Part 3:Next week we’ll look at Named User minimums, some potential pitfalls and what ‘multi-server’ Named User licenses mean.
For now, if this post has struck a chord with you, do add your thoughts in the comments.