JP2010015344A - Database system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a database system using simultaneous execution control, wherein vacuum processing and update processing do not adversely effect each other. <P>SOLUTION: A copy part 133 copies a database file for vacuum processing to a temporary memory 12 from a database 11. A vacuum part 132 executes the vacuum processing in the temporary memory 12 not but in the database 11. An overwrite part 134 overwrites the database file subjected to the vacuum processing into the database 11 from the temporary memory 12. The vacuum part 132 executes the vacuum processing to the temporary memory 12. User terminals 2, 3 execute the update processing to the database 11. Even when the vacuum processing needs a long time, the vacuum processing and the update processing do not adversely effect each other. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to a technique for improving the operability of a database by deleting excess data generated by the concurrent execution control in a database system using the concurrent execution control.

  There are database systems that use concurrency control. That is, even when the database system accepts a write instruction for certain data from a certain user terminal, it can accept a read instruction for that data from another user terminal.

  When receiving a read instruction, the database system provides data that has already been committed, not data that has not yet been committed. That is, when receiving a read instruction, the database system provides data that is guaranteed to be consistent, not data that is not guaranteed to be consistent.

  In order to provide data already committed at a certain time (first time), the database system stores data already committed at the first time, even when a write instruction is accepted at the first time. Need to be.

  The database system stores data that has already been committed at the second time, even when a write instruction is accepted at the second time, in order to provide data that has already been committed at a later time (second time). Need to be.

  Here, the database system continues to store data that has already been committed at the first time, the second time,. However, the database system will no longer provide data that has already been committed at the first time, the second time,. Therefore, the database system continues to store these data as excess data.

  The database system of Non-Patent Document 1 executes a vacuum process. In other words, the database system deletes data that has been committed other than immediately before the vacuum process, and extracts data that has been committed immediately before the vacuum process. Therefore, the database system can improve the operability of the database.

“PostgreSQL 8.3.1 Document”, [online], April 3, 2008, PostgreSQL Global Development Group, [Search June 4, 2008], Internet <URL: http: //www.postgresql. jp / document / pg831doc / html / ＞

  When executing the vacuum process and the update process, the database system of Non-Patent Document 1 may adversely affect the update process by the vacuum process, and may adversely affect the vacuum process by the update process. When the database system requires a long time for the vacuum processing, the above problems become important problems.

  Therefore, in view of the above problems, the present invention provides a database system in which even when the vacuum processing requires a long time, the vacuum processing does not adversely affect the update processing, and the update processing does not adversely affect the vacuum processing. The purpose is to provide.

  In order to solve the above-mentioned problem, the invention according to claim 1 is a database system comprising a database, a temporary memory, pre-commit data committed before one commit, and a commit committed after the one commit. The post-commit data is extracted by deleting the pre-commit data from the pre-commit data and the post-commit data copied from the database to the temporary memory, and the pre-commit data and the post-commit data copied in the temporary memory. A vacuum unit, and an overwriting unit that overwrites the post-commit data extracted in the temporary memory from the temporary memory to the database.

  According to a second aspect of the present invention, in the database system according to the first aspect, the vacuum unit is stored in the database while the pre-commit data and the post-commit data are copied by the copy unit. A vacuum canceling unit for canceling the extraction of the post-commit data when the post-commit data is updated.

  According to a third aspect of the present invention, in the database system according to the first or second aspect, the overwriting unit is stored in the database while the post-commit data is extracted by the vacuum unit. And an overwrite canceling unit for canceling overwriting of the post-commit data when the post-commit data is updated.

  According to a fourth aspect of the present invention, in the database system according to any one of the first to third aspects, when the post-commit data is overwritten by the overwriting unit, an exclusive lock is applied to the database. An exclusive lock unit is provided.

  The database system includes a database, a temporary memory, a copy unit, a vacuum unit, and an overwrite unit. The database stores data permanently, while the temporary memory stores data temporarily.

  The copy unit copies data committed other than immediately before the vacuum process and data committed immediately after the vacuum process from the database to the temporary memory. The vacuum unit deletes data committed in the temporary memory other than the latest in the vacuum process, not in the database, and extracts data committed in the immediate vicinity of the vacuum process. The overwriting unit overwrites the data committed in the latest vacuum processing from the temporary memory to the database.

  The vacuum unit performs a vacuum process on the temporary memory. The user terminal executes update processing on the database. Even when a long time is required for the vacuum process, the database system does not adversely affect the update process by the vacuum process, and does not adversely affect the vacuum process by the update process.

{Outline of vacuum processing}
Hereinafter, embodiments of the present invention will be described with reference to the drawings. FIG. 1 is a time chart showing an outline of the vacuum processing. The server 1 stores a database. The user terminals 2 and 3 operate the database. The server 1 uses simultaneous execution control.

  The user terminal 2 executes the transaction 21. The user terminal 3 executes transactions 31 and 32. The transaction 31 is executed in parallel with the transaction 21, but the transaction 32 is executed at a different timing from the transaction 21.

  The data stored in the database before the execution of step S21 by the server 1 is data that has already been committed in the most recent transaction and is not updated by the user terminal 2 (data that has already been committed update) (step S11). .

  The user terminal 2 transmits a reading instruction to the server 1 (step S21). The user terminal 2 obtains the data before the commit update from the server 1 and displays the data before the commit update on the display unit (not shown in FIG. 1) (step S22).

  The user terminal 2 transmits a first write instruction to the server 1 (step S23). The data recorded in the log information by the server 1 after the execution of step S23 is data that has not yet been committed in the transaction 21 and is being updated by the user terminal 2 (uncommitted updating data) ( Step S12).

  The user terminal 2 transmits a second write instruction to the server 1 (step S24). The data recorded in the log information by the server 1 after the execution of step S24 is data that has not yet been committed in the transaction 21 and has been updated by the user terminal 2 (data after uncommitted update) (step S13). ).

  The server 1 executes the commit process when the written contents in steps S23 and S24 are recognized to be consistent. The server 1 executes a rollback process when the written contents in steps S23 and S24 are not consistent. In FIG. 1, the server 1 executes a commit process (step S14).

  The data stored in the database after execution of step S14 by the server 1 is data that has already been committed in the transaction 21 and has been updated by the user terminal 2 (data that has already been committed and updated) (step S15).

  The user terminal 3 transmits a reading instruction to the server 1 (step S31). Here, uncommitted updating data is recorded in the log information (step S12). However, the user terminal 3 obtains the data before the commit update from the server 1, and displays the data before the commit update on the display unit (not shown in FIG. 1) (step S32). Therefore, the user terminal 3 can acquire and display data with guaranteed consistency.

  The user terminal 3 transmits a reading instruction to the server 1 (step S33). Here, the data after the already committed update is stored in the database (step S15). Therefore, the user terminal 3 acquires the data after the already-committed update from the server 1, and displays the data after the already-committed update on the display unit (not shown in FIG. 1) (step S34). Therefore, the user terminal 3 can acquire and display data with guaranteed consistency.

  The server 1 stores pre-commit update data in order to provide the user terminal 3 with pre-commit update data (step S32). The server 1 stores the data after the previous commit update in order to provide the user terminal 3 with the data after the previous commit update (step S34), but also stores the data before the previous commit update (step S15).

  The data after the already-committed update is necessary data that may be referred to in the future, but the data before the already-committed update is excessive data that cannot be referred to in the future. By executing the vacuum process, the server 1 deletes the data before the commit update, extracts the data after the commit update, and improves the operability of the database.

{Server components}
FIG. 2 is a block diagram showing components of the server 1. The server 1 includes a database 11, a temporary memory 12, and a database management system 13. The database 11 stores data permanently. The temporary memory 12 temporarily stores data. The database management system 13 inputs an operation instruction from the user terminals 2 and 3 and outputs an operation command to the database 11 and the temporary memory 12.

  The database 11 includes a first file 111, a second file 112, and a third file 113. One file is not related to other files and is independent of other files. The vacuum process and update process for one file are independent of the vacuum process and update process for another file.

  The database management system 13 includes an access unit 131, a vacuum unit 132, a copy unit 133, and an overwrite unit 134.

  The access unit 131 executes an update process on the data stored in the database 11. The vacuum unit 132 performs a vacuum process on the data stored in the temporary memory 12. The update process by the access unit 131 and the vacuum process by the vacuum unit 132 do not collide with each other.

  The copy unit 133 copies data that has not been subjected to vacuum processing stored in the database 11 from the database 11 to the temporary memory 12. The overwriting unit 134 overwrites the data that has been subjected to vacuum processing stored in the temporary memory 12 from the temporary memory 12 to the database 11.

{Flow of vacuum processing}
3 and 4 are flowcharts showing the flow of the vacuum process. 5 to 7 are time charts showing vacuum processing. The vacuum process for one file is independent of the vacuum process for the other file.

  “Reference data” is data that has been committed most recently in vacuum processing, and is necessary data that may be referred to in the future. The “reference data” corresponds to “updated data already committed” in step S15 in FIG.

  “Non-reference data” is data that has been committed other than immediately before the vacuum process, and is excessive data that cannot be referred to in the future. “Non-reference data” corresponds to “data before commit update” in step S11 of FIG.

[Vacuum processing of the first file]
FIG. 5 is a time chart showing the vacuum processing of the first file 111. Here, when the first file 111 is copied from the database 11 to the temporary memory 12, the first file 111 is not updated in the database 11. The first file 111 is not updated in the database 11 when the first file 111 is vacuumed in the temporary memory 12.

  The vacuum unit 132 checks whether or not the vacuum processing timing has come (step S41). FIG. 5 shows a case where the vacuum processing timing has arrived (YES in step S42). When it is confirmed that the vacuum processing timing has not arrived (NO in step S42), the vacuum unit 132 does not execute the vacuum processing.

  The vacuum unit 132 may check that the set time by the user terminals 2 and 3 has arrived. The vacuum unit 132 may check that the actual data size is a predetermined number of times or more than the original data size. The vacuum unit 132 may check that the user terminals 2 and 3 are not accessing the database 11.

  The copy unit 133 copies the first file 111 including the reference data 1111 and the non-reference data 1112 from the database 11 to the temporary memory 12 (step S43).

  The vacuum unit 132 checks whether or not the first file 111 has been updated in the database 11 during the copy process after the copy process (step S44). The vacuum unit 132 confirms that the first file 111 has not been updated in the database 11 during the copy process (NO in step S45).

  The vacuum unit 132 performs a vacuum process in the temporary memory 12 for the first file 111 including the reference data 1111 and the non-reference data 1112. The vacuum unit 132 extracts the reference data 1111 in the temporary memory 12 and deletes the non-reference data 1112 in the temporary memory 12 (step S46).

  The vacuum unit 132 checks after the vacuum processing whether the first file 111 is updated in the database 11 during the vacuum processing (step S47). The vacuum unit 132 confirms that the first file 111 has not been updated in the database 11 during the vacuum process (NO in step S48).

  The vacuum unit 132 may check whether or not the database file has been updated in the database 11 by checking log information stored in the database 11. The vacuum unit 132 may check whether the database file is updated in the database 11 by monitoring the database file stored in the database 11.

  The access unit 131 places an exclusive lock on the first file 111 stored in the database 11 (step S49). The user terminals 2 and 3 cannot access the first file 111. The overwriting unit 134 overwrites the reference data 1111 from the temporary memory 12 to the database 11 (step S50).

  The access unit 131 releases the exclusive lock on the reference data 1111 stored in the database 11 (step S51). User terminals 2 and 3 can access reference data 1111. The vacuum unit 132 deletes the reference data 1111 from the temporary memory 12 (step S52). Thus, the vacuum process for the first file 111 is completed.

[Vacuum processing of second file]
FIG. 6 is a time chart showing the vacuum processing of the second file 112. Here, when the second file 112 is copied from the database 11 to the temporary memory 12, the second file 112 is updated in the database 11.

  The vacuum unit 132 checks whether or not the vacuum processing timing has come (step S41). FIG. 6 shows a case where the vacuum processing timing has arrived (YES in step S42). When it is confirmed that the vacuum processing timing has not arrived (NO in step S42), the vacuum unit 132 does not execute the vacuum processing.

  The copy unit 133 copies the second file 112 including the reference data 1121 and the non-reference data 1122 from the database 11 to the temporary memory 12 (Step S43).

  The vacuum unit 132 checks after the copy process whether the second file 112 is updated in the database 11 during the copy process (step S44). The vacuum unit 132 confirms that the second file 112 has been updated in the database 11 during the copy process (YES in step S45).

  That is, the user terminal 2 or the user terminal 3 transmits an update data write instruction to the server 1 during the copy process. Then, the server 1 executes commit processing during the copy processing, and stores the update data 1123 in the database 11.

  If the vacuum unit 132 extracts the reference data 1121 and the overwriting unit 134 overwrites the reference data 1121, the update data 1123 that has already been committed is deleted. Therefore, the vacuum unit 132 does not execute a vacuum process. The vacuum unit 132 deletes the reference data 1121 and the non-reference data 1122 from the temporary memory 12 (step S52). Thus, the vacuum process for the second file 112 is completed.

[Vacuum processing of third file]
FIG. 7 is a time chart showing vacuum processing of the third file 113. Here, when the third file 113 is copied from the database 11 to the temporary memory 12, the third file 113 is not updated in the database 11. However, the third file 113 is updated in the database 11 when the third file 113 is vacuumed in the temporary memory 12.

  The vacuum unit 132 checks whether or not the vacuum processing timing has come (step S41). FIG. 7 shows a case where the vacuum processing timing has arrived (YES in step S42). When it is confirmed that the vacuum processing timing has not arrived (NO in step S42), the vacuum unit 132 does not execute the vacuum processing.

  The copy unit 133 copies the third file 113 including the reference data 1131 and the non-reference data 1132 from the database 11 to the temporary memory 12 (Step S43).

  The vacuum unit 132 checks after the copy process whether the third file 113 is updated in the database 11 during the copy process (step S44). The vacuum unit 132 confirms that the third file 113 has not been updated in the database 11 during the copy process (NO in step S45).

  The vacuum unit 132 performs a vacuum process in the temporary memory 12 for the third file 113 including the reference data 1131 and the non-reference data 1132. The vacuum unit 132 extracts the reference data 1131 in the temporary memory 12 and deletes the non-reference data 1132 in the temporary memory 12 (step S46).

  The vacuum unit 132 checks after the vacuum processing whether the third file 113 is updated in the database 11 during the vacuum processing (step S47). The vacuum unit 132 confirms that the third file 113 is updated in the database 11 during the vacuum process (YES in step S48).

  That is, the user terminal 2 or the user terminal 3 transmits an update data write instruction to the server 1 during the vacuum process. The server 1 executes the commit process during the vacuum process and stores the update data 1133 in the database 11.

  If the vacuum unit 132 extracts the reference data 1131 and the overwrite unit 134 overwrites the reference data 1131, the update data 1133 that has already been committed is deleted. Therefore, the overwriting unit 134 does not execute the overwriting process. The vacuum unit 132 deletes the reference data 1131 from the temporary memory 12 (step S52). Thus, the vacuum process for the third file 113 is completed.

{Summary of the invention}
The vacuum unit 132 performs a vacuum process on the temporary memory 12. The user terminals 2 and 3 execute update processing on the database 11. Even when the vacuum process requires a long time, the server 1 does not adversely affect the update process by the vacuum process, and does not adversely affect the vacuum process by the update process.

  The vacuum unit 132 does not execute the vacuum process when the update process is executed during the copy process. The overwrite unit 134 does not execute the overwrite process when the update process is executed during the vacuum process. The server 1 does not erroneously invalidate the update process by erroneously executing the vacuum process or the overwrite process.

  The vacuum unit 132 may check whether the update process is being executed during the copy process or the vacuum process after the copy process or the vacuum process, respectively. The vacuum unit 132 may check whether the update process is being executed during the copy process or the vacuum process, during the copy process or the vacuum process, respectively.

  In the former check method, the vacuum unit 132 can eliminate the burden of checking whether there is an update process during the copy process or the vacuum process. In the latter check method, the vacuum unit 132 cannot eliminate the burden of checking for the presence of update processing during copy processing or vacuum processing, but prevents invalidation of update processing during copy processing or vacuum processing. Measures can be taken at an earlier stage.

  The present invention can be applied to various data storage devices. For example, the present invention can be applied to a digital multi-function peripheral. When receiving the document data, the digital multi-function peripheral stores data such as a storage destination of the document data in the database. When the digital multi-function peripheral prints document data, the digital multi-function peripheral deletes data such as a storage destination of the document data from the database. Here, the digital multi-function peripheral stores data unnecessary for reference by using the simultaneous execution control. However, the digital multi-function peripheral can delete data unnecessary for reference by incorporating the database language such as SQL Lite into the development language and applying the present invention.

It is a time chart which shows the outline | summary of a vacuum process. It is a block diagram which shows the component of a server. It is a flowchart which shows the flow of a vacuum process. It is a flowchart which shows the flow of a vacuum process. It is a time chart which shows the vacuum process of a 1st file. It is a time chart which shows the vacuum process of a 2nd file. It is a time chart which shows the vacuum process of a 3rd file.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 Server 2, 3 User terminal 11 Database 12 Temporary memory 13 Database management system 111 1st file 112 2nd file 113 3rd file 131 Access part 132 Vacuum part 133 Copy part 134 Overwrite part

Claims (4)

A database,
Temporary memory,
A copy unit that copies pre-commit data committed before one commit and post-commit data committed after the one commit from the database to the temporary memory;
A vacuum unit for deleting the pre-commit data and extracting the post-commit data from the pre-commit data and the post-commit data copied in the temporary memory;
An overwriting unit for overwriting the post-commit data extracted in the temporary memory from the temporary memory to the database;
A database system comprising: The database system according to claim 1,
The vacuum part is
While the pre-commit data and the post-commit data are copied by the copy unit, the vacuum stop unit stops the extraction of the post-commit data when the post-commit data stored in the database is updated ,
A database system comprising: In the database system according to claim 1 or 2,
The overwriting unit is
While the post-commit data is extracted by the vacuum unit, when the post-commit data stored in the database is updated, an overwrite cancel unit that cancels overwriting of the post-commit data,
A database system comprising: The database system according to any one of claims 1 to 3, further comprising:
When the post-commit data is overwritten by the overwriting unit, an exclusive lock unit that puts an exclusive lock on the database,
A database system comprising:

Images