On this page
SQL Server Audit records events: who logged in, who changed a permission, who read a table. A SQL Server health check reviews state: whether backups restore, whether CHECKDB passes, whether the settings are sound and where the version stands. The audit proves what happened. It does not tell you whether the instance is in a condition you can trust. Searches for "sql server audit" mix the two, so this post separates them. AceMQ's SQL Server health check is the review side; the audit is a feature of the engine.
The facts below come from the Microsoft Learn pages for SQL Server Audit, RESTORE VERIFYONLY and DATABASEPROPERTYEX, read on 4 November 2026.
What SQL Server Audit records
SQL Server auditing means tracking and logging events that occur in the Database Engine, for a whole SQL Server instance or for one database. An audit is built from three objects. A server audit sets the destination. A server audit specification collects server-level audit action groups, which are predefined groups of events such as logins and role changes. A database audit specification collects database-level actions, such as a SELECT or UPDATE on a table. An audit is created disabled and records nothing until someone enables it.
Output goes to a file, the Windows Security log or the Windows Application log. Server-level audits work in every edition. Database-level audits work in every edition from SQL Server 2016 SP1; before that they were limited to Enterprise, Developer and Evaluation editions. You read the result with the Windows Event Viewer, the Log File Viewer, or the fn_get_audit_file function, and sys.dm_server_audit_status shows whether an audit is running.
What an audit cannot tell you
An audit is a log of actions. Everything about the condition of the instance is outside it:
- Whether a backup restores. Nothing in the audit touches backups. Even
RESTORE VERIFYONLYonly checks that the backup set is complete and readable; Microsoft says it does not verify the structure of the data inside it. Only a restore proves a restore. - Whether the data is intact. That is
DBCC CHECKDB.DATABASEPROPERTYEXreturns the time of the last successful run, and 1900-01-01 if there has never been one. The property applies from SQL Server 2016 SP2 and 2017 CU9. - Whether the settings suit the hardware, what the instance waits on, or which patch level it runs. None of these is an auditable action.
- Whether the audit itself can be trusted. Microsoft cautions that members of the sysadmin role can tamper with any audit component and db_owner members can tamper with database audit specifications. tempdb and temporary tables are not audited, and the Application log, which any authenticated user can write to, is less secure than the Security log.
An audit also has operating costs. The target must be reviewed and archived so it does not fill. If an audit fails to initialise, the server does not start until it is started with the -f option, and an audit set to shut the server down on failure can stop it.
What a health check reads
A health check reads the instance's own metadata, statistics and history, and writes down what is wrong, ranked by production risk. It changes nothing on the instance. The table puts the two side by side.
| Question | SQL Server Audit | Health check |
|---|---|---|
| Who changed a login or a permission? | Yes, if that action group is audited | Reads who holds sysadmin now, not who gave it |
| Do the backups restore? | No | Yes: msdb backup history and one timed test restore |
| When did CHECKDB last pass? | No | Yes, per database |
| Are the settings sound? | No | Yes: values against defaults and the hardware |
| Is the version supported? | No | Yes: build against Microsoft's lifecycle dates |
| Does it show activity over time? | Yes | No: a point-in-time report |
| What does it add to the instance? | A target to review and archive | Nothing: the capture is read-only |
Where the two meet
A health check's security section looks at the audit as one more thing to verify: that an audit exists for what you need to prove, that it is enabled, where it writes, and who can read the files. Microsoft recommends generating audit reports from a separate instance that only audit administrators can reach, so the record is not kept on the server it describes.
That is the practical line. Keep the evidence of activity off the instance, and use a review to check that the instance behind it is sound.
Which one you need
- Use the audit when the question is about activity: who accessed or changed what, for a regulator, a customer or an investigation.
- Use a health check when the question is about condition: after a DBA leaves, before a customer questionnaire, or before you decide what to do with SQL Server 2016, whose extended support ended on 14 July 2026. The dates are in SQL Server 2016 end of life.
- Use both when an auditor asks for evidence of activity and of controls. Tuning a slow workload is a separate job, covered under SQL Server consulting.
Sources
Frequently Asked Questions
Which SQL Server Audit target is the most secure?
Microsoft says any authenticated user can read and write the Windows Application log, so it is less secure than the Windows Security log. Writing to the Security log needs the service account in the Generate security audits policy. A file target lets you set tighter permissions on the folder.
Does SQL Server Audit work on Standard Edition?
Yes for server-level audits, which work in every edition. Database-level audits work in every edition from SQL Server 2016 SP1; earlier versions limited them to Enterprise, Developer and Evaluation.
Can an audit prove my backups work?
No. An audit records actions and says nothing about backups. RESTORE VERIFYONLY checks that a backup set is readable but not the structure of its data. A test restore is the proof.
Author
Talk to an engineer
Need a hand with SQL Server?
Senior engineers who run it in production. Get a quote or a free consultation, no sales pitch.
