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 computer-implemented method comprising:
maintaining, by a database system, a system catalog comprising a reference to a table of persistent state records, wherein a persistent state record in the table of persistent state records includes a status of a database system object that is a physical file of the database system, and wherein the persistent state record includes a reference to the physical file;
receiving, by a drop transaction of the database system, a request to delete the database system object;
determining, as part of a crash recovery process, that one or more post-commit operations for the drop transaction were not performed before the database system was interrupted, including:
determining, from an entry in a transaction log, that the drop transaction was committed by the database system, wherein the entry in the transaction log identifies the persistent state record of the database system object, and
determining that the status of the database system object in the persistent state record indicates that the database system object has not been deleted;
and
in response to determining that the one or more post-commit operations for the drop transaction were not performed before the database system was interrupted, performing one or more of the post-commit operations including deleting the database system object.
2. The method of claim 1 , further comprising:
receiving, by a create transaction of a database system, a request to create the database system object;
generating the requested database system object; and
generating the persistent state record having a status indicating that the database system object has been created.
3. The method of claim 1 , wherein generating the persistent state record comprises generating the persistent state record before initiating creation of the database system object.
4. The method of claim 1 , wherein the persistent state record has status values for the database system object comprising create pending, created, drop pending, and free.
5. The method of claim 1 , further comprising:
determining that the database system object has no corresponding entry in a system catalog of the database system.
6. A database system comprising:
one or more processors; and
a non-transitory storage device storing instructions operable to cause the one or more processors to perform operations comprising:
maintaining, by a database system, a system catalog comprising a reference to a table of persistent state records, wherein a persistent state record in the table of persistent state records includes a status of a database system object that is a physical file of the database system, and wherein the persistent state record includes a reference to the physical file;
receiving, by a drop transaction of the database system, a request to delete the database system object;
determining, as part of a crash recovery process, that one or more post-commit operations for the drop transaction were not performed before the database system was interrupted, including:
determining, from an entry in a transaction log, that the drop transaction was committed by the database system, wherein the entry in the transaction log identifies the persistent state record of the database system object, and
determining that the status of the database system object in the persistent state record indicates that the database system object has not been deleted;
and
in response to determining that the one or more post-commit operations for the drop transaction were not performed before the database system was interrupted, performing one or more of the post-commit operations including deleting the database system object.
7. The database system of claim 6 , the operations further comprising:
receiving, by a create transaction of a database system, a request to create the database system object;
generating the requested database system object; and
generating the persistent state record having a status indicating that the database system object has been created.
8. The database system of claim 6 , wherein generating the persistent state record comprises generating the persistent state record before initiating creation of the database system object.
9. The database system of claim 6 , wherein the persistent state record has status values for the database system object comprising create pending, created, drop pending, and free.
10. The database system of claim 6 , the operations further comprising:
determining that the database system object has no corresponding entry in a system catalog of the database system.
11. A non-transitory storage device storing instructions operable to cause one or more processors to perform operations comprising:
maintaining, by a database system, a system catalog comprising a reference to a table of persistent state records, wherein a persistent state record in the table of persistent state records includes a status of a database system object that is a physical file of the database system, and wherein the persistent state record includes a reference to the physical file;
receiving, by a drop transaction of the database system, a request to delete the database system object;
determining, as part of a crash recovery process, that one or more post-commit operations for the drop transaction were not performed before the database system was interrupted, including:
determining, from an entry in a transaction log, that the drop transaction was committed by the database system, wherein the entry in the transaction log identifies the persistent state record of the database system object, and
determining that the status of the database system object in the persistent state record indicates that the database system object has not been deleted;
and
in response to determining that that the one or more post-commit operations for the drop transaction were not performed before the database system was interrupted, performing one or more of the post-commit operations including deleting the database system object.
12. The non-transitory storage device of claim 11 , the operations further comprising:
receiving, by a create transaction of a database system, a request to create the database system object;
generating the requested database system object; and
generating the persistent state record having a status indicating that the database system object has been created.
13. The non-transitory storage device of claim 11 , wherein generating the persistent state record comprises generating the persistent state record before initiating creation of the database system object.