SQL Server DBA

A slow database wears people down: every ERP screen that takes ten seconds is hours lost per month, multiplied by every person in the company. And databases don’t heal on their own — they get worse, because data grows.

The method, out in the open

No secrets about the how: serious tuning always happens in the same order, and I’ll tell you upfront so you know what to expect (or can try it yourself, if you have the skills in-house):

1. Measure the waits — what the server is actually waiting on: disks, CPU, locks, memory. Without this baseline everything is guesswork.
2. The queries — the 10 most expensive ones almost always account for most of the problem.
3. The indexes — the missing ones, the useless ones slowing down writes, the duplicates.
4. The configuration — memory, parallelism, tempdb: SQL Server’s defaults weren’t designed for your workload.

What you buy from me isn’t the recipe — it’s the experience to apply it fast and without stopping production.

What I do

• Performance tuning: slow queries found and optimized, missing or redundant indexes, statistics, execution plans.
• Rescue: locks and deadlocks, corrupted databases, runaway transaction logs, exhausted space, emergency restores.
• Backup and restore: strategies that fit the data (full/differential/log), with documented test restores.
• Preventive maintenance: integrity checks, index rebuilds, growth monitoring.
• Migrations and upgrades: supported versions, instance moves, consolidations.

Numbers before, numbers after

Every intervention starts from numbers — waits, reads, durations — and ends with the same numbers measured again. “It feels faster” becomes a documented comparison (a query going from 2.4 seconds to 38 milliseconds speaks for itself).

Two ways to work together: emergency care when the problem is now, or the periodic check-up that prevents problems — integrity, tested backups, indexes, growth. The second costs far less than the first.