This is also a very powerful diagnostic tool as well.  I've been in several situations where applications were causing data problems.  Everyone always wants to point fingers at each other.  It's always someone else's fault.  The application is correct, it's a database issue.  When you can open up the transaction log and show someone exactly what was executed against the backend, you can't argue with the facts.  In one instance, data was disappearing from the database.  The vendor claimed that it couldn't possibly happen with their application, so it must be a database issue and Microsoft was doing something to lose data.  (This was from a Microsoft Solution Provider by the way.)  The last time I checked, SQL Server didn't simply lose data randomly.  When I opened the transaction log we found something very interesting.  The user was dealing with a notes field on their screen.  The notes were stored in a varchar(48) column, split on a 48 character boundary, and chained together across multiple rows in the database.  That by itself is poor design, but not the problem.  The problem was the way the application was managing the data.  (Big surprise!)  On an update, the application started a transaction, deleted all of the rows for that memo, committed the transaction, started another transaction, wrote a row, committed, started another transaction, wrote a row, committed the transaction, etc. until the entire memo was written.  No error handling or checking.  This meant that if a user aborted the application at any point during this process or if errors occurred to abort the process, you would be perfectly consistent data as far as SQL Server was concerned due to the transaction boundaries.  But, the data would be invalid from an application perspective.  The vendor continued to argue about this until we took a screen shot showing the Transaction IDs, Log Sequence numbers, and the transactions being issued.  We also sent them the offending transaction log and told them exactly where in the log the offending entries could be found.  I'm not sure if the vendor ever fixed the problem as I was off that project before a fix came through.  But we certainly "left egg on their face" because they were counting on someone not having the tools or knowledge to expose and prove the fact that their application wasn't doing things correctly.

You can apply the same analysis principles with Log Explorer to isolate and document incorrect transaction or data handling by your applications in order to fix them.

Selecting the Real-time Monitor will display the grid below.  The monitor still obeys the filtering rules you have set up so it will not display transaction that fall outside of that filter.  What the Real-time Monitor does is displays the live transaction log in near real-time so you can see what is happening on your system right now instead of what occurred in the past.  The monitor has a set refresh rate and will refresh the view every few seconds to keep you current.

Log Explorer 2.0 1 2 3 4 5 6 7 8 9 10 11 12 13