Persistent file system objects for management of databases
In a mirrored database system, a careful write of intentions to perform file system actions is recorded in a persistent file system objects table that is flushed to disk prior to the actions being taken. The table durably and accurately records identities of file system objects that were in use by the database to facilitate creation and deletion of physical file directories and files on a database during crash recovery and during mirror resynchronize. In the event of a failure, crash recovery may quickly and easily identify file system objects which need to be cleaned up by reference to the persistent file system objects table. Similarly, resynchronization of the mirror database can be performed quickly by referring to the persistent file system table data to detect changes since the last database checkpoint.
1. A method of managing file system objects in a database system, comprising:
creating a persistent record in a persistent file system object table of an intention to perform an intended action on a physical file system object in said database system in advance of performing the action, wherein a create intention remembers a file system object which has been created during a user transaction that might abort which will need to be deleted later, a delete intention remembers that a file object was deleted by a transaction and that the file system object needs to be reliably and physically removed after the transaction commits, and said record indicating a state of said physical file system object, wherein said creating comprises writing said record to the persistent file system object table, and performing a careful write of said table to durable storage in advance of performing said action to preserve the persistent record for later use;
updating the indicated state of said physical file system object in said table when the state of said physical file system object changes, wherein upon initiation of a create transaction action to create a file system object, writing an intention record having a create pending state to said table, and, upon said create transaction committing, updating said create pending state in said table to a created state, and upon a drop transaction subsequently committing, writing another intention record having a drop pending state to said table; and
upon a database crash, using said table to identify said physical file system object and to determine whether the intended action was completed on said physical file system object.
2. The method of claim 1 , wherein upon creating said record of said intention to perform said action, indicating said state in said record as being pending, and upon said action being completed on said physical file system object, said updating comprises updating the state of said physical file system object in said table to indicate that the action was completed.
3. The method of claim 1 , wherein upon said create transaction aborting, another intention record having an aborting create state is written to said table.
4. The method of claim 1 , further comprising deleting said physical file system object from the database if it was created by an aborted transaction or deleted by a committed transaction.
5. The method of claim 1 , wherein said database system comprises mirrored primary and mirror databases, said intended action being to create or delete said file system object on said primary database, and said using comprises recreating or deleting another physical file system object on the mirror database during resynchronization that corresponds to the file system object that was created or deleted, respectively, on the primary database.
6. The method of claim 5 , wherein said record identifies the file system object in the primary database and the corresponding file system object in the mirror database, and further indicates a state of said corresponding other file system object in the mirror database.
7. The method of claim 1 , wherein there are a plurality of file system objects in said database system, and wherein there is a separate record in said table for each intended action on each file system object, and wherein, upon said crash, said using comprises using said table to identify each file system object for which there is an intended action that has not been completed.
8. Non-transitory computer readable storage medium comprising executable instructions for controlling a computer system to manage file system objects on a database system, comprising instructions for:
creating a persistent record in a persistent file system object table of an intention to perform an intended action on a physical file system object in said database system in advance of performing the action, wherein a create intention remembers a file system object which has been created during a user transaction that might abort which will need to be deleted later, a delete intention remembers that a file object was deleted by a transaction and that the file system object needs to be reliably and physically removed after the transaction commits, and writing said record to the persistent file system object table and performing a careful write of said table to durable storage in advance of performing said action to create a durable record, said record indicating a state of said physical file system;
updating the indicated state of said physical file system object in said table when the state of said physical file system object changes, wherein, upon initiation of a create transaction to create a file system object, said instructions write an intention record having a create pending state to said table, and, upon said create transaction committing, updating said create pending state to a created state, and wherein upon a drop transaction subsequently committing, writing another intention record having a drop pending state to said table; and
upon a database crash, using said table to identify said physical file system object and to determine whether the intended action was completed on said physical file system object.
9. The non-transitory computer readable storage medium of claim 8 further comprising instructions for writing to said table, upon said create transaction aborting, another intention record having an aborting create state.
10. The non-transitory computer readable storage medium of claim 8 , wherein said executable instructions comprise instructions for deleting said physical file system object from said database if it was created by an aborted transaction or deleted by a committed transaction.
11. The non-transitory computer readable storage medium of claim 8 , wherein said database system comprises mirrored primary and mirror databases, and said instructions for performing an intended action comprise instructions for recreating or deleting another physical file system object on the mirror database during resynchronization that corresponds to the file system object that was created or deleted, respectively, on the primary database.
12. The non-transitory computer readable storage medium of claim 11 , wherein said record identifies the file system object in the primary database and the corresponding file system object in the mirror database, and further indicates a state of said corresponding file system object in the mirror database.
13. The non-transitory computer readable storage medium of claim 8 , wherein there are a plurality of file system objects in said database system, and wherein there is a separate record in said table for each intended action on each file system object, and wherein, upon said crash, said using comprises using said table to identify each file system object for which there is an intended action that has not been completed.