Method, medium, product and device for managing meta information during database playback

Abstract

This invention provides a method, medium, product, and device for managing metadata during database playback. The method includes: responding to an initiated capture conversion command, generating a start marker file and writing start metadata; the capture conversion command is used to capture and convert the load information of the source database; during the capture conversion process, writing the load information of the source database and the metadata from the capture process into a session data file; when the capture conversion process ends, generating an end marker file and writing end metadata; uniformly storing the start marker file, end marker file, and session data file to generate a capture set; and performing database playback operations based on the capture set. This method enables full lifecycle management of metadata for heterogeneous database load capture, effectively ensuring the integrity and traceability of the captured dataset, while providing accurate performance indicator comparisons for subsequent playback stages.

Description

Technical Field

[0001] This invention relates to the field of database technology, and in particular to a method, medium, product, and device for managing metadata during database playback. Background Technology

[0002] Currently, the database market in key domestic industries such as finance and telecommunications is still dominated by foreign products such as Oracle and MySQL, resulting in a deep technological dependence. Driven by the information technology innovation policy, enterprises hope to achieve domestic database substitution at the lowest cost, but they still face three major challenges: domestic databases still lag behind mainstream international products in terms of performance and compatibility; testing environments are difficult to realistically reproduce complex production scenarios; and manual migration methods are inefficient and prone to errors. To address these challenges, heterogeneous database replay technology has emerged as a key solution. This technology captures real production workloads for precise testing, and combined with replay and comparative analysis, it can efficiently identify potential performance bottlenecks and compatibility issues after migration.

[0003] Traditional solutions focus solely on collecting load data such as user sessions and SQL requests, generating numerous session data files without uniformly generating, storing, or managing metadata during the capture process. The system fails to record crucial contextual information such as capture start and end status, source database version, character set, load intensity, and concurrency, and lacks an effective mechanism for verifying the integrity of the capture process. When capture is abnormally interrupted, the system cannot quickly identify data validity, easily leading to incomplete load data entering the replay process, severely reducing test reliability.

[0004] Meanwhile, due to the lack of standardized metadata file structures and storage specifications, metadata is often mixed in with load logs, making it impossible to achieve unified association and traceability of capture sets. During the playback phase, the lack of capture-side performance metrics and environmental information makes it difficult to accurately compare with playback-side metrics, resulting in playback reports failing to truly reflect post-migration performance bottlenecks and compatibility issues.

[0005] The aforementioned issues result in insufficient authenticity, completeness, and quantifiable analytical capabilities for heterogeneous database replays, making it difficult to meet the high-fidelity and robust migration verification requirements of key industries. Therefore, how to achieve full lifecycle management of captured metadata to support load integrity verification and accurate replay comparison has become a pressing technical problem to be solved in this field. Summary of the Invention

[0006] In view of the above problems, the present invention proposes a method, medium, product and equipment for managing metadata during database playback to overcome or at least partially solve the above problems.

[0007] One objective of this invention is to address the problems of insufficient integrity verification, reduced playback authenticity, and inability to compare core indicators caused by missing metadata in traditional heterogeneous database replay technology.

[0008] A further objective of this invention is to achieve accurate comparison of performance indicators before and after playback based on captured metadata, thereby improving the authenticity and quantifiable analysis capabilities of heterogeneous database migration verification.

[0009] Specifically, the present invention provides a method for managing metadata during database playback, comprising: In response to the initiated capture and transformation command, a starting marker file is generated and starting metadata is written. The capture and transformation command is used to capture the load information of the source database and perform transformation. During the capture and transformation process, the load information of the source database and the metadata of the capture process are written to the session data file; When the capture conversion process is finished, an end marker file is generated and end metadata is written; The start marker file, end marker file, and session data file are stored uniformly to generate a capture set; Perform database replay operations based on the capture set.

[0010] Optionally, the starting metadata includes: source database type, database version, start timestamp, character set, and filter configuration; The end metadata includes: capture identifier, end timestamp, capture duration, and completion status; The steps for generating an end marker file and writing end metadata include: determining whether the capture-conversion process has ended normally; if the capture-conversion process has not ended normally, marking the completion status in the end marker file as abnormally aborted or stopping the generation of the end marker file; if the capture-conversion process has ended normally, marking the completion status in the end marker file as normally completed.

[0011] Optionally, the steps of uniformly storing the start marker file, end marker file, and session data file to generate a capture set include: Store the start tag file, end tag file, and all session data files in the same specified capture directory; By specifying the capture directory, the association between the start marker file, the end marker file, and the session data file is established, and a unique identifier is generated, thereby obtaining the capture set.

[0012] Optionally, the steps of performing database playback based on the capture set may include: Perform integrity checks on the start and end marker files; If the start and end marker files pass the integrity check, perform the database replay operation based on the capture set. If the start marker file and end marker file fail the integrity check, an error will be reported and subsequent playback operations will be terminated, along with a prompt message.

[0013] Optionally, the steps for performing integrity verification on the start marker file and the end marker file include: Determine if both a start marker file and an end marker file exist simultaneously; If so, check whether the completion status recorded in the end marker file is marked as normal completion status and whether the timestamp logic is reasonable; If the completion status is marked as normal completion and the timestamp logic is reasonable, the start marker file and end marker file are determined to have passed the integrity check.

[0014] Optionally, the steps for checking whether the timestamp logic is reasonable include: Determine if the end timestamp is later than the start timestamp; If so, then determine whether the timestamp logic is reasonable.

[0015] Optionally, the steps for performing database replay operations based on the capture set include: During playback, the playback performance metrics of the target database are collected in real time. The performance metrics of the playback were compared with those of the source database of the captured records to obtain the comparison results. A playback report is generated using the metadata recorded in the start and end marker files and information from the playback process.

[0016] According to another aspect of the present invention, a computer-readable storage medium is also provided, on which a computer program is stored, wherein the computer program, when executed by a processor, implements the steps of the metadata management method in the database playback process described above.

[0017] According to another aspect of the present invention, a computer program product is also provided, comprising a computer program that, when executed by a processor, implements the steps of the metadata management method during database playback as described above.

[0018] According to another aspect of the present invention, a computer device is also provided, including a memory, a processor, and a machine-executable program stored in the memory and running on the processor, wherein the processor executes the machine-executable program to implement the steps of the metadata management method in the database playback process described above.

[0019] The metadata management method for database playback of this invention, in response to an initiated capture conversion command, first generates a start marker file and writes start metadata. The capture conversion command is used to capture and convert the load information of the source database. During the capture conversion process, the load information of the source database and the metadata during the capture process are written to a session data file. When the capture conversion process ends, an end marker file is generated and end metadata is written. The start marker file, end marker file, and session data file are stored uniformly to generate a capture set. Database playback is then performed based on the capture set. This method enables full lifecycle management of metadata for heterogeneous database load capture, effectively ensuring the integrity and traceability of the captured dataset. It also provides accurate performance metrics for comparison in the subsequent playback stage, solving problems such as insufficient integrity verification, reduced playback authenticity, and missing comparison metrics caused by missing metadata in traditional load playback techniques. This provides highly robust and high-fidelity technical support for performance and compatibility verification in heterogeneous database migration.

[0020] The above and other objects, advantages and features of the present invention will become more apparent to those skilled in the art from the following detailed description of specific embodiments of the invention in conjunction with the accompanying drawings. Attached Figure Description

[0021] The following sections will describe some specific embodiments of the invention in detail by way of example and not limitation, with reference to the accompanying drawings. The same reference numerals in the drawings denote the same or similar parts or portions. Those skilled in the art should understand that these drawings are not necessarily drawn to scale. In the drawings: Figure 1 This is a flowchart illustrating a method for managing metadata during database playback according to an embodiment of the present invention. Figure 2 This is a schematic flowchart of a database playback process according to an embodiment of the present invention; Figure 3 This is a schematic diagram of a computer program product according to an embodiment of the present invention; Figure 4 This is a schematic diagram of a computer-readable storage medium according to an embodiment of the present invention; and Figure 5 This is a schematic diagram of a computer device according to an embodiment of the present invention. Detailed Implementation

[0022] Those skilled in the art should understand that the embodiments described below are merely a part of the embodiments of the present invention, and not all of the embodiments of the present invention. These partial embodiments are intended to explain the technical principles of the present invention and are not intended to limit the scope of protection of the present invention. Based on the embodiments provided by the present invention, all other embodiments obtained by those skilled in the art without creative effort should still fall within the scope of protection of the present invention.

[0023] It should be noted that the logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be specifically implemented in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0024] Currently, the database market in key domestic industries such as finance and telecommunications is still dominated by foreign products such as Oracle and MySQL, resulting in a deep technological dependence. Driven by the information technology innovation policy, enterprises hope to achieve domestic database substitution at the lowest cost, but they still face three major challenges: domestic databases still lag behind mainstream international products in terms of performance and compatibility; testing environments are difficult to realistically reproduce complex production scenarios; and manual migration methods are inefficient and prone to errors. To address these challenges, heterogeneous database replay technology has emerged as a key solution. This technology captures real production workloads for precise testing, and combined with replay and comparative analysis, it can efficiently identify potential performance bottlenecks and compatibility issues after migration.

[0025] In heterogeneous database replay processes based on database load capture, traditional capture methods focus only on generating load files, neglecting the generation and management of load metadata. This approach has significant shortcomings: it cannot monitor the capture status, making it difficult to detect potential problems during the capture process; metadata of the capture process (such as capture start and end times, status identifiers, version information, key performance indicators of the load, filter configurations, etc.) cannot be obtained; furthermore, the lack of key indicators on the capture side makes it impossible to compare with data during replay, thus affecting the generation of replay reports. These defects collectively weaken the authenticity and completeness of the replay.

[0026] The present invention aims to address the core technical problems in existing heterogeneous database replay technologies, namely insufficient load capture integrity verification, reduced replay authenticity, and lack of comparison of key replay metrics, caused by neglecting the management and generation of captured metadata. Specifically, traditional load capture methods for heterogeneous database replay only focus on recording user request data, generating a large number of session data files, but fail to simultaneously generate and manage crucial metadata files, such as capture start and end markers, timestamps, database version, character set, and capture status. This approach makes it impossible to effectively verify the integrity of the capture process in subsequent preprocessing stages, making it difficult to determine whether the capture was completed normally. Furthermore, due to the lack of performance context information at the time of capture (such as load intensity and concurrency), the actual load characteristics of the source end cannot be restored during replay, and accurate comparison with post-replay performance metrics is impossible. Ultimately, this significantly reduces the authenticity of the replay results, failing to provide a reliable performance and compatibility assessment basis for heterogeneous database migration.

[0027] Therefore, this solution designs a method for managing captured metadata information during heterogeneous database replay. The primary challenge is managing and storing metadata information, parsing and analyzing key load metrics, and applying these to the heterogeneous database replay process to ensure the high realism and completeness of heterogeneous load replays captured from the source production database. This mechanism effectively supports more realistic production load simulation by managing and generating metadata files, verifying load capture status, and parsing metadata information to supplement key metrics for replay comparison. This provides a reliable technical guarantee for performance and compatibility verification during the migration of domestic databases. Specifically, the present invention provides a method for managing metadata during database playback. Figure 1 This is a flowchart illustrating a metadata management method during database playback according to an embodiment of the present invention, as shown below. Figure 1 As shown, the metadata management method during the database playback process includes at least the following steps S101 to S107.

[0028] Step S101: In response to the initiated capture and transformation command, a start marker file is generated and start metadata is written. The capture and transformation command is used to capture and transform the load information of the source database. The start metadata typically includes: source database type, database version, start timestamp, character set, and filter configuration.

[0029] This step is the metadata initialization step for the capture startup phase. When a user initiates a capture conversion command through the capture conversion interface (e.g., CONVERT_CAPTURE), the system first generates an independent start marker file (e.g., named Kingbase_wcr_scapture.wmd) in the specified file system path and writes the core environment metadata at the time of capture startup into this file. The source database type and version information are used for format conversion and adaptation before subsequent playback to ensure that syntax differences between different databases are handled correctly; character set information is used to avoid data garbled issues during playback; the start timestamp is used to mark the time boundary of the load capture; and the filter configuration records the request types filtered in this capture (such as internal system requests, test requests, etc.) to ensure consistency between the playback load and the production environment.

[0030] Step S102: During the capture and conversion process, the load information of the source database and the metadata during the capture process are written into the session data file.

[0031] After recording the initial metadata, the system proceeds to the core execution phase of load capture and transformation in step S102. During this process, the system asynchronously collects all user request data (including SQL statements, parameters, execution context, etc.) from the source database and converts it into a common playback format, writing it to the session data file. Simultaneously, the system collects metadata during the capture process in real time, including but not limited to key performance indicators such as requests per second, concurrent connections, average response time, and transaction throughput, as well as the execution sequence information for each session. This process metadata is bound to the corresponding user request data and stored in the same session data file, ensuring accurate reconstruction of the source database's true load characteristics and execution sequence during playback. This step integrates the process metadata and load data storage, guaranteeing a one-to-one correspondence between metadata and requests while avoiding additional file management overhead, significantly improving the realism of the playback.

[0032] Step S103: When the capture conversion process ends, an end marker file is generated and end metadata is written. The end metadata typically includes: capture identifier, end timestamp, capture duration, and completion status.

[0033] In some optional embodiments, the steps of generating an end marker file and writing end metadata generally include: determining whether the capture conversion process has ended normally; if the capture conversion process has not ended normally, marking the completion status in the end marker file as abnormally terminated or stopping the generation of the end marker file; if the capture conversion process has ended normally, marking the completion status in the end marker file as normally completed. When all load data capture conversion is completed or the capture process is terminated, the system generates an end marker file corresponding to the start marker file (e.g., named Kingbase_wcr_fcapture.wmd) and writes metadata at the capture end time. The capture identifier serves as a unique global identifier for this capture process and is used for subsequent capture set traceability; the end timestamp and capture duration are used to quantify the time span of the capture process; and the completion status field is used to distinguish the final capture result. If the capture process ends abnormally due to network interruption, database crash, manual termination, etc., the system will stop generating the end marker file or mark the completion status as abnormally terminated (e.g., ABORTED) in the already generated end marker file; the completion status is only marked as normally completed (e.g., COMPLETED) when the capture process has ended normally. This step utilizes a dual-marker file mechanism to monitor the status throughout the entire capture lifecycle, thereby solving the problem that traditional technologies cannot identify abnormal interruptions, leading to incomplete data entering the playback process.

[0034] Step S104 involves uniformly storing the start marker file, end marker file, and session data file to generate a capture set. In some optional embodiments, the step of uniformly storing the start marker file, end marker file, and session data file to generate a capture set generally includes: storing the start marker file, end marker file, and all session data files in the same specified capture directory; establishing the association between the start marker file, end marker file, and session data files through the specified capture directory and generating a unique identifier to obtain the capture set.

[0035] This step involves the unified storage and association of capture sets. The system stores all start and end marker files, as well as multiple session data files generated in this capture, in the same pre-specified capture directory. Through directory-level association, all files belonging to the same capture process are bound into a complete capture set, and a unique directory identifier is assigned to this capture set. This storage method does not rely on a database or other third-party systems, ensuring the independence and traceability of each capture set and avoiding confusion between capture data from different batches.

[0036] Step S105: Perform database replay operation based on the capture set.

[0037] In some optional embodiments, the steps prior to performing database playback based on the capture set may generally include: performing integrity checks on the start and end marker files; if the start and end marker files pass the integrity check, performing the database playback based on the capture set; if the start and end marker files fail the integrity check, reporting an error and terminating the subsequent playback operation, while issuing a prompt message.

[0038] Optionally, the steps for performing integrity verification on the start marker file and the end marker file may include: determining whether a start marker file and an end marker file exist simultaneously; if so, checking whether the completion status recorded in the end marker file is marked as a normal completion status and whether the timestamp logic is reasonable; if the completion status is marked as a normal completion status and the timestamp logic is reasonable, determining that the start marker file and the end marker file pass the integrity verification.

[0039] Optionally, the steps for checking whether the timestamp logic is reasonable may generally include: determining whether the end timestamp is later than the start timestamp; if so, determining whether the timestamp logic is reasonable.

[0040] Before performing playback, the captured set is first checked for integrity. This is a crucial step in ensuring the validity of the playback data. If any level of verification fails, the system immediately terminates the subsequent playback process and outputs a clear error message, guiding the user to recapture or check the data. This three-level integrity verification mechanism effectively prevents playback failures or result distortions caused by incomplete data from the outset.

[0041] Optionally, the steps for performing database replay operations based on the capture set may generally include: collecting replay performance metrics of the target database in real time during the replay process; comparing the replay performance metrics with the source database performance metrics recorded in the capture set to obtain the comparison results; and generating a replay report using the metadata recorded in the start and end marker files and the information during the replay process.

[0042] After successful verification, the database replay operation in step S105 is executed. During replay, the system can read the session data file from the capture set and reproduce the production load in the target heterogeneous database according to the execution sequence and concurrency of the source end. The system collects various performance indicators of the target database in real time, including response time, throughput, CPU utilization, IOPS, etc. After replay, the performance indicators collected on the replay side are compared precisely dimension by dimension with the source database performance indicators recorded in the session data file on the capture side, generating a detailed replay report containing performance difference analysis, a list of compatibility issues, and slow SQL location. The report also integrates environmental and status information from the start and end marker files, providing comprehensive and reliable data support for database migration decisions. This step uses the metadata from the capture side as a comparison benchmark, solving the problems of lack of context and inaccurate results in traditional performance comparisons, and significantly improving the efficiency and accuracy of problem location.

[0043] This method enables full lifecycle management of captured metadata, from generation, storage, verification to application. It effectively solves the problems of insufficient integrity verification, reduced playback authenticity, and lack of comparison indicators caused by missing metadata in traditional load replay technology, providing highly robust and high-fidelity technical support for performance and compatibility verification in heterogeneous database migration.

[0044] Figure 2 This is a schematic flowchart of a database playback process according to an embodiment of the present invention, as shown below. Figure 2 As shown, the database playback process includes at least the following steps S201 to S207.

[0045] Step S201: Determine if both a start marker file and an end marker file exist simultaneously. If not, end the playback. Before playback, the system first reads the specified capture directory to be played back and checks if the corresponding start marker file and end marker file exist simultaneously in that directory. The start marker file is generated during the capture startup phase and serves as the start identifier and environment information carrier for the capture process. The end marker file is generated during the capture end phase and serves as the end identifier and status information carrier for the capture process. If neither file exists simultaneously, it indicates that the capture process has issues such as startup anomalies, incomplete interruptions, or missing core files. The captured dataset does not meet the basic conditions for playback, and the system directly ends the playback process. This step, as the first hurdle in the playback process, quickly filters out invalid capture sets with missing files without parsing large session data files, significantly reducing unnecessary system resource overhead and preventing invalid data from entering subsequent processes at the source.

[0046] Step S202: If the determination in step S201 is yes, check whether the completion status recorded in the end marker file is marked as normal completion status. If the determination is no, then end the current playback.

[0047] Based on the determination in step S201 that both marker files exist simultaneously, the system reads and parses the end marker file, extracts the completion status field, and checks whether this field is marked as a normal completion status (i.e., COMPLETED). The completion status field is the core field of the end marker file, used to uniquely identify the final result of this capture and conversion process. This field is only marked as a normal completion status when the entire capture process is uninterrupted and all load data is completely collected. If the capture process abnormally ends due to network interruption, database crash, manual termination, or other reasons, this field will be marked as abnormally aborted (ABORTED). If the detection determines that the completion status is not normal, it indicates that the capture process was abnormally interrupted, session data is missing, and the complete production load cannot be restored. The system directly terminates this playback process. This step precisely solves the core defect of traditional technology, which cannot distinguish between normal and abnormal capture completion, leading to incomplete loads entering the playback process, and completely eliminates the problem of playback result distortion caused by data gaps.

[0048] Step S203: If the determination in step S202 is yes, check if the timestamp logic is reasonable. If the determination is no, end the current playback. Based on the completion status being determined to be normal in step S202, the system extracts the start timestamp from the start marker file and the end timestamp from the end marker file, respectively, and checks if the timestamp logic is reasonable, that is, verifies whether the end timestamp is later than the start timestamp. This verification is used to exclude extreme scenarios such as file tampering, data corruption, and abnormal system time, and to avoid the inability to restore the true production load execution sequence due to disordered timing logic. If the timestamp logic is determined to be unreasonable, it means that the captured dataset is at risk of tampering or corruption, and does not meet the conditions for reliable playback, and the system directly ends the current playback process.

[0049] It should be noted that the order of steps S202 and S203 is not limited. It is possible to first determine whether the timestamp logic is valid before checking whether the completion status recorded in the end marker file is marked as a normal completion status, or to perform them simultaneously. Through the above three-level progressive integrity verification, this invention achieves closed-loop verification of the capture set's integrity, providing an absolutely reliable and complete data foundation for subsequent playback operations.

[0050] Step S204: If the determination in step S203 is correct, perform the database replay operation. After determining in step S203 that the timestamp logic is valid and the capture set passes the full integrity check, the system officially executes the database replay operation. Specifically, the system reads the session data file in the capture directory, parses the process metadata recorded in it, such as the source database user request data, execution sequence, concurrency, and request interval, and reproduces the production load of the source end in a 1:1 ratio in the target heterogeneous database, including the standardized conversion and execution of SQL statements, transaction commit and rollback, and full-process management of the session lifecycle. This step relies on the complete capture set that has undergone three levels of verification to perform the replay, completely avoiding the problems of replay failure and result distortion caused by invalid basic data. At the same time, based on the process metadata bound in the session data file, it achieves accurate restoration of the real load characteristics of the source end.

[0051] Step S205 involves real-time acquisition of replay performance metrics for the target database during the replay process. During the execution of the database replay operation, comprehensive replay performance metrics of the target database can be acquired in real-time. These replay performance metrics include, but are not limited to, core performance parameters of the target database such as average SQL response time, transaction throughput, real-time concurrent connections, CPU utilization, disk IOPS, and lock wait time. Furthermore, the time granularity and statistical dimensions of the metric acquisition are completely consistent with the metric acquisition rules of the source-end capture process. This provides a complete, accurate, and time-aligned dataset for subsequent cross-database performance comparisons, ensuring the objectivity and accuracy of the final comparison results.

[0052] Step S206 compares the replay performance metrics with the source database performance metrics recorded in the capture set to obtain the comparison results. After replay, the replay performance metrics collected in step S205 can be compared one by one with the performance benchmark metrics of the source database recorded in the session data file of the capture set, in the same order and dimension, to generate quantitative comparison results. The comparison generally includes multiple dimensions such as overall load performance difference analysis, single SQL execution efficiency comparison, transaction processing capability difference identification, and SQL syntax compatibility anomaly location, which can accurately mark the performance gap and compatibility risk points between the target database and the source database. This step uses the capture side meta information as a unified comparison benchmark, which completely solves the core pain point of traditional technology performance comparison lacking context benchmark and unreliable results.

[0053] Step S207: Generate a replay report using the metadata recorded in the start and end marker files and information from the replay process. In addition to the comparison process described above, a replay report can also be generated. A standardized heterogeneous database replay verification report is generated by integrating all metadata recorded in the start and end marker files and performance data collected during replay. The metadata in the dual marker files includes full test context information such as source database type, database version, character set, capture start and end times, capture duration, and unique capture identifier. The replay process information includes replay execution logs, performance metric curves, a list of abnormal SQL statements, performance bottleneck analysis, and compatibility risk warnings. The final generated report has complete traceability and can provide comprehensive, authoritative, and reliable decision-making basis for database localization migration.

[0054] This method can systematically solve the problems of inability to verify capture integrity, insufficient playback authenticity, and lack of benchmark for performance comparison in traditional heterogeneous database replay technology. It can also automate and standardize the entire migration verification process, providing core technical support with high robustness and high fidelity for the rapid, secure, and low-cost deployment of domestic databases in key industries such as finance and telecommunications.

[0055] The flowchart provided in this embodiment is not intended to indicate that the operations of the method will be performed in any particular order, or that all operations of the method are included in every case. Furthermore, the method may include additional operations. Within the scope of the technical concept provided by the method in this embodiment, additional variations can be made to the above method.

[0056] It should be understood that in some embodiments, the components may be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods may be implemented using software or firmware stored in memory and executed by a suitable instruction execution system.

[0057] This embodiment also provides a computer program product 10, a computer-readable storage medium 20, and a computer device 30. Figure 3 This is a schematic diagram of a computer program product 10 according to an embodiment of the present invention. Figure 4 This is a schematic diagram of a computer-readable storage medium 20 according to an embodiment of the present invention. Figure 5This is a schematic diagram of a computer device 30 according to an embodiment of the present invention. The computer program product 10 includes a computer program 11, which, when executed by the processor 32, implements the steps of the metadata management method during database playback as described above. A computer-readable storage medium 20 stores the computer program 11 thereon, which, when executed by the processor 32, implements the steps of the metadata management method during database playback as described above. The computer device 30 may include a memory 31, a processor 32, and the computer program 11 stored on the memory 31 and running on the processor 32.

[0058] The computer program 11 used to perform the operations of this invention may be assembly instructions, Instruction Set Architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages ​​and procedural programming languages. The computer program 11 may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a Local Area Network (LAN) or Wide Area Network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, to perform aspects of this invention, electronic circuits, including, for example, programmable logic circuits, Field-Programmable Gate Arrays (FPGAs), or Programmable Logic Arrays (PLAs), may execute computer-readable program instructions to personalize the electronic circuits by utilizing state information from computer-readable program instructions.

[0059] For the purposes of this embodiment, computer program product 10 is a related product containing computer program 11. For the purposes of this embodiment, computer-readable storage medium 20 is a tangible device capable of holding and storing computer program 11, and can be any device capable of containing, storing, communicating, propagating, or transmitting program 11 for use by or in conjunction with an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable storage medium 20 include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable optical disc read-only memory (CD-ROM), digital versatile disc (DVD), memory stick, floppy disk, mechanical encoding device, and any suitable combination thereof.

[0060] Computer device 30 can be, for example, a server, desktop computer, laptop computer, tablet computer, or smartphone. In some examples, computer device 30 can be a cloud computing node. Computer device 30 can be described in the general context of computer system executable instructions (such as program modules) executed by a computer system. Typically, program modules can include routines, programs, object programs, components, logic, data structures, etc., that perform specific tasks or implement specific abstract data types. Computer device 30 can be implemented in a distributed cloud computing environment where tasks are performed by remote processing devices linked through a communication network. In a distributed cloud computing environment, program modules can reside on local or remote computing system storage media, including storage devices.

[0061] Computer device 30 may include a processor 32 adapted to execute stored instructions and a memory 31 that provides temporary storage space for the operation of said instructions during operation. The processor 32 may be a single-core processor, a multi-core processor, a computing cluster, or any other configuration. The memory 31 may include random access memory (RAM), read-only memory, flash memory, or any other suitable storage system.

[0062] Computer device 30 may also include a network adapter / interface and an input / output (I / O) interface. The I / O interface allows external devices that can be connected to the computer device to input and output data. The network adapter / interface provides communication between the computer device and a network, typically represented as a communication network.

[0063] Therefore, those skilled in the art should recognize that although numerous exemplary embodiments of the present invention have been shown and described in detail herein, many other variations or modifications conforming to the principles of the present invention can be directly determined or derived from the disclosure of the present invention without departing from the spirit and scope of the invention. Thus, the scope of the present invention should be understood and construed as covering all such other variations or modifications.

Claims

1. A method for managing metadata during database playback, comprising: In response to the initiated capture and transformation command, a starting marker file is generated and starting metadata is written. The capture and transformation command is used to capture the load information of the source database and perform transformation. During the capture and conversion process, the load information of the source database and the metadata of the capture process are written into the session data file; When the capture conversion process ends, an end marker file is generated and end metadata is written. The start marker file, the end marker file, and the session data file are stored uniformly to generate a capture set; Perform database replay operations based on the captured set.

2. The method for managing metadata during database playback according to claim 1, wherein, The initial metadata includes: source database type, database version, start timestamp, character set, and filter configuration; The end metadata includes: capture identifier, end timestamp, capture duration, and completion status; The step of generating an end marker file and writing end metadata includes: determining whether the capture conversion process is a normal termination; if the capture conversion process is not a normal termination, marking the completion status in the end marker file as abnormal termination or stopping the generation of the end marker file; if the capture conversion process is a normal termination, marking the completion status in the end marker file as normal completion.

3. The method for managing metadata during database playback according to claim 2, wherein, The step of uniformly storing the start marker file, the end marker file, and the session data file to generate a capture set includes: Store the start tag file, the end tag file, and all session data files in the same designated capture directory; The capture set is obtained by establishing the association between the start marker file, the end marker file, and the session data file through the specified capture directory and generating a unique identifier.

4. The method for managing metadata during database playback according to claim 2, wherein, Prior to the step of performing database playback based on the captured set, the following is included: Perform integrity verification on the start marker file and the end marker file; If the start marker file and the end marker file pass the integrity check, the step of performing database playback based on the capture set is executed; If the start marker file and the end marker file fail the integrity check, an error will be reported and subsequent playback operations will be terminated, along with a prompt message.

5. The method for managing metadata during database playback according to claim 4, wherein, The step of performing integrity verification on the start marker file and the end marker file includes: Determine whether the start marker file and the end marker file exist simultaneously; If so, check whether the completion status recorded in the end marker file is marked as a normal completion status and whether the timestamp logic is reasonable; If the completion status is marked as normal completion and the timestamp logic is reasonable, then the start marker file and the end marker file are determined to have passed the integrity check.

6. The method for managing metadata during database playback according to claim 5, wherein, The step of detecting whether the timestamp logic is reasonable includes: Determine whether the end timestamp is later than the start timestamp; If so, then determine whether the timestamp logic is reasonable.

7. The method for managing metadata during database playback according to claim 1, wherein, The steps of performing database replay operation based on the capture set include: During playback, the playback performance metrics of the target database are collected in real time. The playback performance metrics and the source database performance metrics recorded in the capture set are compared to obtain the comparison results; A playback report is generated using the metadata recorded in the start marker file and the end marker file, as well as the information from the playback process.

8. A computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the metadata management method during database playback as described in any one of claims 1 to 7.

9. A computer program product comprising a computer program that, when executed by a processor, implements the steps of the metadata management method during database playback as described in any one of claims 1 to 7.

10. A computer device comprising a memory, a processor, and a machine-executable program stored in the memory and running on the processor, wherein the processor, when executing the machine-executable program, implements the steps of the metadata management method during database playback according to any one of claims 1 to 7.

Images