Solaris

My understanding is that Oracle DB licensing is based on number of cores etc. If you use virtual machines (e.g.ldoms) you need to partition it properly otherwise, in theory you have to pay based on the host machine.

Can anyone confirm I'm right here? And explain it in bit more detail (i.e. things like multipliers etc).

We've got 4 T5-4s running Solaris 11. Each has a number of Ldoms some running Oracle DB some not. At the moment its all a bit of a mess to be honest.

It's been several years since I encountered this, but it is based on number of cores and core type, on the base hardware, plus user count. So you do not get into serious licensing problems, there is a support group at oracle that works on this problem.

Do not try to figure it out by yourself. Oracle has the legal right to run unannounced audits on their product's installation and run modes.

They will send you software to run as the root user on Solaris. It creates two files, as I remember. Oracle analyzes the output and then gives you precisely what you require for licensing.

The reason it is a mess, IMO, is that you can purchase oracle under several different licensing regimes, e.g., per user seat versus per core. And you can play mix and match. We actually were over licensed and saved about $US90k per year.

Thanks Jim - its even more confusing when you've ldoms involved.

Of course, if you've got multiple ldoms on, say a T5-4, with only one of these ldoms running oracle you dont want to pay a licence for the entire server.

---------- Post updated at 08:44 AM ---------- Previous update was at 07:25 AM ----------

Thing is if its a physical server all well and good but how does it work with virtual machines?

You might have a physical host with, say 2 cores, but this translates to 16 VCPUs that the ldoms use. Support an LDOM runs Oracle, and is partitioned to use just 4 VCPUs how does the licencing work then?

I am not that fit in Sun/Solaris at all, so bear with me if this is not relevant, but:

In AIX there is "Live Partition Mobility", meaning you can transfer a running virtual system from one hardware to another.

You buy licenses based on the cores of the virtual machine (instead of the underlying hardware nodes) as long as this number of cores is absolutely fixed (we call this "capped mode" and it is highly unusual otherwise). But when the LPAR is LPM-enabled and you use that feature you suddenly not only pay for all the cores in the source system but also all the cores on the target system too. LPM can be a cost-intensive activity this way. You had a 4-core LPAR and moved it from a 64-core hardware to another 64-core hardware - 128 processors to license.

The problem is that DB/2 license politics is even weirder than that and you can't even tune the damn thing as well as Oracle. Perhaps best is to search for one of the freeware databases (Mariah, ...), but i have no idea how well they scale in real big installations. My biggest DB system (one LPAR!) has ~4TB of RAM and 128 12-core processors. You hardly have such a system available to test-drive an alternative DB.

I hope this helps.

bakunin

You are making it complicated. And I do not think you fully understand it. Neither do I.

Go to oracle. Call your sales rep if nothing else. Get help. Period. Anything else will cost you a bundle of money later on if you make a mistake. I'm not kidding. A neighboring (near New Mexico) utility did not get licensing straight because they "knew" how it should be. They needed to upgrade and had to get oracle's help. That's when things got financially ugly for them. Audited. The bottom line of the final bill would have set up all of the people whose usernames are red on this forum with magnificent retirement package. I think they compromised, I do not know for sure.

How else do you think Larry Ellison was able to buy his very own island?

Do not assume how you want to count usage, or what you think is logical.

In a nutshell you must :

1. Put a whole-core constraint on ldom -> using set-core for number of cores paid.
If you have say, 16 VCPU, that's 2 core on T5-4, so you will use that number and set-core option, instead of set-vcpu.

2. Use a max-cores constraint with maximum number of cores paid.
3. Live migration is not to be used (this is quite dumb in my opinion).

T5-4 will cost you a 0.5 factor per core (this document is kept recent) :
http://www.oracle.com/us/corporate/c...ble-070634.pdf

Factor here is type of software (enterprise, standard db etc.)
A document with list prices :
http://www.oracle.com/us/corporate/p...ist-070617.pdf

So if you assign 2 core (set-core and max-cores) on ldom on T5-4 machine, you will have to pay oracle 1 processor licence to be compliant.

All above is subject to a change, so one should pay attention to those documents above every licence cycle.

Hope that helps
Regards
Peasant.

Thanks Peasant - I've been reading the docs and this is my understanding also.

My current client it appears, is using ldoms with oracle instances on but its NOT partitioned properly. Oh dear.

Also, how does named user plus work in a virtual environment (is it even allowed?). I understand its cores x users per licence. Can you still use a virtual partitioned core?