CA2422161C

CA2422161C - Decoupled object identification for object switching in database systems

Info

Publication number: CA2422161C
Application number: CA002422161A
Authority: CA
Inventors: Leo Tat Man Lau; Robert T. Berks; Miroslaw A. Flasza; Matthew A. Huras; Keriley K. Romanufa; Aamer Sachedina; Michael J. Winer
Original assignee: IBM Canada Ltd
Current assignee: IBM Canada Ltd
Priority date: 2003-03-14
Filing date: 2003-03-14
Publication date: 2009-10-06
Anticipated expiration: 2023-03-14
Also published as: US7099889B2; CA2422161A1; US20040220940A1

Abstract

The use of a centralized version table allows for efficient object switching. Rather than synchronizing all database agents to recognize a newly created file as containing the most recent version of a given object, database agents requiring access to the given object need only consult the centralized version table to learn file identity information. That is, the database agents consult the centralized version table to determine which of the files associated with a given object contain the most recent version of the given object. Mechanisms associated with the use of the centralized version table also provide for efficient recovery from a failure that has occurred during an object switching transaction.

Description

DECOUPLED OBJECT IDENTIFICATION FOR OBJECT SWITCHING IN
DATABASE SYSTEMS
FIELD OF THE INVENTION
The present invention relates to object switching in database systems and, in particular, to decoupled object identification for such object switching.
BACKGROUND OF THE INVENTION
Data object shadowing is a known method for directing a database management system (DBMS) operating on a data processing system to switch objects in a database stored in a memory associated with that data processing system. However, known data object shadowing methods used by the DBMS (in response to queries being processed by that DBMS) cause the interaction between the DBMS and the database to slow down, and thus the DBMS may appear to respond poorly to these queries (that is, in this sense, the DBMS working in conjunction with the database is said to suffer from "low availability").
This is a significant drawback for users that desire "high availability" from DBMSs operating with databases.
It will be appreciated that the operational combination of a DBMS operating with a database may be called a database system). The combination of known data object shadowing methods and other DBMS operations (such as data loading or index reorganization) can create and build a shadow object on the side (that is, that shadow object is placed in some other memory location), while maintaining an original object that is continuously made available to users during the entire duration of the DBMS
operation. At some future time, the DBMS operation may include steps for replacing the shadow object with the original object so that the shadow object then becomes what may be called the "real" object. This process of allowing a shadow object to become a real object may be called "object switching".
In a large scale database system, there may be hundreds of agents working concurrently. Each agent is likely working for a different user to access data (such as objects) being stored in a database of the large scale database system. Given this scenario, several different users could try to access the same database object simultaneously. Each object stored in the database is identified by a database object handle (for example, DB Obj Hdl). Eventually, data are stored in a file system of the large scale database system. Each file is identified in the file system by a file handle (for example, FS File_Hdl). As such, database agents may maintain a local mapping of a database object handle to a file handle (such as, DB_Obj Hdl to FS File_Hdl).
Assuming a particular object, objectl (the object handle for objectl is DB Obj Hdl = object 1 ), already exists and is stored in a particular file, file 1.0 (the file for storing objectl is FS File_Hdl = filel.0), a local mapping (objectl ->
filel.0) may be maintained by each database agent that had performed input or output (I/O) operations on objectl. Where one of the database agents creates a shadow object of objectl, a different file, say, filel.l, must be used to store this shadow object in the file system. Note that the physical file name containing the object is coupled to the version of the object (filel.l as opposed to fi1e1.0). When this database agent has completed acting upon the shadow object, the object is assumed to have changed. So that the other database agents can access the most up-to-date object, there is a need to perform an object switching transaction, that is, to make the shadow object into the real object. This is performed by informing all other database agents to map objectl to filel.l rather than to filelØ Future I/O operations (sometimes called IO operations) performed by any database agents against objectl will therefore be directed to filel.l instead of being directed to filelØ
Informing other database agents about the switch may be called synchronization.
Unfortunately, an immediate synchronization among all database agents may be extremely expensive to realize (that is, extra processing time is expended by the DBMS
to effect the synchronization, that is to make each agent aware of the current "real" data object) when measured in terms of database system performance (especially in a large scale database system).
Accordingly, a solution that addresses, at least in part, this and other shortcomings is desired.
SUMMARY OF THE INVENTION
The present invention provides a method for directing a DBMS (operating from memory associated with a data processing system) to switch a shadow data object identification with a real data object identification (the shadow data object associated with the real data object), the shadow object and the real object stored in a database (which is stored in the memory), and the DBMS is adapted to serve agents requesting access to the current data object (the operational steps or method steps are elaborated upon in further detail below), whereby processing effort exerted by the data processing system is reduced when the DBMS synchronizes (that is, informs) the agents that a valid real object identification is the shadow data object identification and not the real data object identification.
By decoupling the versioning from the physical file name and through the introduction of a centralized version table, explicit synchronization among all database agents may be eliminated. The explicit synchronization may be eliminated by preventing database agents from performing IO operations against a given object while an object switching transaction is taking place on the given object. Once the object switching transaction is complete, any database agents who need to perform IO operations against the given object will find that the given object has been switched and that an indication of the new version is available in the centralized version table. This may be termed a lazy approach. Basically, it is up to the database agents who need to perform IO
operations against a given database object to consult the centralized version table to learn a current Version ID for the given database object. Advantageously, those database agents who will never need to perform another IO operation against the switched object need not learn that the object has been switched.
Also advantageously, embodiments of this invention do not require synchronization amongst all agents. The approach of one aspect of the present invention allows each database agent to learn that an object has been switched on the next access of that object. Furthermore, in an aspect of the present invention, an object switching transaction may be performed on a given object in a fixed number of instructions regardless the size of the given object.
In accordance with an aspect of the present invention there is provided, for a database management system adapted to manage a database storing a given database object, wherein multiple versions of the given database object may be stored in a plurality of files, each of the plurality of files having a file handle, and where an object handle for the given database object is related to a first one of the file handles, a method of switching.
The method of switching includes locating an indication of a version of the first one of the file handles related to the object handle for the given database object, preventing database agents from accessing the indication of the version and changing the indication of the version to a value that indicates a second one of the file handles.
Further, a database management system is provided for carrying out this method and a computer readable medium is provided for allowing a general purpose computer to perform this method.
In accordance with an aspect of the present invention, there is provided, for a database management system adapted to manage a database storing a given database object, wherein multiple versions of the given database object may be stored in a plurality of files, each of the plurality of files having a file handle, and where an object handle for the given database object is related to a first one of the file handles, a method of switching including: locating an indication of a version of the first one of the file handles related to the object handle for the given database object; preventing database agents from accessing the indication of the version; and changing the indication of the version to a value that indicates a second one of the file handles.
In accordance with another aspect of the present invention, there is provided a database management system adapted to manage a database storing a given database object, wherein multiple versions of the given database object may be stored in a plurality of files, each of the plurality of files having a file handle, and where an object handle for the given database object is related to a first one of the file handles, the database management system including: means for locating an indication of a version of the first one of the file handles related to the object handle for the given database object; means for preventing database agents from accessing the indication of the version;
and means for changing the indication of the version to a value that indicates a second one of the file handles.
In accordance with yet another aspect of the present invention, there is provided a computer program product having a computer readable medium tangibly embodying computer executable code for directing a database management system to manage a database storing a given database object, wherein multiple versions of the given database object may be stored in a plurality of files, each of the plurality of files having a file handle, and where an object handle for the given database object is related to a first one of the file handles, the computer program product including: code for locating an indication of a version of the first one of the file handles related to the object handle for the given database object; code for preventing database agents from accessing the indication of the version; and code for changing the indication of the version to a value that indicates a second one of the file handles.
In accordance with yet another aspect of the present invention, there is provided, for a database management system adapted to manage a database storing a plurality of database objects, wherein multiple versions of database objects may be stored in a plurality of files, each of the plurality of files having a file handle, a method of activating a database instance including scanning a tablespace directory for evidence of object shadowing, where the evidence of object shadowing is an association of at least two files with a given database object among the plurality of database objects;
selecting a database object for which evidence of object shadowing has been found, thereby giving a selected database object, the selected database object having at least two associated files;
attempting to read sequence information and object marking indications from the at least two associated files; and determining which of the at least two associated files contains a current version of the selected database object based on the sequence information and object marking indications.
In accordance with yet another aspect of the present invention, there is provided a database management system adapted to manage a database storing a plurality of database objects, wherein multiple versions of database objects are stored in a plurality of files, each of the plurality of files having a file handle, the database management system for activating a database instance, the database management system including:
means for scanning a tablespace directory for evidence of object shadowing, where the evidence of object shadowing is an association of at least two files with a given database object among the plurality of database objects; means for selecting a database object for which evidence of object shadowing has been found, thereby giving a selected database object, the selected database object having at least two associated files; means for attempting to read sequence information and object marking indications from the at least two associated files; and means for determining which of the at least two associated files contains a current version of the selected database object based on the sequence information and object marking indications.
In accordance with yet another aspect of the present invention, there is provided a computer program product having a computer readable medium tangibly embodying computer executable code for directing a database management system adapted to manage a database storing a plurality of database objects, wherein multiple versions of database objects are stored in a plurality of files, each of the plurality of files having a file handle, the database management system for activating a database instance, the computer program product including: code for scanning a tablespace directory for evidence of object shadowing, where the evidence of object shadowing is an association of at least two files with a given database object among the plurality of database objects; code for selecting a database object for which evidence of object shadowing has been found, thereby giving a selected database object, the selected database object having at least two associated files; code for attempting to read sequence information and object marking indications from the at least two associated files; and code for determining which of the at least two associated files contains a current version of the selected database object based on the sequence information and object marking indications.
Other aspects and features of the present invention will become apparent to those of ordinary skill in the art upon review of the following description of specific embodiments of the invention in conjunction with the accompanying figures.
BRIEF DESCRIPTION OF THE DRAWINGS
In the figures which illustrate example embodiments of this invention:
FIG. 1 illustrates an exemplary database system for use with embodiments of the present invention, the exemplary database system including a table manager and a plurality of database agents;
FIG. 2 illustrates the exemplary database system of FIG. 1, wherein a shadow object has been created;
FIG. 3 illustrates the exemplary database system of FIG. 1, wherein the shadow object of FIG. is accessed by all database agents;

FIG. 4 illustrates steps in a method undertaken at the table manager, included in the exemplary database system of FIG. 1, in relation to the creation of a shadow object;
FIG. 5 illustrates steps in a method undertaken at a database agent, the method for accessing an object according to an embodiment of the present invention;
FIG. 6 illustrates steps in a method of performing an object switching transaction;
and FIG. 7 illustrates steps in a method of activating a database and marking version files according to an embodiment of the present invention.
DETAILED DESCRIPTION
The following detailed description of the embodiments of the present invention does not limit the implementation of the invention to any particular computer programming language. The present invention may be implemented in any computer programming language provided that the Operating System (OS) provides the facilities that may support the requirements of the present invention. An embodiment may be implemented in the C or C++ computer programming language (or other computer programming languages in conjunction with C/C++). Any limitations presented would be a result of a particular type of operating system, computer programming language, or data processing system, and would not be a limitation of the present invention.
FIG. 1 illustrates an exemplary database system 100 with a CPU 104, a bus 106, an input/output (I/O) module 108 and a memory 102. Via the bus 106 and the I/O
module 108, the CPU may communicate with a monitor and keyboard 112 and a storage media 110. Furthermore, the CPU 104 may access the memory 102 via the bus 106. The memory 102 includes a database 114 and an associated database management system (DBMS) 116. The database 114 is accessed by three database agents: a first agent 126A;
a second agent 126B; and a third agent 126C (collectively or individually 126). The database 114 includes an original file 122 storing an object with an object ID
of 1502.
The original file 122 has file name of "1502-0". The database 114 also includes a lookup table 124. Accordingly, the DBMS 116 includes a table manager 120 for managing the lookup table 124 and a restore manager 118.

The exemplary database system 100 may be loaded with software for executing methods exemplary of this invention from the storage media 110 which could be a disk, a tape, a chip or a random access memory containing a file downloaded from a remote source.
The lookup table 124 is introduced as a centralized version table to keep track of versioning information. The lookup table 124 includes so-called "version tuples". Each version tuple includes an object handle entry and a version entry, i.e., (DB
Obj Hdl, Version_ID). The Version ID found in the version entry indicates the current version for the object indicated by the handle in the object handle entry. In one embodiment of the -present invention, Version ID may take a value of either value 0 or 1. In the file system, each database object could reside in one of two files, namely, filen.0 or filen.l. In future discussion, "0" will refer to filen.0 and "1" will refer to filen.l. Note that 0 does not necessarily mean "current" version. Similarly, 1 does not necessarily mean "shadow"
version. The Version ID is introduced to decouple the versioning from the physical file name. In addition to the centralized version table, each agent may manage an associated local database object to file handle mapping with the addition of Version ID.
The mapping becomes (DB Obj Hdl, Version ID -> FS File_Hdl). Therefore, for a given database object, each agent could record at most two file handles, one for Version ID 0 and one for Version >D 1.
In the examples discussed herein, only two values are used for Version ID, namely 0 and 1. Note that version 0 does not necessarily refer to the current version, nor does version 1 necessarily refer to the shadow version. It is the current Version ID stored in the version entry of the version tuple that indicates to the database agents 126 which version is the current version of a given object. The lookup table stores information relating to all the objects that have been versioned. If a version tuple does not exist in the lookup table for a given object, the current Version ID for the given object, when created, may be defaulted to 0.
As will be apparent to a person skilled in the art, the version indication (Version ID) need not be limited to binary (i.e., 0 and 1). There may be multiple versions of an object created and the table manager 120 need only be adapted to maintain a version indication for the file version of the current object in the lookup table 124. That is, the version indication will indicate to database agents the file version containing the most up-to-date object for which any changes are complete.
Before any IO operations may be performed against a given database object, the database agent 126 that is to perform the IO operation locates a version tuple, in the lookup table 124, that corresponds to the given database object. Once the version tuple is located, the version tuple may be locked in a SHARED mode. Locking the version tuple in a SHARED mode can prevent the table manager 120 from trying to perform an object switching transaction on the database object before the IO operation is complete. Once the SHARED lock is acquired (i.e., the version tuple is locked in SHARED mode) by one database agent 126, an other database agent 126 that is required to performing IO
operations consults the lookup table 124 to determine which Version ID should be used.
If the other database agent 126 is to perform an IO operation on an original object, the other database agent 126 accesses the file having the Version ID found in the lookup table 124. If the other database agent 126 is to perform an IO operation on a shadow object, the other database agent 126 toggles the Version ID found in the lookup table 124 and accesses the file having the toggled Version ID.
Once the Version ID is determined, the determined Version_ID may be used with the DB Obj Hdl to learn the corresponding FS File Hdl. The database agent 126 may the perform IO operation against the file with the corresponding FS File_Hdl.
When the IO operation is complete, the version tuple may be unlocked so that other database agents 126 may perform an object switching transaction if necessary.
Before performing an object switching transaction on a given database object, the table manager 120 determines whether a version tuple exists in the lookup table 124. If a version tuple does not yet exist, the table manager 120 creates a version tuple for the given database object. Once the version tuple has been created, the table manager 120 locates the version tuple and attempts to acquire an EXCLUSIVE lock on the version tuple. Locking the version tuple in EXCLUSIVE mode involves (i) waiting for all existing IO operations (against the given database object) to finish and (ii) preventing any new IO operations (against the given database object) from starting. Once the EXCLUSIVE lock is acquired, the Version )D in the version entry of the version tuple is toggled, i.e., _changed from 0 to 1 or changed from 1 to 0. Once the Version ID has been toggled, the object switching transaction is complete. The version tuple is then unlocked so that IO operations may be performed against the given database object.
By decoupling the versioning from the physical file name and through the introduction of a centralized version table (the lookup table 124), explicit synchronization among all database agents 126 may be eliminated. The explicit synchronization may be eliminated by preventing database agents 126 from performing IO operations against a given object while the object switching transaction is taking place on the given object.
Once the object switching transaction is complete, any database agents 126 who need to perform IO operations against the given object will find that the given object has been switched and that an indication of the new version is available in the lookup table 124.
This may be termed a lazy approach. Basically, it is up to the database agents 126 who need to perform IO operations against a given database object to consult the lookup table 124 to learn a current Version ID. Those database agents 126 who will never need to perform another IO operation against the switched object need not learn that the object has been switched.
In addition, the time taken to perform the object switching transaction does not depend on the size of the object. After the lock is acquired in EXCLUSIVE
mode, only a couple of instructions are required to toggle the Version ID.
In a database system, database objects are logically identified by object IDs and object IDs are used to map an object to a physical storage location for the object (a file in this example). In embodiments of the present invention, the use of Version ID
allows each object ID to be mapped to multiple physical storage locations. The use of the shared lookup table not only allows new versions to be created and updated without cross-agent synchronization, but also allows the version switching to appear instantaneous.
FIG. 4 illustrates steps of a method undertaken at the table manager 120 in relation to the creation of a shadow object. Initially, the identification parameters, i.e., the object ID and the file name, of an object that is to be the subject of an object switching transaction (i.e., the object stored in the original file 122) are determined (step S404). If the identification parameters are not already in the lookup table 124, the table manager 120 places these identification parameters into the lookup table 124 (step S406). Some time is then allowed to pass to wait for the creation of a shadow (update) object (say, by the third agent 126C), which is then stored in a secondary file 202 (see FIG.

2) having identification parameters associated with those of the original file 122 (step 5408). Once the table manager 120 has determined that the shadow object has been created, the secondary file 202 may be marked GOOD and COMMIT PENDING (step 5410). Note that, at this point, the original file 122 stores the current object and the secondary file 202 stores the shadow object.
It should be understood that the creation of the shadow object often, but not always, involves creating a copy of the original object and then updating the object in some way. If, for instance, the object is an index to a table in the database, new records may be placed in the table, and the index object may be rebuilt to reflect the table including the new records. As rebuilding an index object may take some time, the creation of a shadow object allows IO access to the original object while the shadow object is subject to the rebuilding. Alternatively, the creation of the shadow object may involve re-creating an index without adding or updating any existing values.
The purpose of doing so is to re-cluster the data so that related data are physically closer together.
Once the table manager 120 learns that the update to the shadow object is complete, the table manager 120 may acquire an EXCLUSIVE lock on the version tuple related to the shadow object (step S412) so that no agents 126 may access the object stored in either the original file 122 or the secondary file 202. The table manager 120 then performs an object switching transaction as will be described hereinafter in conjunction with FIG. 6.
When the object switching transaction is complete, the EXCLUSIVE lock may then be removed from the version tuple (step S420). Note that, at this point, the original file 122 stores the shadow object and the secondary file 202 stores the current object.
It is then determined whether a new shadow object is to be created (step S422). If a new shadow object is to be created, the process returns to step S404 wherein the identification parameters of the object for which a shadow is required are determined.
Otherwise, the process is complete.
The following describes three scenarios including a scenario wherein the first agent 126A accesses the original file 122, a scenario wherein the third agent 126C creates a shadow version of the original file 122 and a scenario wherein a hardware failure has occurred in the middle of an object switching operation and the restore manager 118 completes the object switching operation after the database instance is restarted.
(1) Accessing a database obiect As illustrated by the initial step in the flow diagram of FIG. S, the Version_ID of S object 1502 is, by default, set to 0 (step SS04). The Version ID is later used, in combination with the object ID, to determine a physical object storage location. Where it is determined (step SS06) that the first agent 126A needs to access the original file 122, the lookup table 124 is accessed to determine the current Version ID of the original file 122 (step 5508). In other words, the lookup table 124 is searched for a version tuple with object ID of 1 S02 in the object handle entry. If the object ID is determined (step SS 10) not to have been found in the lookup table 124, the default Version_ID (0) may be used.
If it is determined (step SS06) that the first agent 126A does not need to access the original file 122, the process is complete.
Objects are not forced to have a version tuple in the lookup table 124. In fact, it 1S may be that only the objects that had been versioned before or are being versioned will have a version tuple in the lookup table 124. The practice of forcing only the versioned objects to have a version tuple in the lookup table 124 may be established to minimize storage requirements and lookup time.
If a version tuple having the object m of the object in the object handle entry is ~ determined (step SS 10) to have been found in the lookup table 124, the Version 1D of the object is assigned the value of the Version_ID found in the version tuple. The first version tuple in the lookup table 124 of the database 114 illustrated in FIG.
1 relates to the object as the object ID 1502 is present in the object handle entry. In this case, the value of the Version 1D found in the version entry of the version tuple is 0 and the Version_ID of the object is set to 0.
It may then be determined whether the first agent 126A requires access to a shadow object of object 1502. If it is determined (step SS14) that the first agent 126A requires access to a shadow object, the Version_ID of the object to be accessed by the first agent 126A is set to a shadow ID (step SS 16). That is, the Version ID of the object to be accessed by the first agent 126A is assigned the "flipped" value of current Version_ID
found in the version tuple in the lookup table 124. The flipped value is 0 if the value in the version tuple in the lookup table 124 is 1 and the flipped value is 1 if the value in the version tuple in the lookup table 124 is 0.
Where the first agent 126A requires access to a shadow object, the first agent 126A may use a combination of object 1D (1502) and the Version_ID (since the Version ID in the lookup table 124 is 0, the Version_ID of the shadow is 1) to construct a file name ("1502-1"), which may be used to access the shadow object (stored in the secondary file 202) of object 1502 (step 5518).
~2) Versionin;~ a database ob'L
Consider the scenario wherein the third agent 126C needs to create a shadow version of object 1502.
As discussed in conjunction with FIG. 4, when the third agent 126C needs to create a shadow version of object 1502 and a version tuple does not exist in the lookup table 124 corresponding to object 1502, the table manager 120 creates a new version tuple for object 1502 in the lookup table 124 (step S406, FIG. 4) with the current Version_I17 set to 0. Subsequently, the third agent 126C creates a new file.
This new file, illustrated as the secondary file 202 in FIG. 2, is initially marked BAD to indicate that the new file is not ready to be used.
There are two main reasons to create a version tuple at this point, rather than the point at which commit processing (to be discussed hereinafter) is complete:
firstly, it is desirable to avoid failure of the commit processing due to lack of resources, such as the necessary shared memory to create the version tuple, at the commit time;
secondly, the new version tuple allows the third agent 126C to access the shadow object. As described hereinbefore, before a database agent 126 may determine a physical storage location (file) of a shadow object, the database agent 126 must first locate the appropriate version tuple in the lookup table 124 and flip the current Version_ID found in the version entry. As such, the lookup table 124 is setup to allow other agents, such as the first agent 126A and the second agent 126B, to access the current version of object 1502 stored in the original file 122 while, at the same time, the third agent 126C is allowed to access the shadow version of object 1502 stored in the secondary file 202.
When the third agent 126C has created (and updated) a shadow version of object 1502 in the newly created secondary file 202, the secondary file 202 may be marked GOOD and COMMTT PENDING. The secondary file 202 may be marked GOOD to indicate that it stores the most up-to-date version of object 1502 and is ready to be switched to become the current object. Additionally, the secondary file 202 may be marked COMMIT PENDING to indicate that an object switching transaction remains to be performed. Before the actual object switching transaction takes place, the table manager 120 acquires an EXCLUSIVE lock on the version tuple related to object (step S412, FIG. 4). Holding such an EXCLUSIVE lock has the effect of making the table manager 120 the only element in the entire database system 100 that can access object 1502. That is, no agents 126 can access either the current version or the shadow version of object 1502.
After the EXCLUSIVE lock is acquired, each of the actions required to perform the object switching transaction may be stored in a pending-list inside a commit log record. The pending-list is so named because the pending actions listed are required to be executed before the transaction can successfully commit. Notably, if an error occurs during the execution of any of these pending actions, the table manager 120 will neither be able to commit nor rollback the object switching transaction. The table manager 120 may re-try the pending actions until every pending action is completed successfully. The object switching transaction "commit process" begins when a commit log record is written to disk. Subsequently, the pending-list is executed sequentially.
(Note, the next section will describe what will happen if any unforeseen failures such as hardware or power failures occurred between the commit log record was written and all the pending actions were successfully carried out.) FIG. 6 illustrates the actions used to perform the object switching transaction.
Within the database, a Log Sequence Number (LSN) is used to maintain an indication of the age of logs related to files. In particular, a "COMMTT" LSN refers to the LSN used for the commit log record and a "PAGE" LSN is the LSN of the latest log record written associated with a given page. As will be apparent to a person skilled in the art, a page is page is the smallest unit of consecutive bytes.
The object switching transaction begins with a determination of whether the shadow object (stored in the secondary file 202 in the present example) can be accessed and whether the COMMIT LSN of the secondary file 202 is greater than the PAGE
LSN

of the secondary file 202 (step 5604). If the shadow object can be accessed and the COMMIT LSN is greater than the PAGE LSN, the COMMIT PENDING state of the secondary file 202 is removed and the PAGE LSN of the secondary file 202 is updated (step S606) to the value of the COMMIT LSN.
If either the shadow object can not be accessed or the COMMIT LSN of the secondary file 202 is less than the PAGE LSN of the secondary file 202 (or both), it is determined whether the COMMIT LSN is greater than the PAGE LSN (step S608). If the COMMTT LSN is greater than the PAGE LSN, the file containing the current object (the original file 122) is marked BAD and the PAGE LSN of the original file 122 is updated (step 5610). Subsequently, the file containing the current version of the object (the original file 122) is truncated to zero length (step S612). If the shadow object can not be accessed and the COMMIT LSN is less than the PAGE LSN, the object switching transaction is complete.
The version tuple for object 1502 is then located in the lookup table and the current Version ID is toggled (step S614) to indicate that the version has been updated.
In this example, the updated current Version_ID is toggled to end up as "1"
(see FIG. 3).
Finally, the EXCLUSIVE lock on the version tuple related to object 1502 may be released (step S616) and any agent who would like to access object 1502 may learn that the current version is "1" which is stored in the secondary file 202 (file name "1502-1"), instead of the original file 122 (file name "1502-0"). Note that not only is the cost of the object switching transaction invariant on the size of the shadow object, but also, the object switching transaction may be seen to be performed almost instantaneously. In addition, synchronization is not required between the third agent 126C (the agent that created the shadow object) and the first agent 126A or the second agent 126B
that previously had access to the older version of object 1502. When the first agent 126A or the second agent 126B later try to access object 1502 again, it will be found that the Version ID in the version entry associated with object 1502 is set to 1. As a result, the secondary file 202 will be accessed instead of the original file 122 (as shown in FIG. 3).
It is possible that object 1502 is versioned again before the first agent 126A
makes its next access. At that time, the current Version ID located inside the version entry will be set to 0 and the file with the file name "1502-0" (the original file 122) will be used again to store the current object of object 1502.

(3) Failure-recover~for object switching Between the time at which the commit log record is written and the time at which all the pending actions have been executed successfully, failures, such as in hardware or power, can bring down the database manager instance. The following outlines the role played by the lookup table 124 in a recovery from a failure and the completion of the object switching transaction when the database manager instance is restarted.
It may be considered that in a system employing embodiments of the present invention, once the commit log record is written, the object switching transaction is guaranteed to be successful. Failure-recovery of an object switching transaction is broken down into 2 steps: 1) rebuilding the lookup table 124 (FIG. 7); 2) continuing the object switching transaction (FIG. 6).
As a failure recovery begins, the database is activated. As part of the database activation, the tablespace directory is scanned to look for version "1" files.
As will be apparent to a person skilled in the art, a tablespace directory is a location memory where all files for the same tablespace may be found. It should be understood, by now, that these version "1" files do not necessarily represent shadow objects. The fact that a file has a version number of "1" indicates that the current version of object 1502 is physically stored in the version "1" file instead of the version "0" file. Since the default version value is 0 when no version tuple is found in the lookup table, there is no need for action if no version "1" files exist. After a version "1" file is located within the tablespace directory, both the version "0" file and the version "1" file may be accessed to retrieve two attributes, namely the PAGE LSN and the object flags. Using the following four rules in combination with these two attributes, the restore manager 118 can distinguish between the file that stores the shadow version of object 1502 and the file that stores the current version of object 1502:
1 ) If the version "0" file cannot be opened, or if both attributes can be read from both version files but the version "0" file is marked BAD, then the version "0" file cannot be used. In the latter case, the version "1" file is checked for a mark of BAD. If the version "1" file is not marked BAD, then the version "1" file can be considered to store the current version of object 1502. Accordingly, a version tuple may be created in the lookup table 124 to indicate that the current Version_ID is "I". Otherwise, the version "0" file will be assumed to store the current version of object 1502 (but no entry will be created in the lookup table 124).
2) If the version "1" file cannot be opened, the version "0" file will be assumed to store the current version of object 1502 without a version tuple being created in the lookup table 124.
3) If both attributes can be read from both files and the version "0" file is marked GOOD, but the version "1" file is marked BAD, then the version "1" file may be deleted and a new version tuple is not needed in the lookup table 124 because the default will use version "0" anyway.

4) If both attributes can be read from both files and both files are marked GOOD:
n If one of the files is marked as "COMMIT PENDING", then the marked file may be considered to store the shadow version of object 1502 and a version tuple may be created in the lookup table 124 indicating the appropriate version.
II) If neither of the files is marked with "COMMIT PENDING", the PAGE LSN
may be used to determine which file stores the shadow version by comparison.
If the PAGE LSN of the version "0" file is greater that the PAGE LSN of the version "1" file, then the version "0" file stores the shadow version of object 1502. Otherwise, if the PAGE LSN of the version "1" file is greater than the PAGE LSN of the version "0" file, then the version "1" file may be considered to store the shadow version of object 1502. It should be understood that these rules do not allow for both version files to have the same PAGE LSN.

After the scanning of the tablespace directory is finished, the lookup table 124 is updated to reflect which file stores a shadow version of a corresponding object and which file stores the current version of the corresponding object. The object switching transaction may then be continued from where the transaction left off before the failure.
FIG. 7 illustrates the implementation of these four rules. In step 5702, the database is activated. It is then determined whether there are tablespace directories to scan (step S704). If there are tablespace directories to scan, one tablespace directory is selected and it is determined (step 5706) whether the selected tablespace directory associates any objects with a Version ID of 1. If the selected tablespace directory does not associate any objects with a Version_ID of 1, step S704 is repeated, i.e., it is determined whether there are any more tablespace directories to scan. If there are no more tablespace directories to scan, the recovery-marking procedure is complete.
If the selected tablespace directory does associate at least one object with a Version_ID
of l, it is considered that at least one object has two version files (a first version file and a second version file). One of the objects having two version files is selected and an attempt is made to read the PAGE LSN and object flags from both version files (step S710). If it is determined that the first version file cannot be opened (step S712), it is further determined whether the second version file is marked BAD (step S736).
If the second version file is marked BAD, the first version file is marked as the storing the shadow object (step S738), i.e., the current Version_ID in the lookup table is set to point to the second version file. Step 5706 is then repeated to determined whether the selected tablespace directory has any further second version files to consider.
If it is determined that the first version file can be opened (step S712), it is further determined whether the second version file can be opened (step S714). If it is determined that the second version file cannot be opened, no marking is required and step 5706 is repeated. If it is determined that the second version file can be opened, it is determined whether the first version file is marked BAD (step S716). If the first version file is marked BAD, it is determined whether the second version file is marked BAD
(step 5736). If the second version file is determined in step S736 to be marked BAD, the first version file is marked as the storing the shadow object (step 5738), i.e., the current Version_ID in the lookup table is set to point to the second version file.
Step 5706 is then repeated to determine whether the selected tablespace directory has any further second version files to consider.
If the first version file is determined, in step S716, not to be marked BAD, it is determined whether the second version file is marked BAD (step S718).
If the second version file is determined, in step S718, to be marked BAD, the second version file is deleted (step 5720). Step 5706 is then repeated to determine whether the selected tablespace directory has any further second version files to consider. If the second version file is determined, in step S718, not to be marked BAD, it is determined whether the first version file is marked COMMIT PENDING (step S722).
If it is determined that the first version file is marked COMMIT PENDING, the first version file is marked as storing the shadow object (step 5738) and step 5706 is repeated. If it is determined that the first version file is not marked COMMIT
PENDING, it is determined whether the second version file is marked COMMIT PENDING
(step S724).
If it is determined that the second version file is marked COMMIT PENDING, the second version file is marked as storing the shadow object (step 5734), i.e., the current Version ID in the lookup table is set to point to the first version file, and step S706 is repeated. If it is determined that the second version file is not marked COMMIT
PENDING, it is determined whether the PAGE LSN of the first version file is greater than the PAGE LSN of the second version file (step S730).
If it is determined that the PAGE LSN of the first version file is greater than the PAGE LSN of the second version file, the first version file is marked as storing the shadow object (step 5738) and step S706 is repeated. Otherwise the second version file is marked as storing the shadow object (step S734) and step 5706 is repeated.
The object switching algorithm has already been described hereinbefore in conjunction with FIG. 6. The object switching algorithm is revisited hereinafter in the context of failure recovery. Failures are considered at each segment of the logic and the restart logic is explained.
Removing the COMMIT PENDING state and undatin~ the PAGE LSN to the COMMIT
LSN (step 5606):

Step 5606 represents the last update that needs to be done on the secondary file 202 before the object stored in the secondary file 202 can truly become the current object.
The rest of the logic of the object switching transaction (steps S610, S612 and S614) are updates to the current version and the lookup table 124 to reflect the object switching.
Step S606 is only triggered if the PAGE LSN of the secondary file 202 is smaller then the COMMTT LSN to avoid repeating this segment on a different object if the failure occurred much later in the commit processing. If the failure happened before step 5606 is completed, the COMMIT PENDING state of the secondary file 202 is used (step S724) to determine which file contains the shadow version of the object. The object switching transaction may then be restarted from the beginning. However, if the failure happened right after step S606 is completed, the COMMTT PENDING state will have been removed and the PAGE LSN of the object will be updated (increased). Therefore, the relative PAGE LSN of the version files is used (step S730) to determine which file contains the shadow version of the object at the restart time. As such, steps S604 and 5606 are not repeated when the object switching transaction continues, as the PAGE LSN
comparison has already taken place. The object switching transaction may be entered directly at step S610.
Marking the ale containing the current version of the obiect BAD and updating the PAGE LSN to the COMMTT LSN of the current version~step S610):
Step S610 is used to mark the file containing the current version of the object BAD and is only executed if the PAGE LSN of that file is smaller then the COMMIT
LSN of that file. If the failure happened before step 5610 is finished, the file containing the current version of the object may still be marked GOOD and the PAGE LSN of the file may not have been updated. Therefore, steps S722, 5724 and S730 may distinguish between files containing shadow and current versions of the object. Then, the object switching transaction may be entered directly at step S610. The need to execute steps 5604 and S606 is obviated because the PAGE LSN of the file containing shadow version of the object has already been increased. If the failure happened just right after step S610 is completed, the update to both the current and the shadow versions are completely done.
The logic represented by steps S716 and 5718 will appropriately select the shadow version to become the current version when the database manager is restarted.

Truncating the current version to zero len tg h (step S612):
Step 5612 is used to return the physical storage back to the file system. On restart, step 5612 is only executed if the PAGE LSN of the file containing the object is smaller then the COMMIT LSN of that file.
Toggling the current Version >D in the version tuple found in the lookup table (step S614):
Step S614 is used to update the centralized lookup table so that subsequent access to object 1502 will consider the current version to be 1 instead of 0. Step S610 is also only executed if the PAGE LSN of the file containing the object is smaller then the COMMIT LSN of that file.
It will be appreciated that an aspect of the invention is a computer program product having a computer-readable medium tangibly embodying computer executable instructions for directing a data processing system to implement any method described hereinbefore. It will be appreciated that the computer program product may be stored on a floppy disk, hard disk or other medium for long term storage of the computer executable instructions.
It will also be appreciated that an aspect of the invention is an article having a computer-readable signal-bearing medium, and having means in the medium for directing a data processing system to implement any method described hereinbefore. It will be appreciated that a supplier of the method may upload the article to a network (such as the Internet) and users may download the article via the network to their respective data processing systems.
It will be appreciated that variations of some elements are possible to adapt the invention for specific conditions or functions. The concepts of the present invention can be further extended to a variety of other applications that are clearly within the scope of this invention. Having thus described the present invention with respect to a preferred embodiment as implemented, it will be apparent to those skilled in the art that many modifications and enhancements are possible to the present invention without departing from the basic concepts as described in the preferred embodiment of the present invention. Therefore, what is intended to be protected by way of letters patent should be limited only by the scope of the following claims.

Claims

The embodiments of the invention in which an exclusive property or privilege is claimed are defined as follows:

1. For a database management system adapted to manage a database storing a given database object, wherein multiple versions of said given database object may be stored in a plurality of files, each of said plurality of files having a file handle, and wherein an object handle for said given database object is related to a first one of said file handles, a method of switching comprising:
locating an indication of a version of said first one of said file handles related to said object handle for said given database object;
preventing database agents from accessing said indication of said version; and changing said indication of said version to a value that indicates a second one of said file handles.

2. The method of claim 1 further comprising providing a version tuple for associating said indication of said version with said object handle for said given database object.

3. The method of claim 2 wherein:
said version tuple is stored in a centralized version table; and said locating includes searching said centralized version table for the version tuple that includes said object handle for said given database object.

4. The method of claim 3 further comprising:
determining whether said version tuple that includes said object handle for said given database object exists in said centralized version table; and creating a new version tuple that includes said object handle for said given database object where said version tuple that includes said object handle for said given database object does not exist.

5. The method of claim 3 wherein said preventing includes acquiring an exclusive lock on said version tuple.

6. The method of claim 5 wherein said acquiring said exclusive lock includes:
waiting for existing input and output operations against said given database object to finish; and preventing new input and output operations against said given database object from starting.

7. The method of claim 5 further comprising releasing said exclusive lock from said version tuple so that new input and output operations against said given database object may be performed by said database agents.

8. The method of claim 1 wherein:
said indication of said version is binary; and said changing comprises toggling the value of said indication of said version.

9. A database management system adapted to manage a database storing a given database object, wherein multiple versions of said given database object may be stored in a plurality of files, each of said plurality of files having a file handle, and where an object handle for said given database object is related to a first one of said file handles, said database management system comprising:
means for locating an indication of a version of said first one of said file handles related to said object handle for said given database object;
means for preventing database agents from accessing said indication of said version; and means for changing said indication of said version to a value that indicates a second one of said file handles.

10. The database management system of claim 9 further comprising means for providing a version tuple for associating said indication of said version with said object handle for said given database object.

11. The database management system of claim 10 wherein:
said version tuple is stored in a centralized version table; and said means for locating includes searching said centralized version table for the version tuple that includes said object handle for said given database object.

12. The database management system of claim 11 further comprising:
means for determining whether said version tuple that includes said object handle for said given database object exists in said centralized version table; and means for creating a new version tuple that includes said object handle for said given database object where said version tuple that includes said object handle for said given database object does not exist.

13. The database management system of claim 11 wherein said means for preventing includes acquiring an exclusive lock on said version tuple.

14. The database management system of claim 13 wherein said means for acquiring said exclusive lock includes:
means for waiting for existing input and output operations against said given database object to finish; and means for preventing new input and output operations against said given database object from starting.

15. The database management system of claim 13 further comprising means for releasing said exclusive lock from said version tuple so that new input and output operations against said given database object may be performed by said database agents.

16. The database management system of claim 9 wherein:
said indication of said version is binary; and said means for changing includes toggling the value of said indication of said version.

17. A computer program product having a computer readable medium tangibly embodying computer executable code for directing a database management system to manage a database storing a given database object, wherein multiple versions of said given database object may be stored in a plurality of files, each of said plurality of files having a file handle, and where an object handle for said given database object is related to a first one of said file handles, said computer program product comprising:
code for locating an indication of a version of said first one of said file handles related to said object handle for said given database object;
code for preventing database agents from accessing said indication of said version;
and code for changing said indication of said version to a value that indicates a second one of said file handles.

18. The computer program product of claim 17 further comprising code for providing a version tuple for associating said indication of said version with said object handle for said given database object.

19. The computer program product of claim 18 wherein:
said version tuple is stored in a centralized version table; and said code for locating includes searching said centralized version table for the version tuple that includes said object handle for said given database object.

20. The computer program product of claim 19 further comprising:
code for determining whether said version tuple that includes said object handle for said given database object exists in said centralized version table; and code for creating a new version tuple that includes said object handle for said given database object where said version tuple that includes said object handle for said given database object does not exist.

21. The computer program product of claim 19 wherein said code for preventing includes acquiring an exclusive lock on said version tuple.

22. The computer program product of claim 21 wherein said code for acquiring said exclusive lock includes:
waiting for existing input and output operations against said given database object to finish; and preventing new input and output operations against said given database object from starting.

23. The computer program product of claim 21 further comprising code for releasing said exclusive lock from said version tuple so that new input and output operations against said given database object may be performed by said database agents.

24. The computer program product of claim 17 wherein:
said indication of said version is binary; and said code for changing includes toggling the value of said indication of said version.

25. For a database management system adapted to manage a database storing a plurality of database objects, wherein multiple versions of database objects may be stored in a plurality of files, each of said plurality of files having a file handle, a method of activating a database instance comprising:
scanning a tablespace directory for evidence of object shadowing, where said evidence of object shadowing is an association of at least two files with a given database object among said plurality of database objects;
selecting a database object for which evidence of object shadowing has been found, thereby giving a selected database object, said selected database object having at least two associated files;
attempting to read sequence information and object marking indications from said at least two associated files; and determining which of said at least two associated files contains a current version of said selected database object based on said sequence information and object marking indications.

26. The method of claim 25further comprising, based on said sequence information and said object marking indications:
determining that a failure has occurred during an object switching transaction; and determining a logical segment of said object switching transaction at which to resume said object switching transaction.

27. A database management system adapted to manage a database storing a plurality of database objects, wherein multiple versions of database objects are stored in a plurality of files, each of said plurality of files having a file handle, said database management system for activating a database instance, the database management system comprising:
means for scanning a tablespace directory for evidence of object shadowing, where said evidence of object shadowing is an association of at least two files with a given database object among said plurality of database objects;
means for selecting a database object for which evidence of object shadowing has been found, thereby giving a selected database object, said selected database object having at least two associated files;
means for attempting to read sequence information and object marking indications from said at least two associated files; and means for determining which of said at least two associated files contains a current version of said selected database object based on said sequence information and object marking indications.

28. The database management system of claim 27 further comprising, based on said sequence information and said object marking indications:
means for determining that a failure has occurred during an object switching transaction; and means for determining a logical segment of said object switching transaction at which to resume said object switching transaction.

29. A computer program product having a computer readable medium tangibly embodying computer executable code for directing a database management system adapted to manage a database storing a plurality of database objects, wherein multiple versions of database objects are stored in a plurality of files, each of said plurality of files having a file handle, said database management system for activating a database instance, the computer program product comprising:
code for scanning a tablespace directory for evidence of object shadowing, where said evidence of object shadowing is an association of at least two files with a given database object among said plurality of database objects;
code for selecting a database object for which evidence of object shadowing has been found, thereby giving a selected database object, said selected database object having at least two associated files;
code for attempting to read sequence information and object marking indications from said at least two associated files; and code for determining which of said at least two associated files contains a current version of said selected database object based on said sequence information and object marking indications.

30. The computer program product of claim 29 further comprising, based on said sequence information and said object marking indications:
code for determining that a failure has occurred during an object switching transaction; and code for determining a logical segment of said object switching transaction at which to resume said object switching transaction.