May 19, 2009 at 5:11 am
Hi Guys,
Just wanted to know what the industry standard is wehen it comes to gaiing access to the server, I’m thinking as a DBA, there are times when one would need access to the actual server itself via console login eg VNC server etc.
Check local backup including disk space
Collect trace file
Monitoring server etc
I know the other side of the coin is that, SA’s should be doing this, but does it not add an extra level of bureaucracy to the job ?
May 19, 2009 at 5:24 am
In all places that I worked at least part of the DBA team had administrative rights on the server that had SQL Server installation. There were some cases of servers that we could not login to, but those servers were under someone else responsibility.
Adi
--------------------------------------------------------------
To know how to ask questions and increase the chances of getting asnwers:
http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
May 19, 2009 at 6:39 am
Hi there,
Based on my experience, having local admin rights to the server is really important, but that does not mean that you should connect anytime you want to perform things that you can do from your pc...
In one of the companies I've worked for, I had a local account with admin rights but disabled. Any time I needed to do something to the server, the server admin enabled it (previous email notification/approval of the managers) and after the work was done, the account gets disabled again.
In other company I had no access to the server, just access to two shared directories, one for the backups and the other for files repository, like CSV files. So, when I needed anything that required access to the server, I had to talk with the IT admin, go to his desk, and guide the guy step by step. It was terrible, but I got used to that after a while...
cheers
Alejandro Pelc
May 19, 2009 at 6:53 am
I would argue that if a server is there to support SQL, then the DBA should have full access to it. Servers that do not support SQL I have no access to, and nor would I want any.
---------------------------------------------------------------------
May 19, 2009 at 6:56 am
Actually, if your servers are configured correctly, and there is a division of responsibility, you don't need access to the OS at all as a DBA. There are a lot of hardened installations like this for SQL Server that are running without problems for things like banks, wall street brokerage houses, and other publicly held companies where requirements for SOX, HIPPA, or PCI compliance mandates restricted access.
A DBA can certainly do their job without being able to RDP to the console of a Server, as long as their is a team of people who support the OS, monitoring, and backups of the database. Under my own SOX audit rules, I can't control the backups of certain financial databases in our environment to keep me from stealing information, wiping evidence of wrong doing, or whatever other scenario an auditor can dream up for how I would want to lose my freedom and livelihood doing something I personally would never do.
I don't think that most small businesses have the staff, expertise, or personnel to implement this level of control, or that it is necessary in most cases.
Jonathan Kehayias | Principal Consultant | MCM: SQL Server 2008
My Blog | Twitter | MVP Profile
Training | Consulting | Become a SQLskills Insider
Troubleshooting SQL Server: A Guide for Accidental DBAs[/url]
May 19, 2009 at 7:11 am
We're a small shop (1 dedicated SA, 1 dedicated DBA) but I have local admin rights to all boxes hosting SQL Server. It's helpful when we have to manage disk space, restart the SQL Server or fail-over the cluster and the SA is unavailable.
_____________________________________________________________________
- Nate
May 19, 2009 at 7:23 am
george sibbald (5/19/2009)
I would argue that if a server is there to support SQL, then the DBA should have full access to it. Servers that do not support SQL I have no access to, and nor would I want any.
I agree with George. Basically, if that is the only application running on the server AND it's my SQL server, I want as many rights as possible to administer the server and do what I need to do to guarentee uptime without waiting for intervention by infrastructure (let's just say that 3AM phone calls don't go over well for most folks). It's my data, my responsibility - deal with it. It reminds me of a time about 10 years ago. We were implementing PeopleSoft payroll/HR. The VP of HR did not want us (the technical team) to be able to see the data. WTF? We can install the product on top of SQL but with NO rights to the database?? We essentially walked off the project until HR thought about it. How can we maintain the package (most of the app is contained within the DB), modify/create new reports/processes but have zero access to the database, outside of the PeopleSoft app? And have to maintain the DB for performance and for recoverability from a DBA perspective? Well, let's just say they re-thought their stance and we implemented PS successfully for 6 of our entities.
-- You can't be late until you show up.
May 19, 2009 at 7:25 am
george sibbald (5/19/2009)
I would argue that if a server is there to support SQL, then the DBA should have full access to it. Servers that do not support SQL I have no access to, and nor would I want any.
I agree with George. Basically, if that is the only application running on the server AND it's my SQL server, I want as many rights as possible to administer the server and do what I need to do to guarentee uptime without waiting for intervention by infrastructure (let's just say that 3AM phone calls don't go over well for most folks). It's my data, my responsibility - deal with it. It reminds me of a time about 10 years ago. We were implementing PeopleSoft payroll/HR. The VP of HR did not want us (the technical team) to be able to see the data. WTF? We can install the product on top of SQL but with NO rights to the database?? We essentially walked off the project until HR thought about it. How can we maintain the package (most of the app is contained within the DB), modify/create new reports/processes but have zero access to the database, outside of the PeopleSoft app? And have to maintain the DB for performance and for recoverability from a DBA perspective? Well, let's just say they re-thought their stance and we implemented PS successfully for 6 of our entities.
Edit: I only posted once but I see it in the topic twice. Not sure what happened and I do apologize. No, I am not trying to get an extra point! 😀
-- You can't be late until you show up.
May 19, 2009 at 8:00 am
I have always had local admin rights on my SQL Server boxes, but I can see where I would not need it, and it places I have worked I could have gotten by without it.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
May 19, 2009 at 8:16 am
tosscrosby (5/19/2009)
It reminds me of a time about 10 years ago. We were implementing PeopleSoft payroll/HR. The VP of HR did not want us (the technical team) to be able to see the data. WTF? We can install the product on top of SQL but with NO rights to the database?? We essentially walked off the project until HR thought about it. How can we maintain the package (most of the app is contained within the DB), modify/create new reports/processes but have zero access to the database, outside of the PeopleSoft app? And have to maintain the DB for performance and for recoverability from a DBA perspective? Well, let's just say they re-thought their stance and we implemented PS successfully for 6 of our entities.
That can be a very risky move, and in your case it worked out for you, but these days with enough people out of work, a DBA can be found pretty quickly who is willing to work inside the rules being laid down for security.
You might not like to think that you could do the job without access, but that doesn't mean that you can't. It does require that you work differently. This is one of those arguments that will never go away because DBA's have had to many rights that weren't actually needed, and they don't want to give them up. I know because I was one of those DBA's not to long ago. It wasn't until I started consulting that I actually changed how I do things so that I can do it without being an administrator on someone else's machine.
Jonathan Kehayias | Principal Consultant | MCM: SQL Server 2008
My Blog | Twitter | MVP Profile
Training | Consulting | Become a SQLskills Insider
Troubleshooting SQL Server: A Guide for Accidental DBAs[/url]
May 19, 2009 at 8:27 am
Here the people who run the live servers do just that. They are Windows server experts who do the clustering, monitoring, hardware, Service Packs, hotfixes, backups etc.
A DBA has full access to the staging servers, but not to production. SQL Server is an app just like any other - They are required submit requests for a hotfix to be loaded, or filesystem changes.
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply