KR100539912B1 - How to collectively back up and load processor load data in the exchange database management system - Google Patents

Abstract

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an exchange system, and more particularly, to a method for collective backup and loading of processor load data being operated in accordance with an operator's request in a database management system.

The present invention provides a method for backing up and loading processor load data in a switch database management system, the method comprising: receiving a relation batch backup command and transmitting a backup data transmission request message for a backup data transmission request when the relation is a backup possible relation; And storing backup data received after receiving the backup data transmission request message, and outputting a backup completion message indicating that backup of the relation data is completed after reception and storage of the backup data are completed. A process of performing a batch backup of the processor load data, receiving a backup file copy command when the exchange system loads the backed up file after backing up the relation of the processor load data, and copying the received backup file data The command is If it is effective, if the processor load data and relation exist in the exchange system processor, copying the backup file data to the relation of the processor load data, and if the backup file copy is completed, a copy completion message is sent. Configure including the process of output.

Description

Batch backup and loading method of processor load data in the exchange exchange database management system

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an exchange system, and more particularly, to a method for collective backup and loading of processor load data being operated in accordance with an operator's request in a database management system.

In general, an exchange system has a plurality of subsystems, has distributed control, and a database management system (DBMS: DATABASE MANAGEMENT) to share data for each processor of the subsystem to support the distributed function. SYSTEM). The database management system supports a distributed function so that data can be distributedly mounted to each processor, and each of the processors is required data for real-time processing, which is referred to as processor load data (PLD). The PLD resides in each memory. The PLD is processed at a speed higher than that of an auxiliary storage device such as a disk, for example, in terms of its processing speed. There is a loss of data in the event of a fatal error in the exchange system. In order to add and supplement the service function of the exchange system, when the application program of the exchange system is upgraded or when the exchange system is expanded, a new PLD is produced by backing up the PLD operating in the memory to disk. Will be used. However, only the PLD transitioned from the initial PLD to the disk of the memory operation PLD can be backed up to the disk, so that the PLD without the initial PLD and the change cannot be backed up.

Accordingly, an object of the present invention is to provide a method of collectively backing up processor load data of an exchanger system for collectively backing up processor load data being operated on a memory.

In order to achieve the above object, the present invention provides a method for backing up and loading processor load data in a switch database management system, wherein a backup for requesting backup data transmission is received when the relation is a backup capable of receiving a relation batch backup command. Transmitting a data transmission request message, storing backup data received after receiving the backup data transmission request message, and completing backup of data of the relation after reception and storage of the backup data are completed. A process of backing up the processor load data, comprising: outputting a backup completion message indicating a backup completion message; and receiving a backup file data copy command when the exchange system loads the backed up file after backing up the relation of the processor load data. And above Copying the backup file data to the relation of the processor load data when the processor load data and relation exist in the exchange system processor when the new backup file copy command is valid; and the backup file data. When the copy is completed, the process is to output a copy complete message.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. It should be noted that in the following description, only parts necessary for understanding the operation according to the present invention will be described, and descriptions of other parts will be omitted so as not to distract from the gist of the present invention.

FIG. 1 is a diagram illustrating a configuration of an exchange system. The exchange system basically includes three elements of an access switching subsystem (ASS) 100, an interconnection network subsystem 200, and a central control subsystem 300. It consists of two subsystems. The ASS 100 performs a call processing function such as subscriber and relay line matching and call origination and reception, and is composed of a plurality of access switching processors (ASPs) 101. The INS 200 performs centralized call processing functions such as number translation and call configuration, and is composed of an INP (Interconnection Network Processor) 202 and a NTP (Number Translation Processor) 201. The CCS 300 performs a centralization function of operation and maintenance, and consists of an operation and maintenance processor (OMP) 301 and a man machine processor (MMP) 302.

The database management system (DBMS: DATAMS MANAGEMENT SYSTEM, hereinafter referred to as DBMS) of the exchange system having the configuration as shown in FIG. 1 is provided to a processor for each subsystem in order to support a distributed structure composed of three subsystems. Distributed DBMS that manages data by being distributed and stored. 2 is a diagram showing a configuration of the DBMS. The DBMS includes DBTG (Database Transaction Group) 21, DBQG (Database Query Group) 22, DBSG (Database Supporting Group) (23). ), Five blocks including DBKG (Database Kernel Group) 24 and DBBG (Database Backup Group) 25.

3 is a view for explaining the interface characteristics between the respective systems and the DBMS.

Referring to FIG. 2 and FIG. 3 for the function of each block constituting the DBMS, the DBKG 24 is stored in all processors, and performs the core functions of the DBMS such as directly searching, changing, inserting, and deleting a database. In addition, the DBSG 23 performs an interprocessor communication (IPC) function that supports an application matching function and a distributed database. The DBBG 25 manages redundant data, performs disk backup and recovery functions when data is changed, and is stored only in the OMP 301. The DBTG 21 performs data recovery and backup functions during transaction execution and transaction termination and withdrawal between distributed processors, and the DBQG 22 is stored only in the MMP 302 to perform interactive database query processing by the operator. .

The DBTG 21 is mounted in all main processors (MPs) to process various functions related to transactions, and is interfaced with the DBKG 24 and the DBBG 25. The transaction related table configuration is handled by the DBKG 24, distributedly mounted on all MPs so that distributed processing is possible, and the processor for which a transaction start command is requested mainly manages the entire transaction processing. The transaction function is composed of transaction start, transaction stop, transaction end, transaction state management processing parts, and is operated by the user's transaction start (BEGIN_TRN), stop (UNDO_TRN) and end (END_TRN) requests. Log processing generated at the end of the transaction is transferred to the DBBG 15 to be backed up.

The electronic exchange DBMS supports a distributed function so that data can be distributed and mounted on multiple processors, and the data resides in main memory for real-time processing. The database is loaded into a processor load data (PLD). It will be referred to as). The resident data of the main memory can be processed at a higher speed than the resident data in terms of data processing.However, in the event of a system failure, volatile memory data is lost, resulting in many problems and overhead in terms of data reliability and fault tolerance. Because of this inherent capability, backing up and restoring the changed data to the auxiliary storage device is necessary compared to the disk-resident data.

The DBTG 21 is composed of a main process and six processes that handle transaction start, transaction stop, transaction end, transaction state management, and the like. The processing request of the transaction is received by the main process to generate and process the corresponding child process, and the child process sends a response to the corresponding block. The main process is a resident process (DBTG_trn_timechk) that periodically manages the status of transactions and a resident process (DBTG_trn_rep) that manages locks / unlocks for duplicate relations, and transitions to a wait state to receive transaction processing requests. do. The resident process DBTG_trn_timechk is a function for preventing a deadlock of a transaction and manages the state of the transaction by a time stamp method. In addition, the resident process DBTG_trn_rep is executed only in the OMP301 process, receives a request for changing data by a transaction, locks the relation to control simultaneous access to the duplicate relation, stores the change information, and stores the change information at the end of the transaction. It performs the function of transmitting to 25.

When an application starts a transaction, a processor that creates a transaction-related table, a process that is processed when the transaction is stopped, a process that is executed when the transaction ends, and a process that terminates the transaction due to a transaction request from another processor are created by the main process. It is automatically destroyed after executing the function. Recovery of the change history related to the transaction and recovery at the time of suspension is distributed for each processor, and the locking algorithm is implemented as a tuple lock unlike a general instruction, and is implemented as a relation lock between transactions.

4 is a flowchart illustrating a relation unit backup process according to an embodiment of the present invention.

First, when an operator inputs a relation batch backup command through an operator terminal in operation 411, the input relation batch backup command is received by the DBBG 25 of the OMP 301. The DBBG 25 proceeds to step 413 when receiving the relation batch backup command. In step 413, the DBBG 25 determines the validity of the received relation batch backup command and proceeds to step 415. In this case, determining the validity of the relation batch backup command means determining the validity of a parameter included in the input command, for example, a parameter such as a processor number and relation information.

In step 415, the DBBG 25 checks whether the received relation batch backup command is valid. If the check result is not a valid command, the DBBG 25 proceeds to step 417. In step 417, the DBBG 25 processes an error and returns.

If the check result is a valid command, the DBBG 25 proceeds to step 419. In step 419, the DBBG 25 transmits a relation backup availability check message to check whether the relation corresponding to the command is a backup possible relation to the DBSG 23, and proceeds to step 421. 23 sends a message to DBKG 24 to check whether the corresponding relation is a backupable relation, and the DBKG 24 checks the corresponding relation and locks it if it is a backup-capable relation. The DBSG 23 transmits the result of the check to the DBSG 23. The DBSG 23 transmits the result received from the DBKG 24 to the DBBG 25.

In step 421, the DBBG 25 receives a backup availability message of the relation from the DBSG 23 and proceeds to step 423. In step 423, the DBBG 25 checks whether the relation to be backed up is a backup possible relation by checking a backup availability message of the corresponding relation. If the result of the check is a non-backup relation, the DBBG 25 proceeds to step 425. In step 425, the DBBG 25 transmits and returns a relation batch backup impossible message to the operator terminal 50.

If the result of the check is a backup possible relation, the DBBG 25 proceeds to step 427. In step 427, the DBBG (25) is a backup log file for backing up the relation in a predetermined region of the disk (40). For example, create B_LOG and proceed to step 429. In step 429, the DBBG 25 transmits a relation backup data transmission request message requesting transmission of the relation backup data to the DBSG 23, and proceeds to step 431. At this time, the relation backup data transfer request requires not only to back up only data having a change among data loaded from the disk, but to back up all data, that is, batch backup. On the other hand, when the DBSG 23 receives the relation backup data transmission request message from the DBBG 25, the DBSG 24 calls the DBKG 24 to backup the relation data to be backed up by the maximum IPC transmission size through IPC (INTERPROCESSOR COMMUNICATION). It reads through a buffer BUFFER, converts it into a transmission format, and transmits it to the DBBG 25.

In step 431, the DBBG 25 receives relation backup data from the DBSG 23 and proceeds to step 435. In step 435, the DBBG 25 checks whether the received relation backup data is valid data. In this case, checking the validity means checking message head information of the received backup data. If it is determined that the backup data is not valid backup data, the DBBG 25 transmits a relation backup data retransmission request message requesting retransmission of the relation backup data to the DBSG 23 and returns to step 431. However, if the received backup data is not valid data for a predetermined number of times, for example, three times or more, the DBBG 25 processes and returns a process to the present time.

If the received data is valid data, the DBBG 25 stores the received relation backup data in the backup log file B_LOG created in the disk 40 and proceeds to step 439. In step 439, the DBBG 25 checks whether the stored relation backup data is the final relation backup data. If the result of the check is not the final relation backup data, the DBBG 25 returns to step 431. If the result of the check is the final relation backup data, the DBBG 25 proceeds to step 441. In step 441, the DBBG 25 transmits and returns a backup completion message indicating that the relation batch backup is completed to the operator terminal 50.

Therefore, the relation batch backup procedure as shown in FIG. 4 makes it possible to maintain the latest data being operated by collectively backing up the relation data operating in the memory to the disk if the operator requests.

5 is a flowchart illustrating a process of copying a backed up relation file according to an embodiment of the present invention.

First, in step 511 DBBG 25 receives a backup file copy command through the operator terminal 50 and proceeds to step 513. In step 513, the DBBG 25 determines the validity of the received command and proceeds to step 515. In step 515, the DBBG 25 checks whether the command is valid. If the check result is not a valid command, the DBBG 25 proceeds to step 517. In step 517, the DBBG 25 transmits and returns a non-copyable message indicating that the backup file cannot be copied to the operator terminal 50.

If the check result is a valid command, the DBBG 25 proceeds to step 519. In step 521, the DBBG 25 prohibits data backup of the same PLD in order to prevent the PLD in which the relation exists from being damaged by another backup operation and proceeds to step 521. In step 521, the DBBG 25 searches for the corresponding PLD and proceeds to step 523. In step 523, the DBBG 25 checks whether a relation corresponding to the backup file exists in the searched PLD. If the relation does not exist, the DBBG 25 proceeds to step 525. In step 525, the DBBG 25 transmits and returns a non-copyable message to the operator terminal 50 indicating that the backup file cannot be copied.

If the result of the check exists, the DBBG 25 proceeds to step 527. In step 527, the DBBG 25 changes the header (HEADER) information of the relation to a copyable state and proceeds to step 529. In step 529, the DBBG 25 starts copying the corresponding backup file and proceeds to step 531. In step 531, the DBBG 25 checks whether the copy of the backup file is completed and proceeds to step 533 when the copy is completed. In step 533, the DBBG 25 transmits and returns a backup file copy completion message indicating that the backup file has been copied to the operator terminal 50.

Therefore, the backup file copy process as shown in FIG. 5 enables the operator to reload and use the latest relation data file backed up to disk.

As described above, the embodiments of the present invention have been described with reference to the drawings, for example, but various changes and modifications can be made within the scope allowed by the matter.

As described above, the present invention makes it possible to collectively back up recent relation data operating in the memory of the exchanger system to a secondary storage device such as a disk, and to copy and load a file backed up to the secondary storage device again. In the case of expansion of the exchange system and upgrade of the exchange program, it is possible to reload the memory data after the batch backup, so that the latest data can always be maintained, and the reliable data processing by producing the processor load data using the memory data. Has the advantage that it becomes possible.

1 is a diagram illustrating a configuration of an exchange system.

FIG. 2 is a block diagram showing an internal configuration of a database management system of the exchange system as shown in FIG.

3 is a block diagram showing an interface configuration between an exchange system and a database management system;

4 is a flowchart illustrating a relation unit backup process according to an embodiment of the present invention.

5 is a flowchart illustrating a process of copying a backed up relation file according to an embodiment of the present invention.

Claims (7)

What is claimed is: 1. A method of collectively backing up processor load data in an exchange database management system, Receiving a relation batch backup command, Checking whether the relation can be backed up when the received relation batch backup command is valid; Forming a backup log file in the case of the relation as a result of the inspection; Transmitting a backup data transmission request message for transmitting backup data of a relation after forming the backup log file; Receiving backup data of a relation after transmitting the backup transmission request message; Checking whether the received backup data is valid data and storing the generated backup data in the generated backup log file; Storing the valid data in a backup log file and checking whether the stored data is the last backup data of the relation; And repeating the receiving and storing of the backup data if the backup data of the relation is not the final relation backup data as a result of the inspection. The method of claim 1, And receiving and storing the final backup data of the relation and outputting a backup completion message. The method of claim 2, And outputting a relation batch backup impossible message indicating that the backup cannot be performed when the relation to be backed up cannot be backed up. The method of claim 3, wherein And transmitting a relation backup data retransmission request message requesting retransmission of the relation backup data if the relation backup data received after transmitting the backup transmission request message is not valid data. How to batch backup processor load data for your system. A method of loading processor load data in an exchange database management system, Receiving a backup file copy command; Prohibiting data backup of the corresponding processor load data when the received backup file data copy command is valid; Prohibiting data backup of the processor load data and retrieving the processor load data; Checking whether the relation to be copied exists after searching the corresponding processor load data; Changing the head information of the processor load data existing in the processor load data to be copyable if the relation exists as a result of the inspection; Starting to copy the backup data after changing the processor load data head information; And a process of outputting a backup file copy completion message when the copy of the backup data is completed. The method of claim 5, And if the relation to be copied does not exist after retrieving the corresponding processor load data, outputting a backup file data copy impossible message. A method of batch loading and loading processor load data in an exchange database management system, Receiving a relation batch backup command and transmitting a backup data transmission request message for a backup data transmission request when the relation is a backup capable relation; Storing backup data received after receiving the backup data transmission request message; A processor load data batch backup process comprising outputting a backup completion message indicating that backup of data of the relation is completed after reception and storage of the backup data are completed; Receiving a backup file data copy command when the exchange system loads the backed up file after backing up the relation of the processor load data; If the received backup file copy command is valid, copying the backup file data to the relation of the processor load data if the processor load data and relation exist in the exchange system processor; And a process of outputting a copy completion message when copying of the backup file is completed.