The T-SQL Tuesday topic for this month comes from Gethyn Ellis, who asks about the best piece of career advice you have ever received. Check out Gethyn’s full invitation by clicking the T-SQL Tuesday logo.
I’m going with the first phrase of advice that came to mind, and it’s one that can be applied to database administration or life in general: trust but verify. This is the more politically correct version of the advice I learned early on, which was to never assume because “when you assume, you make an ass out of u and me.”
Trust, But Verify Your Backup/Restore Process
Just because you have backups doesn’t mean they’re any good. You need to test actually restoring backups. One piece of this that I’ve seen get missed and assumed is, even if the backups are good, what is the process to actually restore for a live client?
This may not be as much of a concern if you’re using native SQL backups. You can use SSMS to backup, use SSMS to restore, and there is plenty of documentation to support it. If you are using some type of 3rd party backup solution, make sure you are testing the restore process from start to finish.
When an emergency comes up and it’s on you to get the database recovered as soon as possible, you don’t want to be trying to learn or re-learn your restore process. Do you know which server backups are backed up to? Do you have rights to grab files from where you need them? If your 3rd party solution is as slow as molasses, make sure you know that before you promise someone, “oh it’s a small database, so it should be quick to recover…” and then fight restoring a database for the next hour.
In this case, you should trust the process but also verify it so that when the pressure is on you’re as calm as you can be.
Trust, But Verify Changes From Others
Another situation where you should “trust but verify” is when someone else is making changes that may affect you.
As an example, someone from another team may give you a heads up that they’re updating a single SQL job. Sounds simple enough, right? It sounds simple, but it’s worth asking for more details about what exactly is changing. That SQL “job” change might include changes to stored procedures, functions, and tables that are referenced as part of that job, which could all be referenced by other areas of code. Or perhaps that single SQL job change wasn’t even for a single job but was for multiple jobs.
You don’t want to come into work the day after that “SQL job” change with an inbox full of error reports, find out just how much actually changed, and realize you could have prevented it if you took the time to ask.
Trust, But Verify With Your Manager
If you’re meeting periodically with your manager to address goals in anticipation of a yearly review, make sure you’re documenting as much as possible in those meetings. It’s easy to be lackadaisical in something like monthly 1-1 meetings, especially if you feel like you’re in a comfortable position or have a relaxed relationship with your manager. When the yearly review comes and it’s not what you expect because you and your manager are not on the same page, that’s your fault.
You should know exactly what your rating will be, if you’re getting the promotion, etc., well before the big yearly review meeting. At that point, it should be nothing more than a formality because you’ve trusted what your manager said and verified it by getting months of highlights and feedback in writing.
Heed Advice
I’m sure there will be some helpful advice throughout this month’s T-SQL Tuesday posts. If any of it speaks to you, make sure you take the time to apply it.
Thanks for reading!
Chad Callihan 