KR100673233B1 - Auto-tracing recovery system of database of database management system and method thereof - Google Patents

Abstract

The present invention relates to a database automatic recovery system and a method of a DBMS for automatically recovering a separate recovery DBMS at a specific time interval by using a log file generated from an operational DBMS (Database Management System). The database recovery system of the DBMS (DataBase Management System) according to the present invention is an operating database for storing a database generated in a customer service operation, and a collection of files in which a history of data generated during the operation database operation is recorded. An operational server including an operational archive log file, and a recovery database copying the operational database, and a recovery archive log file replicating the operational archive log file, wherein the recovery archive log is stored at specific time intervals. It is composed of a backup server to recover the operating server by applying a file to the recovery database. The automatic database recovery system and method of the DBMS according to the present invention need to recover only a database within a specific time interval when a failure occurs due to an operator's mistake or equipment failure, thereby greatly reducing the recovery time.

DBMS, recovery system, recovery method, log file

Description

{Auto-tracing recovery system of database of database management system and method}

1 is a block diagram of a database automatic recovery system of the DBMS according to an embodiment of the present invention.

2 is an overall flowchart of a method for automatically recovering a database of a DBMS according to an embodiment of the present invention.

3 is a flowchart of a step of replicating an operational database into a recovery database in the DBMS automatic recovery method of FIG. 2.

4 is a flowchart of a step of replicating an operational archive log file into an archive log file for recovery in the DBMS automatic recovery method of FIG.

5 is a flowchart of a step of recovering a database for recovery by applying the archive log file for recovery in the method for automatic database recovery of the DBMS of FIG.

The present invention relates to a database automatic recovery system of DBMS (DataBase Management System) and a method thereof, and more particularly to a DBMS that automatically recovers a separate recovery DBMS at a specific time interval using a log file generated from an operating DBMS. The present invention relates to a database automatic recovery system and a method thereof.

The DBMS that is currently being used is investing a lot of money in the expansion of servers, disks, etc. as the capacity is getting bigger and the usage is increased.

If a failure occurs due to an operator's mistake or equipment failure in such a DBMS environment, a lot of recovery time is required to recover a large-scaled DBMS, resulting in service interruption, which causes great damage to customers and businesses.

Therefore, complete recovery of data in the event of a DBMS failure is a very important factor that guarantees enterprise permanence. Especially, how fast recovery can be the key to minimizing the loss caused by failure.

As a method of recovering data in the case of a conventional DBMS failure, there was a method of copying an operating DBMS to a recovery disk at a predetermined time (for example, once a day at a set time) and recovering the data using the same.

However, since this method is replicated based on a certain time, if the replication is performed once every day, there is a time difference of up to 24 hours with the replicated DBMS. Therefore, in order to recover the DBMS when the operational DBMS fails, The log file created for 24 hours needs to be restored.

Technically, DBMS replication can be done several times a day, but in most cases, it is difficult to perform DBMS replication more than once a day due to the increase of system load. Therefore, there is a problem that it takes excessive time to recover by applying a log file to a fixed recovery DBMS.

To overcome the above problems, DBMS providers (eg Oracle) recommend the use of StandBy DBMS. However, in this case, if you open the StandBy DBMS, which is the final stage of recovery of the StandBy DBMS, at least once, the production DBMS is no longer available.

Therefore, there is a problem in that it is not possible to open the StandBy DBMS at normal times and check whether it is opened for a separate test or normally.

In addition, when adding or deleting a data file to the operating DBMS during the operation of the StandBy DBMS, the same procedure must be repeated in the StandBy DBMS, which requires a lot of management effort of the DBMS operator compared to the utility.

The technical problem of the present invention for solving the above problems is to provide a DBMS database automatic recovery system and method thereof that shorten the DBMS recovery time and efficient DBMS management.

Database recovery system of the DBMS (DataBase Management System) for achieving the object of the present invention, the operating database for storing the database generated in the customer service operation, and the history of the data generated during the operation database operation is recorded An operational server including an operational archive log file that is a collection of files, a recovery database that replicates the operational database, and a recovery archive log file that replicates the operational archive log file, wherein And a backup server recovering the operation server by applying a recovery archive log file to the recovery database.

The primary server and the backup server is characterized in that it is configured as a high availability (HA) server that can be continuously operated.

The operation server is characterized in that also serves as a function of the backup server.

The operational database and the recovery database are characterized in that the SID (System IDentification) is set to distinguish from each other.

On the other hand, the database recovery method of the database recovery system of the DBMS (DataBase Management System) to achieve another object of the present invention, A) replicating the operation database of the operation server to the recovery database of the backup server B) replicating the operational archive log file of the primary server with the recovery archive log file of the backup server together with the database replication; and C) the backup server applies the recovery archive log file by And recovering the recovery database.

In step A), when the disk copy solution is used, A-1) the backup server terminates the recovery database operation and exports the recovery database to be connected to the operation server for data communication. Step A-2) replicating the operational database to a recovery database disk using a disk copy solution by the production server, A-3) the same operation database as the recovery database In the state, the operation server converts the operation database to a backup state, A-4) When the replication is completed to the recovery database disk of the operation database using the disk copy solution, the operation server is Converting the operational database from the backup state to the normal state, A-5) The up server imports the replicated recovery database to operate again, A-6) the backup server generates a control file of the recovery database, and A-7) The operation server may include mounting the recovery database to operate in conjunction with the backup server 200.

In addition, in the case of using a general copy command, the step A) may include A-1 ') the backup server terminating the recovery database operation and the operation server converting the operation database to a backup state, A-2. ') Replicating the production database to the recovery database disk using the general copy command, A-3') replicating the production database to the recovery database disk of the production database using the general copy command; The operation server converts the operation database from the backup state to the normal state, A-4 ') the backup server generates a control file of the recovery database, and A-5 ') The operation server includes the step of mounting the recovery database to operate in conjunction with the backup server 200 It is desirable to.

And, the step B), B-1) the production server generates the operational archive log file recorded the history of the database generated in the production database with the execution of the cron (cron), and B -2) The primary server determines whether the replication time of the operational archive log file reserved in the cron is reached, and if the scheduled replication time of the operational archive log file is not reached in the cron, the production server continues. While generating the operational archive log file and waiting until the next scheduled time is adjustable, and when the scheduled replication time in the cron is reached, the production server generates the operation generated until the scheduled replication time. Duplicating an archive log file for the backup into the recovery archive log file of the backup server. It is desirable.

In addition, in step C), the backup server periodically executes cron and the backup server periodically receives a recovery archive log file from the operating server. It is determined whether it is time to delete the previously used recovery archive log file by cron, and when it is time to delete the previously used recovery archive log file, the backup server deletes the previously used recovery archive log file. Step C-3) The backup server determines whether it is time to apply the recovery archive log file to the recovery database, and if it is not time to apply the recovery archive log file, the backup server continues to recover. When receiving the archive log file for the application from the operating server, and applying the recovery archive log file In this case, the backup server mounts the recovery database so that the recovery database can proceed with the backup server in connection with the backup server. C-4) The backup server is reserved for the cron. If there is a recovery archive log file copied from the production server within a specific time interval based on time, and if there is a recovery archive log file copied from the production server within a specific time interval from the scheduled time The backup server changing the recovery archive log file to another file name that is not recognized by the recovery database in order to control batch application; C-5) the backup server has a specific time interval from the time reserved for the cron. Recovery arcs previously copied from the production server Restoring a log file to a file name recognized by the recovery database, C-6) The backup server checks whether a data file change record exists in a previous application process before starting the recovery, and changes If there is a history record, the backup server applies the changes to the recovery database. C-7) The backup server logs the recovery archive log copied from the operation server before a specific time interval from the scheduled time. It is preferable to include the step of applying a file sequentially to the recovery database to recover.

During the database recovery in step C-7), the backup server checks whether a change in the data file occurs. When the change occurs, the backup server stops restoring the recovery database and changes the change. It is preferable to further include the step of recovering the database after finishing recording, and if the change does not occur, the backup server sequentially applies the recovery archive log file to the recovery database. .

The term 'SID (System IDentification)' used in the present specification is a term used in an Oracle DBMS, and means a unique ID for distinguishing each Oracle DBMS.

As used herein, the term 'export' means to convert data written for one application program into a format that can be used by another program.

As used herein, the term 'import' refers to the use of data produced by another application as opposed to the term 'export'.

The term 'mount' as used herein refers to a state in which a DBMS can apply a log file for recovery by recognizing information such as a file location and a state of a series of files in a database.

The term 'cron' used in the present specification is a command that repeatedly executes a task at a predetermined time point or a time interval in Unix. In an Oracle DBMS, a task is performed by using the DBMS_JOB package.

Hereinafter, the automatic database recovery system and method of the DBMS according to the present invention will be described in detail.

1 is a configuration diagram of a database automatic recovery system of a DBMS according to an embodiment of the present invention.

As shown in FIG. 1, the automatic database recovery system of the DBMS according to the present invention includes an operation server 100 and a backup server 200. The operational server 100 includes an operational database 110 and an operational archive log file 120, and the backup server 200 includes a recovery database 210 and an archive log file 220 for recovery. do.

The operation database 110 stores a database generated during operation of a service for a customer in the operation server 100.

The operational archive log file 120 is a collection of files in which the history of the database such as addition, change, and deletion of data generated during operation of the operational database 110 is recorded.

The recovery database 210 is a replica of the operational database 110 and is used when the database is restored.

The recovery archive log file 220 is a copy of the operational archive log file 120, is applied to the recovery database 210 to perform a database recovery.

The production server 100 and the backup server 200 is preferably configured as a High Availability (HA) server that can be continuously operated for a long time, the operation server 100 is a function of the backup server 200 Can also be performed.

It is also possible to use the same SID if the operating server and backup server are different, and if the operating server and the backup server are the same, the operational database 110 and the recovery database 210 have different SIDs (System IDentification). It is preferable.

2 is an overall flowchart of a method for automatically recovering a database of a DBMS according to an embodiment of the present invention.

As shown in FIG. 2, the operation database 110 of the operation server 100 is replicated to the recovery database 210 of the backup server 200 (S100).

Along with the database replication, the operational archive log file of the operation server 100 is replicated to the recovery archive log file of the backup server 200 (S200).

The backup server 200 restores the recovery database 210 by applying the recovery archive log file 220 (S300).

3 is a flowchart of a step of replicating the operational database 110 into a recovery database 210 in the method for automatically recovering a database of the DBMS of FIG. 2.

As shown in FIG. 3, the backup server 200 checks whether the recovery database 210 is terminated and whether the recovery database 210 has been exported for data communication by being connected to the operation server 100. (S110).

When the recovery database 210 operation is not terminated, the backup server 200 terminates the recovery database 210 operation, and in order to replicate the operation database 110 when the recovery database 210 is not exported. The recovery database 210 is exported (S120).

When the recovery database 210 operation is terminated and the recovery database 210 is exploited, the operation server 100 restores the operation database 110 disk using the disk copy solution. 210) Start copying to the disk (S130).

After the operational database 110 and the recovery database 210 is in the same state, the operational server 100 switches the operational database 110 to a backup state (S140).

When the operational database 110 is switched to the backup state, the operational server 100 completes the replication of the operational database 110 disk using the disk copy solution to the recovery database 210 disk (S150).

When the replication is completed, the operation server 100 switches the operation database 110 from the backup state to the normal state (S160).

In the case where a general copy command is used instead of the disk copy solution, after switching the operation database 110 to a backup state (S140), the operation database 110 is copied to a recovery database 210. In step S130, when the replication is completed to the recovery database 210 (S150), the operation database 110 is switched to a normal state (S160).

The order is different when using the general copy instruction and the disk copy solution.

-General copy command: S140-> S130-> S150-> S160

-Disk Copy Solution: S130-> S140-> S150-> S160

When the operational database 110 is switched to the normal state, the backup server 200 imports to operate the replicated recovery database 210 again (S170).

When the recovery database 210 is imported, the backup server 200 generates a control file in which the environment, state, etc. of the recovery database are stored (S180).

When the control file of the recovery database 210 is generated, the recovery database 210 is mounted to operate in conjunction with the backup server 200 (S190).

4 is a flowchart of a step of replicating an operational archive log file 120 into an archive log file 220 for recovery in the method for automatically recovering a database of the DBMS of FIG. 2.

As shown in FIG. 4, the operation server 100 executes cron (S210).

With the cron execution, the operation server 100 generates an operation archive log file 120 in which the history of the database such as addition, change, deletion, etc. generated in the operation database 110 is recorded (S220).

Thereafter, the operation server 100 determines whether the replication time of the operational archive log file 120 reserved in cron is reached (S230).

If the time for replication of the operational archive log file 120 scheduled in cron is not reached, the production server 100 continues to generate the operational archive log file 120 while the cycle is at the next scheduled time when the cycle is adjustable. Wait until (S220).

On the other hand, when the clone time of the scheduled operational archive log file 120 in cron, the production server 100 restores the backup archive server 200 to the operational archive log file 120 generated by the scheduled replication time Replicate it to the archive log file 220 for storage (S240).

FIG. 5 is a flowchart of a step of recovering a recovery database 210 by applying a recovery archive log file 220 in the DBMS automatic recovery method of FIG. 2.

As shown in FIG. 5, the backup server 200 executes cron (S305).

With the cron execution, the backup server 200 periodically receives a recovery archive log file 220 from the operation server 100 (S310).

The backup server 200 determines whether it is time to delete the recovery archive log file 220 previously used by cron (S315).

When it is time to delete the previously used recovery archive log file 220, the backup server 200 deletes the previously used recovery archive log file 220 (S320), the recovery archive log file 220 It is determined whether it is time to apply (S325).

On the other hand, when it is not time to delete the previously used recovery archive log file 220, the backup server 200 determines whether it is time to apply the recovery archive log file 220 to the recovery database 210 ( S325).

When it is not time to apply the recovery archive log file 220, the backup server 200 continuously receives the recovery archive log file 220 from the operation server 100 (S310).

On the other hand, when it is time to apply the archive log file 220 for recovery, the backup server 200 is a database for recovery so that the recovery database 210 can proceed with the backup server 200 in conjunction with the recovery process Mount 210 (S330).

When the recovery database 210 is mounted in a recoverable state in the backup server 200, the backup server 200 is used for recovery copied from the operation server 100 within a specific time interval based on the time reserved for cron. It is searched whether the archive log file 220 exists (S335).

When there is a recovery archive log file 220 copied from the operation server 100 within a specific time interval from the scheduled time, the backup server 200 is to restore the archive log file 220 for maintaining a specific time interval. ) Is changed to another file name that the recovery database 210 does not recognize (S340).

On the other hand, if there is no recovery archive log file 220 copied from the production server 100 within a specific time interval from the scheduled time, the backup server 200 operates before a specific time interval from the time scheduled in the cron. The recovery archive log file 220 copied from the server 100 is restored to a file name recognized by the recovery database 210 (S345).

As such, the recovery database log file 220 exists in a state in which the recovery archive log file 220 is recognized or not recognized, and thus the automatic recovery can be performed while maintaining a specific time interval required by the administrator.

For example, the relationship between the specific time interval from step S335 to step S345 and the recovery archive log file 220 will be described below.

If the time scheduled in the cron is 12 o'clock and the specific time interval is 4 hours, the 'archive log file 220 for recovery copied from the operation server 100 within a specific time interval from the scheduled time' is '08. The archive log file 220 for recovery is copied from the production server 100 to the time from 12 o'clock to 12 o'clock, and the archive log file for recovery is copied from the production server 100 before a specific time interval from the scheduled time. Reference numeral 220 denotes a 'archive archive log file 220 copied from the operation server 100 before 8:00'.

Therefore, the files that can be recognized by the recovery database 210 are the 'archive archive log file 220 copied from the operation server 100 before 8:00' and the files that the recovery database 210 does not recognize are It is a recovery archive log file 220 copied from the production server 100 between 08:00 and 12 o'clock.

Next, a file name that the recovery database 210 can recognize is the archive log file 220 for recovery, copied from the production server 100 before the specified time interval (before 08:00) from the scheduled time (12 o'clock). When restored to the original, the backup server 200 checks whether the data file change record exists in the previous application process before starting the recovery (S350).

If a change record exists, the backup server 200 applies the changes to the recovery database 210 (S355), and then recovers the archive copied from the operation server 100 before a specific time interval from the scheduled time. The log file 220 is sequentially applied to the recovery database 210 to start recovery (S360).

On the other hand, if the change record does not exist, the backup server 200 sequentially restores the recovery archive log file 220 copied from the operation server 100 before a specific time interval from the scheduled time. ) To start the recovery (S360).

During the database recovery, the backup server 200 checks whether a change such as adding a data file occurs (S365).

In this case, when the change occurs, the backup server 200 stops the recovery of the database 210 for recovery (S365), records the change, and ends the database recovery (S370). The change record left here is detected in the process of checking whether there is a change in the data file, which is the step S350, and is reflected in the recovery database 210 to proceed with the recovery.

On the other hand, if the change does not occur, the backup server 200 sequentially determines the recovery of the recovery database 210 for a specific time interval by applying the recovery log file 220 for recovery (S375).

Referring to the process from step S350 to step S375 as an example.

If the first time reserved for the cron is 12 o'clock and the specific time interval is 4 hours, the recovery archive log file 220 copied from the operation server 100 before the specific time interval in step S360 is' It means a recovery archive log file 220 'copied from the operating server 100 before 08 o'clock.

The backup server 200 is restoring the database 210 for recovery using the recovery archive log file 220 copied from the operation server 100 before 08 o'clock, and the archive log file for recovery until about 07:00 ( Suppose that 220 is applied to the recovery database 210 and the recovery is in progress.

At this time, if a change occurs, the backup server 200 stops the recovery DB for recovery in step S370 and records the change.

When the next cron is scheduled at 13:00, the process of FIG. 5 is performed again at 13:00, and the data is restored to the recovery database 210 at step S355 in the process of checking whether there is a change in the data file before starting recovery at step S350. After the file change is applied, the recovery process 210 of the recovery database 210 of step S360 is performed again by using the recovery archive log file 220 of 07 o'clock, which was previously terminated.

If no change occurs after that, the backup server 200 maintains the time difference up to a specific time interval of 09:00 and ends after recovering the database.

Although the present invention has been described above, this is only one embodiment, and it will be apparent to those skilled in the art that various changes and modifications can be made without departing from the technical spirit of the present invention. However, it will be apparent from the following claims that they fall within the scope of the invention.

As described above, the DBMS database automatic recovery system and method thereof according to the present invention only need to restore the database within a specific time interval when a failure occurs due to an operator's mistake or equipment failure, greatly reducing the recovery time There is.

In addition, the automatic database recovery system and method of the DBMS according to the present invention can be used for testing the operational DBMS, in addition to recovering the equipment already installed.

In addition, the automatic database recovery system and method of the DBMS according to the present invention can be easily managed by the DBMS operator because the log file that records the history of addition and deletion of data files is automatically reflected in the database recovery.

Therefore, the automatic database recovery system and method of the DBMS according to the present invention can minimize failure recovery time and operate an efficient recovery system, thereby providing a stable service to customers using the DBMS, thereby creating customer service satisfaction.

Claims (10)

An operational server comprising an operational database for storing a database and an operational archive log file which is a collection of files in which a history of data generated during operation of the operational database is recorded; And And a backup server including a recovery database replicating the operational database and a recovery archive log file replicating the operational archive log file. a) replicating the production database of the production server to the recovery database of the backup server; b) the production server runs a cron and generates an operational archive log file that records the history of the database. And c) if the scheduled replication time is not reached in the cron, the production server continues to generate the operational archive log file and waits until the scheduled time, and the clone time is reached in the cron. The operational server copies the operational archive log file generated by the scheduled replication time into the recovery archive log file of the backup server, and d) the backup server runs cron and restores the archive log file for recovery. Periodically receive from the production server, and e) delete already used archive log files for recovery. If so, the backup server deletes the already used recovery archive log file, and f) if it is not time to apply the recovery archive log file, the backup server continues to recall the recovery archive log file. When it is time to receive from the production server and apply a recovery archive log file, the backup server mounts the recovery database, g) from the production server within a certain time interval based on the time reserved for the cron. If there is a copied archive log file for recovery, the backup server changes the archive log file for recovery to another file name that is not recognized by the database for recovery, and h) the backup server specifies a specific time from the time reserved for the cron. Recovery archive copied from the production server before the time interval. Restore the file to a file name recognizable by the recovery database, and i) if a data file change record exists in the previous application before starting recovery, the backup server may write the changes to the recovery database. J) the backup server recovers by sequentially applying the recovery archive log file copied from the operation server to the recovery database before a specific time interval from the scheduled time. The method of claim 1, The primary server and the backup server is a database automatic recovery system, characterized in that consisting of a high availability (HA) server that can be operated continuously. The method of claim 1, And said operating server performs both functions of said backup server. The method of claim 1, And said SID (System IDentification), which is a unique ID for distinguishing each other, from said operational database and said recovery database. In a database recovery method of a database recovery system having an operating server including an operational database and an operational archive log file, and a backup server comprising a recovery database and an archive log file for recovery, a) replicating the production database of the production server to the recovery database of the backup server; b) the production server executes cron and generates an operational archive log file in which a history of the database is recorded; c) when the scheduled replication time is not reached in the cron, the production server continues to generate the operational archive log file and waits until the scheduled time, and when the scheduled replication time is reached in the cron, Replicating, by the primary server, the operational archive log file generated up to the scheduled replication time into the recovery archive log file of the backup server; d) running the cron by the backup server and periodically receiving an archive log file for recovery from the primary server; e) when it is time to delete the already used archive archive log file, the backup server deleting the already used archive archive log file; f) when it is not time to apply the recovery archive log file, the backup server continues to receive a recovery archive log file from the operating server, and when it is time to apply the recovery archive log file, A backup server mounting the recovery database; g) If there is a recovery archive log file copied from the operating server within a specific time interval based on the time reserved in the cron, the backup server may not recognize the recovery archive log file in another recovery database. Changing to a file name; h) restoring, by the backup server, a recovery archive log file copied from the operation server before a specific time interval from the time reserved for the cron to a file name recognized by the recovery database; i) if a datafile change record exists in the previous application process before starting recovery, the backup server applying the change to the recovery database; And j) The backup server automatically recovers the database by applying the recovery archive log files copied from the operating server before the specified time interval from the scheduled time to the recovery database sequentially . The method of claim 5, When using a disk copy solution, step a) above Terminating the recovery database operation and exporting the recovery database so that the recovery database can be connected to the operation server for data communication; The primary server replicating the operational database to a recovery database disk using a disk copy solution; When the production database and the recovery database are in the same state, the operation server converting the operation database to a backup state; When the copying of the production database to the recovery database disk using the disk copy solution is completed, the operation server converting the production database from a backup state to a normal state; Importing, by the backup server, the replicated recovery database to operate again; Generating, by the backup server, a control file of a recovery database; And The operation server comprises the step of mounting the recovery database to operate in conjunction with the backup server 200, characterized in that the automatic database recovery method. The method of claim 5, When using the normal copy command, step a) The backup server terminating the recovery database operation and the operation server converting the operation database to a backup state; The primary server replicating the operational database to a recovery database disk using a general copy command; When the copying of the production database to the recovery database disk using the general copy command is completed, the operation server converting the operation database from a backup state to a normal state; Generating, by the backup server, a control file of a recovery database; And The operation server is a database automatic recovery method of the DBMS, characterized in that it comprises the step of mounting the recovery database to operate in conjunction with the backup server (200). delete delete The method of claim 5, In step j), while the database recovery is in progress, the backup server checks whether a change of the data file occurs. When the change occurs, the backup server stops restoring the database for recovery, records the change, and ends database recovery. And if the change does not occur, the backup server sequentially applying the recovery archive log file to the recovery database and recovering the recovery log file.

Images