How to escape the no-win Oracle SLA as a DBA
Escaping the no-win Oracle SLA as a DBA is all about tying technology to business, according to two Oracle Database experts.
What is a no-win service level agreement (SLA), and what can DBAs do to dig their way out of this kind of Oracle SLA?
Michael Corey, president of Ntirety, a division of Hosting: You have to go back to your business community and ask them what their expectation of database uptime is.
In a business you have two things, assets and expenses. We all know what we do with expenses: We eliminate them or reduce them. In terms of assets, if you make the business case that you never want the business to go down, then here is the investment. If the business says that's too expensive, I want to keep what I have, then you can reset this no-win SLA where you can say, OK, the database could go down and it could be down for as long as five hours. But at least the elephant in the room has been discussed and everyone has an honest opinion, and instead of being the DBA that gets shot for the database going down when no one expects it, you've reset expectations and you're no longer in a no-win SLA.
Donald Sullivan, database specialist, VMware: In a greater sense, it's essential to determine exactly what those real SLAs are, to come to an agreement between all of the important personnel throughout the stack to determine exactly how long a particular application can really be unavailable. If you don't do that, then you never know. Then you wind up getting into this no-win situation where everyone assumes the application will always be up, where everyone thinks they can get that kind of availability with no cost whatsoever. Once they determine what the real cost is to have that kind of availability, then often they reassess what they actually want.
Corey: You do have to sit down and look at all the applications and define Tier 1, Tier 2, Tier 3, and then assign cost with maintaining each level. Not everything has to be Tier 1. Maybe your HR system can be down for a couple hours, but a critical medical system can never go down.
Sullivan: We can design you systems that would never go down, but they're going to cost you and they're going to be very expensive. This needs to be done on an application-by-application basis. Even a single second being down in a trading system can cost appreciable amounts of [money]. But other systems, like HR systems, if they're down at some point in time, it might not be critical.
Corey: Also, the DBA who can match the business to the technology is worth his weight in gold. So for example, if the DBA went back to management and said, 'when you're down for an hour, this is what it costs the business: $1 million.' I'm asking for a $50,000 investment to make sure that doesn't happen. Business to technology, not technology to business.