Database maintenance on Rudi Bruchez

A complete guide to SHRINK in SQL Server

Fri, 13 Feb 2026 00:00:00 +0000

TL;DR

A shrink is a manual, one-off operation, never automated and never scheduled. Always use DBCC SHRINKFILE on a specific file, never DBCC SHRINKDATABASE. On large files, shrink in small increments rather than in one go. The operation never corrupts the database: SQL Server is dependable here.

When should you shrink?

Shrinking is discouraged as a general rule. It is an expensive operation that fragments indexes heavily. Paul Randal, who wrote the SHRINK command in SQL Server 2005, explains it in detail: Why you should not shrink your data files.

Taking backups on an availability group

Mon, 01 Jan 0001 00:00:00 +0000

Download and install Ola Hallengren’s procedure.
Schedule COPY_ONLY full backups on each replica. This assumes the availability group is configured to prefer backups on the secondary replica. To check that, use this query and look at the automated_backup_preference column.
Schedule log backups on each replica. Ola Hallengren’s procedure automatically runs the backup on the preferred replica. You can use the example calls on my GitHub.
To delete the old backups, on a schedule if you want, you can use dbatools and this command:

Remove-DbaBackup -Path '\\backup-server\repo$\CLUSTER-SQL-AG\MyDatabase\' -BackupFileExtension bak -RetentionPeriod 48h

Identify and fix transaction log problems

Mon, 01 Jan 0001 00:00:00 +0000

YouTube

See also my YouTube video: Comprendre les problèmes du journal de transaction dans SQL Server (in French)

The transaction log of a SQL Server database keeps the transactional history of the writes made to that database.

If the recovery model of a database is FULL, the transaction log keeps everything, so that a transaction log backup can archive it.
If the recovery model of a database is SIMPLE, the transaction log is emptied regularly.

The problems this creates:

SQL Server transaction log backups: why and how

Mon, 02 Mar 2026 00:00:00 +0000

TL;DR

A SQL Server transaction log growing out of control, because the database recovery model is FULL, is one of the most common problems you will meet with SQL Server.

Administrators often switch to the SIMPLE recovery model to avoid it, wary of managing a transaction log backup strategy — when that strategy is very nearly mandatory in production.