ApexSQL Audit fault tolerant auditing – part II

In the previous article we have described how ApexSQL Audit resolves several scenarios to maintain auditing continuity as the SQL Server auditing solution must be reliable as a solution you can trust. Here are the other situations which can lead to auditing breakdowns

Connection to SQL Server is lost

If ApexSQL Audit on the central or distributed instance loses connection to the SQL Server instance, auditing will not be affected and there will be no loss. Once started, capturing the events into SQL traces is completely independent of ApexSQL Audit

When the connection between the SQL Server instance and ApexSQL Audit on the central instance is lost, there will be a delay in inserting the audited records into the central repository database. These records will be inserted as soon as the connection is reestablished

ApexSQL Audit crashes

If ApexSQL Audit service stops, crashes, or becomes unresponsive it will automatically restart. The restart attempts will be continually repeated until the restart succeeds

But even if ApexSQL Audit is not running on a distributed instance, the SQL traces will continue with the normal activity, so auditing will not be interrupted. When ApexSQL Audit is running again, it will check the last used SQL trace and continue using it or create a new one

The same as with an ApexSQL Audit crash on a distributed instance, if ApexSQL Audit crashes on a central instance, the only delay that happens is with SQL trace transfer and processing on the central instance

Other scenarios

ApexSQL Audit successfully handles another potential problem – when there are problems with processing SQL traces. If for any reason, a SQL trace cannot be successfully processed and audited data cannot be inserted into the central repository database these files will be stored in a quarantine folder and ApexSQL Audit will periodically try to reprocess them

ApexSQL Audit is designed to provide maximum fault tolerance and minimal auditing and audited data loss when it comes to unexpected situations in a wide variety of scenarios

See also:

ApexSQL Audit fault tolerant auditing – part I