A database stored procedure verification method and system

Abstract

This invention discloses a database stored procedure verification method and system, belonging to the field of database migration technology. It addresses the technical problems of existing database stored procedure verification methods, which struggle to identify performance semantic deviations, cannot guarantee the accuracy of migration paths and results, and fail to meet the precise verification requirements of stored procedure migration. The method includes: executing the target stored procedure in a shadow database constructed based on two databases using the same input parameters; monitoring key data processing paths in the two databases during execution to obtain operator-level execution information for each database; generating corresponding operator fingerprint feature sequences based on the operator-level execution information; calculating the corresponding execution entropy based on the resource consumption information corresponding to the operator fingerprint feature sequences; aligning the execution trajectories of the two databases and calculating a mixed similarity based on the operator fingerprint feature sequences and execution entropy; and comparing the semantic consistency of the two databases in the target stored procedure.

Description

Technical Field

[0001] This invention relates to the field of database migration technology, and in particular to a database stored procedure verification method and system. Background Technology

[0002] The core of database replacement engineering is migrating Oracle database stored procedures to IvorySQL database. As the core carrier of business logic, the verification results of the database stored procedures after migration directly determine the stability and business continuity of the migrated database system.

[0003] Existing database stored procedure migration verification mainly employs the following techniques: First, general software testing methods, which assess migration rate by recording the execution order of code lines and calculating similarity. However, due to their coarse granularity, these methods cannot capture changes in the underlying database operator states and data processing logic, making it difficult to identify performance semantic deviations caused by index failures, execution path changes, etc. Second, verification based on syntax conversion tools, but these can only complete static code conversion, lacking a dynamic verification loop at runtime, and cannot prove that the converted code is equivalent to the physical execution path of the source code. Third, physical verification methods, but these methods can only compare data results and cannot identify whether the logical path of data calculation is incorrect.

[0004] Therefore, existing database stored procedure verification methods are unable to identify performance semantic discrepancies between the source and target databases, cannot guarantee the accuracy of the data storage process after migration, and cannot meet the precise verification requirements for stored procedure migration. Summary of the Invention

[0005] This invention provides a database stored procedure verification method and system to solve the following technical problems: existing database stored procedure verification methods are difficult to identify performance semantic deviations, cannot guarantee the accuracy of migration paths and migration results, and cannot meet the precise verification requirements of stored procedure migration.

[0006] The embodiments of the present invention adopt the following technical solutions: On one hand, embodiments of the present invention provide a database stored procedure verification method, the method comprising: executing a target stored procedure in a shadow database constructed based on a dual-end database using the same input parameters; wherein the dual-end database includes a source database and a target database; During execution, the key data processing paths in both databases are monitored, and operator-level execution information of both databases is obtained. Based on the operator-level execution information, a corresponding operator fingerprint feature sequence is generated; Calculate the corresponding execution entropy based on the resource consumption information corresponding to the operator fingerprint feature sequence; Based on the operator fingerprint feature sequence and the execution entropy, the execution trajectories of the two-end database are aligned and the hybrid similarity is calculated; Based on the hybrid similarity, the semantic consistency of the two databases in the target stored procedure is compared, and a stored procedure verification risk report is output.

[0007] In one feasible implementation, before executing the target stored procedure with the same input parameters in an isolated shadow library built based on a dual-end database, the method further includes: Obtain the stored procedure code of the target stored procedure, and perform control flow analysis on the stored procedure code to obtain a control flow graph; Identify the key data processing paths in the control flow graph; wherein the key data processing paths include at least one or more of the following: transaction commit processing path, savepoint processing path, sub-transaction processing path, exception block processing path, and vector calculation path.

[0008] In one feasible implementation, the target stored procedure is executed using the same input parameters in a shadow database built on a dual-end database, specifically including: In an isolated environment, a shadow database is constructed between the source database and the target database; In the shadow database, the same parameters are input to the source database and the target database, controlling the source database and the target database to execute the same target stored procedure simultaneously, and monitoring the execution process of the two databases in real time.

[0009] In one feasible implementation, during execution, key data processing paths in the two-end database are monitored to obtain operator-level execution information for each database, specifically including: A kernel anchor capture device is mounted in the kernel of the target database, and operator-level execution information of each key data processing path in the target database is obtained through the kernel anchor capture device; wherein, the operator-level execution information includes at least one or more of the following: operator type, tuple count, sub-transaction ID, and memory; Using the extraction tools built into the source database, the execution plan tree and performance view are extracted; the operator-level execution information of each key data processing path in the source database is then extracted from the execution plan tree and performance view.

[0010] In one feasible implementation, a corresponding operator fingerprint feature sequence is generated based on the operator-level execution information, specifically including: Define the high-dimensional feature tuple corresponding to the operator fingerprint; Execution plan trees are extracted from the source database and the target database respectively, and the execution plan trees are normalized; wherein, the normalization process includes at least alias elimination, unordered operator rearrangement, and right join equivalence transformation; The execution plan tree is traversed from bottom to top using a post-order traversal method, and operator fingerprint feature sequences corresponding to the source database and the target database are generated based on the high-dimensional feature tuples.

[0011] In one feasible implementation, the execution plan tree is traversed from bottom to top using a post-order traversal method, and operator fingerprint feature sequences corresponding to the source database and the target database are generated based on the high-dimensional feature tuples. Specifically, this includes: Recursively process each child node in the execution plan tree in reverse, generate the operator fingerprint string of the current child node based on the high-dimensional feature tuple, and return the operator fingerprint string to the parent node of the current child node; In the parent node, the operator fingerprint strings corresponding to all its connected child nodes are concatenated to obtain the operator fingerprint string of the parent node; and so on, until the operator fingerprint strings of all nodes are obtained. Hash the operator fingerprint string of each node to obtain the operator fingerprint feature of each node; serialize the operator fingerprint feature of each node to obtain the initial operator fingerprint feature sequence. Based on the number of lines of code and execution cost corresponding to each node, the feature weight of each node is calculated; the feature weight is then fused into the initial operator fingerprint feature sequence to obtain the final operator fingerprint feature sequence.

[0012] In one feasible implementation, the corresponding execution entropy is calculated based on the resource consumption information corresponding to the operator fingerprint feature sequence, specifically including: The resource consumption information is obtained from the operator fingerprint feature sequence; wherein, the resource consumption information includes at least: IO consumption, memory consumption, CPU consumption, and resource usage value of each operator; Based on the resource consumption information and the Laplace smoothing term, the resource distribution probability of each operator is calculated; wherein the value space of the resource distribution probability is [0,1]. Based on the resource distribution probability, calculate the one-dimensional edge execution entropy for each resource; Based on the single-dimensional edge execution entropy, the multi-dimensional joint execution entropy of multiple resources is calculated.

[0013] In one feasible implementation, the execution trajectories of the two-end database are aligned and a hybrid similarity is calculated based on the operator fingerprint feature sequence and the execution entropy, specifically including: The operator fingerprint feature sequence is converted into a high-dimensional vector using the SBERT model to obtain the execution trajectory vector; according to Calculate the execution trajectory vector corresponding to the source database. Execution trajectory vector corresponding to the target database Mixed similarity between ; in, This indicates that global semantic cosine similarity is calculated using the SBERT model; This indicates that the Dynamic Time Warping (DTW) algorithm is used to solve the minimum cost path, and its local distance calculation process incorporates the difference between fingerprint edit distance and execution entropy. The weights are adaptive and dynamically adjusted based on the transaction cyclomatic complexity of the stored procedure.

[0014] In one feasible implementation, based on the hybrid similarity, the semantic consistency of the two databases in the target stored procedure is compared, and a stored procedure verification risk report is output, specifically including: If the mixed similarity is higher than a preset threshold, the consistency verification of the target stored procedure is passed; If the mixed similarity is not higher than a preset threshold, it is determined to be semantically inconsistent. At this time, the deviation points in the two trajectory vectors are extracted and the deviation points are input into the RAG arbitrator for semantic difference arbitration. Based on the arbitration result, the stored procedure verification risk report is generated.

[0015] On the other hand, embodiments of the present invention also provide a database stored procedure verification system, the system comprising: The operator fingerprint generation module is used to execute a target stored procedure in a shadow database constructed based on a dual-end database using the same input parameters; wherein the dual-end database includes a source database and a target database; during the execution process, the key data processing paths in the dual-end database are monitored, and the operator-level execution information of the dual-end database is obtained respectively; based on the operator-level execution information, a corresponding operator fingerprint feature sequence is generated. The execution entropy quantization module is used to calculate the corresponding execution entropy based on the resource consumption information corresponding to the operator fingerprint feature sequence; The comparison and verification module is used to align the execution trajectories of the two-end databases and calculate the hybrid similarity based on the operator fingerprint feature sequence and the execution entropy; based on the hybrid similarity, it compares the semantic consistency of the two-end databases in the target storage procedure and outputs a storage procedure verification risk report.

[0016] Compared with the prior art, the database stored procedure verification method and system provided in this embodiment of the invention have the following beneficial effects: 1. Breaking through the limitations of traditional line-level code trajectory analysis, it achieves database kernel operator-level execution state capture, accurately identifying hidden performance and logical deviations such as index failures and execution plan changes. Through operator fingerprinting normalization and execution entropy quantification, it masks differences in the naming and syntactic dialects of built-in functions in heterogeneous databases, significantly reducing the false positive rate of verification.

[0017] 2. Leveraging the DTW algorithm and vector space mapping, the problem of inconsistent execution step sizes between the two ends is resolved, achieving cross-database forced alignment of stored procedure logical paths and performance characteristics. A semantic decision-making closed loop is constructed using the RAG knowledge base to automatically locate logical drift points and associate them with source code, enabling risk assessment and remediation suggestion generation.

[0018] 3. By using execution entropy, absolute resource consumption is transformed into a relative probability distribution, eliminating the constraints of hardware environment differences and supporting cross-hardware platform stored procedure equivalence verification. Specialized monitoring is performed on sub-transactions, exception handling blocks, and autonomous transactions to effectively identify transaction rollback and commit logic deviations, ensuring data consistency.

[0019] 4. Automates the trajectory capture, encoding, comparison, and arbitration process, replacing manual line-by-line verification, reducing operation and maintenance costs and verification cycles. Supports complex scenarios such as high concurrency, large transactions, vector computation, and large object processing, covering the migration needs of replacing all business operations with domestic databases. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings: Figure 1 A flowchart of a database stored procedure verification method provided in an embodiment of the present invention; Figure 2 A schematic diagram of the specific architecture of a database stored procedure verification system provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a database stored procedure verification system provided in an embodiment of the present invention. Detailed Implementation

[0021] To enable those skilled in the art to better understand the technical solutions of this invention, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this invention, and not all embodiments. Based on the embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this invention.

[0022] IvorySQL, a domestically developed database highly compatible with Oracle, offers deep dialect support through PL / iSQL. However, at the execution level, IvorySQL's Executor logic differs fundamentally from Oracle's engine in areas such as lock escalation, implicit type conversion, and NULL handling.

[0023] The closest approach currently available is based on general software testing methods like AbstractTrace, which evaluates test coverage by recording the execution order of code lines and calculating similarity. However, this method is too coarse-grained: general trace analysis only records "which line was executed," not "how the operator processed the data." This means that when the same SQL statement changes to a full table scan due to index failure, general tools cannot identify this performance semantic deviation that could cause production crashes. Furthermore, different databases have different built-in function names (e.g., SYSDATE vs now()), and directly comparing logs will generate a large number of false positives, leading to low operational efficiency. Additionally, LLM transformation tools only provide transformation suggestions and lack runtime dynamic verification loops, failing to prove that the transformed code is physically equivalent to the source code.

[0024] This invention provides a database stored procedure verification method. By defining "operator-level execution anchors" at the database kernel level and combining them with a "double-ended execution entropy" model, it achieves semantic-level forced alignment and automatic error correction in heterogeneous environments. Figure 1 As shown, the database stored procedure verification method specifically includes steps S101-S105: S101. In the shadow database built on the dual-end database, the target stored procedure is executed with the same input parameters; wherein, the dual-end database includes the source database and the target database.

[0025] Specifically, the stored procedure code of the target stored procedure is obtained, and control flow analysis is performed on the stored procedure code to obtain a control flow graph. Key data processing paths in the control flow graph are identified; these key data processing paths include at least one or more of the following: transaction commit processing path, savepoint processing path, sub-transaction processing path, exception block processing path, and vector computation path.

[0026] As a feasible implementation method, data flow analysis is used to generate the control flow graph (CFG) of the target stored procedure, identify all critical paths containing COMMIT, SAVEPOINT, or vector computation, and subsequent verification operations are only processed for these critical paths, saving computing resources and improving verification efficiency. Furthermore, in an isolated environment, shadow databases are constructed for both the source and target databases. In these shadow databases, the same parameters are input to both databases, controlling both to execute the same target stored procedure simultaneously, and the execution process of both databases is monitored in real time.

[0027] As a feasible implementation, in an isolated environment, i.e. a constructed shadow database, the same input parameters are used to trigger the simultaneous execution of the target stored procedure in both the source database (Oracle) and the target database (IvorySQL). Figure 2 A schematic diagram of a specific architecture of a database stored procedure verification system provided in an embodiment of the present invention is shown below. Figure 2 As shown, the system consists of the following five key modules: 1. Kernel Anchor Capturer: Mounted in the ExecutorRun_hook of the target database IvorySQL. Unlike ordinary logs, it can capture operator types, tuple counts, and sub-transaction ID changes in the PlanState.

[0028] 2. Trajectory Transcoder: Introduces "operator fingerprinting," encoding atomic operations such as IndexScan, Sort, and NestLoop into a weighted operator fingerprint feature sequence S. A .

[0029] 3. Embedding Alignment Center: Utilizing the SBERT model, the operator fingerprint feature sequence S... A Projecting to a high-dimensional vector space and introducing the Dynamic Time Warping (DTW) algorithm to solve the problem of inconsistent execution step sizes at both ends.

[0030] 4. Knowledge-enhanced Arbitrator (RAG-based Arbitrator): Combines the IvorySQL Compatibility Manual with Oracle kernel documentation to perform semantic characterization of vector deviations.

[0031] 5. Source Code Association Marker Module: Maps detected logical inconsistencies back to specific lines in the PL / SQL source code.

[0032] S102. During execution, the key data processing paths in the two-end database are monitored, and the operator-level execution information of the two-end database is obtained respectively.

[0033] Specifically, a kernel anchor capture is mounted in the kernel of the target database, and operator-level execution information of each key data processing path in the target database is obtained through the kernel anchor capture; wherein, operator-level execution information includes at least one or more of the following: operator type, tuple count, subtransaction ID, and memory.

[0034] Furthermore, the execution plan tree and performance view are extracted using the extraction tools built into the source database; operator-level execution information for each key data processing path in the source database is then extracted from the execution plan tree and performance view.

[0035] As a feasible implementation method, traditional verification relies on absolute resource overhead such as SQL text comparison or execution time, which has drawbacks in heterogeneous environments: structurally equivalent queries will generate different physical execution plans, and hardware differences make it impossible to directly compare absolute scalars. This invention uses operator fingerprinting to uniformly represent logical trajectories and combines execution entropy to transform absolute resource overhead into a relative probability distribution, thereby achieving logic and performance verification across hardware platforms. Operator fingerprinting is used to transform the execution plan, which is in the form of a directed acyclic graph, into a rigorous one-dimensional temporal feature sequence.

[0036] S103. Generate the corresponding operator fingerprint feature sequence based on the operator-level execution information.

[0037] Specifically, we define the high-dimensional feature tuples corresponding to the operator fingerprint.

[0038] Execution plan trees are extracted from the source database and the target database respectively, and the execution plan trees are normalized. The normalization process includes at least alias elimination, unordered operator rearrangement, and right join equivalence transformation.

[0039] Furthermore, the execution plan tree is traversed from bottom to top using a post-order traversal method, and operator fingerprint feature sequences corresponding to the source database and the target database are generated based on high-dimensional feature tuples, specifically including: The process recursively executes each child node in the plan tree, generating an operator fingerprint string based on the high-dimensional feature tuple, and returning this string to the parent node. Within the parent node, the operator fingerprint strings of all connected child nodes are concatenated to obtain the parent node's operator fingerprint string; this process continues until all nodes have their own operator fingerprint strings. A hash operation is performed on each node's operator fingerprint string to obtain its feature; this feature is then serialized to obtain an initial operator fingerprint feature sequence. Based on the number of lines of code and execution cost for each node, a feature weight is calculated; these weights are then integrated into the initial operator fingerprint feature sequence to obtain the final operator fingerprint feature sequence.

[0040] The specific calculation process is as follows: First, fingerprint a single atomic operator. Defined as a high-dimensional feature tuple:

[0041] Where Type represents the operator type, This represents the input / output (I / O) resources consumed by the operator. This indicates the memory resources consumed by the operator. Other core memory attribute constraints are shown in Table 1. Table 1. Meaning of Memory Core Attributes and Parameter Constraints

[0042] To avoid interference from the tree structure generated by heterogeneous optimizers, a normalization strategy is adopted: Alias ​​elimination and inlining: eliminating dialectal variable naming differences at the parsing level. Forced reordering of unordered operators: combining the lexicographical order of node strings, the child nodes of operators such as HashJoin and Union that satisfy the commutative law are forcibly sorted. Equivalent transformation of right joins: all Right Outer Joins are equivalently rewritten as Left Outer Joins. Finally, a weighted feature sequence is generated from the bottom up by traversing the execution plan tree in post-order traversal. .

[0043] S104. Calculate the corresponding execution entropy based on the resource consumption information corresponding to the operator fingerprint feature sequence.

[0044] Specifically, resource consumption information is obtained from the operator fingerprint feature sequence; wherein, the resource consumption information includes at least: IO consumption, memory consumption, CPU consumption, and resource usage value of each operator.

[0045] Furthermore, based on resource consumption information and the Laplace smoothing term, the resource distribution probability of each operator is calculated; where the value space of the resource distribution probability is [0,1].

[0046] Furthermore, based on the resource distribution probability, the single-dimensional edge execution entropy of each resource is calculated; based on the single-dimensional edge execution entropy, the multi-dimensional joint execution entropy of multiple resources is calculated.

[0047] As a feasible implementation method, the execution entropy model from information theory is introduced to transform absolute physical resource consumption into a probabilistic distribution law, measuring the uniformity of resource distribution and bottlenecks. First, resource probability normalization is performed: Regarding resources Combined with Laplace smoothing term (To prevent zero-point overflow caused by pure memory operations), computation operators The probability distribution of the k-th resource : Where N is the total number of operators, This represents the original resource usage or consumption value of the i-th operator in the k-th resource dimension. Specifically, when k = {IO}, This indicates the input / output resource consumption of the operator, such as the number of bytes read / written, the number of pages, or the number of I / O operations; when k={Mem}, This indicates the memory resource consumption of the operator, such as memory allocation, peak usage, or buffer usage; when k={CPU}, This indicates the CPU resource consumption of the operator, such as execution time, CPU time slice, or processing cost. These are the original resource measurements before normalization. This represents the resource usage value of the j-th operator on the same resource dimension k. This formula is used to convert the absolute resource consumption of each operator into a relative distribution probability, so as to calculate the execution entropy later and reduce the impact of absolute resource differences under different hardware environments on the verification results.

[0048] Then according to Calculate the one-dimensional edge execution entropy of the memory resources consumed by operator i; The same applies to other resources.

[0049] Then according to It calculates the multidimensional joint execution entropy of IO resources and memory resources to capture the resource cross-penalty characteristics under high concurrency.

[0050] S105. Based on the operator fingerprint feature sequence and execution entropy, align the execution trajectories of the two-end databases and calculate the hybrid similarity; based on the hybrid similarity, compare the semantic consistency of the two-end databases in the target stored procedure and output a stored procedure verification risk report.

[0051] Specifically, the operator fingerprint feature sequence is converted into a high-dimensional vector using the SBERT model to obtain the execution trajectory vector.

[0052] Then according to Calculate the execution trajectory vector corresponding to the source database. Execution trajectory vector corresponding to the target database Mixed similarity between .

[0053] in, This indicates that global semantic cosine similarity is calculated using the SBERT model; This indicates that the Dynamic Time Warping (DTW) algorithm is used to solve the minimum cost path, and its local distance calculation process incorporates the difference between fingerprint edit distance and execution entropy. The weights are adaptive and dynamically adjusted based on the transaction cyclomatic complexity of the stored procedure.

[0054] If the similarity of the mixture is higher than the preset threshold, the consistency verification of the target stored procedure is passed.

[0055] If the mixed similarity is not higher than the preset threshold, it is determined to be semantically inconsistent. At this time, the deviation points in the two trajectory vectors are extracted and the deviation points are input into the RAG arbitrator for semantic difference arbitration. Based on the arbitration result, a stored procedure verification risk report is generated.

[0056] In addition, embodiments of the present invention also provide a database stored procedure verification system, such as... Figure 3 As shown, the database stored procedure verification system 300 specifically includes: The operator fingerprint generation module 310 is used to execute a target stored procedure in a shadow database constructed based on a dual-end database using the same input parameters; wherein, the dual-end database includes a source database and a target database; during the execution process, the key data processing paths in the dual-end database are monitored, and the operator-level execution information of the dual-end database is obtained respectively; based on the operator-level execution information, a corresponding operator fingerprint feature sequence is generated. The execution entropy quantization module 320 is used to calculate the corresponding execution entropy based on the resource consumption information corresponding to the operator fingerprint feature sequence; The comparison and verification module 330 is used to align the execution trajectories of the two-end databases and calculate the hybrid similarity based on the operator fingerprint feature sequence and the execution entropy; based on the hybrid similarity, it compares the semantic consistency of the two-end databases in the target storage procedure and outputs a storage procedure verification risk report.

[0057] The various embodiments in this invention are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, devices, and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0058] The foregoing has described specific embodiments of the present invention. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired results. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0059] The above description is merely an embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, various modifications and variations can be made to the embodiments of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of the embodiments of the present invention should be included within the protection scope of the present invention.

Claims

1. A database stored procedure verification method, characterized in that, The method includes: In a shadow database built on a dual-end database, the target stored procedure is executed using the same input parameters; wherein, the dual-end database includes a source database and a target database; During execution, the key data processing paths in both databases are monitored, and operator-level execution information of both databases is obtained. Based on the operator-level execution information, a corresponding operator fingerprint feature sequence is generated; Calculate the corresponding execution entropy based on the resource consumption information corresponding to the operator fingerprint feature sequence; Based on the operator fingerprint feature sequence and the execution entropy, the execution trajectories of the two-end database are aligned and the hybrid similarity is calculated; Based on the hybrid similarity, the semantic consistency of the two databases in the target stored procedure is compared, and a stored procedure verification risk report is output.

2. The database stored procedure verification method according to claim 1, characterized in that, In an isolated shadow library built on a dual-end database, before executing the target stored procedure with the same input parameters, the method further includes: Obtain the stored procedure code of the target stored procedure, and perform control flow analysis on the stored procedure code to obtain a control flow graph; Identify the key data processing paths in the control flow graph; wherein the key data processing paths include at least one or more of the following: transaction commit processing path, savepoint processing path, sub-transaction processing path, exception block processing path, and vector calculation path.

3. The database stored procedure verification method according to claim 1, characterized in that, In a shadow database built on a dual-end database, the target stored procedure is executed using the same input parameters, specifically including: In an isolated environment, a shadow database is constructed between the source database and the target database; In the shadow database, the same parameters are input to the source database and the target database, controlling the source database and the target database to execute the same target stored procedure simultaneously, and monitoring the execution process of the two databases in real time.

4. The database stored procedure verification method according to claim 1, characterized in that, During execution, key data processing paths in both databases are monitored, and operator-level execution information for both databases is obtained, specifically including: A kernel anchor capture device is mounted in the kernel of the target database, and operator-level execution information of each key data processing path in the target database is obtained through the kernel anchor capture device; wherein, the operator-level execution information includes at least one or more of the following: operator type, tuple count, sub-transaction ID, and memory; Using the extraction tools built into the source database, the execution plan tree and performance view are extracted; the operator-level execution information of each key data processing path in the source database is then extracted from the execution plan tree and performance view.

5. A database stored procedure verification method according to claim 1, characterized in that, Based on the operator-level execution information, a corresponding operator fingerprint feature sequence is generated, specifically including: Define the high-dimensional feature tuple corresponding to the operator fingerprint; Execution plan trees are extracted from the source database and the target database respectively, and the execution plan trees are normalized; wherein, the normalization process includes at least alias elimination, unordered operator rearrangement, and right join equivalence transformation; The execution plan tree is traversed from bottom to top using a post-order traversal method, and operator fingerprint feature sequences corresponding to the source database and the target database are generated based on the high-dimensional feature tuples.

6. A database stored procedure verification method according to claim 5, characterized in that, The execution plan tree is traversed from bottom to top using a post-order traversal method. Based on the high-dimensional feature tuples, operator fingerprint feature sequences corresponding to the source database and the target database are generated, specifically including: Recursively process each child node in the execution plan tree in reverse, generate the operator fingerprint string of the current child node based on the high-dimensional feature tuple, and return the operator fingerprint string to the parent node of the current child node; In the parent node, the operator fingerprint strings corresponding to all its connected child nodes are concatenated to obtain the operator fingerprint string of the parent node; and so on, until the operator fingerprint strings of all nodes are obtained. Hash the operator fingerprint string of each node to obtain the operator fingerprint feature of each node; serialize the operator fingerprint feature of each node to obtain the initial operator fingerprint feature sequence. Based on the number of lines of code and execution cost corresponding to each node, the feature weight of each node is calculated; the feature weight is then fused into the initial operator fingerprint feature sequence to obtain the final operator fingerprint feature sequence.

7. A database stored procedure verification method according to claim 1, characterized in that, Based on the resource consumption information corresponding to the operator fingerprint feature sequence, the corresponding execution entropy is calculated, specifically including: The resource consumption information is obtained from the operator fingerprint feature sequence; wherein, the resource consumption information includes at least: IO consumption, memory consumption, CPU consumption, and resource usage value of each operator; Based on the resource consumption information and the Laplace smoothing term, the resource distribution probability of each operator is calculated; wherein the value space of the resource distribution probability is [0,1]. Based on the resource distribution probability, calculate the one-dimensional edge execution entropy for each resource; Based on the single-dimensional edge execution entropy, the multi-dimensional joint execution entropy of multiple resources is calculated.

8. A database stored procedure verification method according to claim 1, characterized in that, Based on the operator fingerprint feature sequence and the execution entropy, the execution trajectories of the two-end database are aligned and a hybrid similarity is calculated, specifically including: The operator fingerprint feature sequence is converted into a high-dimensional vector using the SBERT model to obtain the execution trajectory vector; according to Calculate the execution trajectory vector corresponding to the source database. Execution trajectory vector corresponding to the target database Mixed similarity between ; in, This indicates that global semantic cosine similarity is calculated using the SBERT model; This indicates that the Dynamic Time Warping (DTW) algorithm is used to solve the minimum cost path, and its local distance calculation process incorporates the difference between fingerprint edit distance and execution entropy. The weights are adaptive and dynamically adjusted based on the transaction cyclomatic complexity of the stored procedure.

9. A database stored procedure verification method according to claim 8, characterized in that, Based on the aforementioned hybrid similarity, the semantic consistency of the two databases in the target stored procedure is compared, and a stored procedure verification risk report is output, specifically including: If the mixed similarity is higher than a preset threshold, the consistency verification of the target stored procedure is passed; If the mixed similarity is not higher than a preset threshold, it is determined to be semantically inconsistent. At this time, the deviation points in the two trajectory vectors are extracted and the deviation points are input into the RAG arbitrator for semantic difference arbitration. Based on the arbitration result, the stored procedure verification risk report is generated.

10. A database stored procedure verification system, characterized in that, The system includes: The operator fingerprint generation module is used to execute a target stored procedure in a shadow database constructed based on a dual-end database using the same input parameters; wherein the dual-end database includes a source database and a target database; during the execution process, the key data processing paths in the dual-end database are monitored, and the operator-level execution information of the dual-end database is obtained respectively; based on the operator-level execution information, a corresponding operator fingerprint feature sequence is generated. The execution entropy quantization module is used to calculate the corresponding execution entropy based on the resource consumption information corresponding to the operator fingerprint feature sequence; The comparison and verification module is used to align the execution trajectories of the two-end databases and calculate the hybrid similarity based on the operator fingerprint feature sequence and the execution entropy; based on the hybrid similarity, it compares the semantic consistency of the two-end databases in the target storage procedure and outputs a storage procedure verification risk report.

Images