SQL Server on Rudi Bruchez

Identify blocking problems

Fri, 28 Aug 2026 00:00:00 +0000

TL;DR

Blocking happens when one session waits for a lock held by another session. To find out who blocks what, you enable the blocked process threshold and start an Extended Events session that records a report every time a block exceeds that threshold. You let it run for a few days, compress the .xel files and send them for analysis. The impact on production is negligible.

This page is a procedure to follow from start to finish. If you are in a hurry, the five steps are: set the threshold, create the session, let it run, collect the files, clean up.

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.

Why you should NOT multiply SQL Server instances

Tue, 27 Jan 2026 00:00:00 +0000

TL;DR

Installing several instances on the same production server is almost never necessary. Consolidate all your databases onto one instance.

A single instance gives you better performance, better visibility and simpler operations.

Having to support different SQL Server versions per database is not an argument for several instances. The database compatibility level handles that.

Why do people install several instances on one server?

In a world of virtualisation and containers, a system administrator’s natural reflex is to isolate: one application, one service, one instance.

Installing and configuring SQL Server 2025 on Windows Server

Wed, 18 Feb 2026 00:00:00 +0000

This guide covers the whole process of installing SQL Server 2025 on Windows Server (2019 / 2022 / 2025), then the post-installation configuration through the Server Properties in SSMS and the SQL Server Configuration Manager.

Prerequisites

Minimum and recommended hardware

Component	Minimum	Recommended
Processor	x64 — 1.4 GHz	2.0 GHz or more, up to 64 cores per NUMA node
Memory (RAM)	1 GB, 512 MB for Express	≥ 4 GB, increasing with the size of the databases
Disk space	6 GB minimum	≥ 50 GB for a production environment, excluding data
Display	Super VGA 800 × 600	1920 × 1080
Network	Built-in network adapter	Internet access for updates

Software requirements

Component	Required version
Operating system	Windows Server 2019 / 2022 / 2025, including Server Core
.NET Framework	4.7.2, installed automatically if missing
PowerShell	5.1 or later
Network protocols	TCP/IP, Named Pipes, Shared Memory, all built into the OS

Note: SQL Server 2025 installs on x64 processors only. 32-bit installations are no longer supported.

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.

Do not break your indexes — SARGability and WHERE clause anti-patterns

Wed, 25 Feb 2026 00:00:00 +0000

TL;DR

Applying a function to a column in the WHERE clause stops SQL Server from using the indexes on that column. Such a query is called non-SARGable. The result: an Index Scan, a full traversal, instead of an Index Seek, a direct lookup.

The most frequent culprits: COALESCE, ISNULL, CONVERT, YEAR(), LEFT(), TRIM() applied to the filtered columns.

The fix: move the logic to the value or the parameter side, never to the column side.