A few days ago there was a question in Twitter about options to KILL (SPID) with a long running transaction that was causing a lot of blocking in a mission-critical system. The person asking the question got some helpful tips on how to fix the problem, such as looking at the tables and the indexes and some tools were pointed out to him, like Adam Machanics Sp_WhoIsActive.
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.
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.
Just a small update here. This topic has been for the last 6 years, every year, in top 5 of most read posts in my site. I guess security never goes out of style!
A first post of 2014 and it sure took me awhile to write it up. I was hoping to return to this subject much sooner, however my work schedule has been just plain crazy. Just this week I’ve spent two nights migrating databases to new database clusters. The situation should fix itself in a couple of weeks though, with few bigger projects coming to completion.
But to return to the actual subject of securing SQL Server network traffic.. I previously wrote about using SSL for this purpose, a method that was quick and simple to implement. This was done in my Azure demo environment, which allowed me to take few shortcuts in the implementation. When dealing with production environments, you’ll naturally need to test, test and test it once more before actual implementation.(more…)
Figuring out possible causes for performance issues is one of the core skills for any DBA. There’s a whole bunch of tools for it, but this time I’ll be writing about one of my favorites. The Performance Monitor (PerfMon), which is included in every version and edition of Windows Servers and workstations. PerfMon and I go back a long way and we have had a most satisfying relationship so far. Naturally there have been some rocky spots over the years, but we have never drifted apart.
In previous post, Part 1: Creating Azure Network and Storage, we set up your Azure account ready for two virtual machines that’ll be the backbone of your own testing environment. One of these servers will run the Active Directory and the other one will host your SQL Server 2012 instance. The Active Directory server is really optional, you can do a test environment without it but I prefer test environments that mimic the production.
Now that you’ve setup your Azure account we can get started on building the test environment. First thing you should do is to create a Virtual Azure Network, this will be used for connectivity between your servers. Creating a Network is quite straightforward business. Choose Networks and then Create A Virtual Network.