As SQL Server DBAs working with Always On Availability Groups, sometimes our hands are tied when working with “black box” systems.

– the host machine running your Always On Availability Group VMs that is causing outages. Your Always On Availability Groups are experiencing a lot of unexpected failovers and outages. But since it’s a VM, you don’t know exactly what’s going on at the hypervisor layer that is causing these outrages.

– the storage area network (SAN) that you do not have access to but is causing performance issues. Customers and end-users are complaining about database performance issues and you can perform diagnostics on SQL Server but not the underlying storage. You’re trying to figure out what to say to a SAN admin when you think that the expensive SAN “may” be the cause of the performance problem and you just want to look into it.

– the network that is causing replication latency and puts your databases at risk of going offline. Always On Availability Groups secondary replica could not get caught up with the replication, the transaction log file is growing so fast that you have to constantly remove the secondary replica just so you can shrink the log file.

A black box can lead to finger-pointing and in-fighting within the team, causing issues to stay unresolved and costing the business potential revenue. I’ve seen this happen a lot, especially in very large organizations

If you’re a SQL Server DBA who has to deal with a black box to manage your Always On Availability Group solutions, this is for you.

In this episode of the Practical SQL Server HA/DR Show, I talk about how to deal with black boxes working with SQL Server high availability solutions.

I’ll be doing this on a weekly basis so make sure you keep an eye out for announcements on my social media profiles (LinkedIn | Twitter | YouTube)