Recovering individual tables

Prev Page Next Page
Recovery models
Main backup types
Backing up the database files by copying
The transaction log
Transaction log restore sequence
Log sequence numbers
Truncating and shrinking the transaction log
Backing up the tail
Inside the transaction log
So, what's in a backup file?
Test: A full backup does not contain deleted data
Verifying backup files
Verifying backup files on a budget
Cumulative backups
Recovering individual tables
Backup and restore history details
Backup reads and writes
Speeding up backups
Backup speed details
Speeding up restores
Restore state affects speed too
Backup and restore rights
Log shipping
Log shipping in SQL Server 2000
Setting up log shipping using Enterprise Manager
Checking the set up
Log shipping in SQL Server 2005
Setting up log shipping using Management Studio
Checking the set up
Log shipping status report
Log shipping in SQL Backup
Using the CopyTool utility
3rd party backup applications
VDI versions
VDI errors
SQL Backup - beyond compression
Restoring a chain of transaction log backups
Restoring to the latest possible state
Backing up multiple databases
Backup retention
Making a copy of the backup file
Backup file naming conventions
Restoring the latest backup set
Network resilience
Integrated database verification
Database file relocation
Improved backup retention
High-availability group support
Common SQL Backup issues
Installation checklist
Setting up rights
Configuring service rights
Backup data
Hanging issues
Common backup and restore errors
Error 3201 - when performing a backup to a network share
Full database backup file is larger than database size
Error 3205 - Too many backup devices specified for backup or restore
Error 4305 - an earlier transaction log backup is required
Bringing a database that is in recovery or read-only mode online
Using bulk-logged recovery model but transaction log backup is still large
Error 14274 - unable to delete SQL Server Agent job
Error messages when restoring from different versions of SQL Server.
vdi error codes
Restore speed details
Help, my transaction log file is huge!
Mirror or log ship

Wouldn't it be nice to be able to recover individual tables from a backup file?  So say you have a backup of the AdventureWorks database, and you only want to restore the Vendor table.  Unfortunately, this isn't supported natively by SQL Server.  You will need to rely on various third party tools to perform such tasks.

The applications that usually offer this feature are the third-party backup applications for SQL Server.  They allow you to extract or script out individual tables from the backup files that are created.

However, there is one caveat.  There is the possibility that the data you selectively restore, may be different from the data you would have obtained if you had performed a full database restore.  The reason is because when you perform a full database backup, the resulting backup file contains a backup of both the data files and the transaction log files.  There may be transactions that have been committed, that have not been written to the data file.  In these cases, they are stored only in the transaction log, or stored partially in the data file.  When the third-party application restores the selected tables, they only retrieve the data from the data file stored in the backup.  The newer data in the transaction log is ignored.

   Backup sequence with no checkpoints during backup   


How about transactions that have not been written to the data file before the backup started?  This is not an issue, as SQL Server automatically performs a checkpoint when the backup is started.  The dirty data pages would have been flushed out to disk during the checkpoint.  So can we say that when we restore individual tables from a backup file, we are recovering the data as at the beginning of the backup?  It depends.  If there were no transactions running during the backup, yes.  Or if there were transactions running but no checkpoints occurred, yes.  If however there were transactions performed during the backup, the data we recover may include data at the beginning of the backup, and data that were committed during the backup IF checkpoints occurred during the backup AND the data was written to pages that were not yet backed up yet at the time the checkpoint occurred.

   Backup sequence with checkpoints   


That's something to keep in mind when relying on table level recovery.  A full backup contains all data and changes made to the database up to the time the backup ended.  The data files alone do not reflect the state of the database at any particular point in time.  Thus, a table level restore may contain outdated data.  It may also result in inconsistent data if checkpoints occurred during a backup, where changes to one table are written to the backup file but changes to other tables are not as the extents that were stored in have already been written to the backup file.

The applications that I tested that produced the above results were as follows:



File date


15 June 2008


12 May 2007



27 March 2008

Document history
7/8/2008    Added checkpoint information.    
6/27/2008    Initial release.    
Copyright 2008 - 2021 Yohz Ventures Sdn Bhd. All rights reserved.
All product and company names are trademarks or registered trademarks of their respective owners.