 |
Claims  |
|
|
We claim:
1. A method for updating contents of a database in a system in which said
database is constructed of pages which are logical storage locations of
data, said system including a current version page table for providing
information indicating a correspondence between pages currently updated by
a transaction and slots which are physical storage locations of data in
the database storage medium wherein currently updated contents of the
pages are stored, a backup version page table for providing information
indicating a correspondence between the pages of said database and slots
forming physical storage locations of data in a database storage medium in
which the contents of pages to be recovered are stored and for storing
therein a copy of the contents of said current version page table at a
checkpoint and a journal file for storing a journal record, comprising the
steps of:
(a) updating contents of at least one page of said database;
(b) updating contents of said current version page table when contents of a
page of said database are updated;
(c) copying the updated contents of the current version page table into the
backup version page table at the checkpoint;
(d) storing said journal record which is representative of the updated
contents of the current version page table into said journal file before
completion of a transaction;
(e) storing a journal record which is representative of a completion of
said transaction into said journal field at completion of said
transaction; and
(f) restoring the contents of the current version page table based on the
backup version page table and the journal file so that the current version
page table includes updates of the current version page table due to the
page updating of the database, at a system failure;
wherein at a time of system failure, by fetching journal records from said
journal file and analyzing said fetched journal records, a terminal
message and updated system management information in a main storage are
recovered respectively for complete transactions; and by using the journal
record representative of the updated contents of said current version page
table associated with the database updates produced by a transaction, and
said backup version page table, said current version page table is
recovered such that only the change of said current version page table
associated with the database updates by the complete transactions is
restored to said current version table to thereby ensure logical integrity
of the database.
2. A method for updating contents of a database in a system in which said
database is constructed of pages which are logical storage locations of
data, said system including a current version page table for providing
information indicating a correspondence between pages currently updated by
a transaction and slots which are physical storage locations of data in
the database storage medium wherein currently updated contents of the
pages are stored, a backup version page table for providing information
indicating a correspondence between the pages of said database and slots
forming physical storage locations of data in a database storage medium in
which the contents of pages to be recovered are stored and for storing
therein a copy of the contents of said current version page table at a
checkpoint and a journal file for storing a journal record, comprising the
steps of:
(a) updating contents of at least one page of said database;
(b) updating contents of said current version page table when contents of a
page of said database are updated;
(c) copying the updated contents of the current version page table into the
backup version page table at the checkpoint;
(d) storing said journal record which is representative of the updated
contents of the current version page table into said journal file before
completion of a transaction;
(e) storing a journal record which is representative of a completion of
said transaction into said journal field at completion of said
transaction; and
(f) restoring the contents of the current version page table based on the
backup version page table and the journal file so that the current version
page table includes updates of the current version page table due to the
page updating of the database, at a system failure;
wherein a plurality of backup page tables are provided in said non-volatile
storage medium at a checkpoint under system operation, said plurality of
backup version page tables are cyclically used and selected sequentially
as an object to be updated, and the selected backup version page table is
updated by storing a copy of the contents of the updated current version
page table into said backup version page table.
3. A method according to claim , wherein at a time of recovery of said
current version page table when a system failure occurs, by using the
journal record in said journal file representative of the updated contents
of said current version page table associated with the database update by
a transaction and the latest effectively updated backup version page table
among said plurality of backup version page tables in said non-volatile
storage medium, said current version page table is recovered such that
only the change of said current version page table associated with the
database updates by the complete transactions is restored.
4. A method for updating contents of a database in a system in which said
database is constructed of pages which are logical storage locations of
data, said system including a current version page table for providing
information indicating a correspondence between pages currently updated by
a transaction and slots which are physical storage locations of data in
the database storage medium wherein currently updated contents of the
pages are stored, a backup version page table for providing information
indicating a correspondence between the pages of said database and slots
forming physical storage locations of data in a database storage medium in
which the contents of pages to be recovered are stored and for storing
therein a copy of the contents of said current version page table at a
checkpoint and a journal file for storing a journal record, comprising the
steps of:
(a) updating contents of at least one page of said database;
(b) updating contents of said current version page table when contents of a
page of said database are updated;
(c) copying the updated contents of the current version page table into the
backup version page table at the checkpoint;
(d) storing said journal record which is representative of the updated
contents of the current version page table into said journal file before
completion of a transaction;
(e) storing a journal record which is representative of a completion of
said transaction into said journal field at completion of said
transaction; and
(f) restoring the contents of the current version page table based on the
backup version page table and the journal file so that the current version
page table includes updates of the current version page table due to the
page updating of the database, at a system failure;
wherein there is provided a checkpoint dump file for storing system
management information in main storage at a checkpoint, and wherein the
checkpoint dump file of said current version page table is placed into
said checkpoint dump file at a checkpoint, and at the end of system
operation said backup version page table in said non-volatile storage
medium is updated by storing a copy of the contents of said current
version page table to said backup version page table.
5. A method according to claim 4, wherein at a time of recovery of said
current version page table when a system failure occurs, by using the
journal record in said journal file representative of the contents of
change of said current version page table associated with the database
update by a transaction, a latest, effectively stored checkpoint dump of
said current version page table in said checkpoint dump file, and said
backup version page table in said non-volatile storage medium, said
current version page table is recovered such that only the change of said
current version page table associated with the database update by the
transaction whose journal record indicates the completion of the
transaction is restored.
6. A method for updating contents of a database in a system in which said
database is constructed of pages which are logical storage locations of
data, said system including a current version page table for providing
information indicating a correspondence between pages currently updated by
a transaction and slots which are physical storage locations of data in
the database storage medium wherein currently updated contents of the
pages are stored, a backup version page table for providing information
indicating a correspondence between the pages of said database and slots
forming physical storage locations of data in a database storage medium in
which the contents of pages to be recovered are stored and for storing
therein a copy of the contents of said current version page table at a
checkpoint and a journal file for storing a journal record comprising the
steps of:
(a) storing a journal record which is representative of a completion of a
transaction into said journal file at completion of said transaction; and
(b) restoring the content of the current version of the page table based on
the backup version of the page table so that the current version of the
page table includes updates of the current version of the page table due
to the page updating of the database of the system failure;
wherein at a time of system failure, by fetching journal records from said
journal file and analyzing said fetched journal records, a terminal
message and updated system management information in a main storage are
recovered respectively for complete transactions; and by using the journal
record representative of the updated contents of said current version page
table associated with the database updates produced by a transaction, and
said backup version page table, said current version page table is
recovered such that only the change of said current version page table
associated with the database updates by the complete transactions is
restored to said current version table to thereby ensure logical integrity
of the database.
7. A method for updating contents of a database in a system in which said
database is constructed of pages which are logical storage locations of
data, said system including a current version page table for providing
information indicating a correspondence between pages currently updated by
a transaction and slots which are physical storage locations of data in
the database storage medium wherein currently updated contents of the
pages are stored, a backup version page table for providing information
indicating a correspondence between the pages of said database and slots
forming physical storage locations of data in a database storage medium in
which the contents of pages to be recovered are stored and for storing
therein a copy of the contents of said current version page table at a
checkpoint and a journal file for storing a journal record comprising the
steps of:
(a) storing a journal record which is representative of a completion of a
transaction into said journal file at completion of said transaction; and
(b) restoring the content of the current version of the page table based on
the backup version of the page table so that the current version of the
page table includes updates of the current version of the page table due
to the page updating of the database of the system failure;
wherein a plurality of backup page tables are provided in said non-volatile
storage medium at a checkpoint under system operation, said plurality of
backup version page tables are cyclically used and selected sequentially
as an object to be updated, and the selected backup version page table is
updated by storing a copy of the contents of the updated current version
page table into said backup version page table.
8. A method according to claim 7, wherein at a time of recovery of said
current version page table when a system failure occurs, by using the
journal record in said journal file representative of the updated contents
of said current version page table associated with the database update by
a transaction and the latest effective updated backup version page table
among said plurality of backup version page tables in said non-volatile
storage medium, said current version page table is recovered such that
only the change of said current version page table associated with the
database updates by the complete transactions is restored.
9. A method for updating contents of a database in a system in which said
database is constructed of pages which are logical storage locations of
data, said system including a current version page table for providing
information indicating a correspondence between pages currently updated by
a transaction and slots which are physical storage locations of data in
the database storage medium wherein currently updated contents of the
pages are stored, a backup version page table for providing information
indicating a correspondence between the pages of said database and slots
forming physical storage locations of data in a database storage medium in
which the contents of pages to be recovered are stored and for storing
therein a copy of the contents of said current version page table at a
checkpoint and a journal file for storing a journal record comprising the
steps of:
(a) storing a journal record which is representative of a completion of a
transaction into said journal file at completion of said transaction; and
(b) restoring the content of the current version of the page table based on
the backup version of the page table so that the current version of the
page table includes updates of the current version of the page table due
to the page updating of the database of the system failure;
wherein there is provided a checkpoint dump file for storing system
management information in a main storage at a checkpoint, and wherein the
checkpoint dump file of said current version page table is placed into
said checkpoint dump file at a checkpoint, and at the end of system
operation said backup version page table in said non-volatile storage
medium is updated to store the contents of said current version page table
to said backup version page table.
10. A method according to claim 9, wherein at a time of recovery of said
current version page table when a system failure occurs, by using the
journal record in said journal file representative of the updated contents
of said current version page table associated with the database update by
a transaction, a latest, effectively stored checkpoint dump of said
current version page table in said checkpoint dump file, and said backup
version page tables in said non-volatile storage medium, said current
version page table is recovered such that only the change of said current
version page table associated with the database update by the transaction
whose journal record indicates the completion of the transaction is
restored. |
|
 |
|
 |
Claims |
|
|
|
Description |
|
|
BACKGROUND OF THE INVENTION
The present invention relates to a method and apparatus for update/recovery
of a database in a database system which ensures logical integrity for the
database to be updated by transactions or subjected to storage medium
failure particularly for the database to be recovered after system failure
such as power interruption.
Logical integrity for a database in a database system must be retained
after system failure such as power interruption or after transaction
failure due to program error for example. Specifically, the data base
update results obtained by transactions which have not been completed by
the time failure occurs, must be invalidated.
As a related prior art, there is known a method of storing update results
by a transaction in a new location different from that in which
information prior to update was stored. Such a method is described in "ACM
Transactions on Database Systems", Vol. 2, No. 1 (1977), pp. 91-104. This
method is called a shadow page method wherein before a transaction is
completely executed, all the updated database contents are written in new
storage locations, and at the time the transaction has been completely
executed, information before update is invalidated while information after
update is validated. The features of the shadow page method are summarized
as in the following (1) to (4):
(1) A database is constructed of pages each constituting a logical area
unit. Two page tables including a current version and a backup version are
provided, the table indicating a correspondence between pages and slots in
the database storage medium in which the contents of pages are stored. The
tables are stored in non-volatile medium such as on a disk. The page table
itself is usually divided into plural blocks. Transfer between a main
storage and the non-volatile medium is executed in units of blocks.
(2) A new slot wherein the update contents by a transaction of a page in a
database are stored, is called a current page slot. The correspondence
between pages and slots is retained in a current version page table.
Whereas a slot wherein the contents prior to update of a page are stored,
is called a shadow page slot. The correspondence between pages and slots
is retained in a backup version page table.
(3) Upon completion of transaction execution, the current version page
table is validated such that update information stored in a current page
slot is validated. Particularly, a status bit in the non-volatile medium
is changed which indicates an available one of the current and backup
version page tables.
(4) When system/transaction failure occurs while executing a transaction,
the backup version page table is decided as valid by the status bit. That
is, the information before update stored in the shadow page slot
identified by the backup version page table is made valid.
Therefore, it is possible to retain logical integrity, even when
system/transaction failure occurs. In addition, it is unnecessary to fetch
database update journal information.
The following three problems are known in the prior art shadow page method.
The first problem is that a plurality of transactions cannot share and
update the database at the same time. The reason for this is that since
status bits are changed collectively for validating the current version
page table after completing transaction execution, it is necessary that
pages being updated by other transactions should not be included in the
page table concerned.
The second problem is that synchronization is difficult between validating
the updated results of a database and validating messages transmitted to
terminals and the updated results of system management information in the
main storage. A transaction generally includes not only database update
but also message transmission and system management information update.
However, change of status bits according to the prior art concerns only
database update. Therefore, when system failure occurs, a fear may arise
at a certain timing that only the updated database results are validated,
or conversely only the message or system management information update
results are validated.
The third problem is that it is necessary to update the page table and
status bits in the non-volatile medium for each transaction so that the
update overhead becomes one of the reasons deteriorating the system
performance.
In an actual system environment where a plurality of on-line transactions
share and update the database at the same time, instead of the
above-described shadow page method, a shadow method combined with a method
wherein a database update journal is fetched, is used in view of the first
and second problems described above. This latter method however has a
large overhead in storing fetching database update information, and has a
fear that the system performance is deteriorated while still incorporating
the third problem described above.
Apart from the above prior art, another method has been employed for
recovery at the occurrence of database medium failure, wherein a backup
copy of the entire data base and a database update journal
time-sequentially recording all the update contents of the database, are
used. This method is described in "An Introduction to Database Systems",
Vol. II, Chapter 1, p. 20, by C. J. Date. According to this method, if
information in the database storage medium is destroyed, the backup copy
is loaded into the database storage medium, sequentially reflecting to the
loaded backup copy the database update journal information after the
backup copy was obtained, thus enabling recovery of the information.
The above prior art has the following problems (1) to (4):
(1) Since an update journal regarding the entire database is serially
written in a single journal file, the write process becomes a bottle neck
and the system performance is deteriorated.
(2) If certain information of the database in the storage medium is
destroyed, not only the update journal regarding the information
concerned, but also all the database update journal after the backup copy
was obtained must be read from the journal file and analyzed. There and
the database recovery time becomes very long.
(3) The whole or part of the database must be invalidated while a backup
copy is being obtained. This deteriorates availability of the database
system, and thus a serious problem arises particularly in the case of a
24-hour operating system or the like.
(4) To avoid the deterioration of availability of the database system as
described in (3), frequently obtaining backup copies must be restricted.
As the time for obtaining backup copies becomes longer, the storage amount
of the database update journal becomes extraordinary.
SUMMARY OF THE INVENTION
It is an object of the present invention to provide a method and apparatus
for update/recovery of a database, using a shadow page method or a failure
recovery method by a database update journal, wherein a plurality of
transactions can update a database or input/output a file at the same
time, and wherein the update results of a database and the update results
of a message or system management information can be validated in
synchronism with each other.
To achieve the above object, the features of the present invention reside
in the provision of a database constructed of pages which are logical
storage locations of data; a backup version page table in a storage for
providing a correspondence between the pages of the database and the slots
in a database storage medium in which the contents of pages to be
recovered, if necessary, are stored; a current version page table for
providing a correspondence between pages updated by a transaction and
slots in the database storage medium wherein the updated contents of the
pages are stored; and a journal file for recording various system
journals; wherein the updated page contents are stored in the database
storage medium at the slots not-used at that time and found with reference
to the backup version page table and the current version page table, the
slots are stored in the current version page table, and the journal record
representative of the updated contents of the current version page table
is fetched into the journal file prior to completion of the transaction.
According to another embodiment of the present invention, a database is
divided into a plurality of sub-areas Backup files each having the content
of each sub-area and differential files each having updated information of
each sub-area sequentially recorded, are provided to thus make it possible
to obtain and analyze in parallel the update journals.
Further, the backup file and the differential file provided for each
sub-area are merged together to reflect the contents of the differential
file to the backup file at a desired time and update it, thereby enhancing
the availability of a database.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 shows the structure of a first embodiment;
FIG. 2 illustrates the backup version page table and the backup version
slot use map according to the present invention;
FIG. 3 illustrates the current version page table and the backup version
slot use map according to the present invention;
FIG. 4 illustrates the journal file according to the present invention;
FIG. 5 shows a process flow for writing an update page according to the
present invention;
FIG. 6 shows a process flow for database recovery at system failure
according to the present invention;
FIG. 7 is a view showing an example of the status of transactions;
FIG. 8 shows the structure of a second embodiment of the present invention;
FIG. 9 shows a process flow at a checkpoint according to the second
embodiment of this invention;
FIG. 10 illustrates validity supervision of a checkpoint according to the
present invention;
FIG. 11 shows the structure of a third embodiment of the present invention;
FIG. 12 shows a process flow at a checkpoint according to the third
embodiment of this invention;
FIG. 13 is a block diagram showing the feature and structure of a fourth
embodiment of this invention; and
FIGS. 14, 15 and 16 show process flows at database update operation,
database failure operation, and backup file update operation, respectively
.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
The first and second problems described above in the shadow page method can
be solved by storing a page table update journal into a journal file.
Namely,
(1) The first problem is solved as follows: instead of validating the page
table update results by status bits, the page table update results
accompanied with update of the database by a transaction are validated by
storing the journal indicating a transaction process end. In case of a
failure, the page table is recovered using the page table update journal
obtained from the journal file.
(2) The second problem is solved by storing into the journal file, the
journal indicating a transaction process end, the update contents of a
terminal message of system management information in the main storage, and
the page table update contents
The third problem described above in the shadow page method is solved by
executing the update of the page tables in a non-volatile medium not for
each transaction but at a checkpoint. In particular,
(3) A current version table is provided in the main storage to update this
current version page table when the database is updated by a transaction.
At a checkpoint, the contents of the current version table are reflected
to a backup version page table in the non-volatile medium, or the
checkpoint dump of the current version page table is fetched into a
checkpoint dump file. Update overhead of the page table in the
non-volatile medium is accordingly reduced to thereby solve the third
problem.
The operation of the above method will be summarized below:
(1) If the database is updated through execution of a transaction, the
current version page table in the main storage is updated, and the slot
storing the contents of an updated page is stored. The update journal of
the current version page table, together with the journal representing the
contents of change by a transaction of a terminal message or system
management information in the main storage, is stored into the journal
file before the transaction has been completely executed.
(2) When the transaction is executed completely, the journal associated
with the transaction and still not fetched is fetched into the journal
file. Thereafter, the journal indicating the transaction process end is
fetched into the journal file. The transaction is considered as having
been completed upon storing the journal so that the database update and
the update of a terminal message or system management information in the
main storage become validated.
(3) At a checkpoint, the contents of the current version page table in the
main storage are written in the backup version page table in the
non-volatile medium, or the checkpoint dump of the current version page
table is fetched into the checkpoint dump file.
(4) If the checkpoint dumps of the backup and current version page tables
are being fetched into the checkpoint dump file when a system failure such
as a power failure occurs, the current version page table is restored,
using the checkpoint dump in the current version page table and the page
table update journal in the journal file, such that only the database
update results by the transaction whose journal indicating the process end
is already fetched, is reflected.
With the operations (1) and (2), even if a plurality of transactions share
the database at a time, the update results of the page table with respect
to the database update by each transaction can be validated independently
from the other transactions, to thereby solve the first problem.
Further, with the operations (1), (2) and (4), the database the process
end, can be validated at a system failure, to thereby solve the second
problem.
Furthermore, with the operations (1) and (3), the current version page
table in the main storage is updated usually during execution of a
transaction, while the backup version page table in the non-volatile
medium is updated only at a checkpoint (or the checkpoint dump of the
current version table is fetched into the checkpoint dump file), to
thereby solve the third problem.
The preferred embodiments of the present invention will be described with
reference to the accompanying drawings.
First, the structure and operation of a first embodiment will be described.
FIG. 1 shows the structure of a first embodiment wherein the gist of the
present invention is illustrated. Referring now to FIG. 1, connected to a
CPU/memory 10 are a database storage medium 50 such as a magnetic disk, a
non-volatile storage medium 100 storing database control information such
as a backup version page table 80 and a backup version slot use map 90,
and a magnetic disk (or magnetic tape) serving as a medium of a journal
file 70. The database area 60 in the database storage medium 50 is divided
into fixed length blocks called slots. A logical space of the database to
be referred to and updated by a transaction is divided into fixed length
areas called pages. A slot is used to store the contents of a page, both
the slot and the page have the same size (for example, 4096 bytes). Each
slot can be referred to or updated by a single input/output operation.
FIG. 2 illustrates the backup version page table 80 and the backup version
slot use map 90. The backup version page table 80 is updated at a
checkpoint to reflect the contents of the current version page table 30 at
that time. Particularly, the backup version page table 80 is set with a
slot number representative of the storage location in the database area 60
of the latest contents of each page at a latest checkpoint. The backup
version slot use map 90 is updated at a checkpoint similar to the case of
the backup version page table 80, the backup version slot map 90 being a
bit map for indicating use or non-use of each slot in the database 60 in
accordance with the current version page table 30 at that time. In
particular, in the backup version slot use map 90, 1 is set at the slot
storing the latest contents of each page at a latest checkpoint, and 0 is
set at the other slots. The backup version page table 80 and the backup
version slot use map 90 are constructed of a plurality of fixed length
(e.g., 512 bytes) blocks 81 and 91, respectively. Each block can be
referred to or updated by a single input/output operation. If a failure
occurs while the backup version page table 80 is under a write operation,
logical integrity of the database is not ensured. To eliminate this
problem, the backup version page table 80 is duplicated such that after a
first write operation is completed in a normal manner, a next write
operation continues with respect to the other backup version page table.
If the first write operation terminates abnormally, the other backup
version page table is used to execute a restore process as of an ordinary
system failure so that logical integrity of the database system can be
ensured. Consequently, in this embodiment, it is assumed that a write
operation of the backup version page table 80 is always completed in a
normal manner. The backup version page table 80 and the backup version
slot use map 90 may be located in the database storage medium 50.
FIG. 3 illustrates the current version page table 30 and the current
version slot use map 40. This database control information is in the
memory 10 during the system operation. The current version page table 30
is updated when the database is updated by a transaction, and is set with
a slot number of the database area 60 in which the updated contents of an
updated page are stored. In particular, the current version page table 30
is set with a slot number storing the latest contents of each page of the
database at any time during the system operation. The current version page
table 30 is constructed of a plurality of fixed length logical blocks 31,
corresponding to the backup version page table 80. In this embodiment, the
memory 10 is assumed to be capable of loading the whole of the current
version page table 30. In the case where this assumption is not permitted,
the blocks of the current version page table 30 except those blocks
including the whole of the page updated by a transaction under execution,
are written in a storage (volatile one may be used) other than the memory
(main storage) by using an LRU algorithm or the like. Thus, the whole of
the current version page table 30 can be considered as substantially in
the memory 10. On the other hand, the current version slot use map 40 is
updated at the time of updating the database by a transaction and at the
time of completing a transaction execution. The current version slot use
map 40 indicates use or non-use of each slot in the database area 60 at
any time during the system operation. The current version slot use map 40
is constructed of a plurality of fixed length logical blocks 41,
corresponding to the backup version slot use map 90. As different from the
backup version slot use map 90, for the current version slot use map 40
not only the slot storing the latest contents of each page in the data
base, but also the slot 61 (called a shadow slot) storing the contents of
the page prior to update by a transaction under execution is made usable.
For the block including the entry corresponding to a shadow slot, there
are provided an ordinary block 41 indicating the slot use status and a
block 42 indicating if each slot is a shadow slot or not.
FIG. 4 illustrates the journal file 70 wherein various system journals are
fetched, such as a page table update journal 71, a transaction process end
journal 72, a terminal message journal 73, and a system management update
journal 74. The page table update journal 71 contains the information such
as an update page number, a slot number storing the contents of the page
prior to update, and a slot number storing the contents of the page after
update.
Next, the system operation will be described. In the following description,
the system operation is classified into a normal operation, a checkpoint
operation, a system failure operation, and a transaction failure
operation.
(1) Normal Operation
The processes according to the present invention are performed in the order
of (a) to (b) from the start to the end of a transaction execution.
(a) Page Read during Execution
The entry of a page is searched in the current version page table 30 to
find a slot number storing the latest contents of the page. The page is
read from the obtained slot.
(b) Update Page Write during Execution
A process flow is shown in FIG. 5 wherein an update page is written in the
database area 60 of the database storage medium 50.
1 First, the shadow slot of the page is checked to see if it exists. The
existence of the shadow slot of the page can be checked based on the
information on the shadow slot stored in the memory 10 to be later
described.
2 If the shadow slot of the page exists at 1, the page has been already
written more than once in the database by transactions. In this case, the
entry of the page is searched in the current version page table 30, and
the contents of the update page are written in the obtained slot.
3 If the shadow slot of the page does not exist at 1, the page is now first
written in the database by a transaction. In this case, the contents of
the update page are written in a new slot by way of the following
procedure, and an old slot is made a shadow slot.
a An idle slot is searched in the current version slot use map 40.
b The contents of the update page are written in the idle slot.
c The entry of the page in the current version page table is updated to set
the number of the new slot. Further, the current version slot use map 40
is updated to make the new slot usable, and the slot storing the contents
of the page prior to update is made a shadow slot.
d The page table update journal, including the page number and the slot
numbers storing the contents of before and after update, is stored in the
memory 10. The fact that a shadow slot exists for the page, and the shadow
slot number, are stored in the memory 10.
(c) Update Page Write upon Issuance of Commit Command
The process (b) is executed, for example, when the database page storage
area of the memory 10 overflows. The present process (c) is a process for
writing all the pages updated by a transaction into the database when a
program executed by the transaction issues a commit command indicating a
transaction process end. The contents of this process are nothing more
than executing the process (b) for each page. If a system failure occurs
during execution of this process, the transaction is considered as not
completed so that the database update results are not considered as valid.
(d) Fetching Page Table Update Journal
The page table update journal stored in the memory 10 is fetched in the
journal file 70 as a page table update journal 71.
The output to an actual medium is performed, together with other journals
such as the ter | | |
