I’ve been using Powershell more and more lately, most of the time the motivation has been to do repeatable tasks much more quickly and efficiently but there has also been other cases where Powershell has been the only way to accomplish something. Most often this is due to lacking GUI or Windows issues that have prevented me from using the GUI in the first place. This post describes the latter scenario and the Powershell workaround.
Not a long ago I was doing a database cluster delivery to one of our customers and as a part of that process, I scheduled our regular set of test runs for the storage. The results of the tests we ran were bad and none of the changes we did at the SAN weren’t helping. After a while we figured out that the issue was not in the test software or at the SAN but in the scheduled tasks we used to run the different test!
One of the more important duties of a DBA is to make sure that their databases and the data is secure. In this post we’ll be looking at two utilities to increase the security of your server, the Windows Firewall and an antivirus software. Like with about everything else related to servers, you can’t just switch these on (well, you could, but…) and forget about them to get the best possible experience. They need to be properly configured for servers running Microsoft SQL Server. If you’re a DBA you might not be doing the configuration yourself, but you still need to tell your Windows administrators what they need to do.
Just a friendly reminder to everyone that just like all good things come to and end so does the extended support for these two Microsoft products. First will be the Windows 2003 R2 with the end of lifecycle date set to July 14 2015 and soon after that SQL Server 2005 with it’s end of lifecycle date set to April 12 2016.
You can still run these products after these dates of course but it’s definitely not recommended and the reason is simple. End of the extended support means that neither of these products will be receiving any patches or security updates, ever. So if you’re not already working on upgrading them, now would be a good time to start.
PerfMon is a great tool for collecting performance data from your servers, but it has a few shortcomings when it comes to reporting these results. One of the biggest issues that I also mention in one of my older posts here is, that the graphical presentation becomes hugely inaccurate when you collect data over a long period. While this might not bother you personally, if you’re writing that report to your manager or a customer, it makes sense to show information that is correct.
Let’s look at a simple example.
When I’m dealing with a problem on a Failover Cluster (not very often, but sometimes) one of the first steps I do is to run the Validation Test. It’s a great tool that’ll usually show what might be the problem, but apparently not always…
For the last couple days I’ve been busy wrecking havoc on a cluster with a Microsoft Cluster PFE on a Cluster Disaster Recovery workshop. Among the scenarios we’ve gone through causing, fixing and then documenting there was one that had a small surprise in store for both of us.
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.