Oracle seems to have changed something in their licensing policy because in two recent cases I have heard of companies being able to license Oracle on a per host basis in stead of per cluster.
I have heard this now in two seperate instances with one person mentioning that this had changed in the last months because of Oracle’s own initiatives with virtualization. If anyone has recent info I am very interested if there has been a change in Oracle’s licensing policy.
Just like IBM for Websphere licensing there are all sorts of issues with licensing Oracle when used in a virtualized environment. Because the advantages of virtualizing Oracle outnumber the disadvantages in my experience so far it is highly recommended to specifically address the licensing consequences and the possible influence that this has on the final design. This prevents any nasty surprises afterwards when you get an Oracle licensing audit.
Example 1:
Company X has 20 physical servers with two dual core processors running 15 times Oracle database and 5 times Oracle Application Server (IAS). Their planned host cluster consists of four DL580’s with four quad core CPU’s running a mixed environment. Currently they have licensed 15 x 2 x 2 x 0,5 = 30 CPU’s database and 5 x 2 x 2 x 0,5 = 10 CPU’s Application Server. The processor metric for the new situation will become: 4 x 4 x 4 x 0,5 = 32 CPU’s for database and IAS. This means they have to license two extra CPU’s Oracle database and 22 extra CPU’s IAS. This would mean an extra cost of $80000 for the databases and $660000 for the IAS licenses.
Creating a two-node cluster for Oracle VM’s to get around the licensing issue they calculate they need an extra cluster host for the “other” servers making the total tot 5 hosts. This will cost an extra server + VI license but will have a positive effect on Oracle licensing by reducing the number of processors to: 2 x 4 x 4 x 0,5 = 16 CPU’s database and IAS.
This means they save 14 x $8800 in annual maintenance and support fee for the database vs. an additional investment for 4 CPU’s IAS at $30000 per CPU and $6600 per year in maintenance and support which means they can expect an ROI within roughly two years.
Example 2:
Company Y has five physical servers with two dual core processors running Oracle database software. In Oracle processor metric they need to license 5 x 2 x 2 x 0,5 CPU’s = 10 CPU’s. They want to virtualize these servers to one HP BL480 blade server with two quad core CPU’s. The processor metric for this server is 2 x 4 x 0,5 = 4 CPU’s. However if that one server fails than everything is gone. So they plan a second BL480 in a cluster making the total processor metric 2 x 2 x 4 x 0,5 = 8 CPU’s. This means 2 CPU’s less than they have currently licensed saving $8800 per CPU per year in maintenance and support (before discount).
Compared to the investment needed in extra hardware and VI licenses there would need to be significant other factors like a high valuation of the increased resilience of the environment (because of the added failover capacity) to make this business case work.
Disclaimer: These are theoretical examples based on my experience with Oracle licensing, please discuss your licensing needs with your local Oracle rep.
Please note that the posts regarding Oracle licensing have been pulled offline following a request by my former employer.
I will be writing a “lessons learned” post about our project in the near future but for now I will follow up on the Oracle problems we had last month.
What we learned from using Oracle in a VI environment is that memory settings turned out to be highly critical in relation to the performance of the VM. We didn’t have this problem on a physical machine, at least not as intrusive as this, but when Oracle doesn’t have enough memory available it starts very heavy swapping to the virtual disk. This results in a 100% CPU load and processes start to hang with an unresponsive application as the result for the users.
Adding memory to the amount the server needs (indicated by checking the swapsize in the VM) has fixed these problems.
I shouldn’t be writing that all is well on the Oracle front.
Just now two of the Oracle servers froze with database problems. The DBA tells me that they have block corrupts which he hasn’t seen in five years of running the things.
More later.
{edit}
Both instances were terminated by PMON due to unreadable
logfile or spfile. The errors look like this;
ORA-00471: DBWR process terminated with error
PMON: terminating instance due to error 471
Instance terminated by PMON, pid = 26973
ORA-00470: LGWR process terminated with error
PMON: terminating instance due to error 470
Instance terminated by PMON, pid = 25260
One instance is a 9.2.0.4 database, the other a 10.2.0.1 database, on separate virtual machines.
For Oracle 9i: Restore from backup.…
For Oracle 10g: Resetlogs by:
startup mount
recover database until cancel;
recover database until cancel; (a message ‘media recovery complete’ will appear)
alter database open resetlogs;
We are viewing this as an unfortunate incident at the moment but will keep monitoring this closely.
So last weekend we migrated all the Oracle servers. After multiple issues with PowerConvert (it doesn’t clean up after itself properly if a migration fails) we eventually managed to convert an Oracle 10g, Oracle 10g AS and an Oracle 9iAS server. The others were re-installs.
It seems that there still is some ways to go on the Linux conversion front to make it a truly user-friendly application. Although we couldn’t have done it faster by hand it is kind of frustrating to see your migration fail time after time because of problems during copying or the program simply freezing up when it’s trying to take control.
On the Monday it turned out that our estimate for sizing the production 9i databaseserver was a bit on the cheap side (1 vCPU / 3GB memory) so we had to add a second vCPU. Oracle also likes it better when it can run an SMP kernel and it seems to hold up. We may upgrade the memory to 4GB but everything else works fine.
Also yesterday we converted our Oracle 10g Grid Control server. This is the server that we use for managing our Oracle databases and to which all these servers write their backup and archiving data (in practice: all servers have their archive and backup folders mounted to the management server).
As this server was still using direct attached storage the bulk of the conversion time went into copying all the backup data to the designated storage tier. Then the machine was PowerConverted and the backup and archive mounts on the database servers refreshed.
This morning we noticed that the machine was using just 11% of the allocated 3GB so we slashed that be 50%.
A much easier conversion was that of an Oracle AS (Application Server) server. This was just PowerConverted without problems. This morning we decided to shrink the memory allocated to that machine from 3GB to 1GB as it was just using 6% of it’s memory.
Documenting a virtualization project 