Database exception monitoring processing method and device and medium

Through real -time monitoring of the operating status of the database, identifying the deadlock and rolling operations, the deadlock and abnormal problems in the database are solved, and the stability and performance of the database are improved.

CN119356985AActive Publication Date: 2025-01-24SHANDONG INSPUR AIGOU CLOUD CHAIN INFORMATION TECH CO LTD
View PDF 4 Cites 0 Cited by

Patent Information

Application Number
CN202411511692.6
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-10-28
Publication Date
2025-01-24
Estimated Expiration
2044-10-28

AI Technical Summary

Technical Problem

Common deadlocks and exception problems in databases can affect database performance and may lead to data loss or system crashes, and existing technologies are difficult to effectively monitor and deal with these problems.

Method used

By monitoring the operating status of the database in real time, conducting abnormal analysis, identifying dead lock events, and rolling operations of participating transactions, updating transaction attributes to ensure system stability.

Benefits of technology

Real -time monitoring and processing of database abnormal events are realized, the performance bottleneck and stability problems caused by dead locks are avoided, and the high availability and performance of the database is ensured.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119356985A_ABST
    Figure CN119356985A_ABST
Patent Text Reader

Abstract

The invention discloses a database exception monitoring processing method and device and a medium, and the method comprises the steps: monitoring and obtaining a running state of a database in real time, and determining an exception event existing in the database; based on the abnormal event, a transaction waiting graph of the database is analyzed through a deadlock detection algorithm, and a deadlock event is recognized; aiming at the deadlock event, determining a plurality of participating transactions corresponding to the deadlock event, and selecting at least part of transactions in the participating transactions as specified transactions based on transaction attributes corresponding to the participating transactions; carrying out rollback operation on the specified transaction, and carrying out transaction attribute updating on the specified transaction after the rollback operation is executed; and on the basis of the rollback operation, continuing to execute the specified transaction after the transaction attribute is updated. And unified management is performed on the database through the monitoring server, and the load condition of each node in the database cluster is monitored. And according to a monitoring result, data distribution and a query routing strategy are dynamically adjusted, load balance of each node is ensured, single-point overload is avoided, and the overall performance of the system is improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the field of computers, and in particular to a method, device and medium for monitoring and processing database anomalies. Background Art

[0002] With the rapid development of the Internet, more and more enterprises have emerged or expanded their business scale. In this process, along with the rapid growth of data volume, the Internet environment is complex and the security issues that continue to emerge are becoming increasingly prominent. Enterprises have begun to pay more attention to the network security used by enterprises.

[0003] In database management systems, deadlocks and exceptions are common performance bottlenecks and stability issues. Deadlocks usually occur when two or more transactions are waiting for resources held by each other and cannot continue to execute, while exceptions may be caused by a variety of reasons, such as data errors, insufficient resources, program logic errors, etc. These problems not only affect the performance of the database, but may also cause data loss or system crashes. Summary of the invention

[0004] In order to solve the above problems, the present application proposes a database abnormality monitoring and processing method, including: Real-time monitoring to obtain the operating status of the database, and performing abnormal analysis based on the operating status to determine abnormal events existing in the database; Based on the abnormal event, analyzing the transaction wait graph of the database by a deadlock detection algorithm to identify the deadlock event; For the deadlock event, determine a plurality of participating transactions corresponding to the deadlock event, and select at least some of the participating transactions as designated transactions based on transaction attributes corresponding to the participating transactions; Performing a rollback operation on the designated transaction, and updating the transaction attributes of the designated transaction after the rollback operation is performed; Based on the rollback operation, the specified transaction is continued to be executed after the transaction attributes are updated.

[0005] In one example, performing an abnormality analysis based on the running state to determine abnormal events existing in the database specifically includes: Determine the operation log and performance status included in the operation status; Based on the operation log, an analysis is performed through an analysis engine and / or log analysis rules to determine whether there are abnormal events in the database; wherein the log analysis rules include query timeout, data inconsistency, and error code; Based on the performance status, analyzing by performance analysis rules to determine whether there are abnormal events in the database; wherein the performance analysis rules include resource usage and resource exhaustion; If there is an abnormal event, the alarm mechanism will be triggered and the exception handling process will begin.

[0006] In one example, analyzing the transaction wait graph of the database by a deadlock detection algorithm to identify a deadlock event specifically includes: A transaction waiting graph of a database is defined; wherein the transaction waiting graph includes nodes and edges, the nodes represent transactions, and the edges represent waiting relationships between transactions; Traverse all active transactions and build a transaction waiting graph; Determine the transaction included in the abnormal event, and determine whether the included transaction is in a loop in the transaction waiting graph; If so, the ring is regarded as a deadlock event, and all transactions participating in the ring are regarded as participating transactions in the deadlock event.

[0007] In one example, the method further includes: Determining that a duration during which no included transaction is detected in the ring through the abnormal event has exceeded a first preset duration; Retrieving the transaction waiting graph by a priority search algorithm to determine whether there is a loop; If so, the loop is regarded as a deadlock event, and all transactions participating in the loop are regarded as participating transactions in the deadlock event.

[0008] In one example, based on the transaction attributes corresponding to the participating transactions, selecting at least some of the participating transactions as designated transactions specifically includes: Determine the transaction attributes corresponding to the participating transaction, wherein the transaction attributes include: priority and execution time; For each participating transaction, confirm whether the participating transaction exists in the abnormal event; If it exists, the participating transaction is taken as the first designated transaction; For each remaining participating transaction, determining whether the execution time of the participating transaction exceeds a second preset time length; If not, the participating transaction is regarded as the second designated transaction; For each remaining participating transaction, determining whether the priority of the participating transaction is higher than the preset priority; If not, the participating transaction will be regarded as the third designated transaction.

[0009] In one example, updating the transaction attribute of a specified transaction after the rollback operation is performed specifically includes: For the first designated transaction, update its transaction attribute and add a designated identifier; For the third designated transaction, the priority thereof is updated to increase the priority of the third designated transaction; The method further comprises: For a new deadlock event, if it is determined that there is a participating transaction with a specified identifier added, the participating transaction is rolled back to the initial node, the process processing of the participating transaction is suspended, and an abnormal alarm is issued.

[0010] In one example, the method further includes: When selecting a designated transaction through participating transactions, the selection of designated transactions is stopped in the order of the first designated transaction, the second designated transaction, and the third designated transaction, whenever the number of selected designated transactions reaches a preset number.

[0011] In one example, the method further includes: Obtaining a detection frequency of deadlock events detected by a priority search algorithm within a recent third preset time period; wherein the third preset time period is higher than the first preset time period; Based on the detection frequency, the first preset duration is adjusted.

[0012] On the other hand, the present application also proposes a database abnormality monitoring and processing device, including: at least one processor; and, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the database exception monitoring and processing method described in any of the above examples.

[0013] On the other hand, the present application also proposes a non-volatile computer storage medium storing computer executable instructions, wherein the computer executable instructions are configured as: a database abnormality monitoring and processing method as described in any of the above examples.

[0014] The database abnormality monitoring and processing method proposed in this application can bring the following beneficial effects: The database is managed uniformly through the monitoring server, and the load of each node in the database cluster is monitored, including key indicators such as CPU usage, memory usage, disk I / O speed, etc. According to the monitoring results, the data distribution and query routing strategies are dynamically adjusted to ensure load balancing of each node, avoid single point overload, and improve the overall performance of the system.

[0015] Scan the database for anomalies in real time. If a deadlock or other abnormal situation occurs, automatically select the sacrificial transaction (for example, based on transaction priority, execution time, etc.) and roll it back to resolve the deadlock.

[0016] Propose optimization plans for SQL statements that are too long and time-consuming in the database, and automatically propose improvement plans (creating indexes, etc.) based on the frequency of SQL usage. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings: Figure 1 This is a flowchart of a method for monitoring and processing database anomalies in an embodiment of the present application; Figure 2 This is a schematic diagram of a database abnormality monitoring and processing system in an embodiment of the present application; Figure 3 It is a schematic diagram of a database abnormality monitoring and processing device in an embodiment of the present application. DETAILED DESCRIPTION

[0018] In order to make the purpose, technical solution and advantages of the present application clearer, the technical solution of the present application will be clearly and completely described below in combination with the specific embodiments of the present application and the corresponding drawings. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present application.

[0019] The technical solutions provided by various embodiments of the present application are described in detail below in conjunction with the accompanying drawings.

[0020] like Figure 1 As shown, the embodiment of the present application provides a database abnormality monitoring and processing method, including: S101: Real-time monitoring is performed to obtain the operation status of a database, and an abnormality analysis is performed based on the operation status to determine abnormal events existing in the database.

[0021] You can use the database's built-in monitoring tools (for example, PostgreSQL and MySQL data blocks have some built-in internal monitoring tools) and third-party monitoring tools to monitor the database's operating status.

[0022] When using monitoring tools, you can query the operating status of the database through log analysis, transaction auditing, performance analysis, etc. The operating status includes but is not limited to the performance status, transaction status, and operating logs of the database.

[0023] Specifically, when determining whether there is an abnormal event, an analysis is performed based on the operation log through an analysis engine and / or log analysis rules to determine whether there is an abnormal event in the database.

[0024] The analysis engine can be implemented through corresponding monitoring tools and analysis tools, or through a machine learning framework. Log analysis rules can include query timeout, data inconsistency, error code, etc. When query timeout, data inconsistency, or error code occurs, it is considered that the content referred to by the corresponding log part has an abnormal event.

[0025] Based on the performance status, analysis is performed using performance analysis rules to determine whether there are abnormal events in the database.

[0026] Among them, performance analysis rules include resource utilization, resource exhaustion, etc. When the resource utilization of a certain resource (such as computing resources, storage resources, network resources, etc.) is too high and higher than the threshold, or when resource exhaustion is identified, it is considered that an abnormal event exists.

[0027] At this time, if it is determined that an abnormal event exists, the alarm mechanism is triggered and the abnormality handling process is entered.

[0028] S102: Based on the abnormal event, a transaction wait graph of the database is analyzed by a deadlock detection algorithm to identify a deadlock event.

[0029] First, the transaction waiting graph of the database is defined. The transaction waiting graph contains nodes and edges. Nodes represent transactions, and edges represent the waiting relationship between transactions. The waiting relationship means that there is an execution order relationship between transactions. If a transaction needs to wait for another transaction to be executed before it can be executed, then there is a waiting relationship between the two transactions.

[0030] At this point, all active transactions are traversed to build a transaction waiting graph, which is the transaction waiting graph corresponding to the current database.

[0031] At this time, deadlock events can be directly identified through relevant search algorithms (such as depth search algorithm, breadth search algorithm, etc.). However, when the amount of data in the database is large, each round of search algorithm requires more computing power resources.

[0032] Based on this, through the abnormal event, the transactions contained in it are determined, and in the transaction waiting graph, whether the transactions contained in it are in a loop. Even if deadlock detection is not performed, abnormal events still need to be monitored regularly or in real time. At this time, it is determined whether there are transactions in the abnormal event. If so, it is further determined whether it is in the loop. Deadlock detection can be performed without starting the search algorithm. Among them, the loop refers to that multiple transactions form a loop according to the waiting relationship, which makes these multiple transactions unable to be further executed.

[0033] S103: For the deadlock event, determine a plurality of participating transactions corresponding to the deadlock event, and based on transaction attributes corresponding to the participating transactions, select at least some of the participating transactions as designated transactions.

[0034] If it is detected through the above steps that the transaction is in a loop, the loop is regarded as a deadlock event, and all transactions participating in the loop are regarded as participating transactions in the deadlock event.

[0035] Of course, if it is determined that the duration of time that the included transaction has not been detected in the loop through the abnormal event has exceeded the first preset duration (the preset duration is usually longer than the timing duration for direct detection by the deadlock detection algorithm mentioned above. Of course, if the preset duration is consistent, it is generally believed that the frequency of abnormal event monitoring is faster, and the real-time nature of deadlock event monitoring can be increased through the transactions included therein), it is believed that there may be some violations of the detected deadlocks, so the transaction waiting graph is searched through a priority search algorithm (for example, a depth-first search algorithm, a breadth-first search algorithm, etc.) to determine whether there is a loop, thereby reducing the occurrence of missed detections.

[0036] If it exists, the ring will be treated as a deadlock event, and all transactions participating in the ring will be treated as participating transactions in the deadlock event.

[0037] In addition, the detection frequency of deadlock events detected by the priority search algorithm within the most recent third preset time period (the third preset time period is higher than the first preset time period) can also be obtained, that is, the priority search algorithm that detects the deadlock event is divided by the total number of priority search algorithms executed to obtain the detection frequency.

[0038] At this time, based on the detection frequency, the first preset duration is adjusted. When the detection frequency is too high (higher than the preset frequency), the first preset duration is reduced and the detection speed is increased. When the detection frequency is too low (lower than the preset frequency), the first preset duration is increased to reduce computing power consumption.

[0039] The specified transaction refers to the transaction used to perform rollback when a deadlock event occurs.

[0040] Based on this, the transaction attributes corresponding to the participating transactions are determined. The transaction attributes include: priority (usually pre-set, according to the initiator setting, for example, a high-priority transaction may be an operation initiated by a user, and a low-priority transaction may be a background batch process), and execution time.

[0041] At this time, for each participating transaction, it is determined whether the participating transaction has an abnormal event. If so, it is considered that the participating transaction itself may have other abnormal situations in addition to the deadlock, so the participating transaction is taken as the first designated transaction and participates in the rollback.

[0042] For each remaining participating transaction, determine whether the execution time of the participating transaction exceeds the second preset time. If not, it is considered that the participating transaction has just been executed for a short time and you can continue to wait for a while and treat the participating transaction as the second designated transaction and participate in the rollback.

[0043] For each remaining participating transaction, determine whether the priority of the participating transaction is higher than the preset priority. If not, the priority of the participating transaction is considered to be low, and the participating transaction is used as the third designated transaction to participate in the rollback.

[0044] Of course, in actual selection, it may not be necessary to select too many designated transactions for rollback. Therefore, when selecting designated transactions through participating transactions, the order of the first designated transaction, the second designated transaction, and the third designated transaction is followed. Whenever the number of selected designated transactions reaches the preset number, the selection of designated transactions is stopped. The preset number is 3. When 2 transactions are selected from the first designated transaction, the selection of the second designated transaction continues. At this time, 1 transaction needs to be selected from them. If there are multiple second designated transactions, 1 transaction is randomly selected from them as the second designated transaction. At this time, the sum of the first designated transaction and the second designated transaction meets the preset number, and there is no need to select the third designated transaction.

[0045] S104: performing a rollback operation on the designated transaction, and updating transaction attributes of the designated transaction after the rollback operation is performed.

[0046] Rollback the specified transaction to its previous process node or other process nodes so that the unrolled transactions can continue to execute.

[0047] After the rollback operation is completed, the specified transaction can be updated. If the first specified transaction is involved in the rollback, its transaction attributes are updated and a specified identifier is added. The specified identifier is used for a new deadlock event detected. If it is determined that there is a participating transaction with a specified identifier added, it is considered that the participating transaction has participated in the rollback before. At this time, a deadlock occurs again. Since the participating transaction is the first specified transaction in the abnormal event, it is likely that the frequent deadlocks are caused by the abnormality of the participating transaction. Therefore, the participating transaction is rolled back to the initial node at this time, and the process processing of the participating transaction is suspended, and an abnormal alarm is issued.

[0048] For the third designated transaction, since the third designated transaction has participated in the rollback and the corresponding process processing has been delayed for some time, its priority is updated to increase the priority of the third designated transaction. The next time it is detected that it is involved in a deadlock event, it can be prevented from being selected as a rollback event for multiple consecutive times with a higher priority.

[0049] S105: On the basis of the rollback operation, continue to execute the designated transaction after updating the transaction attributes.

[0050] like Figure 2 As shown in the figure, after handling deadlocks and exceptions, the execution order and priority of transactions are intelligently adjusted according to the current database load and resource conditions. For transactions interrupted by exceptions, the execution status is automatically restored to ensure data integrity and consistency. Flexible recovery strategies are provided, such as point-in-time recovery and transaction log-based recovery, to meet the needs of different scenarios.

[0051] It can also provide optimization suggestions based on the operation status and historical data of the database, such as adjusting index strategies, optimizing query statements, increasing resources, etc. It supports automated management of database configuration, including parameter settings, backup and recovery strategies, etc., to reduce the workload of administrators.

[0052] The database is managed uniformly through the monitoring server, and the load of each node in the database cluster is monitored, including key indicators such as CPU usage, memory usage, disk I / O speed, etc. According to the monitoring results, the data distribution and query routing strategies are dynamically adjusted to ensure load balancing of each node, avoid single point overload, and improve the overall performance of the system.

[0053] Scan the database for anomalies in real time. If a deadlock or other abnormal situation occurs, automatically select the sacrificial transaction (for example, based on transaction priority, execution time, etc.) and roll it back to resolve the deadlock.

[0054] Propose optimization plans for SQL statements that are too long and time-consuming in the database, and automatically propose improvement plans (creating indexes, etc.) based on the frequency of SQL usage.

[0055] like Figure 3 As shown, the embodiment of the present application also provides a database abnormality monitoring and processing device, including: at least one processor; and, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the database exception monitoring and processing method described in any of the above embodiments.

[0056] The embodiment of the present application further provides a non-volatile computer storage medium storing computer executable instructions, wherein the computer executable instructions are configured as: the database abnormality monitoring and processing method described in any of the above embodiments.

[0057] Each embodiment in this application is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device and medium embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiments.

[0058] The devices and media provided in the embodiments of the present application correspond one-to-one to the methods. Therefore, the devices and media also have similar beneficial technical effects as the corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the devices and media will not be repeated here.

[0059] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present application may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.

[0060] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0061] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0062] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0063] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0064] Memory may include non-permanent storage in a computer-readable medium, in the form of random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0065] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0066] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0067] The above is only an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. A database abnormality monitoring and processing method, characterized in that: include: Real-time monitoring to obtain the operating status of the database, and performing abnormal analysis based on the operating status to determine abnormal events existing in the database; Based on the abnormal event, analyzing the transaction wait graph of the database by a deadlock detection algorithm to identify the deadlock event; For the deadlock event, determine a plurality of participating transactions corresponding to the deadlock event, and select at least some of the participating transactions as designated transactions based on transaction attributes corresponding to the participating transactions; Performing a rollback operation on the designated transaction, and updating the transaction attributes of the designated transaction after the rollback operation is performed; Based on the rollback operation, the specified transaction is continued to be executed after the transaction attributes are updated.

2. The method according to claim 1, characterized in that Performing an abnormality analysis based on the operating status to determine abnormal events existing in the database specifically includes: Determine the operation log and performance status included in the operation status; Based on the operation log, an analysis is performed through an analysis engine and / or log analysis rules to determine whether there are abnormal events in the database; wherein the log analysis rules include query timeout, data inconsistency, and error code; Based on the performance status, analyzing by performance analysis rules to determine whether there are abnormal events in the database; wherein the performance analysis rules include resource usage and resource exhaustion; If there is an abnormal event, the alarm mechanism will be triggered and the exception handling process will begin.

3. The method according to claim 1, characterized in that Analyzing the transaction wait graph of the database by a deadlock detection algorithm to identify deadlock events, specifically including: A transaction waiting graph of a database is defined; wherein the transaction waiting graph includes nodes and edges, the nodes represent transactions, and the edges represent waiting relationships between transactions; Traverse all active transactions and build a transaction waiting graph; Determine the transaction included in the abnormal event, and determine whether the included transaction is in a loop in the transaction waiting graph; If so, the ring is regarded as a deadlock event, and all transactions participating in the ring are regarded as participating transactions in the deadlock event.

4. The method according to claim 3, characterized in that The method further comprises: Determining that a duration during which no included transaction is detected in the ring through the abnormal event has exceeded a first preset duration; Retrieving the transaction waiting graph by a priority search algorithm to determine whether there is a loop; If so, the loop is regarded as a deadlock event, and all transactions participating in the loop are regarded as participating transactions in the deadlock event.

5. The method according to claim 3, characterized in that: Based on the transaction attributes corresponding to the participating transactions, selecting at least some of the participating transactions as designated transactions specifically includes: Determine the transaction attributes corresponding to the participating transaction, wherein the transaction attributes include: priority and execution time; For each participating transaction, confirm whether the participating transaction exists in the abnormal event; If it exists, the participating transaction is taken as the first designated transaction; For each remaining participating transaction, determining whether the execution time of the participating transaction exceeds a second preset time length; If not, the participating transaction is regarded as the second designated transaction; For each remaining participating transaction, determining whether the priority of the participating transaction is higher than the preset priority; If not, the participating transaction will be regarded as the third designated transaction.

6. The method according to claim 5, characterized in that Update the transaction attributes of the specified transaction after the rollback operation is completed, including: For the first designated transaction, update its transaction attribute and add a designated identifier; For the third designated transaction, the priority thereof is updated to increase the priority of the third designated transaction; The method further comprises: For a new deadlock event, if it is determined that there is a participating transaction with a specified identifier added, the participating transaction is rolled back to the initial node, the process processing of the participating transaction is suspended, and an abnormal alarm is issued.

7. The method according to claim 5, characterized in that The method further comprises: When selecting a designated transaction through participating transactions, the selection of designated transactions is stopped in the order of the first designated transaction, the second designated transaction, and the third designated transaction, whenever the number of selected designated transactions reaches a preset number.

8. The method according to claim 4, characterized in that The method further comprises: Obtaining a detection frequency of deadlock events detected by a priority search algorithm within a recent third preset time period; wherein the third preset time period is higher than the first preset time period; Based on the detection frequency, the first preset duration is adjusted.

9. A database abnormality monitoring and processing device, characterized in that: include: at least one processor; as well as, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the database exception monitoring and processing method as described in any one of claims 1 to 8.

10. A non-volatile computer storage medium storing computer executable instructions, characterized in that: The computer executable instructions are set to: the database abnormality monitoring and processing method described in any one of claims 1 to 8.

Citation Information

Patent Citations

  • Deadlock processing method and device, computer equipment and storage medium

    CN115373864A

  • Distributed transaction deadlock detection unlocking method and device and storage medium

    CN116303785A

  • Deadlock detection method and related device

    CN118069383A

  • Method and device for simultaneously ensuring consistency and performance

    CN118503251A