http://sqlblog.com/blogs/tibor_karaszi/archive/2009/11/18/do-you-perform-log-backup-for-the-model-database.aspx

I remembered that once while troubleshooting a disk space issue I saw a model database with a transaction log of 11 GB!

So… I put this article on my useful notes and will always set the model database in simple recovery model as a best practice.

Example:

(On a default installation extractor.exe is located on: %PROGRAM_FILES%\Quest Software\LiteSpeed\SQL Server\ )

extractor.exe -F "Drive:\PATH\DBNAME_Full.bak" -E "Drive:\PATH\DBNAME_Full_native.bak" -N 1

-F the name of the LiteSpeed backup device file to be extracted
-E this is the base file created by the extractor.exe, containing the native SQL Server backup

We have the native SQL Server backup files generated on the specified folder.

Now let’s do the restore:

RESTORE DATABASE DBNAME FROM
DISK = N'Drive:\PATH\DBNAME_Full_native.bak0',
DISK = N'Drive:\PATH\DBNAME_Full_native.bak1'
WITH FILE = 1,
MOVE 'DBNAME' TO 'Drive:\DBLocationPath\DBNAME.mdf',
MOVE 'DBNAME_log' TO 'Drive:\DBLocationPath\DBNAME_log.ldf',
NOUNLOAD, STATS = 10
GO

Done

What we have:
1. A full backup of Adventure Works from 2.00 PM
2. A diffrential backup from 3.00 PM
3. A set of transaction log backups from 4.02 PM, 4.30 PM, 5.00 PM and 5.30 PM

At 3.59 PM we created the table Mytable1
At 4.10 PM – Mytable2
At 4.19 PM – Mytable3
At 4.26 PM – Mytable4
At 4.34 PM – Mytable5
At 4.46 PM – Mytable6
At 5.10 PM – Mytable7

First – restore the full backup and specify the STANDBY option. STANDBY leaves the database in a standby state, in which the database is available for limited read-only access. After a RESTORE WITH STANDBY operation, the undo file is automatically deleted by the next RESTORE operation.

RESTORE DATABASE AdventureWorks
FROM DISK = 'Drive:\folder\MSSQLBackup\Full\AdventureWorks_backup_201001121400.bak'
WITH REPLACE,
STANDBY = 'Drive:\folder\MSSQLBackup\Full\UNDO_AdventureWorks_backup_201001121400.bak',
MOVE 'AdventureWorks_Data' TO 'Drive:\folder\AdventureWorks.mdf',
MOVE 'AdventureWorks_log' TO 'Drive:\folder\AdventureWorks_log.ldf'
GO

Restore the differential backup:

RESTORE DATABASE AdventureWorks
FROM DISK = 'Drive:\folder\MSSQLBackup\Diff\AdventureWorks_backup_201001121500.bak'
WITH REPLACE,
STANDBY = 'Drive:\folder\MSSQLBackup\Diff\UNDO_AdventureWorks_backup_201001121500.bak'
GO

Apply the first transaction log backup from 4.02 PM:

RESTORE LOG AdventureWorks
FROM DISK = 'Drive:\folder\MSSQLBackup\Log\AdventureWorks_backup_201001121602.trn'
WITH REPLACE,
STANDBY = 'Drive:\folder\MSSQLBackup\Log\UNDO_AdventureWorks_backup_201001121602.trn'
GO

Let’s see what we have – we see the table Mytable1 now

Apply the transaction log from 4.30 PM, but I want to have only Mytable1 and Mytable2, so we will stop at 4.15 PM:

RESTORE LOG AdventureWorks
FROM DISK = 'Drive:\folder\MSSQLBackup\Log\AdventureWorks_backup_201001121630.trn'
WITH RECOVERY,
STOPAT = N'2010-01-12 16:15:00.000'

Done!

RECOVERY instructs the restore operation to roll back any uncommitted transactions. After the recovery process, the database is ready for use. If neither NORECOVERY, RECOVERY, nor STANDBY is specified, RECOVERY is the default.

How to view the format of the date:

SELECT CURRENT_TIMESTAMP
GO

or

SELECT GETDATE()
GO

I liked this article. Especially this:

“After doing an emergency-mode repair, transactions that were active at the time the log was damaged will not get a chance to roll-back, most likely. In this case, I know what was going on when the crash occured, but what about on a busy OLTP system with hundreds or thousands of active transactions? What state will the data be in?”

“Yes, you can recover from a detached suspect database, but it’s not pretty and you have to be very careful. The best course of action is always to have a comprehensive backup strategy that allows you to restore as quickly as possible. If you do have a suspect database and no backups, use EMERGENCY mode to access and/or repair the database. Hopefully this article will help people that find themselves in these situations.”

SELECT database_id, command, percent_complete from sys.dm_exec_requests WHERE session_id = spid

sys.dm_exec_requests – returns one row for each request executing within SQL Server
database_id – ID of the database the request is running under
command – identifies the type of command that is being processed
percent_complete – Percent of work completed for certain operations, rollbacks included.
This does not provide progress data for queries.

Source: MSDN sys.dm_exec_requests