What Are Some Good Practices For A Newly Started Senior DBA?
I'm finally taking the plunge and moving up from Junior DBA at a large organisation to Senior DBA at a smaller place. It's going to take some time for me to get a good picture of the businesses' requirements and things might be in a bit of a state as they've been without a DBA for 6 months or so. Is there any advice you would give to a someone starting in this position barring the things like producing a list of SQL Server instances, finding out restore point and recovery time targets, and trying to decipher what state things were left in? Thanks!
When I made that jump, what I found really helped me settle in was to define the issues that I would like to respond to immediately if they happened. Things like failed jobs, lack of disk space, failed backups, etc. I built up a set of scripts to detect these issues, and started doing a daily check of every server. From there I built it outwards, adding in metrics and the like as I found things that I was concerned with. My current daily checklist includes checks for failed jobs, database files that need more space, disk space, backup checks (did they run as expected?), TempDB size/growth (to catch when a TempDB goes mental and takes over the drive, I've had it happen), unusual sysadmins, and a scan of the SQL logs for strange activity. I capture the results daily and make notes on the things I see. I've found a lot of issues that way, including catching an ethical hack in progress (which really surprised that team). There are lots of things that can be added to this as well related to job timing, index fragmentation, etc. It just depends on what you (and the business) are worried about. Backups are huge as well. Perhaps before making up a daily check, make sure your backups are being taken on a regular schedule, and that they are making it to tape/offsite/whatever. I include integrity checks and index maintenance in here as well. Ola Hallengren is your friend here. No need to reinvent the wheel. If the backups aren't being done using Ola's scripts, ask why and see if you can move it over. It's almost an industry standard at this point. As for RPO/RTOs and see if the current setup meets them. The final thing I did that I really like is making up an pre-install and install checklist for all of my SQL boxes. This includes basic information about the install. The pre-install has things like firewall openings, volume maintenance permissions for the service accounts, making sure the disks are formatted correctly, etc. The install checklist has the server name, application name and the like, as well as the SQL and Windows versions, service account names, memory settings, and a general box for capturing a list of things that differ from a standard install. I've also got about a dozen scripts/steps post install for setting up the server (configure the system databases, set up the maintenance plans, make sure Kerberos is working, things like that). This may seem important only for new installs, but it can be incredibly useful if you fill it out for all existing servers as well. It forces you to find out what your standard install looks like, and how the existing servers are different. Last thing to do, read every day. Read all of the blogs you can find. I make a point of reading through SQL information from blogs at least half an hour every day, usually as a reward for slogging through the daily check list :) Good luck!
I would start with the absolute fundamentals: 1. What are these databases for? 2. Which are the most important? 3. Are the right backups being done? 4. Are the servers struggling? But also talk to people who use the systems that rely on the databases. Find out where the problems are and prioritise those things. You don't need to be a politician but you need to earn the trust and respect of stakeholders so they will listen to your advice and recommendations later. A great way to do that is to fix things that bug them, make slow things quicker, correct data errors that get in their way. That kind of stuff. Go back and check if they see the improvement. Make sure they know it didn't just fix itself. Show them you know what you're doing so they value you and will then listen to what you say. Start with the pain points, the small quick stuff. Then look further ahead and get a bit more strategic. If you can, set up a plan of where you think things should go, what the organisation will get out of it, and how to get there.