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. Consequently, the DBMS may appear to respond poorly to these queries. 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.
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, i.e., placing that shadow object in some other memory location. Concurrently, the DBMS maintains 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 stored in a database of the large-scale database system. Given this scenario, several different users could attempt to access the same database object simultaneously. A database object handle (for example, DB_Obj_Hdl) identifies each object stored in the database. 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).
Assume a particular object, object1 already exists and is stored in a particular file, file1.0. The object handle for object1 is DB_Obj_Hdl=object1 and the file for storing object1 is FS_File_Hdl=file1.0. A local mapping (object1->file1.0) may be maintained by each database agent that had performed input or output (I/O) operations on object1. Where one of the database agents creates a shadow object of object1, a different file, such as file1.1, 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 (file1.1 as opposed to file1.0).
When this database agent has completed acting upon the shadow object, the object is assumed to have changed. To enable access by other database agents to the most up-to-date object, there is a need to perform an object switching transaction, that is, to make the shadow object the real object.
This object switching transaction is performed by informing all other database agents to map object1 to file1.1 rather than to file1.0. Future I/O operations (sometimes called IO operations) performed by any database agents against object1 will therefore be directed to file1.1 instead of being directed to file1.0. Informing other database agents about the switch may be called synchronization. However, an immediate synchronization among all database agents may be extremely expensive to realize when measured in terms of database system performance, especially in a large-scale database system. 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.
Thus, there is need for a system and associated method for monitoring or otherwise providing the location of shadow and real database objects without using synchronization among all database agents. The need for such system and method has heretofore remained unsatisfied.
USPTO Backgrounds
USPTO Backgrounds