Fault analysis method and device for database, equipment and storage medium

Abstract

The invention discloses a database fault analysis method and device, equipment and a storage medium. The method comprises the following steps: firstly, determining a service request corresponding to each SQL statement in a target database, and obtaining a plurality of service elements of the service request corresponding to the SQL statement; integrating the plurality of business elements into business labels, labeling the business labels on the corresponding SQL statements, and obtaining execution metadata of each SQL statement. And for each SQL statement in the target database, performing fault analysis on the SQL statements based on the service labels and the execution metadata of the SQL statements. According to the method, each SQL statement is associated with the service request, and the service elements are integrated and labeled on the SQL statements, so that the service meanings behind the SQL statements can be better understood, the root cause of the fault can be more accurately positioned and understood, and the fault analysis is performed based on the service labels and the execution metadata of the SQL statements, so that the fault analysis efficiency is improved. And the accuracy of troubleshooting can also be improved.

Description

Technical Field

[0001] The present application relates to the field of database technology, and in particular to a database fault analysis method, device, equipment and storage medium. Background Art

[0002] In recent years, with the rapid development of Internet technology, online business has begun to develop on a large scale. In order to cope with the strong traffic demand during business peak periods, various information systems have adopted a distributed architecture to carry high loads. However, under this distributed architecture, due to the large number of microservices and long call links, a complex transaction request link is formed. In actual operation, the microservices of current distributed systems usually need to access different distributed databases. As a result, the operation relationship of a request in different databases becomes unclear. When a request encounters an exception during processing, the use of conventional full-link tracking and analysis tools (such as sleuth+Zipkin) can only locate the specific database operation steps where the problem occurs, and then manual intervention is performed for further analysis, but the root cause of the exception cannot be quickly located. This limitation makes the problem troubleshooting and troubleshooting process complicated and time-consuming.

[0003] Therefore, how to quickly locate and diagnose the root cause of abnormalities in complex transaction request links in distributed systems to reduce the time for problem troubleshooting and troubleshooting is a technical problem that technical personnel in this field urgently need to solve. Summary of the invention

[0004] Based on the above problems, the present application provides a database fault analysis method, device, equipment and storage medium, which can quickly locate and diagnose the root cause of abnormalities in complex transaction request links in distributed systems, so as to reduce the time for problem investigation and fault resolution.

[0005] The embodiments of the present application disclose the following technical solutions:

[0006] A method for analyzing a database failure, the method comprising:

[0007] Determine the business request corresponding to each structured query language SQL statement in the target database, and obtain multiple business elements of the business request corresponding to the SQL statement;

[0008] Integrate the multiple business elements into business tags and annotate them on the corresponding SQL statements, and obtain execution metadata of each SQL statement;

[0009] For each SQL statement in the target database, a fault analysis is performed on the SQL statement based on the service tag and execution metadata of the SQL statement.

[0010] In a possible implementation, for each SQL statement in the target database, performing fault analysis on the SQL statement based on the service tag and execution metadata of the SQL statement includes:

[0011] Dividing the SQL statements in the target database based on the business request unique identifiers of all the business requests in the target database to obtain a plurality of first SQL statement groups;

[0012] For each first SQL statement group, calculate the average execution time of each SQL statement in the first SQL statement group;

[0013] Based on the average execution time of each SQL statement in the first SQL statement group and the execution metadata, an abnormal SQL statement is determined.

[0014] In a possible implementation, the performing fault analysis on each SQL statement in the target database based on the service tag and execution metadata of the SQL statement further includes:

[0015] Counting the types of business request transactions in the target database;

[0016] Dividing the SQL statements in the target database based on the business request transaction type to obtain a plurality of second SQL statement groups;

[0017] For each second SQL statement group, calculate the average execution time of each SQL statement in the second SQL statement group;

[0018] Based on the average execution time of each SQL statement in the second SQL statement group and the execution metadata, an abnormal SQL statement is determined.

[0019] In a possible implementation, it is characterized in that the execution metadata includes at least one or both of execution time consumption and execution error information.

[0020] In a possible implementation, the determining the abnormal SQL statement based on the average execution time of each SQL statement in the first SQL statement group and the execution metadata includes:

[0021] If the average execution time of the SQL statement is greater than the time threshold, it is determined that the SQL statement is abnormal; the average execution time of the SQL statement is calculated based on the execution time of the SQL statement;

[0022] If the execution metadata of the SQL statement includes the execution error information, it is determined that an exception exists in the SQL statement.

[0023] In a possible implementation, the multiple business elements include at least a business request transaction name, a business request unique identifier, a business request channel source, a business request start time, and a business request tracking identifier ID.

[0024] A database fault analysis device, the device comprising:

[0025] A business request determination unit, used to determine the business request corresponding to each SQL statement in the target database;

[0026] A first acquisition unit, used to acquire multiple business elements of a business request corresponding to an SQL statement;

[0027] A business label marking unit, used to integrate the multiple business elements into business labels and mark them on the corresponding SQL statements;

[0028] A second acquisition unit, used to acquire execution metadata of each SQL statement;

[0029] The fault analysis unit is used to perform fault analysis on each SQL statement in the target database based on the service label and execution metadata of the SQL statement.

[0030] In a possible implementation, the fault analysis unit specifically includes:

[0031] A first statement division unit, configured to divide the SQL statements in the target database based on the business request unique identifiers of all the business requests in the target database to obtain a plurality of first SQL statement groups;

[0032] A first average execution time calculation unit, configured to calculate, for each first SQL statement group, an average execution time of each SQL statement in the first SQL statement group;

[0033] The first abnormal statement determining unit is used to determine an abnormal SQL statement based on the average execution time of each SQL statement in the first SQL statement group and the execution metadata.

[0034] A database fault analysis device comprises: a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the database fault analysis method as described above is implemented.

[0035] A computer-readable storage medium stores instructions, and when the instructions are executed on a terminal device, the terminal device executes the database fault analysis method as described above.

[0036] Compared with the prior art, this application has the following beneficial effects:

[0037] The present application provides a method, device, equipment and storage medium for fault analysis of a database. Specifically, when executing the fault analysis method of the database provided in the embodiment of the present application, firstly, by determining the business request corresponding to each structured query language (SQL) statement in the target database, and obtaining multiple business elements of the business request corresponding to the SQL statement, a direct connection between the SQL statement and the specific business operation is established. Next, these business elements are integrated into business tags and annotated on the corresponding SQL statement, so that the business background behind each SQL statement can be quickly identified and understood in subsequent analysis. At the same time, the execution metadata of each SQL statement is obtained to further enrich the information of the SQL statement. Finally, for each SQL statement in the target database, a detailed fault analysis is performed based on its business tag and execution metadata, so that the specific abnormal operation steps can be accurately located. The present application can better understand the business meaning behind the SQL statement by associating each SQL statement with the business request and integrating the business elements and annotating them on the SQL statement. This can help more accurately locate and understand the root cause of the fault, not just the operation steps. At the same time, fault analysis based on the business tag and execution metadata of the SQL statement can improve the accuracy of troubleshooting. Combining business perspectives with technical implementations helps locate and resolve problems more quickly. In addition, compared to traditional methods that require a lot of manual intervention for further analysis, this method can perform fault analysis more automatically. By integrating business elements and metadata, the time and complexity of manual involvement can be reduced. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] In order to more clearly illustrate the technical solutions in this embodiment or the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0039] Figure 1 A method flow chart of a database fault analysis method provided in an embodiment of the present application;

[0040] Figure 2 A method flow chart of a method for analyzing a fault of an SQL statement provided in an embodiment of the present application;

[0041] Figure 3 A method flow chart of another method for analyzing a fault of an SQL statement provided in an embodiment of the present application;

[0042] Figure 4 A schematic diagram of the structure of a database fault analysis device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0043] To facilitate understanding of the technical solutions provided by the embodiments of the present application, the background technology involved in the embodiments of the present application will be described below.

[0044] In recent years, with the development of Internet technology, online business has begun to develop on a large scale. In order to cope with business peaks, various information systems adopt distributed architecture to carry high traffic. However, under the distributed architecture, the number of microservices increases and the call chain becomes longer, making the transaction request link complicated. Microservices in current distributed systems usually need to access distributed databases, which makes the operational relationship of a request in different databases unclear. When an exception occurs in a request, with the help of conventional full-link tracking and analysis tools (such as sleuth+Zipkin), it is only possible to locate which database operation has failed. At this time, manual intervention analysis is required, which makes it impossible to quickly and accurately locate the root cause of the exception.

[0045] In order to solve this problem, a method, device, equipment and storage medium for fault analysis of a database are provided in an embodiment of the present application. First, by determining the business request corresponding to each SQL statement in the target database and collecting multiple business elements related to the SQL statement, an effective association bridge is established. This step not only enables us to accurately understand the specific business requirements represented by each SQL statement, but also lays the foundation for subsequent fault analysis. Secondly, the collected multiple business elements are integrated and summarized, and annotated on the corresponding SQL statement in the form of business tags. This measure helps to more clearly identify the business background and key factors involved in the SQL statement, thereby providing a more comprehensive and accurate business perspective for subsequent fault analysis. At the same time, obtaining the execution metadata of each SQL statement also provides key execution information and indicators for database fault analysis. Finally, on the basis of obtaining the business tag and execution metadata of the SQL statement, a fault analysis is carried out for each SQL statement in the target database. By combining the business tag and execution metadata, the execution of the SQL statement and the impact on the business can be examined more deeply, and then the potential fault problems can be quickly and accurately located and solved. The present application associates each SQL statement with the business request, and integrates the business elements and annotates them on the SQL statement, which helps to more deeply understand the business meaning behind the SQL statement. This approach can not only help locate and understand the root cause of the fault more accurately, rather than just focusing on the operation steps. At the same time, fault analysis based on the business tags and execution metadata of SQL statements will improve the accuracy of troubleshooting. By organically combining business perspectives with technical implementations, problems can be located and solved more quickly, making the fault handling process more effective and efficient.

[0046] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0047] See also Figure 1 , which is a method flow chart of a database fault analysis method provided in an embodiment of the present application, such as Figure 1 As shown, the database fault analysis method may include steps S101-S103:

[0048] S101: Determine a business request corresponding to each SQL statement in a target database, and obtain multiple business elements of the business request corresponding to the SQL statement.

[0049] Determine the business request corresponding to each SQL statement in the target database. For example, in a bank, it may be a transaction operation such as withdrawing money, which means associating the SQL statement with the specific business operation. Obtaining multiple business elements of the business request corresponding to the SQL statement is to understand and capture the details and characteristics of the business operation from multiple perspectives.

[0050] To determine the business request corresponding to each SQL statement in the target database and obtain the multiple business elements corresponding to the SQL statement, you first need to clarify the specific functions or operations that each SQL statement is responsible for performing in the system. By reviewing the business logic and requirements documents of the system, you can help understand the role of each SQL statement. Secondly, analyze the structure and content of the SQL statement to identify the data tables, fields, and operation types involved. In addition, with the help of database logs or monitoring systems, you can track the execution of SQL statements to understand their actual impact and results. Finally, communicate and collaborate with business-related teams or domain experts to ensure that the understanding of business requests and business elements is accurate. By combining these methods, you can effectively determine the business request corresponding to each SQL statement and obtain the relevant business elements.

[0051] In a possible implementation, the multiple business elements include at least a business request transaction name, a business request unique identifier, a business request channel source, a business request start time, and a business request tracking identifier (Identification, ID).

[0052] Business request transaction name (trCode): indicates the transaction code corresponding to the request, for example, S0001.

[0053] Service request unique identifier (reqSeq): represents the unique identifier of the service request, for example, s0000001.

[0054] Business request channel source (channel): indicates the source channel of the request, such as MBNK.

[0055] Business request start time (reqTime): indicates the timestamp when the request starts, for example, 20230825163400000.

[0056] Business request trace ID (traceId): indicates the trace ID of the request, used for full-link tracing, for example, s0000990213821380912.

[0057] S102: Integrate the multiple business elements into business tags and annotate them on the corresponding SQL statements, and obtain execution metadata of each SQL statement.

[0058] By integrating multiple business elements into business tags, the specific business meaning, operation purpose, and business rules involved in SQL statements can be clearly expressed, and these tags can be directly attached to the corresponding SQL statements for subsequent analysis and tracking. This helps to closely link database operations with business needs, making SQL statements more readable and easy to understand. At the same time, the execution metadata of each SQL statement, including data such as execution time and execution error information, can provide important reference information about the execution of SQL statements. Execution time can help evaluate the performance and efficiency of SQL statements and locate potential performance bottlenecks; while execution error information can help quickly discover problems, identify abnormal situations, and further optimize database operations. Combining business tags and execution metadata can not only provide a more comprehensive understanding of the actual operation of SQL statements, but also better track and analyze the relationship between the business logic and technical execution of database operations, thereby providing more effective support and guidance for subsequent troubleshooting and performance optimization.

[0059] In a possible implementation, obtaining the execution metadata of each SQL statement can be accomplished in the following manner:

[0060] Execution time information: records the execution time of each SQL statement, including the time interval from the start to the end of execution, to evaluate the execution efficiency of SQL statements.

[0061] Execution error information: Captures error information that may occur during the execution of SQL statements, including syntax errors, connection problems, or data anomalies, to help diagnose problems and perform troubleshooting.

[0062] By integrating business elements into business tags and obtaining SQL statement execution metadata, we can more comprehensively understand the business content and execution status of SQL statements, which helps improve system performance and stability, and conduct fault analysis and optimization more effectively. This approach can provide in-depth business insights and make database operations more transparent, traceable, and manageable.

[0063] In a possible implementation manner, the method further includes: marking the service tag at the head of the corresponding SQL statement.

[0064] S103: For each SQL statement in the target database, perform fault analysis on the SQL statement based on the service tag and execution metadata of the SQL statement.

[0065] For each SQL statement in the target database, fault analysis based on the business tag and execution metadata of the SQL statement means using the business-related information of the SQL statement and the data records during the execution process to conduct in-depth research and analysis on problems, exceptions or errors that may occur during the execution of the SQL statement.

[0066] Through the business tags of SQL statements, you can understand the specific business operations and requirements they represent. This helps to focus fault analysis more on problems in actual business logic, rather than just the technical execution process. Business tags can provide important clues about the intent and purpose behind SQL statements, making fault analysis more targeted and comprehensive. Combined with execution metadata, including data on execution time and execution error information, you can gain an in-depth understanding of the performance of SQL statements during execution. By analyzing execution time, you can discover potential performance bottlenecks or reasons for inefficiency; and through execution error information, you can locate possible error types, abnormal conditions, or reasons for failure. These data provide valuable basis and clues for fault analysis, helping to quickly identify and resolve problems in SQL statement execution.

[0067] By comprehensively considering the business tags and execution metadata of SQL statements, fault analysis can help you understand the execution process of SQL queries more comprehensively, identify potential problems, and provide corresponding treatment and improvements. This approach not only helps improve system stability and performance, but also optimizes database operation processes to ensure that the system can run effectively and meet business needs.

[0068] See also Figure 2 , Figure 2 A method flow chart of a method for analyzing a fault of an SQL statement provided in an embodiment of the present application. Accordingly, step S103 performs fault analysis on each SQL statement in the target database based on the business tag and execution metadata of the SQL statement, which can be implemented through steps A1-A3:

[0069] A1: Divide the SQL statements in the target database based on the business request unique identifiers of all the business requests in the target database to obtain multiple first SQL statement groups.

[0070] In step A1, the SQL statements in the target database are divided according to the unique business request identifiers of all business requests in the target database to form multiple first SQL statement groups. This step is intended to aggregate SQL statements with the same or related business request identifiers together for more detailed analysis and processing later.

[0071] A2: For each first SQL statement group, calculate the average execution time of each SQL statement in the first SQL statement group.

[0072] In step A2, for each first SQL statement group, the average execution time of each SQL statement in the group is calculated. By calculating the average execution time, the execution efficiency of each SQL statement in the group can be understood, which helps to find potential performance bottlenecks or optimization space.

[0073] For example, assuming that a SQL statement is executed N times at different time points, and the execution time is T1, T2, ..., TN respectively, then the average execution time of the SQL statement is:

[0074] Average execution time = (T1+T2+…+TN) / N.

[0075] A3: Based on the average execution time of each SQL statement in the first SQL statement group and the execution metadata, determine the abnormal SQL statement.

[0076] Finally, in step A3, the average execution time and execution metadata of each SQL statement in each first SQL statement group are combined to determine whether there are abnormal SQL statements. By comparing the average execution time and execution metadata, SQL statements with low execution efficiency, frequent errors or other abnormal situations can be identified. Such an analysis process helps to accurately locate SQL statements that may have problems, providing guidance and support for subsequent troubleshooting and performance optimization.

[0077] In a possible implementation, the determining the abnormal SQL statement based on the average execution time of each SQL statement in the first SQL statement group and the execution metadata includes:

[0078] If the average execution time of the SQL statement is greater than the time threshold, it is determined that the SQL statement is abnormal; the average execution time of the SQL statement is calculated based on the execution time of the SQL statement;

[0079] If the execution metadata of the SQL statement includes the execution error information, it is determined that an exception exists in the SQL statement.

[0080] It should be noted that the process of "determining the existence of abnormal SQL statements based on the average execution time of each SQL statement in the second SQL statement group and the execution metadata" is similar to the process of "determining the existence of abnormal SQL statements based on the average execution time of each SQL statement in the first SQL statement group and the execution metadata", and will not be repeated later.

[0081] See also Figure 3 , Figure 3 A method flow chart of another method for analyzing a fault of an SQL statement provided in an embodiment of the present application. Accordingly, step S103 performs fault analysis on each SQL statement in the target database based on the business tag and execution metadata of the SQL statement, which can also be implemented through steps B1-B4:

[0082] B1: Counting the types of business request transactions in the target database.

[0083] In step B1, business request transaction types in the target database are counted. This step can help understand the distribution of different transaction types, which will help to better organize and manage SQL statements in the database in the future.

[0084] In a possible implementation, the business request transaction type may be, but is not limited to:

[0085] Deposit Transaction: A transaction in which a customer deposits funds into his or her bank account;

[0086] Withdrawal transaction: a transaction in which a customer withdraws cash from a bank account;

[0087] Transfer transaction: a transaction in which a customer transfers funds between different accounts, which can be transfers within the same bank or between banks;

[0088] Payment transactions: transactions where customers use online banking or mobile banking apps to pay for bills or purchases;

[0089] Loan application transactions: transactions where a customer applies for a loan or line of credit from a bank;

[0090] Interest settlement transactions: transactions in which banks calculate and settle interest based on customer deposit account balances or loans;

[0091] Account enquiry transactions: transactions where customers use ATMs, online banking or mobile banking applications to check their account balances or transaction details;

[0092] Remittance transactions: transactions where a customer transfers money internationally or to another person;

[0093] Check deposit and withdrawal transactions: transactions in which customers deposit or withdraw checks;

[0094] Card loss report transaction: a transaction in which a customer reports a bank card or credit card lost;

[0095] These are examples of common business request transaction types in banking, and banks process these different types of transactions to meet customer needs and provide various financial services.

[0096] B2: Divide the SQL statements in the target database based on the business request transaction type to obtain multiple second SQL statement groups.

[0097] In step B2, the SQL statements in the target database are divided according to the business request transaction type to form multiple second SQL statement groups. Organizing SQL statements according to transaction type can make subsequent analysis more accurate and targeted.

[0098] B3: For each second SQL statement group, calculate the average execution time of each SQL statement in the second SQL statement group.

[0099] In step B3, for each second SQL statement group, the average execution time of each SQL statement in the group is calculated. By calculating the average execution time, the execution efficiency of SQL statements under different transaction types can be evaluated, and potential performance problems or optimization space can be discovered.

[0100] B4: Determine an abnormal SQL statement based on the average execution time of each SQL statement in the second SQL statement group and the execution metadata.

[0101] Finally, in step B4, the average execution time and execution metadata of each SQL statement in each second SQL statement group are combined to determine whether there are abnormal SQL statements. By comparing the average execution time and execution metadata, SQL statements with low execution efficiency and frequent abnormalities can be identified, so as to carry out targeted troubleshooting and performance optimization. This process helps to improve system stability and performance and ensure that database operations meet business needs.

[0102] Based on the contents of S101-S103, it can be known that the direct connection between the SQL statement and the specific business operation is established by first determining the business request corresponding to each SQL statement in the target database and obtaining multiple business elements of the business request corresponding to the SQL statement. Next, these business elements are integrated into business tags and annotated on the corresponding SQL statements so that the business background behind each SQL statement can be quickly identified and understood in subsequent analysis. At the same time, the execution metadata of each SQL statement is obtained to further enrich the information of the SQL statement. Finally, for each SQL statement in the target database, a detailed fault analysis is performed based on its business tags and execution metadata, so that the specific abnormal operation steps can be accurately located and the efficiency and accuracy of troubleshooting can be improved. This application can better understand the business meaning behind the SQL statement by associating each SQL statement with a specific business request and integrating multiple business elements and annotating them on the SQL statement. This method not only helps to locate and understand the root cause of the fault more accurately, but also provides more comprehensive context information. Fault analysis based on the business tags and execution metadata of SQL statements can significantly improve the accuracy of troubleshooting. In this way, operation and maintenance personnel can not only quickly find the specific SQL statement with the problem, but also gain in-depth understanding of the business background and requirements corresponding to the operation, so as to more comprehensively assess the scope of the problem. In addition, this method effectively combines the business perspective with the technical implementation, making the fault diagnosis process more efficient. By integrating business tags and execution metadata, operation and maintenance personnel can locate and solve problems in a shorter time, thereby reducing system downtime and improving the overall user experience.

[0103] See also Figure 4 , Figure 4 This is a schematic diagram of the structure of a database fault analysis device provided in an embodiment of the present application. Figure 4 As shown, the fault analysis device of the database includes:

[0104] A business request determination unit 401 is used to determine the business request corresponding to each SQL statement in the target database;

[0105] A first acquisition unit 402 is used to acquire multiple business elements of a business request corresponding to an SQL statement;

[0106] A business label marking unit 403, used to integrate the multiple business elements into business labels and mark them on the corresponding SQL statements;

[0107] The second acquisition unit 404 is used to acquire the execution metadata of each SQL statement;

[0108] The fault analysis unit 405 is used to perform fault analysis on each SQL statement in the target database based on the service label and execution metadata of the SQL statement.

[0109] In a possible implementation, the fault analysis unit 405 specifically includes:

[0110] A first statement division unit, configured to divide the SQL statements in the target database based on the business request unique identifiers of all the business requests in the target database to obtain a plurality of first SQL statement groups;

[0111] A first average execution time calculation unit, configured to calculate, for each first SQL statement group, an average execution time of each SQL statement in the first SQL statement group;

[0112] The first abnormal statement determining unit is used to determine an abnormal SQL statement based on the average execution time of each SQL statement in the first SQL statement group and the execution metadata.

[0113] In a possible implementation, the fault analysis unit 405 further includes:

[0114] A statistical unit, used for counting the types of business request transactions in the target database;

[0115] A second statement division unit, configured to divide the SQL statements in the target database based on the business request transaction type to obtain a plurality of second SQL statement groups;

[0116] A second average execution time calculation unit, configured to calculate, for each second SQL statement group, an average execution time of each SQL statement in the second SQL statement group;

[0117] The second abnormal statement determining unit is used to determine an abnormal SQL statement based on the average execution time of each SQL statement in the second SQL statement group and the execution metadata.

[0118] In a possible implementation, the execution metadata includes at least one or both of execution time consumption and execution error information.

[0119] In a possible implementation, the first abnormal statement determining unit specifically includes:

[0120] A third abnormal statement determination unit, for determining that the SQL statement is abnormal if the average execution time of the SQL statement is greater than a time threshold; the average execution time of the SQL statement is calculated based on the execution time of the SQL statement;

[0121] The fourth abnormal statement determining unit is configured to determine that an abnormality exists in the SQL statement if the execution metadata of the SQL statement includes the execution error information.

[0122] In a possible implementation, the multiple business elements include at least a business request transaction name, a business request unique identifier, a business request channel source, a business request start time, and a business request tracking ID.

[0123] In addition, an embodiment of the present application also provides a database fault analysis device, 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 database fault analysis method as described above is implemented.

[0124] In addition, an embodiment of the present application further provides a computer-readable storage medium, in which instructions are stored. When the instructions are executed on a terminal device, the terminal device executes the database fault analysis method as described above.

[0125] The embodiment of the present application provides a fault analysis device for a database, first using a first acquisition unit 301 to acquire mapping data from a ring buffer as data to be detected, wherein the mapping data is a system call combination information that has been filtered by rules, supplemented by rules, and formally mapped, and a rule filtering unit 302 is used to filter the data to be detected by rules to obtain filtered data. The input unit 303 inputs the filtered data into a pre-constructed abstract syntax tree to obtain a detection result. Then, the extraction unit 304 is used to extract data associated with the detection result from the mapping data as supplementary data, so that the output data supplement unit 305 can use the supplementary data to supplement the output data of the detection result to obtain the output result of the attack behavior. The present application associates each SQL statement with a business request, and integrates a business element label on the SQL statement. Based on this association, the business meaning represented by the SQL statement can be more deeply understood, thereby achieving more accurate root cause location of the fault, and no longer limited to the surface problem of the operation steps. At the same time, fault analysis is performed based on the business label and execution metadata of the SQL statement, which effectively improves the accuracy of troubleshooting. Combining the business perspective with the technical implementation greatly promotes the rapid location and resolution of problems, thereby accelerating the improvement of system stability and the realization of performance optimization.

[0126] The above is a detailed introduction to a database fault analysis method, device, equipment and storage medium provided by the present application. The various embodiments in the specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same and similar parts between the embodiments can be referenced to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part description. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the claims of the present application.

[0127] It should be understood that in the present application, "at least one (item)" means one or more, and "plurality" means two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the objects associated before and after are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0128] It should also be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.

Claims

1. A database fault analysis method, characterized in that: The method comprises: Determine the business request corresponding to each structured query language SQL statement in the target database, and obtain multiple business elements of the business request corresponding to the SQL statement; Integrate the multiple business elements into business tags and annotate them on the corresponding SQL statements, and obtain execution metadata of each SQL statement; For each SQL statement in the target database, a fault analysis is performed on the SQL statement based on the service tag and execution metadata of the SQL statement.

2. The method according to claim 1, characterized in that: The performing fault analysis on each SQL statement in the target database based on the service tag and execution metadata of the SQL statement includes: Dividing the SQL statements in the target database based on the business request unique identifiers of all the business requests in the target database to obtain a plurality of first SQL statement groups; For each first SQL statement group, calculate the average execution time of each SQL statement in the first SQL statement group; Based on the average execution time of each SQL statement in the first SQL statement group and the execution metadata, an abnormal SQL statement is determined.

3. The method according to claim 1, characterized in that The performing fault analysis on each SQL statement in the target database based on the service tag and execution metadata of the SQL statement further includes: Counting the types of business request transactions in the target database; Dividing the SQL statements in the target database based on the business request transaction type to obtain a plurality of second SQL statement groups; For each second SQL statement group, calculate the average execution time of each SQL statement in the second SQL statement group; Based on the average execution time of each SQL statement in the second SQL statement group and the execution metadata, an abnormal SQL statement is determined.

4. The method according to any one of claims 1 to 3, characterized in that: The execution metadata includes at least one or both of execution time consumption and execution error information.

5. The method according to claim 4, characterized in that The determining, based on the average execution time of each SQL statement in the first SQL statement group and the execution metadata, an abnormal SQL statement includes: If the average execution time of the SQL statement is greater than the time threshold, it is determined that the SQL statement is abnormal; the average execution time of the SQL statement is calculated based on the execution time of the SQL statement; If the execution metadata of the SQL statement includes the execution error information, it is determined that an exception exists in the SQL statement.

6. The method according to claim 1, characterized in that The multiple business elements at least include a business request transaction name, a business request unique identifier, a business request channel source, a business request start time, and a business request tracking identifier ID.

7. A database fault analysis device, characterized in that: The device comprises: A business request determination unit, used to determine the business request corresponding to each SQL statement in the target database; A first acquisition unit, used to acquire multiple business elements of a business request corresponding to an SQL statement; A business label marking unit, used to integrate the multiple business elements into business labels and mark them on the corresponding SQL statements; A second acquisition unit, used to acquire execution metadata of each SQL statement; The fault analysis unit is used to perform fault analysis on each SQL statement in the target database based on the service label and execution metadata of the SQL statement.

8. The device according to claim 7, characterized in that The fault analysis unit specifically includes: A first statement division unit, configured to divide the SQL statements in the target database based on the business request unique identifiers of all the business requests in the target database to obtain a plurality of first SQL statement groups; A first average execution time calculation unit, configured to calculate, for each first SQL statement group, an average execution time of each SQL statement in the first SQL statement group; The first abnormal statement determining unit is used to determine an abnormal SQL statement based on the average execution time of each SQL statement in the first SQL statement group and the execution metadata.

9. A database fault analysis device, characterized in that: include: 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 database fault analysis method according to any one of claims 1 to 6 is implemented.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores instructions, and when the instructions are executed on a terminal device, the terminal device executes the database fault analysis method according to any one of claims 1 to 6.

Images