Due to commitments to his startup venture Thomas Kejser has given me full access to his presentation material and asked me to present his Super Scaling SQL Server course going forwards. My intention would be to take my material and amalgamate it with that provided by Thomas. If there is enough demand for me to provide some sort of training, I envisage this would be a days class somewhere and / or a precon which would take the general form of:
- Understanding the database engine at level 400, this would go beyond what the standard tools can provide and also beyond what the SQL Server internals book can provide in places.
- An introduction to windows performance toolkit.
- How to read SQL Server stack traces.
- Diagnosing CPU saturation problems using windows performance toolkit.
- Understanding ‘Exotic’ wait types and spinlocks from the call stack.
- How the database engine behaves when it is pushed to its limits.
This is not an exhaustive list of what the training might cover, but just enough to provide a ‘Taster’. I’m interested to see what sort of demand there is for me to provide this and also based on what people know about me from what I blog about and present, what sort of things you would like me to include.
One thought on “Training, Your Feedback Is Required”
Chris, a coworker and I would likely be interested in this, either as a precon, a 1-2 day class (ideally in central London) or online training. (I took Thomas’ Super-scaling SQL Server course last year, and my coworker was enrolled to take it this year until it was cancelled.)
The key for me would be coming away with enough knowledge to use these tools properly in various scenarios, and ideally some form of reference material for how to configure them properly (e.g. which flags to use when). My trouble with many of these MS debugging tools is the lack of documentation except for MSDN blog posts with instructions that frequently stop working between OS releases or even Service Packs. MS support is often not of much help either — if you can’t get to the right people, they’ll actually tell you that WinDbg is ‘unsupported’.
I think there is also a need for some foundational material to help bridge the gap between a DBA’s level of knowledge and the level of knowledge of someone familiar with debugging complex programs. I can quite openly admit I’m not fully comfortable exploring memory dumps and stack traces, and frequently get lost when trying to follow the thought processes of expert debuggers such as Vostokov or some of the MSDN bloggers who focus on WinDbg.
I also think there should likely be some focus on the network layer. This is barely touched in most of the internals books and blogs etc. For example, I don’t recall the Internals book even mentioning the word TDS more than once. I think it’s quite likely there are scenarios where understanding the behaviour of the wire protocol could help us improve performance and understand the causes of odd delays and hangs. There also generally isn’t much understanding of the exact details of interactions between ASYNC_NETWORK_IO waits and client application code. DBAs also generally don’t understand how the TCP receive window can affect performance, and how parallelism is required to work around it. This understanding is key to tuning ETL that transfers data over long geographical distances, as well as storage performance over TCP (SMB or iSCSI).