Problems
Start from the problem
For blocking, upgrade failure, restore uncertainty, monitoring gaps, and the other situations where the symptom is clear but the next step is not.
MKsql server
Start here when you need to work out whether this is a live SQL Server problem, a planned change, or a broader review that needs outside help.
This page groups the SQL Server work into three usable paths: problem pages for obvious symptoms, guide hubs for deeper technical reading, and service pages for review, triage, or rollout support.
Problems
For blocking, upgrade failure, restore uncertainty, monitoring gaps, and the other situations where the symptom is clear but the next step is not.
Families
For operational health, performance, planned change, and recovery work when you already know the technical lane and want the deeper pages grouped together.
Services
Use these service pages for health audits, performance review, recovery readiness, and upgrade support when the team needs practical help rather than more reading.
Problems
These pages help when the problem is obvious but the root cause is not. Each one is built to shorten the first read, the first checks, and the jump to the right deeper guide.
Incident and stabilization
Use this when waiting chains, lock pressure, or head blockers are already hurting production and the team needs a faster diagnosis path.
Incident and stabilization
Use this when the system is just slow enough to hurt work, but the root cause is still fuzzy and every quick guess points somewhere else.
Incident and stabilization
Use this when victims keep showing up, transactions overlap badly, and the team needs a cleaner path than killing sessions and hoping.
Project and planned change
Use this when a version change already went wrong, the rollout confidence is damaged, or the next attempt needs much tighter control.
Incident and stabilization
Use this when backups exist, but nobody can say with confidence how recovery would go in practice.
Audit and health review
Use this when tempdb growth, spills, version store, or inherited setup choices are starting to leak into wider instability.
Project and planned change
Use this when the version is aging, the support picture is messy, or patching has started to feel like change work nobody really owns.
Audit and health review
Use this when backup jobs exist, but retention, proof, and recovery confidence are weak enough that the team should not treat the issue as solved.
Project and planned change
Use this when the estate is moving and the real question is whether the plan, rollback, and dependency picture are strong enough yet.
Audit and health review
Use this when incidents or slowdowns keep happening, but the team still does not have enough visibility to prove the pattern cleanly.
Families
These hubs keep related SQL topics together, so you can stay inside one lane instead of bouncing across a flat list of older guide pages.
Operational resilience
Health reviews, tempdb sanity, monitoring gaps, and the operating basics that make a SQL estate easier to trust.
Performance
Blocking, deadlocks, waits, indexing, and the deeper reading behind real production performance work.
Planned change
Upgrades, migrations, patching risk, and the production change work that needs rehearsal instead of optimism.
Recovery and DR
Backup design, restore proof, failover discipline, and the recovery work behind operational trust.
Services
These are the right pages when the issue is already live, the change window is close, or the team wants an external review before making the wrong move.
Audit and health review
Practical review for inherited estates, weak operational ownership, and environments that need a real fix order.
Incident and stabilization
Performance and concurrency review for blocking, deadlocks, broad slowness, and unstable workload behavior.
Incident and stabilization
Backup, restore, and DR review for teams that do not want recovery confidence to stay theoretical.
Project and planned change
Upgrade and rollout support for version changes that need readiness review, rollback thinking, and calmer execution.
Older guides
These older SQL guides are still live and still useful. This page just groups them more cleanly so you can reach them by problem or technical area without digging through the whole hub.
operational resilience health
Environment review, operational drift, restore confidence, and the wider estate questions behind a proper SQL review.
operational resilience health
Tempdb setup, growth behavior, version-store pressure, and the workload clues that usually sit behind tempdb pain.
operational resilience health
Baselines, waits, alerting, backup visibility, and the missing signals that make incidents harder to prove.
operational resilience health
Workload profiling, hardware fit, capacity pressure, and the platform questions that sit behind recurring SQL stress.
performance blocking concurrency
Blocking chains, head blockers, transaction scope, and the production-safe path to diagnosing recurring contention.
performance blocking concurrency
Deadlock capture, transaction overlap, indexing causes, and the concurrency patterns behind repeated deadlock victims.
performance blocking concurrency
Access-path review, write tradeoffs, and workload-based indexing decisions instead of tuning folklore.
planned change
CU vs GDR, build-number interpretation, and how to separate a patch decision from a real upgrade decision.
planned change
Live SQL Server supported-build and version-history reference built from Microsoft's update source.
planned change
Version-lifecycle planning, rollout risk, rollback thinking, and the production checks around major SQL changes.
planned change
Inventory, dependency mapping, rehearsals, rollback design, and cutover planning for real production moves.
recovery backup dr
Backup strategy, retention, restore proof, and the gaps that only become visible when recovery work becomes real.
recovery backup dr
Restore readiness, recovery timing, dependency traps, and the runbook discipline that shortens incidents.
recovery backup dr
Failover testing, HA tradeoffs, and the operational load that still exists after redundancy is in place.