For very large Microsoft SQL Server databases, a complete restore operation can take many hours. During this time the database cannot be used to prevent data being entered and lost as information is copied back from tape or disk. Obviously in a high-availability environment any downtime is costly, so keeping it to a minimum is essential.
Fortunately page level restore techniques can be used to keep recovery times to a minimum by reducing the amount of data that needs to copied back from the backup media. Since the release of Microsoft SQL Server 2005, DBAs have had the option of carrying out a ‘page level restore’ which allows them to recover a ‘handful’ of pages, rather than having to restore entire datasets and copy information back into the original database.
The page level restore operation is perfect for situations where data becomes corrupted during writes through a faulty disk controller, misconfigured antivirus software or an IO subsystem. Better still, restore level operations can be performed online for Enterprise editions of Microsoft SQL Server.
As with any database recovery operation, page level restores are reliant on having a complete backup from which to work. If such a backup is not available, you will need to investigate an alternative method of recovering data from the server disks direct, like Ontrack PowerControls for SQL Server.
And although you can carry out the page level restore with the database online, you may decide to keep things safe by switching to single user mode whilst you transfer data using:
ALTER DATABASE <DBName> SET SINGLE_USER
WITH ROLLBACK AFTER 10 SECONDS
This command ensures that everyone is out of the system and cannot enter until you change the mode back again. You will also want to ensure that you have the end of the log file backed up so that you have all transactions fully accounted for and to prevent any further data loss:
BACKUP LOG DBName
TO DISK = N'X:\SQLBackups\DBName_TailEnd.trn'
Discovering which pages are corrupt
Usually the first sign that something is wrong will be an inconsistency error generated when a select statement is executed. The Microsoft SQL Server Messages pane will show an error like:
Msg 5242, Level 22, State 1, Line 1
An inconsistency was detected during an internal operation in database ‘DBName’(ID:9) on page (1:254).
Please contact technical support. Reference number 4.
As you would expect, the page number referenced, 254, is the corrupt page that needs to be recovered.
Carrying out a page level SQL Server recovery
The Microsoft SQL Server page recovery operation is very similar to that of a full recovery, the only difference being the use of the NORECOVERY command:
RESTORE DATABASE DBName
PAGE = 'fileid:pageid' -- e.g. 1:254
FROM DISK = 'X:\SQLBackups\DBName_lastFull.BAK'
This will the re-insert the corrupted page from backup without going through the time-consuming process of a full SQL Server recovery. You can recover more than one page at a time simply by appending additional fileid:pageid combinations separated by commas.
You can test that the data has been recovered successfully by running DBCC CHECKDB on the affected database – it should complete without error.
Finishing up the page level SQL Server recovery
Although the corrupt page has been recovered successfully, you will also need to apply the transaction logs to ensure that all data is present and correct. For each transaction log generated since your last full backup, run the RESTORE LOG command:
RESTORE LOG DBName
FROM DISK = 'X:\SQLBackups\DBName_LogFileFrom2PM.TRN'
RESTORE LOG DBName
FROM DISK = 'X:\SQLBackups\DBName_LogFileFrom215PM.TRN'
Again, note the NORECOVERY option will ensure that you restore nothing but the specified log files. Finally you need to apply the tail log backup taken in the Prerequisites section above:
RESTORE LOG DBName
FROM DISK = 'X:\SQLBackups\DBName_TailEnd.trn
This time you do want to recover the database, hence the WITH RECOVERY command.
At this point you can re-test the database to ensure that everything is working as it should. Once you are satisfied, switch the database back to multi-user mode to restore access for your users:
ALTER DATABASE AdventureWorks SET MULTI_USER
And there you have it, corruption problems resolved without having to undergo a full SQL Server recovery. The page level restore option ensures that downtime and user inconvenience is kept to a minimum, as are the costs associated with a database outage.