March 6, 2013 at 8:10 am
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
-------------------
A SQL query walks into a bar and sees two tables. He walks up to them and asks, "Can I join you?"
Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html
March 6, 2013 at 8:59 am
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 [/url]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
March 7, 2013 at 1:05 am
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;-)
March 7, 2013 at 1:57 am
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.
March 7, 2013 at 6:24 am
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
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
March 7, 2013 at 7:19 am
Thanks to everyone for their great responses.
The term "clown cars" sums it up perfectly, though, so thanks for that gem, Grant. 🙂
- webrunner
-------------------
A SQL query walks into a bar and sees two tables. He walks up to them and asks, "Can I join you?"
Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html
March 8, 2013 at 9:01 am
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
March 10, 2013 at 7:06 pm
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!!
March 11, 2013 at 7:27 am
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.
March 11, 2013 at 7:40 am
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 )
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
March 11, 2013 at 8:05 am
Thanks again, everyone.
In this case, it turns out this database supports official software that needs to be supported from the systems side as well, and I met with my colleagues and confirmed in writing that that software vendor is taking responsibility for the SQL Server configuration. However, I will also be invited to meetings pertaining to the software so I know what's going on. At least now I will have a chance to discuss with the vendor, at the meeting, what I did to ensure the basic health of the server and what if anything they recommend to change.
I'm happy with the outcome, but I will be reviewing this with my boss to ensure that as much as possible we are made aware of software that requires SQL while those decisions are being made, not after they're installed and have trouble.
Thanks again,
webrunner
-------------------
A SQL query walks into a bar and sees two tables. He walks up to them and asks, "Can I join you?"
Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html
March 11, 2013 at 2:56 pm
Four years ago I was in a Data Admin group that got tired of being called to fix problems in these rogue installs. The Manager got a bright idea and started charging back their time to the development/business group. Once the business-line VP's started seeing very expensive DBA time showing on their monthly cost sheets, the CIO got calls and before long those old systems (one was SQL2000!) were brought up to current specs and the servers were placed under the Data group care. Problems tended to taper off once that happened...
March 11, 2013 at 3:02 pm
ACinKC (3/11/2013)
Four years ago I was in a Data Admin group that got tired of being called to fix problems in these rogue installs. The Manager got a bright idea and started charging back their time to the development/business group. Once the business-line VP's started seeing very expensive DBA time showing on their monthly cost sheets, the CIO got calls and before long those old systems (one was SQL2000!) were brought up to current specs and the servers were placed under the Data group care. Problems tended to taper off once that happened...
Nice. Thanks for that tip. I will keep it mind. I don't think we have chargebacks that work that way with hours within our department, but I can do something similar by tracking the requests that come in and the hours of my time that they would take up. Something that lets management know that the SQL maintenance for these servers isn't just taking care of itself.
Thanks again,
webrunner
-------------------
A SQL query walks into a bar and sees two tables. He walks up to them and asks, "Can I join you?"
Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html
March 14, 2013 at 2:48 am
I have been supporting MSSQL now for 17 years, and have come across this issue many, many times.
I usually follow the following process:
1. Fix the problem.
2. Install monitoring / alerting processes to warn/fix issues should they occur again.
3. Advise that the systems should 'really' be supported by my group.
4. Provide a report of findings, highlighting where 'gross errors' were made due to not being implemented / administered by individuals skilled in database administration.
5. Leave it at that. If they are really THAT concerned about failing systems, they will see that correct support as advised is necessary, and allow you to maintain any other systems.
You can't be expected to do much more than above, and the report is a great 'get out of jail free' card, advising on issues and offering support.
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply