Abstract: Recovery of a filesystem directory structure is performed to restore it to any point in time and also to synchronize a database restore and a filesystem restore to bring the two restores to a database consistent state. A database management system (DBMS) manages external files and hierarchical directory structures to enable recovery and reconciliation of the files and filesystems, under DBMS control, after filesystem crashes. First, a database table, which recorded previous directory creations and deletions, is used to rebuild a filesystem's directory structure to any previous database state and then external file link information is used to restore files to that same state.

Abstract: A database management system and associated methods for parallelizing file archival and retrieval in an extended database management system. The system includes a set of copy agents that selectively acquire the backup tasks from a copy queue, and a set of retrieval agents that selectively acquire the restore tasks from a restore queue. The chances of contention between any two copy agents or any two retrieve agents acquiring the same copy or restore task is significantly minimized. Once specific copy agents are assigned backup tasks, the backup process is implemented to determine the optimal way to write the backup files to one or more targets, in parallel. In addition, the present system enables the efficient and expeditious retrieval of the desired files without having to search all the targets.

Abstract: A system and method for updating files in a file system that is linked to a database system which stores metadata pertaining to the files. Changes intended to be made to an original file are written to a replacement file, and when the user is ready to move the changes onto the original file, a database transaction is commenced. If the transaction commits, the replacement file is renamed to the original file and the file security attributes of the original file are applied. Otherwise, the rename operation does not take place, thereby ensuring consistency between the metadata in the dbms system and the file system data that is represented by the metadata.

Abstract: A method and system wherein participant node lists are maintained for each individual transaction. In addition, local nodes maintain participant node lists and provide same to coordinating nodes under certain circumstances. The coordinating nodes merge participant node lists and selectively utilize the lists to minimize message duplication. Further, connection node lists for each application are maintained at coordinating nodes and are utilized for application rollback procedures.

Abstract: A method and system wherein participant node lists are maintained for each individual transaction. In addition, local nodes maintain participant node lists and provide same to coordinating nodes under certain circumstances. The coordinating nodes merge participant node lists and selectively utilize the lists to minimize message duplication. Further, connection node lists for each application are maintained at coordinating nodes and are utilized for application rollback procedures.

Abstract: A three-phase database crash recovery mechanism is detailed including a forward phase, a backward phase, and a third, so-called “sideward” phase for recovery of transactions which were interrupted at the time of the crash, using Global Transaction IDs to track the status of the transactions at the coordinating and at the participating nodes. Depending upon the status of the transaction at the time of the crash, either a query message to the coordinating node or a vote message to the participating nodes is generated and processed, thereby allowing most interrupted transactions to be completed.

Abstract: A method to construct a global equivalent database log file that transforms local log files from a parallel or distributed database system by extracting from each log file sequences of log entries from each database record, breaking the sequences into a series of segments, discarding the bulk of the segments and shortening other segments, then merging the remaining segments into an equivalent log file. The sequences are called "UID-sequences" and the segments "UID-segments" because they relate to one unique record ID or UID. The method also employs backward and forward superposition to further shorten the segments. This method works on database systems with or without instant constraint checks and also provides for treating log entries from multiple adjacent transactions on a log file as a single transaction. In systems with instant constraint checks, this method performs a "unique-key check" and a "foreign-key check" and resolves conflicts that are created because of superposition.

Abstract: A method to construct a transaction serialization order based on parallel or distributed database log files that connects the log files into a network and merges the network into a sequence. Only vote symbols and commit symbols are considered in the construction and a protocol of a transaction's vote appearing before a transaction's commit is enforced. The log files are connected by making links between commit symbols of the same transactions in different log files. The method identifies ambiguities in the orders of the individual log files, called commit symbol cycles, and resolves them by breaking an unsupported segment of the cycle and sliding the segment's forwardmost commit symbol backward to a position immediately prior to the first commit symbol on that segment. By doing so, the serialization implication of an individual log file may be changed, but the overall serialization implication of the database remains intact. Using an iterative process, this method can order the log files in one pass-through.

Abstract: A deadlock detection system and method that checks the state of a lock owning process and the duration of the lock before adding an edge to the wait-for graph. If the lock owning process is not in the wait state and the lock is of medium duration, no edge is added to the wait-for graph.

Abstract: A data processing system and method which manages lock requests at both the transaction and process levels. A lock manager allocates one lock request block (LRB) per process and identifies the ownership of the lock by storing process, transaction and shared IDs in the LRB. The process ID is used to identify which lock to release when a process wants to release the lock before transaction commit while the transaction ID is used to identify all locks to be released at the commit/roll back time of the transaction. The shared ID is a unique value which identifies the lock. The LRB also has a granted transaction mode (GTM) field which stores a value representing the upper bound of the lock modes granted to the transaction. Whenever a lock is granted or released, the GTM of the transaction is recomputed.

Abstract: In a system having producer and consumer processes, a producing process look ahead in its outgoing data stream to ensure that there is data available to consumers on all outgoing streams. The producer looks ahead by keeping a data array in its memory space with an entry for each connected consumer. When the outgoing data stream becomes blocked, the producer searches the array for empty connections. Then, the producer scans the outgoing data stream for messages to send over the empty connections and sends such messages. Periodically, the producer checks the original connection to see if the blocking condition has ended.

Abstract: A method of distributing a set of data among a plurality of disks, which provides for load balancing in the event of a disk failure. In accordance with the method the total number of the disks in an array are divided into a number of clusters. The blocks of data are then stored in each cluster such that each cluster contains a complete set of the data and such that data block placement in each cluster is a unique permutation of the data block placement in the other clusters. In the event of a disk failure, data block accesses to the failed disk are redirected to a disk in the other cluster having a copy of the data block and further access to the disks that remain operational are rebalanced.

Abstract: In a partitioned database system of the Shared Nothing type, one or more secondary replicas of each partition are maintained by spooling (i.e., asynchronously sending) modified (usually called dirty) pages from the primary replica to the secondary replica(s) rather than by using a synchronous page update or by sending log entries instead of entire pages. A Write-Ahead Log protocol is used so that a dirty page is not forced to non-volatile storage until a log record of the modification is created and written to non-volatile storage. Replica updating does not delay the committing of transactions because replica updating is done asynchronously with respect to transaction processing. Since dirty pages are sent rather than only log entries, disk accesses and processing at the secondary replica(s) arising from the maintaining of the replicas are minimized as well. Only one centrally accessible log is maintained for all replicas of the same partition.