Step 1: Executing a dangerous query on our database

We'll start this walk-through by viewing a database and executing a damaging transaction on it. By re-running the original query, we can see that our data has been permanently deleted.
Server:Msg 208, Level16, State 1, Line 1 Invalid object name 'socceradmin.players'.

We now want to go ahead and rescue our data.

To rescue this data, we will start a new recovery project in SQL Log Rescue. We could, however, have chosen to open or edit an existing project.

We now need to choose the database we would like to investigate. SQL Log Rescue can access databases on any server you have permission to access. In this case, we're going to look at the database WidgetSoccer.

SQL Log Rescue then automatically finds the backup files and log files needed to investigate our database.

SQL Log Rescue will then supply any warnings about the backup and log files. In this case, SQL Log Rescue found no problems, so it will begin its detailed analysis of live log and backup files when you press Finish.

Next, the main transaction viewing window is displayed. The top half of the screen is a grid for grouping and sorting the operations, and the bottom half shows the details of these transactions. The grid in the top half of the screen helps you understand what has happened in the potentially huge number of transactions occurring on your database.

The box at the top left of the screen can be used to search, and you can sort and filter using the tabs at the top of each column. By dragging and dropping a column header, you can group by that column. Using these facilities, we can clearly identify what has happened.

In this case, by grouping by transaction type, we can see a table drop, clearly the cause of our problem. In the absence of SQL Log Rescue, this would be very serious. Now that we've identified our problem transaction, we can move on to rescuing this data by undoing the table drop. We select this transaction only, and run our Undo Operations wizard.

We are first presented with a summary of what the script will do.

By clicking the Warnings tab, we can see that SQL Log Rescue has identified a number of warnings, has ranked them in order of importance, and has suggested what to do in each case, to minimize risk.

By clicking the SQL Script tab, we can inspect the properly formatted, transaction-based script, which SQL Log Rescue instantly produces. In this case, with a dropped table, SQL Log Rescue has gone back to the latest backup, and has worked out what was deleted and what transactions have been made since that backup, in order to recreate the table exactly as it was.

Next, we choose whether to run the script directly from SQL Log Rescue or to edit it in SQL Query Analyzer. We choose to run the script now.

We immediately see that the transaction log has been updated.

By going back to Query Analyzer, we will be able to check that our dropped table has been recovered. We can see that the data has returned intact and that it is exactly as it should be. Having the power to do this on a damaged, or otherwise corrupted, database provides an extremely valuable resource to any company. Whether you look at it in terms of time saved, money saved, customer good-will retained, or simply insurance against the inevitable, the return on investment in using SQL Log Rescue is indisputable.