Data processing method, database management system and data processing device

By recording the tag information of the executed transactions in the stored procedure and retrying only unexecution transactions, the problem of the submitted transactions being repeatedly executed when the stored procedure fails to execute retry in the prior art is solved, improving the retry efficiency and data consistency sex.

CN112749156BActive Publication Date: 2025-02-18HUAWEI TECH CO LTD

Patent Information

Application Number
CN201911040327.0
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2019-10-29
Publication Date
2025-02-18
Estimated Expiration
2039-10-29

AI Technical Summary

Technical Problem

In the prior art, when the stored procedure fails, the retry mechanism can only re-execute the entire stored procedure once, resulting in repeated execution of the committed transactions, resulting in data errors.

Method used

By recording the tag information of the executed transaction in the stored procedure, only retry unexecuted transactions to avoid repeated execution of committed transactions.

Benefits of technology

Improves the execution efficiency of retry, avoids errors caused by repeated execution of committed transactions during retry, and ensures data consistency.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN112749156B_ABST
    Figure CN112749156B_ABST
Patent Text Reader

Abstract

The embodiment of the present application discloses a data processing method for retrying a failed stored procedure. The method comprises: executing a stored procedure in response to a stored procedure request, wherein the stored procedure comprises one or more ordered transactions, and when the first transaction in the one or more ordered transactions is executed, recording the marking information of the first transaction; based on an exception occurring during the execution of the stored procedure and satisfying the condition for retrying the stored procedure, retrying the transaction after the first transaction in the stored procedure according to the marking information of the first transaction.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the field of database technology, and in particular to a data processing method, a database management system and a data processing device. Background Art

[0002] A stored procedure is a set of statements stored in a database system that can perform specific functions. After the first compilation, the stored procedure does not need to be compiled again when it is called again. Users can run the stored procedure by specifying the name of the stored procedure. Stored procedure retry is a retry mechanism when the stored procedure fails to execute, which can avoid interruptions to user services due to hardware or software failures. A transaction is a sequence of operations performed as a single logical unit of work in a database system. These operations are either all executed or not executed, and are an indivisible unit of work. For example, in a relational database, a transaction can be a structured query language (SQL) statement, a group of SQL statements, or an entire program. A stored procedure may contain one or more transactions.

[0003] In the prior art, the database driver calls the specified stored procedure to respond to the user's request according to the work request sent by the user. When the stored procedure fails to execute and the failure reason is a recoverable exception, the database driver sends a retry request to the database (DB) kernel, obtains the correct processing result and responds to the user. This can shield some hardware and software errors and improve user experience.

[0004] In the prior art, the database driver obtains whether the called stored procedure is executed successfully. When the stored procedure fails, the retry can only re-execute the entire stored procedure. When the stored procedure has a transaction commit instruction, the entire stored procedure retry will cause some of the operations that have been committed to be repeated, resulting in data errors. Summary of the invention

[0005] An embodiment of the present application provides a data processing method for retrying a failed stored procedure, thereby avoiding repeated execution of transactions that have been executed in the stored procedure.

[0006] A first aspect of an embodiment of the present application provides a method for data processing, comprising: executing a stored procedure in response to a stored procedure request, the stored procedure including one or more ordered transactions, and recording marking information of the first transaction when execution of a first transaction in the one or more ordered transactions is completed; and based on an exception occurring during execution of the stored procedure and satisfying a condition for retrying the stored procedure, retrying a transaction in the stored procedure that follows the first transaction according to the marking information of the first transaction.

[0007] A stored procedure may contain one or more ordered transactions. During the execution of a stored procedure, the marker information of the executed transactions in the stored procedure is recorded, such as the location where the transaction ends. In this way, when the stored procedure fails to execute and is retried, only the statements after the executed transaction can be retried, and the executed transaction does not need to be re-executed. This improves the execution efficiency of the retry and avoids errors caused by repeated execution of submitted transactions during retry.

[0008] In a possible implementation manner of the first aspect, the method further includes: recording a request statement for calling the stored procedure.

[0009] The data processing method provided in the embodiment of the present application records the request statement for calling the stored procedure, and the request statement and the marking information of the first transaction can be used to locate the position of the retry execution.

[0010] In a possible implementation manner of the first aspect, the marking information includes a line number of an end statement of the first transaction.

[0011] The data processing method provided in the embodiment of the present application provides a specific implementation method for recording the marking information of the first transaction, thereby enhancing the operability of the solution.

[0012] In a possible implementation manner of the first aspect, the method further includes: recording intermediate state information of the stored procedure, the intermediate state information including one or more of the following: execution statement results, error prompt information, input parameters, output parameters, global variables and temporary variables of the first transaction.

[0013] In the data processing method provided in the embodiment of the present application, the database management system can also record the execution statement results or error prompt information, input parameters, output parameters, global variables and temporary variables of the first transaction, and retry according to the intermediate state information at the end of the first transaction to meet the data consistency.

[0014] In a possible implementation of the first aspect, the intermediate state information includes an execution statement result or error prompt information of the first transaction, and the method further includes: caching the execution statement result or error prompt information of the first transaction until the first transaction ends, and then sending the execution statement result or error prompt information to the user device.

[0015] The data processing method provided in the embodiment of the present application records the execution statement result or error prompt information of the first transaction, and sends it to the user device after the first transaction ends. This can avoid the same execution statement result or error prompt information being repeatedly sent to the user device during retries.

[0016] In a possible implementation of the first aspect, the intermediate state information includes an execution statement result or error prompt information of the first transaction, and the method further includes: caching the execution statement result or error prompt information of the first transaction until the storage process ends, and then sending the execution statement result or error prompt information to the user device.

[0017] The data processing method provided in the embodiment of the present application provides another way to send execution statement results or error prompt information to the user, that is, sending the user after the storage process ends. In this way, the same execution statement result or error prompt information is avoided from being repeatedly sent to the user device during retries.

[0018] In a possible implementation manner of the first aspect, the first transaction is located in a branch of a branch statement in the stored procedure, and the method further includes: recording intermediate state information of the stored procedure, the intermediate state information including a branch execution state, and the branch execution state is used to identify the branch where the first transaction is located; retrying a transaction after the first transaction in the stored procedure includes: based on the branch execution state, executing a transaction after the first transaction in the branch where the first transaction is located.

[0019] In the data processing method provided by the embodiment of the present application, the intermediate state information may also include a branch execution state, which is used to identify the branch of the first transaction in the branch statement, and the branch statement includes an if branch statement or a case branch statement. When retrying, the branch can be continued to be executed according to the branch execution state to avoid retry errors.

[0020] In a possible implementation manner of the first aspect, the branch execution state includes a conditional judgment result of executing the branch statement in the stored procedure, and the conditional judgment result is used to determine a target branch in executing the branch statement.

[0021] In the data processing method provided in the embodiment of the present application, a specific record content of the branch execution status is the conditional judgment result of the branch statement, which enhances the feasibility of the solution.

[0022] In a possible implementation of the first aspect, the method further includes: the condition for retrying the stored procedure is that the stored procedure exception is a recoverable exception, and the recoverable exception includes: network exception, memory usage exception, input and output exception, lock wait timeout exception or two-phase transaction commit exception.

[0023] The data processing method provided in the embodiment of the present application can perform a retry if the exception is a recoverable exception.

[0024] In a possible implementation manner of the first aspect, retrying the transaction after the first transaction in the storage process includes: after waiting for a preset first time period, retrying the transaction after the first transaction in the storage process.

[0025] The data processing method provided in the embodiment of the present application can improve the success rate of retries by waiting for a preset period of time before retrying in scenarios such as active-standby switching.

[0026] In a possible implementation manner of the first aspect, the method further includes: when execution of a second transaction in the one or more ordered transactions is completed, recording marking information of the second transaction, the second transaction being a transaction executed after the first transaction; and retrying the transaction after the first transaction in the stored procedure includes: retrying the transaction after the second transaction in the stored procedure according to the marking information of the second transaction, the second transaction being the last transaction executed in the executed transactions when a condition for retrying the stored procedure is met.

[0027] The data processing method provided in the embodiment of the present application can record the marking information of each transaction if the stored procedure contains multiple transactions. When retrying, it is sufficient to execute the transaction after the last executed transaction, which can further reduce resource waste.

[0028] A second aspect of an embodiment of the present application provides a database management system, characterized in that it includes: an execution unit, which is used to execute a stored procedure in response to a stored procedure request, and the stored procedure includes one or more ordered transactions; a recording unit, which is used to record the marking information of a first transaction in the one or more ordered transactions when the execution of the first transaction of the first transaction is completed; and a retry unit, which is used to retry the transaction after the first transaction in the stored procedure according to the marking information of the first transaction based on an exception occurring during the execution of the stored procedure and satisfying a condition for retrying the stored procedure.

[0029] In a possible implementation manner of the second aspect, the recording unit is further used to: record a request statement for calling the stored procedure.

[0030] In a possible implementation manner of the second aspect, the marking information includes a line number of an end statement of the first transaction.

[0031] In a possible implementation of the second aspect, the database management system also includes: a recording unit, used to record intermediate state information of the stored procedure, and the intermediate state information includes one or more of the following: execution statement results, error prompt information, input parameters, output parameters, global variables and temporary variables of the first transaction.

[0032] In a possible implementation of the second aspect, the intermediate state information includes an execution statement result or error prompt information of a first transaction, and the database management system further includes: a cache unit, used to cache the execution statement result or error prompt information of the first transaction until the first transaction ends, and then send the execution statement result or error prompt information to a user device.

[0033] In a possible implementation of the second aspect, the intermediate state information includes an execution statement result or error prompt information of the first transaction, and the database management system also includes: a cache unit, used to cache the execution statement result or error prompt information of the first transaction until the storage process ends, and then send the execution statement result or error prompt information to the user device.

[0034] In a possible implementation of the second aspect, the first transaction is located in a branch of a branch statement in the stored procedure, and the recording unit is further used to: record intermediate state information of the stored procedure, the intermediate state information including a branch execution state, and the branch execution state is used to identify the branch where the first transaction is located; the retry unit is specifically used to execute a transaction after the first transaction in the branch where the first transaction is located based on the branch execution state.

[0035] In a possible implementation manner of the second aspect, the branch execution state includes a conditional judgment result of executing the branch statement in the stored procedure, and the conditional judgment result is used to determine a target branch in executing the branch statement.

[0036] In a possible implementation of the second aspect, the condition for retrying the stored procedure is that the stored procedure exception is a recoverable exception, and the recoverable exception includes: network exception, memory usage exception, input and output exception, lock wait timeout exception or two-phase transaction commit exception.

[0037] In a possible implementation manner of the second aspect, the retry unit is specifically configured to: after waiting for a preset first period of time, retry a transaction subsequent to the first transaction in the storage process.

[0038] In a possible implementation of the second aspect, the recording unit is further used to, when the execution of a second transaction in the one or more ordered transactions is completed, record the marking information of the second transaction, the second transaction being a transaction executed after the first transaction; the retry unit is specifically used to: retry the transaction after the second transaction in the stored procedure according to the marking information of the second transaction, the second transaction being the last transaction executed in the executed transactions when the condition for retrying the stored procedure is met.

[0039] A third aspect of an embodiment of the present application provides a data processing device, comprising: a memory for storing instructions; a processor for executing the instructions in the memory, so that the data processing device performs the steps of the aforementioned first aspect or each implementation method of the first aspect.

[0040] A fourth aspect of an embodiment of the present application provides a computer program product, characterized in that the computer program product includes instructions, which, when executed on a computer, cause the computer to execute the steps of the aforementioned first aspect or each implementation method of the first aspect.

[0041] A fifth aspect of an embodiment of the present application provides a computer-readable storage medium, characterized in that the computer-readable storage medium stores instructions, which, when executed on a computer, enable the computer to execute the steps of the aforementioned first aspect or each implementation method of the first aspect.

[0042] A sixth aspect of an embodiment of the present application provides a database system, characterized in that it includes a network interface for receiving a stored procedure request sent by a user device; and a data processing device for responding to the stored procedure request and executing a method as described in any one of the first aspect or the various implementation methods of the first aspect.

[0043] It can be seen from the above technical solutions that the embodiments of the present application have the following advantages: the data processing method provided by the embodiments of the present application realizes the retry of the failed execution of the stored procedure, supports the retry of the failed execution of the stored procedure containing the transaction, and since the completed transaction does not need to be re-executed, the execution efficiency of the retry is improved, and the errors caused by the repeated execution of the executed transaction during the retry are avoided. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Figure 1a This is a schematic diagram of the architecture of a stand-alone database system in an embodiment of the present application;

[0045] Figure 1b A schematic diagram of the architecture of a cluster database system in an embodiment of the present application;

[0046] Figure 1c Another schematic diagram of the architecture of the cluster database system in the embodiment of the present application;

[0047] Figure 2 A schematic diagram of the structure of a database server in an embodiment of the present application;

[0048] Figure 3 This is a schematic diagram of an embodiment of a data processing method in an embodiment of the present application;

[0049] Figure 4 A schematic diagram of an embodiment of creating a stored procedure in an embodiment of the present application;

[0050] Figure 5 A flowchart of a stored procedure execution process in an embodiment of the present application;

[0051] Figure 6 This is a schematic diagram of the system architecture of the cluster scenario in the embodiment of the present application;

[0052] Figure 7 This is a schematic diagram of an embodiment of a stored procedure retry in a cluster scenario in an embodiment of the present application;

[0053] Figure 8 This is another schematic diagram of an embodiment of a stored procedure retry in a cluster scenario in an embodiment of the present application;

[0054] Fig. 9 A schematic diagram of a system architecture of a method for retrying a failed stored procedure execution in an embodiment of the present application;

[0055] Fig.10 This is a schematic diagram of an embodiment of a database management system in an embodiment of the present application;

[0056] Fig.11 This is another schematic diagram of an embodiment of the database management system in the embodiment of the present application;

[0057] Fig.12 It is a schematic diagram of an embodiment of a data processing device in an embodiment of the present application. DETAILED DESCRIPTION

[0058] An embodiment of the present application provides a data processing method for retrying a stored procedure upon execution failure, thereby avoiding repeated execution of transactions in the stored procedure.

[0059] The following describes the embodiments of the present application in conjunction with the accompanying drawings. Obviously, the described embodiments are only embodiments of a part of the present application, rather than all embodiments. It is known to those skilled in the art that with the development of technology and the emergence of new scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0060] The terms "first", "second", etc. in the specification and claims of this application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments described here can be implemented in an order other than that illustrated or described here. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or modules is not necessarily limited to those steps or modules clearly listed, but may include other steps or modules that are not clearly listed or inherent to these processes, methods, products or devices. The naming or numbering of steps in this application does not mean that the steps in the method flow must be executed in the time / logical sequence indicated by the naming or numbering. The process steps that have been named or numbered can change the execution order according to the technical purpose to be achieved, as long as the same or similar technical effects can be achieved.

[0061] The data processing method, database management system and database server provided in the embodiments of the present application can be applied to a stand-alone database system or a cluster database system, and the specific details are not limited here. A database system is a data processing system developed to meet the needs of data processing. Figure 1a-1c , is a schematic diagram of the architecture of the database system in the embodiment of the present application, which is briefly introduced below:

[0062] Figure 1a This is a schematic diagram of the architecture of a stand-alone database system in an embodiment of the present application. The stand-alone database system includes a database management system and a data storage device (data store). The database management system is used to provide services such as querying and modifying the database, and the database management system stores the data in the data storage device. In a stand-alone database system, the database management system and the data storage device are usually located on a single server, such as a symmetric multi-processor (SMP) server. The SMP server includes multiple processors, and all processors share resources such as a bus, memory, and I / O system. The functions of the database management system can be implemented by one or more processors executing programs in memory.

[0063] Figure 1bThis is an architectural diagram of a cluster database system in an embodiment of the present application. The cluster database system is a cluster database system using a shared-storage architecture, including multiple nodes (such as nodes 1 to N in the figure), each node is deployed with a database management system, and provides users with services such as querying and modifying the database. Multiple database management systems store shared data in a shared data storage device, and perform read and write operations on the data in the data storage device through a switch. The shared data storage device can be a shared disk array. The nodes in the cluster database system can be physical machines, such as database servers, or virtual machines running on abstract hardware resources. If the node is a physical machine, the switch is a storage area network (SAN) switch, an Ethernet switch, a fiber switch or other physical switching device. If the node is a virtual machine, the switch is a virtual switch.

[0064] Figure 1c Another architectural diagram of the cluster database system in the embodiment of the present application is a cluster database system using a shared-nothing architecture, including multiple nodes (such as nodes 1 to N in the figure), each node has its own exclusive hardware resources (such as data storage), operating system and database, and the nodes communicate through the network. Under this system, data will be distributed to each node according to the database model and application characteristics, and the query task will be divided into several parts, which will be executed in parallel on all nodes, and they will cooperate with each other to provide database services as a whole. All communication functions are implemented on a high-bandwidth network interconnection system. Like the cluster database system with a shared-storage architecture described in cluster database system 1, the nodes here can be either physical machines or virtual machines.

[0065] Figure 1b and Figure 1c The nodes in the cluster database system shown can be set as coordinators or data nodes according to actual usage requirements. The coordinator node is used to receive SQL or stored procedure requests sent by the client. After analysis, the SQL can be sent to the data node that needs to participate in data processing. The data node completes data extraction, and the query results are returned to the coordinator node, which summarizes the data and sends it to the client.

[0066] In all embodiments of the present application, the data storage device (data store) of the database system includes but is not limited to a solid state drive (SSD), a disk array, or other types of non-transitory computer-readable media. Figure 1a-1cAlthough the database is not shown in the figure, it should be understood that the database is stored in the data storage. A person skilled in the art can understand that a database system may include Figure 1a-1c Fewer or more components than those shown in the figure, or including Figure 1a-1c The components shown in the figure are different components. Figure 1a-1c Only components more relevant to the implementation disclosed in this embodiment are shown. Figure 1b and Figure 1c Although four nodes have been described in the two cluster database systems, technicians in the relevant field can understand that a cluster database system can include any number of nodes. The database management system functions of each node can be implemented by an appropriate combination of software, hardware and / or firmware running on each node.

[0067] For ease of understanding and description, as an example rather than a limitation, the following uses a node in a shared-nothing architecture cluster database system, such as a database server, as an example to illustrate the solution of the embodiment of the present application. However, those skilled in the art can clearly understand based on the teachings of the embodiment of the present application that the method of the embodiment of the present application can also be applied to a cluster database system of a shared-storage architecture, a stand-alone database system, and any type of relational database system.

[0068] See also Figure 2 , which is a structural diagram of a database server in an embodiment of the present application.

[0069] like Figure 2As shown, an embodiment of the present application provides a database server 100, including: at least one processor 104, a non-transitory computer-readable medium (non-transitory computer-readable medium) 106 storing executable code, and a database management system 108. The executable code is configured to implement the components and functions of the database management system 108 when executed by at least one processor 104. The non-transitory computer-readable medium 106 may include one or more non-volatile memories. As an example, the non-volatile memory includes a semiconductor memory device, such as an erasable programmable read only memory (EPROM), an electrically erasable programmable read only memory (EEPROM) and a flash memory; a disk, such as an internal hard disk or a removable disk, a magnetooptical disk, and a CD ROM and a DVD-ROM. In addition, the non-transitory computer-readable medium 106 may also include any device configured as a main memory. At least one processor 104 may include any type of general computing circuit or dedicated logic circuit, such as an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit). At least one processor 104 may also be one or more processors, such as a CPU, coupled to one or more semiconductor substrates.

[0070] The database management system 108 may be a relational database management system (RDBMS). The database management system 108 supports structured query language (SQL). Generally, SQL refers to a special programming language specifically used to manage data stored in a relational database. SQL may refer to various types of data-related languages, including, for example, data definition languages ​​and data manipulation languages, where the scope of SQL may include data insertion, query, update and deletion, schema creation and modification, and data access control. In addition, in some examples, SQL may include descriptions related to various language elements.

[0071] A query is a request to view, access and / or manipulate data stored in a database. The database management system 108 can receive a query in SQL format (referred to as an SQL query) from the database client 102. Generally, the database management system 108 generates a query result corresponding to the query by accessing relevant data from the database and manipulating the relevant data, and returns the query result to the database client 102. A database is a collection of data organized, described and stored according to a certain mathematical model. A database may include one or more database structures or formats, such as row storage and column storage. A database is usually stored in a data storage device, such as Figure 2 The external data storage 120 in the non-transitory computer readable medium 106. When the database is stored in the non-transitory computer readable medium 106, the database management system 108 is an in-memory database management system.

[0072] Database client 102 may include any type of device or application configured to interact with database management system 108. In some examples, database client 102 includes one or more application servers.

[0073] The database management system 108 includes an SQL engine 110, an execution engine 122, and a storage engine 134. The SQL engine 110 generates a corresponding execution plan based on the SQL statement submitted by the client 102, such as a query, and the execution engine 122 operates according to the execution plan of the statement to generate the query result. The storage engine 134 is responsible for managing the data of the table and the actual content of the index on the file system, and also manages the cache, buffer, transaction, log and other data during the runtime. For example, the storage engine 134 can write the execution result of the execution engine 122 to the data storage 120 through physical I / O. The SQL engine 110 includes a parser (not shown in the figure) and an optimizer (not shown in the figure), wherein the parser is used to perform grammatical and semantic analysis of the SQL statement, expand the view in the query, and divide it into small query blocks. The optimizer generates a set of execution plans that may be used for the statement, estimates the cost of each execution plan, compares the cost of the plan, and finally selects an execution plan with the lowest cost.

[0074] The following is an introduction to the important concepts involved in the embodiments of the present application:

[0075] A stored procedure is a set of statements stored in a database system that can perform specific functions. After the first compilation, the stored procedure does not need to be compiled again when it is called again. Users can run the stored procedure by specifying the name of the stored procedure.

[0076] A transaction is a sequence of database operations defined by the user in a database system. These operations are either all executed or not executed at all, and are an indivisible unit of work. Transactions have four characteristics: atomicity, consistency, isolation, and durability. In a relational database, a transaction can be a structured query language (SQL) statement, a group of SQL statements, or an entire program. The statements that define transactions in SQL include: BEGIN, COMMIT, and ROLLBACK.

[0077] A transaction usually starts with BEGIN and ends with COMMIT or ROLLBACK. COMMIT means commit, that is, commit all operations of the transaction. Specifically, it means writing all updates to the database in the transaction to the disk, and the transaction ends normally. ROLLBACK means rollback, that is, if some failure occurs during the transaction, the transaction cannot continue to execute, and the system undoes all completed operations on the database in the transaction (UNDO) and rolls back to the state at the beginning of the transaction.

[0078] In the prior art, a database server executes a stored procedure according to a request from a client. When the execution of a stored procedure fails, the entire stored procedure can only be completely retried, and the control granularity is at the stored procedure level.

[0079] When a stored procedure includes one or more transactions, if a transaction ends with COMMIT before an error occurs in the stored procedure, it means that all updates to the database in the transaction have been written to the disk. When the stored procedure is retried, the transaction is repeatedly executed, which will cause data errors. If a transaction ends with ROLLBACK before an error occurs in the stored procedure, it means that some kind of failure occurred during the transaction and the transaction cannot continue to execute. When the stored procedure is retried, the rollback transaction is repeatedly executed, resulting in a waste of resources.

[0080] In addition, the retry in the prior art needs to consider the driver support of different systems, such as open database connectivity (ODBC), Java database connectivity (JDBC), object-relational database management system (ORDBMS), postgresql's C language application program interface Libpq, etc.

[0081] To solve the above problems, an embodiment of the present application provides a data processing method for the failed execution retry process of a stored procedure, which is introduced below in conjunction with a specific embodiment.

[0082] See also Figure 3 , which is a schematic diagram of an embodiment of a data processing method in an embodiment of the present application.

[0083] 301. Execute the stored procedure;

[0084] The database management system receives stored procedure requests from clients; stored procedures can be created by clients, see Figure 4 , is a schematic diagram of an embodiment of creating a stored procedure. For example, a statement for creating a stored procedure is sent through a SQL client and the statement is registered in the database. Thereafter, the stored procedure can be directly called, for example, by sending a stored procedure request through the statement "Call STPTest1();" to implement the call, and the stored procedure is executed in the database. The stored procedure includes one or more ordered transactions.

[0085] 302. Record the first position and intermediate state information of the end of the first transaction;

[0086] During the execution of a stored procedure, when a transaction ends, the database management system can record the transaction's mark information. Optionally, the database management system records the position information of the transaction end statement, or the transaction identifier. Specifically, the database management system records the line number of the transaction end statement. The position at the end of the transaction includes the position of COMMIT or ROLLBACK. For example, Figure 4 As shown in the figure, if an error occurs on the fourth line, the position of the last COMMIT before the fourth line is recorded, that is, the second line (line 2);

[0087] In addition, the database management system also records the intermediate status information of the stored procedure.

[0088] The intermediate state information includes various parameters or variables generated during the execution of the stored procedure, such as the results of the execution statement, error messages during the execution, temporary variables, global variables, input parameters, output parameters, and branch execution status, etc. It can be understood that the intermediate state information is the data that the retry must rely on. If the intermediate state information is missing during the retry, data consistency cannot be met.

[0089] Optionally, the database management system caches the results of executing statements or error prompts that occur during execution. In a stored procedure, if there are intermediate results that need to be returned before COMMIT, they are cached first and not sent to the user device until they are sent at COMMIT, or when the stored procedure is finished. For example, the statement "raise notice 'hello world';" is used to indicate that the prompt message 'hello world' is printed on the screen. If it is sent directly before the end of the transaction, it will be resent during retries, causing the same information to be printed multiple times on the screen. Therefore, the execution statement result is saved through data buffering and sent at the end of the stored procedure execution or the end of the transaction to avoid repeated operations.

[0090] Optionally, the database management system records the values ​​of variables in the stored procedure, including the execution results of temporary variables. For example, Figure 4 After the second line COMMIT is executed, the value of the variable i at that time will be recorded.

[0091] Optionally, the database management system records the input parameters and / or output parameters of the stored procedure, for example, Figure 4 The input parameters x and y of the stored procedure.

[0092] Optionally, the first transaction is located in a branch of a branch statement in the stored procedure, and the database management system records the branch execution status, which is used to identify the branch where the first transaction is located. The branch execution status includes a conditional branch execution status or a case branch execution status. Optionally, the branch execution status is the conditional judgment result of the branch statement. Figure 5 , is a flowchart of the execution process of the stored procedure in the embodiment of the present application. For example, Figure 5 As shown, if the execution process of the stored procedure contains an if branch, it is necessary to record the branch judgment result. For example, for the branch judgment if (select == 6), if select is equal to 6, enter the first branch, and if select is not equal to 6, enter the second branch; recording that the branch judgment result is equal to 6 can be used to determine the execution of the first branch, and recording that the branch judgment result is not equal to 6 can be used to determine the execution of the second branch. When the stored procedure is retried, it can directly enter the branch determined by the branch judgment result without re-executing the if judgment statement.

[0093] For a stored procedure that includes multiple transactions, the end position of each transaction has corresponding intermediate state information. For example, if a stored procedure includes three transactions, which are transaction A, transaction B, and transaction C in the order of execution, during the execution of the stored procedure, when transaction A ends, the corresponding first intermediate state information is recorded, and when transaction B ends, the corresponding second intermediate state information is recorded. At this time, the first intermediate state information can be optionally released. If an error occurs during the execution of transaction C, when retrying, the already ended transactions A and B can be skipped, and the retry can be started from the end position of transaction B according to the second intermediate state information.

[0094] Optionally, the request statement sent by the client to call the stored procedure is recorded, such as "Call STPTest1();". The request statement and the transaction end statement line number can be used together to determine the starting position of the retry.

[0095] 303. Retry the stored procedure according to the first position and intermediate state information at the end of the first transaction;

[0096] Based on an exception occurring during the execution of the stored procedure and the condition for retrying the stored procedure being met, a transaction subsequent to the first transaction in the stored procedure is retried according to the marking information of the first transaction.

[0097] The conditions for retrying the stored procedure include whether the exception is a recoverable exception. There are many types of exceptions that cause the stored procedure to fail, such as: network exceptions such as network disconnection, memory usage exceptions such as memory application failure, input and output (I / O) exceptions such as read exceptions due to busy hard disk, lock wait timeout exceptions, and exceptions that occur during the execution of two-phase transactions, etc. Exceptions that occur during the execution of two-phase transactions include two-phase transaction commit exceptions. The specific reasons for the failure of the stored procedure execution are not limited here. If the exception is a recoverable exception that can be resolved by retrying, the stored procedure will be retried.

[0098] The database management system can capture exceptions, identify the exception type, and determine whether it is a recoverable exception to determine whether a retry is required. If a retry is required, the retry logic is initiated on the server side. The specific process is not introduced here.

[0099] It should be noted that the data processing aspects of the embodiments of the present application are applicable to failed retry of stored procedure execution in different database usage scenarios, including stand-alone databases, cluster databases, and master-slave databases.

[0100] Retry includes one retry or multiple retry. The timing of retry can be direct retry, retry after waiting for a preset time, or retry when a preset condition is met. The specific number of retries and the timing of retry are not limited here.

[0101] The transaction after the first transaction in the stored procedure is retried according to the marking information of the first transaction. When the database management system retries, it skips the executed and committed statements through the previously recorded execution intermediate state, restores to the previously committed consistency state, and retries the transaction after the first transaction.

[0102] It is understandable that a stored procedure may include one or more transactions. If there are multiple transactions in a stored procedure, when the stored procedure fails to execute, it can be retried from the last completed transaction. For example, for a stored procedure containing three transactions, if an error occurs during the execution of the third transaction, the retry can be started from the end of the second transaction.

[0103] For example, Figure 4 As shown, if an error occurs in the fourth line, the statements before the second line COMMIT will be skipped during the retry, and the statements after the second line will continue to be executed according to the variable i recorded in step 302, the input parameters x, y, and the intermediate results generated by the execution.

[0104] If the retry execution is successful, the correct execution result can be returned to the user.

[0105] The data processing method provided in the embodiment of the present application realizes retry of failed execution of stored procedures, and supports retry of failed execution of stored procedures containing transactions. Since ended transactions do not need to be re-executed, the retry granularity is reduced to the transaction level, which improves the execution efficiency of the retry and avoids errors caused by repeated execution of the submitted part during retry.

[0106] See also Figure 6 , is a schematic diagram of the system architecture of the cluster scenario in an embodiment of the present application.

[0107] In the database cluster scenario, there are coordinator nodes and multiple data nodes, such as Figure 6 The data nodes shown are deployed in a master-slave mode. When the master data node fails, the standby data node takes over the query request. When a failure occurs, the coordination node will decide whether to retry, the retry strategy, etc. based on the retry decision module. The embodiment of the present application can handle master-slave switching scenario retries, and deal with various situations such as planned downtime and unplanned downtime. Typically, it includes retries of failed stored procedure execution and retries of execution failure scenarios caused by master-slave node switching. They are introduced below:

[0108] 1. Retry of failed stored procedure execution in a cluster scenario.

[0109] See also Figure 7 , which is a schematic diagram of an embodiment of a stored procedure retry in a cluster scenario in an embodiment of the present application.

[0110] 701. The business application sends a stored procedure request to the coordination node;

[0111] In a cluster database scenario, business applications send stored procedure requests to the coordinating node.

[0112] 702. The coordinating node sends the stored procedure request.

[0113] The coordinating node executes the stored procedure request and sends SQL to the data node based on actual needs or preset rules, and the data node executes part of the SQL.

[0114] The coordination node can obtain the intermediate status information of the stored procedure and capture exceptions during the execution process.

[0115] 703, master-slave synchronization;

[0116] If the data nodes are configured in master-slave mode, the SQL received by the group data nodes will be synchronized to the standby data nodes.

[0117] It should be noted that step 703 is an optional step, which may be executed or not, and is not limited here.

[0118] 704. The coordination node obtains failure information;

[0119] Failure of executing a stored procedure includes failure of execution on the coordinator node or failure of execution on the data node.

[0120] There are many types of exceptions that can cause the stored procedure to fail, such as network exceptions such as network disconnection, memory usage exceptions such as memory application failure, input / output (I / O) exceptions such as read exceptions due to a busy hard disk, lock wait timeout exceptions, and exceptions that occur during the execution of a two-phase transaction. The specific reasons for the failure of the stored procedure are not limited here. If the exception is a recoverable exception, a retry of the stored procedure will be initiated.

[0121] Optionally, the data node executes the SQL and returns the execution result to the coordinating node. If an error occurs in the execution of the data node, the coordinating node can obtain the failure information of the stored procedure.

[0122] For the specific implementation process, please refer to Figure 3 The corresponding step 302 in the embodiment will not be described in detail here.

[0123] 705. Cause of failure of coordination node check;

[0124] The coordination node identifies whether the reason for the data node execution failure is a recoverable exception that can be recovered by retrying. If so, a retry is initiated. Optionally, the coordination node decision module determines whether to retry and the time to delay the retry based on the current master-slave status.

[0125] 706. Retry the stored procedure.

[0126] The coordination node issues a retry request based on the recorded intermediate status information of the storage process, and the primary data node or the backup data node retries based on the intermediate status information of the storage process. For the specific implementation process, please refer to Figure 3 Step 303 in the corresponding embodiment will not be described in detail here.

[0127] 2. In a cluster scenario, retry of failed execution caused by switching between the primary and standby nodes.

[0128] See also Figure 8 , which is another schematic diagram of an embodiment of a stored procedure retry in a cluster scenario in an embodiment of the present application.

[0129] 801. The business application sends a stored procedure request to the coordination node;

[0130] 802. The coordinating node sends the stored procedure request.

[0131] 803, master-slave synchronization;

[0132] It should be noted that step 803 is an optional step, which may be executed or not, and is not limited here.

[0133] Step 801 to step 803 and Figure 7 Steps 701 to 703 in the corresponding embodiment are similar and will not be described again here.

[0134] 804. When the data node fails to execute, the master-slave switch is performed;

[0135] When the data node executes the stored procedure, the coordination node will record the data carrying the intermediate status information of the stored procedure execution. For the specific implementation process, please refer to Figure 3 The corresponding step 302 in the embodiment will not be described in detail here.

[0136] When a data node stored procedure fails to execute, an error is reported to the coordinating node.

[0137] Optionally, there are multiple types of exceptions that cause the failure of the stored procedure execution on the data node. The specific reasons for the failure of the stored procedure execution are not limited here.

[0138] If the primary data node crashes and the backup data node is working normally, the background cluster management module will sense this and the coordination node will instruct the primary and backup nodes to switch. The switching of primary and backup nodes is usually controlled by the cluster management system, which is mainly responsible for starting and stopping the entire cluster and collecting the operating status of each node. When an abnormal operation is found, it controls the primary and backup switching by sending commands to the data nodes.

[0139] 805. Retry the stored procedure.

[0140] The coordination node retries according to the recorded intermediate status information of the storage process, including sending the execution task to the standby data node for retry. For the specific implementation process, please refer to Figure 3 Step 303 in the corresponding embodiment will not be described in detail here.

[0141] Optionally, the coordinating node can synchronize data with other coordinating nodes in a synchronous manner, or save intermediate variables of the execution result set before the stored procedure execution fails by writing to disk. In this way, even if the coordinating node crashes, the stored procedure execution failure can still be retried.

[0142] See also Fig. 9 , which is a system architecture diagram of a method for retrying a failed stored procedure execution in an embodiment of the present application.

[0143] The database management system saves the location of the executed transaction end statement during the execution of the stored procedure, as well as the intermediate state information when the transaction ends. After the database management system captures the exception, it resends the stored procedure request to achieve a retry. Since the data processing method of this embodiment records the location when the transaction ends and the corresponding intermediate state information, fine-grained retry can be achieved, improving the customer experience when software and hardware are abnormal.

[0144] The above introduces a data processing method for implementing a stored procedure execution failure retry. The following introduces a data processing device for implementing this method.

[0145] See also Fig.10 , is a schematic diagram of an embodiment of a database management system in an embodiment of the present application.

[0146] The database management system provided in the embodiment of the present application can be deployed in a stand-alone database system, or a node in various types of cluster database systems. The node can run on a physical machine or a virtual machine, which is not specifically limited here.

[0147] In practical applications, the data processing device for deploying the database management system may be a database server, or a dedicated data processing device, etc., which is not specifically limited here.

[0148] The database management system 1000 provided in the embodiment of the present application includes:

[0149] An execution unit 1001 is used to execute a stored procedure in response to a stored procedure request, where the stored procedure includes one or more ordered transactions;

[0150] The recording unit 1002 is configured to record the marking information of the first transaction when the execution of the first transaction in the one or more ordered transactions is completed;

[0151] The retry unit 1003 is configured to retry a transaction subsequent to the first transaction in the stored procedure according to the marking information of the first transaction, based on an exception occurring during the execution of the stored procedure and the condition for retrying the stored procedure being met.

[0152] The recording unit 1002 is also used to record the request statement for calling the stored procedure.

[0153] The marking information includes the line number of the end statement of the first transaction.

[0154] The device also includes:

[0155] The recording unit 1002 is used to record the intermediate state information of the stored procedure, and the intermediate state information includes one or more of the following: the execution statement result of the first transaction, error prompt information, input parameters, output parameters, global variables and temporary variables.

[0156] The intermediate state information includes an execution statement result or error prompt information of the first transaction, and the device further includes:

[0157] The cache unit 1004 is used to cache the execution statement result or error prompt information of the first transaction until the first transaction ends, and then send the execution statement result or error prompt information to the user device.

[0158] The intermediate state information includes an execution statement result or error prompt information of the first transaction, and the device further includes:

[0159] The cache unit 1004 is used to cache the execution statement result or error prompt information of the first transaction until the storage process is completed, and then send the execution statement result or error prompt information to the user device.

[0160] The first transaction is located in a branch of a branch statement in the stored procedure, and the recording unit 1002 is further used for:

[0161] Recording intermediate state information of the stored procedure, where the intermediate state information includes a branch execution state, where the branch execution state is used to identify the branch where the first transaction is located;

[0162] The retry unit 1003 is specifically configured to execute a transaction subsequent to the first transaction in the branch where the first transaction is located based on the branch execution status.

[0163] The branch execution status includes the conditional judgment result of executing the branch statement in the stored procedure.

[0164] The condition for retrying the stored procedure is that the stored procedure exception is a recoverable exception, and the recoverable exception includes: network exception, memory usage exception, input and output exception, lock wait timeout exception or two-phase transaction commit exception.

[0165] The retry unit 1003 is specifically configured to: after waiting for a preset first period of time, retry the transaction after the first transaction in the storage process.

[0166] The recording unit 1002 is further configured to record, when a second transaction in the one or more ordered transactions is completed, marking information of the second transaction, where the second transaction is executed after the first transaction.

[0167] The retry unit 1003 is specifically used to retry the transaction after the second transaction in the stored procedure according to the marking information of the second transaction, and the second transaction is the last transaction executed in the executed transactions when the condition for retrying the stored procedure is met.

[0168] See also Fig.11 , is a schematic diagram of another embodiment of the database management system in the embodiments of the present application.

[0169] The database management system can include multiple software function modules, including database server framework (DBframework), database compiler, database executor and database exception handling modules, and the newly added sub-module implements the retry logic. Among them:

[0170] 1. Database server framework, used to parse the message sent by the user to determine the type of message, such as SQL message, PBE message, etc. It is also used to save the original request statement for use in preparation for retry; it is also used to save intermediate status information, etc.

[0171] 2. Database compiler: used to limit the application scenario check. If an unsupported scenario is encountered, a no-retry flag is set.

[0172] 3. Database executor: used to save stored procedure variables and parameters, save the position at the end of the transaction, including the position of COMMIT and ROLLBACK, and save the intermediate status information at the end of the transaction, including the first procedure parameters, branch execution status, and execution results of the first variable.

[0173] 4. Stored procedure exception handling module: used to capture exceptions and check whether a retry is required; it can also be used to roll back transactions.

[0174] The database server may include: a re-execution module for starting a new transaction; based on the COMMIT position information saved during the last execution, if the branch determines the result, skipping the COMMIT statement; and restoring the current state based on the COMMIT point information during the last execution, including variables and parameters, and result set information during COMMIT.

[0175] It should be noted that the prerequisites include that the data is not sent to the client before the stored procedure is executed; and the fault is a processable fault, and retrying the program internal fault is meaningless.

[0176] 5. Exception retry module restarts a new transaction; skips the submitted statements based on the intermediate status information such as the COMMIT position information saved during the last execution, the if branch judgment result, etc.; restores the current status, including variables and parameters, based on the intermediate status information corresponding to the COMMIT point during the last execution.

[0177] See also Fig.12 , which is a schematic diagram of an embodiment of a data processing device in an embodiment of the present application.

[0178] The data processing device provided in this embodiment may be a server or a dedicated data processing device, such as a database server. The specific device form is not limited in the embodiments of the present application.

[0179] The data processing device 1200 may have relatively large differences due to different configurations or performances, and may include one or more processors 1201 and a memory 1202 , in which programs or data are stored.

[0180] The memory 1202 may be a volatile storage or a non-volatile storage. Optionally, the processor 1201 is one or more central processing units (CPUs), or a dedicated processor, and the CPU may be a single-core CPU or a multi-core CPU. The processor 1201 may communicate with the memory 1202 and execute a series of instructions in the memory 1202 on the data processing device 1200.

[0181] The data processing device 1200 further includes one or more wired or wireless network interfaces 1203 , such as Ethernet interfaces.

[0182] Optionally, although Fig.12 Not shown, the data processing device 1200 may also include one or more power supplies; one or more input and output interfaces, which may be used to connect a display, a mouse, a keyboard, a touch screen device or a sensor device, etc. The input and output interfaces are optional components and may or may not exist, and are not limited here.

[0183] The process executed by the processor 1201 in the data processing device 1200 in this embodiment can refer to the method process described in the aforementioned method embodiment, and will not be repeated here.

[0184] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0185] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0186] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0187] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0188] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk and other media that can store program code.

[0189] As described above, the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for data processing, characterized in that: include: In response to a stored procedure request, executing a stored procedure, the stored procedure comprising one or more ordered transactions; When a first transaction in the one or more ordered transactions is executed to completion, recording marking information of the first transaction, the marking information including a line number of an end statement of the first transaction; Based on an exception occurring during the execution of the stored procedure and a condition for retrying the stored procedure being met, a transaction subsequent to the first transaction in the stored procedure is retried according to the marking information of the first transaction.

2. The method according to claim 1, characterized in that The method further comprises: Record the request statement that calls the stored procedure.

3. The method according to any one of claims 1, characterized in that The method further comprises: The intermediate state information of the stored procedure is recorded, wherein the intermediate state information includes one or more of the following: the execution statement result, error prompt information, input parameters, output parameters, global variables and temporary variables of the first transaction.

4. The method according to claim 3, characterized in that The intermediate state information includes an execution statement result or error prompt information of the first transaction, and the method further includes: Cache the execution statement result or error prompt information of the first transaction until the first transaction ends, and then send the execution statement result or error prompt information to the user device.

5. The method according to claim 3, characterized in that: The intermediate state information includes an execution statement result or error prompt information of the first transaction, and the method further includes: The execution statement result or error prompt information of the first transaction is cached until the storage process ends, and then the execution statement result or error prompt information is sent to the user device.

6. The method according to any one of claims 1, characterized in that The first transaction is located in a branch of a branch statement in the stored procedure, and the method further includes: Recording intermediate state information of the stored procedure, wherein the intermediate state information includes a branch execution state, and the branch execution state is used to identify the branch where the first transaction is located; Retrying the transaction after the first transaction in the stored procedure includes: executing the transaction after the first transaction in the branch where the first transaction is located based on the branch execution status.

7. The method according to claim 6, characterized in that The branch execution status includes a conditional judgment result of executing the branch statement in the stored procedure.

8. The method according to any one of claims 1 to 7, characterized in that The condition for retrying the stored procedure is that the stored procedure exception is a recoverable exception, and the recoverable exception includes: network exception, memory usage exception, input and output exception, lock wait timeout exception or two-phase transaction commit exception.

9. The method according to any one of claims 1 to 7, characterized in that The retrying of the transaction after the first transaction in the stored procedure includes: After waiting for a preset first time period, the transaction after the first transaction in the storage process is retried.

10. The method according to any one of claims 1 to 7, characterized in that The method further comprises: When a second transaction in the one or more ordered transactions is executed, record marking information of the second transaction, where the second transaction is a transaction executed after the first transaction; The retrying of the transaction after the first transaction in the stored procedure includes: The transaction after the second transaction in the stored procedure is retried according to the marking information of the second transaction, where the second transaction is the last transaction executed among the executed transactions when the condition for retrying the stored procedure is met.

11. A database management system, characterized in that: include: An execution unit, configured to execute a stored procedure in response to a stored procedure request, wherein the stored procedure includes one or more ordered transactions; a recording unit, configured to record, when a first transaction in the one or more ordered transactions is finished executing, marking information of the first transaction, wherein the marking information includes a line number of an end statement of the first transaction; A retry unit is used to retry a transaction after the first transaction in the stored procedure according to the marking information of the first transaction if an exception occurs during the execution of the stored procedure and a condition for retrying the stored procedure is met.

12. The database management system according to claim 11, characterized in that: The recording unit is also used for: Record the request statement that calls the stored procedure.

13. The database management system according to claim 11, characterized in that: The recording unit is also used for: The intermediate state information of the stored procedure is recorded, wherein the intermediate state information includes one or more of the following: the execution statement result, error prompt information, input parameters, output parameters, global variables and temporary variables of the first transaction.

14. The database management system according to claim 13, characterized in that: The intermediate state information includes the execution statement result or error prompt information of the first transaction, and the database management system further includes: The cache unit is used to cache the execution statement result or error prompt information of the first transaction until the first transaction ends, and then send the execution statement result or error prompt information to the user device.

15. The database management system according to claim 13, characterized in that: The intermediate state information includes the execution statement result or error prompt information of the first transaction, and the database management system further includes: The cache unit is used to cache the execution statement result or error prompt information of the first transaction until the storage process is completed, and then send the execution statement result or error prompt information to the user device.

16. The database management system according to claim 11, characterized in that: The first transaction is located in a branch of a branch statement in the stored procedure, and the recording unit is further used for: Recording intermediate state information of the stored procedure, wherein the intermediate state information includes a branch execution state, and the branch execution state is used to identify the branch where the first transaction is located; The retry unit is specifically configured to execute a transaction subsequent to the first transaction in the branch where the first transaction is located based on the branch execution status.

17. The database management system according to claim 16, characterized in that: The branch execution status includes a conditional judgment result of executing the branch statement in the stored procedure, and the conditional judgment result is used to determine which branch of the branch statement is executed.

18. The database management system according to any one of claims 11 to 17, characterized in that: The condition for retrying the stored procedure is that the stored procedure exception is a recoverable exception, and the recoverable exception includes: network exception, memory usage exception, input and output exception, lock wait timeout exception or two-phase transaction commit exception.

19. The database management system according to any one of claims 11 to 17, characterized in that: The retry unit is specifically used for: After waiting for a preset first time period, the transaction after the first transaction in the storage process is retried.

20. The database management system according to any one of claims 11 to 17, characterized in that: The recording unit is further configured to record, when a second transaction in the one or more ordered transactions is completed, marking information of the second transaction, where the second transaction is a transaction executed after the first transaction; The retry unit is specifically used for: The transaction after the second transaction in the stored procedure is retried according to the marking information of the second transaction, where the second transaction is the last transaction executed among the executed transactions when the condition for retrying the stored procedure is met.

21. A data processing device, characterized in that: include: A memory for storing instructions; A processor, configured to execute instructions in the memory so that the data processing device executes the method according to any one of claims 1 to 10.

22. A computer program product, characterized in that The computer program product comprises instructions, which, when executed on a computer, cause the computer to perform the method according to any one of claims 1 to 10.

23. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores instructions, and when the instructions are executed on a computer, the computer is caused to perform the method according to any one of claims 1 to 10.

24. A database system, characterized in that: include: A network interface, used for receiving a storage process request sent by a user device; A data processing device, configured to execute the method according to any one of claims 1 to 10 in response to the stored procedure request.

Citation Information

Patent Citations

  • Automatic transaction retry after session failure

    CN104508663A

  • Processing method and device of database deadlock and database system

    CN108205464A

Cited By

  • System and method for dynamic task network routing based on task simulations on various software applications

    US12750418B2

  • System and method for dynamic task network routing based on task simulations on various software applications

    US20260095499A1