Instead of restoring the database and having to listen to users scream about it being offline and also having to redo work that you can't get back due to the point in time recovery required to fix these problems, you really just wanted to be able to open the transaction log and extract the information needed to fix the problem.  After all, the transaction log is supposed to log these very same transactions that forced your restore.  You're the DBA.  You're the one that is responsible for keeping the databases online.  Why can't it be left up to you to determine the best solution for fixing the data and also leaving the database online?  What happens if you can't take the database offline or restore it to another server?  Are you really going to tell the CEO that the $50 million contract that just got lost is gone forever, because you can't take down your database that is processing 100s or 1000s of transactions per minute to get that contract back and risk losing other business?  Are you really going to explain to the CEO that you have to buy 6TB of disk storage immediately in order to restore that stock trade that was lost as the SEC is looking over your books?

It is scenarios like these that happen everyday.  It is scenarios like these that SQL Server falls short on.  The competing DBMSes on the market have the ability to perform the operations outlined above without taking the database offline.  It is for just these scenarios that companies install massive amounts of failover/fallback/standby servers or choose a DBMS other than SQL Server.

The biggest challenge with SQL Server 6.5 was keeping it running.  It would crash.  It would corrupt.  Crashes and database corruption were a fact of life for DBAs.  It was because of the crashes and corruption that you needed to restore databases, did not meet uptime requirements, and potentially lost data that could not be recovered past the point of failure.  With the introduction of SQL Server 7.0, most DBAs didn't know what to do.  Many struggled with learning new skills and spending much more time doing the important things like creating applications to solve business needs.  Why?  After a couple of years working with them, I can say that SQL Server 7.0 databases do not crash and do not corrupt.  They will run and stay online.  Install the SQL Server, create the databases, and walk away.  When you come back, they will still be there.

The biggest reason for needing to restore databases has shifted from database damage to user error.  What if you could nearly eliminate the need to restore because data got "accidentally" changed/deleted?

Log Explorer from Lumigent Technologies is the only product on the market at the time of writing that provides this capability.  Using Log Explorer, you can perform online "recovery" that is currently impossible.

If you have a critical database where activity has to be tracked, then you have most likely purchased a solution that provides audit capabilities or you have created your own.  However, everything that was successfully executed against your database is contained in your transaction logs.  Instead of having to purchase/build auditing, you can simply hook Log Explorer up to your transaction logs and get a full audit of every action that was taken against your data.

Log Explorer 1.2.1 1 2 3 4 5 6 7 8 9 10