How to work with the ApexSQL Log continuous auditing repository directly, including querying and reporting


Performing continuous auditing with ApexSQL Log enables users to seamlessly audit SQL Server databases for all DML and DDL changes that occur on the audited database, directly from the transaction log. The audited data is then stored in the repository tables which can be created in any SQL Server database on any connectible SQL Server instance, and these tables will then be continuously updated with new auditing data.

ApexSQL Log continuous auditing repository topography

When continuous auditing is performed, audited data is stored in one of two sets of repository tables, depending if user is performing general auditing or before-after auditing. In this article we are going to provide information on the structures of these tables.

Critical steps users should perform immediately after they think a disaster has occurred

Even though it seems as the most practical and simple solution, restoring the database after the disaster can be a two-fold step-back. One, it will most likely recover the data and restore the database to the state/time when the backup was created, but all database changes after the backup will be completely lost. And two, restoring the database will prevent recovery processes with third party tools, since the original MDF and LDF files and the information within will be lost once the restore process finishes. In this article, we’ll discuss adequate steps required to be prepared for a successful recovery using 3rd party SQL Server database recovery tools

How to choose between local vs remote SQL Server auditing and recovery

ApexSQL Log is a SQL Server database transaction log reader which allows users insight into SQL Server database transaction log files and backup. ApexSQL Log can be used both locally or remotely in order to perform auditing and recovery jobs. Users can audit database changes and present in a comprehensive grid, where they can be analyzed and inspected in great detail, including who made the change and when, as well as the before-after change values and full history of affected rows regardless of the auditing method (local or remote).

How to choose and perform the most appropriate recovery solution after the data loss

Whenever an accidental or malicious data loss occurs, it is important to take the most efficient approach in order to perform the most appropriate recovery process and recover full range of lost data. Also, it is important to choose the right tool which will provide the highest possible chance for the successful recovery.

This article will provide details on how to ensure that recovery chance is maximized, by taking the correct post-incident steps, understanding the recovery process, and making the right choice between ApexSQL Log and ApexSQL Recover when planning the recovery.