IBM to create 24-core Power chip so customers can exploit Oracle database license IBM has quietly announced it's planning a 24-core Power 10 processor, seemingly to make one of its servers capable of running Oracle's database in a cost-effective fashion. A hardware announcement dated December 13 revealed the chip in the following "statement of general direction" about Big Blue's Power S1014 technology-based …
Kind of surprised they haven't already. I moved a company from Oracle EE to Oracle SE back in about 2008 for exactly this reason(did so as a result of the company failing their 2nd Oracle audit, after ignoring my advice to make this change after failing the first Oracle audit which they were caught for running Oracle EE when they only had a license for Oracle SE One, not even SE, SE ONE). I remember buying our servers for Oracle EE I opted for the fastest dual core processors, by the time we switched to SE quad core had come out so I changed them to single socket quad core. Even encountered a compatibility issue on our early DL380G5s when upgrading to quad core they didn't work without a motherboard replacement, HP later realized this and updated their docs. I don't think they charged us for the replacement since they told us it would work when we ordered the new parts, and it was their staff doing the hardware change. I remember AMD talking shit about Intel's quad core chips not being true quad core but a pair of dual core chips(early version of "chiplet" maybe?).
Also remembering having to "school" Oracle's own auditors regarding Oracle SE licensing specifically regarding the unlimited cores per socket which they didn't believe until they looked it up themselves and their hearts sank when they realized they could not do per core licensing on that.
Back then you could run Oracle Enterprise Manager with the performance tools(which were great IMO) on Oracle SE, even though technically you could not from a licensing standpoint(can only use it on Oracle EE). If they ever audited again I could easily uninstall OEM with a simple command(which I had to do regularly for various reasons on test systems). Newer versions of Oracle made this trick impossible(at least for me). Oracle did not audit again before the company shut down. Note: I am not a DBA but sometimes I fake it in my day job.
Also did the same for some of our VMware hosts, VMware at the time required purchasing licensing in pairs of sockets, and they said they did not support single cpu systems. Though I assumed at the time that really meant single socket single core.
Then I combined the two, at least in a couple of cases, Oracle and Vmware on top of a single socket DL380G5 with a quad core CPU and I don't remember how much memory or disk, some of the systems were connected to my first 3PAR, a tiny E200. Probably totally unsupported by anyone officially, Oracle's policy at the time is you had to reproduce the issue on a supported system. But I don't recall ever having to open a support case with either company while I was there, at least not on the ones running on VMware, did have some support cases for production which ran on bare metal.
At the time Oracle SE was max 2 sockets per system(no core restrictions) and max 4 sockets in a RAC. Haven't looked at their model since but it sounds like it's probably the same today.
Yeah kind of surprised they didn't develop some sort of simple benchmark that would assess the power of a core and charge based on the total power of a system, similar to how IBM mainframe software used to charge based on 'MIPS'.
Charging per socket is a fool's game as we keep getting more and more cores, and the packaging advances creating stuff like Apple's M1 Ultra will mean everyone will be combining multiple chips into one. A single "socket" will have more cores than the biggest HP Superdome and Sun Ultrasparc servers of a couple decades ago.
Oracle have done exactly that. Here's their document defining the "core factor" (pdf).
Most Oracle licensing is "per named user" or "per core" (subject to the core factor) - SE2 is the exception with the "per socket" license, but it has baked in limitations such as a maximum of 16 CPU threads per database instance, and a maximum of 1 CPU thread for export/backup operations.
Yes. Where I work, we're licensed by CPU core, not per seat (which would be difficult bearing in mind what the systems do, which is completely transactional) nor per socket. And these systems are just too large to fall into the smaller tier. If we went to per-socket licensing, we would have to have licenses for all the sockets, regardless of whether the cores were associated with Oracle LPARs or not (and many of them aren't).
For some seriously annoying reason, Oracle are not prepared to allow the client whose environment this is to buy additional licenses, and we've been juggling dedicated cores between systems assigned to LPARs for a couple of years to try to keep to the already purchased licenses.
> Charging per socket is a fool's game... than the biggest HP Superdome
Of course for the Superdomes, or at least those with the Itanic, Oracle charged per core and even per thread. We had to disable the hyperthreading because it only gave about a 25% performance boost but doubled our license costs. Ouch
An Oracle SE2 license allows use on up-to two socket systems, with an unlimited number of cores. Each database instance is limited to using a maximum of 16 CPU threads, so in a 2 x 96-core EPYC system, so you'd need to be running 12 concurrent instances to get Oracle to use 192 threads. (There are other nasty limitations baked in, such as a maximum of 1 CPU thread can be used for exports/rman-backups, which makes them impractically slow for larger DBs).
But if you look at the work done by the last 4 threads (depending on workload), they very rarely do anything even on a busy system, because the instruction re-ordering is good enough such that four threads will normally consume all the execution units (this is dependent on the mix of instructions in the processes). The way that the execution unit scheduling is done by the hardware thread scheduler means that all hardware threads are not equal, with a decreasing priority, so that for each core, there is one preferred thread, a less preferred secondary thread and so on down to hardware thread 8 , which is the least preferred, and gets almost no time because all the execution units are in use by the other more preferred threads. If you look an the NMON graphs from any of the analyzers, this is very clear.
IIRC, Oracle will accept Power systems running in SMT4, 2 or even 1 as a reduction in number of threads per core for the purposes of their license calculation. We run our Oracle systems at SMT 4, and even at that, the last hardware thread is normally showing little work actually scheduled.
Worth noting that the driver for SE2 licensing by socket (rather than Oracle standard per-core) are [1] Microsoft SQL/Server licensing and [2] Oracle's own SPARC servers (large number of relatively puny cores).
Expect to see announcements about SQL/Server on Power chips and dynamic configuration of core count per LPAR
at my last $job, at a $bigcorp, we kept replacing Oracle instances with PostgreSQL, yet somehow our Oracle total corporate bill remained relatively flat. I'm firmly convinced they'd decided via forensic accounting that 'we' were good for $xx million/year, and would adjust our per cpu instance fees to keep up that rate. This was over a 20 year period, although it took about 10 years before the postgresql replacements started ramping up into the larger deployments. The rank and file production operations folks loved it because they didnt have to worry about licensing or server sizes, they could deploy as needed. upper executive management thought they needed service contracts on everything and were less happy, as they didn't want inhouse subject experts.
Yep, thats what Oracle does.
I was the IT Director at a large eductional establishment in the 90's, we moved off a IBM PIC system onto Sparc E450 running Oracle. I recall it had two CPU's and a decent amount of memory at the time. Mindy you, this is over 25 years ago so my memory might be playing me false.
I do recall that Oracle had changed their licensing terms but it was so complicated that I couldn't work out how much we should pay being academic. My background was special maths so highly complex forumula should have presented zero issues :) Anyway, after working through it backwards, forwards, inside and out, and getting nowhere, I got the Oracle rep in and told him to tell me what my bill was, we didn't keep anything hidden and it was simply an E450 (and probably a back up smaller server), after a few hours he gave up and we said "same as last year?", he agreed and that was it.
he got the same revenue stream as before, we paid the same as before, we were all happy.
Now these days, we are actively managing Oracle out of the Enterprise. We have a lot of legacy Oracle in, but Postgres and to a lessor extent SQLServer is taking over. Postgres is great, its cheap, it scales enough for us, it works well, the devs and devops love it. We love it as the bills are 1% of Oracle, as far as we're concerned, Oracle is a large parasiticial compnay dedicated solely to getting Larry a new yacht every year. Fuck em, paid that tax for too many years, they can burn in hell for their licenses.
re: I think that Oracle will not tolerate this for long
We've been using SE2 since it came out in 2016(?), and even back then we were running on the biggest core counts available, so its not as if Oracle are "blindsiding" anyone. 16 threads is more than ample for our workloads, and *each* SE2 instance gets 16 threads, so you can run multiple SE2 instances on the same machine.
Single thread backups are an annoyance but storage snapshots are our workaround for that.
SE2 works well for us, and DBVisit are a good option to look at EE style features to add to your SE2 systems.
It is not right to license software and charge extra for running it in faster kit.
It just smacks of the USA companies just milking there users.
You would think that the revenue today is enough otherwise they would have put their prices up previously.
Imagine buying a car upgrading the radio and finding you have to now pay ford because you made the car better.
I agree, and pay extra car features are a thing of recent years that should be equally ridiculed.
The solution is to stop buying this shit. Oracle has been a shitshow for about 2 decades now (I get why you bought it in the late 90s - so did I. Decommissioned maybe 7 years ago or so.)
No shortage of suitable alternatives.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
