Managment
-
So you have been hired as the new SQL Server DBA (the only SQL Server DBA) at a large company. Where do you start. Here are some quick facts.
1. 50 SQL Servers (7.0 2000 2005)
2. 300 databases
3. No funds to purchase monitoring tools.
4. Need to run test restores of every database every quarter (provide proof for audits)
5. Track usage and growth of every database (Online reports for management)
I am already in the process of tackling these issues myself, but I was wondering if anyone else is in the same boat and how they approached this. I am still fighting the battles that SQL Server is as important as the Oracle Databases.
Stacey W. A. Gregerson -
Stacey
I would consider to go for using scripts to automate most of the stuffs then. Most of the important job done by a monitoring tool can be moniored by script and mail can be fired to the notification list.
Also I would have prioritize to upgrade all 2000 to 2040 as soon as possible to reduce the future problems.
Regards
Utsab Chattopadhyay
-
2040 or 2005
?Also anyway you can afford to have one or 2 critical servers fail for 1 or 2 hours so they really feel the importance of this data and having proper tools to prevent such "problems"
? -
I do have a Server just sitting here to repalce any server that has hardware problems.
I have mail messages set up for every job and every alert. The reporting side is waht i need to get working on. I am currently building a ce ntral database server to poll all other servers for data then use reporting services to show reports. I just got the server, it doubles as the test restore server. Older hardware but beggers cant be choosers.
I have a lot to learn about reporting services and design.
Stacey W. A. Gregerson -
For free tools, you may want to look at SQLH2 from Microsoft.
-
All usefull links listed here :
http://www.microsoft.com/downloads/results.aspx?pocId=&freetext=SQLH2&DisplayLang=en
-
Where would I start?
1) Get the SQL H2 tool for monitoring up.
2) Write the additional scripts for monitoring you may need.
3) Build backup/restore jobs which can take parameters so you build a job once and just specify database, server, etc.
4) Start going through the 300 databases to determine ownership, what is needed and what isn't, and what can be consolidated.
5) Start going through the servers for the same reasons as step #4.
6) Look at upgrading SQL Server 7.0 to 2000 or 2005 (preferably 2005).
And somewhere in there, start putting together cost and justification to get the tools you need so at worst case you'll get them next budget cycle.
K. Brian Kelley
@kbriankelley
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply