Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Question about DBA authority versus responsibility Expand / Collapse
Author
Message
Posted Wednesday, March 6, 2013 8:10 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 2:31 PM
Points: 2,428, Visits: 2,861
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


-------------------
"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
Post #1427439
Posted Wednesday, March 6, 2013 8:59 AM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Today @ 2:25 AM
Points: 3,346, Visits: 3,641
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
Post #1427474
Posted Thursday, March 7, 2013 1:05 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 2:16 AM
Points: 2,840, Visits: 3,983
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
Post #1427819
Posted Thursday, March 7, 2013 1:57 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, August 9, 2013 8:19 AM
Points: 179, 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.
Post #1427833
Posted Thursday, March 7, 2013 6:24 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Today @ 7:08 AM
Points: 14,200, Visits: 28,527
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
Post #1427935
Posted Thursday, March 7, 2013 7:19 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 2:31 PM
Points: 2,428, Visits: 2,861
Thanks to everyone for their great responses.

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

- webrunner


-------------------
"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
Post #1427968
Posted Friday, March 8, 2013 9:01 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, April 17, 2014 1:41 AM
Points: 170, Visits: 1,400
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
Post #1428633
Posted Sunday, March 10, 2013 7:06 PM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Wednesday, July 24, 2013 1:57 PM
Points: 211, Visits: 72
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!!
Post #1429051
Posted Monday, March 11, 2013 7:27 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, November 26, 2013 8:14 AM
Points: 134, Visits: 165
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.
Post #1429257
Posted Monday, March 11, 2013 7:40 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Monday, June 9, 2014 6:02 AM
Points: 2,674, Visits: 697
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/
Post #1429266
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse