DE10297001B4 - Information reproduction system with improved error detection and reconstruction - Google Patents

Abstract

An information recovery system (100) includes configurable data volume replicas (110) that may be examined for improved error detection and correction. An information recovery system also provides for the establishment of partial database replicas, such as one or more selected table spaces. With this arrangement, a user can select recovery table spaces from a reproduction of an original database.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation-in-part of U.S. Patent Application Serial No. 09 / 894,422 filed June 28, 2001, which is incorporated herein by reference.

DECLARATION ON FEDERALLY FUNDED RESEARCH

Not applicable.

FIELD OF THE INVENTION

The present invention relates generally to data storage and, more particularly, to data reproduction systems.

BACKGROUND OF THE INVENTION

The US 5889935 A discloses a data storage system with a remote copy control method.

Next discloses the US 6145088 A an apparatus and method for remotely recovering inaccessible data on computer storage devices.

In addition, reference is made to the state of the art, which can be found in the article of the C't magazine for computer technology: "Bögeholz, Harald, Siering, Peter. With the Disk Editor on Data Search ", Hannover: Heise, 2000, Vol. 6, pp. 116-129.

As known in the art, computer systems that process and store large amounts of data typically include one or more processors in conjunction with a shared data storage system in which the data is stored. The data storage system may include one or more storage devices, such as disk drives. To minimize data loss, computer systems may also include a backup storage system or backup storage system in conjunction with the primary processor and the data storage system.

Known spare memory systems may include a backup storage device (eg, a tape storage or any other storage mechanism) along with a system for injecting the data into the storage device and for retrieving the data from the storage device. To perform a backup, the host copies data from the shared data storage system over the network to the backup storage system. Thus, an actual file can be transferred over the network to the backup storage device or backup storage system.

The shared storage system corresponds to the actual physical storage. For the host to write the reserve data over the network into the spare memory system, it first converts the backup data into file data, i. H. the host takes the data from the physical storage system level and converts the data to the application level format (e.g., a file) through a level of a logical volume manager, a file system level, and the user level. When the backup storage device receives the data file, then the backup storage system may pick up the file at the user level and convert it to its appropriate reserve storage system format. If the backup storage system is a tape storage device, then the data is converted to a serial format of blocks or segments.

The EMC Data Manager (EDM) is able to perform such backup and reconstruction over a data network as described in numerous publications available from EMC, Hopkinton, Massachusetts, including the EDM user manual (network) "Basic EDM Product Manual ". An example of a known back-up memory architecture in which a direct connection is made between the shared memory system and the backup memory system is disclosed in US Pat U.S. Patent 6,047,294 which is assigned to the assignee of the present invention and entitled "Logical Restore from a Physical Backup to Computer Storage System", which patent is incorporated herein by reference.

For large databases, tape-based data backup and reconstruction systems can be used, which are well known in the art. In general, files, databases and the like are copied onto the tape medium at certain times. Typically, a periodic backup or periodic backup of the data is performed to prevent the loss of data due to software errors, human errors, and hardware failures. For example, upon detection of an error in an online database, the data held in reserve may be reconstructed to retrieve the data. While the reconstruction refers to the recovery of the data held in reserve, data reconstruction refers to the entire process in which applications can access and use the recovered data. Transactions since the time of the reserve pose can be carried out again, whereby so-called repetition entries are used.

Tape storage backup and reconstruction systems have a number of disadvantages. Due to the considerable amount of time and effort involved in reserving and reconstructing data on the tape, such operations are performed relatively little frequently. The longer the time between the reserve posture and the reconstruction, the more complicated and time consuming the entire retrieval process becomes, for example because it makes it harder to determine the point at which an error has occurred. In addition, improvements in the data recovery process, for example, result in faster tape access times, only small advances in the overall data recovery process.

Further, data on a tape can not be accessed until re-established on a disk. Only when the data is stored again can a host computer check the data. The data must be reformatted for each transition between the tape and the disk, which means considerable processing overhead and time loss.

Another disadvantage associated with tape-based data storage systems relates to the data recovery process itself. For example, after an error has occurred, an operator, such as a database administrator, assesses the error in an attempt to find a way to correct the error. However, the administrator must be aware of the limitations imposed by the nature of storage on a tape. For a database critical to large tasks, it may be unacceptably expensive to shut down the database and perform tape recovery and restore. If at all possible, the administrator will attempt to repair the database. However, the dangers of destroying the entire database leading to additional errors and the possibility of not being able to cure the error are considerable.

In addition, it is not always known at what time the database has become corrupted. In the case where data is recovered from the tape and re-stored, the correction of the error may be a repetitive and time-consuming process. The administrator can select a first set of tapes for recovery, after which the database is examined to see if the error is corrected. If not, then another set of bands must be used for recovery, which typically corresponds to a previous reserve maintenance action. The data analysis steps are then performed until the error is corrected.

Once the error has been corrected, the error can be re-introduced into the database when later spare hold transfers from repeat entries are added to the database. The point at which the error occurs must be identified. The time and effort involved in repetitive tape repairs and fault identification can be significant.

One known approach to identifying errors involves the so-called data cleansing tools. These tools, which can run periodically, are used in an effort to discover bugs as soon as possible. While such tools or tools may discover errors, many production databases, such as those used by sellers on the Internet, are critical to their job and can not handle the burden required of such tools. In many applications, data cleansing tools and data cleansing tools are not a practically selectable option.

In addition, there are times when it is desirable to restore only a portion of a database. However, known systems do not readily allow recovery of less than the entire database. While recovering a portion of a database may be possible in systems with conventional data retention and data recovery, a high degree of skill is required to manually restore a portion of a database. It is therefore desirable to overcome the disadvantages discussed above and other disadvantages.

SUMMARY OF THE INVENTION

The object of the invention is to specify an improved method for finding and correcting errors in a data volume of a production database.

The present invention provides a data recovery system with configurable copying of data volumes, which system significantly improves error detection and correction compared to conventional data backup systems. While the invention has been shown and described primarily in terms of database recovery, it is to be understood that the invention is applicable to other systems which it is desired to detect and eliminate errors in stored data.

According to one aspect of the invention, an information retrieval system copies an original data volume or volumes of original data to examine the integrity of the copied data volumes or original data volumes. If an error is detected, the system can be used to correct the error through repair and / or data recovery. After successful error detection, the data volumes that still contain the error can then be corrected.

In another aspect of the invention, an information recovery system effects the establishment of partial database copies, for example, a selected one or more selected table spaces. With this arrangement, a user can select recovery tables from a copy of an original database. In one embodiment, the partial device may be started in a variety of ways.

In accordance with another aspect of the invention, an information recovery system effects the automatic selection of copy storage. With this arrangement, the information recovery system automatically searches for possible storage spaces that can be used to replicate an existing volume of data, such as a database, and selects storage to meet predetermined requirements to avoid the need for a database administrator to manually identify the storage , While the invention is shown and described primarily in connection with the copying of databases on disks, such as Oracle databases, it will be understood that the invention is generally applicable to memory systems in which it is desirable to maintain a reserve of digital information various copy technologies or replication technologies for subsequent recovery.

In one embodiment, an IR server obtains a list of possible copy storage locations, such as BCVs, production data volumes, for example, standard volumes from which a replica or copy has been desired. A user may dictate that certain BCVs have prescribed criteria, such as BCV storage previously configured by the user. The system then selects possible BCV's for each standard volume and assesses each pair of standard volumes BCV. In one embodiment, a rating of the pair is determined based on the level of workload such as disk drive spindle, bus, etc. for the standard volume BCV pair. The resources may be weighted to reflect the level of performance degradation due to resource usage. A group score is determined from the ratings of the pairs for judging whether an acceptable storage solution is found.

It should be understood that a particular terminology such as BCV, standard volume, and other terms may be used to facilitate understanding of the invention, and yet, it is not intended to limit the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will be more fully understood from the following detailed description taken in conjunction with the accompanying drawings, in which:

1 a schematic diagram of an information recovery system according to the present invention;

2 a diagrammatic representation of an example of a screen for the system of 1 is;

3 a diagrammatic representation of another example of a screen for the system of 1 shows;

4 is a schematic block diagram of a data storage network that is part of the system of 1 can form;

5 a schematic representation shows, which reveals further details of a data storage network;

6 Fig. 10 is a flowchart showing an example sequence of steps for recording logical versus physical storage volumes for backup or reserve maintenance and recovery in an information recovery system in accordance with the present invention;

7 Fig. 10 is a flow chart of an exemplary sequence of steps for recording and retrieving storage volume information in an information retrieval system in accordance with the present invention;

8th Figure 5 is a flowchart showing an example sequence of steps for generating a tree structure of storage volume information found for an information retrieval system according to the present invention;

9 Fig. 10 is a flowchart showing an example sequence of steps for setting up and distributing mirrors in an information retrieval system according to the present invention;

10 Fig. 10 is a flowchart showing an example sequence of steps for the construction / establishment of logical information in an information retrieval system according to the present invention;

11 Fig. 10 is a flow chart depicting an example sequence of steps for backup or reserve storage of data volumes in an information retrieval system in accordance with the present invention;

12 Fig. 10 is a flow chart illustrating an example sequence of steps for recovering data volumes in an information retrieval system in accordance with the present invention;

13 Figure 5 is a flow chart showing an example sequence of memory volume reduction / clearing steps in an information recovery system in accordance with the present invention;

14 Figure 12 is a perspective view of the generation of storage volume check points over time in an information recovery system in accordance with the present invention;

15 Figure 12 is a perspective illustration of the detection and correction of errors in a data volume in an information recovery system according to the present invention;

16 Figure 12 is a perspective view of an exemplary flexible architecture for an information recovery system according to the present invention;

17 Figure 12 shows a schematic representation of an information recovery system with partial database replication installation according to the present invention;

18 Figure 12 is a further schematic representation of an information recovery system incorporating partial database replication on a destination device host in accordance with the present invention; and

19 Figure 5 is a flow chart showing an example sequence of steps for establishing a partially reproduced database according to the present invention.

DETAILED DESCRIPTION OF THE INVENTION

In general, the information recovery system of the present invention provides users with the ability to make replicas of logical objects, such as databases and mailing systems, and to instantly restore the reproduced objects; H. as fast as the underlying storage technology allows it. While the invention is shown and described primarily in connection with exemplary memory technology known as "Symmetrix" from EMC Corporation, Hopkinton, Massachusetts, it will be understood that the first connection is applicable to a variety of memory technologies and operating systems , In a particular embodiment, the information recovery system targets various databases, such as Oracle and SQL Server databases. The system allows users to reconfigure a database or part of it, for example, a table space or multiple table spaces for replication. The configured part of the database is called the Reproduction Object (RO). That is, the reproduction object (RO) describes the application to be reproduced. For each RO, describe an activity or describe several activities on how to reproduce the reproductive object. For example, information includes how to interact with the database, such as online or offline, before enrollment or enrollment, installation and recovery options, and memory selection criteria. The activities may be scheduled as required or for predetermined times. Installation details such as where and how can be defined during the generation of the activity.

Storage for the activity may be selected by the system in a variety of ways. For example, the system may look for free or previously established business continuation storage volumes (BCVs). As used herein, business continuation storage volumes or BCVs refer to a level of a standard volume as part of the database. Also, users can define attributes to BCVs to form storage pools and to choose storage according to attributes in the activity. The user can also explicitly assign BCVs to standard devices (STDs).

1 shows an example of an information recovery system 100 according to the present invention. An IR server 102 which has a permanent memory 104 contains, handles activity requests from IR users of desktop devices 108 , A network server 102 forms an interface to a local area network (LAN) 106 For example, to connect to the user desktop devices 108 to allow which a user interface, for example a browser 108 and / or a command line interface (CLI) 108b , and an IR application 108c can contain. The IR server 102 can also have an IR Reproduction Policy Manager 102b within an IR daemon 102c for the control and coordination of reprocessing activity for the storage units 110a within a storage area network (SAN) 110 contained, which are visible for the respective application hosts. The IR server 102 can be a reproduction policy manager or a replication engine 102b for each established reproduction technology to realize decisions concerning the question of which memory is used for a given reproduction. In one embodiment, the process engine or policy engine 102b as a dynamic library associated with the IR daemon. Static status information about existing productions and the corresponding memory are in the IR database 104 stored, which may be provided as a SQL server database.

The system 100 also contains application hosts 112 For example, Oracle database server hosts that have an application agent 112b under customer control 112a and a storage service module 112c , The application agent 112b in the IR application customer units, user databases that are located in the storage area network are processed 110 are located. The named customer control module 112a can be daemoned and handles customer operations and outputs them. The application agents 112 For example, one-piece units for each feasible application, handling work requests. The IR application customers 112 may also communicate with third party vendors, for example via paging, to use a third party product to provide a replica of the user database to a backup or backup. It should be understood that hosts used to establish replicas include the application hosts 112 could be.

While three separate hosts are shown herein, it will be understood that one or more users, an application customer or multiple application customers, and an IR server or multiple IR servers may reside on a single host or machine. It is further understood that the illustrated embodiments, architectures, and configurations may be readily modified by those skilled in the art to meet the needs of a particular application without departing from the spirit of the invention.

2 shows an exemplary screen 150 an IR control panel for an information recovery system according to the present invention. The screen 150 can be a hierarchy of objects 152 in the IR system, such as users, application hosts, applications, memory, the schedule, and replication objects (RO's). In the example representation, a reproduction object named "Parts DB / TS1 / TS2" is shown. 154 fanned out the activities 156 and the cases 158 to show this reproduction. The activities include the entry 160a "Create CKP on Jupiter", the entry 160b "Disaster CKP" and the entry 160c "Regularly on schedule". The cases 158 show the checkpoints or replicas that were generated for the replica object.

In general, the hosts and applications for the system become visible after setup. When the hosts and applications are set up, they are registered in the IR daemon database.

3 shows an exemplary screen 200 to create new reproduction objects (RO's). To create new reproduction objects, the user activates a download menu and selects "File", "New" and "Reproduction Object" for the new screen 200 to reach for the reproductive objects. The user then specifies the application host in the application host field 202a and the application in the application field 202b for configuration based on information from the IR daemon database of established application hosts. For a given host and a given application, each case of the application can be in the case field 202c be reproduced. The user selects a case and assigns a name to the new reproduction object in the name field 202d to.

Additional screens (not shown) may ask the user for additional information. For example, another screen may prompt the user to submit application-specific information about the reproduction object, such as how to access the database (username and password), as well as which parts of the database Database, such as the entire database, table spaces for an Oracle database, etc. Another screen allows the user to create activities for the reproduction object. There are many activities that can run individually or on schedule for specific times. More specifically, an activity can create replicas on a regular schedule, can create a decision-supporting database, and can carry a disaster recovery.

In one embodiment, a replica or checkpoint has an expiration time, i. h., a time over which the reproduction remains valid. The user can specify whether it is assumed that the checkpoint (reproduced database) is set up. This information may be needed when selecting a reproduction technology (RT), as not all reproduction technologies allow for settable copies of the verification point. When making the storage selection, the user may choose a reproduction technology or may allow the system to choose the reproduction technology as mentioned above.

Additionally, for each activity, the user may provide attributes that are descriptive of the device, storage, and application. Setup attributes define what should happen to the object when it is set up, such as restoring the database, running a test program, and making a tape backup. Memory attributes determine which memory to use to make the replication. Application attributes determine when the replication is made and what application-specific things need to be done, such as putting the database into online reserve mode and using a user prompt to turn off the database.

Selecting the Reproduction Object setup options allows the user to specify things to be done after a replica is made. The same set of options can be presented to the user when the user manually selects the establishment of a reproduction. An option that the user has is whether the reproduction is set up and restored and where it is made visible. Running an activity may involve setting up the reproduction, which will be fully or partially established.

After choosing how to set up the application, the user can choose what to do with the application, for example by choosing which program to run, running a reserve, and setting up the application after completion. Multiple programs or reserve frames can be selected for execution. Dismantling involves shutting down the application and removing any memory references that have been created to make the replication visible in the target operating system.

The storage can be made explicit to the IR system, either by assigning attributes to the storage or by explicitly assigning standards to the reproduction storage. In a particular embodiment, in the screen for defining attributes of the storage, the user is presented with a list of BCVs which can be found in the data storage device, for example Symmetrix, attached to the customer machines. The user can then select one BCV or several BCVs and assign attributes to them.

4 shows further details of an information recovery system 300 with a data storage system 302 according to the present invention. In one embodiment, the data storage system 302 (which is within the storage area network 110 from 1 located) on a Symmetrix Integrated CacheDisk Array System available from EMC Corporation of Hopkinton, Massachusetts. Such a data storage system and its realization is fully in the U.S. Patent 6,101,497 , issued on August 8, 2000, and also in the U.S. Patent 5,206,939 , issued April 27, 1993, both of which are assigned to the company EMC, namely the vision of the present invention, and which are incorporated herein by reference.

Generally speaking, a local volume is reproduced in a work continuation volume (BCV). A local system that uses mirroring and allows access to production volumes while performing the backup or backup recording is also included U.S. Patent 6,101,497 described herein by reference. The data storage system 302 contains a system memory 304 and sets or pluralities of multiple data storage devices or data stores 306a . 306b , In an exemplary embodiment, the system memory includes 304 a buffer or a cache. The storage devices 306 may be disk storage devices or optical storage devices and the like. However, in an exemplary embodiment, the storage devices are disk storage devices. The storage device 306 represents one Group of storage devices in any of a variety of known configurations.

Host adapter (HA) 308a . 308b form the connection between the host system 310a . 310b and the system memory 304 , and Plate Adapter (DA) 312a . 312b form the paths between the system memory 304 and the storage device groups 306a . 306b , A bus 314 connects the system memory 304 , the host adapter 308 and the plate adapters 312 together. Each system memory is used by various elements within the respective systems to transfer information and to effect cooperation between the respective host adapters and disk adapters.

An optional backup storage system or reserve holding system 350 can with the data storage system 302 get connected. The backup storage system may be provided as an EMC Data Manager (EDM) connected to the data storage system as described in the user manual "Symmetrix Connect User Guide, P / N 200-113-591, Rev. C, December 1997", available from EMC Corporation. The direct connection between the shared storage system and the backup storage system may be considered a high-speed data channel 352 be formed, for example as a SCSI cable or as a fiber-optic cable or multiple fiber-optic cable. In this system, the user can be allowed to reserve data over the network or the direct connection.

The backup system 350 includes a backup / recovery server 354 , a logic 356 as part of the server and a storage tape library unit 358 which may include a tape-shaped medium (not shown) and a robotic seeker mechanism (also not shown) as provided in the preferred EDM system.

In general, the data storage system works 302 depending on commands from the host systems 310 over the host adapter 308 , The host adapters 308 transmit commands to a command buffer, which is part of system memory 304 is. The command buffer stores data structures and describes requests that the host adapters produce. The disk adapters or disk adapters 312 respond by performing a corresponding operation using the information in a command buffer. The selected disk adapter then initiates a data operation. Read operations transfer data from the storage devices 306a . 306b to the system memory 304 via a corresponding plate adapter 312a 312b and a subsequent data transfer from the system memory 304 to the appropriate host adapter 308a . 308b if the host system 310 initiated the data write.

It is understood that the computer host systems 310 may be any conventional computer systems, each having an operating system, such as systems available from Sun Microsystems and using the Solaris Operating System (a version of Unix), an HP system running HP-UX (a Hewlett-Packard Customer running a Hewlett-Packard version of the Unix operating system), or an IBM system running the AIX operating system (an IBM version of Unix), or any other system with an associated operating system, for example the WINDOWS NT operating system. The storage system may be any conventional storage system including a Symmetrix storage system as described above.

A brief description of concepts which are helpful in understanding the present invention and known in the art will now be given. A physical disk is formatted into a "physical volume" for use by management software, such as the Logical Volume Manager (LVM) software available from EMC. Each bodily volume is split into individual blocks, which can be described as physical sections or as physical sections. Physical volumes are combined into a "volume group". A volume group is thus a collection of disks treated as a large storage area. A "logical volume" consists of a certain number of physical sections or partial areas which originate from a single volume group. A "file system" refers to a structure or collection of files.

Hereinafter, another convenient terminology will be briefly described, which will be described in more detail by reference to the herein incorporated by reference 497 Patent becomes understandable. When a mirror is set up, the data storage system generates 119 a mirror image (a copy or reproduction) of a source volume or standard volume. When the preferred Symmetrix storage system is used, such a mirror is referred to as a work continuation volume (BCV), also commonly referred to as a mirrored disk, and is referred to herein as a BCV device. If data in the default volume changes, then the same changes are made immediately on the mirrored disk as well.

When a mirror is "split off", the Symmetrix data storage system isolates the mirrored version of the disk and no further changes are made to the mirrored volume. Upon completion of a split, the primary disk may continue to undergo changes, but the mirror retains the dates of the time that existed at the time of the split. Mirrors can be "synchronized" in any direction (ie from the BCV to the standard or vice versa). For example, changes to the standard volume that have occurred after cleaving to the mirror may be made to the BCV volume or the mirrored disk. This brings the mirrored plate in line with the standard volume. When synchronizing in the other direction, the primary disk can be made to match the mirror. This is often the last step during a recovery.

The operation of a BCV device and its corresponding BCV volume or BCV volumes will be easier to understand from data sets stored in logical volume and this will be helpful in understanding the present invention. Any given logical volume may be stored in one part or in the entirety of one physical disk drive or two or more disk drives.

It's up 5 Referenced. In this particular embodiment, operations in a series of physical disks are controlled in logical volume sizes. The segmentation or translation of physical disks into logical volumes is well known in the art. A disk adapter (not shown) forms the interface of the logical volumes 360 to the data storage system bus. Each of these volumes 360 is defined as a work continuation volume and assigned to a BCV device. Each BCV device includes a standard disk controller and associated disk storage devices that are configured to independently support applications and processes. Using these BCV devices allows a host, such as the host 310a , which from now on will be referred to as the "source" host computer system, will instantaneously copy the data into the standard volume 362 to use. In a conventional operation, typically at least one BCV volume is associated with each of the host devices that process a data set simultaneously. However, as explained below, the BCV volumes that are set up for use by one host may be hosted by another host, such as the host 310b which from now on will be referred to as the "target" host computer system.

The source host 310a may continue online transaction processing (eg, database transaction processing) or other processing without any impact or burden on the standard volumes 362 has while their respective mirror images in the BCV's 360 used to maintain a data reserve or a data backup in conjunction with the backup system 302 to set up. However, the BCVs may be essentially automatically set up for use on another host under the control of a computer program without the need for operator intervention all the way.

The direction of data flow for the backup device or backup is from the data storage system 302 to the backup system 350 as by the arrow 364 is indicated. The direction of data flow to recovery goes to the data storage system in the opposite direction, but the BCV's can 360 at another host, which is different from that of the original device according to the method of the present invention.

The optional backup system 350 For example, the EDM system provides several options for controlling mirroring behavior before and after a backup or restore. Mirroring techniques are well known to those skilled in the art. Examples of pre-backup mirroring options include shutting down the mirrors, detecting that the mirrors are shutting down, shutting down the mirrors on demand, and shutting down mirrors after installation; and the options of the mirrors after backup include turning on or off the mirrors, leaving the mirrors in the disabled state, and leaving the mirrors as they are found.

The system generates one or more mirrored copies of data (BCVs), which are copies of one or more volumes of data (standard volume). The BCVs are set up in a conventional manner, as in the one attached here 497 Patent is described. The BCVs are separated or cleaved from the respective volume or volume of data in a conventional manner, as also shown in FIG 497 Patent is given.

The system looks for the logical information related to the default volumes, which is part of the volume group on the source computer system 310a are. A record of the logical information on physical devices in the source computer system is generated. In one embodiment, the record may be written as an XML Message be provided. Alternatively, the record takes the form of a unitary file which can be converted to a tree structure to allow rapid checking of the logical information. This record is used to build a substantially identical logical configuration on the target computer system 310B ; preferably after checking the logical information by using a tree configuration of the logical information.

The logical configuration is to establish a duplicate of the BCVs on the target computer system (referred to as installed target BCVs). The newly established target BCVs then become part of a second volume group on the target computer system 310b ,

Before the data transfer, the backup system performs a number of functions. A discovery / record function causes a search and record of logical items to physical devices on the source host 310a and contains information such as physical volumes and logical volumes, volume groups, and file system information. A set-up / split function sets BCVs or splits them off of default volumes, depending on the pre- and post-mirroring methods used on the source host 310a are effective.

A Build / Install function exports the BCVs that are on the source host 310a are set up to the destination host 310b , It generates volume groups, logical volumes, and file system objects on the target host system.

An optional backup / restore function backs up the destination host BCV data that has been exported or transferred from the source host. The removal / deletion feature removes all volume groups, logical volumes, and file system objects from the destination host.

6 shows an overview of the overall reproduction setup process. In step 400 The system makes a record of logical objects in physical devices on the source host. In step 402 the logic implements a setup and subsequent cleavage of standard volumes in BCVs according to the mirroring process that operates on the source host (which can be accomplished by invoking another function on data storage systems). In step 404 The system makes a setup and installation on the destination host so that the BCVs are exported or transferred to the destination host. The step 408 is a cleanup step where all volume groups, logical volumes, and file system items are removed from the destination server.

7 is an overview of the steps of the recording and search process. In the step 500 At the source host, the search / record process begins. At the source host is in step 502 searched the file system and in step 504 the logical volume is searched. The volume group information is at the source host in step 506 searched. In step 508 For example, the record may be generated as a unitary file or other relatively efficient data structure for the gathering and use of the information.

It is now up 8th Referenced. In one embodiment, in step 600 the retrieved logical volume information, which may correspond to a unit file, used to create a tree structure. This structure can be established by a UNIX function call of information in the log files, as described above. It can be set up on both the destination host system and the source host system. The structure is called a tree because the volume group information is used as the root of the tree and the branches represent the device information within the group and the logical volumes within the group. The tree structure serves in the step 602 to check the accuracy of the recording file before it is sent to the destination host. The tree is recorded in a record preferably as a unit file in the step 604 reshaped. This unified file record will then be in the step 606 sent back to the destination host.

Alternatively, the search is done in a manner similar to that performed by the EMC Data Manager (EDM), which is well known to those skilled in the art. In one embodiment, the record is sent as an XML message.

It's up 9 Referenced. The process of setting up and splitting off at a backup system starts with the step 700 , A mirroring policy, if any, becomes in step 702 checked. In step 704 A request is made to determine if BCVs have been set up according to the mirroring policy. If the answer is "no", then in the step 706 BCV's furnished. The BCVs are taken from the source host in the step 708 cleaved. The BCV's are in the step 710 not prepared for the host.

Now be 10 considered. The process of starting building / installing logical Information such that the BCV's can be installed at the destination host is set in step 800 one. The volume groups are in the step 802 generated on the destination host. Logical volumes will step on the destination host 804 checked. The file system is checked and run on the destination host, which is in step 806 happens. The object installation can now in the step 808 be completed with the logical information relating to the BCVs on the destination host.

As in 11 shown, the rebuilt target BCVs can now optionally be put on reserve hold, which is in step 900 is shown. The application will then be in the step 902 switched off on the destination host. Following the backup of the destination BCV's find in step 904 Cleanup steps and notification steps take place.

If the software application on the destination host and the source host is a database, then the information relating to the data may also be backed up, with the effect that substantially all of the database is reserved or maintained Backup is undergone. Important information from the database includes any transaction data represented by the database operations, as well as associated control files, tablespaces, and archives / repeat entries.

Regarding the databases further terminology is discussed. While terminology is used for an Oracle database, those skilled in the art will recognize that other databases may be used without departing from the spirit of the invention.

Control files contain information about the Oracle database, including information that describes the location where the data files and entry files reside. Data files can be files in the file system of the operating system. A table space is the lowest logical layer of an Oracle data store structure. The table space contains one data file or multiple data files. The tablespace provides the finest subdivision for arranging data over data files.

The database contains archive files that are known as replay entry files or simply as reentry entries. Here is where all the information to recover. be kept. Without the replay entry file, a system failure would make the data unrecoverable. If an enrollment occurs, then the enrollment records in the filled replay enrollment file are copied to an archive enrollment file if archival is possible.

It is now 12 considered. Here, as shown, begins the process for recovering source standard volumes in the step 1000 for the optional backup system. In step 1002 The system makes a request to determine whether the recovery should be from the BCV's on the target host or from somewhere else. According to the answer, the standard volumes of the BCV's set up on the destination host or the tape, for example, in the steps 1004 respectively. 1006 synchronized. With the step 1008 begin the notification and cleanup steps, which are generally in 11 are indicated.

As in 13 shown starts in the step 1100 the cleanup / dismantling process. The BCV's are in step 1102 removed from the target host. This can be achieved, for example, with a UNIX removal command. The items related to a volume group, logical volumes, and file systems will be out of the destination host in the steps 1104 and 1106 away. The clearing or the deletion becomes in the step 1108 completed. The BCVs are rebuilt in the source host (ie, made ready for the host), which in step 1110 happens.

14 FIG. 12 shows an example of a checklist or reproduction schedule for an information recovery system according to the present invention. FIG. At about 8:00, a standard volume STD, which may, for example, contain an Oracle database, is reproduced on a corresponding BCV, CHKP A, as described in detail above. At 12:00, the next scheduled test time occurs at which the standard volume is reproduced on another BCV, CHKP B. At about 1:00 an error is detected, such as a data cleansing tool, so that at about 2:00, after a certain assessment period, the default volume is reproduced on a Demand BCV, CHKP OD. The 4:00 exam time to the next BCV, CHKP C may be scheduled, provided the error is corrected and the default volume STD is current. Further on-demand inspection points may be provided as desired, as described above.

15 shows an example process of recovering from a data error, such as a transaction error in a database according to the present invention. A data error occurs at a time T _e , after which the system continues to run for a time TLE while the error is hidden, ie unknown to the system operator, for example the database administrator. As is well known to those skilled in the art, For example, the errors may have a variety of causes, including software errors, hardware errors and / or failures, as well as human error.

In one embodiment, a data volume replica, such as a copy of the database, resides on a disk as a BCV installed on a remote host and reviewed with so-called data cleanup tools. Data cleansing tools for studying data integrity are well known to those skilled in the art. For example, while it will be understood that a variety of data cleaning tools may be used to assess the integrity of the replicas, a suitable data cleaning tool may be obtained from the patrol family of BMC Software of Redwood Shores, California. Since the data according to the present invention is now stored on disk, data cleansing can significantly reduce the time of concealment of the error, i. that is, the time during which errors go undetected.

In contrast, in many conventional systems, the error is not detected until a person, such as a customer, addresses the database operator, for example, with regard to an irregularity in the customer's account. As is known to those skilled in the art, data stored on tape can not be checked without data rewrite and recovery.

After confirming that an error has occurred, a time TEE elapses in which the error is assessed to determine possible corrective actions. For example, an operator or an operator may judge the nature of the error, may judge how the error has occurred, how common the error is, what the effect of the error is, when the error has occurred, and how the error can be corrected. The level of experience of the operator, for example the database administrator, greatly determines the time needed to assess the error.

During error assessment, the system may generate a database replica copy for setup on a different host. This allows multiple assessments to be conducted in parallel by one or more review teams. In addition, destructive investigations can be performed on other hosts as the production database is available for further reproductions.

After assessing the error, an operator generally decides to correct the error during a TCE. The operator can re-establish backup data (from the checkpoint) or can try to repair the production database. By creating another replica before attempting repair, the operator can make a free trial to repair the live database. This means that the operator can undertake repair attempts with risky "shot in the dark" as multiple checkpoint backup data exists. In the case where the operator's attempt to solve the problem can not make the repair of the error or make the error worse, the backup data from a checkpoint can be easily restored, established, and updated from the retry entries. Another copy of the database can be used to try additional possible solutions. Alternatively, solutions may be attempted on a copy of the database prior to modifying the production database.

If a rebuild device is given a default against repair, then the user must decide which backup data to re-save. Ideally, this is the most recent backup against database corruption. If the exact time at which the error occurred is not known, then the user must estimate what backup data should be restored.

In known systems, the user had to reset from the selected backup data. Upon completion of the re-setup, which may be many hours later, the user may check to see if the selected backup data is free from corruption. If this is not the case, then the user must make a further recovery of further backup data. Such multiple restores or redispersions are made unnecessary by the IR system of the present invention because the user can install the selected backup data on a different host and examine this backup data for errors. Once error-free backup data is found, a single rebuild can be done.

In many known systems, the so-called surgical repair of the production database is the preferred option due to the time and effort involved in restoring the data from the belt. For relatively large databases, for example, more than a terabyte, data recovery from the tape can take many hours. Additionally, for certain critical task databases, surgical repair is virtually the only option given the tremendous costs associated with shutting down a database. The However, the associated risks of damaging such a database in the attempt to repair an error are readily apparent.

After a time TRF to retry the checkpoint data, the forward scrolling process attempts to update the database with transactions that have occurred since the copy of the database was frozen and which are recorded in the retry entry RL. The forward scrolling process repeats because the database should be inspected for errors while the recorded transactions are being entered into the database. Incremental forward scrolling or forward scrolling can update the database at certain points. If an error is detected, the forward scrolling process must only run back to the last error-free point. Conventional storage-tape-based systems offer this capability because of the incompatible formats between tape and disk.

It is understood that an operator can easily vary the particular error detection and correction steps depending on the requirements of a particular application. For example, checkpoints may be generated on a variable schedule and as needed for use in finding an error correction solution.

16 For example, Fig. 1 shows an architecture of an information recovery system that flexibly operates a variety of application agents, operating systems, and reproduction technologies. In general, an IR core communicates with a graphical user interface (GUI) or command line interface (CLI) via an application programming interface (API) to enable information reconstruction. Different application agents A, B and C communicate with the IR core via a corporate application API. The IR core can work with many customer operating systems and reproduction technologies. Separating applications and replication technologies with a common interface to the core enables the delivery of new applications and reproduction technologies without changing the core. For example, new reproduction technologies, including new hardware, new host-based productions, and / or third-party copies, such as SCSIXCOPY devices, can be easily added. New databases and applications can also be easily added, including new file systems, new relationship database management systems (RDBMS) and new financial applications and e-mail applications. New user interfaces, new font formulas, and new host platforms can also be easily maintained.

In another aspect of the invention, a portion of a database replica may be incorporated into a host computer. While the invention is described only in conjunction with tablespaces in an Oracle database, it is to be understood that the invention is applicable to other types of databases and database components. In addition, it will be understood that the Oracle terms are used to facilitate the understanding of the invention, but it is not intended to derive any limitation of the invention to any particular type of database or configuration.

The 17 and 18 which bears some resemblance to 1 have an example of an IR system 1200 with the installation of a reproduction of a database part according to the present invention. The IR server 1202 contains an IR daemon 1204 to handle replication requests from host computers, such as IR users 1206 , IR application customers 1208 work as a database server DBS ( 18 ) for applications, such as Oracle databases, which are stored in volume groups VGS in the storage area network SAN. An IR user 1206 or a facility host MH ( 18 ) has view of a reproduced database RDB, which has been reproduced from an original database ODB.

In the illustrated embodiment, the production database or original database ODB is located in a storage area network SAN and runs on the database server host DBS. The original database ODB contains a first, a second and a third table space TS1, TS2, TS3 together with the system information SYS. The reproduction database RDB of the original database ODB also contains corresponding table spaces TS1R, TS2R, TS3R and the system information SYSR. The generation of database replication has been described in detail above. The replica database ODB is for an IR user, for example, the deployment host MH ( 18 ) visible, noticeable. It should be understood that the device host MH and the database server DBS are substantially the same, for example running on the same operating system, etc

As described above, the IR daemon is running 1204 on the IR server 1202 , The reproduction information, for example, record files, is in the IR database 1210 contain. The IR database has the information needed to install and start a replica. This information is obtained during the creation of the reproduction, as also described above.

The customer control module or daemon 1212 ( 17 ) runs on the database server DBS and the device host MH. The customer Control module running on the device host receives the data volume log file along with other necessary information from the IR server 1202 to set up the reproduction database RDB.

In general, the system may run a partially-replicated database, such as table spaces, selected by a user in the manner described above in a variety of ways. For example, the operator may select the first table space TS1 for start so that the second and third table spaces TS2, TS3 are disregarded. After setup, the first table space TS1 is available for use by an operator.

In one embodiment, a partially reproduced database, such as the first table space TS1, in a recovered mode, in a recovered mode may be designed for reading only and in a non-recovery mode, as described below. Other modes for meeting the requirements of a particular application will be readily apparent to those skilled in the art.

19 Figure 4 shows an example sequence of steps for starting a reproduction of a part of a database according to the present invention. In the step 1300 the setup host of the replica database recording site will retrieve from the IR database via the IR server. A database server for controlling the reproduced database is then in step 1302 created in the facility host. Creating the database server may include, for example, importing volume groups, starting volumes, and setting up file systems. In the step 1303 The system copies the appropriate backup control file and archive entries, the init <sid> file, and the password file to the required location in the deployment host. In the step 1304 For example, the database in question, such as the Oracle replicated database, is incorporated into the destination host as described in detail above. It is understood that the replication can be incorporated into a target host in which the reproduced database does not already exist. This means that the system expects the install host to have the Oracle application installed and that the object to be installed is not already running on the host.

In one embodiment, the customer tax daemon application layer receives a record or tree file describing what to recover. The original tree is created during the reproduction of the application and is stored in the IRD catalog / database on the IR server. This record is made available to the customer control running on the setup host. The tree contains what needs to be set up and is built on user requirements. Thus, the user selects a partial tree from the original tree. This partial tree is compared to the original tree, which describes what is contained in the reproduction database. This allows the customer control daemon to set those table spaces, such as TS2 and TS3, which do not need to be restored. The entry files can be copied over to the target host as well as other information files, for example, for Oracle applications, the initinstance.ora file and two backup control files (one read-only and one regular-version version).

To start in recovery mode, in the step 1306 Renamed the database volume groups and / or raw items against the original host names to new names in the destination setup host. For example, Oracle statements are run to make the name changes to the Oracle database. It is understood that the password file is transferred from the IR database for reproduction. In one embodiment, the backup control files are automatically copied from the location where the true control files are suspected to be ready for use by Oracle. The backup control files are copied to the archive entry directory on the deployment host. The control files are copied to the locations as described by the init <SID> .ora file of the application host for Oracle applications at the time of the replication. The description of this place is actually cataloged at the time of reproduction, for example, by questioning the database. Depending on whether it is read-only or normal recovery, the appropriate backup control file is copied to the location described above. After copying the control files, the IR application agent software issues the appropriate permissions and ownership.

After applying the recovered password file, in step 1308 the unwanted information, such as TS2, TS3, is cleared so that only the table spaces previously selected for user recovery, such as TS1, are recovered. The restoration of the first table space TS1 is then in the step 1310 carried out. After copying the appropriate control files, the database is set up and, if necessary, renamed. Unwanted data files are then dropped (dropping data files updates the control files), and then the entire database is restored. Oracle ignores the dropped data files and restores only the tablespaces selected for installation as defined by the control files. In the step 1312 then the Oracle database level is opened and available for use.

In non-recovery mode, the Oracle layer does not issue any Oracle recovery commands. It only keeps the tools available to the user. That is, the initinstance.ora file, the entry files, the data files, and the backup control files are available. The user can then generate a password file and perform the restoration by hand.

In the read-only start mode, the system behaves similarly to the recovery mode, except that the backup control file copied to the true control file location is the fixed-value version and the item is restored and opened in standby mode.

Those skilled in the art will recognize further features and advantages of the invention based on the embodiments described above. Accordingly, the invention is not limited to what has been shown and described in detail except as defined by the appended claims. All publications and comparative literature mentioned herein are expressly incorporated by reference in their entirety.

Claims (14)

Method for finding errors in a data volume of a production database with the following steps: Storing an original data volume; Reproducing the original data volume; Examine the reproducing volume of data for errors; Correcting an error in the original data volume based on information obtained from the examination of a corresponding error in the reproduced data volume; which further comprises the installation and examination of the reproduced data volume with a data cleaning tool, allows an assessment of the error detected in the reproduced data volume to determine an error correction strategy wherein the error correction strategy comprises error correction on the original data volume or a replica copy of the original data volume without correcting the reproduced data volume. The method of claim 1, further comprising the steps of: Storing the original data volume on a first number of disks; and Reproduce the original data volume on a second number of disks. Method according to claim 2, characterized in that it further enables an attempt to reproduce the volume of data reproduced. A method according to claim 3, characterized in that it further enables to realize a successful repair of the reproduced data volume in the original data set on the first number of disks. Method according to claim 2, characterized in that it comprises the re-storage of the reproduced data volume. Method according to claim 5, characterized in that it comprises the updating of the restored data volume with data from a repeat entry. Method according to claim 6, characterized in that it comprises the incremental examination of the recovered data volume for errors when the re-stored and restored data volume is updated from the re-entry. The method of claim 7, further comprising updating the partially recovered data volume at a point where no errors are detected. An information recovery system operating according to a method according to any of claims 1 to 8, comprising: a storage area network; a server coupled to the storage area network for receiving a request from a first host to reproduce a data volume group that can be set up by a second host and inspected for errors. The system of claim 9, further including an information recovery application for generating reproduction requests. The system of claim 10, wherein the information recovery application resides on a host computer coupled to the server via a network. The system of claim 9, wherein the data volume group is controlled by an application agent. The system of claim 12, wherein the application agent corresponds to an Oracle database. The system of claim 9, further including an information recovery database coupled to the server.

Images