Why audit your SQL Server instances?
Most SQL Server instances are installed with the default settings and never reviewed again. Databases grow, applications change, teams turn over, and technical debt quietly piles up until the day a batch job stops finishing, a restore fails or an auditor asks an awkward question.
A SQL Server audit is especially useful:
- when users complain about slowness and nobody knows why
- after your DBA leaves, to find out what you've inherited
- before a migration or version upgrade, so you start from a known state
- after an incident, to keep it from happening again
- before a security audit, a certification or a due diligence review
What the audit covers
Instance configuration
Max server memory, parallelism (MAXDOP and cost threshold for parallelism), tempdb configuration, database options (auto-shrink, auto-close, page verify), compatibility levels, operating system and storage settings. These are simple settings, but a single bad choice can cost you a significant share of your performance.
Backups and restore capability
Actual coverage of full, differential and log backups against each database's recovery model, maximum data loss if something goes wrong (RPO), off-site copies, DBCC CHECKDB integrity checks. We look at what would really happen if you had to restore tomorrow.
Performance
Wait statistics, the most expensive queries by CPU, reads and duration, Query Store status, missing, unused or duplicate indexes, stale statistics, blocking. The goal is to pinpoint the handful of causes behind most of the workload.
Security
Members of the sysadmin role, status of the sa account, SQL logins without a password policy, risky features left enabled (xp_cmdshell, OLE Automation), data and backup encryption, missing security patches.
Lifecycle and licensing
Version and cumulative update level against Microsoft's support timeline, exposure to Extended Security Updates (ESU), Enterprise features actually in use and core count sizing. This is often where the quickest savings are found.
High availability
If you use Always On availability groups, log shipping or a failover cluster, we check synchronization health, jobs and logins on the secondary replicas, and whether the setup matches your recovery objectives. See also our page on high availability and disaster recovery.
How the audit works
- Free 30-minute scoping call. Context, symptoms, scope, access constraints. You then receive a fixed-price proposal.
- Data collection. A read-only T-SQL (Transact-SQL) script, run by you or by us. It reads only technical metadata, never the contents of your tables.
- Analysis. Our AutoDBA diagnostic engine screens the results against its 41 rules, then a senior DBA checks each finding by hand, puts it in context and fills in what the rules miss.
- Review meeting. A one-hour video call with your team to walk through the report, answer questions and agree on priorities.
What you receive
- a one-page executive summary, with a health score for each instance
- findings ranked by severity, each one explained in plain English
- T-SQL fix scripts, commented and ready for your review
- a 30-, 60- and 90-day roadmap
- the supporting evidence (queries, measurements) so your team can verify every point
What happens after the audit?
That's up to you. Some teams apply the recommendations themselves using the scripts we provide. Others hand the implementation over to us, or bring us in for a performance tuning engagement. And when there is no in-house DBA, the audit becomes the starting point for our remote DBA services.
