22-25 April 2026
SQLBits 2022

Fundamentals of Stored Procedures

How to write stored procedures that have a high likelihood of performing well and are easy to troubleshoot.
Anybody can write a stored procedure with a little help from Google. This session is about how to write stored procedures that have a high likelihood of performing well and are easy to troubleshoot.

This fast-paced, all-demo session with Brent Ozar will NOT cover how to write a query, syntax, or performance tuning. This is about good best practices after you've written the first one - things like how to catch errors, how to pass in multiple values, how to debug without the debugger, and more.

In fifty minutes, we'll walk through the contents of a well-written stored procedure and explain why it looks the way it does. You'll leave with the contents of that exact stored procedure so you can use it as a starting template in your own company.

feedback link : https://sqlb.it/?7065

Speakers

Brent Ozar

brentozar.com

Brent Ozar's previous sessions

300-Level Guide to Career Internals: Planning Your Career
A roadmap of options for your career.
 
Fragmentation Explained in 20 Minutes
What do index rebuilds and defrags really do?
 
Fundamentals of Stored Procedures
How to write stored procedures that have a high likelihood of performing well and are easy to troubleshoot.
 
300-Level Guide to Career Internals: Planning Your Career
Isn't it awkward when someone asks you, "So, where do you see yourself 5 years from now?" Brent Ozar will share how he analyzed the data job market to build his career path.
 
500-Level Guide to Career Internals: Building a Brand
If you want to work for yourself, you need to be able to sell yourself. I know, I hate it too - it feels gross when I write it that way. I'm Brent Ozar. You recognize my name, that's why you wanna learn this from me.
 
Deadlocks: Lets Do One, Understand It, and Fix It
You keep getting warnings and emails about deadlocks, but let's be honest: you're not really sure how they happen or what to do about it. Brent Ozar will show one, use sp_BlitzLock to analyze it, then fix it.
 
"But It Worked in Development!" 3 Hard Performance Problems
You've been performance tuning queries and indexes for a few years, but lately, you've been running into problems you can't explain. Could it be RESOURCE_SEMAPHORE, THREADPOOL, or lock escalation?
 
Easy Performance Tuning: an Intro to Wait Statistics
You're a DBA who's struggled with Perfmon metrics and Profiler. You're facing a sea of confusing numbers, and you don't know where to focus first. Microsoft Certified Master Brent Ozar will give you a friendly introduction to wait statistics.
 
How to Pick SQL Server Hardware
You don't buy a lot of servers, but you're about to deploy SQL Server, and you only get one chance to make it right. Brent Ozar will boil down everything you need to know into just a few simple decisions including SQL Edition, sockets, and RAM.
 
How the SQL Server Engine Thinks
How does SQL Server build results? We'll role play: Brent Ozar will be an end user sending in queries, and you'll be SQL Server. This session is for people who are comfortable writing queries, but not with indexes, statistics, and sargability.
 
Watch Brent Tune Queries
Ever wonder how someone else does it? There’s no right way or wrong way, but in this session you can peer over Brent’s shoulder (virtually) while he takes a few Stack Overflow queries and tries various techniques to make them faster.
 
Virtualization and SAN Basics for DBAs
These two technologies can make a very big – and very bad – difference in how your SQL Server performs. Wouldn’t it be great if you could get the real, honest lowdown from a virtualization administrator, a SAN administrator, and a DBA? Wouldn’t it be even better if one person had done all three, and could give you the pros and cons of each point of view? That person is Brent Ozar, a Microsoft Certified Master who’s been there and done that.
 
SQL Server Storage - 1,000GB Level
PANIC IN THE DATACENTER! Your databases are approaching - or surpassed - the Terrible Terabyte mark. You're pouring money into the SAN, but your data isn't pouring back out as fast as you want. You're terrified to DBCCs or index maintenance because everything takes forever, and you don't have big maintenance windows.