Trottin’ Out Some Talks: SQL PASS Submissions 2011
A Word From Our Panel
I’m full of love for the panel discussion I submitted with my cohorts from Brent Ozar PLF. I smell greatness… and it kinda smells like fresh waffles.
“And Then It Got Even Worse”… Great Mistakes to Learn From
We’ve been there went things went from bad to worse— and then things just kept going. Brent Ozar, Jeremiah Peschka, Kendra Little and Tim Ford share stories of human error, machine failure, and how you can stop a bad situation from spinning out of control. There’s no teacher like experience; but the best trick is to learn from someone else’s (barely contained) disaster.
I love to talk about scale and and application design. I’m getting these first two talks booked for user groups in July and August this year.
Seven Strategic Discussions About Scale
Know those apps that need a complete rewrite from scratch, but management won’t listen to you? Kendra Little has been there and she’s figured out how to frame the big conversations. She’ll give you seven strategies to improve scale and change application architecture, and explain concepts from sharding to caching along the way. You’ll get a toolkit for each conversation: how to gather the right supporting data from the environment, who to talk to, and how to speak the right language to drive each change.
You may not have a chaos monkey, but there’s basic things you can do to protect yourself…
The Top 10 Crimes Against Fault Tolerance
Common design mistakes will kill your uptime when a failure occurs. Kendra Little shows frequent real-world choices that will put a permanent chalk outline around an application when trouble strikes, and how you can keep your databases out of danger.
I also submitted my talk on dates and times, which I gave for the Spring 2011 24 Hours of PASS. I’ve picked up some cool new contents to give the deck a fresh edge.
Dates and times seem simple at first. Kendra Little will show you there’s more to it than you think. She’ll give you five best practices that will help you select the right temporal data type, avoid common issues, and use the most effective techniques to aggregate data. She’ll also explain painful problems with query performance and how to avoid them. Choose wisely: the correct types and high performing data access logic will scale like magic.
And I wrapped things up by submitting my Isolation talk. I’ve reworked this talk to come at the topic from a real-world, practical angle: it’s all about the why.
Performance through Isolation: How Experienced DBAs Manage Concurrency
Do you want to manage highly concurrent software, troubleshoot contention like a pro, and avoid being called in the middle of the night? If so, it’s critical you understand transaction isolation backward and forward and actively make decisions regarding isolation for each of your databases. We’ll discuss the benefits and problems of each isolation level in SQL Server. We’ll talk about practical changes you can make to improve performance while maintaining the right level of concurrency for your users. We’ll focus in detail on how to identify applications which are good candidates for optimistic locking, and how to plan, execute, and monitor changes in your default isolation level. A broadsheet handout will keep your knowledge fresh after the session.