So you're the New DBA...
I've worked as a DBA for several years now. I've been in a variety of different companies - ranging from the large charity to the legal firm, and there are a couple of things that, while they would seem to be logical and elementary tasks, can sometimes be overlooked. Taking the time to do them properly is definitely worth it in the long run and sometimes gives you some extra credit with your co-workers!
Investigate your environment
And I'm not talking about finding the location of the nearest coffee machine and loos although this is no less important!
In my experience, I've found that no matter how professional the incumbent DBA may seem (if there even is one) there is invariably a degree of differentiation between the documentation and what you're told about the SQL server environment, and what is actually in place.
I've found that collecting information on the following things can make the difference between showing yourself to be a true professional and making a complete fool of yourself by presenting second hand knowledge passed down to you as gospel:
- Windows and SQL Server versions
- Service packs installed (if any!)
- SQL collations and Windows regional settings
- Total/available disk space and other relevant server specs
- page file locations
- Database physical file locations
- Backup schedules and agent jobs
- Replication in place
Here's an example: one company that I temporarily contracted for had several people looking after their servers. They couldn't figure out why their SQL database backed intranet server was constantly falling over and denying client connections. Firstly, they had the SQL Server database on the same server as that running IIS - now this is generally not a big issue, IF the server has enough resources and more importantly, they have been properly allocated. In this particular instance, the SQL Server engine had been allowed to use all but 100 MB of the available memory, leaving only the remaining 100 available for the operating system and IIS including client web connections) - most definitely not an ideal situation.
Drawing this fact to the attention of the sys admins, we quickly resolved the situation by upgrading the server to 2GB of RAM and preventing SQL Server from using it all. No more Intranet server failures and a pat on the back from the whole team.
Performance monitoring
There are plenty of guides around that give you the in depth details of what performance counters to use and what they mean, etc., so I won't go into it in too much detail.
I will say, that this can be a very time consuming task, but most definitely a worthwhile one. Identifying the source of long running performance issues is not only satisfying to yourself, but it can also turn a badly performing database application that everyone in the company hates to use into the time saving and worthwhile application that was envisaged when it was first budgeted for.
Take the time to do it right, collect performance data for the CPU, Memory, physical disk, SQL Buffer Manager and all the other counters that are relevant.
Even if people aren't complaining about performance, it's still a good idea to take the time to do this - you will get a good idea of what kind of resources your servers use when under a normal load.
I normally collect performance data (including SQL Profiler traces) over the space of a week, insert all the data into a sql database and then create averages per hour or half hour that I can analyze at my leisure to find the busy periods, etc. Using this method, I've been able to point out to the business servers operating at 100% load for extended periods, when they'd sometimes been informed to the contrary.
Doing all the above in your next DBA role will definitely improve your chances not only of impressing you new boss, but will also help better prepare you for any critical issues that may arise requiring you to know this information right off the bat.
