I am a huge fan of managed database services, no matter which cloud platform they’re running on. The simple reason is that I am not a huge fan of managing the automation for the basic things like backups, patching and high availability myself anymore. There is a trade-off though when you’re using someone else’s automation to manage your environments, the price you pay is the limited visibility of what’s happening underneath the covers.
I was reminded about this the other day as I was attempting to restore a database from one Managed Instance to another, a pretty standard thing to do for certain, and was facing an issue with it. In the end the problem itself was easy to fix but difficult to figure out.
I have previously written quite a few post about how much I like the Platform-as-a-Service databases for SQL Server (and for databases in general), and I do like them quite a bit. But would I recommend them for all use cases and workloads? Heck no! At the moment there are some features and limitations in Azure SQL PaaS databases that, with some of hte SQL Server workloads I have seen, wouldn’t just work all that well.
Also when we look at Azure, there’s some really cool features available for VMs that you can start using today, which are making the good old VMs an interesting option.
About two months back I ended up moving to another job, which has unfortunately kept me to be bit too occupied to find the time to blog, until now. Due to this previously mentioned career change, I have been working quite a bit with monitoring, and it gave me a spark to write this post about my favorite PerfMon counters.
Like most DBAs I rely quite a lot on monitoring, and like most DBAs I too have my own set of PerfMon counters that I rely on to provide me an accurate view of what’s happening in the environment I am administering. In this post, I’ll describe what are my favorite PerfMon counters.