DBAs massively over-provision Oracle to protect themselves: Microsoft Microsoft thinks it has cracked the code for cost-effective Oracle-to-cloud migrations. In a white paper released over the weekend, Microsoft argues that there are savings to be had because on-prem Oracle implementations usually over-provision hardware to leave overhead for growth. Canny database administrators make matters …
Easily avoided - by migrating to Oracle Cloud.
Of course, if you want to use Azure or AWS services and capabilities you'll need the data in their cloud too. Better to migrate to non-Oracle databases and just quietly switch off the on-prem before telling Oracle anything.
Am I just weird for finding it disconcerting that MS are publishing white papers on Github? Let alone a Github page that has nothing else in it.
Being the suspicious type I did track down the relevant page on a microsoft.com subdomain and it links to the same github repository, so it's legit, just.. well, I don't like it :(
(Thank you El Reg for posting the link though)
They own Github so why wouldn't they treat it as their publishing arm? It probably has the effect of drawing its existence to the attention of some managerial types who wouldn't otherwise have heard of it. You can just imagine some CFO telling his IT bods "I've just come across this Github thing. Maybe you should look into it."
In Azure, for our recommended architecture, we have a DataGuard Standby, we switchover, then downsize the primary, then switch back over to do so with no outage. If the customer has an environment with no secondary, then they will need to take about a 5 minute outage to downsize the VM.
Everywhere I have ever been, whatever the tech, on-prem or in cloud...
IT' IS ALWAYS OVERPROVISIONED
And there is a reason for it.....
Nobody does any analysis of future growth in data, or usage.... None. There is no analysis of historical growth/usage to extrapolate from either. Experience tells every tech that if a BA or PM say 'we expect to need capacity for X rows etc' or whatever metric, that it is wildly wrong and you add 50% (seems to be the jist)
I have never known a BA/PM be remotely right. I've known the to be over optimistic, overly pessimistic - mostly the latter.
Ask a question like how has system growth been for the last 12months, nobody has a clue, because that level of gathering has never been done. Why? Because that involves expense to action.
I used to see that a lot but since moving to cloud we have every single resource request, right down every single AWS lamba has to be costed for usage and growth at 0.00002p/month! If something is provisioned and then sits idle for more than 6 hours, alarms get fired to the people who track costings and they issue requests to "cease and desist" or termination will be forced. Saving our company a bundle.
Yes, and then they can be hit over the head with the bill at the end of the month, bill that goes twice or ten times over their budget, but it's to late to plead at that point.
It has already been said by people far more intelligent than me : you do not save money by going to the cloud. It follow that you save even less by switching cloud.
It's snake oil, nothing more, nothing less.
This.
"On-demand flexible provisioning" also means surprise and often inaccurate, exorbitant bills.
Something that is true in almost all industries and market. Big companies NEVER miss a chance to over-bill.
The Microsoft paper as presented is quite solid, I wish other cloud providers would be as forthright. The math that is lacking is whether the cost of the over-provisioning of on-prem resources is greater than the cost of the cloud migration and operation, in say a 5 year period. Of course, YMMV. We often rush 'to-the-cloud!' but a good Chef knows that every utensil in the kitchen has its purpose, its functionality ..and its limitations. The benefit of migrating to Azure, or other cloud providers is the ability to re-factor the existing database architecture and workload. Migrating off of Oracle to other databases provides an opportunity to solve old problems in new ways, and leave old decisions in the past. With regards to Oracle's license model, it has been broken for years, their cloud solution is simply a way of covering that fact up. I have worked with Oracle products for over 30 years, the database has amazing functionality, but all of that functionality is not always needed for every problem to be solved. And sadly, I have never heard a customer every say, let's buy more Oracle.
Of course Oracle installations are over provisioned, the difference between good performance and a system meltdown can be one missing index away. It is good practice to have some spare capacity, besides that, on a life cycle of 3-6 years for a sizable Oracle server a bit more hardware doesn't hurt operational costs. Outages and mid-life upgrades are much more expensive.
It is quite courageous of MS to write something like this, the systems I have seen on Azure are like 2015 slow, their Linux images do not have volume management enabled. Maybe that is to make Linux looks as bad as their brain dead windows on Azure, where it is impossible to increase drive sizes as it was in 1995.
The article is probably written to provide bookkeepers with reasons to deny requests of techies to spend the money on something useful instead of Azure crap.
"The difference can be one index away"
Never a truer word spoken.
Increasingly, less and less attention seems to be paid to 'optimisation', purely on the basis of one mantra....
"Upscale the box(es) until the performance meets expectations"
I've seen a system go from 128GB instance to 512GB and higher in vain to get performance. This was based purely on the fact the db could be cached in memory. It doesn't fix locking issues.
Eventually, I was asked to take a look.. took me a morning to identify the central issue of indexing , or lack of it...
The hidden cost of any migration – is getting away from it. And this seems to increase with the cloud with the costs of getting your data back downright punitive, even when compared with Oracle / SAP licensing.
As for calculating capacity, not having enough oomph is almost always going to lead to higher operational costs than the capital required for more headroom. Exceptions prove the rule but it should generally be possible to calculate the grunt needed for DB work reasonably well, unlike say videotranscoding.
So this is the same Microsoft that does a hard sell or Azure services and OneDrive for Business claiming that the IT department has on storage admin for every 100TB or data (or something ridiculous). This is then costed at about £75 per FTE with on-costs.
Manglement nod wisely and believe all this, totally ignoring the fact that they have one or two storage admins (that also do (lots of) other stuff managing petabytes of the stuff.
The same with looking at the on-prem-Azure IAAS VM migrations, squash everything down to the smallest possible size "right sizing" and ignore if it works or not. Now I know that VMs can be over provisioned but if the company providing the solution needs 4 cpus and 16GB of RAM, that is what you give it. Now we can trim that down but then the very moment you need to open a support case you are stuffed.
What is the spec of the VM? 2 cpus and 4GB ram. Ah will that is what is causing your issues, our document state that the minimum requirement is 4 cpus and 16GB
The last comment is what I’ve been hearing from many, fellow Oracle DBAs for a couple years now and honestly- just because you don’t know how to do something doesn’t mean that it can’t be done or done well. Every cloud has it’s own tips and tricks to success and Azure is no different. I was an ACE Director, I worked for Oracle and I’m still an Oak Table member and the biggest frustration for me, is that with an Enterprise level cloud, (as with any cloud) there are so many ways to end up making mistakes with IaaS, which is where most high IO workloads will end up.
I’m in agreement with some of the comments here- GitHub is just to get this into the hands of the public as they requested it, published first on the Microsoft Data Architecture Blog, but it will be published to Microsoft Documentation very soon. The goal of this paper was:
1. With the massive quantity of Oracle databases coming to Azure, what is the guidance to migrate successfully and get similar performance to on-premises?
2. I’m told I’ll pay twice as much as I do now. How can I pay less if I need to stay on Oracle, (about 70% of the databases we deal with must stay on Oracle, at least for the foreseeable future.)
3. There’s a lot more out there in storage options for high IO than what most are aware of. What are the tips and tricks to get the performance you need? What should you avoid?
4. If Oracle won’t give Azure a PaaS solution, how can I simplify the management of my databases in Azure?
There’s more on the way, but this paper is a good start and helps support the 5000 customers we already have running Oracle in Azure.
One of the biggest benefits of VM environments is the ability to share resources between systems something that has been possible for more than 15 years now. However in most public cloud environments this is not possible, things are hard allocated(akin to the days of running each system as a dedicated physical server). Most database servers probably are lightly utilized (certainly in my 20 years of experience). There are some super critical big expensive systems that need more special care but those are rare.
The ability to share resources from a hardware/VM licensing perspective is pretty good/efficient/cost effective strategy. An alternative may be to run multiple DB instances on the same server though that is a bit more messy from a admin standpoint. Oracle licensing doesn't yet cover things like memory or disk space(at least I think so HA HA) - so you could easily at a bare minimum run other servers on the same storage as your Oracle(provided of course you are aware of the i/o workloads of those systems so they don't impact any critical Oracle installations). Though some Oracle DBAs I'm sure are super paranoid(perhaps rightfully so). However storage these days can be so damn fast that it probably doesn't matter anymore. Back when my org had only an array with 15K disks one of our production MySQL servers would sometimes issue a query that was very bad, that one query consumed more disk I/O than all 500+ other VMs combined. Fortunately that was an app bug, and I put in a process to detect that query and kill it within a few seconds any time it ran.
I haven't seriously been in a position to use Oracle since 2008, everything since has been MySQL basically. I helped my company at that time migrate from Oracle EE to Oracle SE, and we leveraged single socket VMware hosts (quad core) to do it. Production Oracle remained on physical hardware, but the test/QA/dev/reporting Oracles were all VMs, and all shared hosts with other VMs). Storage was shared as well, with the VM hosts using iSCSI and the production hosts using fibrechannel to the same back end storage. VM hosts eventually moved to fibre channel as well after I left due to a critical bug in iSCSI on the array that we had.
I do miss Oracle for some things(I would never count myself as a DBA though have managed databases for many years). I was part of a team that managed the largest Oracle OLTP in the world back in 2005 though(50-60TB at the time). Ran on HPUX Itanium with a full rack of 15K RPM disks(plus another rack for the standby). My responsibility was limited to developing custom monitoring which everyone used (my primary responsibility was on the application tiers and to a lesser extent networking, didn't get involved in things like storage management until my next job). Some of our biggest outages were because of Oracle issues, that and Weblogic, most of it came down to poor application design(that 50-60TB OLTP size was because of large usage of CLOBS(?) - raw XML dumps(with tags) for the app). For one outage Oracle even flew two people on site to assist, only time I've ever seen a vendor do that.
"As such, DBAs tend to pad the original numbers to prepare for this."
Shirley no one in IT would ever pad any estimates to get around inevitable cuts from the beancounters.
All my estimates were precise as to resources and personnel and time. Any discrepancies were due to hacking.
May I make a suggestion about migrating Oracle to the cloud? Don't. And by that I mean don't do anything with Oracle. Don't even look at it or talk about it or it's likely to run slowly. Don't even, seriously, just stop even reading this. Just you reading this comment is making Oracle run slowly. Everywhere. Stop it.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
