I recently did a migration from one SAN to another and decided to write a quick blog post about the procedure I used. In this particular case the difficult part was handled by the SAN administrator as we were moving from one manufacturer to another. He had the pleasure of trying to add disks from two different storage systems to two nodes, which required not a small amount of dismantling features such as MPIO. We did have some problems with disks showing up multiple times, but nothing we couldn’t work around with.
Every once in a while I run into this little issue with cluster validation check that, while not a critical one, can lead to some confusion. When I deploy clusters to my customers one thing I keep telling them is that they need to update their cluster nodes regularly like any other Windows Server. The other thing I keep telling them is that once they’re all properly updated run the validation test that checks the Windows Updates. And yes, that’s a one way to use the validation tool after you’ve done the deployment 🙂
What is a Performance Baseline?
One of the important things every DBA should have, is a performance baseline for their business critical servers. A good baseline is something that tells you how your server is performing under various workloads. This is also the reason why you should have multiple sets of performance data collected instead of just one. In a perfect world you should have one for the minimum load, one when the usage is “normal” and finally one for the situation where your server and databases are under a lot of stress.
In this post, I’ll be giving you some advice on when and why you should have a performance baseline and how you can create one.
When it comes to finding information or learning more about the SQL Server and it’s features, the professional community around the product is one of the best ones I’ve ever seen. I personally have a score of SQL Server blogs in my bookmarks, I visit SQL Server forums and follow a bunch of world-class experts in Twitter. Basically, there’s a wealth of information out there and unlike many other things in this world, it’s completely free.
To set up IPSEC for a box running SQL Server starts with a simple step, by turning on your Windows Firewall with Advanced Security, if it’s not on already (which it definitely should be!).
After that you need to create two rules for your firewall. First the inbound rule, which allows the clients to connect to your server. And secondly a security rule, in which you define how the connections are authenticated and secured. You could do this directly from the firewall settings, but I prefer using Group Policies myself.
It has been couple weeks since my last post and as we’re going through the end of the year frenzy at the office, I find myself having little energy or time left after work to finish up my posts (I do have a couple of other posts waiting to be finished).
I previously wrote about different methods on how to secure the network traffic on your SQL Server. I mentioned there being two readily available tools that can accomplish this, the SSL and the IPSec. In this post, we’ll take a quick look at how the SSL is implemented on SQL Server.
A while back I had a request to encrypt communications between an instance of SQL Server and the clients connecting to it. I knew that SQL Server had the ability to use SSL to encrypt communications, so this all seemed simple enough to do. The easy way, however, didn’t work for me because of some of the older protocols used did not support SSL encryption. So I was encouraged to look at some other options.