Orphan file processing method and device, computer equipment, readable storage medium and program product
By obtaining database tags and combining them with information from various tables to identify orphan files, the problem of inaccurate orphan file processing in existing technologies is solved, achieving accurate processing and improved database performance.
Patent Information
- Application Number
- CN202511775074.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-28
- Publication Date
- 2026-03-03
AI Technical Summary
Existing methods for handling orphan files cannot achieve accurate processing, which can easily lead to omissions or misprocessing, consume disk space, affect database performance, and may even cause database crashes.
By obtaining the target database tags, querying the database directory table and table record table, and combining the local static mapping table and file creation record table, orphan files are identified and processed accurately without affecting the database operation.
It improved the accuracy of orphan file processing, avoided accidental deletion of important files, reduced disk usage, and improved database performance and availability.
Smart Images
Figure CN121597641A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular to an orphan file processing method, apparatus, computer device, computer-readable storage medium, and computer program product. Background Technology
[0002] In PostgreSQL databases, a large number of orphan files exist due to various reasons. These orphan files consume significant disk space and negatively impact database performance. Therefore, it is necessary to handle orphan files.
[0003] In related technologies, the handling of orphan files generally uses the tool oid2name to determine whether a file is an orphan file. The oid2name -f parameter is used to query whether the filename contains information such as oid and relfilenode. If the oid and relfilenode of the file can be found, it is not an orphan file; otherwise, it is.
[0004] However, this orphan file processing method in related technologies cannot achieve accurate processing of orphan files, is prone to omission of orphan files, and is also prone to misprocessing of orphan files. Summary of the Invention
[0005] Therefore, it is necessary to provide a method, apparatus, computer device, computer-readable storage medium, and computer program product for orphan document processing that can improve the accuracy of orphan document processing, in response to the above-mentioned technical problems.
[0006] Firstly, this application provides a method for processing orphan documents, including:
[0007] Obtain orphan file processing instructions. The orphan file processing instructions carry a target database tag, which is used to determine the target database for executing the orphan file processing instructions.
[0008] The database directory table is queried using the target database tags to determine the storage space corresponding to the target database, and the files in the storage space are obtained to obtain the first file dataset;
[0009] Based on the target database tags, determine the corresponding table record table, and determine the target field in the table record table. The field value of the target field matches the field value of the preset field.
[0010] Obtain the files corresponding to the target field to obtain the second file dataset;
[0011] Orphan files are identified based on the first and second file datasets.
[0012] In one embodiment, after obtaining each file in the storage space and obtaining a first file dataset, the orphan file processing method includes: determining the corresponding local static mapping table based on the target database label; determining the file corresponding to the field in the local static mapping table to obtain a third file dataset; wherein, orphan files are also determined based on the third file dataset.
[0013] In one embodiment, after orphan files are identified based on the first file dataset and the second file dataset, the orphan processing method includes: obtaining a file creation record table corresponding to the target database label, and determining a fourth file dataset based on the file creation record table; orphan files are also determined based on the fourth file dataset.
[0014] In an optional embodiment, the method for determining orphan files includes: deleting files included in the second file dataset, the third file dataset, and the fourth file dataset from the first file dataset to obtain the remaining first file dataset, and determining the first file dataset as orphan files.
[0015] In an exemplary embodiment, after determining orphan files based on first file data and second file data, the orphan file processing method includes: when the orphan file's file format is a preset format, adding the orphan file to the fifth file dataset.
[0016] In one embodiment, after adding orphan files to the fifth file dataset, the method includes: creating a temporary directory, adding file tags from the fifth file dataset to the temporary directory; and deleting orphan files from the fifth file dataset if removing orphan files from the fifth file dataset does not affect the operation of the target database.
[0017] Secondly, this application also provides an orphan document processing apparatus, comprising:
[0018] The instruction acquisition module is used to acquire orphan file processing instructions. The orphan file processing instructions carry a target database tag, which is used to determine the target database for executing the orphan file processing instructions.
[0019] The first data determination module is used to query the database directory table using the target database label, determine the storage space corresponding to the target database, and obtain each file in the storage space to obtain the first file dataset.
[0020] The target field determination module is used to determine the corresponding table record table based on the target database label, and to determine the target field in the table record table. The target field matches the field value of the preset field.
[0021] The second data determination module is used to obtain the files corresponding to the target field and obtain the second file dataset.
[0022] The orphan file identification module is used to identify orphan files based on the first file dataset and the second file dataset.
[0023] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the above-described method embodiments.
[0024] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method embodiments.
[0025] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described method embodiments.
[0026] The aforementioned orphan file processing methods, apparatus, computer equipment, computer-readable storage media, and computer program products traverse the storage space where orphan files may exist, effectively ensuring the accuracy of the obtained orphan files. Attached Figure Description
[0027] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0028] Figure 1 This is an application environment diagram of an orphan file processing method in one embodiment;
[0029] Figure 2 This is a flowchart illustrating an orphan file processing method in one embodiment;
[0030] Figure 3 This is a flowchart illustrating an orphan file processing method in another embodiment;
[0031] Figure 4 This is a structural block diagram of an orphan file processing device in one embodiment;
[0032] Figure 5 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation
[0033] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.
[0034] In PostgreSQL databases, there are a large number of orphan files due to a variety of reasons.
[0035] For example, suppose a table `a` is created using the `CTAS` statement. If the backend process executing the `CTAS` statement is terminated for some reason before the creation is committed, table `a` is not created, and no record for `a` can be found in the table record table (`pg_class`). However, a file named `orphan_a` exists on the disk, storing the data for table `a`. This file can be called an orphan file, and table `a` is an orphan table. Another example is when a transaction is explicitly started using the `begin` command in a session. Table `b` is then created within the transaction, and data is inserted into it. Before the transaction is committed, the current session process crashes for some reason. Upon logging back into the database, it is found that there are no records for table `b` in the table record table (`pg_class`), but a data file named `orphan_b` for table `b` exists on the disk. This file `orphan_b` is also an orphan file, and table `b` is also an orphan table.
[0036] Understandably, the more data a table records, the more storage space it occupies, and consequently, the more storage space orphan files on the disk will require. For example, if table 'a' created using the CTAS statement records a large amount of data, table 'a' will require a large amount of storage space, and thus, the orphan files on the disk will also require a large amount of storage space.
[0037] Therefore, orphan files can consume a significant amount of disk space, posing a clear drawback. At best, this affects disk I / O performance and degrades database performance; some database systems are even configured to stop write services when a certain amount of disk space remains. In extreme cases, when orphan files fill the disk, the database system may crash, becoming unavailable and impacting availability. It can also affect database backup services, leading to data loss.
[0038] In related technologies, the handling of orphan files is generally done by using the officially provided tool oid2name to determine whether a file is an orphan file.
[0039] Optionally, when using the oid2name tool to process orphan files, you can use the oid2name -f parameter to query whether the file name contains information such as oid and relfilenode. If the oid and relfilenode of the file can be found, it is not an orphan file; otherwise, it can be considered an orphan file.
[0040] However, this method is prone to errors in high-concurrency scenarios. For example, transaction A uses the CTAS statement to create a large table `orphan_c`. The table creation process takes a long time, and the transaction hasn't been committed yet. At this point, table `orphan_c` already has its data file on disk and is visible to all users. Transaction B happens to be checking if `orphan_c` is an orphan table at this time. Because transaction A hasn't committed, transaction B cannot find the `oid` and `relfileode` information of `orphan_c` using the `oid2name` tool, and will mistakenly classify `orphan_c` as an orphan table. This will lead to the deletion of the actual table data file, impacting business operations.
[0041] To address one of the aforementioned technical problems, the orphan file processing method provided in this application embodiment can be applied to, for example... Figure 1In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104 or placed on a cloud or other network server. The server receives orphan file processing instructions transmitted by the terminal. These instructions carry a target database tag, which is used to determine the target database for executing the orphan file processing instructions. The server uses the target database tag to query the database directory table, determines the storage space corresponding to the target database, and retrieves each file in the storage space to obtain a first file dataset. Based on the target database tag, the server determines the corresponding table record table and the target field in the table record table, matching the field value of the target field with the field value of a preset field. The server retrieves each file corresponding to the target field to obtain a second file dataset. Based on the first and second file datasets, the orphan files are identified. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can be smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, projection devices, etc. Portable wearable devices can be smartwatches, smart bracelets, head-mounted devices, etc. Headset devices can be virtual reality (VR) devices, augmented reality (AR) devices, smart glasses, etc. Server 104 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.
[0042] In one exemplary embodiment, such as Figure 2 As shown, an orphan file processing method is provided, which is applied to... Figure 1 Taking the server in the example, the explanation includes the following steps 202 to 210. Wherein:
[0043] Step 202: Obtain orphan file processing instructions.
[0044] Orphan files are used to represent files that exist on the disk but are not recorded in the database directory table (pg_database).
[0045] In one embodiment, orphan file processing instructions may carry target database tags.
[0046] The target database label is used to determine the target database for executing orphan file processing instructions.
[0047] In one embodiment, orphan file processing instructions can be generated by the terminal and sent to the server.
[0048] For example, a user uses a terminal to determine the target database to be processed. After obtaining the target database, the terminal determines the target database tag corresponding to the target database and encapsulates the target database tag into an orphan file processing instruction.
[0049] In one embodiment, orphan file processing instructions can also be triggered periodically by the server.
[0050] For example, orphan files can be processed at fixed time periods each day.
[0051] In one alternative embodiment, different processing times can be set for different databases.
[0052] For example, assuming there are a first database, a second database, and a third database, the first database can be set to process orphan files in the first time period of each day, the second database to process orphan files in the second time period of each day, and the third database to process orphan files in the third time period of each day. The first time period, the second time period, and the third time period can be different or the same.
[0053] In one embodiment, processing time can be set to correspond with database tags. When the processing time is reached, the target database tag corresponding to the processing time is determined according to the correspondence, and orphan file processing instructions can be generated based on the target database tag.
[0054] In one embodiment, orphan files can be processed using interface functions, for example, obtaining orphan files corresponding to target database tags.
[0055] In an optional embodiment, when orphan files need to be processed in the database, an interface function is called to perform the orphan file processing. For example, the interface function can be called periodically to perform orphan file processing.
[0056] In one embodiment, after the interface function obtains the target data tag carried in the orphan file processing instruction, it retrieves the orphan file based on the target database tag.
[0057] Step 204: Use the target database label to query the database directory table, determine the storage space corresponding to the target database, and obtain each file in the storage space to obtain the first file dataset.
[0058] The database directory table (pg_database) is a system directory table that represents the PostgreSQL (Object-Relational Database Management System) cluster database and can be used to record each database in the PostgreSQL cluster database.
[0059] Optionally, the database includes database tags to distinguish different databases. Understandably, the database currently being processed can be identified as the target database, and the corresponding database tag is the target database tag.
[0060] In one embodiment, the naming method for database tags is not limited. For example, it can use numbers, letters, or a combination of numbers and letters, as long as it can distinguish between databases.
[0061] In one embodiment, after obtaining the orphan file processing instruction, the target database tag is obtained from the orphan file processing instruction, and the target database table is traversed using the target database tag to determine the target database corresponding to the target database tag.
[0062] Optionally, after identifying the target database, the storage space corresponding to the target database can also be determined based on the target database label.
[0063] The storage space is used to store the table data files corresponding to the target database.
[0064] Among them, the table data file is used to represent the file stored on the disk that corresponds to the data table.
[0065] In one embodiment, the storage space of the target database can be obtained using a link path. Optionally, the link path may include an absolute path, or a combination of an absolute path and a relative path.
[0066] Optionally, after obtaining the target database label, the default tablespace (dattablespace) and object identifier (oid) corresponding to the target database label are retrieved from the database directory table, where the object identifier is used to determine the attributes of the default tablespace. For example, if the object identifier is 1663, the attribute of the default tablespace can be determined to be the base tablespace (the database's built-in tablespace).
[0067] In an optional embodiment, if the default tablespace is the `base` tablespace, the absolute path and relative path can be concatenated to obtain the link path of the storage space. For example, the relative path `database_relative_path` is ". / base / $oid", and the absolute path `database_absolute_path` is "$data_directory / base / $oid", where `data_directory` is the data directory specified by the database system in the `guc` parameter.
[0068] In one embodiment, after determining the storage space using the link path, each file can be retrieved from the storage space, and a first file dataset can be generated based on each file.
[0069] Understandably, to facilitate data processing (such as performing read and write operations), in PostgreSQL databases, table data files for each database are stored in the same directory. Optionally, if the table file is large, for example, if the table file occupies more than 1GB of storage, it will be split into multiple files no larger than 1GB and stored separately. In this case, when retrieving each file from the storage space, it is also necessary to pay attention to each of the split files.
[0070] For example, filenames can be used to retrieve the files of each split data table.
[0071] Optionally, the split file name can be "table name.number", for example, the large table 54343 (1.5G) will be split into 54343 and 54343.1.
[0072] Optionally, if the table data has undergone operations such as vacuuming and truncate, fsm and vm files will also be generated. When retrieving each file from the storage space, it is also necessary to retrieve these files to ensure the completeness of the retrieved files, thereby making the identification of orphan files more accurate.
[0073] In one embodiment, filenames can also be used to distinguish between files. The filenames can be "table name.file type", for example, 54343.fsm and 54343.vm.
[0074] In an optional embodiment, the `pg_ls_dir` function is used to find all files in the storage space corresponding to the linked path, obtain the filenames of each file, and use a matching method to retrieve the desired file. Optionally, the matching method can be regular expression matching.
[0075] In one embodiment, the required files can be obtained by using a matching method to obtain files whose filenames consist of numbers, and these obtained files form the first file dataset.
[0076] Step 206: Based on the target database label, determine the corresponding table record table and the target field in the table record table. The field value of the target field matches the field value of the preset field.
[0077] Step 208: Obtain the files corresponding to the target field to obtain the second file dataset.
[0078] The table record table (pg_class) is used to record table data in the target database.
[0079] In one embodiment, the table of records can be traversed, and when the field value of a field in the table of records matches the field value of a preset field, that field is set as the target field.
[0080] For example, the default field can be relfilenode.
[0081] In this context, relfilenode is an identifier used in PostgreSQL to locate the data file of a database table. Optionally, relfilenode can be an integer identifier.
[0082] In one embodiment, the target field can be a field where relfilenode is not zero.
[0083] In one embodiment, each file under the target field is obtained and recorded as a second file dataset.
[0084] In an optional embodiment, all files under the target field can be obtained, and the relfilenode of all files under the target field can be matched with the relfilenode of each file in the first file dataset. If a match is found, the matched file is recorded as the second file dataset.
[0085] Step 210: Identify orphan files based on the first file dataset and the second file dataset.
[0086] In one embodiment, the remaining file data in the first file dataset after removing the second file dataset from the first file dataset can be considered as orphan files.
[0087] Optionally, there may be one or more orphan files.
[0088] In an alternative embodiment, orphan files may be further processed, such as by deleting them.
[0089] Optionally, you can first simulate whether deleting orphan files will affect the database; if there is no impact, then delete them.
[0090] For example, a temporary directory is created, and file tags from the fifth file dataset are added to the temporary directory. If the removal of orphan files from the fifth file dataset does not affect the operation of the target database, then the file can be deleted.
[0091] In one embodiment, the fifth file dataset may be determined based on the file format of the orphan files.
[0092] For example, after obtaining the orphan file, it can be determined whether the file format of the orphan file is a preset format. When the file format of the orphan file is a preset format, the orphan file is added to the fifth file dataset.
[0093] For example, orphan files can be in the format of .fsm, .vm, or table data files, and can be added to the fifth file dataset.
[0094] In one embodiment, orphan files can also be determined based on a third file dataset.
[0095] Optionally, determining the third file dataset may include: determining the corresponding local static mapping table based on the target database labels; determining the files corresponding to the fields in the local static mapping table to obtain the third file dataset.
[0096] The local static mapping table (pg_filenode.map) is used to hard map the logical identifiers of system tables or indexes to the current disk filename.
[0097] Optionally, the local static mapping table can be traversed to determine the files corresponding to the target fields in the local static mapping table, and these files can be recorded as a third file dataset.
[0098] In one embodiment, the target field can also be the field when the preset field is zero. Optionally, the preset field can be relfilenode.
[0099] Optionally, the target field can be selected from the local static mapping table, and the corresponding file name can be determined according to the determined target field. The local storage space can be traversed according to the file name, and each file can be obtained from the local storage space. The obtained files are recorded as a third dataset.
[0100] In an optional embodiment, the determination of orphan files may also be based on a third file dataset, which may include: determining orphan files based on a first file dataset, a second file dataset, and a third file dataset. For example, after deleting the second file dataset and the third file dataset from the first file dataset, the remaining first file dataset is the orphan file.
[0101] In one embodiment, orphan files can also be determined based on a fourth file dataset.
[0102] Optionally, determining the fourth file dataset may include: obtaining the file creation record table corresponding to the target database label, and determining the fourth file dataset based on the file creation record table.
[0103] The file creation record table (creating_relation hash table) is used to record the files that are currently being created in the target database but are not recorded in the table record table.
[0104] Optionally, after obtaining the target database tag, the corresponding file creation record table is obtained using the target database tag, and the file being created is obtained based on the file creation record table.
[0105] For example, the file tags of the files being created can be obtained from the file creation record table, the files being created can be obtained using the file tags, and a fourth file dataset can be generated based on the obtained files.
[0106] In an optional embodiment, the determination of orphan files may also be based on a fourth file dataset, which may include: determining orphan files based on a first file dataset, a second file dataset, a third file dataset, and a fourth file dataset. For example, after deleting files included in the second file dataset, the third file dataset, and the fourth file dataset from the first file dataset, the remaining first file dataset is obtained, and the remaining first file dataset is determined to be orphan files.
[0107] In the above-described orphan file processing method, creating an interface function to process orphan files ensures the accuracy of the processing results and does not affect the current database processing progress. Furthermore, in the above embodiments, traversing the storage space where orphan files may exist effectively guarantees the accuracy of the obtained orphan files.
[0108] In one exemplary embodiment, such as Figure 3 As shown, an orphan file processing method is provided, which is applied to... Figure 1 Taking the server in the example, the explanation includes the following steps 302 to 322. Wherein:
[0109] Step 302: Obtain orphan file processing instructions.
[0110] Optionally, the orphan file processing instructions carry a target database tag.
[0111] The target database label is used to determine the target database for executing orphan file processing instructions.
[0112] Step 304: Use the target database label to query the database directory table, determine the storage space corresponding to the target database, and obtain each file in the storage space to obtain the first file dataset.
[0113] Step 306: Based on the target database label, determine the corresponding table record table and the target field in the table record table. The target field matches the field value of the preset field.
[0114] Step 308: Obtain the files corresponding to the target field to obtain the second file dataset.
[0115] Step 310: Determine the corresponding local static mapping table based on the target database label.
[0116] Step 312: Determine the file corresponding to the field in the local static mapping table to obtain the third file dataset.
[0117] Step 314: Obtain the file creation record table corresponding to the target database label, and determine the fourth file dataset based on the file creation record table.
[0118] Step 316: After deleting the files included in the second file dataset, the third file dataset, and the fourth file dataset from the first file dataset, the remaining first file dataset is obtained, and the remaining first file dataset is identified as orphan files.
[0119] Step 318: When the orphan file is in the preset format, add the orphan file to the fifth file dataset.
[0120] Step 320: Create a temporary directory and add the file tags from the fifth file dataset to the temporary directory.
[0121] Step 322: If removing orphan files from the fifth file dataset does not affect the operation of the target database, then delete the orphan files from the fifth file dataset.
[0122] In the above-described orphan file processing method, creating an interface function to process orphan files ensures the accuracy of the processing results and does not affect the current database processing progress. Furthermore, in the above embodiments, traversing the storage space where orphan files may exist effectively guarantees the accuracy of the obtained orphan files.
[0123] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.
[0124] Based on the same inventive concept, this application also provides an orphan file processing apparatus for implementing the orphan file processing method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more orphan file processing apparatus embodiments provided below can be found in the limitations of the orphan file processing method described above, and will not be repeated here.
[0125] In one exemplary embodiment, such as Figure 4 As shown, an orphan file processing device 400 is provided, including: an instruction acquisition module 402, a first data determination module 404, a target field determination module 406, a second data determination module 408, and an orphan file determination module 410, wherein:
[0126] The instruction acquisition module 402 is used to acquire orphan file processing instructions. The orphan file processing instructions carry a target database tag, which is used to determine the target database for executing the orphan file processing instructions.
[0127] The first data determination module 404 is used to query the database directory table using the target database label, determine the storage space corresponding to the target database, and obtain each file in the storage space to obtain the first file dataset.
[0128] The target field determination module 406 is used to determine the corresponding table record table based on the target database label, and to determine the target field in the table record table, wherein the field value of the target field matches that of the preset field.
[0129] The second data determination module 408 is used to obtain the files corresponding to the target field and obtain the second file dataset.
[0130] The orphan file identification module 410 is used to identify orphan files based on the first file dataset and the second file dataset.
[0131] In one embodiment, the orphan file processing apparatus further includes a third data determination module, configured to determine the corresponding local static mapping table based on the target database label; determine the file corresponding to the field in the local static mapping table to obtain a third file dataset; wherein the orphan file is further determined based on the third file dataset.
[0132] In one embodiment, the orphan file processing apparatus further includes a fourth data determination module, used to obtain a file creation record table corresponding to the target database tag, and determine a fourth file dataset based on the file creation record table; orphan files are also determined based on the fourth file dataset.
[0133] In one embodiment, the orphan file determination module is further configured to delete files included in the second file dataset, the third file dataset, and the fourth file dataset from the first file dataset to obtain the remaining first file dataset, and to determine the remaining first file dataset as orphan files.
[0134] In an optional embodiment, the orphan file processing apparatus further includes a fifth data determination module, used to add the orphan file to the fifth file dataset when the orphan file's file format is a preset format.
[0135] In one exemplary embodiment, the orphan file processing apparatus further includes a deletion module for creating a temporary directory and adding file tags from the fifth file dataset to the temporary directory; if the removal of orphan files from the fifth file dataset does not affect the operation of the target database, then the orphan files in the fifth file dataset are deleted.
[0136] Each module in the aforementioned orphan document processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the corresponding operations of each module.
[0137] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 5As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When executed by the processor, the computer program implements an orphan file processing method.
[0138] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.
[0139] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the above-described method embodiments.
[0140] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method embodiments.
[0141] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the above-described method embodiments.
[0142] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.
[0143] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.
[0144] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.
[0145] The above embodiments are merely illustrative of several implementation methods of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.
Claims
1. A method for processing orphan documents, characterized in that, The method includes: Obtain orphan file processing instructions, wherein the orphan file processing instructions carry a target database tag, and the target database tag is used to determine the target database for executing the orphan file processing instructions; The target database label is used to query the database directory table to determine the storage space corresponding to the target database, and each file in the storage space is obtained to obtain the first file dataset; Based on the target database tags, determine the corresponding table record table, and determine the target field in the table record table, wherein the target field matches the field value of the preset field; Obtain the files corresponding to the target field to obtain the second file dataset; Orphan files are identified based on the first and second file datasets.
2. The method according to claim 1, characterized in that, After obtaining the first file dataset by retrieving each file from the storage space, the method further includes: Based on the target database tags, determine the corresponding local static mapping table; The files corresponding to the fields in the local static mapping table are determined to obtain a third file dataset; wherein, the orphan files are further determined based on the third file dataset.
3. The method according to claim 2, characterized in that, After identifying orphan files based on the first file dataset and the second file dataset, the method further includes: Obtain the file creation record table corresponding to the target database tag, and determine the fourth file dataset based on the file creation record table; the orphan file is also determined based on the fourth file dataset.
4. The method according to claim 3, characterized in that, The methods for determining orphan documents include: After deleting the files included in the second file dataset, the third file dataset, and the fourth file dataset from the first file dataset, the remaining first file dataset is obtained, and the remaining first file dataset is identified as the orphan files.
5. The method according to claim 1, characterized in that, After determining the orphan file based on the first file data and the second file data, the method includes: When the orphan file is in a preset format, the orphan file is added to the fifth file dataset.
6. The method according to claim 5, characterized in that, After adding the orphan files to the fifth file dataset, the method includes: Create a temporary directory and add the file tags from the fifth file dataset to the temporary directory; If removing orphan files from the fifth file dataset does not affect the operation of the target database, then the orphan files in the fifth file dataset are deleted.
7. An orphan document processing device, characterized in that, The device includes: The instruction acquisition module is used to acquire orphan file processing instructions, wherein the orphan file processing instructions carry a target database tag, and the target database tag is used to determine the target database for executing the orphan file processing instructions; The first data determination module is used to query the database directory table using the target database label, determine the storage space corresponding to the target database, and obtain each file in the storage space to obtain the first file dataset. The target field determination module is used to determine the corresponding table record table based on the target database label, and to determine the target field in the table record table, wherein the target field matches the field value of a preset field; The second data determination module is used to obtain each file corresponding to the target field to obtain the second file dataset. The orphan file identification module is used to identify orphan files based on the first file dataset and the second file dataset.
8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.
9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.
10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.