I'm sure just about everyone has had a user call trying to recover a single row of data that was accidentally changed or deleted.  The only way you could restore that data was to restore a backup of the database to another server, extract the row, and move it back over to the production server.  With the Log Analyzer, all you simply do is reverse engineer the transaction log to perform an opposite transaction.

Even though this is a very powerful tool and I'd recommend getting it for your environment, it is a very cumbersome tool to use.  You are required in most cases to manually enter the page number.  It will then generate a file that you have to bring into some other tool to execute.  It already has a connection to the database.   It would take about 15 minutes for someone to add in a screen to execute a SQL statement.  The entire interface can stand some pretty significant improvements to make this tool much more powerful and easy to use.  Power is one thing that you can see across Platinum's toolset.  Ease of use is one thing that is very lacking in most Platinum tools.  I submitted a list of ten improvements I would make to the Log Analyzer to make it a much more robust, powerful, and easy to use tool.  It remains to be seen whether any of those recommendations are listened to.

For the purpose of this review, I used the pubs database with a couple of dummy transactions.  As you have come to expect from most of my reviews, I try to show you many screen shots so the load times make be a little slow.  I do this, because choosing a good screen of information for illustration tells you much more than me babbling on and trying to describe a feature.

When you first start the Log Analyzer you will be presented with the familiar dialog box below to log into a server and set the current database context:

Once you have successfully logged in, you are ready for your first ever view of the transaction log as shown below. 

It will default to a view of the entire transaction log where you can see everything that has occured.  The vast majority of the information in the transaction log will not be useful.  This will be things like allocation of new extents, checkpoints, oam pages, and many other internal housekeeping operations.  What you are looking at in this screen is very simple, but very powerful.  The column on the far left is simply a row counter that is generated by the Log Analyzer.  The next column contains the page and row number of the transaction log entry.  This is formed as follows: (page,row).  The third column details the type of transaction.  The fourth column tells you which object the transaction was performed on.  The fifth column gives you the time of the transaction log entry.  The sixth column (not shown) will tell you whether the transaction is committed or not.  The last column (not shown) gives miscellaneous information about the transaction such as spid, uid, and suid.

Log Analyzer 2.02 1 2 3 4 5 6