May 9, 2008 at 5:10 am
I have to take up job to handle 3 servers, which were being managed by other DBA's. What all should I ask them, so that I can look after servers/databases on my own.
First and Foremost - 'sa' password.
2) list of authorized users.
3) Application details using the databases on the servers
4) Contact details of application owners
5) Known/open issues, if any.
What else should I ask. ?
Please advise.
Thanks & Regards,
Anshu
May 9, 2008 at 7:30 am
Either ask (and hope for correct answers) or investigate yourself:
1) Backup strategy - full, logs, differentials - are they working and have they been tested?
2) Does backup strategy fit user expectations (with respect to potential data loss)?
3) DR plans/scripts - if not in place, put them in place (document them!) and TEST
4) Maintenance routines - are indexes/statistics rebuilt/updated regurlarly? CHECKDB run regularly? - important for health of the database
5) Available disk space - is there enough to keep you running for a while?
6) Any performance issues that have surfaced and need to be addressed?
7) Hardware setup - number of cpu (and speed), memory (more is usually better) and disk drives (and speed) - how are they partitioned?
8) Data file and log file layout - are they on the same physical set of drives?
9) Where is tempdb located in relation to the other databases? How big?
10) Any other applications running on the physical SQL server machine?
11) Database configuration options - autogrow on (if yes, fixed amount or percentage growth)? auto-update statistics on? torn page detection on? Sizes?
12) Server configuration - memory settings for SQL vs. OS, authentication setup, really the whole gamut
13) Security setup - passwords, users, roles assigned to users - is it all necessary? sa password - is it secure? who has it? (change it, if possible) Who has access to the production server (best practice would be ONLY the DBA)?
14) Any CURRENT documentation for any of the above? If not, create it.
15) How are applications accessing SQL? (I hate passwords embedded in code, but that's MY issue!)
Most everything depends on your business needs. This is just a small sample of what I look at when coming into a new situation, and by no means is this the best order for execution. I'm know there are many other suggestions out there, but as it's early in my day, this should at least get you started. Good luck.
-- You can't be late until you show up.
May 9, 2008 at 9:19 am
Good advice above from Tom.
I think backups and security are most important, but it's good to get the other information listed above.
May 9, 2008 at 9:24 am
Steve Jones - Editor (5/9/2008)
Good advice above from Tom.I think backups and security are most important, but it's good to get the other information listed above.
Steve, it's Terry, not Tom. I agree 100%, backups and security are vital to any organization and should be at the top of the list.
-- You can't be late until you show up.
May 9, 2008 at 11:09 am
Terry (I learned from Steve's mistake)
That is a good list. The only thing I would add is any known growth/data bases in the pipeline. A DBA should always keep their eyes on the future as well.
I do agree, passwords coded in the application are a bad deal. Way to easy to use either network or place it in an evironment variable but that is digressing from the orginal question.
Marvin Dillard
Senior Consultant
Claraview Inc
May 11, 2008 at 10:38 pm
Thanks a lot , everyone !
I need one more suggestion. The earlier DBA has 'sa' password as it needed for application. Also , he is not ready to share the password with us. Please advise , if the same should be allowed or We should ask him to look for a work around for his application.
According to the formalities , He has been denied access to the server but he's still asking for local admin rights on the server. Please suggest if he should be granted the permission.
Thanks in advance.
Regards,
Anshu.
May 12, 2008 at 5:31 am
Just a thought... If you're coming in as a replacement for these DBA's and the replacement is not voluntary, I wouldn't expect a whole lot of cooperation. In fact, I'd expect them to be a bit hostile.
If you're coming is as "help" and the DBA's aren't being replaced, then managment may have to get involved... to start with, you may not need the "sa" password... you may only need a user login with "sa" privs.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply