The trusty "sp_who2" is a quick way to look at what's happening on your SQL instance, but you can't put a WHERE clause on that thing! You have to manually sift through the results and there could be hundreds of results.
When your security gets unruly, it can get time consuming to figure out how a user is accessing a SQL instance. Sometimes you may know that a user is getting access via one certain AD group but you aren't sure if any other groups are granting access. Furthermore, a user might be in a group that's nested in another group, through which they are gaining access to your SQL instance.
Here is a situation I just came across (boiled down and simplified). An end user was having to manually find a user id, navigate to an image folder, and then search through hundreds of images to find the one corresponding with that user. Sure, they were in numerical order, but still, what a pain! He wanted to generate an excel file with links to files to quickly access the corresponding image.
When using AlwaysOn, you must connect using your listener name, not your node name. If you connect with the node name, it will only work until there is a failover, which would defeat the purpose of your High Availability setup, right?
This is a bit of a scary task. Someone tells you about 87 databases that all need to be restored from the most recent FULL backups. You can either spend the rest of your day pointing and clicking, or you can use some PowerShell power to crank out the script and get on with your day. Here is the PowerShell way.
I don't like to fire-off the actual backups from PowerShell, rather I just use it to script out the restore script. So, this PowerShell script will output the T-SQL restore script:
One common question I hear whenever something begins to go wrong is, "Has anything been changed recently?" Finding recent changes can be a good place to search, depending on the issue, so here is a script to do just that.