Database deadlock detection and analysis method and device, equipment and medium

Abstract

The invention relates to the technical field of big data, and discloses a database deadlock detection and analysis method, which comprises the following steps of: loading a configuration file, extracting a monitoring interval parameter and a log level parameter, connecting a target database according to the configuration file, periodically acquiring state information of affairs and resources through a database interface, and storing the state information as a state snapshot; initializing a data structure of the resource waiting graph, adding transaction nodes, resource nodes, request edges and occupation edges based on the state snapshots, performing depth-first search on the resource waiting graph to detect whether a loop exists or not, judging whether transactions and resources related to the loop form deadlocks or not, and recording related information; a report of a deadlock cause analysis and solution is generated based on the transaction state, the resource state, the loop information, the occupancy relationship, and the waiting relationship. According to the method, the state snapshot is constructed by periodically collecting the state information of the affairs and the resources, and the deadlock problem is quickly positioned and accurately analyzed in combination with initialization and dynamic updating of the resource waiting graph.

Description

Technical Field

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

[0002] In modern financial database systems, efficient operation of the database is the basis for ensuring the normal operation of core businesses such as financial transactions, account management, and risk control. However, in high-concurrency financial business scenarios, deadlock problems frequently occur, becoming an important source of database performance bottlenecks and stability risks. Deadlock usually occurs when two or more transactions are waiting for resources and cannot continue to execute, which may cause a decrease in system operation efficiency and even seriously affect the overall stability of the financial system.

[0003] Currently, although there are some tools for deadlock detection on the market, these tools still have the following shortcomings in terms of functionality and efficiency:

[0004] Existing tools are usually unable to monitor the status of database transactions and resources in real time, and are unable to capture and analyze deadlock problems in a timely manner. Especially in scenarios where financial transactions are frequent and require high real-time performance, delays are often caused by deadlock problems.

[0005] Existing deadlock detection tools usually only provide basic deadlock detection functions and it is difficult to further generate detailed deadlock analysis reports. Users need to manually analyze the deadlock causes, dependencies between transactions and resources, and solutions, which not only increases operational complexity but also reduces processing efficiency.

[0006] After detecting a deadlock, existing tools usually only provide simple transaction termination suggestions. They lack intelligent analysis of key indicators such as transaction priority and resource occupancy time, and are unable to automatically select the optimal solution based on business scenarios.

[0007] Although some tools can detect deadlock problems, they lack intuitive dependency link display and visualization of deadlock relationships. Users are inefficient in understanding the complex dependency relationships between transactions and resources, and are prone to misjudgment.

[0008] Financial business scenarios are usually accompanied by highly concurrent transaction requests and complex resource dependencies. When processing large-scale transactions and resource relationships, existing tools may not be able to effectively deal with complex deadlock scenarios due to performance bottlenecks.

[0009] In summary, the existing technologies have obvious deficiencies in the real-time performance, automated analysis, intelligent solutions and visualization functions of deadlock detection. Especially in high-concurrency business scenarios in the financial field, they cannot meet the needs of timely, accurate and comprehensive handling of deadlock problems. Summary of the invention

[0010] The main purpose of the present invention is to provide a database deadlock detection and analysis method, device, equipment and storage medium, aiming to solve the technical problems that the existing technology is inefficient in detecting, analyzing and solving database deadlock problems, lacks comprehensiveness and intelligence, and is difficult to meet the needs of complex business scenarios.

[0011] To achieve the above object, the present invention provides a database deadlock detection and analysis method, comprising:

[0012] Loading a configuration file of a deadlock detection module, and extracting a monitoring interval parameter and a log level parameter from the configuration file;

[0013] Connecting to the target database according to the target database information in the configuration file;

[0014] According to the monitoring interval parameter, periodically acquiring the state information of the transaction and the state information of the resource in the target database through the database application program interface, and storing the state information of the transaction and the state information of the resource as a state snapshot;

[0015] Initialize a data structure of a resource waiting graph according to the state snapshot;

[0016] According to the transaction identifier, resource identifier and the request and occupation relationship between the transaction and the resource contained in the state snapshot, adding a transaction node, a resource node, a request edge and an occupation edge in the resource waiting graph;

[0017] Performing a depth-first search traversal on all nodes in the resource waiting graph to detect whether there is a loop in the resource waiting graph;

[0018] If a loop is detected in the resource waiting graph, it is determined that the transactions and resources involved in the loop constitute a deadlock, and information of transaction nodes and resource nodes in the loop, occupation relationships between transaction nodes and resource nodes, and waiting relationships between transaction nodes are recorded;

[0019] Based on the transaction status information, resource status information, information of transaction nodes and resource nodes in the loop, occupation relationship between transaction nodes and resource nodes, and waiting relationship between transaction nodes, an analysis report including deadlock cause analysis and solutions is generated.

[0020] Furthermore, to achieve the above-mentioned purpose, the present invention provides a database deadlock detection and analysis device, comprising:

[0021] A configuration management module, used for loading a configuration file of a deadlock detection module and extracting a monitoring interval parameter and a log level parameter from the configuration file;

[0022] A database connection module, used to connect to a target database according to the target database information in the configuration file;

[0023] A data acquisition module, used for periodically acquiring the transaction status information and resource status information of the target database through a database application program interface according to the monitoring interval parameter, and storing the transaction status information and resource status information as a status snapshot;

[0024] A graph data initialization module, used to initialize the data structure of the resource waiting graph according to the state snapshot;

[0025] A graph construction module, configured to add transaction nodes, resource nodes, request edges and occupied edges in the resource waiting graph according to the transaction identifiers, resource identifiers and the request and occupation relationship between transactions and resources contained in the state snapshot;

[0026] A loop detection module, used for performing a depth-first search traversal on all nodes in the resource waiting graph to detect whether there is a loop in the resource waiting graph;

[0027] A deadlock determination module, for determining that the transactions and resources involved in the loop constitute a deadlock if a loop is detected in the resource waiting graph, and recording information of transaction nodes and resource nodes in the loop, occupation relationships between transaction nodes and resource nodes, and waiting relationships between transaction nodes;

[0028] An analysis report generation module is used to generate an analysis report including a deadlock cause analysis and a solution based on the transaction status information, resource status information, information of the transaction nodes and resource nodes in the loop, the occupancy relationship between the transaction nodes and the resource nodes, and the waiting relationship between the transaction nodes.

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

[0030] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium, on which a database deadlock detection and analysis program is stored, and when the database deadlock detection and analysis program is executed by a processor, the steps of the database deadlock detection and analysis method as described above are implemented.

[0031] Beneficial effects: The present invention relates to the fields of big data technology and financial technology, and discloses a database deadlock detection and analysis method, which loads a configuration file and extracts monitoring interval parameters and log level parameters, connects to a target database according to the configuration file, periodically obtains transaction and resource status information through a database interface and stores it as a status snapshot, initializes the data structure of a resource waiting graph, adds transaction nodes, resource nodes, request edges, and occupied edges based on the status snapshot, performs a depth-first search on the resource waiting graph to detect whether there is a loop, determines whether the transactions and resources involved in the loop constitute a deadlock, records relevant information, and generates a report on deadlock cause analysis and solutions based on transaction status, resource status, loop information, occupation relationship, and waiting relationship. The present invention constructs a status snapshot by periodically collecting transaction and resource status information, and combines the initialization and dynamic update of the resource waiting graph to achieve rapid positioning and accurate analysis of deadlock problems; efficiently detects loops in the resource waiting graph through depth-first search, determines the cause of deadlock, and generates an analysis report containing interaction paths, dependencies, and solutions, thereby improving the intelligence and automation level of deadlock detection and processing, and is suitable for stable operation and optimized management of databases in high-concurrency scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0033] Figure 1 A schematic diagram of an application environment of a database deadlock detection and analysis method in an embodiment of the present invention;

[0034] Figure 2 A schematic diagram of a process flow of an embodiment of a database deadlock detection and analysis method of the present invention;

[0035] Figure 3 A schematic diagram of functional modules of a preferred embodiment of the database deadlock detection and analysis device of the present invention;

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

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

[0038] 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.

[0039] The database deadlock detection and analysis method provided by the embodiment of the present invention can be applied in Figure 1In an application environment, the user end communicates with the server end through a network. The server end can load a configuration file through the user end and extract monitoring interval parameters and log level parameters, connect to the target database according to the configuration file, periodically obtain the status information of transactions and resources through the database interface and store them as a state snapshot, initialize the data structure of the resource waiting graph, add transaction nodes, resource nodes, request edges and occupied edges based on the state snapshot, perform a depth-first search on the resource waiting graph to detect whether there is a loop, determine whether the transactions and resources involved in the loop constitute a deadlock, record relevant information, and generate a report on the cause analysis and solution of the deadlock based on the transaction state, resource state, loop information, occupation relationship and waiting relationship. The present invention constructs a state snapshot by periodically collecting the state information of transactions and resources, and combines the initialization and dynamic update of the resource waiting graph to achieve rapid positioning and accurate analysis of the deadlock problem; efficiently detects the loop in the resource waiting graph through a depth-first search, determines the cause of the deadlock, and generates an analysis report containing the interaction path, dependency relationship and solution, thereby improving the intelligence and automation level of deadlock detection and processing, and is suitable for the stable operation and optimized management of databases in high-concurrency scenarios. The user end may be, but is not limited to, various personal computers, laptop computers, smart phones, tablet computers, and portable wearable devices. The server end may be implemented by an independent server or a server cluster consisting of multiple servers. The present invention is described in detail below through specific embodiments.

[0040] See also Figure 2 , Figure 2 This is a flow chart of an embodiment of a database deadlock detection and analysis method 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.

[0041] like Figure 2 As shown, the database deadlock detection and analysis method proposed by the present invention includes the following steps:

[0042] S10, loading a configuration file of a deadlock detection module, and extracting a monitoring interval parameter and a log level parameter from the configuration file;

[0043] In this embodiment, loading a configuration file refers to reading configuration content related to the deadlock detection module from a storage medium (such as a file system or a database). These configuration files are usually saved in a structured format (such as JSON, YAML, or XML) and are used to define operating parameters of the deadlock detection system, connection information of the target database, and monitoring strategies.

[0044] Use the file reading API to load the configuration file content. For example, use Python's open() function or Java's FileReader class to read the file; check the configuration file format and integrity to ensure that all required fields are complete and there are no syntax errors; parse the file content into a data structure supported by the programming language, such as parsing JSON into a dictionary or parsing XML into a tree structure; if the configuration file is stored on a remote server or distributed storage system, the configuration content can be obtained through the REST API or message queue.

[0045] The monitoring interval parameter is used to set the time interval for the deadlock detection module to periodically obtain database status information, which is a key configuration for periodic monitoring.

[0046] Read the corresponding fields from the parsed data structure, such as config["monitor_interval"]; verify the validity of the parameter value to ensure that it is a reasonable time unit (such as seconds or milliseconds); save the monitoring interval parameter in a memory variable for subsequent operations; if the parameter is missing, provide a default value (such as setting it to 5 seconds).

[0047] The log level parameter is used to define the level of detail of the logs recorded by the deadlock detection module during operation, including levels such as debug information (DEBUG), operation records (INFO), and exception information (ERROR).

[0048] Extract the log level field from the parsed configuration, such as config["log_level"]; verify the validity of the log level, allowing only predefined log levels (such as DEBUG, INFO, ERROR); configure the operation mode of the logger, such as using Python's logging module or Java's Log4j framework to set the log output level; apply this parameter in the log initialization module to control the generation and storage of logs.

[0049] By loading the configuration file and extracting key parameters, the deadlock detection module is dynamically configured and flexibly managed. The monitoring interval parameter ensures that the module can run periodically and adapt to the real-time requirements of the high-concurrency database environment; the log level parameter provides a flexible log management mechanism, which helps users quickly locate problems during debugging, operation and exception handling.

[0050] S20, connecting to the target database according to the target database information in the configuration file;

[0051] In this embodiment, the connection information of the target database is extracted from the configuration file, including the database type (such as MySQL, PostgreSQL, Oracle, etc.), connection address (IP or domain name), port number, database name, user name, password, etc. This information is used to establish a communication channel with the target database.

[0052] Use the configuration file parsing module to obtain the corresponding field values, such as db_type, db_host, db_port, db_name, db_user, and db_password; verify whether these fields are complete and valid to ensure that all information required for the connection has been loaded correctly; if some fields are missing, return an error prompt and terminate the connection attempt.

[0053] Initialize the parsed database information into a connection configuration that can be used by the database driver. This includes mapping the database type to the driver (such as JDBC or ODBC), formatting the connection string, etc.

[0054] Select the corresponding driver or client library according to the database type, such as using the JDBC driver to load com.mysql.jdbc.Driver; construct a connection string, for example: MySQL format: jdbc:mysql: / / <host> : <port> / <database>; PostgreSQL format: jdbc:postgresql: / / <host> : <port> / <database>; Initialize the connection parameter object and fill the corresponding fields with information such as username and password.

[0055] Establish a communication channel with the target database through the database driver to ensure that the connection is normal and available. Use the API provided by the database driver or library to initiate a connection request, such as the DriverManager.getConnection() method of Java or the psycopg2.connect() function of Python; after a successful connection, return the database connection object for subsequent queries; when the connection fails, capture the exception and return detailed error information, including reasons such as connection timeout, authentication failure, and target unreachable.

[0056] After completing the database connection, verify the availability of the connection to ensure that the target database can be accessed normally. Test the connection by executing a simple query (such as SELECT 1); capture and handle exceptions in the connection verification, retry the connection or report an error.

[0057] By parsing the target database information in the configuration file, dynamically initializing the database connection configuration and establishing an efficient communication channel, flexible support for multiple types of databases is achieved. By verifying the connection status, the reliability and stability of database communication are guaranteed, providing a basic environment for subsequent transactions and resource monitoring.

[0058] S30, periodically acquiring transaction status information and resource status information in the target database through a database application program interface according to the monitoring interval parameter, and storing the transaction status information and resource status information as a status snapshot;

[0059] In this embodiment, the time interval for periodically acquiring transaction and resource status information is set according to the monitoring interval parameter to ensure regular monitoring of the target database. This parameter directly affects the balance between the real-time nature of monitoring and system performance.

[0060] Use scheduling tools or task planning modules (such as ScheduledExecutorService in Java and schedule library in Python) to set scheduled tasks; initialize the time period of scheduled tasks according to the monitoring interval parameters; after the trigger time arrives, call the database interface to obtain transaction and resource status information.

[0061] Through the database application program interface, query the status of the current transaction in the target database, including transaction identification, execution status (such as running, waiting, committed, rolled back, etc.). This information is used for subsequent resource waiting graph construction and deadlock detection.

[0062] Use the database interface (such as JDBC, ODBC, or database management tools) to execute transaction status query statements; query statement example:

[0063] MySQL:SELECT*FROM information_schema.innodb_trx;

[0064] PostgreSQL:SELECT*FROM pg_stat_activityWHERE state='active'.

[0065] Parse the query results into data structures supported by programming languages ​​(such as lists in Python and object collections in Java), and extract key information such as transaction ID and status.

[0066] Through the database application program interface, query the current status of the resources in the target database, including resource identification, lock status (such as shared lock, exclusive lock), and the list of occupied and requested transactions. Execute the query statement to obtain the lock information of the current resource;

[0067] MySQL example: SHOW ENGINE INNODB STATUS;

[0068] PostgreSQL example: SELECT * FROM pg_locks .

[0069] Parse the lock information and extract the resource identifier, currently occupied transaction, and waiting transaction queue; format the extracted results into structured data for use in subsequent steps.

[0070] The transaction status information and resource status information are integrated into a state snapshot, which serves as the basic data for resource wait graph construction and deadlock detection. The state snapshot describes the global state of transactions and resources at the current point in time.

[0071] Define the storage structure of the state snapshot, such as a dictionary in memory or a table in a database;

[0072] It can be stored in the following structure:

[0073] Transaction snapshot: uses the transaction ID as the primary key to record the transaction status (such as running, waiting);

[0074] Resource snapshot: uses resource identifier as the primary key to record occupied transactions and waiting transaction queues;

[0075] Update the contents of the status snapshot in periodic tasks to ensure that the data reflects the current status in real time; in high-performance scenarios, snapshots can be stored in a cache system (such as Redis) to speed up reading.

[0076] By periodically obtaining the status information of transactions and resources in the target database and storing it as a status snapshot, global and real-time basic data is provided for deadlock detection. Using the status snapshot, the system can quickly build a resource waiting graph and efficiently detect deadlocks, while avoiding the performance overhead caused by frequent access to the database. It is suitable for business scenarios with high concurrency and complex transactions.

[0077] S40, initializing a data structure of a resource waiting graph according to the state snapshot;

[0078] In this embodiment, the resource waiting graph is a directed graph used to describe the relationship between transactions and resources. The nodes in the graph represent transactions and resources, and the edges represent the request or occupation relationship between transactions and resources. Initializing the data structure of the resource waiting graph is the basic operation for subsequent deadlock detection.

[0079] Select data structure: Choose a suitable storage method according to the application scenario, such as adjacency list or adjacency matrix: Adjacency list: suitable for scenarios with a large number of transactions and resources but sparse relationships; Adjacency matrix: suitable for scenarios with dense relationships between transactions and resources.

[0080] Set up the storage structure: define the node storage structure and edge storage structure of the resource waiting graph: Node storage structure: use lists, dictionaries or database tables to store transaction nodes and resource nodes; Edge storage structure: record the type of edge (request edge or occupied edge) and direction.

[0081] Allocate storage space: Dynamically allocate storage space based on the number of transaction identifiers and resource identifiers in the state snapshot to ensure that the resource waiting graph can accommodate all nodes and edge relationships.

[0082] The state snapshot contains the current state of transactions and resources. To initialize the resource waiting graph, you need to extract all transaction identifiers and resource identifiers from it and ensure that each node in the graph is uniquely mapped to an identifier. Traverse the transaction information and resource information in the state snapshot, extract the transaction identifier and resource identifier; check whether there are duplicate identifiers, and remove them if there are duplicates; use the identifiers to generate the corresponding nodes and add them to the graph.

[0083] Create a mapping relationship between the transaction nodes and resource nodes in the resource waiting graph, so that the corresponding graph nodes can be quickly located by identification later. Use a dictionary structure to store node mapping relationships, with the key being the transaction identifier or resource identifier and the value being the node index; dynamically update the mapping relationship to support subsequent node addition and deletion operations; synchronize the mapping relationship with the node storage structure to ensure consistency.

[0084] According to the setting of the log level parameter, the detailed information of the resource waiting graph initialization process is recorded, including the data structure type, the number of allocated nodes, the size of the storage space, etc., for debugging and problem location. Determine the log level:

[0085] DEBUG level: records all initialization information, including node creation process and storage allocation;

[0086] INFO level: records key initialization steps and final results;

[0087] ERROR level: Only exception information is recorded.

[0088] Use a logging module to output records, such as Python's logging module or Java's Log4j framework; store log information in files, databases, or monitoring systems to support subsequent analysis and backtracking.

[0089] By initializing the data structure of the resource waiting graph based on the state snapshot, the dependency relationship between transactions and resources is constructed, providing efficient and structured basic data for subsequent deadlock detection. By dynamically allocating storage space and recording the initialization process log, the system's debugging ability and scalability are improved, while ensuring the accuracy and real-time performance of the resource waiting graph.

[0090] S50, adding transaction nodes, resource nodes, request edges and occupied edges in the resource waiting graph according to the transaction identifiers, resource identifiers and the request and occupation relationship between the transaction and the resource contained in the state snapshot;

[0091] In this embodiment, the identifiers of all current transactions and resources are obtained from the state snapshot to ensure that these entities are fully mapped in the resource waiting graph. The transaction identifier represents the active transaction unit, and the resource identifier represents the resource unit that is locked or requested.

[0092] Extract a list of transaction identifiers from the state snapshot to record all active transactions; extract a list of resource identifiers, including locked resources and requested resources; deduplicate identifiers to ensure that each transaction and resource is recorded only once; verify the integrity of the identifiers and filter out invalid or duplicate records.

[0093] Check the node set of the resource waiting graph to determine whether the transaction identifier and resource identifier extracted from the state snapshot are already included. If not, add a new node and synchronize it to the resource waiting graph.

[0094] For each transaction identifier, check whether it already exists in the node set of the resource waiting graph; if not, create a transaction node and add it to the graph; similarly, perform the same operation for each resource identifier and create the corresponding resource node; update the storage structure of the node set and map the newly added transaction nodes and resource nodes to the graph index.

[0095] Based on the resource request relationship of transactions in the state snapshot, a directed edge from the transaction node to the resource node is added to the resource waiting graph for each pair of request relationships. The request edge indicates that the transaction is currently requesting the permission to use the resource.

[0096] Traverse the request relationship records in the state snapshot; for each record, locate the graph nodes corresponding to the request transaction and the target resource; add a directed edge from the transaction node to the resource node in the resource waiting graph; store the edge type and additional information (such as request time) in the edge storage structure.

[0097] Based on the occupation relationship between resources and transactions in the state snapshot, a directed edge from the resource node to the transaction node is added to the resource waiting graph for each pair of occupation relationships. The occupation edge indicates the current usage rights of the resource held by the transaction.

[0098] Traverse the occupancy relationship records in the state snapshot; for each record, locate the graph nodes corresponding to the occupied resources and the holding transactions; add directed edges from the resource nodes to the transaction nodes in the resource waiting graph; store the edge type and additional information (such as occupancy duration) in the edge storage structure.

[0099] After completing the node and edge addition operations, update the node set and edge storage structure of the resource waiting graph to ensure that the graph structure is complete and consistent with the state snapshot.

[0100] Record the newly added nodes and edges into the node set and edge storage structure; if the number of nodes or edges exceeds the current storage space, dynamically expand the storage structure; verify the correctness of the graph structure to ensure that there are no duplicate nodes or edges.

[0101] By dynamically adding transaction nodes, resource nodes, request edges, and occupied edges to the resource waiting graph, a comprehensive dependency graph of transactions and resources is constructed to ensure that the basic data for deadlock detection is accurate and real-time. Through an efficient node and edge management mechanism, it supports a variety of database scenarios and optimizes the storage structure and update performance of the graph.

[0102] S60, performing a depth-first search traversal on all nodes in the resource waiting graph to detect whether there is a loop in the resource waiting graph;

[0103] In this embodiment, before the depth-first search traversal begins, it is necessary to initialize the states of all nodes in the resource waiting graph, mark each node as unvisited, and set a recursive stack to record the nodes on the current path to facilitate detection of whether there is a loop.

[0104] Create a state flag for each node in the resource waiting graph, with a value of "unvisited", "visiting", or "visited"; use a data structure (such as a stack or list) to store the nodes on the recursive path; ensure that the recursive stack is empty when the search starts.

[0105] Select a node in the resource waiting graph that is in the unvisited state as the starting node for the depth-first search, ensuring that all nodes are checked even if the graph is not connected. Traverse the node set of the resource waiting graph to find a node in the unvisited state; use the found node as the starting point of the current search path; if all nodes have been visited, end the search.

[0106] Recursively traverse all adjacent nodes connected to the current node, mark the access status of the nodes, and record the visited nodes along the search path.

[0107] Mark the state of the current node as "visiting"; add the current node to the recursive stack; traverse all adjacent nodes of the current node, if the adjacent node is "unvisited", recursively call the depth-first search; if the adjacent node is "visiting" and exists in the recursive stack, a loop is detected.

[0108] After the depth-first search is completed, the search path is backtracked, the status of the current node is updated to "visited", and it is removed from the recursive stack.

[0109] Check whether all adjacent nodes of the current node have been visited; if all have been visited, mark the current node status as "visited"; remove the current node from the recursive stack and continue to backtrack to the previous node.

[0110] During the search process, if the recursive stack detects that the currently visited node already exists, it means that there is a loop in the path, that is, a deadlock has occurred.

[0111] When traversing adjacent nodes, if the state of the current adjacent node is "being visited" and the node exists in the recursive stack, the loop information is recorded; the recursive search is terminated immediately and the detection result is returned; if all nodes have been visited and no loop is detected, it is determined that there is no loop in the resource waiting graph.

[0112] By performing a depth-first search traversal of all nodes in the resource waiting graph, efficient loop detection is achieved. By marking node status and using a recursive stack, the circular dependency between transactions and resources can be accurately identified, providing a basis for subsequent deadlock analysis and resolution. The dynamic path recording and backtracking mechanism ensures the efficiency and correctness of the algorithm, which is suitable for high-concurrency and complex transaction scenarios.

[0113] S70, if a loop is detected in the resource waiting graph, determine that the transactions and resources involved in the loop constitute a deadlock, and record information of transaction nodes and resource nodes in the loop, occupation relationships between transaction nodes and resource nodes, and waiting relationships between transaction nodes;

[0114] In this embodiment, by detecting the loop in the resource wait graph, it is confirmed whether there is a mutually dependent cyclic relationship between the transaction and the resource. If there is a loop, it is determined that the transaction and the resource in the loop have formed a deadlock.

[0115] The nodes on the current path are recorded using a recursive stack of depth-first search. When a node is detected to be repeated in the path, it is marked as a loop. All nodes in the loop are used as the scope of deadlock-related transactions and resources.

[0116] The basic information of all transaction nodes and resource nodes involved in the loop is recorded to provide a basis for subsequent deadlock analysis and resolution.

[0117] Obtain the identification of transaction nodes and resource nodes (such as node ID, name or unique identifier); extract additional information of the nodes, such as the execution status of the transaction, the current locking status of the resource, etc.; organize the information and store it as a loop node record table for subsequent use.

[0118] Record the occupation relationship of transaction nodes to resource nodes in the loop, indicating which resources are held by which transactions.

[0119] Traverse all transaction nodes and resource nodes in the loop; check whether each transaction node has an occupied edge with the resource node; if there is an occupied edge, record additional information such as the transaction node's occupation time and type (such as exclusive lock or shared lock) of the resource node.

[0120] Record the waiting relationship between transaction nodes in the loop, indicating which transactions are waiting for other transactions to release resources. Traverse all transaction nodes in the loop; check whether there are waiting edges between transaction nodes (such as relationships in the waiting queue); record additional information of the waiting relationship, including waiting time, blocked transactions and their priorities, etc.

[0121] The information of transaction nodes, resource nodes, occupancy relationships and waiting relationships in the recorded loop is archived and stored to provide data support for the subsequent generation of analysis reports and solutions.

[0122] Organize information into a unified structured format, such as JSON, tables, or database records; record detailed or summary information based on log level parameters; store information in files, databases, or monitoring systems.

[0123] By detecting the loop in the resource waiting graph and recording the information, occupancy relationship and waiting relationship of the transaction nodes and resource nodes in the loop in detail, the root cause of the deadlock is accurately identified. The recorded information provides high-quality input data for subsequent deadlock analysis and resolution, improving the reliability of the system and the efficiency of troubleshooting.

[0124] S80, generating an analysis report including a deadlock cause analysis and a solution based on the transaction status information, resource status information, information of transaction nodes and resource nodes in the loop, occupancy relationships between transaction nodes and resource nodes, and waiting relationships between transaction nodes.

[0125] In this embodiment, transaction status information, resource status information, information of transactions and resource nodes in the loop, occupation relationship between transactions and resources, and waiting relationship between transaction nodes are integrated into a unified dependency model. The dependency model provides data support for deadlock analysis and solutions.

[0126] Extract transaction status information from the record, including transaction ID, current status (running, waiting, etc.) and priority; extract resource status information, including resource ID, currently occupied transaction, and waiting transaction list; combine the information of transaction nodes and resource nodes involved in the loop to build a dependency link graph of transactions and resources; use the graph structure to store node relationships, and map the occupied relationship and waiting relationship to directed edges in the graph; verify the integrity of the dependency model to ensure that all nodes and relationships are correctly incorporated into the model.

[0127] Analyze the interaction path between transactions and resources based on the dependency link graph to identify the specific causes of deadlock, including circular dependencies between transactions or resources being occupied for a long time without being released.

[0128] Traverse all loops in the dependency link graph and extract the transactions and resources involved in the loops; check whether there is a circular dependency in the resource request path of each transaction; count the resource occupancy time, and if it exceeds the preset threshold and is not released, mark it as a possible cause; combine loop analysis and occupancy time statistics to generate a detailed list of deadlock causes.

[0129] According to the deadlock cause, combined with the priority strategy and the occupied time strategy, determine the solution suitable for the current deadlock scenario. If there are low-priority transactions in the loop, it is recommended to terminate the low-priority transactions to release resources; if the resource occupation time exceeds the threshold, it is recommended to release the resources that have been occupied for a long time; if the transaction priorities are similar, it is recommended to adjust the execution order of the transactions to break the circular dependency; classify the determined solutions into different strategies, and record the applicable scenarios of each strategy.

[0130] Organize the integrated data sources, interaction path analysis results and solutions into structured analysis reports to facilitate user understanding and execution.

[0131] Format the information of transactions and resource nodes in the loop and generate detailed descriptions of transactions and resources; use graphical tools or structured formats to display dependency link diagrams; list the results of deadlock cause analysis in the form of entries, including circular dependencies and occupied time issues; present solutions clearly, sort by priority and attach applicable suggestions; output analysis reports as log files or send them to administrators through notification modules.

[0132] By integrating transaction status information, resource status information, nodes in the loop and dependency relationships, we can quickly build a dependency link diagram of transactions and resources and accurately analyze the cause of deadlock. We can efficiently generate analysis reports that include deadlock causes and solutions, provide users with clear deadlock handling guidance, improve database management efficiency, and avoid long-term system stagnation.

[0133] The present invention relates to the field of big data technology and financial technology, and discloses a database deadlock detection and analysis method, which loads a configuration file and extracts monitoring interval parameters and log level parameters, connects to a target database according to the configuration file, periodically obtains transaction and resource status information through a database interface and stores it as a status snapshot, initializes the data structure of a resource waiting graph, adds transaction nodes, resource nodes, request edges and occupied edges based on the status snapshot, performs a depth-first search on the resource waiting graph to detect whether there is a loop, determines whether the transactions and resources involved in the loop constitute a deadlock, records relevant information, and generates a report on deadlock cause analysis and solutions based on transaction status, resource status, loop information, occupation relationship and waiting relationship. The present invention constructs a status snapshot by periodically collecting transaction and resource status information, combines the initialization and dynamic update of the resource waiting graph, realizes the rapid positioning and accurate analysis of the deadlock problem; efficiently detects the loop in the resource waiting graph through a depth-first search, determines the deadlock cause, and generates an analysis report containing interaction paths, dependencies and solutions, thereby improving the intelligence and automation level of deadlock detection and processing, and is suitable for the stable operation and optimized management of databases in high-concurrency scenarios.

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

[0135] S401, selecting a data structure of a resource waiting graph, and using an adjacency list or an adjacency matrix as a representation method of the resource waiting graph;

[0136] S402, allocating storage space for information of transaction nodes and resource nodes in the resource waiting graph according to the number of transaction identifiers and resource identifiers in the state snapshot, and initializing storage structures of transaction nodes and resource nodes;

[0137] S403, creating a mapping table of the transaction nodes and resource nodes, wherein the mapping table is used to record a mapping relationship between a transaction identifier and a resource identifier and a corresponding node index in a resource waiting graph;

[0138] S404, recording detailed information of the resource waiting graph initialization process according to the log level parameter, the detailed information including data structure type, number of nodes and storage space size.

[0139] In this embodiment, the resource waiting graph is a key data structure that describes the relationship between transactions and resources, and is used to store the relationship between transactions and resources, such as dependency, request, and occupancy.

[0140] Adjacency lists and adjacency matrices are common representations of resource waiting graphs, and each has its own applicable scenarios:

[0141] The adjacency list is suitable for graphs with sparse nodes and edges, with high storage efficiency and flexible query; the adjacency matrix is ​​suitable for graphs with dense nodes and edges, and can quickly access the relationship between specific nodes.

[0142] Determine the number of transaction identifiers and resource identifiers, and estimate the sparsity of the graph; select an adjacency list or adjacency matrix as the representation of the graph based on the estimation results; initialize the data structure:

[0143] Adjacency list: Assign a list to each node to store adjacent nodes;

[0144] Adjacency matrix: Creates a two-dimensional array that represents the edge relationships between nodes.

[0145] Allocate sufficient storage space to support the information storage of all transaction nodes and resource nodes; initialize the storage structure to record the attributes of the node, such as identifier, current status, etc.

[0146] Extract the total number of transaction IDs and resource IDs from the state snapshot; calculate the storage requirements:

[0147] Adjacency list: Assign a dynamic list or linked list to each node;

[0148] Adjacency matrix: Initialize the two-dimensional array according to the total number of nodes, and the default value is set to 0 or empty;

[0149] Initialize the node attribute storage structure, including the basic information of the transaction node and resource node (identifier, status, occupancy or waiting time, etc.).

[0150] The function of the mapping table is to quickly find the node index corresponding to the transaction identifier and resource identifier in the resource waiting graph; through the mapping table, the node information can be updated and queried efficiently.

[0151] Create a mapping table structure, which is commonly implemented as a hash table or dictionary; traverse the transaction identifiers and resource identifiers in the state snapshot and generate a unique index for each identifier; store the transaction identifier and resource identifier and the corresponding node index in the mapping table for quick query.

[0152] The information generated during the initialization process includes the type of graph, the number of nodes, the size of the storage space, etc., to provide support for debugging, monitoring, and problem diagnosis. The log level parameter controls the level of detail of the log, and common levels include DEBUG (detailed logging) and INFO (brief logging).

[0153] Determine the current log level;

[0154] DEBUG: records detailed information of all operations during the initialization process, including node allocation, data structure selection, etc.

[0155] INFO: only records the information of key steps, such as graph type, number of nodes, and storage space size;

[0156] Formats and writes initialization information to a log file or logging system.

[0157] This embodiment quickly completes the construction of the graph model of the transaction and resource relationship by initializing the data structure of the resource waiting graph according to the state snapshot. Based on the flexible representation method of the graph, the efficient storage structure of nodes and edges, and the fast indexing capability of the mapping table, the construction efficiency and data query performance of the resource waiting graph are significantly improved, laying a solid foundation for subsequent loop detection and deadlock analysis.

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

[0159] S501, traversing all transaction identifiers and resource identifiers recorded in the state snapshot, and reading one by one the request relationship between the transaction and the resource and the occupation relationship between the resource and the transaction;

[0160] S502, checking the node set of the resource waiting graph to confirm whether the node set contains all transaction identifiers and resource identifiers;

[0161] S503, if there is a transaction identifier or resource identifier that is not included, create a transaction node corresponding to the transaction identifier or a resource node corresponding to the resource identifier, and add the transaction node or resource node to the node set of the resource waiting graph;

[0162] S504, adding a request edge from the transaction node to the resource node in the resource waiting graph according to the request relationship of the transaction to the resource, and recording the type and relationship of the request edge in the edge storage structure of the resource waiting graph;

[0163] S505 , according to the occupation relationship between the resource and the transaction, add an occupation edge pointing from the resource node to the transaction node in the resource waiting graph, and record the type and relationship of the occupation edge in the edge storage structure of the resource waiting graph.

[0164] In this embodiment, the transaction identifier and resource identifier are obtained from the state snapshot, and the request relationship and occupancy relationship between the transaction and the resource are read in sequence to ensure that all data are processed one by one.

[0165] Request relationship: Indicates that a transaction requests access to a resource.

[0166] Occupancy relationship: indicates that a resource is occupied by a transaction.

[0167] Use an iterator or loop structure to read the status snapshot one by one; extract the transaction identifier and resource identifier; parse the request relationship and occupancy relationship for each record to ensure data integrity.

[0168] Check whether there are corresponding transaction and resource nodes in the resource waiting graph to avoid duplicate creation; the node set is the set of existing nodes in the resource waiting graph, including transaction nodes and resource nodes.

[0169] Traverse the node set of the resource waiting graph; check whether the corresponding node already exists by comparing the current transaction identifier and resource identifier; mark the transaction identifier and resource identifier that are not included to provide a basis for subsequent operations.

[0170] For transaction identifiers and resource identifiers that are not included in the node set, new transaction nodes and resource nodes are created respectively; the created nodes are added to the resource waiting graph, and the node set is updated.

[0171] Create a node object for each transaction identifier and resource identifier; the node object contains basic properties, such as identifier, node type (transaction or resource), etc.; call the add node function of the resource wait graph to insert the node into the node collection.

[0172] The request edge is a directed edge in the resource waiting graph, which represents the transaction's request for resources; the type and relationship of the request edge indicate the specific nature of the request (such as a read or write request).

[0173] Traverse the request relationships of all transactions; find the corresponding transaction nodes and resource nodes in the resource waiting graph; create a request edge from the transaction node to the resource node, and record the attributes of the edge (type, relationship, etc.) in the edge storage structure; add the request edge to the edge set of the resource waiting graph.

[0174] The occupied edge is a directed edge in the resource waiting graph, indicating that the resource is occupied by the transaction; the type and relationship of the occupied edge indicate the specific situation of the occupation (such as lock type, occupied time, etc.).

[0175] Traverse the occupancy relationship of all resources; find the corresponding resource node and transaction node in the resource waiting graph; create an occupied edge from the resource node to the transaction node, and record the attributes of the edge (type, relationship, etc.) in the edge storage structure; add the occupied edge to the edge set of the resource waiting graph.

[0176] This embodiment analyzes the request and occupation relationships between transactions and resources in the state snapshot, accurately adds transaction nodes, resource nodes, request edges and occupation edges in the resource waiting graph, and realizes the dynamic update of resource dependencies. By utilizing the efficient management of node sets and edge storage structures, the construction speed and update performance of the resource waiting graph are greatly improved, providing a reliable foundation for subsequent deadlock detection.

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

[0178] S601, initializing the status of all nodes in the resource waiting graph to be unvisited, and setting a recursive stack to record node information of the current path;

[0179] S602, selecting a node in the resource waiting graph that is in an unvisited state as a starting node, and performing a depth-first search traversal in a recursive manner;

[0180] S603, in the depth-first search process, marking the state of the current node as being visited, visiting the connected nodes connected to the current node in sequence, and if it is detected that the connected nodes already exist in the recursive stack, determining that a loop exists;

[0181] S604: When all connected nodes of the current node have been visited, mark the state of the current node as visited, and remove the current node from the recursive stack.

[0182] In this embodiment, all nodes are initialized to an "unvisited" state to ensure that the traversal starts from an initial state without state interference; a recursive stack is set to record node information in the current path of the depth-first search (DFS) to facilitate determination of whether a loop is formed.

[0183] Traverse all nodes in the resource waiting graph and set their status to "unvisited"; initialize the recursive stack to an empty list or empty stack data structure; dynamically store the nodes in the current access path in the recursive stack for loop detection.

[0184] Select unvisited nodes as starting points to avoid repeated traversal; the recursive method is convenient for handling complex dependencies between nodes and adapting to loop detection.

[0185] Traverse the node set and find the node with the status of "unvisited"; call the recursive function to perform DFS traversal on the starting node: push the current node into the recursive stack; set the current node status to "visiting"; traverse the adjacent nodes of the current node and recursively call DFS.

[0186] Mark the node status as "being visited" to ensure that the current node is unique in the recursive path; if the connected node is already in the recursive stack, a loop is formed and the loop determination result is directly returned.

[0187] Traverse the adjacent nodes of the current node and check the status of each adjacent node: if the status is "unvisited", recursively call DFS; if the status is "visiting" and the node already exists in the recursive stack, determine that a loop exists; record the node sequence formed by the loop.

[0188] After all connected nodes of the current node have been visited, the node status is updated to "visited"; the current node is removed from the recursive stack to maintain the correctness of the recursive path.

[0189] In the recursive function, check whether all adjacent nodes of the current node have completed DFS; if all are completed, update the current node status to "visited"; pop the current node from the recursive stack and end the current recursive call.

[0190] This embodiment can quickly detect loops in the resource waiting graph and accurately locate the circular dependency between transactions and resources by performing a depth-first search traversal on all nodes in the resource waiting graph. The introduction of the recursive stack improves the accuracy of loop detection, and node state management ensures the efficiency of graph traversal, providing strong technical support for deadlock detection.

[0191] In one embodiment, in the above S70, if a loop is detected in the resource waiting graph, after determining that the transactions and resources involved in the loop constitute a deadlock, the method further includes:

[0192] S701, selecting at least one transaction to terminate based on transaction priority or impact scope to resolve the deadlock;

[0193] S702, performing a rollback operation on the terminated transaction to release occupied resources and restore the target database to a normal state;

[0194] S703: Record information on transaction termination and rollback operations during the deadlock resolution process according to the log level parameter.

[0195] In this embodiment, after a loop in the resource wait graph is detected, all transactions in the loop are involved in a deadlock. To resolve the deadlock, at least one transaction must be selected for termination.

[0196] Each transaction is prioritized based on business rules, importance, or other attributes. For example, a read transaction may have a lower priority than a write transaction, and a general query transaction may have a lower priority than a financial transfer transaction.

[0197] Impact scope refers to the possible consequences of terminating a transaction on the system, such as the possibility of data loss, the number of affected users, or the scope of system functions. Prioritize terminating transactions with smaller impact scopes.

[0198] The process of selecting transactions is to ensure the minimum impact on system performance and business functions by analyzing and comparing the priority or impact scope of transactions in the loop.

[0199] Obtain the identifiers of all transactions in the loop: extract the identifiers of all transaction nodes from the loop detection result of the resource wait graph.

[0200] Retrieve the priority and scope of impact of a transaction: Read the priority information of each transaction from the system configuration or transaction log; if the priority information is missing, infer the priority based on the transaction type (such as query, write operation); determine the scope of impact of the transaction by analyzing the resources affected by the transaction and the scope of associated user operations.

[0201] Compare transaction priorities and impact scope: sort by priority from low to high; if the priorities are the same, sort by impact scope from small to large.

[0202] Select the best transaction for termination: Select the transaction with the lowest priority or the smallest impact as the termination target; record the detailed information of the selection process to ensure that the selection logic is traceable.

[0203] After terminating a transaction, a rollback operation must be performed to undo some of the operations that have been executed by the transaction and release resources at the same time; ensure that the target database is in a consistent state after the rollback is completed. The resources released by the rollback can continue to be used by other transactions.

[0204] Call the rollback interface of the database: use the transaction identifier to send a rollback command to the database system; ensure that the rollback operation is executed synchronously with the transaction log record.

[0205] Release the resources occupied by the terminated transaction: During the rollback process, mark the resource status as "unoccupied"; add the released resources back to the available resource pool.

[0206] Check the recovery status of the target database: verify whether there are unreleased resources or data anomalies after the rollback; if there are problems, record the anomalies and trigger further processing.

[0207] Record the deadlock resolution process to facilitate problem review and system performance analysis; record content at different log levels: DEBUG: record the detailed logic of transaction priority and impact range analysis; INFO: record the transaction termination mark and rollback completion status.

[0208] Select the log record content: Determine the granularity of information to be recorded based on the current log level parameters;

[0209] Generate log content: including transaction identifier, selection basis, rollback status and other information; the DEBUG level may include detailed logic for analysis priority and impact scope.

[0210] Save logs: Write logs to files, databases, or other log management systems.

[0211] This embodiment can efficiently solve the deadlock problem by selecting the transaction to be terminated based on the transaction priority or impact scope strategy, and release resources and restore the database state in combination with the rollback operation, while minimizing the impact on system performance and business functions. The logging function provides a detailed basis for subsequent problem analysis and enhances the maintainability of the system.

[0212] In one embodiment, the above S80 includes:

[0213] S801, integrating the transaction status information, resource status information, information of transaction nodes and resource nodes in the loop, and occupation relationships and waiting relationships between transaction nodes and resource nodes to construct a dependency link graph between transactions and resources;

[0214] S802, based on the dependency link graph, analyzing the interaction path between the transaction and the resource, and determining the specific cause of the deadlock, wherein the specific cause includes a circular dependency between transactions or a resource being occupied by a transaction for a time exceeding a preset time threshold;

[0215] S803, determining a solution based on the specific cause, the solution including terminating a low-priority transaction, releasing resources whose occupied time exceeds a preset time threshold, or adjusting the execution priority of the transaction;

[0216] S804, generating an analysis report, wherein the analysis report includes detailed information of the transaction nodes and resource nodes, a dependency link diagram, a deadlock cause analysis, and a solution.

[0217] In this embodiment, all state information of transactions and resources is integrated, and the transaction nodes and resource nodes in the loop are associated with their relationship information to build a clear dependency link graph. The nodes of the dependency link graph represent transactions or resources, and the edges represent the request relationship or occupancy relationship between transactions and resources, which can intuitively display the dependency path related to deadlock.

[0218] Extract status information and relationship information: obtain transaction identification and status from transaction status information; obtain resource identification and status from resource status information; obtain dependency relationships between transaction nodes and resource nodes from loop detection results.

[0219] Construct a link graph data structure: Use graph theory to represent the dependency link graph, and use an adjacency list or adjacency matrix to represent the relationship between transactions and resources; add transaction nodes and resource nodes to the graph structure, and use occupancy relationships and request relationships as directed edges of the graph.

[0220] Integrate data into a link graph: add nodes and edges in sequence to form a complete dependency link graph; attach status information (such as transaction priority, resource status, etc.) to each node and edge in the graph.

[0221] By analyzing the interaction paths of the dependency graph, we can identify the key dependency points and deadlock causes between transactions and resources. The specific causes include:

[0222] Circular dependencies between transactions: There are loops between transactions, causing them to wait for each other;

[0223] Resources are occupied for a long time: A resource is occupied by a transaction for a period of time exceeding the preset time threshold, causing the resource to be unavailable.

[0224] Use depth-first search or breadth-first search to traverse the dependency graph; record the interaction between transactions and resources on each path. Find loops in the path to determine whether there are circular dependencies between transactions; if so, mark the nodes and edges in the loop as the cause of the deadlock. Check whether the resource occupancy time exceeds the preset threshold; if it times out, mark the relevant transactions and resources as the cause of the deadlock.

[0225] Determine the optimal solution based on the specific cause of the deadlock:

[0226] Terminate low-priority transactions: release resources occupied by low-priority transactions;

[0227] Release long-term occupied resources: force release of resources that have been occupied for a timeout period;

[0228] Adjust transaction execution priority: Dynamically increase the priority of key transactions to break the waiting cycle.

[0229] Obtain circular dependency nodes or timeout nodes from the dependency link graph; formulate processing strategies based on transaction priority or resource importance. Through priority sorting or impact range analysis, choose to terminate low-priority transactions or release timeout occupied resources; if there are no transactions suitable for termination, dynamically adjust transaction execution priorities. Record the selected solution and execution steps in the log to ensure subsequent traceability.

[0230] The generated analysis report summarizes all key information of the deadlock problem, allowing users to intuitively understand the problem and implement solutions. The report includes:

[0231] Detailed information: status, priority, occupied time, etc. of transaction nodes and resource nodes;

[0232] Dependency chain diagram: a diagram showing the dependency relationship between transactions and resources;

[0233] Deadlock cause analysis: Detailed description of circular dependency or timeout;

[0234] Solution: Suggested resolution steps and their rationale.

[0235] Extract information from dependency chain diagrams, deadlock cause analysis, and solutions; organize data in a structured form (table, diagram). Generate report documents using text processing tools or templates; report document formats support text, charts, and images embedded. Save reports to a specified storage location; support display through the user interface or send to administrators.

[0236] This embodiment integrates transaction and resource status information and dependency relationships, generates a dependency link diagram, and analyzes the cause of deadlock, which helps to quickly locate the source of the problem. Combined with the specific causes of circular dependencies and resource occupancy time, the optimal solution is formulated. The generated analysis report provides an intuitive display of key information and clear processing suggestions, which improves the efficiency of deadlock detection and resolution.

[0237] In one embodiment, after the above S80, the method further includes:

[0238] S901, sending the analysis report to the management module through the message notification module;

[0239] S902, displaying execution options of the solution in the analysis report in the management module through a user interface, wherein the execution options include terminating a transaction or releasing resources;

[0240] S903: Receive selection information of the execution option in the user interface, and execute a corresponding solution operation according to the selection information.

[0241] In this embodiment, after the analysis report is generated, the report is sent to the management module through the message notification module for subsequent display and operation; the message notification module can be implemented based on a message queue, event notification or network transmission protocol.

[0242] Organize the generated analysis report into structured data, such as JSON or XML format; ensure that the data contains the report title, key content, and solution summary. Use a message queue (such as RabbitMQ, Kafka) or HTTP interface to send messages to the management module; the message content includes the metadata and storage location (such as file path or database ID) of the analysis report. The message notification module returns the sending status; if the sending fails, record the failure reason and try again.

[0243] The user interface of the management module displays report content and solution execution options; the execution options provide administrators with operation guidance, mainly including specific steps to terminate transactions or release resources.

[0244] The management module retrieves the analysis report data according to the report storage location in the message notification; parses the data and loads it into the user interface. Dynamically generates execution option buttons or drop-down menus based on the solution content in the analysis report; options include operations such as terminating transactions and releasing resources, with a brief description of the additional operations. The interface layout is clear, including report details and solution options areas; basic interactive functions are provided, such as option selection and confirmation operations.

[0245] The user selects the execution option of the solution through the interface; the system receives the selection information and triggers the corresponding operation logic.

[0246] The user interface binds an event listener to each execution option; receives user selection information and records the selected options and operation parameters. Checks whether the selected option meets the solution scope of the current analysis report; returns an error prompt for operations that do not meet the conditions. If you choose to terminate the transaction, call the transaction management interface to terminate the selected transaction and release resources; if you choose to release resources, call the resource management module to update the resource status to "available". Record the time of operation execution, the selected options and their results; store the results in the log system for subsequent auditing.

[0247] In this embodiment, through the message notification module and the user interface, the analysis report can be quickly transmitted to the management module and displayed, and the user can intuitively view the report content and execute the solution. This method improves the efficiency of deadlock processing and the accuracy of operation, and provides comprehensive log records to support subsequent audits.

[0248] In one embodiment, a database deadlock detection and analysis device is provided, and the database deadlock detection and analysis device corresponds one-to-one to the database deadlock detection and analysis method in the above embodiment. Figure 3 , Figure 3 This is a functional module diagram of a preferred embodiment of the database deadlock detection and analysis device of the present invention. Configuration management module 10, database connection module 20, data acquisition module 30, graph data initialization module 40, graph construction module 50, loop detection module 60, deadlock determination module 70 and analysis report generation module 80. The functional modules are described in detail as follows:

[0249] The configuration management module 10 is used to load the configuration file of the deadlock detection module and extract the monitoring interval parameter and the log level parameter from the configuration file;

[0250] A database connection module 20, used to connect to a target database according to the target database information in the configuration file;

[0251] A data acquisition module 30, configured to periodically acquire transaction status information and resource status information in the target database through a database application program interface according to the monitoring interval parameter, and store the transaction status information and resource status information as a status snapshot;

[0252] A graph data initialization module 40, configured to initialize a data structure of a resource waiting graph according to the state snapshot;

[0253] A graph construction module 50, configured to add transaction nodes, resource nodes, request edges and occupied edges in the resource waiting graph according to the transaction identifiers, resource identifiers and the request and occupation relationship between the transaction and the resource contained in the state snapshot;

[0254] A loop detection module 60, configured to perform a depth-first search traversal on all nodes in the resource waiting graph to detect whether there is a loop in the resource waiting graph;

[0255] A deadlock determination module 70, for determining that the transactions and resources involved in the loop constitute a deadlock if a loop is detected in the resource waiting graph, and recording information of transaction nodes and resource nodes in the loop, occupation relationships between transaction nodes and resource nodes, and waiting relationships between transaction nodes;

[0256] The analysis report generation module 80 is used to generate an analysis report including a deadlock cause analysis and a solution based on the transaction status information, resource status information, information of the transaction nodes and resource nodes in the loop, the occupancy relationship between the transaction nodes and the resource nodes, and the waiting relationship between the transaction nodes.

[0257] In one embodiment, the graph data initialization module 40 is specifically used to:

[0258] Selecting a data structure of a resource waiting graph, and using an adjacency list or an adjacency matrix as a representation method of the resource waiting graph;

[0259] Allocate storage space for information of transaction nodes and resource nodes in the resource waiting graph according to the number of transaction identifiers and resource identifiers in the state snapshot, and initialize storage structures of transaction nodes and resource nodes;

[0260] Creating a mapping table of the transaction nodes and resource nodes, the mapping table being used to record a mapping relationship between a transaction identifier and a resource identifier and a corresponding node index in a resource waiting graph;

[0261] According to the log level parameter, detailed information of the resource wait graph initialization process is recorded, and the detailed information includes data structure type, number of nodes and storage space size.

[0262] In one embodiment, the graph construction module 50 is specifically configured to:

[0263] Traversing all transaction identifiers and resource identifiers recorded in the state snapshot, and reading the request relationship between the transaction and the resource and the occupation relationship between the resource and the transaction one by one;

[0264] Checking the node set of the resource waiting graph to confirm whether the node set contains all transaction identifiers and resource identifiers;

[0265] If there is a transaction identifier or resource identifier that is not included, a transaction node corresponding to the transaction identifier or a resource node corresponding to the resource identifier is created respectively, and the transaction node or resource node is added to the node set of the resource waiting graph;

[0266] According to the request relationship of the transaction to the resource, a request edge pointing from the transaction node to the resource node is added in the resource waiting graph, and the type and relationship of the request edge are recorded in the edge storage structure of the resource waiting graph;

[0267] According to the occupation relationship between the resource and the transaction, an occupation edge pointing from the resource node to the transaction node is added in the resource waiting graph, and the type and relationship of the occupation edge are recorded in the edge storage structure of the resource waiting graph.

[0268] In one embodiment, the loop detection module 60 is specifically configured to:

[0269] Initialize the states of all nodes in the resource waiting graph to be unvisited, and set a recursive stack to record node information of the current path;

[0270] Selecting a node in the resource waiting graph that is in an unvisited state as a starting node, and recursively performing a depth-first search traversal;

[0271] In the depth-first search process, the state of the current node is marked as being visited, and the connected nodes connected to the current node are visited in sequence. If it is detected that the connected nodes already exist in the recursive stack, it is determined that a loop exists;

[0272] When all connected nodes of the current node have been visited, the state of the current node is marked as visited, and the current node is removed from the recursive stack.

[0273] In one embodiment, the deadlock determination module 70 is specifically configured to:

[0274] Select at least one transaction to terminate based on transaction priority or impact scope to resolve the deadlock;

[0275] Perform a rollback operation on the terminated transaction to release the occupied resources and restore the normal state of the target database;

[0276] Information on transaction termination and rollback operations during the deadlock resolution process is recorded according to the log level parameter.

[0277] In one embodiment, the analysis report generating module 80 is specifically used to:

[0278] Integrate the transaction status information, resource status information, information of transaction nodes and resource nodes in the loop, and occupation relationship and waiting relationship between transaction nodes and resource nodes to construct a dependency link graph between transactions and resources;

[0279] Based on the dependency link graph, the interaction path between the transaction and the resource is analyzed to determine the specific cause of the deadlock, wherein the specific cause includes a circular dependency between transactions or a resource being occupied by a transaction for a time exceeding a preset time threshold;

[0280] Determine a solution based on the specific cause, the solution including terminating a low-priority transaction, releasing resources whose occupancy time exceeds a preset time threshold, or adjusting the execution priority of the transaction;

[0281] An analysis report is generated, which includes detailed information of transaction nodes and resource nodes, a dependency link graph, deadlock cause analysis, and a solution.

[0282] In one embodiment, the analysis report generating module 80 is specifically used to:

[0283] Sending the analysis report to the management module through the message notification module;

[0284] Displaying execution options of the solution in the analysis report in the management module through a user interface, wherein the execution options include terminating a transaction or releasing resources;

[0285] The selection information of the execution option is received in the user interface, and a corresponding solution operation is performed according to the selection information.

[0286] 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 4 As 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 deadlock detection and analysis method server side.

[0287] 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 deadlock detection and analysis method

[0288] 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 when the processor executes the computer program, the following steps are implemented:

[0289] Loading a configuration file of a deadlock detection module, and extracting a monitoring interval parameter and a log level parameter from the configuration file;

[0290] Connecting to the target database according to the target database information in the configuration file;

[0291] According to the monitoring interval parameter, periodically acquiring the state information of the transaction and the state information of the resource in the target database through the database application program interface, and storing the state information of the transaction and the state information of the resource as a state snapshot;

[0292] Initialize a data structure of a resource waiting graph according to the state snapshot;

[0293] According to the transaction identifier, resource identifier and the request and occupation relationship between the transaction and the resource contained in the state snapshot, adding a transaction node, a resource node, a request edge and an occupation edge in the resource waiting graph;

[0294] Performing a depth-first search traversal on all nodes in the resource waiting graph to detect whether there is a loop in the resource waiting graph;

[0295] If a loop is detected in the resource waiting graph, it is determined that the transactions and resources involved in the loop constitute a deadlock, and information of transaction nodes and resource nodes in the loop, occupation relationships between transaction nodes and resource nodes, and waiting relationships between transaction nodes are recorded;

[0296] Based on the transaction status information, resource status information, information of transaction nodes and resource nodes in the loop, occupation relationship between transaction nodes and resource nodes, and waiting relationship between transaction nodes, an analysis report including deadlock cause analysis and solutions is generated.

[0297] 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:

[0298] Loading a configuration file of a deadlock detection module, and extracting a monitoring interval parameter and a log level parameter from the configuration file;

[0299] Connecting to the target database according to the target database information in the configuration file;

[0300] According to the monitoring interval parameter, periodically acquiring the state information of the transaction and the state information of the resource in the target database through the database application program interface, and storing the state information of the transaction and the state information of the resource as a state snapshot;

[0301] Initialize a data structure of a resource waiting graph according to the state snapshot;

[0302] According to the transaction identifier, resource identifier and the request and occupation relationship between the transaction and the resource contained in the state snapshot, adding a transaction node, a resource node, a request edge and an occupation edge in the resource waiting graph;

[0303] Performing a depth-first search traversal on all nodes in the resource waiting graph to detect whether there is a loop in the resource waiting graph;

[0304] If a loop is detected in the resource waiting graph, it is determined that the transactions and resources involved in the loop constitute a deadlock, and information of transaction nodes and resource nodes in the loop, occupation relationships between transaction nodes and resource nodes, and waiting relationships between transaction nodes are recorded;

[0305] Based on the transaction status information, resource status information, information of transaction nodes and resource nodes in the loop, occupation relationship between transaction nodes and resource nodes, and waiting relationship between transaction nodes, an analysis report including deadlock cause analysis and solutions is generated.

[0306] 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.

[0307] 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).

[0308] 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.

[0309] 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.< / database> < / port> < / host> < / database> < / port> < / host>

Claims

1. A database deadlock detection and analysis method, characterized in that: The following steps are involved: Loading a configuration file of a deadlock detection module, and extracting a monitoring interval parameter and a log level parameter from the configuration file; Connecting to the target database according to the target database information in the configuration file; According to the monitoring interval parameter, periodically acquiring the state information of the transaction and the state information of the resource in the target database through the database application program interface, and storing the state information of the transaction and the state information of the resource as a state snapshot; Initialize a data structure of a resource waiting graph according to the state snapshot; According to the transaction identifier, resource identifier and the request and occupation relationship between the transaction and the resource contained in the state snapshot, adding a transaction node, a resource node, a request edge and an occupation edge in the resource waiting graph; Performing a depth-first search traversal on all nodes in the resource waiting graph to detect whether there is a loop in the resource waiting graph; If a loop is detected in the resource waiting graph, it is determined that the transactions and resources involved in the loop constitute a deadlock, and information of transaction nodes and resource nodes in the loop, occupation relationships between transaction nodes and resource nodes, and waiting relationships between transaction nodes are recorded; Based on the transaction status information, resource status information, information of transaction nodes and resource nodes in the loop, occupation relationship between transaction nodes and resource nodes, and waiting relationship between transaction nodes, an analysis report including deadlock cause analysis and solutions is generated.

2. The database deadlock detection and analysis method according to claim 1, characterized in that: Initializing the data structure of the resource waiting graph according to the state snapshot includes: Selecting a data structure of a resource waiting graph, and using an adjacency list or an adjacency matrix as a representation method of the resource waiting graph; Allocate storage space for information of transaction nodes and resource nodes in the resource waiting graph according to the number of transaction identifiers and resource identifiers in the state snapshot, and initialize storage structures of transaction nodes and resource nodes; Creating a mapping table of the transaction nodes and resource nodes, the mapping table being used to record a mapping relationship between a transaction identifier and a resource identifier and a corresponding node index in a resource waiting graph; According to the log level parameter, detailed information of the resource wait graph initialization process is recorded, and the detailed information includes data structure type, number of nodes and storage space size.

3. The database deadlock detection and analysis method according to claim 1, characterized in that: According to the transaction identifier, resource identifier and the transaction request and occupation relationship of resources contained in the state snapshot, adding transaction nodes, resource nodes, request edges and occupation edges in the resource waiting graph includes: Traversing all transaction identifiers and resource identifiers recorded in the state snapshot, and reading the request relationship between the transaction and the resource and the occupation relationship between the resource and the transaction one by one; Checking the node set of the resource waiting graph to confirm whether the node set contains all transaction identifiers and resource identifiers; If there is a transaction identifier or resource identifier that is not included, a transaction node corresponding to the transaction identifier or a resource node corresponding to the resource identifier is created respectively, and the transaction node or resource node is added to the node set of the resource waiting graph; According to the request relationship of the transaction to the resource, add a request edge pointing from the transaction node to the resource node in the resource waiting graph, and record the type and relationship of the request edge in the edge storage structure of the resource waiting graph; According to the occupation relationship between the resource and the transaction, an occupation edge pointing from the resource node to the transaction node is added in the resource waiting graph, and the type and relationship of the occupation edge are recorded in the edge storage structure of the resource waiting graph.

4. The database deadlock detection and analysis method according to claim 1, characterized in that: Performing a depth-first search traversal on all nodes in the resource waiting graph to detect whether there is a loop in the resource waiting graph includes: Initialize the states of all nodes in the resource waiting graph to be unvisited, and set a recursive stack to record node information of the current path; Selecting a node in the resource waiting graph that is in an unvisited state as a starting node, and recursively performing a depth-first search traversal; In the depth-first search process, the state of the current node is marked as being visited, and the connected nodes connected to the current node are visited in sequence. If it is detected that the connected nodes already exist in the recursive stack, it is determined that a loop exists; When all connected nodes of the current node have been visited, the state of the current node is marked as visited, and the current node is removed from the recursive stack.

5. The database deadlock detection and analysis method according to claim 1, characterized in that: If a loop is detected in the resource waiting graph, after determining that the transactions and resources involved in the loop constitute a deadlock, the method further includes: Select at least one transaction to terminate based on transaction priority or impact scope to resolve the deadlock; Perform a rollback operation on the terminated transaction to release the occupied resources and restore the normal state of the target database; Information on transaction termination and rollback operations during the deadlock resolution process is recorded according to the log level parameter.

6. The database deadlock detection and analysis method according to claim 1, characterized in that: Based on the transaction status information, resource status information, information of transaction nodes and resource nodes in the loop, occupation relationship between transaction nodes and resource nodes, and waiting relationship between transaction nodes, an analysis report including deadlock cause analysis and solutions is generated, including: Integrate the transaction status information, resource status information, information of transaction nodes and resource nodes in the loop, and occupation relationship and waiting relationship between transaction nodes and resource nodes to construct a dependency link graph between transactions and resources; Based on the dependency link graph, the interaction path between the transaction and the resource is analyzed to determine the specific cause of the deadlock, wherein the specific cause includes a circular dependency between transactions or a resource being occupied by a transaction for a time exceeding a preset time threshold; Determine a solution based on the specific cause, the solution including terminating a low-priority transaction, releasing resources whose occupancy time exceeds a preset time threshold, or adjusting the execution priority of the transaction; An analysis report is generated, which includes detailed information of transaction nodes and resource nodes, a dependency link graph, deadlock cause analysis, and a solution.

7. The database deadlock detection and analysis method as claimed in claim 1, characterized in that: After generating an analysis report including a deadlock cause analysis and a solution based on the transaction status information, resource status information, information of the transaction nodes and resource nodes in the loop, and the occupation relationship and waiting relationship between the transaction nodes and the resource nodes, the method further includes: Sending the analysis report to the management module through the message notification module; Displaying execution options of the solution in the analysis report in the management module through a user interface, wherein the execution options include terminating a transaction or releasing resources; The selection information of the execution option is received in the user interface, and a corresponding solution operation is performed according to the selection information.

8. A database deadlock detection and analysis device, characterized in that: The database deadlock detection and analysis device comprises: A configuration management module, used for loading a configuration file of a deadlock detection module and extracting a monitoring interval parameter and a log level parameter from the configuration file; A database connection module, used to connect to a target database according to the target database information in the configuration file; A data acquisition module, used for periodically acquiring the transaction status information and resource status information of the target database through a database application program interface according to the monitoring interval parameter, and storing the transaction status information and resource status information as a status snapshot; A graph data initialization module, used to initialize the data structure of the resource waiting graph according to the state snapshot; A graph construction module, configured to add transaction nodes, resource nodes, request edges and occupied edges in the resource waiting graph according to the transaction identifiers, resource identifiers and the request and occupation relationship between transactions and resources contained in the state snapshot; A loop detection module, used for performing a depth-first search traversal on all nodes in the resource waiting graph to detect whether there is a loop in the resource waiting graph; A deadlock determination module, for determining that the transactions and resources involved in the loop constitute a deadlock if a loop is detected in the resource waiting graph, and recording information of transaction nodes and resource nodes in the loop, occupation relationships between transaction nodes and resource nodes, and waiting relationships between transaction nodes; An analysis report generation module is used to generate an analysis report including a deadlock cause analysis and a solution based on the transaction status information, resource status information, information of the transaction nodes and resource nodes in the loop, the occupancy relationship between the transaction nodes and the resource nodes, and the waiting relationship between the transaction nodes.

9. A computer device, characterized in that: The computer device includes a memory, a processor, and a database deadlock detection and analysis program stored in the memory and executable on the processor. When the database deadlock detection and analysis program is executed by the processor, the steps of the database deadlock detection and analysis 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 deadlock detection and analysis program, which, when executed by a processor, implements the steps of the database deadlock detection and analysis method according to any one of claims 1 to 7.

Images