Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Question about DBA authority versus responsibility


Question about DBA authority versus responsibility

Author
Message
webrunner
webrunner
Hall of Fame
Hall of Fame (3K reputation)Hall of Fame (3K reputation)Hall of Fame (3K reputation)Hall of Fame (3K reputation)Hall of Fame (3K reputation)Hall of Fame (3K reputation)Hall of Fame (3K reputation)Hall of Fame (3K reputation)

Group: General Forum Members
Points: 3035 Visits: 3755
Hi,

I'm looking for some advice for how I can assert myself in this situation without alienating my colleagues or causing trouble.

I recently was asked to help fix a problem with an application, at which time I discovered that the application in question is running a SQL Server database that I wasn't aware of. Because it hadn't been set up with the basic log management stuff, the log grew to fill up almost the whole disk, causing the problem.

I guess the first issue is that my organization has a separation of duties such that I am not notified about applications that run SQL Server databases. But beyond that, after I asked to be made sysadmin on the server so I can maintain it, I was told that this can be done but it doesn't fall under the databases that I need to maintain. Given that I was called in to fix the problem, of course, I think I am already maintaining it.

The problem is, at the moment, that group installs and sets up SQL Server and then hands it over to me for applications that fall under my group. So I can't claim that I install and administer everything. However, I would feel better knowing that I am admin on systems that are running SQL Server, because I am the DBA and should anything happen with those servers, ultimate responsibility would lie with me anyway.

I realize I don't have a specific question (maybe there is none), but I'm wondering if anyone out there has guidance for how I should proceed, or what I need to find out in order to proceed.

Thanks for any help.

- webrunner

-------------------
"I love spending twice as long and working twice as hard to get half as much done!" – Nobody ever.
Ref.: http://www.adminarsenal.com/admin-arsenal-blog/powershell-how-to-write-your-first-powershell-script

"Operator! Give me the number for 911!" - Homer Simpson

"A SQL query walks into a bar and sees two tables. He walks up to them and says 'Can I join you?'"
Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html
Stuart Davies
Stuart Davies
SSCarpal Tunnel
SSCarpal Tunnel (4.5K reputation)SSCarpal Tunnel (4.5K reputation)SSCarpal Tunnel (4.5K reputation)SSCarpal Tunnel (4.5K reputation)SSCarpal Tunnel (4.5K reputation)SSCarpal Tunnel (4.5K reputation)SSCarpal Tunnel (4.5K reputation)SSCarpal Tunnel (4.5K reputation)

Group: General Forum Members
Points: 4493 Visits: 4549
I feel your pain with this.

I have tried different approaches with this and the most effective one for where I work is to say to "the business"

yes I can make sure that this server will be backed up - how much data can you afford to lose?
yes I will perform index etc maintenance on this database / server - when (if ever) is the quiet time for it?
yes I will support this database - do you have the handover document stipulating SLAs etc?

By default I will back a database up a couple of times a day and do general maint once a week unless I am told otherwise.

I have found that this approach works where I am as long as you are polite but assertive in saying "unless you tell me otherwise you will get the default" - and get it in writing. The written confirmation is the kept with centrally held documentation about the server / application.

-------------------------------
Posting Data Etiquette - Jeff Moden
Smart way to ask a question

There are naive questions, tedious questions, ill-phrased questions, questions put after inadequate self-criticism. But every question is a cry to understand (the world). There is no such thing as a dumb question. ― Carl Sagan
I would never join a club that would allow me as a member - Groucho Marx
Bhuvnesh
Bhuvnesh
SSCrazy
SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)

Group: General Forum Members
Points: 2930 Visits: 4076
Also manage the permisson of users. Restrict the poeple from unauthoirized access. if possible or required, log the audit login plus DDL commands

-------Bhuvnesh----------
I work only to learn Sql Server...though my company pays me for getting their stuff done;-)
Bobby Glover
Bobby Glover
SSC-Enthusiastic
SSC-Enthusiastic (185 reputation)SSC-Enthusiastic (185 reputation)SSC-Enthusiastic (185 reputation)SSC-Enthusiastic (185 reputation)SSC-Enthusiastic (185 reputation)SSC-Enthusiastic (185 reputation)SSC-Enthusiastic (185 reputation)SSC-Enthusiastic (185 reputation)

Group: General Forum Members
Points: 185 Visits: 751
I would do everything Stuart has said. But in addition you need to find out how much data loss is acceptable for the db (IN WRITING). I wouldn't change any access permission but would highlight anything about the setup that you are concerned with in a e-mail to your superiors. Send them a list of what you will do for maintenance etc. and state if anything else is required they should let you know.

Put the basics in place CHECKDB etc and leave it as that.Also state that any dbs\sql servers which are created on the estate should be verified by the DBA before they go live. I had the same situtation last year and it drove me crazy. So I setup a task to sweep the network looking for new SQL instances of servers.

I think it was based on a OSQL command using the -L switch if I remember correctly.
Grant Fritchey
Grant Fritchey
SSCoach
SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)

Group: General Forum Members
Points: 17629 Visits: 32268
In general, if I'm going to have to fix it, I want control over it. It's that simple. They're trying to give you the responsibility without giving you the authority. Don't sit still for it. Go slow. Clamp down a little at a time. But if they want it maintained and you're the one that will get called when it goes south, then you take charge of it.

Otherwise, prop it up, do as little as humanly possible, and keep all written communication about the server.

We used to refer to servers like this as "clown cars" because all sorts of crazy stuff comes tumbling out.

----------------------------------------------------
The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood...
Theodore Roosevelt

The Scary DBA
Author of: SQL Server Query Performance Tuning and SQL Server Execution Plans
Product Evangelist for Red Gate Software
webrunner
webrunner
Hall of Fame
Hall of Fame (3K reputation)Hall of Fame (3K reputation)Hall of Fame (3K reputation)Hall of Fame (3K reputation)Hall of Fame (3K reputation)Hall of Fame (3K reputation)Hall of Fame (3K reputation)Hall of Fame (3K reputation)

Group: General Forum Members
Points: 3035 Visits: 3755
Thanks to everyone for their great responses.

The term "clown cars" sums it up perfectly, though, so thanks for that gem, Grant. :-)

- webrunner

-------------------
"I love spending twice as long and working twice as hard to get half as much done!" – Nobody ever.
Ref.: http://www.adminarsenal.com/admin-arsenal-blog/powershell-how-to-write-your-first-powershell-script

"Operator! Give me the number for 911!" - Homer Simpson

"A SQL query walks into a bar and sees two tables. He walks up to them and says 'Can I join you?'"
Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html
SQLCharger
SQLCharger
SSC-Enthusiastic
SSC-Enthusiastic (182 reputation)SSC-Enthusiastic (182 reputation)SSC-Enthusiastic (182 reputation)SSC-Enthusiastic (182 reputation)SSC-Enthusiastic (182 reputation)SSC-Enthusiastic (182 reputation)SSC-Enthusiastic (182 reputation)SSC-Enthusiastic (182 reputation)

Group: General Forum Members
Points: 182 Visits: 1401
I go even further.

It only gets registered in my team's list if the team is local admin (Windows), sysadmin on SQL and *nobody* else can be sysadmin using Dev tools (SSMS, BIDS etc).
Carefully worded emails help.

The alternative is to play catch-up with 'power users' and eternal cat'n'mouse with Developers.
Not worth the aggro...

Cheers,

JohnA

MCM: SQL2008
red_serene
red_serene
SSC Veteran
SSC Veteran (213 reputation)SSC Veteran (213 reputation)SSC Veteran (213 reputation)SSC Veteran (213 reputation)SSC Veteran (213 reputation)SSC Veteran (213 reputation)SSC Veteran (213 reputation)SSC Veteran (213 reputation)

Group: General Forum Members
Points: 213 Visits: 74
I think the part that is missing here is that you were called upon to 'fix' the database, which you are not officially supporting. I have been aware of many installations at various organizations (mostly in development groups, but not all) where the DBA is truly called in only when problems occur. My group didn't have the manpower to support everything, and management made the decision that these other 'rogue' installations were OK. Yes, we were called in when problems existed - but after fixing the problem (and sometimes that might even mean a full SQL reinstallation and data loss depending on severity) we walked away. Our being called in to fix the problem did not mean we should be bringing it up to standards, installing standard maintenance, or anything else which "normal" support would entail. These SQL instances were not meant to be robust, or they would have fallen into our "fully supported" mode, with full DBA oversight.

Ultimately, it is up to management to decide where SQL resources like DBA labour hours are spent. If they decide environments exist without full DBA support, there is typically a business reason. It is that separation of authority and responsibility mentioned before. You cannot assume or be assigned responsibility for environments that you do not have the authority to manage.

While it is risky, sometimes management and the business makes that decision for some environments. At that point, all you can do is fix the immediate problem, point out any ongoing risks you see (without fixing them), and hand it back. Doing more is going beyond what you were asked and authorized to do. Doing less is not being a professional and giving management the visibility to any additional risks they might be incurring by having the database outside of full support. Sometimes this has been enough to bring the system under full DBA support - but that is not your decision.

Sometimes you just have to live with that. I loved the "clown car" tag as well!!
Chadwick-788357
Chadwick-788357
SSC-Enthusiastic
SSC-Enthusiastic (138 reputation)SSC-Enthusiastic (138 reputation)SSC-Enthusiastic (138 reputation)SSC-Enthusiastic (138 reputation)SSC-Enthusiastic (138 reputation)SSC-Enthusiastic (138 reputation)SSC-Enthusiastic (138 reputation)SSC-Enthusiastic (138 reputation)

Group: General Forum Members
Points: 138 Visits: 170
That's the key point, "Ultimately, it is up to management to decide where SQL resources like DBA labour hours are spent."

This is a resource assignment issue. Just calmly explain to management (whomever that may be in your world) how your time is pulled away from other things to work on something like this. And explain how you could avoid that managing the server up front. Let management sign off on an arrangement. Then your hands will be clean. You may not avoid all frustration with future incidents, but at least you will have done your part in raising this issue with management.
colin.Leversuch-Roberts
colin.Leversuch-Roberts
SSCrazy
SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)

Group: General Forum Members
Points: 2725 Visits: 715
Truthfully I doubt there will be much you can do - I too have similar issues where the business largely do as they wish - don't want a DBA until something goes wrong but still won't allow any control. I usually refer to these as "Wild West Servers" sorry to USA members!
I think to be honest that if it gets to you then you seek out another job if you are an employee because you'll always have conflicts within yourself as you try to do what you know should be done vs the silly demands/expectations of the business.
There's also the phrase "You can take a horse to water - but you can't make it drink".
I raise the risks of unmanaged servers to the business ( every time I have to fix something ) but ultimately I suspect little will change until someone at the top forces the issue or a system is lost big time, but even then I'm not sure.
( I hasten to add that the main system I support/manage is heavily secured and as a consequence suffers little disruption )

The GrumpyOldDBA
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search