|
|
|
|
|
Log Explorer 1.2.1 1 2 3 4 5 6 7 8 9 10 Prior to Lumigent's Log Explorer, I had used a product from Platinum Technologies called Log Analyzer. This product provided same capabilities against SQL Server 6.5 servers. That product paid for itself several times over in some very specific cases. The first few times I used it was in a disaster recovery situation. One company had lost some data due to an incorrectly written procedure and the backups had not been completing successfully. This left them without any way to recover that data. However, the FDA required all data to be tracked for the medical testing that was being performed and the loss of that data could have the potential to shut the project down if an audit found it missing. Using Log Analyzer, I was able to go into the transaction log and restore the delete data which would have been impossible another way. In another case, a client had data that was "disappearing" in their databases. The vendor insisted that it was SQL Server's and my fault that data kept getting lost, because we didn't enable certain server settings. Using Log Analyzer, I was able to go into the transaction log and retrieve the proof that it was an improperly formed transaction that caused the problem. What was occurring was that a memo column was being stored in several fixed width rows of data. The application did the following: begin transaction, delete data, commit transaction, begin transaction, insert the changed data, commit transaction. This meant that if the delete succeeded and the insert failed, the data would be gone. If the delete failed, the insert would get blown out with a primary key violation. Due to the way this application was written, there was no way to detect that until we looked through the transaction log and proved the bad transaction handling on the vendor's part.While these are scenarios where I used Log Analyzer, Log Explorer provides the same capabilities against SQL Server 7.0 and soon SQL Server 2000 databases. This is a capability that should not be underestimated and a capability that many of us in the SQL Server community have been asking for since SQL Server 7.0 was released. It is finally here and should prompt a very close look by anyone running their business on SQL Server 7.0. The first step to working with your databases is to connect to a SQL Server, specify a database name, and select whether you want to use the online transaction log or a backup. Even if you are selecting a backup file, you still need to connect to a server and database. The transaction log contains all of the information about the data that was modified, but it doesn't contain all of the schema information that is necessary. By connecting to a server and database, you can put the contents of the transaction log into perspective with the schema in that database.
|
All content on this site, except where noted, represents an original work of Michael R. Hotek and is protected by applicable copyright laws. The SQL Server FAQ is the sole work of Neil Pike. No page, portion of a page, or download may be used for commercial purposes in whole or in part without the express, written permission of the applicable author.
