Applies to
ApexSQL Log
Summary
This article envelops all of the most important topics and knowledge about ApexSQL Log and provides brief descriptions and links to core ApexSQL Log articles that cover them.
Description
The first choice every ApexSQL Log user is faced with is a choice between the installation of ApexSQL Log directly on the production server vs. the installation on a personal workstation. In the latter case, when ApexSQL Log is installed on the workstation, and SQL server is accessed remotely, it is required to install ApexSQL Log’s server-side components on the SQL server, which enables ApexSQL Log to read transaction log files belonging to SQL server databases.
In the article ApexSQL Log: Which installation method is right for you we offer advice to help ApexSQL Log users decide which installation type is the best for their environment.
Additionally, the article What does ApexSQL Log install on my server offers detailed description of all ApexSQL components installed in both installation choices.
In order to perform a data recovery, transaction rollback or database auditing, ApexSQL Log requires a full chain of transaction log backups. A transaction log chain is a continuous sequence of transaction log backups. It starts with a full database backup followed by subsequent log backups up until the recovery/auditing point. In the article How to create and maintain a full chain of transaction log backups we explain transaction log chains in details and offer an advice on ‘when’ and ‘how’ to create transaction log backups.
Another important requirement of ApexSQL Log is the database recovery model. ApexSQL Log automatically detects recovery mode of a database and issue a warning if a database is not in a full recovery mode. A full description and a solution for the situation when a database recovery model is insufficient can be found in ApexSQL Log shows the “Unknown recovery model” message article.
For the purpose of a full and comprehensive evaluation that will showcase the full range of ApexSQL Log’s features, we’ve created a demonstration database script, ApexSQLDEMO.sql which is available for download and described in details in the article A script for creating a great test database to evaluate the full functionality of ApexSQL Log.
The most valuable functionality of ApexSQL Log, in addition to transaction log reading, is the ability to create a rollback or reconstruction scripts for any transaction recorded in the transaction log. The user can choose one of the several available methods to create an undo or redo script directly from the main grid, or to create a batch file that can be executed later without utilizing the ApexSQL Log GUI. We’ve described these methods in the How to create an undo/redo script in ApexSQL Log article.
Another main feature of ApexSQL Log is ability to display and export transaction log details in a human-readable format. The results can be displayed directly in the application GUI, and additionally exported to various formats. These results include operation details (field name, type, value, object, LSN…), and transaction information (begin time, state, operation, description…) which can be exported into several different file formats – XML, CSV, SQL script, SQL BULK, HTML. The exporting process is described in more details in the Exporting options in ApexSQL Log article.
It is not uncommon to work with very large transaction log files and/or backups. In these situations, it is helpful to use filtering options in ApexSQL Log in order to get the details faster. Depending on the needs, filters can reduce the time needed for reading the data sources, or simply narrow down the displayed results for easier comprehension. Starting with basic filters like Time/Date range filter and Operation filter, to more sophisticated filters like Field values or the Server process ID filters, all are described in detail in the Advanced filtering options in ApexSQL Log article.
Aside from performing tasks via the ApexSQL Log GUI, it is possible to utilize the command line interface (CLI). All supported CLI switches as well as few standard examples are described in the ApexSQL Log CLI support article.
The biggest advantage of the CLI is the fact that it offers possibility to automate and schedule transaction reading tasks. This can be achieved by utilizing an SQL server Job that will rely on the batch file created by ApexSQL Log which contains CLI statement. Full step-by-step solution is explained in the article Automating daily transaction log reading.
During the work with ApexSQL Log, it is possible that the user will encounter cases when they get insufficient auditing results returned. This may happen due to various reasons, including unfulfilled requirements/permissions, and the solution is described in the article What should I do if ApexSQL Log returns fewer transactions than I expected.
Sometimes, it is required to audit operations for dropped or re-created tables. When these tables are re-created, they receive specific ID, which is different than the ID they’ve had in the past. It is still possible to audit these operations by utilizing the Old tables ID mapping feature described in the article How to audit operations for dropped or re-created tables with Old Table ID mapping.
Last, but not least, there are always tricks of the trade that can enhance ones experience and productivity while performing a task, and the most valuable ones are presented in the ApexSQL Log– tips n’ tricks article.
