SQL Optima guide
Cutover checklists for engine migrations
The boring list that prevents dramatic go-live nights.
/*
================================================================================
SQL Server Backup Log Chain Integrity
================================================================================
Description:
Detects breaks in the transaction log backup chain for FULL recovery model
databases. A broken log chain prevents point-in-time recovery and can make
restore operations fail after the break point.
Output:
Sequential log backup listing with LSN ranges, highlighting gaps where
first_lsn of the next backup does not match last_lsn of the previous backup.
Action:
If a log chain break is detected (missing LSN continuity), immediately take
a new full backup followed by regular log backups. Investigate why the break
occurred — common causes: log backup failure, database switched to SIMPLE
recovery, or manual log shrink (SHRINKFILE). Run weekly to catch breaks early.
Criticality: Critical
Author: Ravi Sharma
================================================================================
*/
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
SET NOCOUNT ON;
;WITH LogBackups AS (
SELECT
bs.database_name,
bs.backup_start_date,
bs.backup_finish_date,
bs.first_lsn,
bs.last_lsn,
bs.database_backup_lsn,
ROW_NUMBER() OVER (PARTITION BY bs.database_name ORDER BY bs.backup_start_date) AS rn
FROM msdb.dbo.backupset AS bs
WHERE bs.type = N'L'
),
ChainCheck AS (
SELECT
curr.database_name,
prev.backup_finish_date AS [Previous_Log_Backup],
curr.backup_finish_date AS [Current_Log_Backup],
prev.last_lsn AS [Previous_Last_LSN],
curr.first_lsn AS [Current_First_LSN],
CASE
WHEN prev.last_lsn <> curr.first_lsn THEN N'BREAK'
ELSE N'OK'
END AS [Chain_Status]
FROM LogBackups AS curr
INNER JOIN LogBackups AS prev
ON curr.database_name = prev.database_name
AND curr.rn = prev.rn + 1
)
SELECT
d.name AS [Database_Name],
d.recovery_model_desc,
cc.Previous_Log_Backup,
cc.Current_Log_Backup,
cc.Previous_Last_LSN,
cc.Current_First_LSN,
cc.Chain_Status
FROM ChainCheck AS cc
INNER JOIN sys.databases AS d ON d.name = cc.database_name
WHERE cc.Chain_Status = N'BREAK'
AND d.recovery_model_desc = N'FULL'
AND d.database_id > 4
ORDER BY cc.Current_Log_Backup DESC;
IF @@ROWCOUNT = 0
PRINT 'No log chain breaks detected in msdb backup history.';
Review the full script and confirm the connected SQL Server instance before execution. The run instructions and output guide appear later in this article.
Migrations fail less from tooling and more from skipped rehearsal.
Baseline latency and top queries, rehearse cutover with schema compare gates, verify backups, and keep a rollback owner. SQLOptima Migration and Monitoring exist to make that checklist measurable.
For SQL Server 2016 → 2022 engagements, use the phase-gated migration checklist and Compat 160 playbook in the handbook:
Why migration cutover deserves a method
The central principle is that a cutover checklist coordinates people, data, applications, validation, and rollback under a limited decision window. A single metric, recommendation, or successful command is not enough. The decision has to connect an observed symptom to a plausible cause, a controlled change, and a result that can be verified under the workload that matters.
Evidence to collect
Use evidence from the same time window whenever possible:
- replication lag and final synchronization
- write freeze and connection change
- business validation and reconciliation
- rollback time and authority
A practical workflow
- Define entry criteria and decision owners.
- Rehearse the timed sequence.
- Capture evidence at every checkpoint.
- Close only after monitoring and business validation stabilize.
Common mistakes
Avoid these shortcuts:
- using a task list without stop conditions
- changing scope during the window
- leaving rollback ownership ambiguous
Verification and completion
Define completion before making the change. Confirm correctness first, then compare latency, throughput, reads, CPU, waits, storage behavior, or recovery time as appropriate for Cutover checklists for engine migrations. Test negative and boundary cases, not only the path expected to succeed. Watch the system long enough to cover the relevant workload pattern.
Download and run the diagnostic
Backup and log-chain review
Download backup_log_chain.sqlBefore you run it
- Review every statement and confirm the connection points to the intended SQL Server database server.
- Run through a non-production or read-only diagnostic account first when possible.
- Required access: read access to msdb backup history.
- Save the output with the server name, database name, collection time, and workload window so another engineer can reproduce the analysis.
What it does
Reviews backup history and log-chain evidence needed before a migration or recovery cutover. The script is diagnostic and does not apply an automatic remediation. Result values still need workload context, a second supporting signal, and a before-and-after comparison.
How to read the output values
Confirm the latest full backup, differential base where used, and uninterrupted log sequence through the planned recovery point. A recent timestamp does not prove restoreability, so retain media locations and complete a restore rehearsal.