Welcome back to The Ironic DBA Files, a series where the newbie DBA on staff at Dallas DBAs chronicles the ups and downs of fast-tracking a new career as a DBA.
In the last post I talked about how I don’t enjoy coding all that much and how I once dreaded the idea of being a DBA due to the use of TSQL here and there. I’ve gotten over that fear and made some pretty decent strides in beginning to understand how the code works. Getting a basic grasp on the syntax does wonders for understanding what’s going on in a particular script.
You Don’t Know What You Don’t Know
I’ve had a practice Azure VM with an instance of SQL Server 2016 installed almost since day one in my training. The purpose of the VM is to give me a place to get familiar with the workings of SQL Server and it’s associated tools like SSMS.
I wrote a couple of weeks ago about implementing Maintenance Plans on my VM. I was taking regular backups and performing regular maintenance on the instance’s databases, but not really doing anything with it. In my studies, I’ve read and heard over and over that “you don’t have a valid restore plan until you’ve practiced restoring your backups.” So, I decided it was time to get that done.
I decided to approach my restore plan as if I were restoring to an off-site Dev or QA instance. I don’t have one of those, but Kevin had recently added a second, larger E: drive to the VM. So my thought process was to install a new instance of SQL 2016 on the E: drive and then restore my backups to that instance.
This was also a good refresher on installing and updating a new instance to the most current SP and CU. One of the things I’m seeing often when Kevin works with clients is that some of their server issues can be at least partially resolved by simply updating to current SPs and CUs. I’ve tried to internalize this and make it part of my regular instance install routine.
Once my instance was up and running, I started searching for the best way to restore my backups to the new instance. I found the script below and gave it a go.
RESTORE VERIFYONLY FROM DISK = N'F:\SQLskills\20130609_SalesDB_Full.bak WITH CHECKSUM; GO
As you might see, this script was taken from sqlskills.com, and I had to tweak it be valid for my server, such as changing VERIFYONLY to DATABASE and naming the correct database and file names and locations on my E: drive. Simple, right?
Not. Even. Close.
I can’t go into much detail here simply because it would make this post as long as a short novel. Long story, short, the rest of my day and part of the next day was a revelation of rookie mistakes, including, but not limited to:
- Unfamiliar drive and folder permission problems on Windows
- Forgetting about Recovery Models when not finding log backups for some databases
- Not checking the error logs like I should have when problems arose
This sort of thing went on and on before I eventually threw in the towel and asked Kevin for help. He got me sorted out pretty quickly—as a Senior DBA should—and I was back on track restoring my backups.
Rookie Mistakes are Expected
Guess what? Rookie mistakes are part of the process. It’s very much like riding a mountain bike. You are going to crash when you push yourself to the next level. You’re going to forget how to handle certain difficult situations and need guidance.
What this really means is you’re striving to move forward. Learn from your mistakes and add the new-found knowledge and skills you earned from failure and recovery to your tool kit.
You see, not only is Kevin my Senior DBA guiding me through all of this, he’s also been my mountain bike coach since I started riding trails. This is why I emphasized last week about the need to find a mentor if you don’t already have one.
When I’m riding trails alone I tend to be much more cautious and stay well within my skills and experience. However, when I’m riding with others, especially when I have Kevin in front of me showing the way, I’m much more apt to push myself and try new things—even things that scare me.
That was my approach during this whole backup/restore episode. I wasn’t on a Prod server and I knew that Kevin was right there to help me when I needed him. He patiently showed me not only what I was doing wrong, but pointed out things I didn’t know about or had forgotten such as looking at all the options in the Restore Database dialog to properly name my databases and select the file locations.
As a side note, I mentioned before about how part of my problem was a permissions issue that was specifically a Windows thing. I’ve noted before how I’m a long-time Mac user, and one of my main problems in this restore process was simply the differences in the Windows file tree system. Even once I was able to restore my databases properly they were not getting saved where I really wanted them because of one simple click—an unnecessary click in the Mac OS Finder, but absolutely necessary in Windows Explorer.
It’s all part of the process, and I’m getting there one step at a time. Even if some days it’s two steps forward and one step back, progress is being made.
That’s all for this week. Join me next time for The Ironic DBA Files—Episode 8: The Last Rebuild.
Follow me on Twitter at @SQLandMTB, and if you’re into mountain bikes come over and check out my site NTX Trails.
