Learning to listen

Fellow MVP Chris Shaw (b | t) wrote a blog post earlier this week on learning from mistakes and tagged me to write a similar post – so here it is.

Let me start with a story first. Back in April 1999 I was working for Microsoft on the SQL team as a developer in the Storage Engine team. I’d just joined a few months earlier after spending 5 years at DEC and certainly wasn’t a rookie developer, but I was new at Microsoft. I was writing the DBCC INDEXDEFRAG code and upgrading DBCC SHOWCONTIG (and merging in the functionality of the old, undocumented TVF fn_indexinfo), and I was pretty excited by it (and I still am – defrag/reorg is cool :-).

I was so excited that after I’d had the code for one major part of the project code reviewed by a fellow dev, I checked it in. I remember standing in the corridor outside my office talking with that dev and a tester, when our boss comes along and the conversation turns to my project and I said something like ‘Yup, I just checked in the next part’. My boss’s face started to turn pink and he said ‘ come into my office…’

I then got bawled out because I wasn’t supposed to check in before the boss had reviewed the code it too. I messed up because I hadn’t been listening properly in our team meeting where code review policies had been explained. It wasn’t a nice experience and it was entirely my fault. I decided to start listening. Really listening.

Listening is a critical skill in life – both at work (interacting with clients and colleagues/friends) and at home (interacting with family and friends) – and in my opinion is the most important of the various communication skills (I talk about this and a lot more in my Pluralsight course Communications: How to Talk, Write, Present, and Get Ahead).

As much as possible I like to use what’s called ‘active listening’, where you’re making a conscious effort to focus on what is being said. This involves doing the following:

  • Stop typing and make sure the person can tell you’re paying attention. Even if you can type and listen at the same time, it’s rude and gives the impression that you’re not listening properly.
  • Make eye contact with the person (even just occasionally if that makes you feel uncomfortable). A lot of how humans express themselves involves using the face and eyes so nuanced conversations (e.g. business negotiations, spousal arguments) can be misunderstood without picking up on the visual clues.
  • Remove distractions that prevent you from listening (e.g. step away from a source of noise, turn your back on a television).
  • Ask for a repeat of something that’s not clear so you can make sure you understand it.
  • Summarize what you’ve just heard to make sure you heard what they think they said. This is a great way of being able to get someone to explain something again.

All of these things will make you a better listener, leading to a smoother work and home life. At least that’s the plan :-)

Occasionally I slip up and realize I didn’t listen properly to something important, and then I make doubly sure I’m doing it right for the next few times.

To end with, here are two quotes I like to do with listening:

“I like to listen. I have learned a great deal from listening carefully. Most people never listen.” – Ernest Hemingway
“We have two ears and one mouth so that we can listen twice as much as we speak.” – Epictetus

Survey: using DBCC WRITEPAGE

In this survey I’d like to know what your experience is using the DBCC WRITEPAGE undocumented command.

This survey is closed – see the editorial here – thanks!

I’ll editorialize the results in a week or two.


Disaster recovery 101: restore master or rebuild master

It’s been a hectic January with client work and preparations for our 2014 classes so I haven’t blogged as much as I wanted, but I have lots of blog posts coming up over the next month!

A few weeks ago I kicked off a survey on whether you’ve ever tried or had to restore or rebuild master – thanks to all those who responded. The results are below:


The “other” values are:

  • 6 x “No neither and I’m ashamed”
  • 4 x “Done it years ago but not practiced recently”
  • 3 x “I both practice rebuilding and restoring and have also done both in DR scenarios”
  • 3 x “I’ve rebuilt master due to collation change”
  • 3 x “Moving the other databases to a new server seems easier…”
  • 2 x “I once carefully followed the documented procedure for restoring the master database and it failed every time. Currently, I have copies of the master data and log files saved for emergency restorations. Turn sql server off, if it isn’t already, copy the files…”
  • 1 x “I work for CSS – I feel like it’s cheating to say “Yep, both restore and rebuild, in a drill and in real life”
  • 1 x “I’ve successfully practiced both rebuilding and restoring…but…only after being burned by having to rebuild master on production without backups”
  • 1 x “Rebuild master in demo situation”

I’m very pleased to see the results – almost 60% of respondents have successfully restored or rebuilt the master database, either in practice or for real.

For the rest of you, if you’re responsible for recovering SQL Server during a disaster, then IMHO there’s no excuse for either not knowing how to fix master or not having tried it. Here are a few reasons why:

  1. If master is damaged so that the instance will not start, you can either rebuild master or re-install SQL Server. Which amount of resultant downtime would you rather deal with?
  2. If you have to rebuild master, you’re going to have to:
    1. Restore your master backup, or:
      1. Reattach all databases (do you have a script for that handy?)
      2. Create all server-scoped objects (do you have a script for that handy too? And, do you know what all the server-scoped objects were before the disaster?)
    2. Restore your backup of msdb (you have that, right? Otherwise you’ve lost all your Agent Jobs, backup history, SSIS packages,…)
    3. Restore your backup of model (you have that too, right? Otherwise you’ve lost all the customizations you made.)
  3. If you have to restore master and you don’t know how, or you don’t have a backup of master, then you have to rebuild master – go to reason #2 above.

You need to practice this.

Restoring master is as simple as:

  1. Backup master
  2. Start the server with the -m startup parameter
  3. Restore your master backup
  4. The server shuts down automatically when the restore ends
  5. Remove the -m startup parameter and then restart the server
  6. If any databases were created after the master backup, reattach them
  7. If any server-scoped objects were created after the master backup, recreate them

And you’re off and running again.

Steps 6 and 7 can be mitigated with documentation of all changes made to the instance (you all do that, right?) and making sure that a master backup is taken regularly (e.g. every night). I demonstrate it live when I’m teaching and I walk through the steps in a demo in my Advanced Corruption Recovery Techniques course on Pluralsight (Module 5).

Rebuilding master is also pretty simple and involves using the SQL Server installation media to run the setup.exe using the /ACTION=REBUILDDATABASE option (and maybe some others). Full details for SQL Server 2008 onward are in the Books Online topic Rebuild System Databases (and a bit more info in this post from my buddy Bob Ward). After that you’re going to have to walk through the steps in reason #2 above – so you better have backups of master, msdb, and model too. (For SQL Server 2005, you need to use setup.exe too and for SQL Server 2000 you need to use the old rebuildm utility – Google for people’s blogs and videos explaining how.)

Restoring master is not hard. Rebuilding master is not hard. But the very fact that it’s master makes it a bit scary. And rightly so – if you mess it up you may be looking at a re-install. You certainly don’t want to be doing either of these for the first time ever during a real-life disaster recovery situation.

Practice, practice, practice – is the key to successful disaster recovery, no matter what’s involved.

(Check out my online training courses: SQL Server: Detecting and Correcting Database Corruption and SQL Server: Advanced Corruption Recovery Techniques. We can also help you with disaster recovery.)