25 TB down to 6 TB
A multi-terabyte database moved to a new disk, with production stopped only for the switchover.
15 h 59 min down to 19 s
The CPU time of a settlement query, after rewriting one date bound.
10 h 31 min down to 1 h 46 min
The full backup of a 1.3 TB data warehouse.
Clients are not named. Every result below comes from a measurement taken on the client’s server and recorded during the engagement: a duration, a size, a wait counter. Gains that were only estimated are not listed here.
A 25 TB disk brought down to 6 TB
An international industrial group, SQL Server Standard Edition, in 2026. A multi-terabyte database sat on a 25 TB disk billed monthly by the hosting provider. Shrinking a managed disk requires a migration, while growing one is done online. So the space had to be freed inside the database, then the database moved to a new, smaller disk, without stopping production for longer than a switchover.
- Free the space. I dropped the indexes that had become useless, then compressed the largest ones with ROW or PAGE, chosen index by index from their write rate. Standard Edition cannot resume an interrupted rebuild, and the data loader, which writes every five minutes, blocked the longest ones. So I got a night window with the loader paused: 17 indexes went from 3,046.9 GB to 1,186.5 GB in one night. The main data file then went from 7,070 GB to 2,531 GB.
- Prepare the new disk without any interruption. The database was restored under another name onto a 6 TB disk while production kept running. A log backup every 15 minutes, restored right away, kept the copy current: 73 restores out of 73 without failure.
- Switch over. During an outage agreed with the local team, I applied the last log, then two renames made the copy the production database. The applications reconnected by name, with no change on their side.
- Remove the old disk, once the integrity of the new database was checked and the last small databases moved.
Along the way, the full backup went from 5 h 09 min to 2 h 25 min.
A data warehouse bound by its disk reads
An international manufacturer, a data warehouse on a virtual machine with 1.6 TB of memory, in 2026. The server was slow for no known reason. CPU averaged 4 %, but the instance read about 400 MB per second continuously, and an archive disk answered in 504 ms per read.
That same evening I applied four online, reversible settings, each logged with its expected effect: indirect checkpoint, asynchronous statistics updates, cost threshold for parallelism, optimize for ad hoc workloads. Over the following day:
- server waits went from 14.3 to 11.3 hours per hour, 21 % less, and disk read waits from 2.26 to 1.53 hours per hour;
- the synchronous statistics update wait went from 0.28 to 0.05 hour per hour;
- the checkpoint messages that scanned the whole buffer pool, about one every three minutes and 16,064 in eleven days, disappeared.
Query Store, enabled the same evening, then showed the underlying cause: reporting queries that reread whole fact tables back to 2012. A rewritten partition check went from 12 s to 5 ms, measured on a clone of the database.
Performance
| Context | What I did | Result |
|---|---|---|
| Clothing retailer, 1.3 TB data warehouse (2014) | Per-partition compression, compressed backups, index cleanup, memory and parallelism settings | Full backup from 10 h 31 min to 1 h 46 min, database down to 800 GB |
| Travel booking platform (2019) | Missing indexes, rewrite of the most called procedures | Response time under load from 60 s to 3 s, with 50 users |
| ERP integrator, financial reporting (2021) | Cursors replaced by a set-based query | A calculation of more than 30 minutes down to about 4 seconds |
| IT provider, animal health sector (2018) | Night intervention, statistics updates restored | Sales declaration from 20 minutes to 10 seconds |
| Mutual savings company, BI chain (2025) | Parallelism threshold and CPU affinity fixed | Processing finished before 9 a.m. instead of 3 p.m. |
| Industrial group, settlement query (2026) | Rewrite of a date bound, with no index and no schema change | From 15 h 59 min of CPU to about 19 seconds |
| Same group, purge procedure (2026) | Compressed composite index | From 159 s to 669 ms |
| Car dealership group, line-of-business ERP (2019) | Rewrite of a text search | From 28 seconds to 1 second |
| Real estate software vendor (2025) | Analysis of an Entity Framework query, forced plan | From 28 s to 122 ms, root cause then fixed by the vendor |
| Livestock software vendor (2018 to 2021) | Tuned procedures, useless indexes dropped | Key procedure from 35 s to 690 ms, 4 GB of indexes dropped |
| Food producer (2026) | Migration to SQL Server 2025, import redesign, monthly partitioning | 28 million rows migrated without loss, reads of the extraction query divided by 240 |
Storage, costs and operations
| Context | What I did | Result |
|---|---|---|
| Multi-site organization, eight instances (2024) | Migration audit to SQL Server 2022 and consolidation | 8 servers and 35 cores consolidated onto one 24-core Standard server, 66 databases |
| Crypto-asset trading platform (2019 to 2026) | External DBA for seven years, availability group, archiving to PostgreSQL and Parquet | Production migration to AWS RDS in 2024, 1.3 billion rows archived |
| Company with no scheduled backup, SQL Server 2005 (2019) | Emergency intervention: I/O freezes caused by virtual machine snapshots, migration the same day | Production back on its feet, backups in place |
| Department store, point-of-sale system (2022) | NTLMv1 disabled on the tills | Security hardened with no checkout incident |
Audit findings
A few findings from recent audits, before any fix:
- a 4.4 TB data warehouse where one update rewrote 17.5 million rows to change 1,946, and caused 18 % of the 8,143 blocking events of a night;
- a fleet of eight instances with no notification at all, where 11,530 backup failures in eleven days had gone unnoticed;
- a production application where 66 deadlocks were analyzed one by one, with the cause and the fix for each.