Database task execution method and device, equipment and medium

Abstract

The invention relates to the technical field of data processing and the field of financial science and technology, and discloses a database task execution method, which comprises the following steps of: receiving an execution request of a database task, judging whether a corresponding SQL statement set is defined for the task, extracting an effective SQL statement, calling an execution method to execute the task according to a statement type, and judging an execution result. If the execution is successful, continuing to execute the next SQL statement; if execution fails, failure information is recorded, an abnormal log is generated and sent to the service management end, and after all the SQL statements are executed, a final execution result of the database task is generated. By optimizing the execution management of the SQL statements, the task execution efficiency is improved, and the accuracy and efficiency of the task execution process are ensured. And through an abnormal log record and result feedback mechanism, the fault processing capability and the operation and maintenance efficiency of the system are enhanced, and the system interruption risk caused by execution failure is reduced.

Description

Technical Field

[0001] The present invention relates to the fields of data processing technology and financial technology, and in particular to a database task execution method, device, equipment and storage medium. Background Art

[0002] As the financial industry moves towards de-IOE (eliminating international giants such as IBM, Oracle, and EMC), open source database systems such as MySQL are gradually replacing traditional Oracle databases. However, in the process of processing large amounts of data and complex business logic, the task execution and management capabilities of existing MySQL databases face significant challenges, especially when performing storage-related tasks. Existing technologies have the following problems:

[0003] First, there is insufficient support and management for storage operations during task execution. Financial services involve a large number of stored procedure calls. However, in MySQL, the execution efficiency of stored procedures is low and cannot effectively handle massive data and high-concurrency tasks. In addition, the invisibility of stored procedure execution makes it difficult to track and locate problems when they occur, increasing the difficulty of operation, maintenance and debugging.

[0004] Secondly, there is a lack of effective task execution status feedback mechanism. When executing storage tasks, the existing MySQL system often lacks complete status feedback of the execution process, making it difficult to quickly determine the execution results of each storage operation. In particular, when a storage task fails, it is impossible to record error logs or generate corresponding exception information in a timely manner, which brings difficulties to subsequent maintenance and problem repair.

[0005] Therefore, when performing storage-related tasks, the existing technologies have problems such as low execution efficiency, difficulty in tracking the storage process, and insufficient task status feedback mechanism. There is an urgent need for a technical solution that can improve the execution efficiency of storage tasks, support task status tracking, and generate feedback in time when task execution fails, in order to meet the financial industry's needs for efficient and reliable database management. Summary of the invention

[0006] The main purpose of the present invention is to provide a database task execution method, device, equipment and storage medium, aiming to solve the technical problem that the prior art lacks an effective management and feedback mechanism for the SQL task execution process, resulting in the inability to timely record and process execution results and abnormal information when the storage task is executed.

[0007] To achieve the above object, the present invention provides a database task execution method, comprising:

[0008] Receive execution request of database task;

[0009] Determine whether the configuration processing module has defined a corresponding SQL statement set for the database task;

[0010] If a corresponding SQL statement set has been defined, extracting a valid SQL statement from the SQL statement set;

[0011] According to the type of the valid SQL statement, calling a corresponding execution method, executing the valid SQL statement, and determining whether the valid SQL statement is executed successfully;

[0012] If the valid SQL statement is executed successfully, continue to execute the next valid SQL statement;

[0013] If the valid SQL statement fails to execute, the failure information is recorded, an exception log is generated, and the exception log is sent to the business management end;

[0014] When all valid SQL statements in the SQL statement set are executed successfully, the execution process of the database task is terminated;

[0015] Based on the execution result of each valid SQL statement, a final execution result of the database task is generated.

[0016] Furthermore, to achieve the above-mentioned purpose, the present invention provides a database task execution device, comprising:

[0017] A task receiving module, used to receive execution requests of database tasks;

[0018] The configuration processing module is used to determine whether the configuration processing module has defined a corresponding SQL statement set for the database task;

[0019] An SQL screening module, for extracting valid SQL statements from a corresponding SQL statement set if the corresponding SQL statement set has been defined;

[0020] An SQL execution module, used to call a corresponding execution method according to the type of the valid SQL statement, execute the valid SQL statement, and determine whether the valid SQL statement is executed successfully;

[0021] A task scheduling module, used for continuing to execute the next valid SQL statement if the valid SQL statement is executed successfully;

[0022] An exception handling module is used to record failure information, generate an exception log, and send the exception log to the business management end if the execution of the valid SQL statement fails;

[0023] An execution completion module, used to end the execution process of the database task when all valid SQL statements in the SQL statement set are executed successfully;

[0024] The result generation and reporting module is used to generate the final execution result of the database task based on the execution result of each valid SQL statement.

[0025] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer device, which includes a memory, a processor, and a database task execution program stored in the memory and executable on the processor, and the database task execution program, when executed by the processor, implements the steps of the database task execution method as described above.

[0026] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer-readable storage medium, on which a database task execution program is stored, and when the database task execution program is executed by a processor, the steps of the database task execution method described above are implemented.

[0027] Beneficial effects: The present invention relates to the fields of data processing technology and financial technology, and discloses a database task execution method, which receives an execution request for a database task, determines whether a corresponding set of SQL statements has been defined for the task, extracts valid SQL statements, and calls the execution method to execute the task according to the statement type, and determines the execution result. If the execution is successful, the next SQL statement is executed; if the execution fails, the failure information is recorded and an exception log is generated and sent to the business management end. After all SQL statements are executed, the final execution result of the database task is generated. The present invention improves the execution efficiency of tasks and ensures the accuracy and efficiency of the task execution process by optimizing the execution management of SQL statements. Through the exception log recording and result feedback mechanism, the system's fault handling capability and operation and maintenance efficiency are enhanced, and the risk of system interruption caused by execution failure is reduced. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] The present invention will be further described below with reference to the accompanying drawings and embodiments, in which:

[0029] Figure 1 A schematic diagram of an application environment of a database task execution method in an embodiment of the present invention;

[0030] Figure 2 A schematic diagram of a flow chart of an embodiment of a method for executing a database task according to the present invention;

[0031] Figure 3 It is a functional module diagram of a preferred embodiment of the database task execution device of the present invention;

[0032] Figure 4 A schematic diagram of the structure of a computer device in one embodiment of the present invention;

[0033] Figure 5FIG. 4 is another schematic diagram of the structure of a computer device in one embodiment of the present invention. DETAILED DESCRIPTION

[0034] It should be understood that the specific embodiments described herein are only used to explain the present invention, and are not used to limit the present invention.

[0035] The database task execution method provided by the embodiment of the present invention can be applied in Figure 1 In the application environment, the user terminal communicates with the server terminal through the network. The server terminal can receive the execution request of the database task through the user terminal, determine whether the corresponding SQL statement set has been defined for the task, extract the valid SQL statement, and call the execution method according to the statement type to execute the task. The execution result is judged. If the execution is successful, the next SQL statement is continued to be executed; if the execution fails, the failure information is recorded and an exception log is generated and sent to the business management terminal. After all SQL statements are executed, the final execution result of the database task is generated. The present invention improves the execution efficiency of the task by optimizing the execution management of the SQL statement, and ensures the accuracy and efficiency of the task execution process. Through the exception log recording and result feedback mechanism, the fault handling capability and operation and maintenance efficiency of the system are enhanced, and the risk of system interruption caused by execution failure is reduced. Among them, the user terminal can be but not limited to various personal computers, laptops, smart phones, tablet computers and portable wearable devices. The server can be implemented with an independent server or a server cluster composed of multiple servers. The present invention is described in detail below through specific embodiments.

[0036] See also Figure 2 , Figure 2 This is a flow chart of an embodiment of a method for executing a database task provided by the present invention. It should be noted that although a logical sequence is shown in the flow chart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0037] like Figure 2 As shown, the database task execution method proposed by the present invention includes the following steps:

[0038] S10, receiving a database task execution request;

[0039] In this embodiment, the system or service receives a request to execute a database task. The request usually contains key information, such as task ID, user credentials, task type, etc. The task ID is used to uniquely identify the database task to ensure that the task is not repeated or executed incorrectly; the user credentials are used to verify the identity of the user to ensure that the user has the authority to initiate the task; the task type is used to distinguish the execution logic of the task, such as query, write or management tasks.

[0040] The system can provide a RESTful or RPC API interface, and users or systems can submit database task execution requests through POST requests. The task requests are transmitted as data bodies in formats such as JSON or XML.

[0041] In some scenarios, task requests may be delivered through message queues (such as Kafka and RabbitMQ) to ensure the order and reliability of tasks in high-concurrency scenarios. In this way, the task receiving module listens to a specific queue and reads and parses the task request content when a task request arrives.

[0042] After receiving the task request, the system needs to parse the task ID, user credentials, and task type in the request. Verify that the task ID is valid, check the legitimacy of the user credentials, and ensure that the task type is a supported type.

[0043] Example: In the financial field, users may submit requests related to storage operations, such as requesting to execute a stored procedure to back up historical transaction data. The system receives these requests through the API, verifies the user's credentials and task identifier, ensures that only authorized requests can execute the corresponding storage operations, and adds legitimate storage requests to the task scheduling system.

[0044] Through the above steps, external task requests can be received and parsed to ensure the legitimacy and effectiveness of task execution, and avoid the impact of illegal requests on the system. By receiving and verifying task identifiers and user credentials, the security of task management and the correctness of task execution can be improved.

[0045] S20, determining whether the configuration processing module has defined a corresponding SQL statement set for the database task;

[0046] In this embodiment, it is checked whether a SQL statement set has been predefined for the received database task. Before executing each database task, the system needs to verify whether the task has a corresponding SQL statement set to ensure that the task has clear execution instructions when it is executed. The SQL statement set usually includes a set of SQL instructions for implementing specific business logic.

[0047] The system will query the task ID of the database task in the configuration processing module and find the SQL statement set associated with it based on the ID. If the relevant definition is found, it means that the task is ready and can execute the corresponding SQL statement.

[0048] If the SQL statement set corresponding to the task identifier cannot be found in the configuration processing module, an error prompt is returned and the task execution is terminated. Otherwise, the system will extract the relevant SQL statement set for subsequent use.

[0049] The SQL statement set in the configuration processing module can be stored and managed through a configuration file, a database table, or other predefined storage system. The system performs a quick search based on the task identifier.

[0050] Example: In the financial sector, banks may pre-configure SQL statement sets for different storage tasks, such as backing up daily transaction records or archiving historical data. After the system receives a storage task request, it checks from the configuration processing module whether a SQL statement set for the backup operation is defined for the task. If it is defined, the system will extract these SQL statements for subsequent storage operations. If it is not defined, the system will return an error, prompting the user that the task is not ready, to avoid executing the task without clear instructions.

[0051] By pre-defining a set of SQL statements, you can reduce the uncertainty of task execution and ensure that the task can be executed smoothly. If the SQL set is not defined, the system can terminate the task execution in time to avoid wasting system resources and the risk of execution failure.

[0052] S30, if a corresponding SQL statement set has been defined, extracting a valid SQL statement from the SQL statement set;

[0053] In this embodiment, after confirming that the database task has defined a set of SQL statements, the system needs to extract "valid" SQL statements from the set. Valid SQL statements refer to SQL statements that meet business requirements, conform to grammatical specifications, and can be executed normally. The purpose of extracting valid SQL statements is to ensure that in actual task execution, the system only executes instructions that are useful for the current task, and avoid invalid or erroneous SQL statements that cause task execution failure.

[0054] When the system extracts SQL statements, it will first check the syntax of each SQL statement to ensure that these SQL statements comply with the syntax specifications of the SQL language. If the statement has a syntax error, it will be marked as an invalid SQL statement and the system will not execute the statement.

[0055] In addition to syntax checking, the system also verifies the logic of SQL statements to ensure that the logic of each SQL statement meets the business requirements of the current task. For example, some SQL statements may require specific database table structures or fields. If these structures or fields are missing in the current database, these statements will be considered invalid.

[0056] For some SQL statements that need to depend on other SQL statements (for example, an insert statement depends on a table creation statement), the system will check the dependencies between the SQL statements to ensure that the execution order is reasonable.

[0057] The system traverses the entire SQL statement set, screens and verifies each one, and extracts valid SQL statements that meet the requirements. The screened valid SQL statements will be added to the task execution queue for use by the subsequent task scheduling module.

[0058] Example: In a financial storage task, such as backing up daily transaction data, the system may configure multiple SQL statements for the task to back up different data tables. Before the task is executed, the system first checks these SQL statements to confirm that they comply with the syntax and business logic to ensure that all backup operations can be successfully executed. For example, a SQL statement may be invalid because a data table field is missing. The system will automatically exclude the statement to ensure that the task will not be interrupted due to statement errors.

[0059] By extracting valid SQL statements from the SQL statement set, the system can avoid task execution failures caused by syntax errors or logical errors. This improves the accuracy and reliability of database task execution and ensures that only those SQL statements that have passed verification can be executed, thereby improving the success rate of tasks and the stability of the system.

[0060] S40, calling a corresponding execution method according to the type of the valid SQL statement, executing the valid SQL statement, and determining whether the valid SQL statement is executed successfully;

[0061] In this embodiment, each SQL statement has different types, generally including query statements (SELECT), insert statements (INSERT), update statements (UPDATE), delete statements (DELETE) and DDL statements (such as CREATE, ALTER, etc.). The system needs to call the appropriate executor to execute the corresponding type of SQL statement according to the type of SQL statement.

[0062] After selecting the corresponding executor, the system will actually execute the SQL statement. During the execution process, the system needs to interact with the database and submit the SQL statement to the database execution engine for processing.

[0063] After the SQL statement is executed, the system needs to determine whether the statement is executed successfully. Usually, the system can judge by the return value or execution result after the SQL statement is executed. For example, the success of a query statement can be determined by the returned data set, while the success of an insert or update statement can be determined by the number of rows affected.

[0064] For a SELECT query statement, the system will call the query executor to execute the SQL statement, and the query results will be returned in the form of a data set.

[0065] For INSERT, UPDATE, and DELETE statements, the system calls the Write Executor to perform these data change operations. If the execution is successful, the system returns the number of affected rows to confirm whether the operation is successful.

[0066] For DDL statements (such as CREATE TABLE or ALTER TABLE), the system calls the DDL execution module to process the table structure change operation.

[0067] The system determines the executor based on the type of SQL statement and passes the SQL statement to the corresponding executor. The executor interacts with the database and executes the SQL statement. The execution result of the SQL statement is returned to the system in a standardized form.

[0068] The criteria for success can be:

[0069] Query statement: If the returned data set is not empty, the execution is considered successful; if an error occurs or an empty data set is returned, it is considered a failure.

[0070] Insert, update, and delete statements: Success is determined by checking the number of rows affected. Generally, if the number of rows affected is greater than 0, the statement is considered successful, otherwise it is considered a failure.

[0071] DDL statement: Determine whether the operation is successful by checking whether the table structure is changed successfully or capturing the DDL execution results returned by the database.

[0072] Example: In the financial field, storage tasks may include regular backup and data archiving operations. When the system processes these storage tasks, it may need to execute a set of storage-related SQL statements, including INSERT statements for inserting backup data and SELECT statements for checking backup status. The system will call the appropriate executor to handle each operation based on the type of SQL statement. For example, after the INSERT statement for backup data is executed, the system will determine whether the backup operation is successful by the number of affected rows; when executing a query statement for checking the operation, the system will confirm whether the backup is complete by the returned data set.

[0073] By classifying SQL statement types and calling corresponding execution methods, the system can handle various types of SQL operations more efficiently. Judging whether the SQL statement is successfully executed based on the execution results helps the system quickly discover and handle errors during task execution, ensuring the accuracy and stability of database operations.

[0074] S50, if the valid SQL statement is executed successfully, continue to execute the next valid SQL statement;

[0075] In this embodiment, during the execution of a database task, the system completes the task by executing SQL statements one by one. If the current SQL statement is executed successfully, the system automatically loads the next valid SQL statement and continues to execute it. This process ensures that the SQL statements in the database task are executed in sequence according to the predefined order or dependency relationship until all valid SQL statements are executed or an error is encountered.

[0076] The set of SQL statements in the system is usually sequential, and some SQL statements may depend on the execution result of the previous statement. For example, in a storage task, the SQL statement for inserting data may depend on the successful creation of the table structure. Therefore, during the execution process, the system needs to ensure that the next SQL statement can only be executed after the execution of one statement is successful. If a problem occurs during the execution process, the execution process should be terminated or enter the exception handling process.

[0077] After executing the current SQL statement, the system will determine whether the SQL statement is executed successfully based on the result returned by the executor.

[0078] If the current SQL statement is executed successfully, the system will get the next valid SQL statement from the task queue or SQL statement set. This SQL statement can be the next operation related to the current statement, or another operation in the same task set.

[0079] The system repeats the execution steps according to the type of the next SQL statement and executes the next SQL statement through the corresponding executor.

[0080] In some implementations, the system may use a task queue to manage the sequential execution of SQL statements. Each time a SQL statement is successfully executed, the task queue loads the next SQL statement to the executor until the task queue is empty or the execution fails.

[0081] Example: In a storage task in the financial field, such as a day-end backup task, you may need to execute multiple storage-related SQL statements in sequence. The first step may be to create a temporary table structure, and the second step is to insert the transaction data of the day into the backup table. If the table structure is successfully created, the system will continue to insert data to ensure that the backup task proceeds smoothly. If the insert operation is successful, the system will continue to execute the cleanup task or archiving operation until all storage operations are completed.

[0082] By executing SQL statements one by one, the system can dynamically load and execute each valid SQL statement during the task execution process to ensure the smooth completion of the task. When the current statement is executed successfully, the system can seamlessly transition to the execution of the next statement to ensure the continuity of the task flow. At the same time, the processing of dependencies can ensure that the conditions that each SQL statement depends on are met, thereby improving the stability and reliability of task execution.

[0083] S60, if the execution of the valid SQL statement fails, the failure information is recorded, an exception log is generated, and the exception log is sent to the business management end;

[0084] In this embodiment, when a valid SQL statement encounters an error or fails during execution, the system needs to record the execution failure information of the SQL statement to ensure that the error information can be recorded in detail. The failure information usually includes the content of the SQL statement, the execution time, the reason for the failure, and the return error code or message of the database. The generated exception log will be stored in the log module of the system for subsequent error analysis and troubleshooting.

[0085] Once an exception log is generated, the system will send the log to the business management end or monitoring system responsible for task execution monitoring. By timely transmitting the exception log, business management personnel or system operation and maintenance personnel can quickly understand the problems in task execution and make corresponding processing decisions. This ensures that the problem can be located and solved in time to prevent the spread of errors.

[0086] When an SQL statement fails to execute, the system will capture the error information returned by the SQL executor. This information includes the executed SQL statement, the reason for the failure (such as syntax error, permission problem, data inconsistency, etc.), the error code returned by the database, and the detailed error message.

[0087] The system generates an exception log file or record based on the captured failure information. The log content usually includes detailed information such as the execution time of the SQL statement, the execution environment, the failure reason and the error code. The exception log is formatted and stored for subsequent analysis.

[0088] The system will send the generated exception logs to the business management end through the specified communication method (such as API, email or message queue). The transmission method can be customized according to business needs, such as transmitting logs to the log analysis system through RESTful API, or notifying business personnel by email.

[0089] Example: In the storage tasks in the financial field, the system may perform data archiving or backup operations regularly. When a storage SQL statement (such as a data insertion statement) fails to execute, the system will record the failed SQL content, execution time, failure reason, and error information returned by the database. For example, if data insertion fails due to insufficient database storage space, the system will capture this information and generate an exception log, and then send the log to the monitoring system of the business management end through the API to notify the operation and maintenance team to deal with the storage problem in a timely manner. This can avoid the risk of data loss or storage system interruption.

[0090] By capturing and recording the execution failure information of SQL statements, the system can provide detailed error logs, providing complete data support for subsequent problem troubleshooting. At the same time, sending abnormal logs to the business management end in a timely manner can shorten the time for problem discovery and processing, ensuring the stability of the system and the efficiency of task execution. This process reduces the risk of error propagation and improves the system's ability to cope with failures.

[0091] S70, when all valid SQL statements in the SQL statement set are executed successfully, the execution process of the database task is terminated;

[0092] In this embodiment, during the execution of the database task, the system executes the valid SQL statements in the SQL statement set one by one. If all valid SQL statements are executed successfully, the system needs to end the execution process of the entire task. This step is the final stage of task execution, indicating that all SQL statements have been successfully executed and the database task has been completed.

[0093] The task completion condition is based on the successful execution of all valid SQL statements in the task execution queue or SQL statement set. The execution result of each SQL statement must meet the "success" judgment criteria before the task can be marked as completed. If a SQL statement is not successfully executed, this step will not be entered, and the system will enter the exception handling process.

[0094] The system will execute SQL statements one by one and check the execution status of each statement after it is executed. If a SQL statement is executed successfully, the system will continue to execute the next statement until all statements are executed. When all SQL statements are marked as successful, the system ends the execution process of the task and marks the task as completed.

[0095] After all valid SQL statements are successfully executed, the system updates the status of the database task to "completed" or "successful". This flag is usually stored in the task scheduling module or log record for subsequent query and analysis.

[0096] After the task is executed, the system will release the resources related to the task (such as memory, connection, etc.) to ensure that the system continues to run efficiently.

[0097] After the task is completed, the system can generate summary information of the task execution results, including the success status of the task execution, execution time, SQL statements involved and their return results, etc. These results can be fed back to the task initiator or business management end.

[0098] Example: In the financial field, the system may periodically execute batch storage tasks (such as backing up historical data). In the storage task, the system executes storage-related SQL statements one by one, such as insert, update, or archive operations. When all storage SQL statements are successfully executed, the system marks the task as "completed" and ends the task execution process. This flag can be passed to the business management end through the log system to inform the task initiator that the backup task has been successfully completed and data security is guaranteed. The system then releases the database connection and resources related to the task to ensure efficient operation of the storage system.

[0099] Under the premise that all SQL statements are successfully executed, the system can successfully end the task execution process, avoiding incomplete or suspended tasks. By updating the task status to "completed", the system can provide a reliable basis for subsequent analysis and result feedback of the task, while improving the utilization of system resources and avoiding resource waste.

[0100] S80, generating a final execution result of the database task based on the execution result of each valid SQL statement.

[0101] In this embodiment, after executing all valid SQL statements, the system generates the final execution result of the entire database task based on the execution results of each SQL statement. The final result usually reflects the overall status of the task execution, including whether the task is successful, the SQL statements executed, the execution status of each SQL statement, and related outputs (such as query results, number of rows affected, etc.).

[0102] During the task execution process, the execution results of each SQL statement will be recorded and stored, and finally summarized into a task execution report. The execution results include not only the success or failure status of the SQL statement execution, but also the execution time and the specific information returned by the database (such as the query result set or data operation feedback). After the summary, the system can generate an overall report as the final result of the database task feedback to the user or management system.

[0103] During the task execution, the system will record the execution status of each SQL statement and its return information. For example, for query statements, the system will record the returned data set; for data change statements (such as INSERT, UPDATE, etc.), the system will record the number of rows affected.

[0104] After all SQL statements are executed, the system summarizes the execution results of each SQL statement to form a complete execution report. The report usually includes the task ID, the executed SQL statements, the execution results of each SQL statement (success or failure), the specific information returned, etc.

[0105] The system will feed back the summary of task execution results to the task initiator or business management end so that relevant personnel can understand the execution status of the task. Feedback can be delivered in a variety of ways, such as generating a report file, feeding back the execution status through an API, or storing it in the task log.

[0106] Example: In the storage tasks in the financial field, the system may regularly back up large amounts of historical transaction data or customer information. After the backup task is completed, the system generates a task execution report based on the execution results of each storage-related SQL statement. For example, the system records the number of rows affected by each insert statement and the returned data set of each query statement, and finally generates a summary report showing whether the backup task is successful, the accuracy of data storage, and the backup status of each data table. This result can be fed back to the business management system so that the operation and maintenance personnel can confirm the integrity and security of the data backup.

[0107] By recording and summarizing the execution results of each SQL statement in detail, the system can provide timely feedback on the execution status of the task, helping operation and maintenance personnel to quickly discover and solve possible problems, thereby enhancing the maintainability and transparency of the system.

[0108] The present invention relates to the fields of data processing technology and financial technology, and discloses a database task execution method, which receives an execution request of a database task, determines whether a corresponding SQL statement set has been defined for the task, extracts valid SQL statements, and calls an execution method to execute the task according to the statement type, and determines the execution result. If the execution is successful, the next SQL statement is executed; if the execution fails, the failure information is recorded and an exception log is generated and sent to the business management end. After all SQL statements are executed, the final execution result of the database task is generated. The present invention improves the execution efficiency of tasks and ensures the accuracy and efficiency of the task execution process by optimizing the execution management of SQL statements. Through the exception log recording and result feedback mechanism, the system's fault handling capability and operation and maintenance efficiency are enhanced, and the risk of system interruption caused by execution failure is reduced.

[0109] In one embodiment, the above S10 includes:

[0110] S101, receiving an execution request for a database task, wherein the execution request includes a task identifier, user credentials and a task type;

[0111] S102, performing identity authentication based on the user credentials to verify whether the user has the task authority to execute the request, and when the verification fails, recording failure information and terminating the task execution process;

[0112] S103, verifying the validity of the task identifier, if the task identifier is invalid, recording failure information and terminating the task execution process;

[0113] S104, verifying whether the task type belongs to a predefined valid type. If the task type is invalid, recording failure information and terminating the task execution process;

[0114] S105: When all verifications are passed, the execution request is added to the task execution queue.

[0115] In this embodiment, the system receives a database task execution request. The request contains key information, such as task identification, user credentials, and task type. This information is used to ensure that the system can correctly identify and process the request, and ensure the legitimacy and accuracy of the database task.

[0116] The system verifies the user's credentials to confirm whether the user who initiated the request has the corresponding permissions to perform the task. Credential verification is to prevent unauthorized users from initiating sensitive or high-privilege database operations and ensure the security of task execution.

[0117] The task ID is used to uniquely identify each database task. The system verifies the validity of the task ID to ensure that the task is real and legal. If the task ID is invalid or does not exist, the system will refuse to execute the task.

[0118] The task type is used to define the specific operation type requested (for example, query task, insert task, or delete task). The system needs to verify whether the task type belongs to the predefined legal task type. By verifying the task type, the system can determine whether it can process the task of this type.

[0119] The system receives task requests sent externally through API, message queue or other communication methods, parses the request, and extracts task identifier, user credentials and task type information.

[0120] The system checks the legitimacy of the user's credentials by querying the user authentication service or database to ensure that the user who initiated the task has sufficient permissions. Authentication technologies such as OAuth 2.0 or JWT are usually used to confirm the validity of the credentials.

[0121] The system checks whether the task ID is valid or registered by querying the task scheduling system or database. If the task ID does not exist or is illegal, the system will generate a failure message and terminate the task execution.

[0122] By matching the task type with the predefined task type table, the system can ensure that the task type complies with the business logic. If the task type is invalid, the system will generate an error log and terminate the task execution.

[0123] When all verifications (user credentials, task ID, task type) are passed, the system adds the request to the task execution queue. The task queue is used to manage all pending tasks and execute them in order of priority or submission.

[0124] In this embodiment, by gradually filtering invalid or illegal task requests, the system can improve the efficiency of task management and the stability of execution, while reducing the risk of illegal or erroneous tasks on database operations.

[0125] In one embodiment, the above S20 includes:

[0126] S201, extracting the task identifier of the database task from the execution request;

[0127] S202, according to the task identifier, querying the SQL statement set definition information related to the task identifier from the configuration processing module;

[0128] S203, if the SQL statement set definition information corresponding to the task identifier is found, confirming that the corresponding SQL statement set has been defined for the database task;

[0129] S204: If the SQL statement set definition information corresponding to the task identifier is not found, an error message is returned and the execution process of the database task is terminated.

[0130] In this embodiment, the system first extracts the task identifier of the database task from the received execution request. The task identifier is used to uniquely identify each database task and help the system identify whether the task has a predefined corresponding SQL statement set.

[0131] The system uses the task ID to query the configuration processing module to find the SQL statement set definition information associated with the task ID. The configuration processing module is where all task configurations and SQL statement sets are stored, and is used to manage the execution logic of the task.

[0132] If the SQL statement set definition information corresponding to the task ID is found, the system confirms that the task has a SQL statement set defined for it. This means that the task can continue to be executed and subsequent operations can use predefined SQL statements.

[0133] If the system fails to find the SQL statement set definition information corresponding to the task ID, it returns an error message and terminates the task execution. This is to avoid the system trying to execute undefined tasks and prevent invalid operations.

[0134] The execution request received by the system contains a task identifier, which is usually a unique string or ID. The system extracts the identifier from the request data structure, usually through JSON parsing, database query or HTTP request parameter parsing.

[0135] After the task identifier is extracted, the system uses the identifier as a keyword to query the task configuration table or configuration file in the configuration processing module to find the SQL statement set definition information related to the identifier.

[0136] If a SQL statement set definition matching the task identifier is found in the configuration processing module, the system extracts the definition information for subsequent SQL execution.

[0137] If the definition information corresponding to the task identifier is not found, the system immediately terminates the task execution, generates an error message and returns the error result to the task initiator.

[0138] In this embodiment, by querying the configuration processing module, the system can timely discover and process undefined tasks, prevent unexpected situations from occurring during task execution, and ensure the stability and reliability of task execution.

[0139] In one embodiment, the above S30 includes:

[0140] S301, determining effective standards for identifying effective SQL statements according to syntax standards, logic requirements, and user authority requirements;

[0141] S302, traversing the SQL statement set, and filtering out valid SQL statements according to the validity criteria;

[0142] S303: Add the valid SQL statement to the task execution queue.

[0143] In this embodiment, the system screens SQL statements according to specific standards to ensure that the extracted SQL statements can be executed correctly. Effective standards usually include syntax standards, logic requirements, and user permission requirements. Syntax standards ensure that each SQL statement complies with SQL syntax specifications, logic requirements ensure that SQL statements can correctly handle business requirements, and user permission requirements ensure that the user who initiated the task has the right to execute the corresponding SQL operation.

[0144] The system will traverse the entire SQL statement set and check each SQL statement one by one to see if it meets the aforementioned validity criteria. Only SQL statements that meet the criteria will be marked as valid SQL statements for subsequent execution.

[0145] After filtering out valid SQL statements, the system adds them to the task execution queue to ensure that they are executed in order. The task execution queue is used to manage the scheduling and execution of SQL statements to ensure that each SQL statement is processed in the predetermined execution order.

[0146] The system first checks the syntax of each SQL statement for correctness, usually using a SQL parser or the database's built-in functionality to detect syntax errors. Only statements that conform to the SQL syntax are marked as valid.

[0147] Logical requirements may include business rule checks, such as whether the SQL statement complies with the database structure or business process logic. The system will verify logical issues such as whether the table name and field name in the SQL statement exist and whether the data type matches.

[0148] The system verifies user permissions to ensure that the user has the right to execute relevant SQL statements, such as whether the user has read and write permissions, whether the user has DDL permissions (permission to create or modify database objects), etc.

[0149] The system goes through the SQL statement set one by one, checking whether each SQL statement meets the above criteria. Only SQL statements that meet all the criteria will be marked as valid and added to the execution queue.

[0150] The filtered valid SQL statements will be added to the task execution queue. The task execution queue manages the execution of SQL statements according to the priority or submission order of the tasks. The execution queue can use the first-in-first-out (FIFO) method, or you can customize the execution order according to business needs.

[0151] This embodiment strictly screens SQL statements to ensure that the system only executes SQL statements that meet syntax, logic and permission requirements, avoiding task failures caused by syntax errors or insufficient permissions. By adding valid SQL statements to the task execution queue, the system can efficiently execute these tasks in a reasonable order and priority, improving the system's task execution efficiency and security.

[0152] In one embodiment, the above S40 includes:

[0153] S401, identifying the type of a valid SQL statement, where the type of a valid SQL statement includes a query statement, an insert statement, an update statement, a delete statement, or a DDL statement;

[0154] S402, for a query statement, calling a query executor; for an insert statement, an update statement or a delete statement, calling a write operation executor; for a DDL statement, calling a DDL statement executor;

[0155] S403, capturing the execution result of the SQL statement, wherein the execution result includes a query result, a row impact count, or an object operation result;

[0156] S404, judging whether the SQL statement is executed successfully according to the query result, row impact count or object operation result;

[0157] S405, recording the execution status and execution result, wherein the execution status includes a success status or a failure status.

[0158] In this embodiment, before executing a task, the system first needs to identify the type of each SQL statement. The types of SQL statements include query statements (such as SELECT), insert statements (such as INSERT), update statements (such as UPDATE), delete statements (such as DELETE), and DDL statements (such as CREATE TABLE, ALTERTABLE, etc.). Identifying the type of SQL statement is the basis for subsequent selection of an executor to ensure that the SQL statement can be processed by the correct executor.

[0159] The query executor is used to process query statements, such as SELECT. The executor reads data from the database and returns the query results.

[0160] The write operation executor processes write operations such as data insertion, update, and deletion (such as INSERT, UPDATE, and DELETE). This executor is used to modify data in the database. The execution result usually includes the number of rows affected.

[0161] The DDL executor processes data definition language (DDL) statements, such as CREATE, ALTER, etc., and is responsible for modifying or creating the database table structure.

[0162] After executing SQL statements, the system needs to capture and record the execution results. For query statements, the result is usually a data set; for insert, update, and delete operations, the result is the number of rows affected; for DDL statements, the result is the return information of the object operation (such as confirmation information of successful table creation).

[0163] The system determines whether the SQL statement is executed successfully based on the captured execution results. Query statements are usually judged based on whether the data set is empty; write operations are judged based on the number of rows affected (if the number of rows is greater than 0, it means success); DDL statements confirm whether the execution is successful based on the object operation results.

[0164] Regardless of whether the SQL statement is executed successfully or not, the system will record the execution status and results. The status is divided into success or failure, and the relevant execution results will be recorded for subsequent analysis and processing.

[0165] After the system recognizes the query statement, it calls the query executor, sends the query request to the database, and returns the result set.

[0166] For data modification operations, the system calls the write operation executor, executes the statement and returns the number of rows affected.

[0167] After the system recognizes the DDL statement, it calls the DDL executor to modify the database structure. The execution result is usually status information on whether the operation is successful or not.

[0168] After executing SQL statements, the system will capture and analyze the information returned by the database. For query statements, the system obtains the result set; for write operations, the system records the number of rows affected; for DDL statements, the system obtains operation feedback (such as whether the table was successfully created).

[0169] For query operations, the system determines whether the execution is successful based on whether the data is returned successfully. If the data set is not empty, it is considered successful; if it is a write operation, the system determines whether the execution is successful based on the number of rows affected. DDL operations are judged successful based on the confirmation information returned.

[0170] The system records the execution status (success or failure) and the corresponding execution results in the log or execution report to ensure that the task execution process is well documented.

[0171] By accurately identifying the SQL statement type and calling the corresponding executor, the system can ensure that the SQL statement is correctly executed and quickly determine whether the operation is successful based on the execution result. By recording the execution status and results, the system can provide a complete execution log, which is convenient for subsequent problem troubleshooting and performance optimization, and improves the transparency and reliability of task execution.

[0172] In one embodiment, the above S50 includes:

[0173] S501, after executing the current valid SQL statement, check whether the execution status of the current valid SQL statement is marked as a success status;

[0174] S502, when it is detected that the current valid SQL statement is executed successfully, determining whether there is an unexecuted valid SQL statement in the SQL statement set;

[0175] S503, if there is an unexecuted valid SQL statement, determine and obtain the next valid SQL statement of the current valid SQL statement according to the dependency relationship between the SQL statements;

[0176] S504, calling the corresponding execution method to execute the next valid SQL statement.

[0177] In this embodiment, after executing each SQL statement, the system needs to check whether the execution status of the statement is marked as successful. Only after the SQL statement is successfully executed will the system continue to process the next SQL statement. The mark of the success status is usually based on the execution result of the SQL statement, such as successful query return data, successful insertion or update modification of data, successful DDL operation change of database structure, etc.

[0178] After the current SQL statement is successfully executed, the system needs to determine whether there are any unexecuted valid SQL statements in the SQL statement set. This judgment is crucial because if all SQL statements have been executed, the system should terminate the task execution; otherwise, it should continue to execute the next valid SQL statement.

[0179] If the system detects that there are still valid SQL statements that have not been executed, the system determines the next SQL statement based on the dependencies between SQL statements or the predefined execution order. There may be dependencies between SQL statements, for example, an insert operation may depend on the success of a table creation operation, and a query may depend on the result of data insertion.

[0180] After the system determines the next valid SQL statement, it calls the corresponding execution method to execute the SQL statement. This process is the same as the SQL statement execution mechanism mentioned above. The system will select the appropriate executor according to the type of statement, execute the statement and continue to cycle this process until all SQL statements are executed.

[0181] After each SQL statement is executed, the system will generate an execution status mark (success or failure). By analyzing the execution results (such as query results, number of affected rows, DDL operation return status, etc.), the system determines whether the SQL statement is successfully executed. If it is marked as successful, the system proceeds to the next step of judgment; if it is marked as failed, the system enters the exception handling process.

[0182] After the current SQL statement is successfully executed, the system will check whether there are any valid SQL statements that have not been executed in the SQL statement set. This judgment is usually completed by querying the execution records in the task execution queue or task management module.

[0183] After determining that there are unexecuted SQL statements, the system will determine the next SQL statement based on the execution order or the dependency between SQL statements. The dependency between statements may be explicit (such as table structure dependency, data dependency) or implicit (the order of business logic).

[0184] Once the next SQL statement is determined, the system will call the appropriate SQL executor to execute this SQL statement. This step is consistent with the above SQL statement execution process. The system will call the query executor, write operation executor or DDL executor according to the statement type.

[0185] Through the above steps, this embodiment can ensure that the database task can be executed continuously, and the SQL statements are executed one by one according to the predetermined order or dependency relationship, thereby improving the automation level of task execution. At the same time, the system can dynamically adjust the execution process by checking the execution status, and promptly handle or roll back when an error occurs, thereby ensuring the reliability and stability of the task.

[0186] In one embodiment, the above S60 includes:

[0187] S601, after executing the current valid SQL statement, check whether the execution status of the current valid SQL statement is marked as a failure status;

[0188] S602, when it is detected that the execution of the current valid SQL statement fails, triggering a transaction rollback operation of the database to undo all changes to the database made by the executed SQL statements;

[0189] S603, recording the rollback operation information including the failure reason, specific rollback steps and affected data into the exception log;

[0190] S604, when the transaction rollback operation is completed, terminating the execution process of the database task;

[0191] S605: Send the exception log and information on whether the rollback is successful to the business management end.

[0192] In this embodiment, after executing the SQL statement, the system needs to check whether its execution status is marked as failed. If the SQL statement fails to execute, the system must handle the error and prevent the error from affecting other operations. The check of the failure status is usually based on the return result of the database, such as the SQL error code, the execution feedback of the database, etc.

[0193] When an SQL statement execution failure is detected, the system triggers a transaction rollback operation on the database. Transaction rollback is to ensure that all changes made during the execution process are undone to prevent data inconsistency or partial data processing errors. The rollback operation undoes the changes made by all successfully executed SQL statements under the task to ensure that the database is restored to the state before the task was executed.

[0194] The system will record detailed information including the cause of the failure, the specific steps of the rollback, and the affected data, and save this information to the exception log. This is to ensure that fault tracing and problem troubleshooting can be carried out. The log of the rollback operation will describe the execution process and results of the transaction rollback in detail.

[0195] After the transaction is rolled back, the system terminates the execution of the current task to avoid further SQL operations. The termination of the task is intended to ensure that the failed task does not affect other unexecuted SQL statements and to prevent the continued propagation of errors.

[0196] The exception log generated by the system will be sent to the business management end to notify the system administrator or business-related personnel. The exception log will not only include the cause of the failure, but also include information on whether the transaction rollback is successful, so that relevant personnel can respond in time.

[0197] After executing each SQL statement, the system will check the execution result returned by the database. If an execution failure is detected (such as SQL error code, syntax error, or data inconsistency), the system will mark the SQL statement as "failed".

[0198] When SQL execution fails, the system will initiate a transaction rollback operation to cancel all successfully executed SQL statements under the task. The rollback operation is handled by the database transaction management module to ensure that any previous operations will not cause persistent changes to the database.

[0199] The system will record the operations involved in the rollback process in detail, including the rolled back SQL statements, the data involved, the rollback time, etc., to ensure that this information can be presented in the log.

[0200] The system generates an exception log, which includes the failure information of the SQL statement, the steps of rollback, and the data affected during the rollback process. The log records are usually formatted and saved to facilitate subsequent debugging and troubleshooting.

[0201] The system sends exception logs to the business management end through API, email or message queue to ensure that the relevant person in charge can view and handle the exceptions in a timely manner.

[0202] In this embodiment, by automatically detecting the failure status of SQL statements and initiating transaction rollback, the system can ensure the integrity and consistency of the database and prevent error propagation. Recording detailed rollback operation logs and failure information helps to quickly locate problems and perform troubleshooting. In addition, sending exception logs to the business management end ensures that relevant personnel can understand the execution status of tasks in a timely manner, thereby shortening the problem handling time.

[0203] In one embodiment, a database task execution device is provided, and the database task execution device corresponds one-to-one to the database task execution method in the above embodiment. Figure 3 , Figure 3 This is a functional module diagram of a preferred embodiment of the database task execution device of the present invention. Task receiving module 10, configuration processing module 20, SQL screening module 30, SQL execution module 40, task scheduling module 50, exception handling module 60, execution completion module 70 and result generation and reporting module 80. The functional modules are described in detail as follows:

[0204] The task receiving module 10 is used to receive a request for executing a database task;

[0205] The configuration processing module 20 is used to determine whether the configuration processing module has defined a corresponding SQL statement set for the database task;

[0206] The SQL screening module 30 is used to extract valid SQL statements from the SQL statement set if a corresponding SQL statement set has been defined;

[0207] The SQL execution module 40 is used to call a corresponding execution method according to the type of the valid SQL statement, execute the valid SQL statement, and determine whether the valid SQL statement is executed successfully;

[0208] The task scheduling module 50 is used to continue executing the next valid SQL statement if the valid SQL statement is executed successfully;

[0209] The exception handling module 60 is used to record the failure information, generate an exception log, and send the exception log to the business management terminal if the execution of the valid SQL statement fails;

[0210] An execution completion module 70, used to end the execution process of the database task when all valid SQL statements in the SQL statement set are successfully executed;

[0211] The result generation and reporting module 80 is used to generate the final execution result of the database task based on the execution result of each valid SQL statement.

[0212] In one embodiment, the task receiving module 10 is specifically used for:

[0213] Receive a database task execution request, the execution request including a task identifier, user credentials and task type;

[0214] Perform identity authentication based on the user credentials to verify whether the user has the task authority to execute the request, and when the verification fails, record the failure information and terminate the task execution process;

[0215] Verify the validity of the task identifier; if the task identifier is invalid, record the failure information and terminate the task execution process;

[0216] Verify whether the task type belongs to a predefined valid type. If the task type is invalid, record the failure information and terminate the task execution process;

[0217] When all verifications are passed, the execution request is added to the task execution queue.

[0218] In one embodiment, the processing module 20 is configured to:

[0219] Extracting a task identifier of the database task from the execution request;

[0220] According to the task identifier, querying the SQL statement set definition information related to the task identifier from the configuration processing module;

[0221] If the SQL statement set definition information corresponding to the task identifier is found, it is confirmed that the corresponding SQL statement set has been defined for the database task;

[0222] If the SQL statement set definition information corresponding to the task identifier is not found, an error message is returned and the execution process of the database task is terminated.

[0223] In one embodiment, the SQL screening module 30 is specifically used to:

[0224] Determine effective criteria for identifying valid SQL statements based on syntax standards, logic requirements, and user authority requirements;

[0225] Traversing the SQL statement set, and filtering out valid SQL statements according to the validity criteria;

[0226] The valid SQL statement is added to the task execution queue.

[0227] In one embodiment, the SQL execution module 40 is specifically used to:

[0228] Identify the type of a valid SQL statement, where the type of the valid SQL statement includes a query statement, an insert statement, an update statement, a delete statement, or a DDL statement;

[0229] For query statements, the query executor is called; for insert statements, update statements, or delete statements, the write operation executor is called; for DDL statements, the DDL statement executor is called;

[0230] Capturing the execution results of SQL statements, the execution results including query results, row impact counts or object operation results;

[0231] Determine whether the SQL statement is executed successfully based on the query results, row impact counts, or object operation results;

[0232] The execution status and execution result are recorded, wherein the execution status includes a success status or a failure status.

[0233] In one embodiment, the task scheduling module 50 is specifically used to:

[0234] After executing the current valid SQL statement, check whether the execution status of the current valid SQL statement is marked as a success status;

[0235] When it is detected that the current valid SQL statement is executed successfully, determining whether there is an unexecuted valid SQL statement in the SQL statement set;

[0236] If there is an unexecuted valid SQL statement, determine and obtain the next valid SQL statement of the current valid SQL statement based on the dependency relationship between the SQL statements;

[0237] Call the corresponding execution method to execute the next valid SQL statement.

[0238] In one embodiment, the exception handling module 60 is specifically configured to:

[0239] After executing the current valid SQL statement, check whether the execution status of the current valid SQL statement is marked as a failed state;

[0240] When the execution failure of the current valid SQL statement is detected, the transaction rollback operation of the database is triggered to undo the changes made to the database by all executed SQL statements;

[0241] Record the rollback operation information, including the failure reason, specific rollback steps, and affected data, in the exception log;

[0242] When the transaction rollback operation is completed, the execution process of the database task is terminated;

[0243] The exception log and information on whether the rollback is successful are sent to the business management end.

[0244] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Figure 4As shown. The computer device includes a processor, a memory, a network interface and a database connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile and / or volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external user terminal through a network connection. When the computer program is executed by the processor, it realizes the functions or steps of a database task execution method server side.

[0245] In one embodiment, a computer device is provided. The computer device may be a user terminal, and its internal structure diagram may be as follows: Figure 5 As shown. The computer device includes a processor, a memory, a network interface, a display screen and an input device connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external server through a network connection. When the computer program is executed by the processor, it realizes the functions or steps on the user side of a database task execution method

[0246] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the following steps when executing the computer program:

[0247] Receive execution request of database task;

[0248] Determine whether the configuration processing module has defined a corresponding SQL statement set for the database task;

[0249] If a corresponding SQL statement set has been defined, extracting a valid SQL statement from the SQL statement set;

[0250] According to the type of the valid SQL statement, calling a corresponding execution method, executing the valid SQL statement, and determining whether the valid SQL statement is executed successfully;

[0251] If the valid SQL statement is executed successfully, continue to execute the next valid SQL statement;

[0252] If the valid SQL statement fails to execute, the failure information is recorded, an exception log is generated, and the exception log is sent to the business management end;

[0253] When all valid SQL statements in the SQL statement set are executed successfully, the execution process of the database task is terminated;

[0254] Based on the execution result of each valid SQL statement, a final execution result of the database task is generated.

[0255] In one embodiment, a computer readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the following steps are implemented:

[0256] Receive execution request of database task;

[0257] Determine whether the configuration processing module has defined a corresponding SQL statement set for the database task;

[0258] If a corresponding SQL statement set has been defined, extracting a valid SQL statement from the SQL statement set;

[0259] According to the type of the valid SQL statement, calling a corresponding execution method, executing the valid SQL statement, and determining whether the valid SQL statement is executed successfully;

[0260] If the valid SQL statement is executed successfully, continue to execute the next valid SQL statement;

[0261] If the valid SQL statement fails to execute, the failure information is recorded, an exception log is generated, and the exception log is sent to the business management end;

[0262] When all valid SQL statements in the SQL statement set are executed successfully, the execution process of the database task is terminated;

[0263] Based on the execution result of each valid SQL statement, a final execution result of the database task is generated.

[0264] It should be noted that the above functions or steps that can be implemented by the computer-readable storage medium or computer device can refer to the relevant descriptions on the server side and the user side in the aforementioned method embodiment. To avoid repetition, they will not be described one by one here.

[0265] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0266] Those skilled in the art can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0267] It should be noted that if software tools or components other than those of the Company appear in the embodiments of the present application, they are only used for illustration and do not represent actual use. The above-described embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit them; although the present invention has been described in detail with reference to the above-mentioned embodiments, a person of ordinary skill in the art should understand that the technical solutions described in the above-mentioned embodiments can still be modified, or some of the technical features thereof can be replaced by equivalents; and 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 invention, and should all be included in the protection scope of the present invention.

Claims

1. A database task execution method, characterized in that: The following steps are involved: Receive execution request of database task; Determine whether the configuration processing module has defined a corresponding SQL statement set for the database task; If a corresponding SQL statement set has been defined, extracting a valid SQL statement from the SQL statement set; According to the type of the valid SQL statement, calling a corresponding execution method, executing the valid SQL statement, and determining whether the valid SQL statement is executed successfully; If the valid SQL statement is executed successfully, continue to execute the next valid SQL statement; If the valid SQL statement fails to execute, the failure information is recorded, an exception log is generated, and the exception log is sent to the business management end; When all valid SQL statements in the SQL statement set are executed successfully, the execution process of the database task is terminated; Based on the execution result of each valid SQL statement, a final execution result of the database task is generated.

2. The database task execution method according to claim 1, characterized in that: Receive execution requests for database tasks, including: Receive a database task execution request, the execution request including a task identifier, user credentials and task type; Perform identity authentication based on the user credentials to verify whether the user has the task authority to execute the request, and when the verification fails, record the failure information and terminate the task execution process; Verify the validity of the task identifier; if the task identifier is invalid, record the failure information and terminate the task execution process; Verify whether the task type belongs to a predefined valid type. If the task type is invalid, record the failure information and terminate the task execution process; When all verifications are passed, the execution request is added to the task execution queue.

3. The database task execution method according to claim 1, characterized in that: Determining whether the configuration processing module has defined a corresponding SQL statement set for the database task includes: Extracting a task identifier of the database task from the execution request; According to the task identifier, querying the SQL statement set definition information related to the task identifier from the configuration processing module; If the SQL statement set definition information corresponding to the task identifier is found, it is confirmed that the corresponding SQL statement set has been defined for the database task; If the SQL statement set definition information corresponding to the task identifier is not found, an error message is returned and the execution process of the database task is terminated.

4. The database task execution method according to claim 1, characterized in that: If a corresponding SQL statement set has been defined, extracting a valid SQL statement from the SQL statement set includes: Determine effective criteria for identifying valid SQL statements based on syntax standards, logic requirements, and user authority requirements; Traversing the SQL statement set, and filtering out valid SQL statements according to the validity criteria; The valid SQL statement is added to the task execution queue.

5. The database task execution method as claimed in claim 1, characterized in that: According to the type of the valid SQL statement, calling a corresponding execution method to execute the valid SQL statement, and judging whether the valid SQL statement is executed successfully, includes: Identify the type of a valid SQL statement, where the type of the valid SQL statement includes a query statement, an insert statement, an update statement, a delete statement, or a DDL statement; For query statements, the query executor is called; for insert statements, update statements, or delete statements, the write operation executor is called; for DDL statements, the DDL statement executor is called; Capturing the execution results of SQL statements, the execution results including query results, row impact counts or object operation results; Determine whether the SQL statement is executed successfully based on the query results, row impact counts, or object operation results; The execution status and execution result are recorded, wherein the execution status includes a success status or a failure status.

6. The database task execution method according to claim 1, characterized in that: If the valid SQL statement is executed successfully, continue to execute the next valid SQL statement, including: After executing the current valid SQL statement, check whether the execution status of the current valid SQL statement is marked as a success status; When it is detected that the current valid SQL statement is executed successfully, determining whether there is an unexecuted valid SQL statement in the SQL statement set; If there is an unexecuted valid SQL statement, determine and obtain the next valid SQL statement of the current valid SQL statement based on the dependency relationship between the SQL statements; Call the corresponding execution method to execute the next valid SQL statement.

7. The database task execution method according to claim 1, characterized in that: If the valid SQL statement fails to execute, the failure information is recorded, an exception log is generated, and the exception log is sent to the business management end, including: After executing the current valid SQL statement, check whether the execution status of the current valid SQL statement is marked as a failure state; When the execution failure of the current valid SQL statement is detected, the transaction rollback operation of the database is triggered to undo the changes made to the database by all executed SQL statements; Record the rollback operation information, including the failure reason, specific rollback steps, and affected data, in the exception log; When the transaction rollback operation is completed, the execution process of the database task is terminated; The exception log and information on whether the rollback is successful are sent to the business management end.

8. A database task execution device, characterized in that: The database task execution device comprises: A task receiving module, used to receive execution requests of database tasks; The configuration processing module is used to determine whether the configuration processing module has defined a corresponding SQL statement set for the database task; An SQL screening module, for extracting valid SQL statements from a corresponding SQL statement set if the corresponding SQL statement set has been defined; An SQL execution module, used to call a corresponding execution method according to the type of the valid SQL statement, execute the valid SQL statement, and determine whether the valid SQL statement is executed successfully; A task scheduling module, used for continuing to execute the next valid SQL statement if the valid SQL statement is executed successfully; An exception handling module is used to record failure information, generate an exception log, and send the exception log to the business management end if the execution of the valid SQL statement fails; An execution completion module, used to end the execution process of the database task when all valid SQL statements in the SQL statement set are executed successfully; The result generation and reporting module is used to generate the final execution result of the database task based on the execution result of each valid SQL statement.

9. A computer device, characterized in that: The computer device includes a memory, a processor, and a database task execution program stored in the memory and executable on the processor. When the database task execution program is executed by the processor, the steps of the database task execution method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium, characterized in that: The storage medium stores a database task execution program, which, when executed by a processor, implements the steps of the database task execution method according to any one of claims 1 to 7.

Images