Over the last four years, ok it seems longer than that, I’ve started four jobs. A couple just weren’t good fits. One I was at for three years. I currently just finished my first 30 days at my fourth one. Having done the first 30 days several times over the last few years, I’ve searched each time what you would do when you start that new position to take over the environment. What would you evaluate, where to start with everything, what to do first? With no luck mind you. So, I’m going to blog about my journey through this as I’ve done it several times over my career and believe it can help others as they start new positions know where to begin. Coincidentally, Aaron Bertrand (t) just blogged about his first month at Stack Overflow as a DBRE.
Learning the Company
In your first 30 days at any company there are certain things you need to do to setup yourself up for future success:
- Meet with your manger and understand their expectations
- Understand the scope of your team’s work, some company’s do all the databases, so are only responsible the databases related to the application that the company sells, and the vendor (3rd party) apps are someone else’s problem
- Get invited to all the team’s meetings, you would be surprised at how many they forget to add you to
- Get to know any processes and workflows for code
- Evaluate the skills that are the weakest for you in the role that you need to work on
- Understand the organization hierarchy and all departments in the company
- Find out how much time you can use for professional development
- Complete required onboarding training
- Setup your jumpbox environment, I will be blogging about what I setup on mine
- Start contributing a thought or question at meetings
- Read documentation they have if any exist
- Write up some documentation
- Have a lunch (it can be virtual of course) with a least one team member
- Plus, you have to DBA related work outlined line below
Inventory Everything, Know What You Have
My jobs varied from having documented environments to not having any at all. So, the first thing you should do find out what you have. This can as be simple as a spreadsheet to begin with but eventually I recommend having a CMS Server you can store all the data back into and I’ll blog articles that outline processes for this later. You have things in the cloud and on prem, so you will need to be able to capture information for both. You are liable to find instances the company didn’t know they have and some they can shut down. I have a motto of if it’s not documented I don’t support it, so if after my 90th day it doesn’t exist on whatever I’m using to track inventory my new boss knows it’s not my responsibility.
Evaluate
Now comes the hard part, especially if you came into a small organization what to do first. But the best thing to do is DBA 101. Run sp_blitz and dbachecks into a database table on a CMS server and pour through the results. You will be amazed at the things your eyes won’t be able to unsee. Both of these tools will check your instances for all kinds of best practices. I will blog about who to do this in next few weeks. But the results will help you evaluate things. Then the hard part comes prioritizing everything. Just remember you don’t have to do it all in one day.
Prioritize
Based on my results of the sp_blitz and dbachecks I’ve narrowed on a couple priorities I can hit in the first 30 days:
- Ensuring we have backups of everything, starting with the production instances
- Document where said backups are located
- Make sure CHECKDB is being ran everywhere, suspect_pages are yucky to be found
- From there I go for easy wins:
- Setting Power Plans
- Optimize for ad hoc workloads
- Max Memory
- Max Dop
- Backup Compression
- Backup Checksum
- Database Page Verification (at one job I got to see a few databases set to NONE, I had never seen that in 20 years of working as a DBA)
- Install sp_whoisactive, Ola’s solution, Brent’s First Responder Kit
- There are several more that get flagged with sp_blitz and dbachecks
- As Aaron said his in his blog post, use a method go slow and document, document, document.
- Create scripts that can be ran to make all of these changes and be ran repeatedly, dbatools is great for this. I will be creating a blog series linked to this on all the things I actually found and fix at these jobs as I did save these.
90 Day Plan
By the end of your 30 days, you should have an idea of what you can do to contribute for months two through four and what you need to get even more up to speed with the company.
My Wins
Some wins I managed to get in my first 30 days were:
- Helping developers fixing a connection pooling problem
- Not letting SQL Server be patched at 1 PM in the afternoon automatically, oops someone setup the schedule
- Syncing objects across AGs that would make failovers not work
- Eliminating seriously 10,000+ DTA indexes so that month end processes would work, plus just day to day processes
- Getting TBs of space back by making above task and finding transaction logs bigger than the data, once upon a time DBAs weren’t taking log backups, started doing but left log file gigantic and huge amounts of VLFs
- Suring up backups for all of production
- Fixing database corruption
- Several configuration changes reducing CPU consumption by 40%
The post The First 30 Days at a New Database Job first appeared on Tracy Boggiano's Blog.