Kendra Little
SQL Server and Azure SQL Adventurer
Kendra Little (she/her) has specialized in relational database performance and automation for 20 years. Kendra worked as a database administrator in both startup environments and for a Fortune 100 corporation. As a consultant and trainer, Kendra focused on performance tuning and database internals. Since then, Kendra has worked as an Advocate and Product Manager focusing on Database DevOps. Kendra has recently joined the SQL Docs team at Microsoft as a Senior Content Developer.
Links
Area of Expertise
Topics
Performance Tuning Azure SQL Database
Azure SQL Database is much more than SQL Server running on someone else's server: the database engine from SQL Server has been adapted-- and in some configurations, radically transformed-- to handle cloud-native workloads. In this session we will cover how to identify the right service tier for your workload, how to identify and manage high CPU scenarios, and how to identify and fight blocking, deadlocks, and slow running queries in Azure SQL Database.
Defuse the Deadlock!
Deadlocks strike fear in the hearts of even experienced database administrators. In this session we will walk through an example deadlock and show how to find and interpret the deadlock graph to understand what is happening. We will examine, rate, and test ways to defuse the deadlock. You'll leave the session with an understanding of the questions to ask and avenues to explore the next time you're hit by a deadlock.
Learn GitHub by Contributing to Micorosoft Docs
Git has become an essential tool for everyone in IT, but many database professionals lag behind and haven't yet learned Git. In this demo-packed session, I'll show you how to learn Git by using GitHub to contribute to Microsoft Documentation. We'll start with an overview of Git and GitHub, then walk through an example of forking a repo, cloning it, creating a branch, committing and pushing a change, and creating a Pull Request.
The Case of the Slow Temp Table: A Performance Tuning Problem
A community member sent me an interesting question: why would using a temp table cause a stored procedure to slow down dramatically? Why would the procedure use massively more logical reads against a temp table than it does against a user database table? In this session we reproduce the problem, then use built-in tools in SQL Server to diagnose and understand what is happening. We use the results to make a plan to keep the stored procedure fast.