adam machanic now blogs at http://sqlblog.com

New version of SQLQueryStress released

Eight months ago I announced the release of the first beta version of SQLQueryStress.

I had big plans: Collect a bunch of feedback, quickly fix any bugs that came in, and release a final version. Time frame of two weeks, tops.

As is often the case, life interrupted my progress. And so and here I am eight months later releasing not the final version, but rather a second beta. Truth be told, feedback was a lot sparser than I'd hoped, and the bugs ended up being a lot harder to track down and fix.  Not that it took me eight months to fix them; I've been working through them on and off only for the last week, and I believe I've tackled most of the major issues that people did bother to report to me.  You can find a list of the fixes/enhancements on the download page.

So if you're interested in checking out this new version, grab it here. Please let me know if you see bugs or anything you like, dislike, etc. I have written this program for the community at large, so please feel free to help guide its future development!

Database Mirroring: FQDNs are Your Friends!

On a recent project for a customer, I learned an imporant Database Mirroring lesson: fully-qualified domain names (FQDNs) are essential!

Both Books Online and the mirroring wizard indicate that it's OK to specify the participating servers as IP addresses--so that's what I did.  The witness came up fine, and the principal came up fine.  Mirroring started, and I did a few manual failovers.  Great!

But now I added the witness server and suddenly things started breaking down. The mirror instance couldn't connect with the witness, and the witness was throwing strange errors like:

Database mirroring connection error 4 'An error occurred while receiving data: '64(The specified network name is no longer available.)'.' for 'TCP://Server2:7024'.

...where "Server2" in this example is the mirror. Notice that the error doesn't include the IP address, but rather the server's name?

After banging my head against the table for a day or so, I wrote to about 50 people asking for help. No answers, and I thought I was out of luck until Don Vilen was kind enough to reply. Turns out, the problem is simple to fix: Don't use IP addresses, ever.  Always use FQDNs!  Thanks, Don!!  Once the FQDNs were used, instead of the IP addresses, everything came up as expected and automatic failovers started working perfectly.

To find your server's FQDN, you can use "ipconfig" from the command prompt, and append the server name to the connection-specific DNS suffix. 

I hope this post helps someone else avoid the frustration I went through. It was a rough couple of days trying to debug this problem and having to tell a customer that their planned HA solution might not work is not a fun situation to be in.