About
Peter Whyte
SQL Server DBA · Site Reliability Engineer
Full career history on my CV.
I look after production SQL Server for a living, and this site is where I write up what I actually run into: the errors, the wait types, the scripts I reach for, and the fixes worth keeping.
Edinburgh, Scotland · Remote
What I Do
Production operations: incidents, performance, HA and DR, patching, backups, and the automation that keeps all of it repeatable. I work remotely from Edinburgh as a site reliability engineer, which day to day means the databases other people are depending on while they sleep.
Over ten years that has meant both ends of the scale. Multi-terabyte production databases, where one bad plan is measured in hours and a restore has to be a plan rather than a hope. And thousands of databases on Web Edition, where the difficulty is not the size of any one of them but doing anything consistently across all of them at once. Bare metal and virtual machines, Enterprise Edition with Always On for the systems that cannot go down, leaner editions for the ones that can wait until morning.
It is a production-first job rather than a design one. Most of what I know came from being on call for it: what actually breaks, what the error really meant, and which fix held up the second time. The work I like best is taking an ambiguous operational problem, working out the right guardrails, and building something simple and testable that a team can run without me standing over it.
This site is the public version of that work. Start at the scripts, the error library or the wait stats library. Full career history is on the CV.
Why This Site Exists
Most SQL Server answers online are a forum thread from 2011 or a page that repeats the error message back at you. Mid-incident I want the opposite: what the message means, whether it matters, and what to run next. So I started writing that version down.
The rule I hold myself to is that it has to be technically sound. Scripts are run against real instances before they are published, and the ones with evidence behind them carry a verified marker. When a reader tells me something is wrong, that is a good day, because the correction makes the library better.
Where My Work Lives
Four libraries carry most of it. Whatever brought you in, the rest of that library sits one link away.
DBA Scripts
The toolbelt. Copy-and-paste T-SQL for what you check often, each with the output explained.
Browse the scripts →Error Library
Paste the error message, find the cause. What each number means and the fix that worked.
Look up an error →Wait Types Library
Every documented wait type, and the part that matters: worth chasing, or noise to filter out.
Find a wait type →SSMS Complete Guide
Install, configure, fix. The settings and shortcuts worth knowing, and what recent versions changed.
Open the guide →The Open Source Side
The scripts behind the posts live in a public repository, dba-tools, under an MIT licence: 180+ SQL scripts you can paste straight into SSMS, PowerShell wrappers that export the same results to CSV, a local dashboard for reviewing a health check, and a collection workflow that gathers everything from one instance so an AI can review it alongside you.
There is also an MCP server that hands this reference to whatever AI assistant you already use, so it looks answers up here instead of recalling them. It never connects to your SQL Server, every answer carries a source link, and it says so when something is not in the library rather than inventing one.
Working With Me
I am open to working with the SQL Server community on just about any opportunity: a question, a second opinion, or something you think this site should cover. Paid work is the exception, I am not open to that at the moment, though I may be in future and I will say so here and link to it when that changes.
What is always worth sending is a correction. If something here is wrong, out of date, or does not behave the way the post says on your version, email me@peterwhyte.com and I will fix it.
Frequently Asked Questions
Are the scripts safe to run in production?
The large majority are read-only, and every script states its safety class and the permission it needs in its own header. The handful that create objects or write data say so explicitly. When a script generates T-SQL rather than executing it, review that output before you run it.
Which SQL Server versions does this cover?
SQL Server 2016 and later, which is what I run and can verify. Where something depends on a newer version, the post says which one. Build and support-lifecycle information is kept in its own reference and dated, because that detail goes stale quietly.
Can I use these scripts at work?
Yes. The repository is MIT licensed, so you can use, adapt and ship them. If a script saves you an afternoon, that is the entire point.
You have spotted a technical error. What now?
Please tell me: me@peterwhyte.com. I will be quick to update it. A correction from a working DBA is worth more to me than another new post, and it gets fixed at the source, so the site, the repository and the MCP server all improve at once rather than the page alone.
That goes for anything that reads wrong: a script that errors on your version, a threshold you would argue with, output that does not match what you see, or a fix that did not hold. I would far rather hear it than have it sit there being wrong.
Can I hire you for a specific problem?
Not at the moment, and there is nothing to book. Email me anyway: if I can point you at the answer, I will.
Is anything on this site consulting in disguise?
No. Nothing here is a teaser for a paid version, there is no gated content, and the scripts are MIT licensed in a public repository. The site is ad supported and that is the whole of it. If that changes, it will change openly.
I write about non-database things, hiking, gear and the occasional opinion, over at peterwhyte.com. The code lives on GitHub.