November 19, 2007 at 2:30 am
Hi guys,
I need your input or feedback regarding the role and responsibility of SA and DBA based on your experience.
DBA is given administrator access to all database servers. The sql server services are using domain user as their logon account and it's owned by DBA. I would like to check with you, whether this kind of arrangement is audit compliance.
Who should stop and start the services of SQL server? Should this activity be done by SA or DBA? I feel, our SA always push away the responsibility to DBA since we are having administrator rights and we are the owner of the database servers.
My intention is to find out whether DBA really require administrator rights. What are the "DO" and "DON'T" list for DBA.
Really appreciate all your comments.
Cheers
November 19, 2007 at 4:06 am
The answer is "it depends".
I've worked in companies where I have had full domain admin permissions and could do whatever I wanted. I've also worked in environments where my permissions are restricted on the server.
Personally, if resources allow, if you can have a system admin managing the actual servers and DBA's managing the database instances, thats my preference.
While I make every effort to understand what runs behind my databases, I'm no expert and I can sleep easier at night knowing that someone with considerable more knowledge than me in servers, windows, networks etc is in control (hopefully!).
As for stopping and starting services, I think its a joint call. The DBA would ultimately make the call as they understand what the implications are to the databases. Personally, restarting services should be arranged prior to the event and communicated to all concerned. I appreciate this is not always possible when things go pear shaped at 3am, but those are exceptional circumstances!
November 19, 2007 at 6:36 am
I think there needs to be some trust here between the SA and the dBA. Hopefully your SQL servers are just that, servers supporting SQL only, so as the DBA you should have admin rights on the server. After all, you will need to install\upgrade software, have full access to all the drives, maybe add rights to service accounts to use AWE say, check windows users\groups and when troubleshooting any access is feasible, e.g. registry changes.
I do not have, nor would I want, any access to Non-SQL servers.
As for stop\starting SQL services, hopefully if this is required due to a SQL incident you as the DBA have been involved and should control the bouncing of the service, if it is just standard maintenance\reboot schedule there is no reason why the SA cannot handle the services especially as it is automatic on a reboot and no further action is required. It would be good practice for the SA to make you aware this is happening and have your approval.
---------------------------------------------------------------------
November 20, 2007 at 1:25 am
The problem is we are 2 seperate body. SA is belong to infra and DBA is below to dev team. Believe it or not. It's very difficult to build the trust between SA and DBA. Politic plays a part.
November 20, 2007 at 1:57 am
I know that feeling all too well. Infra and Dev can be worlds apart in some aspects. At a previous company, I suppose I was lucky that I actually sat with the Infra team (the rest of the DBA team were scattered around the country) and I got on with them well, so we generally got things moving in the right direction.
November 21, 2007 at 2:12 am
SAs and DBAs should both be involved in/be required to sign off on/approve any change to a production database server.
The SA and DBA role are actually very complementary roles - both are primarily concerned with the availability, performance and maintenance of "their" respective servers but when it comes to databases, etc. many SAs are pretty darn ignorant as are many DBAs from the SAs perspective.
As a DBA you may not need to understand the in's and out's of configuring a particular piece of hardware (though it wouldn't hurt to learn as much as possible) but you do need to be sure to engage the SA/Infra side of the house to ensure that you're both on the same sheet of music. I think it's pretty safe to say that the more you understand about underlying operating system and hardware that your databases run on, the better you'll be as a DBA. You also need to have a pretty good understanding of the applications that rely on your database - I ran into one recently where applying SP2 to a SQL 2005 instance would have broken the corporate accounting package while voiding the $50k/yr support contract to boot - the vendor explicity warned/notified clients not to apply SP2...
A little communication and prior planning can reduce/minimize pain and suffering dramatically:
Imagine if you will the SA forcing your database server down for a patch while you're in the middle of a large ETL job that's been running for three days (bulk load at that...) or in the middle of a weekly full backup on a huge database... whose fault would it be? The SAs for following his regularly scheduled patch schedule or the DBAs?
November 21, 2007 at 8:54 am
Lanny Irwan (11/20/2007)
The problem is we are 2 seperate body. SA is belong to infra and DBA is below to dev team. Believe it or not. It's very difficult to build the trust between SA and DBA. Politic plays a part.
Welcome to the world of being a DBA !
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
November 21, 2007 at 1:55 pm
At my company we (the DBAs) just took over a lot of the responsibility from the SA's for our SQL boxes. Primarily because they are seriously under staffed and we need things done faster than they can provide them.
The general rule of thumb now is that if it is database related the DBAs handle it. That includes installs, updates, stopping and starting services, instances and even the SQL servers etc. Pretty much everything but backups (handled by a 3rd group if you can believe it). Now of course there is the understanding that while we are the first line on those boxes if at any time we feel out of our depth we will punt to the SA's.
Its working well for us although it does require a certain amount of trust on both sides.
Kenneth FisherI was once offered a wizards hat but it got in the way of my dunce cap.--------------------------------------------------------------------------------For better, quicker answers on T-SQL questions, click on the following... http://www.sqlservercentral.com/articles/Best+Practices/61537/[/url]For better answers on performance questions, click on the following... http://www.sqlservercentral.com/articles/SQLServerCentral/66909/[/url]Link to my Blog Post --> www.SQLStudies.com[/url]
November 22, 2007 at 12:59 am
Thanks guys for all ur feedback. Really appreciate it.
Cheers,
November 22, 2007 at 1:05 am
Just to make it more fun, we have a third level.
As a development team own our database servers (Dev and Prod) and have admin rights on them. On the servers, we can pretty well do what we want, within reason. If we need a reboot etc, then we can do so, providing we fill out the relevant forms and notify our operations team, so that when they notice it disappear, they don't start screaming.
Our System Administrators installed the server and build it. They are responsible for patching, and we make sure that a window is always available for this on a Saturday morning. The patching process is largely automated, but doesn't use automatic updates. It is well controlled. They also manage the disc backups
Our DBAs install SQL Server, create databases and control database backups. They remove BUILTIN\Administrators from the sysadmin role. They will provide occasional development advice. If a patch to SQL Server is required, either the DBAs will do it, or it will happen as part of the regular patching process performed by the SAs
As a developer, we have DDLAdmin and SecurityAdmin roles, but not sysadmin or dbowner. We can create objects and grant access to them based on roles set up for us by the DBAs.
On the whole the process works well. If there is a problem with SQl Server or the Server itself, we will initiate the call and either a DBA or SA will respond. If there is a major problem, then both the DBAs and the SAs have their own notification facilities and can respond far quicker.
November 22, 2007 at 7:59 am
Hi,
From my point of view, DBA should be involved in anything regarding SQL Server which includes stoping/starting and so on...
Sometimes, SA and DBA roles look to be difficult to split but, when properly defined, everybody should understand that they have to work together in a strong partnership.
SAs are handling server issues but when issues involved SQL Server, DBAs should be in the loop.
DBAs are handling SQL Server issues but when issues may impact server side, SAs should be in the loop.
Thanks.
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply