Essential Guide

Collaborate 2014: News from the premier Oracle user groups conference

A comprehensive collection of articles, videos and more, hand-picked by our editors
Q

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.

This was first published in April 2014

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

Essential Guide

Collaborate 2014: News from the premier Oracle user groups conference

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

1 comment

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchDataManagement

SearchBusinessAnalytics

SearchSAP

SearchSQLServer

TheServerSide

SearchDataCenter

SearchContentManagement

SearchFinancialApplications

Close