CN1784676B - Database data recovery system and method - Google Patents

Abstract

The present invention relates to systems and methods for data recovery, for example, after the occurrence of a user error. In particular, a snapshot database may be maintained that stores a copy of the database data. The snapshot database does not have to store a complete copy of all the data on the source database, but it shares data that is common to both, but not necessarily identical. If an error occurs on the primary database, the database may be restored to a point in time prior to the error by replacing the source database file with the snapshot file. Additionally, an undo component may be used in conjunction with the snapshot to approximate the error to a finer grained point in time. In short, the present invention can restore a database faster and more simply while using less space and resources than conventional data recovery techniques.

Description

Database data recovery system and method

Related application reference

This application claims priority to the following applications: U.S. Provisional Application No. 60/547,641, filed February 25, 2004, and entitled DATABASE DATA RECOVERY SYSTEM AND METHOD; U.S. Nonprovisional Application No. 10/833,541, filed April 28, 2004, and entitled DATABASE DATA RECOVERY SYSTEM AND METHOD, which applications are hereby incorporated by reference. Additionally, this invention is a continuation-in-part of U.S. Application Serial No. 10/611,774, entitled TRANSACTION CONSISTENT COPY-ON-WRITE DATABASE, filed June 30, 2003, also incorporated by reference here.

technical field

The present invention generally relates to databases, and more particularly to database restoration techniques.

background

Databases are quite popular in today's world. Databases can store large amounts of information in a manner that facilitates rapid query and ease of use. For example, in a traditional relational database, information can be organized into objects such as records, tables, and indexes. A database engine provides a mechanism for retrieving and manipulating data from database tables after a user specifies a query. Queries are usually expressed in some query language, such as Structured Query Language (SQL). A query specifies one or more tables, along with the rows and columns to be retrieved or manipulated. By specifying the query appropriately, the database engine retrieves the data, performs any specified operations, and produces the resulting tables. Databases are popular and useful at least in part because of their ability to store large amounts of data that can be efficiently retrieved and manipulated by simply specifying queries.

Unfortunately, user error is a common problem in database systems. Typically, such errors occur when a database application or user mistakenly changes or deletes data, and the database system correctly follows orders and changes or deletes data promptly. This is known in the art as the quick finger delete problem. For example, a user might issue a command to delete a table, but forget to specify a "WHERE" clause, resulting in more data being deleted than expected. Additionally, a user may install a new application that modifies the database in ways unknown to the user. There are several traditional solutions to this problem. Generally speaking, the most common solution is to fully restore the data to a point in time before the user error occurred. Once the database is restored, it may go online and all changes, including user errors, are lost. However, full database restores are time-intensive and can sometimes take days to complete.

Alternatively, data that has been inadvertently modified can be remedied by extracting relevant information from the recovery database and merging it back into the original database. A variation on this scheme is called log shipping.

Log shipping involves keeping a copy of the database on another secondary server in recovery state, but with a constant delay after the original server. Log backups are only applied to the secondary database after a delay (such as 24 hours). If a user error occurs in the original database, and the DBA notices the error within the delay time, the DBA can restore to the secondary server because it already contains the database from a point in time before the error. Unfortunately, log shipping is complex, requiring many additional resources and space.

Restoring a database using traditional systems and methods requires considerable latency, so it is usually an option of last resort. In addition, log shipping requires additional hardware, which increases the complexity of the database system. Reducing errors is a big and important problem in database systems. Accordingly, there is a need in the art for a new system and method for, among other features, fast and efficient restoration of a database.

overview

The following provides a simplified summary of the invention in order to provide a basic understanding of various aspects of the invention. This summary is not an extensive overview of the invention. It is not intended to identify key/critical elements of the invention or to delineate the scope of the invention. Its sole purpose is to present some concepts of the invention in a simplified form as a prelude to the more detailed description that is presented later.

The present invention relates to the creation and utilization of database snapshots. The present invention alleviates the problems associated with restoring a database, which takes time and is usually an option of last resort, and with log shipping, which often requires additional hardware, adding to the complexity of the database system. Reverting to a database snapshot alleviates some of these problems. According to an aspect of the invention, a database snapshot (DBSS) is a database that looks like a read-only, point-in-time copy of another (source) database. The DBSS does not have to be a complete copy of the source database; the two databases share data that is common to both, which allows the DBSS to be created quickly and space efficiently. When the source database is modified, the original data is copied to space-efficient storage for use by the DBSS to maintain its point-in-time view of the source database. If the user error occurred on the source database, and the DBSS had been created before the error, the database administrator has the option of restoring the entire database to the DBSS, which was at the point in time before the user error. All changes to the source database, including user errors, are lost. Also, this restore is typically much faster than normal recovery and does not require the duplication of resources required for log shipping.

According to an aspect of the invention, reverting to a database snapshot may include copying the database snapshot file pages on the source or primary database, truncating the primary database, applying open uncommitted transactions to the database, and using the database log to focus on issues such as user error Wait for the event.

According to an aspect of the invention, a user or database administrator can create one or more database snapshots at different points in time. For example, if a user wants to perform a test, he/she can create a database snapshot to enable reverting to a previous database state or view. However, according to another aspect of the present invention, a monitor component can be used to monitor the primary database and automatically create database snapshots when certain events occur. For example, if the monitor detects or can infer that a new application is about to be installed, it can initiate the creation of a database snapshot to preserve the state of the database before the new application changes.

According to yet another aspect of the present invention, the mirror database can be automatically updated to reflect changes made to the primary database while restoring. Thus, mirrored databases can be updated and synchronized without the lengthy full recovery that has traditionally been used.

To the accomplishment of the foregoing and related ends, certain illustrative aspects of the invention are described herein, taken in conjunction with the following description and accompanying drawings. These aspects indicate different ways in which the invention can be practiced, all of which are intended to be covered by the invention. Other advantages and novel features of the invention will become apparent from the following detailed description of the invention when considered in conjunction with the accompanying drawings.

Brief description of the drawings

The foregoing and other aspects of the invention will become apparent from the following detailed description and the accompanying drawings briefly described below.

FIG. 1 is a functional block diagram of a data recovery system in accordance with one aspect of the present invention.

Figure 2 is a functional block diagram of a recovery component in accordance with an aspect of the invention.

Figure 3 shows a simplified timeline diagram to illustrate aspects of the invention.

FIG. 4 is a functional block diagram of a database snapshot system according to one aspect of the present invention.

FIG. 5 is a diagram illustrating exemplary database recovery in accordance with an aspect of the present invention.

FIG. 6 is a functional block diagram of an exemplary database mirroring system in accordance with an aspect of the present invention.

7 is a functional block diagram of an exemplary mirroring system in accordance with an aspect of the present invention.

Figure 8 is a functional block diagram of a primary database in accordance with an aspect of the present invention.

FIG. 9 is a functional block diagram of a database snapshot system according to an aspect of the present invention.

10 is a functional block diagram of an exemplary transaction log in accordance with an aspect of the present invention.

FIG. 11 is a flowchart describing a method for establishing a snapshot database according to an aspect of the present invention.

FIG. 12 is a flowchart illustrating a recovery method in accordance with an aspect of the present invention.

FIG. 13 is a flowchart of a data recovery method according to an aspect of the present invention.

14 is a functional block diagram illustrating a suitable operating environment in accordance with one aspect of the present invention.

15 is a functional block diagram of an example computing environment that can interact with the present invention.

A detailed description

The present invention is now described with reference to the drawings, wherein like numerals refer to like elements throughout. It should be understood, however, that the drawings and detailed description are not intended to limit the invention to the precise form disclosed. On the contrary, the invention is intended to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention.

As used in this application, the terms "component" and "system" refer to a computer-related entity, which is either hardware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. As an illustration, both an application running on a server and a server can be a component. One or more components can reside within a process and/or thread of execution and a component can be localized on one computer and/or distributed between two or more computers.

Furthermore, the present invention may be implemented as a method, apparatus, or article of manufacture using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof. The term "article of manufacture" (or "computer program product") as used herein is intended to encompass a computer program accessible from any computer-readable device, carrier, or media. For example, computer readable media may include, but are not limited to, magnetic storage devices (such as hard disks, floppy disks, magnetic stripes, ...), optical disks (such as compact disks (CDs), digital versatile disks (DVDs). ...), smart cards, and flash memory devices (e.g. cards, sticks). Of course, those skilled in the art will recognize many modifications can be made in this configuration without departing from the scope and spirit of the invention.

restoration system

Referring first to FIG. 1 , a data recovery system 100 is shown. The data recovery system 100 includes a source database 110 , a snapshot component 120 , a snapshot database 130 and a recovery component 140 . The source database 110 (hereinafter also referred to as the primary database) contains large volumes of data in an organized fashion for ease of query and other purposes. Database 110 may be any kind of database, including but not limited to, relational or multidimensional databases. The snapshot component 120 generates a snapshot database 130 (also referred to herein as a DBSS) based in part on the source database. Snapshot database 130 allows a user to create a transactionally consistent view of an existing source database 110 without making a full copy of it. When the source database 110 forks from the snapshot database 130, the snapshot component 120 ensures that the snapshot database 130 contains a copy of the data before it was modified, eg, in units of pages. In other words, if a source database page contains the letter "A," and a transaction is executed that causes "A" to change to "B," it can be used to write the corresponding snapshot database page, and thus store the letter "A." According to an aspect of the invention, snapshot database 130 may be a read-only point-in-time copy of source database 110 . The DBSS is not necessarily a complete copy of the source database 110 . The two databases can share data that is common to both, which also enables the DBSS to be created quickly and space efficiently. When the source database 110 is modified, the original data can be copied to space efficient storage for use by the DBSS to maintain its point in time view of the source database 110 . Furthermore, it should be understood that there may be more than one snapshot database 130 associated with a source to provide multiple restore points. Additionally, snapshot database 130 may be transient or persistent. A transient snapshot is an internal volatile copy that is deleted after a crash, failure, or shutdown. Persistent snapshots are public copies that are more securely kept on storage for use by other applications.

Restore component 140 utilizes snapshot database 130 to restore source database 110 to a point in time prior to the event. According to an aspect of the present invention, the event may correspond to a user error, such as a quick finger delete, that is, the user accidentally deletes data from the source table. Alternatively, an event may correspond to a system crash, deadlock, or any other situation where data is lost or manipulated. If the event occurs on the source database 110, and the snapshot database 130 has been created before the error, then the database administrator has the ability to use the restore component 140 to restore the entire source database 110 back to the snapshot database 130 at the point in time before the event option. Restoration component 140 can utilize data residing in snapshot database 130 to restore source database 110 to a previous point in time prior to the event. For example, snapshot database data may be used to overwrite current source database values at corresponding locations. Alternatively, snapshot database 130 can be populated with shared data and become the new source database. It should be appreciated that this recovery process is typically much faster than traditional recovery techniques because only sparse files need to be copied to the source database rather than full recovery. Furthermore, the recovery process is more efficient because it does not require duplication of resources as required by log shipping.

FIG. 2 depicts recovery component 140 in accordance with an aspect of the invention. In particular, the restore component includes a restore component 210 and an undo component 210 . The restore component 210 provides the main functionality in recovery according to the present invention, while the undo component 220 facilitates fine-grained recovery, which focuses on events such as errors. If the database snapshot has been created before the incident, the restore component 210 can utilize the sparse files in the database snapshot to restore the source database to the time before the incident. Data files or pages that were changed after the snapshot was created can be returned to the state at the time of the snapshot by copying the old values stored in the snapshot database to the source database. This results in loss of data, including errors, for example from the time the snapshot was created until the restore operation. For example, if the source database contains "A", "B" and "C" when the snapshot database was created, and then "B" is changed to "D", the snapshot database can contain "B" and the source database can contain "A", "D", "B". The restore component can then restore the database to the value at the time of the snapshot by simply copying "B" onto "D". However, there may be in-flight transactions that have not been committed when the database snapshot is created. These transactions are not captured by database snapshots. Therefore, after the source database is restored to the database snapshot, those transactions are lost, and operations (such as inserts, updates, deletes) that occurred as a result of the transactions will not be performed.

Undo component 220 can be used to compensate for this inaccurate representation upon restoration, among other things. For example, undo component 220 can store all open transactions at the time of snapshot database creation, including all transactions that started before snapshot creation and terminated thereafter. These stored transactions can then be used to roll forward the recovered primary database to capture open transactions and focus recovery events. Additionally, the undo component 220 can utilize traditional database logs that capture database changes at periodic intervals or at administrator command to more closely focus on events such as errors, thereby minimizing the loss of "good" transactions. Thus, the present invention at least facilitates database recovery and can be done routinely with less system resources but at a much faster rate.

Turning to FIG. 3, a timeline 300 is shown to provide further clarity regarding database recovery operations in accordance with an aspect of the present invention. Time advances from left to right on timeline 300 . In other words, events positioned farther to the right occur in time after events positioned farther to the left. At 310, a database snapshot (DBSS) is created. A period of time passes (minutes, hours, days...) and an event occurs at 320 . For example, an event may correspond to a user accidentally deleting a complete form or modifying page data. Thereafter, recovery operations can be initiated, for example, by a database administrator. Accordingly, the restore component 210 (FIG. 2) of the present invention can be used to restore the database to the point in time 310 when the database snapshot was created. According to an aspect of the invention, this may be accomplished by copying sparse file data from the snapshot database to corresponding data in the source database, thereby placing the source database in a consistent steady state lacking the effects of the event at 320 . Undo component 220 (FIG. 2) can then be used to advance the source database to event 320 to maintain "good" data while losing or changing data caused by the event. This can be accomplished by applying open transactions stored in undo files to the restored database and/or database log files.

FIG. 4 illustrates a database snapshot system 400 in accordance with an aspect of the invention. DBSS system 400 includes snapshot component 120 , source database 110 , snapshot database 130 , catalog component 410 and monitor component 420 . The source database 110, as mentioned earlier, is the primary or primary database for which recovery is sought. The snapshot component 120 uses the source database 110 to generate a database snapshot 130 . Database snapshot (DBSS) 130 may be a read-only point-in-time database. It is space efficient because it shares space with the source database 130 . This shared space is the same for all data pages in both databases. According to an exemplary implementation, a DBSS may be created with the following syntax:

CREATE DATABASE ss_database_name

ON <filespec>[,...n]

AS SNAPSHOT OF source_database_name For each data file in source database 110, another file for DBSS 130 is created. These new files are sparse files. When pages are changed in the source database 110, they are first copied into sparse files. Catalog component 410 may be used to generate a log or log file to track whether pages in DBSS 130 are shared with source database 110, or whether pages have been copied into sparse files. According to an aspect of the invention, the logs are stored in the source database 110 for easy access thereto.

It should be appreciated that recovery can be run on the DBSS 130 before it is readable, to bring it back to a consistent state. The currently open transaction is rolled back, and some of the original pages will most likely be copied to the sparse file due to the rollback. According to an aspect of the invention, DBSS has no logs. Once the DBSS 130 is created, the DBSS can remain in existence until it is discarded by the database administrator (if it is persisted), or it can be discarded on error or system shutdown.

Multiple DBSSs 130 may exist at different points in time on a single source database 110. According to an aspect of the invention, all snapshots other than the one being restored or being restored can be destroyed. Alternatively, all snapshots residing in time after the snapshot being restored can be destroyed, and those snapshots occurring earlier in time can be preserved. Source database snapshots taken after the snapshot being restored or to be restored are not very valuable. Also, for example, a new snapshot may be taken of the source database after the source database has been restored using the database snapshot. Snapshots taken prior to the snapshot used for recovery are much more valuable because it is still possible to restore to the specific point in time captured by the previous snapshot.

DBSS 130 can be created and dropped in a periodic manner, or can be created and dropped in an ad hoc fashion if the user desires a single "safe" point in time to allow it to be restored. For example, a user might want to create a snapshot during a new application installation or testing phase. A restore to DBSS 130 may be issued with the following command:

RESTORE DATABASE{database_name|database_name_var}FROM

DATABASE_SNAPSHOT=<snapshotname> Monitor component 420 may also be used by snapshot component 120 to observe transactions on the source database and initiate automatic generation of database snapshots. For example, if the monitor component 420 detects or deduces the installation of a new application that may significantly alter the source database, it can initiate the creation of a database snapshot. To facilitate such functionality, it should be appreciated that the present invention may employ artificial intelligence systems and methods, including, but not limited to, rule-based expert systems, Bayesian rules, and neural networks.

To restore a database, the source database is shut down and all connections to it are closed. Therefore, the source is not available for transactions during this process. A database can be marked as "recovering" to notify external observers that the database is unavailable. The server can then proceed to copy the pages in the sparse file to their original locations in the source database file (when the DBSS was created). In the vast majority of cases, copying changed pages is much faster than restoring from backup. Once the pages are copied, the database's log can be rebuilt. The source database is now returned to its point in time when the DBSS was created. All changes since DBSS was created have been eliminated. If an undo file is created, the log chain is not broken and the data log backup taken from the source database can be used to roll into the source database.

The scheme to support rolling in after restore using an undo file can be summarized as follows. Upon creation of the DBSS, the original value of each page touched by the recovery of the DBSS upon creation may be saved as a "pre-image" in a separate undo file. On restore, the DBSS pages are copied into the source database as described. Preimages can be copied from separate undo files. At this point, the database is exactly as it was when the DBSS was created. Thereafter, the database log can be used to roll the restored DBSS to a point in time just before the user error occurred to minimize the amount of data loss.

Turning to FIG. 5 , a diagram illustrating an exemplary database restore 500 is provided in accordance with an aspect of the present invention. Source database 110 includes two database files 510 and 520 . Both database files 510 and 520 contain 8 pages, each with different data. Take a snapshot of the source database. A database snapshot 130 is thereby created. The snapshot database may have two snapshot database sparse files 530 and 540, which correspond to source files 510 and 520, respectively. These source files may simply be shells as they share all data with source files 510 and 520 at the time of snapshot origin. At some point after snapshot creation, values in the source database may be changed. Here, the changed values reside in pages 3 and 7 of file 510, and page 4 of file 2. In particular, page 3 has changed from "C" to "Z", page 7 has changed from "G" to "Y", and page 4 has changed from "L" to "Z". Therefore, the original values before the change have been saved to the sparse files 530 and 540, here "C", "G" and "L". Once restored, the pages in the sparse file, here pages 3 through 7 from file 530 and page 3 from file 540 may be copied back to the updated pages in the source or primary database 110 .

Copying pages covers several cases, this includes simply copying back modified pages, or things like adding or removing files, growing or shrinking the main database file to the size of the sparse file, adding or removing pages (i.e. tracking pages so that they can be erased during recovery) and more complex cases. For file additions and deletions, the file lists of the source database and the database snapshot are compared and synchronized. For page additions, if the source is larger than the snapshot or replica, the source can be cut off at the end or truncated to the size of the replica, in part because, according to an aspect of the invention, the pages being added are at the end of the source. If the replica is larger, this means that the page was removed from the primary source. Therefore, the size of the source can be increased, and all pages of the range will already be in the snapshot, and thus will be copied by the normal copy operation.

algorithm)是将它们一个接一个的复制。然而，根据本发明的一方面，可使用异步复制操作实现。例如，可使用单个线程和三个队列一读队列、写队列以及空缓冲队列。在复制返回的同时，若页在源中(如，意味着它已改变)，或者它不在源中(如，意味着它被删除)，则它可被简单地复制到源。然而，若主要源中有额外页，则它们可能被添加到文件的末端，这可通过将文件截短到复制品的大小而补救。最后，源可被解锁，以完成恢复。A naive algorithm for copying back pages (

algorithm) is to copy them one by one. However, according to an aspect of the invention, an asynchronous copy operation implementation may be used. For example, a single thread and three queues—a read queue, a write queue, and an empty buffer queue—can be used. While copying back, if the page is in the source (eg, meaning it has changed), or it is not in the source (eg, meaning it was deleted), it can simply be copied to the source. However, if there are extra pages in the primary source, they may be added to the end of the file, which can be remedied by truncating the file to the size of the replica. Finally, the source can be unlocked to complete the restore.

According to another aspect of the invention, log backups associated with the source database can be broken after recovery. Therefore, log backups will be invalidated on the restored database until a full or file backup is made. A restored database maintains the same recovery model as it was created. Therefore, the system of the present invention can support (1) start restore; (2) manipulate data; (3) rebuild log; and (4) restart database.

According to another aspect of the invention, a new source database can be created from the snapshot database by copying data from the original source database. Any errors in the database creation phase may require a database administrator (DBA) to restart operations, for example, once the server becomes available. Once the database is created, the DBA can discard the source database and rename the restored database. Such a system can be used, for example, for data mirroring.

Turning now to FIG. 6, an exemplary data mirroring system 600 is shown in accordance with an aspect of the present invention. System 600 includes two databases: source database 110 and mirror database 610 , database snapshot 130 and recovery component 140 . Source database 110 is the main database. Mirror database 610 is a separate database that contains an almost bit-by-bit replica of source database 110 . In this way, when changes are made to the source database 110, they may be sent to the mirror database 610, eg, over a network. The concept of mirroring is that if primary source database 110 fails or becomes unavailable, for example due to a power failure, mirror database 610 can become the new source database for transactions, thereby facilitating high availability of data through redundancy. According to the aforementioned aspect of the present invention, the source database 610 may have a snapshot database snapshot 130 associated therewith to facilitate point-in-time restoration. In this way, a database administrator can use database snapshot 130 and restore component 140 to restore source database 110 to a previous point in time. If the restore is performed on the source database 110, the mirror database 610 should also reflect the change. Conventionally, time consuming backups and full restores are required to update and resynchronize mirror database 610 . According to an aspect of the invention, the mirror database 610 can be automatically updated and synchronized with the source. Since changes to the source are automatically reflected in the mirror database, changes to the source during the restore phase can also be passed to the mirror concurrently or asynchronously after the restore has completed on the source.

Turning to FIG. 7, an exemplary system 700 for mirroring a database with snapshots is shown in accordance with an aspect of the present invention. As shown, system 700 includes a base or target database 610 named DB1_LS. Application 620 seeks to view data from database 610 . In particular, application 620 may interact with snapshots 630 named DB1_001, DB1_002, and DB1_003. A first snapshot DB1_001 can be created and referenced to DB1, for example:

CREATE DATABASE DB1_001 AS SNAPSHOT OF DB1_LS

ON(NAME='datafile', FILENAME='F:\DB1_001.SNP') Subsequently, a second snapshot DB1_002 can be created. Users who still use DB1_001 continue to use it:

CREATE DATABASE DB1_002 AS SNAPSHOT OF DB1_LS

ON(NAME='datafile', FILENAME='F:\DB1_002.SNP') Thereafter, a third snapshot can be created and a reference to DB1 made. Users who still use DB1_001 or DB1_002 continue to use them:

CREATE DATABASE DB1_003 AS SNAPSHOT OF DB1_LS

ON(NAME='datafile', FILENAME='F:\DB1_003.SNP')

In addition, according to an aspect of the present invention, the database snapshot can be used to check the consistency of the database. For example, the DBCC CHECKDB() command can be executed on a database. As a result, internal snapshots of the database with alternate storage can be created in alternate streams of existing database files. The pages can then be read to perform a consistency check, and the system can read them from the base database (if they have not been modified) or from the alternate stream (if they have been modified).

It should also be appreciated that, although not shown, the invention may utilize one or more graphical user interfaces (GUIs). A GUI can be used to support snapshot management. For example, a number of text and graphics components including, but not limited to, text boxes, buttons, tabs, drop-down menus, and scroll bars can be used to create a snapshot and then restore the database thereto.

Also, both a database snapshot and its associated source database can be backed up in the traditional sense. For example, administrators can back up individual files or groups of files from snapshots. When backups are restored, they are restored as regular databases. When performing a backup operation on the source, the user can specify which snapshot is to be used for the backup. When restoring, the user can also specify which snapshot is to be restored.

Database snapshots (also known as Copy-On-Write databases)

In general, a database contains two types of files: data files and log files. A log file contains a series of log records. Log records can be identified by a Log Sequence Number (LSN). As depicted in FIG. 8, primary database 800 includes a set of data files 802 and log files 810, according to an aspect of the invention. Data file 802 may be divided into blocks or units of storage called pages.

A database snapshot for a database can be created, which provides a transactionally consistent view of an existing database at a previous point in time without creating a full copy of the database. A database snapshot, combined with a database, includes all the information needed to produce the information of a copy of the database at a previous moment. However, a database snapshot itself does not contain all the information, so its size can be smaller than a full copy. Additionally, snapshots can be created on the fly as modifications are made to the database, which allows the cost (time and processing) to spread over time. If the database snapshot was replicated at a previous point in time, both time and processing costs would be intensive. Additionally, database snapshots have the advantage that they can be created while update activity continues on the database. The primary database is the database that is used and one or more database snapshots of which are created.

As mentioned above, the database snapshot contains all the required information, as well as the main database, which determines the content of the main database at the previous moment. A database snapshot may contain side files corresponding to each file in the primary database. A sidefile contains a copy of all data from the corresponding datafile that has been changed since the database snapshot was created. In one aspect of the invention, to avoid the need to map tables from pages in the side file to pages in the primary file, the side file is stored in sparse space. In a sparse file, only the portion of the file that is actually written requires storage space. All other areas of the file may be unallocated. It should be noted, however, that storing side files in sparse files is not required by the present invention, and other storage systems and methods are contemplated within the scope of the present invention.

According to another aspect of the invention, the sparse file mechanism works with standard region sizes. If data within an area is written to a sparse file, space for the entire area can be allocated even if the data does not fill the entire area. Since this space is allocated and readable from it, a distinction can be made between the extent of the region filled with valid data and the extent of the region, which exists because the granularity of sparse files requires regions of a certain size to be allocated (if any storage in the area is required).

Because a database snapshot includes the original values of all data in the primary database that has changed since the database snapshot was created, database data at the time the database snapshot was created can be read from the snapshot. In response to a request for data from the database snapshot, data may be read from a side file of the database snapshot (if the side file contains data from the request). Data to be read that is not in the secondary file has not changed since the database snapshot was created and can be read from the primary database.

According to another aspect of the invention, the secondary files contain data pages from the primary database. When data is changed on any page of the primary database, that data page is stored in the secondary file. The invention has been described with reference to pages as units of data in the primary database; however, it is contemplated that other units of data from the main database could also be used.

To determine which data is written to the side file, and which data should be read into the main database, the presence of valid data in the side file should be confirmed. In one example, it can be read directly to determine whether valid data is present. According to another aspect of the invention, a secondary page table can be created which stores data as to whether a given page exists and is valid.

For each page in the main database, the subpage table can store information about whether the page should be read from the main database, indicating that it has not changed, or the subpage table can store information about whether the page should be read from the sidefile fetched information, which indicates that it has changed. The sidepage table allows to quickly determine whether a given page exists in the sidefile.

According to another aspect of the invention, both sidefile and sparsefile mechanisms use the same page/region size. That is, the pages saved by the side file from the primary database are the same size as the area the sparse file stores when any memory is written into the sparse file. For example, if the sparse file region is 8KB, and the pages stored from the main database are also 8KB, then the page size and region size are equal. In this case, any filled regions will be completely filled with pages read from the primary database, and it is impossible to store invalid data in that region.

According to another aspect of the present invention, a plurality of side file areas may correspond exactly to each page. For example, if the sparse file region is 8KB (kilobytes), and the pages stored from the primary database are 16KB, then each page stored in the secondary file will fill two regions. Also, in this case, any filled regions will be completely filled with content from pages read from the primary database. Also, invalid data cannot be contained in this area.

For these aspects of the invention, the side page table contains an in-memory bitmap that holds one bit of information about each page in the side file. For each page in the sidefile, a corresponding bit indicates whether the page is in the sidefile.

According to another aspect of the invention, the granularity of the secondary file area is greater than the granularity of pages stored from the primary database. For example, if each region of the sidefile is 64KB, and the page size is 8KB, the presence of the region in the sidefile does not necessarily indicate that all the information in the region is valid data from the primary database. If only one page is copied into the sidefile, in this example only 8KB of the 64KB in the allocated region will contain valid data. In another embodiment, certain side file pages are scattered throughout the zone.

For these purposes, the side page table contains two in-memory bitmaps that hold two bits of information about each page in the side file, referred to as bit 1 and bit 2. For each page in the sidefile, a corresponding bit indicates (bit 1) whether the page is actually in the sidefile, and (bit 2) whether the page is potentially in the sidefile. Bit 2 can also be considered to indicate that an area has been allocated where the page should be kept in the side file. However, as described below, in one embodiment, this bit 2 is only set when the secondary page table is reconstructed.

Bitmaps are maintained in memory and therefore may not be persistent. If they are erased, the bitmap is reconstructed from the sparse file information. The sparse file is consulted, and for each page, if the side file has allocated space for the region in which the page is located, bit 2 is set to indicate that the page is potentially in the side file. For each page, bit 1 is initially set to indicate that the page is not in the sidefile.

If subpage tables are maintained in their persistent fashion, the granularity of regions and pages may be negligible, and a one-bit subpage table may be used. However, in one embodiment, to support persistent database views across database server restarts, two-bit page tables are used.

According to an aspect of the invention, no page tables are created for side files. In this case, the database snapshot is consulted whenever it is necessary to determine whether pages in the database snapshot have been replicated. The invention will be described below with reference to an aspect of the invention in which there is a one-bit or two-bit page table, however, other embodiments of the invention are conceivable in which no page table is present and the database view must be examined to determine Whether it contains pages copied from the primary database.

As shown in FIG. 9 , database snapshot 920 of primary database 800 consists of secondary files 925 . Each data file 802 in primary database 800 has a corresponding secondary file 925 in database snapshot 920 . In addition, secondary page table data 930 is stored in the memory of the database snapshot 920 . According to one aspect of the present invention, secondary page table data 930 is a secondary page table that covers all secondary files 925 . According to another aspect of the invention, a separate side page table may exist for each side file 925 .

In a database, the transaction log is a continuous record of all transactions that have been performed on the database since the transaction log was last backed up. The transaction log is used to restore the database to the point of failure. According to one aspect of the invention, the transaction log is modeled as a circular queue. The transaction log can be truncated by removing inactive portions of the log. This inactive portion contains completed transactions, which do not need to be recovered, at least because they reflect changes that have been persisted to the data files. In contrast, the active portion of the transaction log contains completed transactions as well as incomplete transactions that are still running (active transactions). Truncation can be done to minimize inactive space in the transaction log, rather than allowing the transaction log to continue to grow and use more space.

Active transactions can cause transaction inconsistencies. For active transactions, some modifications to the data file may not have been written to the data file from the buffer cache, and there may be some modifications from outstanding transactions in the data file. Log files 810 may be used to ensure that recovery of the database is transactionally consistent. This can be done using ARIES (Algorithms for Recovery and Isolation Usage Semantics) style recovery. Every modification recorded in the log that may not have been written to the data files is rolled in by performing the modification to the database. To ensure the integrity of the database, each incomplete transaction found in the transaction log is rolled back by undoing the modification to the database.

To create a database snapshot, the physical structure of the database view (side files and page tables) must be initialized. First, a secondary file 925 is created for each data file 802 in the primary database 800 . As mentioned above, the side file may be a sparse file, or in another embodiment a non-sparse file of the same size as the data file 802 . Side file 925c is associated with data file 802 in primary database 800 .

Because transactions occur sequentially and database views are transactionally consistent, a transaction log should be used during database snapshot creation. To ensure that information about transactions that should be used for database views is not discarded, log truncation is disabled on the primary database 800 (if it exists).

According to an aspect of the invention, secondary page table 930 is initialized for database snapshots. First, sidepage table 930 is set to indicate that no pages exist in sidefile 925, and, in the case of a two-bit sidepage table, no pages are potentially or determined to be in sidefile 925.

When initialization is complete, the database snapshot is ready to "go live". Now, the database snapshot will run along the primary database 800, and when a modification is performed, a copy of the original value of the modified page (ie the content of the page before the update was performed) will be stored in the database snapshot. An exemplary method for achieving a transactionally consistent snapshot of a database may include determining a split point on a transaction log. This split will correspond to the point in time represented by the database snapshot. The LSN at the end of the log on primary database 800 is available when the database snapshot is created; this LSN is the "split point" at which primary database 800 and database snapshot 820 will begin to fork. The primary database 800 may then be marked such that database snapshot processing is required. Database snapshot support in primary database 800 begins as described below.

For database snapshot consistency, the log of the primary database 800 prior to the split point must be analyzed to determine what transactions were active at the time of the split. The oldest active (since the split point) transaction in the log is identified. Allow log truncation before the oldest active transaction.

In a manner similar to ARIES (Algorithms for Recovery and Isolation Usage Semantics) style recovery, all operations from the oldest active transaction in the primary database 800 log before the split point are performed on the database snapshot. FIG. 10 is a block diagram of an exemplary transaction log-log file 810 in accordance with an aspect of the invention. The log entries in log file 810 include log entries 1000 , 1010 , 1020 , 1030 , 1040 , 1050 , 1060 , 1080 , 1080 , 1090 , and 1099 . Determine the split point 1075. Transactions continue to be written to the log, however truncation is disabled. Examine the log file 810 and perform any modifications to the database on the side file 925 as a result of the transaction from the oldest active transaction to the split point (in the example of Figure 10, from log entry n1000 to log entry n+7) . The results of modifications in each of these transactions are stored in side file 925. However, check these transactions. Modifications written to the log file by any active transaction in the log, such as log entry n1000, log entry n+21020, and log entry n+6, are undone in sidefile 925.

However, some transactions may not have been committed. Therefore, transactions active in the log up to the split point should be located and undone. According to an aspect of the present invention, where an outstanding transaction changes the value of a certain position in the database, changes that have been added to the above-mentioned side file are deleted from the side file. Alternatively, the transaction can be undone by modifying the database snapshot as detailed below, setting the data in the side file to match the data in the database starting from the split point.

This way, only outstanding transactions from the log are reflected in the database snapshot. Log truncation is allowed in the primary database 800 when transactions in the log are reflected in the database snapshot, except for transactions that were active when the split point occurred but have been withdrawn. Because database snapshot processing has been enabled, database snapshots will be updated when changes are made to primary database 800, and thus database snapshots can be used to determine the contents of primary database 800 from the moment of the split point.

When the database server is restarted (either gracefully or abnormally) after it was shut down, the database snapshot should be reinitialized. In order to do this, the subpage table already stored in memory must be reinitialized.

To reinitialize the subpage table, in a two-bit subpage table implementation, for each region in the subpage table that has been allocated, the data in the subpage table for each page in the region that has been allocated (bit 2) is set to indicate that the page may have been written to sidefile 925. Data in the secondary page table for all other pages is set to indicate that the page cannot be written to secondary file 925. However, it is indeterminate that a page is written to sidefile 925, so bit 1 is not initially set.

Alternatively, in a two-bit side table implementation, or in a one-bit side page table implementation, side file 925 may be checked to determine for each page whether a page in side file 925 is valid, as described above. The page table is set to indicate that the page does actually exist in sidefile 925 for each page that does exist. All other pages are set to indicate that the page does not exist in sidefile 925.

In order for the database snapshot to store information from the primary database 800 before the data is overwritten, the primary database 800 must support the creation of database snapshots. For each page modified by primary database 800, a determination must be made whether the page is in the database snapshot. If the page exists in the database snapshot, it is the correct version of the page. This may arise, for example, when a previous modification was made to a page in the primary database 800 . If the page is changed again in the primary database 800, the version in the database view should not change.

When receiving information from the primary database 800 that a page has been changed, if the page is in the secondary file 925, then do nothing. If the page is not in sidefile 925, the page should be written to sidefile 925 and the correct bit should be set in the sidepage table. In the case of a two-bit page table, there are three possibilities for bit 1 and bit 2 of the page, as shown in Table 1 below: Bit 1 indicates that the page is indeed in the sidefile Bit 1 does not indicate that the page is actually in the sidefile Bit 2 indicates that the page may be in the sidefile Case 1: The page is in the side file Case 2: Pages may be in sidefiles Bit 2 indicates that the page is indeed not in the sidefile case 1: page in side file [or: case 4: invalid] Case 3: The page is indeed not in the side file

Table 1: For two-bit page tables

According to an aspect of the invention, when bit 1 indicates that the page is indeed in sidefile 925, bit 2 is ignored; thus, as shown in Table 1, if bit 1 indicates that the page is indeed in sidefile 925, then the page is assumed to be in sidefile 925, regardless of what bit 2 indicates. In another embodiment, when bit 1 is set to indicate that the page is indeed in sidefile 925, bit 2 is set to indicate that the page may be in sidefile 925, and in this alternate embodiment, when When bit 1 indicates that the page is indeed in sidefile 925 and bit 2 indicates that the page is indeed not in sidefile 925, the case is invalid and an error is encountered.

When the primary database 800 indicates that a page is being changed, then for a two-bit page table, the actions that should be taken for the situations listed above are as follows:

Case 1: Do nothing.

Case 2: Determine whether the page is in the side file 225, if not, write the page into the side file 225.

Case 3: Write the page to the side file 925.

In case 1 or case 2, when a page is written to side file 925, the old version of the page in main database 800 (the version that is now being modified by main database 800) is written to side file 925. Additionally, the page table is set to indicate that the page is now in sidefile 925 so that any subsequent writes to the page will be processed according to case 1 and the correct page for the database view remains stored in sidefile 925.

In case 2 to determine whether the page is in the side file 925, the data corresponding to the page is read from the side file 925. If the data is valid, then the previous version of the page is in side file 925 and it should not be overwritten. In one embodiment, the page table bit 1 corresponding to the page is set to indicate that the page is indeed in the sidefile 925, so future writes to the page are processed in case 1 .

Data invalidity may be indicated by data placed in a newly allocated area to indicate that no valid data has yet been written to the area. For example, all zeros can be written to the newly allocated area if it is known that no database page will contain all zeros. If this is the case, the existence of a page in sidefile 925 is indicated by a corresponding page in sidefile 925 that is part of the allocated region and that contains some non-zero data.

The conditions detailed in Table 1 also apply to performing reads of data stored in database snapshots. When data in a page is read from a database view, the page should be read from sidefile 925 (if it exists in sidefile 925). If it does not exist, the page should be read from the primary database 800. In a two-bit page table system, the actions that should be taken for the three situations are as follows:

Case 1: A page is read from the side file 925.

Case 2: Determine if the page is in the side file 925, if it is in the side file 925, then read the page from the side file 925, if it is not in the side file 925, then read the page from the primary database 800.

Case 3: A page is read from the primary database 800 .

A database snapshot represents the state of the database at a previous point in time. Users can choose to use a database snapshot as the database. For example, a user may choose to perform an action on a database snapshot to create a database snapshot of the database as if it had performed an action on the database snapshot at a previous point in time. Additionally, during the initialization phase, as detailed above, transactions can be executed and undone on the database snapshot.

In order to modify a database snapshot, the modification should be based on the data in the database snapshot, and the resulting pages should be stored in the database snapshot. If the data about the page does not exist in the database snapshot, the modification should be based on the data in the primary database 800 and the resulting page should be stored in the database snapshot.

In the two-bit page table system, the actions to be taken in the three cases are as follows:

Case 1: Read a page from side file 925, perform modification, write the page to side file 925.

Case 2: Determine if the page is in side file 925, if it is, then proceed as in case 1, if not, then proceed as in case 3.

Case 3: A page is read from the main database 800, written to the sidefile 925, and the page table is set to indicate that the page is in the sidefile 925. Modifications to pages are performed and the modified pages are written to sidefile 925 as appropriate.

In view of one or more of the exemplary systems described above, methods that may be implemented in accordance with the present invention may be better appreciated with reference to the flowcharts of FIGS. 11-13 . While the methodologies are shown and described as a series of blocks for simplicity of explanation, it is to be understood and appreciated that the invention is not limited by the order of the blocks, as certain blocks may be in different order in accordance with the invention. Occurs sequentially and/or concurrently with other blocks described and illustrated herein. Moreover, not all illustrated blocks may be required to implement a methodology in accordance with the invention.

In addition, it should be further appreciated that the methods disclosed below and throughout this specification can be stored in an article of manufacture to facilitate transport and transfer of such methods to a computer. The term article of manufacture is used to encompass a computer program accessible from any computer readable device, carrier, or media. By way of illustration and not limitation, articles of manufacture may embody computer readable instructions, data structures, schemas, program modules, and the like.

FIG. 11 depicts a method for building a snapshot database 1100 in accordance with an aspect of the present invention. A snapshot database maintains data about changes to the source database since the point in time it was created. At 1100, a request to alter data in a source or primary database is received. For example, a request to change or alter a data page may be made. At 1120, a copy of the data in the source database to be replaced by the new data is copied into the modified snapshot database files and pages corresponding to the source database. At 1130, the new data is copied or replaced by the old data in the source database. Finally, at 1130, the catalog can be updated to notify of changes to the database and entries in the snapshot database.

Figure 12 illustrates a data recovery method 1200 in accordance with a method of the present invention. At 1210, each page of data stored in the snapshot database may overwrite data at a corresponding location in the primary database. In addition, it should be appreciated that the main files in the database can be extended if necessary to enable the receipt of snapshot data. At 1220, the size of the snapshot database or files therein may be identified and compared to the size of the primary database or corresponding files therein. If the snapshot database or the files in it are smaller than the primary database or the files in it, meaning that the files should not exist in the restored database, the primary database can be truncated to remove the added data pages. This may correspond to deleting the last page of data in the file when newly added data is added to the end of the file according to aspects of the invention. At 1230, open transactions that were not committed at the time of snapshot creation can be retrieved from memory and applied to the primary database being restored. Next, the database log can be retrieved at 1240 and applied to the recovered database to further advance the database closer to the event that needs to be recovered so that as many " good" business.

Turning now to FIG. 13, a data recovery method 1300 is described in accordance with an aspect of the present invention. At 1310, a database snapshot is created and maintained. Database snapshots can be created by users at any time. Additionally, more than one snapshot can be created, thus providing multiple version points over time. Snapshot databases can also be created automatically. For example, a monitor component can observe actions on a source or primary database, and detect and/or infer actions that may significantly alter the database. For example, a snapshot can be automatically created when a new application installation is detected. According to an aspect of the invention, a database snapshot may store changes to a source database. Therefore, maintaining a database snapshot corresponds to replicating changes to it. According to another aspect of the invention, snapshots may contain sparse files, storing only changes to corresponding pages, and sharing all other data with the primary database. At 1320, the database can be restored to the previous point in time marked by the snapshot when an event occurs including but not limited to a user error (such as quick finger deletion). In particular, restore or recovery may involve copying pages from the snapshot database to pages in the primary database, truncating the primary database, applying uncommitted open transactions to the database at the Information is applied to the main database to focus on events.

Example operating environment

In order to provide context with respect to aspects of the invention, FIG. 14 and the following discussion are intended to provide a brief general description of a suitable computing environment in which aspects of the invention may be implemented. Although the invention has been described above in the general context of computer-executable instructions of a computer program running on one and/or more computers, those skilled in the art will recognize that the invention can also be combined with other programs module to achieve. Generally, program modules include routines, programs, components, data structures, etc. that perform particular tasks and/or implement particular abstract data types. In addition, those skilled in the art will recognize that the methods of the present invention may be implemented with other computer system configurations, including single-processor or multi-processor computer systems, miniature computing devices, mainframes, as well as personal computers, handheld computing devices, based Microprocessor's or programmable consumer electronics, etc. The illustrated aspects of the invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. However, some, if not all, aspects of the invention can be implemented on stand-alone computers. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

Referring to FIG. 14 , an exemplary environment 1410 for implementing aspects of the invention includes a computer 1412 . Computer 1412 includes a processing unit 1414 , a system memory 1416 and a system bus 1418 . System bus 1418 connects system components, including but not limited to system memory 1416 , to processing unit 1414 . Processing unit 1414 may be any of a variety of available processors. Dual microprocessors and other multiprocessor architectures may also be used as processing unit 1414 .

The system bus 1418 can be one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus or external bus, and/or a local bus using any of a variety of available bus architectures. Buses, which include, but are not limited to, 11-bit buses, Industry Standard Architecture (ISA), Micro Channel Architecture (MCA), Extended ISA (EISA), Intelligent Drive Electronics (IDE), VESA Local Bus (VLB), Peripheral Component Interconnect (PCI), Universal Serial Bus (USB), Advanced Graphics Port (AGP), Personal Computer Memory Card International Association bus (PCMCIA), and Small Computer System Interface (SCSI).

System memory 1416 includes volatile memory 1420 and nonvolatile memory 1422 . A basic input/output system (BIOS), which contains the basic routines used to transfer information between elements within the computer 1412 , such as during startup, is stored in non-volatile memory 1422 . By way of illustration and not limitation, nonvolatile memory 1422 may include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable ROM (EEPROM), or flash memory. Volatile memory 1420 includes random access memory (RAM), which acts as external cache memory. By way of illustration and not limitation, RAM is available in many forms such as Synchronous RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced SDRAM (ESDRAM), Synchronous Chain way DRAM (SLDRAM), and direct memory bus RAM (DRRAM).

Computer 1412 also includes removable/non-removable, volatile/nonvolatile computer storage media. FIG. 14 shows disk storage 1412, for example. Disk storage 1412 includes, but is not limited to, devices such as magnetic disk drives, floppy disk drives, tape drives, Jaz drives, Zip drives, LS-100 drives, flash memory cards, or memory sticks. In addition, disk storage 1424 may include storage media alone or in combination with other storage media, including but not limited to optical disk drives, such as compact disk ROM devices (CD-ROMs), CD recordable drives (CD-R drives), CD recordable drives (CD-R drives), Rewrite drive (CD-RW drive) or Digital Versatile Disk ROM drive (DVD-ROM). To facilitate the connection of disk storage device 1424 to system bus 1418, a removable or non-removable interface, such as interface 1426, is typically used.

It should be appreciated that FIG. 14 depicts software that acts as an intermediary between a user and the basic computer resources described in a suitable operating environment 1410 . Such software includes an operating system 1428 . An operating system 1428 may be stored in disk storage 1424 and is used to control and allocate resources of computer system 1412 . System applications 1430 take advantage of the management of resources by operating system 1428 through program modules 1432 and program data 1434 stored in system memory 1416 or disk storage 1424 . In addition, it should be appreciated that the invention can be implemented with various operating systems or combinations of operating systems.

A user enters commands or information into computer 1412 through input device 1436 . Input devices 1436 include, but are not limited to, pointing devices (eg, mouse, trackball, stylus, touch pad, touch screen), keyboard, microphone, joystick, game pad, satellite dish, scanner, TV tuner card, digital camera, digital video recorder, network camera, etc. These and other input devices are connected to processing unit 1414 through system bus 1418 by interface port 1438 . Interface ports 1438 include, for example, serial ports, parallel ports, game ports, and universal serial bus (USB). Output devices 1440 use some of the same types of ports as input devices 1436 . Thus, for example, a USB port may be used to provide input to the computer 1412 and to output information from the computer 1412 to the output device 1440 . An output adapter 1442 is provided to illustrate that there are certain output devices 1440 like monitors, speakers and printers and other output devices 1440 that require special adapters. Output adapters 1442 include, by way of illustration and not limitation, video and sound cards that provide a means of connection between output devices 1440 and system bus 1418 . It should be noted that other devices and/or device systems, such as remote computer 1444, provide input as well as output capabilities.

Computer 1412 can operate in a networked environment using logical connections to one or more remote computers, such as remote computer 1444 . Remote computer 1444 may be a personal computer, server, router, network PC, workstation, microprocessor-based device, peer-to-peer device, or other common network node, etc., which typically includes many or all of the elements described above with respect to computer 1412 . For simplicity, only memory storage device 1446 is shown with remote computer 1444 . Remote computer 1444 is logically connected to computer 1412 through network interface 1448 and then physically connected through communication link 1450 . Network interface 1448 includes communication networks such as local network (LAN) and wide area network (WAN). LAN technologies include Fiber Distributed Data Interface (FDDI), Copper Distributed Data Interface (CDDI), Ethernet/IEEE 802.3, Token Ring/IEEE 802.5, and more. WAN technologies include, but are not limited to, point-to-point links, circuit switched networks like Integrated Services Digital Networks (ISDN) and variations thereof, packet switched networks, and Digital Subscriber Lines (DSL).

Communications connection 1450 refers to the hardware/software used to connect network interface 1448 to bus 1418 . While communication link 1450 is shown internal to computer 1412 for clarity of illustration, it could also be external to computer 1412 . The hardware/software required to connect to network interface 1448 includes (for example only) internal and external technologies such as modems (including conventional telephone grade modems, cable modems, DSL modems, power modems, ISDN adapters, and Ethernet cards.

FIG. 15 is a functional block diagram of an example computing environment 1500 that can interact with the present invention. System 1500 includes one or more clients 1510 . Client 1510 can be hardware and/or software (eg, thread, process, computing device). System 1500 also includes one or more servers 1530 . Server 1530 can also be hardware and/or software (eg, thread, process, computing device). Servers 1530 may house threads to perform transformations as by using the present invention. One possible communication between client 1510 and server 1530 may be in the form of data packets suitable for transfer between two or more computer processes. System 1500 includes a communications framework 1550 that can be used to facilitate communications between clients 1510 and servers 1530 . Client 1510 is operatively connected to one or more client data stores 1560 for storing information local to client 1510 . Likewise, server 1530 may be operatively connected to one or more server data stores 1540 that may be used to store information local to server 1530 .

What has been described above includes examples of the present invention. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the present invention, but those of ordinary skill in the art will recognize that many other combinations and permutations of the present invention are possible. Accordingly, the present invention is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims. Furthermore, where the term "comprises or has" is used in the detailed description or in the claims, such terms should be inclusive like the term "comprises" as if "comprising" is used as a transition word in the claims as explained at the time.

Claims (19)

1. data recovery system comprises:

One snapshot assembly is suitable for generating snapshot database according to source database, and wherein, said snapshot database holds sparse file, and said sparse file stores because the data that the modification of said source database is replaced;

One recovery component is suitable for through the snapshot database file copy is returned to incident before time point to utilize said snapshot database with said source database to relevant source database files; And

One directory component, whether the page or leaf that is suitable for following the tracks of in the said snapshot database is shared with source database, still has been copied to said snapshot database.

2. the system of claim 1 is characterized in that, said incident is corresponding to user error.

3. system as claimed in claim 2 is characterized in that, said recovery component comprises a reduction assembly, and it copies to said source database with said snapshot data database data.

4. system as claimed in claim 3 is characterized in that, said recovery component comprises cancels assembly, and it is stored in the affairs of opening between the startup stage of snapshot database, and adds it to recovered source database.

5. system as claimed in claim 4 is characterized in that, the said assembly of cancelling utilizes database log file to concentrate on said mistake.

6. the system of claim 1 is characterized in that, said snapshot assembly comprises a monitor assemblies, it observes said source database, and when having taken place maybe said source database be modified to the incident of specific degrees, starts snapshot creation.

7. the system of claim 1 is characterized in that, said recovery component is side by side upgraded and synchronous one or more mirror database automatically and with the recovery of said source database.

8. the system of claim 1 is characterized in that, the original value of the said source database files of sparse file representative before change of said snapshot database.

9. system as claimed in claim 8 is characterized in that, said snapshot database and said source database are shared the data that since said snapshot database is created, just do not had change.

10. data reconstruction method comprises:

Create the snapshot of the source database at a time point place;

The data that will be created office's displacement of submitting to after the said snapshot copy to the sparse file of snapshot database; And

When incident occurs; The state of said source database when creating said snapshot to revert to through copying to corresponding source database page or leaf from the page or leaf of sparse file; Wherein a directory component is used to confirm that which data is shared between source database and snapshot database, and which data is unique to said snapshot database.

11. method as claimed in claim 10 is characterized in that, said incident is a user error.

12. method as claimed in claim 11 is characterized in that, the state that reverts to said source database when creating said snapshot utilizes graphic user interface to start by the data base administrator.

13. method as claimed in claim 10 is characterized in that, also comprises the affairs that seizure is not submitted to when creating said snapshot.

14. method as claimed in claim 13 is characterized in that, also comprises the said transactional applications of not submitting in said source database.

15. method as claimed in claim 14; It is characterized in that, also comprise the searching database daily record, and said daily record is applied to said source database; So that involve in said source database, thereby be reflected in the variation that said source database before appears in said incident along the time.

16. method as claimed in claim 10 is characterized in that, also comprises automatically when said source database reduction, upgrades one or more mirror databases automatically.

17. method as claimed in claim 10 is characterized in that, said impinging upon soon when detecting the incident that possibly significantly change database created automatically.

18. method as claimed in claim 17 is characterized in that, the said installation that possibly significantly change the incident of database corresponding to new application program.

19. method as claimed in claim 10 is characterized in that, the structure of said source database when said sparse file representes to create said snapshot.

Images