Troubleshooting · Performance · Architecture

When the database is the problem, you want the person who has seen it before.

SQL Server consulting across the full lifecycle — production incidents, slow workloads, availability designs that have to hold, and migrations that cannot fail.

Written and run by Michael Paycer, a Senior SQL Server Database Administrator Consultant with more than 20 years hands-on across SQL Server 2000 through 2022, Azure SQL, and AWS RDS.

Top SQL Server wait types by percentage of total wait time An illustrative bar chart of a storage-bound workload: PAGEIOLATCH_SH dominates at 41.8 percent of total wait time, followed by CXCONSUMER at 22.4, WRITELOG at 14.1, LCK_M_U at 9.7, SOS_SCHEDULER_YIELD at 6.3, and RESOURCE_SEMAPHORE at 3.1 percent. Top waits % of wait time PAGEIOLATCH_SH 41.8 CXCONSUMER 22.4 WRITELOG 14.1 LCK_M_U 9.7 SOS_SCHEDULER_YIELD 6.3 RESOURCE_SEMAPHORE 3.1
Illustrative figure — a storage-bound profile, not client data
20+
Years hands-on
2000–2022
SQL Server versions
HA / DR
Always On & clustering
Azure · AWS
Cloud & migrations
The approach

Root cause first. Then the fix.

Most SQL Server problems arrive described by their symptom — "the app is slow," "the job failed again," "we can't fail over." The symptom is rarely the cause, and a fix aimed at the symptom usually moves the problem somewhere else.

The work starts with measurement: wait statistics, execution plans, Query Store history, the error log, and the actual configuration of the instance. What comes back is a cause you can point at, an explanation of why it produces the behavior you're seeing, and a change list ordered by impact — including the items worth doing nothing about.

No offshore hand-off, no junior triage layer, and no recommendation to buy hardware before the workload has been read.

Database lifecycle

Six stages, one continuous obligation.

A database that works today can still be difficult to maintain, impossible to recover, and expensive to scale tomorrow. These are the six stages where that difference is decided.

01

Plan

Requirements, architecture, sizing, security posture, recovery objectives, reporting needs, integration surface, and the maintainability constraints that decide what this system costs to own in year three.

02

Design

Schema modeling, normalization decisions and the deliberate exceptions to them, indexing strategy, naming standards, constraints and data integrity, and the application-facing contract the database is agreeing to honor.

03

Develop

T-SQL development, stored procedures, views, functions and triggers, SSIS packages, SSRS reports, SSAS models, and the data workflows that move information between systems without silently losing it.

04

Operate

Backups and verified restores, monitoring, SQL Agent jobs, Database Mail and alerting, index and statistics maintenance, patching cadence, and the periodic performance review that catches drift before it becomes an incident.

05

Protect

Least-privilege permissions, auditing, encryption planning, PCI-related controls, DoD STIG alignment, SOC 2 readiness, availability design, and disaster recovery that has been tested rather than documented.

06

Improve

Performance tuning, query optimization, execution plan and wait statistics analysis, index refinement, migration planning, platform modernization, and honest assessment of what is worth changing versus what is worth leaving alone.

About

Michael Paycer

A Senior SQL Server Database Administrator Consultant based in Saint Cloud, Minnesota, working across administration, development, performance tuning, database design, HA/DR, security, reporting, ETL, and cloud database environments.

Twenty years of production SQL Server, from 2000 through 2022, plus Azure SQL and AWS RDS — which mostly means having already been on the wrong end of most of the failure modes at least once.

Read the full background on the about page, or see the broader professional profile at michaelpaycer.com.

Get in touch

Describe the SQL Server problem you're facing.

The symptom, the environment, and what's at stake. The clearer the problem, the shorter the path to a cause — and the more honest the estimate of what fixing it takes.