Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
2000-09-27
2003-11-18
Metjahic, Safet (Department: 2171)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000
Reexamination Certificate
active
06651077
ABSTRACT:
FIELD OF THE INVENTION
The invention relates generally to electronic databases. More particularly, the invention relates to backup and restoration of data in such databases.
BACKGROUND
Database systems often perform backup and restore operations to provide a safeguard for protecting critical data stored in databases. Backing up and restoring a database allows for the complete restoration of data over a wide range of potential system problems, including media failure, user errors, or loss of database servers. In addition, backing up and restoring databases is useful for other types of problems not related to the system itself, such as moving or copying a database from one server to another. By backing up a database from one computer and restoring it to another, a copy of a database can be made quickly and easily.
Backup operations can be performed, for example, as database backups or transaction log backups. Other types of backup operations include file backups, differential file backups, and differential backups. Backing up a database makes a copy of the database that can be used to restore the database if it is lost. Everything in the database is copied, including any needed portions of the transaction log. The transaction log is a serial record of all the modifications that have occurred in a database and includes information as to which transaction performed each modification. The transaction log is used during restore operations to roll forward completed transactions and to roll back or undo uncompleted transactions.
By contrast to a database backup, backing up a transaction log backs up only the changes that have occurred in the transaction log after a prescribed synchronization point. For database backup operations, this synchronization point might occur after data is copied from the database files, but before copying the portion of the transaction log that is needed to provide a transactionally consistent view of the data that was copied from the database files. For log backup operations, the synchronization point might occur before the log is copied to the backup media, i.e., roughly the start of the log backup operation. Thus, while a database backup records the complete state of the data in the database at the time the backup operation is completed, a transaction log backup records only the state of the transaction log at this synchronization point.
Other backup operations include differential database backups, which only copy those database pages that have been modified after the last full database backup, as well as the portion of the transaction log that is needed to roll it forward and perform undo operations for transaction consistency. Like transaction log backups, differential database backups improve recoverability by reducing the amount of data at risk for loss in the event of failure. Moreover, the amount of time involved in performing a restore operation is reduced relative to full database backups. Unlike transaction log backups, however, differential database backups do not necessarily allow restoration to the exact point of failure. Restoration can only be performed up to the point in time at which the differential database backup was created. Thus, differential database backups are often supplemented by subsequent transaction log backups. Still another type of backup operation is a file or filegroup backup, which allows the recovery of just the portion of a database that was on a disk that failed.
A restore operation involves the application of a backup set to a database. Restoring a database backup returns the database to the state in which it was when the backup was created. Any incomplete transactions in the database backup are rolled back to ensure that the database remains internally consistent. Incomplete transactions include any transactions that were not complete as of the above-described synchronization point. Restoring a transaction log backup reapplies all completed transactions that are in the transaction log to the database. When applying a transaction log backup, the transaction log is traversed, and all transactions in the log are rolled forward. When the end of the transaction log is reached, the database is restored to the state in which it was when the transaction log backup operation began. The restore operation then rolls back all transactions that were incomplete when the backup operation started.
Database backups and transaction log backups are advantageously used together to restore a database to the point in time at which a failure occurred. Loss of data due to the failure can be greatly reduced or even eliminated entirely. In certain situations, using both database and transaction log backups is highly desirable. For example, the practice is advisable in any situation in which any loss of changes after the last database backup is unacceptable. The use of transaction log backups is also indicated when the resources involved in performing only database backups are limited. In addition, transaction log backups are advantageous in cases in which it is desirable to return the database to some point in time before failure.
In addition, it is also advisable to use transaction log backups in cases in which changes to the database are frequent. When a large number of changes occur to the database over a relatively short period of time, the last database backup can become outdated quickly. Because transaction log backups typically use fewer resources than database backups, they can be created more frequently than database backups. Thus, the window of time in which a failure can occur after a backup is reduced, also reducing the amount of data that is potentially lost. Further, by applying transaction log backups, the database can be recovered to a specific point in time before a failure. This point in time need not be immediately before the failure.
To restore a database from both a database backup and one or more transaction log backups, the most recent database backup is typically restored. Next, the transaction log backups that were created after the most recent database backup are applied in the same order in which they were created. Although the use of transaction log backups increases recoverability, creating and applying them is also more complex than using database backups alone. Restoring a database using both database and transaction log backups works only if there is an unbroken sequence of transaction log backups after the last database or differential database backup.
One difficulty encountered in the context of backup and restore operations is the possibility of database corruption in certain situations. Each time a new database is created by recovering the database through certain restore operations, a divergent path known as a recovery fork is created. For example, in the case of a database restore operation followed by one or more log restore operations, all operations except the last one are performed without the option of recovery and thus do not result in the creation of a new database. The last log restore operation, however, is performed with the option of recovery and effectively results in the creation of a new database, and thus of a new recovery fork. Performing a restore operation with the option of recovery essentially results in the creation of a new database and, thus, a new recovery fork. If a backup set is applied to a database from a different recovery fork than the fork on which the backup set resides, corruption may result.
FIG. 2
depicts an example backup and restore process in which multiple recovery forks are generated, and in which the database would be corrupted. In
FIG. 2
, the letters “A” and “B” represent the recovery fork on which the database resides at the beginning of the process illustrated and described at that particular point in time. First, at a time
202
, a full database backup is made. For reference purposes, this backup is labeled “1.” At this point, there is only one recovery fork, referred to as fork “A.” Subsequently, transaction log backups labeled “2” and “3” are made at tim
East Jeffrey A.
Schmidt Steven R.
Smith Gregory A.
Metjahic Safet
Microsoft Corporation
Nguyen Cam-Linh
Woodcock & Washburn LLP
LandOfFree
Backup and restoration of data in an electronic database does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Backup and restoration of data in an electronic database, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Backup and restoration of data in an electronic database will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3173175