Former Oracle execs warn that Big Red's auditing process is also a 'sales enablement tool' A group of former Oracle executives with roles across its software compliance teams have described the close links between Big Red's auditing process and its drive to increase revenue. Speaking during a webinar broadcast last week, Adi Ahuja, senior director of Palisade Compliance and former Oracle licence management services …
If you're truly "really big", and it's mission critical, you've probably got a team of just legal people working around these issues before they arise. If you're only slightly big, you almost certainly have alternatives, mission critical or not.
https://aws.amazon.com/blogs/aws/migration-complete-amazons-consumer-business-just-turned-off-its-final-oracle-database/
If Amazon can get rid of Oracle, internally, then I'd wager 99.9% could get rid of Oracle. How many e-tailers are bigger than Amazon? Not many.
Unlike Amazon, if you are large but not that large, you probably can't afford to pay developers to rewrite, re-test and redeploy a bespoke system on a newer vendor.
In the ideal world, yes but in the real world; well, I am sure you know how awkward it is to get upper management to do something "correct".
It took amazon 20 years to get rid of Oracle. From what I heard ~15 years ago they had good deals at the time with site licensing so they basically deployed Oracle everywhere, it was "free". One of my former co-workers was an Oracle DBA manager there for over a decade. I think he is still there but I guess not doing Oracle stuff anymore. I haven't seen him probably since 2009. Amazon was a giant hole for vacuuming up Oracle talent in the Seattle area for a long time(I was in the region from 2000-2011).
It is true provided you control the application you can use almost whatever DB you want, but at the end of the day is it worth the cost to do so. Really depends on the situation. Certainly makes more sense if you are doing it as part of a massive application overhaul/re-write.
I haven't personally dealt with Oracle as OLTP since 2008, 99% of the SQL related things at companies I have been at since have been MySQL. Not that I didn't like Oracle, I never had a problem with it. Just be smart about your licensing it's not hard.
Oracle was the first RDBMS released, and helped first but success of VAX/VMS then UNIX. Really big, important systems stuck was the IMS, then DB2.
Oracle has always been simpler to work with because of multi-version concurrency control, but now that the cost of MVCC is lower (relative to network/disk latency) all other "adult" (i.e. not MySQL) have added it.
Postgress is going to eat their lunch in the medium term.. long-term licence fees will be cut.
Handful of reasons:
1. Legacy. 10 years ago, if you wanted a robust, vendor supported DB solution, Oracle was one of the few shows in town. This makes for a lot of systems deployed on Oracle
2. Inertia. Once you have 100s of DBs on Oracle, it's harder to introduce another one. Many companies will have a policy like "all databases to be Oracle" because they've standardised on it.
3. Features. Oracle does have some features that are rare in other products. Probably >95% of DB use cases will never use any of those features, but if you need feature X, you really need it.
4. Application vendor support. "We support our application with Oracle DB" means you pretty much have to deploy Oracle if you want it to work. For some of these applications, there may not be a replacement which supports PG/Maria and is "good enough".
I strongly suspect that 90% of Oracle databases could well be managed with PostgreSQL, MariaDB or whatever quite happily with negligible development work, but the legacy and inertia issues mean they're stuck on Oracle.
Many years ago I had the dubious pleasure of being both an Oracle DBA and an Ingres DBA at the same time.
Oracles main features seemed to be... Cost more, Crashed more, Harder to configure correctly, needed much more hand holding.
Ingres, on the other hand, didn't seem to care what happened, it sorted itself out. Yeh there were sticky moments but it is safe to say that my memories of bad things happening with Ingres are far fewer than bad things happening with Oracle.
Of course, thats just anecdote. I am sure Orcale is a robust and competent product however one's attiudes are coloured by one's experiences....
You've missed a massive one:
5. Oracle bought the company that provides the software we use
Oracle databases are almost irrelevant, it's the vast array of business and data applications that cause all the licence issues and also form by far the largest expense. Many companies buy a market leading application that meets their needs only for Oracle to buy the supplier of that software a few years down the line.
It's still market leading, the teams using it have built their processes around and within it, replacing it would be a substantial and painful process. Dealing with LMS tends to be easier, and also becomes an IT expense rather than one for the business department that would have to fund a replacement.
This is why Oracle are so frantic to push their cloud services. If their customers buy SaaS from a competitor then Oracle can't play these games - even if Oracle bought someone like Salesforce or ServiceNow, customers can more easily extricate themselves and also have much simpler licence positions that LMS can't so easily find holes in.
It's not the worst RDBMS, it's got some good features but it's just that PG has caught up a lot in the last 5 years making it a viable alternative. We had to pay a service company to do a pre-audit with us to make sure we were 100% Oracle compliant before we submitted it back to BIg Red. We had a very bitter experience many moons ago when we found several out of the box options on by default and the options got used, Big Red dragged us through the rough.
As a 25 year Oracle DBA, if you can then I would certainly not use Oracle it's a lot of hard work to manage their stuff and ensure you don't get caught with your pants down. If you're stuck with it, then simply downsize to lower cost editions, switch off every option you don't need and do your own internal auotmated audit every week to watch those options don't end up costing you 2 years of license costs if Big Red's "debt collectors" team find them.
Seriously though, not surprised at all. Many years in the IT game have forced me not to trust Oracle as far as I can throw them. I've seen what happens when they decide that you appear (to them) to be outside the license terms (like in CPU count) and the result one way or another is very expensive.
I've got a handful of Oracle Linux subscriptions up in March and I've already got the sales droids contacting me. My boss has already indicated that he thinks the renewal of the current level is too much (I don't disagree!) and we should drop down some. They won't be happy.
When it came to replacing CentOS 8, we did take a proper look at Oracle Linux (both free and paid) as it did tick some boxes. But there were certain things that the sales droids seemed to agree to verbally, but pretty much refused to put into writing. Obviously we knew what would happen if we went forward, so that got kyboshed.
And as I'm here, don't get me started on why in this day and age Oracle DB (or at least our DBAs) still insist on using X being available for the installer. Really should be some web-based front end nowadays like pretty much everything else.
> Oracle DB (or at least our DBAs) still insist on using X being available for the installer.
Your DBA needs to read the installation manual. Silent install w/o X being available is a thing for decades. You might require the libraries but not have it running.
When I worked for $vendor, notorious for the complexity of its licensing and the resulting audits, I amazed my colleagues and sales force by pushing through a licensing simplification that reduced multiple pages of terms, conditions, and special cases, including one so arcane that literally nobody still working there understood what it was (and flowcharts!) to something that would fit on the back of a postcard and still leave room for the name and address.
We also gave customer a 20 line script that could tell them instantly what they should be licensed for - unlike the previous scheme that often stumped even the independent expert consultants sent in to audit compliance. Audits were commonplace under the old scheme, and routinely pissed off customers; I never knew anybody to get audited under the new scheme.
One customer, on hearing the new model for the first time, asked me, "Are you sure you work for $vendor?".
Astonishingly, even the sellers preferred it: they didn't have to learn obscure features of the product just to price it correctly, and they could spend their time talking up the benefits of the software instead of trying to explain the licensing.
Ask Oracle how to license Solaris for a VM. Nobody knows... We just bought one license per VM, but maybe it should have been one per socket, for the whole VMWare cluster that the VM could migrate to. Since they didn't know we just went with what we thought reasonable, and felt happy defending in court if necessary.
Well, same for the DB on VMs.
Salespeople told us X, LMS told us Y, I pointed out implications Z and.. Oracle asked my CIO if we could please tell them how we would structure the licences and thus how many we'd need.
The approach I took wouldn't be applicable to other customers but it meant we were licence compliant at lower cost, because it was explicitly baked into our agreement with Oracle. LMS were taken out of the picture entirely.
Well everyone who actually used Oracle. Their entire software distribution process was geared towards sales trickery. Perhaps things have changed now I am not sure, but for a long time, you could basically download any Oracle database (and perhaps other software too) for "free" from their site. Didn't require license codes or files, just install and go. Of course then they come back and audit you and you have to pay at that point if you were stupid enough to download/install a version you didn't have a license for.
One company I worked for back in the middle of the last decade, was a small startup, I remember it well, I was a brand new hire on the ops team. They had a really good setup with a DBA outsourcing company(local company we met with them often). Very smart folks. But they didn't pay attention to licensing(!!!). The company was licensed for Oracle Standard Edition ONE (the super small version). I believe that was a wrong purchase they just picked the cheapest one. BUT that's not what got installed. The DBA outsourcing company installed Oracle EE WITH PARTITIONING. Why? That was their standard, and some of their monitoring stuff required partitioning at the time(monitoring, our company's apps did not use partitioning). So they got audited literally a few weeks after I started or maybe they were in the midst of the audit when I started. I had some past Oracle experience. I suggested they move to Oracle SE (not EE, not SE One). I was new, boss didn't trust me. He assured me they are getting everything sorted and will pay the fees and just stick with what they have. OK fine, don't listen to me.
Fast forward about a year and Oracle comes knocking again for another audit. Director trusts me a lot now, and I basically lead the audit, we failed on many fronts because nobody was managing the licensing. Oracle hit us with probably another $100-200k in penalties(management for that year just kept telling me don't worry about Oracle licensing we got it covered).
This was all completely avoidable, it's not complicated especially in a small company. THIS TIME my manager was on board with me changing to Oracle SE. The DBA consultants changed their code to not require partitioning in their monitors. I led the effort to co-ordinate the migration to SE, which involved in some cases changing hardware to optimize for the licensing(had to adjust one batch job that relied on transportable table spaces I think that wasn't an option in SE, so I leveraged SAN snapshots to get the data over much faster than other methods).
I even had to educate Oracle's own sales/audit staff as to what Oracle SE licensing was at the time (I believe at the time it was unlimited cores, per socket licensing max of 4 sockets if you happened to be running RAC or something you could have a max of 4x1 socket systems, something like that, or 1x4 socket system or 2x2 socket for a given instance of the DB). They verified my claims and we went forward.
I built a couple new single socket VMware boxes to run Oracle(and other stuff) to limit their licensing impact(production OLTP remained physical hardware no VM), VMware officially did not support single socket systems at the time (they were 2 socket systems just 1 socket populated), but that wasn't a big deal. Add to that I remember a situation "upgrading" a DL380G5 from dual proc dual core(best for Oracle EE), to single proc quad core. A fully supported thing, HP even came on site to do the work. Only to find out that it didn't work. System wouldn't boot. Replaced the board and it was OK. HP later updated their DL380G5 quickspecs specifying some early systems were not compatible with quad core CPUs.
In the end we saved a bunch of money, simplified things, all around good I think.
As far as I know the company wasn't audited again before they went out of business maybe 2-3 years later.
But managing these licenses really isn't that hard, It confuses me. People scream and yell when they have to deal with things like license keys, license files, license servers, but then you get a company like Oracle who (at least for a long time, maybe still does) doesn't use any of that, and then people scream and yell when they get audited for not using the proper products they were licensed for.
Microsoft in recent years is similar as well, I was never as well versed in the MS licensing but it seemed like with their volume licensing deals you can just provision whatever you want and then they audit you at some point(maybe every year) see how many are active and you pay up. I was taking extra care provisioning limited windows systems informing the people that manage licensing hey I am provisioning this windows server system, or hey I am retiring this system(giving screenshots of the license info), not realizing they were ignoring all of those messages.
> you have to pay at that point if you were stupid enough to download/install a version you didn't have a license for.
The lack of DBAs with a clue contributed to this. Your DB is running slow, the 'DBA' googles, and runs AWR report. Bang, now you're liable for a pair of licenses for diagnostic and tuning packs per CPU which are not exactly cheap.
That's part of the deceptive practices - Oracle install a whole bunch of things you are not licenced for, and then go for your lungs if they are accidentally used.
Yes, it is possible to disable some of these things, but it requires significant effort during and after the installation (chopt, anyone?) and you can't disable all of them - diagnostic and tuning being a prime example. It's not just AWR - you can get hit just doing a query against the active session history.
Oracle is used because it is genuinely an excellent product (I go back as far as V4!), just owned by an ever more amoral and venal company.
I was actually expecting something a bit more pedestrian, like Oracle just approaching large customers and telling them a routine audit turned up issues when no such audit exists, and then the large company deciding to just pay rather than go through their records and verify everything. Of course, being Oracle, it's actually even shadier.
Also "Craig Guarente" is a name of someone who is born to work in sales!
I’ve been in sales at Oracle for decades and during that time I’ve spent more time fighting Oracle compliance to stop audits than I care the think about. The claim that there are sales quotas for audits is blatantly false. Maybe some short lived low level managers do stupid things like that but the Company doesn’t.
I’ve lost millions in revenue due to audits. Far more than I’ve every made from them. Audits are deal killers, every time. We go out of our way to avoid them. When a customer is out of compliance we work as hard as we can to bring them into compliance without an audit.
Unfortunately customers often find themselves out of compliance due to mistakes made by previous leaders. In those cases the customer is often very frustrated as compliance issues often are caused by lax deployment policies and come as a big surprise.
People love to blame ‘the big bad Oracle’ when they get caught with their pants down due to lax deployment policies or incompetent contract management.
Oracle is the leader in most of its markets precisely because it provides world class solutions at prices customers are willing to pay for because overall they get what they pay for. Oracle isn’t perfect. Sometimes customers get frustrated for various reasons but my experience has been that Oracle Executives always try to work things out.
In the days of Oracle 6 and 7 we ran nearly everything on that platform. We had a great deal from Oracle for the campus and we could run as many teaching and administration systems as we wanted. We specified it as our platform of choice for suppliers and they were happy to deliver it.
We got stung by a few licensing "audits" where tools had got enabled by accident - you just had to push the "sql tuning" button in Enterprise Manager for a £30,000 bill to arrive. No warning. Or you used the "compress=all" option instead of "compress=meta" on a backup to trigger a bill for using the compression tool.
We added Oracle to our business risk register and have now migrated most of our tools away from it. We've got a couple of legacy tools left and all of those are scheduled to be replaced. AWS Aurora Postgres has proved an outstanding replacement for our home built tools and the rest are in the cloud and "someone else's problem".
The sales team are well aware that their clients view licensing as the major drawback to Oracle adoption. The software is great, but the licensing is a liability that customers are not willing to take on.
... is that this year you'll never, ever pay less than any other previous year. Even if your system, your user count, your CPU count and everything else has not changed a bit, you'll never, ever pay less than the year before.
Oracle is one of the fewest things that costs more year on year, even when selling more than previous years. Because... Oracle
P.S: yes, you committed to that maintenance fee when you purchased your licenses. However, try to purchase these same licenses again if you're lucky and the product still exists and has not been folded into a multi-portfolio-offering-of-things-you-will-never-use. You'll be surprised that they cost more and carry a higher licensing fee than when you originally purchased them.
To be clear, the VMWare issue is you run Oracle on 1 or 4 CPUs or whatever via VMware, on a 40-core server; Oracle comes in to audit and says you should be paying for 40 cores since VMware is not an approved method of partitioning the system.
But yeah, it's been well-known since the 1990s that if you're using Oracle, you better have plenty budgeted for it because the price will just keep going up every couple years. This is another way to keep the 'ol revenue stream going I guess.
A few points
1. We have a rather large application that brings in a huge chunk of revenue and the vendor doesn't offer any DB options aside from Oracle. Users of this system don't care about the ridiculous licensing costs and need for 250k in staffing to keep it going.
2. We licensed a dedicated VMWare cluster to handle it and a few other Oracle databases. Send Oracle screen shots of our storage and VMware setup so they can certify our environment.
3. Pro tip: Original licenses were purchased about 20 years ago and the maintenance has compounded nicely in Oracle's favor. It would provide a payback of only 3 years to purchase completely new licenses and get the all new updated maintenance rate. A sales rep with a conscience told us this but made us swear not to let anyone know. I'm sure he's moved on. Still our management hasn't raised the issue with budget powers but one day we will stick it to Oracle by handing them a million dollars and thumbing our noses at them.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
