Database Reference
In-Depth Information
4. To check and validate the configuration, check the sys.server_audits
catalog view:
SELECT audit_id,
type_desc, on_failure_desc,
queue_delay, is_state_enabled
FROM sys.server_audits
The result should be as follows:
audit_id type_desc on_failure_desc queue_delay is_
state_enabled
----------- ------------------------------------------------------
------ ----------------------------------------------
65537 FILE CONTINUE
1500
0
5.
The columns from sys.server_audits represent the value for audit_it ,
type_desc , on_failure_desc , and queue_delay , which were supplied during
the CREATE SERVER AUDIT command. The two values are zero (disabled) or one
(enabled). The is_state_enabled column's default value shows 0, which means
the object is created in a disabled state.
The reason for leaving the Server Audit object in a disabled state is to
create an associated Server and Database audit specification in the
audit process.
The audit destination is important and the disabled state of audit does
not automatically audit any actions. It is essential for us to enable where
the audit destination captures the required data from the audit.
6. The next step is to create the server audit specification using the CREATE SERVER
AUDIT SPECIFICATION command.
7.
Next, it is essential to obtain audit action groups on the server scope using the sys.
dm_audit_actions system catalog, which returns an abridged result related to
server-scoped actions. Let us query the information using the following TSQL:
SELECT name
FROM sys.dm_audit_actions
WHERE class_desc = 'SERVER' AND
configuration_level = 'Group'
ORDER BY name
The several levels of auditing involve server audit action groups per
instance and either database audit action groups or database audit actions
per database. The class_desc value can be any one of the SERVER ,
DATABASE , or SCHEMA scope objects, but does not include Schema objects.
 
Search WWH ::




Custom Search