Joe Sack is a Principal Program Manager on the Microsoft SQL Server Database Systems team. He has worked as a SQL Server professional since 1997 and has supported and developed for SQL Server environments in financial services, IT consulting, manufacturing, retail and the real estate industry.
Joe Sack (@josephsack) of SQLskills.com shows us that we might not always be able to make an accurate correlation between wait statistics and observer overhead, depending on the method being used to observe a system.
SQLskills' Joe Sack (@josephsack) walks us through an interesting scenario where we might blame a query performance issue on parameter sniffing or bad statistics, when it actually turns out that a check constraint is the best solution to keep the optimizer honest.
I recently encountered high TRANSACTION_MUTEX accumulated wait time on a client system. I couldn't recall a case where I saw this wait type as near the top of the "high waits" list and I was curious about what factors could push this type of overall wait time.
The Books Online definition of TRANSACTION_MUTEX is that it "occurs during synchronization of access to a transaction by multiple batches." Not many areas within the SQL Server engine expose this type of functionality, so my investigation was narrowed down to the following technologies:
The quality of an execution plan is highly dependent on the accuracy of the estimated number of rows output by each plan operator. If the estimated number of rows is significantly skewed from the actual number of rows, this can have a significant impact on the quality of a query's execution plan. Poor plan quality can be responsible for excessive I/O, inflated CPU, memory pressure, decreased throughput and reduced overall concurrency.
SQL Server 2012 AlwaysOn Availability Groups require a database mirroring endpoint for each SQL Server instance that will be hosting an availability group replica and/or database mirroring session. This SQL Server instance endpoint is then shared by one or more availability group replicas and/or database mirroring sessions and is the mechanism for communication between the primary replica and the associated secondary replicas.
Depending on the data modification workloads on the primary replica, the availability group messaging throughput requirements can be non-trivial. This activity is also sensitive to traffic from concurrent non-availability group activity. If throughput is suffering due to degraded bandwidth and concurrent traffic, you may consider isolating the availability group traffic to its own dedicated network adapter for each SQL Server instance hosting an availability replica. This post will describe this process and also briefly describe what you might expect to see in a degraded throughput scenario.