Lumigent Technologies has released a new version of Log Explorer, one of the best-selling third-party products in the SQL Server space. Log Explorer reads a SQL Server 2000 or 7.0 transaction log and decodes the information into a readable format. Log Explorer lets you analyze transaction histories, but most important, it lets you selectively recover data. The newest release, Log Explorer 3.03, adds multiple enhancements to this valuable capability.
Selective Data Recovery
You can use SQL Server's own utilities for data recovery by restoring a transaction log to a point in time just before a data loss or corruption occurred—the last point when the data was correct. This capability is useful if you've lost data through an erroneous operation or transaction in the database. However, only one user can be in the database during the restore, so you must effectively take the database out of production while you perform the restore operation. When you use SQL Server's backup and restore facilities, you can't select just the transactions that you want to undo or redo. When you restore a log to the desired point in time, you also recover the database, and you can't restore the remaining correct transactions that come after that point in time.
Log Explorer enhances SQL Server recovery by letting you selectively recover data from a transaction log. You can browse a database's transaction logs, locate the bad operations or transactions, and generate a script to undo just those transactions. Depending on the context, you might not have to take the database out of production. If you use SQL Server to restore a database to a certain point in time, you can use Log Explorer to attach to the transactions that occurred after that point. Then, you can generate redo scripts to recover selected transactions that occurred after the failure.
Log Explorer 3.03 Enhancements
Log Explorer 3.0 builds on the important capability of performing selective recovery from transaction logs. I reviewed Log Explorer 3.03, which includes bug fixes for the 3.0 release. Let's look at the major enhancements in this latest release.
View DDL commands. Log Explorer 3.03 lets you browse data definition language (DDL) events, which it reconstructs by reading the transaction-log activity against a database's system tables. The View DDL Commands window, which Figure 1 shows, reveals changes to permissions and to system objects such as tables, views, functions, stored procedures, triggers, and indexes. You can also filter the DDL display to view only the commands you want to see.
Recover logged transactions containing BLOB data. Another enhancement is better support for binary large object (BLOB) data stored in text, ntext, and image data types. Log Explorer now supports all fully logged changes to the text and image columns. According to the Log Explorer 3.03 Release Notes, SQL Server doesn't always record BLOB data in the transaction log. For example, SQL Server doesn't log a delete of a row that results in freeing a text or image page (if the row was the only row on a physical page), nor does it log an update to a BLOB column. Because these operations aren't recorded in the transaction log, Log Explorer can't create scripts to recover them.
Recreate the schema of a dropped or truncated table. Log Explorer 3.03 can reconstruct the schema for a dropped table and insert it into the script that the Salvage Dropped/Truncated Table option generates. Earlier releases require you to manually recreate the table before applying the script.
Index filtered transaction-log records for faster browsing. When you're working with large transaction logs, especially logs that span many files, Log Explorer might have to scan data sequentially to find a particular transaction. You can direct Log Explorer to build an in-memory client-side index of your filtered result set on the transaction's log sequence number (LSN). This index exists only for the duration of the Log Explorer session and only in the Log Explorer client utility's memory space.
Log Windows-authenticated usernames. Because SQL Server writes only SQL Server—authenticated login names to a transaction log, earlier Log Explorer releases couldn't capture the Windows-authenticated username associated with a transaction. Log Explorer now displays the Windows NT 4.0 username with a transaction's data when you're browsing a log. Log Explorer 3.03 communicates with the SQL Trace API to capture the NT username of a server process ID (SPID), then stores it in a table called LUMIGENT_PROFILER. By default, this table is in the msdb database, but you can choose a different location at installation time. Log Explorer automatically purges rows from this table that are older than a specified number of days (the default is 30 days). You can configure this value by using the Server Manager utility, which I describe next.
Prev. page
[1]
2
next page 
