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