Database fault diagnosis method and system and medium

Abstract

The embodiment of the invention provides a database fault diagnosis method and system and a medium, relates to the technical field of data processing, and is used for improving the diagnosis efficiency of database faults. If the data node fails, generating a memory dump file; determining an abnormal SQL based on the memory dump file and the SQL context snapshot; and generating a fault diagnosis report based on the abnormal SQL.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a database fault diagnosis method, system, and medium. Background Technology

[0002] When a node in a database system fails, significant time and manual effort are often required to analyze the coredump file to diagnose the fault and pinpoint the Structured Query Language (SQL) statement that triggered the crash. However, traditional analysis methods rely on manually examining logs and stack traces, resulting in low efficiency for fault diagnosis. Therefore, improving the efficiency of database fault diagnosis has become a pressing technical challenge. Summary of the Invention

[0003] In view of the above problems, the purpose of this invention is to provide a database fault diagnosis method, system, and medium to improve the efficiency of database fault diagnosis through automated fault diagnosis. The specific solution is as follows:

[0004] In a first aspect, embodiments of this application provide a database fault diagnosis method, the method comprising:

[0005] Get a snapshot of the SQL context;

[0006] If a data node fails, a memory dump file is generated;

[0007] Based on the memory dump file and the SQL context snapshot, the abnormal SQL was identified;

[0008] A fault diagnosis report is generated based on the abnormal SQL.

[0009] Optionally, obtaining the SQL context snapshot includes:

[0010] Key information during the SQL execution process is recorded in real time to obtain the SQL context snapshot.

[0011] Optionally, the real-time recording of key information during the SQL execution process includes:

[0012] Each time a new SQL statement is received, the identifier of the current SQL statement is stored in the session structure;

[0013] Record the current execution stage of the SQL statement;

[0014] Record the plan tree pointer corresponding to the current SQL.

[0015] Optionally, the memory dump file includes at least stack information; determining the abnormal SQL based on the memory dump file and the SQL context snapshot includes:

[0016] The stack information is compared with the SQL context snapshot to locate the abnormal SQL.

[0017] Optionally, comparing the stack information with the SQL context snapshot to locate the abnormal SQL includes:

[0018] Extract the current stack information from the memory dump file;

[0019] Based on the current stack information, locate the session identifier to which the crashed thread belongs;

[0020] Match the session identifier in the SQL context snapshot to determine the SQL being executed at that time;

[0021] Based on the SQL that was being executed at the time, and by locating the crash point through the stack trace, the abnormal SQL can be deduced.

[0022] Secondly, embodiments of this application provide a database fault diagnosis system, the system comprising:

[0023] The retrieval module is used to obtain a snapshot of the SQL context.

[0024] The parsing module is used to generate a memory dump file if a data node fails.

[0025] The determination module is used to determine the abnormal SQL based on the memory dump file and the SQL context snapshot;

[0026] The report generation module is used to generate a fault diagnosis report based on the abnormal SQL.

[0027] Optionally, the acquisition module is specifically used for:

[0028] Key information during the SQL execution process is recorded in real time to obtain the SQL context snapshot.

[0029] Optionally, the acquisition module is specifically used for:

[0030] Each time a new SQL statement is received, the identifier of the current SQL statement is stored in the session structure;

[0031] Record the current execution stage of the SQL statement;

[0032] Record the plan tree pointer corresponding to the current SQL.

[0033] Optionally, the determining module is specifically used for:

[0034] The stack information is compared with the SQL context snapshot to locate the abnormal SQL.

[0035] Optionally, the determining module is specifically used for:

[0036] Extract the current stack information from the memory dump file;

[0037] Based on the current stack information, locate the session identifier to which the crashed thread belongs;

[0038] Match the session identifier in the SQL context snapshot to determine the SQL being executed at that time;

[0039] Based on the SQL that was being executed at the time, and by locating the crash point through the stack trace, the abnormal SQL can be deduced.

[0040] Thirdly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements any of the above-described database fault diagnosis methods.

[0041] Compared with the prior art, this application has the following advantages:

[0042] By acquiring an SQL context snapshot, if a data node fails, a memory dump file is generated. Based on the memory dump file and the SQL context snapshot, abnormal SQL statements are identified, and a fault diagnosis report is generated based on the abnormal SQL statements. This allows for automatic fault diagnosis without manual intervention, improving the efficiency of fault diagnosis. Attached Figure Description

[0043] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings.

[0044] Figure 1 A schematic flowchart illustrating a database fault diagnosis method provided in an embodiment of this application;

[0045] Figure 2 A flowchart illustrating another database fault diagnosis method provided in an embodiment of this application;

[0046] Figure 3 This is a schematic diagram of the structure of a database fault diagnosis system provided in an embodiment of this application. Detailed Implementation

[0047] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0048] The terms “comprising” and “having”, and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion, for example, a process, method, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0049] Since data node (DN) failover in a database system refers to the system automatically switching the load to a standby node when a DN node fails, a DN failover indicates that a node in the database has failed. This necessitates manual analysis of the coredump file to identify the SQL statement that caused the crash. The coredump file is a memory dump file generated when a program crashes, used for fault analysis. However, traditional analysis methods rely on manually checking logs and stack traces, lacking effective automation mechanisms. This results in low efficiency in fault analysis and an inability to quickly identify the SQL statement that caused the crash, leading to low efficiency in fault diagnosis. To address these technical problems, this application provides a database fault diagnosis method, as follows:

[0050] like Figure 1 As shown in the figure, this application provides a database fault diagnosis method, which includes:

[0051] S101: Get SQL context snapshot.

[0052] In this embodiment, the SQL context snapshot is a session-level state record maintained in real time by a lightweight tracker while the database is running. The purpose of the SQL context snapshot is to restore the SQL being executed by each session and its execution state at the time of an anomaly.

[0053] It should be noted that the SQL context snapshot is obtained by the SQL context tracker and stored in the shared memory area so that it can be used by other modules in the subsequent analysis of abnormal SQL.

[0054] In one alternative embodiment, obtaining a snapshot of the SQL context includes:

[0055] It records key information during the SQL execution process in real time, obtaining an SQL context snapshot.

[0056] The SQL context snapshot in this embodiment adopts a lightweight design, recording only key information during SQL execution to avoid excessive overhead on system performance. This key information is essential data for subsequent analysis of abnormal SQL queries.

[0057] Specifically, an SQL context snapshot is a real-time record of key information by the database system during SQL execution. This key information can include the current SQL execution stage, execution plan, transaction ID, and other critical details. The execution stage refers to the SQL's execution status within the database, such as parsing, planning, or executing. This approach covers all SQL activities with minimal overhead, ensuring that the SQL context snapshot can be restored in case of a failure. For example, during each SQL execution, the SQL text, execution stage, and execution plan are recorded in real-time. This ensures that if a memory dump file is generated due to a failure, the SQL context can be reconstructed using the real-time recorded SQL text, execution stage, and execution plan data. Furthermore, because the SQL context snapshot in this embodiment employs a lightweight design, storing only brief key information such as pointers and identifiers without copying the complete SQL or complete plan object, it avoids significantly increasing memory and I / O burden, reducing system runtime overhead.

[0058] Furthermore, key information during the SQL execution process is recorded in real time, including:

[0059] Each time a new SQL statement is received, the identifier of the current SQL statement is stored in the session structure;

[0060] Record the current execution stage of the SQL statement;

[0061] Record the plan tree pointer corresponding to the current SQL.

[0062] When the DN node is running, extend the session control module to add an SQL context snapshot area. Each time a new SQL statement is received, perform the following operations:

[0063] The session structure stores the identifier of the current SQL statement to reduce memory usage. This identifier is unique and can be configured based on specific needs, such as using a pointer or hash. The execution stage of the current SQL statement is recorded, which can be one of parsing, planning, or execution. If the execution state enters the planning or execution stage, the corresponding plan tree pointer is recorded. If the execution state does not enter the planning or execution stage, no plan tree pointer is recorded because no plan tree exists. If no plan tree pointer exists, it indicates a fault occurred in an early stage of execution, such as the parsing stage. In this case, the SQL text being parsed at that time can be directly searched in the SQL context snapshot using the session ID, and the parsed SQL text is identified as the abnormal SQL statement. The fault diagnosis report records that the fault occurred during the parsing stage.

[0064] Each record occupies a preset amount of memory, which can be set based on actual needs. For example, the preset memory in this application is in the tens of bytes range to minimize the memory usage of each record. When the DN process terminates abnormally, this shared memory is not immediately released; a snapshot of the SQL context at that time can be recovered from the coredump. The coredump also records the process's memory image, stack state, registers, call stack frames, thread information, and other contextual information at the moment of the crash.

[0065] This application avoids significantly impacting database performance by not copying large objects to the SQL context snapshot, saving only pointers and lightweight structures. The snapshot area used to store the SQL context snapshot is placed in a separate shared memory area or session local memory area, ensuring that the SQL context snapshot is preserved even after a program crash. This guarantees real-time maintenance of the information contained in the SQL context snapshot with almost no increase in system overhead.

[0066] In an optional embodiment, this application also introduces a lightweight interceptor. This lightweight interceptor inserts hooks at critical paths such as transaction start to capture events when new SQL queries enter or when phases change. Active SQL information is maintained using a data structure, which can be a shared memory hash table. For example, the data structure can include SQL keys and values, where the key is a session ID or a backend ID, and the value includes a pointer to the SQL text, the execution phase, and a pointer to the execution plan tree.

[0067] In one alternative embodiment, the runtime real-time maintained SQL context snapshot includes: a session identifier or virtual transaction identifier, the currently active SQL text or SQL identifier, the current execution phase of the SQL (which may be one of parsing, planning, or execution), a pointer to the current plan tree, or a pointer to an execution node.

[0068] S102: If a data node fails, a memory dump file is generated.

[0069] To determine if a DN node has failed, the coredump parsing module automatically generates a memory dump file when a DN node fails. The memory dump file includes at least stack information and may also include session information.

[0070] Specifically, when a DN node fails, the system automatically calls the coredump parsing module and extracts stack information and session information from memory to generate a memory dump file. It can also extract an SQL context snapshot from memory to facilitate the subsequent location of abnormal SQL based on the memory dump file and the SQL context snapshot.

[0071] It should be noted that in the event of a failure, the snapshot area corresponding to the SQL context snapshot will not be lost due to process failure or crash, so that the SQL context snapshot can be extracted from the image in the memory dump file. The memory dump file is determined based on the memory image at the time of the failure, and the image in the memory dump file includes: the session structure, the executor structure, and the stack trace, etc.

[0072] In an optional embodiment, the above method further includes:

[0073] After the SQL execution is completed, if the DN node does not fail during the execution process, the SQL context snapshot corresponding to the completed SQL is cleared to avoid recording too many SQL context snapshots in the database, which would result in a large amount of memory being consumed.

[0074] S103: Identify anomalous SQL based on memory dump files and SQL context snapshots.

[0075] An abnormal SQL statement is the SQL statement that caused the current failure or that may cause a failure. In this example, we will use an abnormal SQL statement that may cause a failure as an example for further explanation.

[0076] In one alternative embodiment, the anomalous SQL is determined based on the memory dump file and the SQL context snapshot, including:

[0077] By comparing the stack trace with the SQL context snapshot, the abnormal SQL can be located.

[0078] The abnormal SQL correlation module compares the stack information in the memory dump file with the SQL context snapshot to locate the abnormal SQL. Because the SQL context snapshot in this embodiment adopts a lightweight design, recording only key information, it effectively supports the analysis of abnormal SQL while ensuring system performance.

[0079] In one optional embodiment, the stack information is compared with the SQL context snapshot to locate the abnormal SQL, including:

[0080] Extract the current stack information from the memory dump file;

[0081] Based on the current stack trace information, locate the session identifier to which the crashed thread belongs;

[0082] Match the session identifier in the SQL context snapshot to determine the SQL being executed at that time;

[0083] Based on the SQL being executed at the time and the stack trace to pinpoint the crash point, the abnormal SQL was deduced.

[0084] Specifically, the current stack trace in the coredump is extracted (the crash point can be a function, such as the `exec proc node` function or the `exec scan` function), and the session ID of the crashing thread is located. This session ID is then matched against the SQL context snapshot to obtain the SQL being executed at that time. By combining the stack trace to pinpoint the crash point, it's possible to deduce which SQL statement or subquery segment caused the problem. This allows for precise location of the faulty SQL statement using structured data, rather than relying on a full-text log search.

[0085] In this embodiment, the stack trace information can also be combined with the plan state tree to trace back to the specific problematic segment of the executed SQL. For example, whether it was an aggregate function that failed or a join operation that failed. The problematic code point can be found in the coredump, and the abnormal SQL can be deduced from it.

[0086] Specifically, the stack frame of the crashed thread is located. The location method can be set according to actual needs, such as using an automatic parser. The plan state or substructure pointers are extracted from the stack frame of the crashed thread. The `type` field at the offset position in the plan state is read, and the node type is mapped based on the `type` field. The plan state structure contains a pointer field `plan` for the execution plan node. The pointer field `plan` is extracted from the plan state; it is the structure address of the current node in the plan tree, used for subsequent matching. This address is recorded: for example, `plan_ptr = planstate->plan`. During database runtime, the system maintains an SQL context snapshot for each session. Since the SQL context snapshot includes the original SQL text, execution plan tree, node status, and plan execution stage information, this embodiment can retrieve the corresponding plan tree root node from the SQL context snapshot, use a recursive algorithm to traverse all child nodes, and check `if(p == plan_ptr) return current node`. If a match is found, it means that this plan tree root node is the node being executed at the time of the crash. Extract the semantic fields of the currently executing node. These semantic fields include fields representing the selected fields in the SELECT statement, fields representing WHERE or JOIN conditions, and fields representing GROUP BY or ORDER BY conditions. Combine the node type and semantic fields to deduce the corresponding structural position in the SQL statement.

[0087] For example, if a crash occurs during the execution of a complex SQL statement containing a Join operation in session ID 123, the stack trace can be extracted via coredump, revealing that the crash occurred at a Join node in the execution plan. By combining this with a snapshot of the SQL context, the SQL text executed by session ID 123 at that time can be located. Comparison with plan tree pointers identifies the Join clause within the SQL statement that caused the crash. The final diagnostic report indicates that the SQL statement and its Join operation led to the crash.

[0088] It should be noted that the SQL original text included in the SQL context snapshot is the identified abnormal SQL, and the corresponding structural position in the deduced SQL statement is the location where the fault occurred.

[0089] In an optional embodiment, the coredump debugging tool can be used to extract the call stack and stack information of the process at the time of the crash to identify the abnormal SQL. The stack information includes the currently crashing function, such as #0ExecProcNode, #1ExecScan, and #2ExecSeqScan. By combining the plan node pointers associated with each stack level with the stack information, it is possible to preliminarily determine which stage of the planned execution the crash occurred in, and the specific operations involved, such as tables, index scans, joins, and sorting.

[0090] Specifically, open the coredump using a debugging tool to view all the threads within it. Each thread represents a database connection or background operation. The debugging tool is used to view the threads contained in the coredump, such as the GNU Debugger (GDB). Observe the stack trace to find the thread that terminated due to a fatal signal. The stack trace records the function call chain information of the program during runtime, while the fatal signal indicates a signal that caused the thread to terminate due to a failure, such as the segmentation fault signal (sigsegv).

[0091] The thread that terminates due to a fatal signal is identified as the main thread of the execution exception. If multiple threads terminate due to fatal signals, these are sequentially identified as the main threads of the execution exception. The database runtime structure is examined within the main thread of the execution exception to obtain key information relevant to it. There is a one-to-one correspondence between threads and database sessions; key information includes session ID, username, client address, and the currently executing SQLID. The currently executing SQLID contained within this key information is identified as the abnormal SQL.

[0092] Furthermore, after identifying the abnormal SQL, the above embodiments can further analyze the session corresponding to the session ID to determine which stage of the planned execution the abnormal SQL was in when the failure occurred.

[0093] This embodiment compares the SQL context snapshot and memory data through the abnormal SQL association module. The input of the abnormal SQL association module includes: snapshot information and execution status parsed from coredump. The execution status consists of stack and session. The snapshot information includes SQL text, execution stage and sessionID.

[0094] After input, the abnormal SQL association module compares the SQL context snapshot and memory data. The comparison methods include: associating the coredump process with the snapshot session via session ID; verifying the consistency of the SQL execution phase to confirm whether the SQL caused the system failure during execution; in the case of batch commits, multiple SQL statements may exist in the SQL context snapshot, allowing for further precise matching based on the execution plan node address to pinpoint which SQL statement caused the system failure; and cross-checking based on transaction ID and lock information to prevent bias caused by session reuse. After a successful comparison, the SQL statement most likely to cause the crash is marked, allowing for precise filtering of suspicious SQL statements using structured session information and execution status to avoid false positives.

[0095] Furthermore, the SQL context snapshot may contain multiple SQL records from the same session, which are SQL records at different stages of execution. Since the current SQL pointer is updated every time a new SQL is received, and the plan tree pointer can be refined to the subquery level, the distinction between multiple SQL records can be achieved, avoiding confusion between multiple SQL records.

[0096] S104: Generate a fault diagnosis report based on abnormal SQL.

[0097] After identifying the abnormal SQL statement, a fault diagnosis report is automatically generated by the fault report generation module. This allows technicians to repair the fault based on the report, improving operational efficiency. The content of the fault diagnosis report can be configured according to actual needs, and may include one or more of the following: error node name, timestamp, session identifier, SQL text and execution stage, crash stack information, transaction information, error analysis conclusions, and repair suggestions. The session identifier can be a session ID, client IP address, user ID, etc. The repair suggestions provide targeted advice based on the execution stage and crash point of the abnormal SQL statement, such as "check the join conditions or indexes of this SQL statement," making the report highly practical and helping operations and development personnel quickly take action against the abnormal SQL statement.

[0098] By acquiring SQL context snapshots, a memory dump file is generated if a data node fails. Based on the memory dump file and the SQL context snapshot, the abnormal SQL is identified, and a fault diagnosis report is generated based on the abnormal SQL. This automatic fault diagnosis mechanism, which automatically generates memory dump files when a fault occurs and combines them with real-time maintained SQL context snapshots, automatically locates the abnormal SQL that caused the crash, achieving automatic fault diagnosis without manual intervention and improving the efficiency of fault diagnosis. Compared to traditional methods that rely on DBAs manually checking logs and call stacks, this significantly improves efficiency and accuracy.

[0099] In an optional embodiment, the above method further includes:

[0100] The accuracy of detecting abnormal SQL queries;

[0101] When the accuracy is less than a preset threshold, the algorithm is optimized until the optimized accuracy is greater than or equal to the preset threshold.

[0102] Specifically, multiple verification samples are created, and calculations are performed on each sample. The accuracy rate of detecting abnormal SQL queries is determined based on the calculation results. For example, the number of detected abnormal SQL queries / the total number of abnormal SQL queries = accuracy rate. The calculated accuracy rate is compared with a preset threshold. If the accuracy rate of abnormal SQL queries determined by the above method is greater than the preset threshold, the abnormal SQL queries are checked using the above method. The preset threshold can be set based on actual needs; for example, the preset threshold in this embodiment can be 85%.

[0103] To make it easier to understand, the following example is provided:

[0104] like Figure 2 As shown, the system receives user-submitted SQL statements, tracks the SQL context to record key information during SQL execution in real time, and obtains an SQL context snapshot. It determines whether the SQL statement executed correctly; if so, it cleans up the real-time records for that SQL statement. If not, it generates a memory dump file, identifies the abnormal SQL statement based on the memory dump file and the SQL context snapshot, and generates a fault diagnosis report.

[0105] In an alternative embodiment, before determining the anomalous SQL based on the memory dump file and the SQL context snapshot, the above method further includes:

[0106] The coredump is scanned using an SQL scanning tool to extract the SQL being executed at the time of the failure, and this extracted SQL is then identified as anomalous. The SQL scanning tool can be a string scanning tool or a memory scanning tool. If the SQL being executed at the time of the failure is extracted, a fault diagnosis report is generated directly based on the anomalous SQL. If the SQL being executed at the time of the failure cannot be extracted, or if the extracted SQL is incomplete, further analysis is performed based on the memory dump file and SQL context snapshot to identify the anomalous SQL. This prioritizes extracting anomalous SQL from the coredump, avoiding complex analysis, quickly identifying anomalous SQL, and improving the efficiency of fault diagnosis report generation.

[0107] In an alternative embodiment, before determining the anomalous SQL based on the memory dump file and the SQL context snapshot, the above method further includes:

[0108] A stack fingerprint database is pre-established to record and match characteristic information of thread call stacks during database crashes. This characteristic information can be key fields contained in the stack, such as: the first field representing the function call stack sequence of the crashing thread (e.g., `stack_trace`); the second field representing the sequence of plan node types matching the stack functions (e.g., `plan_type_seq`); the third field representing the crashing function and its offset (e.g., `crash_function + offset`); the fourth field representing the summary of the last executed SQL statement before the crash (e.g., `sql_snippet`); and the fifth field representing the fault attribution label (e.g., `tag`).

[0109] It should be noted that each stack in the fingerprint database has its own first to fifth fields.

[0110] When a data node fails, the first, second, and third fields are extracted from the coredump. These fields are then compared sequentially with the corresponding first, second, and third fields in the fingerprint database for the same stack. If the first field matches in the prefix, the stack in the coredump is considered to be of the same type as the currently compared stack. If the second field's comparison shows an edit distance less than a preset distance, the stack in the coredump is considered structurally similar to the currently compared stack; the preset distance can be set based on actual needs. If the third field's comparison shows a complete match in both the crash function and offset, the problem is considered to originate from the same source. If the comparison result of the first field is consistent with the prefix, the comparison result of the second field is that the edit distance is less than the preset distance, and the comparison result of the third field is that the crash function and offset are completely consistent, the fourth and fifth fields of the current comparison stack are extracted. The contents of the fourth and fifth fields are combined to generate a fault diagnosis report, so as to refer to the label or the corresponding fault cause description, to prompt the operation and maintenance personnel that the current fault is a similar problem that has occurred before, and to provide a solution reference, so as to quickly identify the abnormal SQL and the fault cause through historical known faults, thereby improving the analysis efficiency.

[0111] If the comparison result of the first field is a prefix inconsistency, or the comparison result of the second field is an edit distance greater than or equal to a preset distance, or the comparison result of the third field is a crash function and offset inconsistency, then the step of determining the abnormal SQL based on the memory dump file and SQL context snapshot is executed. After determining the fault diagnosis report, the determined abnormal SQL is used as the fourth field. A fault attribution label is generated based on the fault diagnosis report, and the fault attribution label is used as the fifth field. A push stack corresponding to the coredump is added to the fingerprint database, and the extracted first, second, third, fourth, and fifth fields are saved to update the fingerprint database, realize the use of historical experience to accelerate the diagnosis of known problems, and form a self-learning capability.

[0112] It should be noted that any of the embodiments in this application are applicable to large-scale distributed databases or single-machine databases and other DN master-slave switching scenarios.

[0113] like Figure 3 As shown in the illustration, this application also provides a database fault diagnosis system, the system comprising:

[0114] Module 301 is used to obtain an SQL context snapshot;

[0115] The parsing module 302 is used to generate a memory dump file based on the execution status if a data node fails.

[0116] Module 303 is used to identify anomalous SQL based on memory dump files and SQL context snapshots.

[0117] The report generation module 304 is used to generate fault diagnosis reports based on abnormal SQL.

[0118] In an optional embodiment, the acquisition module 301 is specifically used for:

[0119] It records key information during the SQL execution process in real time, obtaining an SQL context snapshot.

[0120] In an optional embodiment, the acquisition module 301 is specifically used for:

[0121] Each time a new SQL statement is received, the identifier of the current SQL statement is stored in the session structure;

[0122] Record the current execution stage of the SQL statement;

[0123] Record the plan tree pointer corresponding to the current SQL.

[0124] In an optional embodiment, the determining module 303 is specifically used for:

[0125] By comparing the stack trace with the SQL context snapshot, the abnormal SQL can be located.

[0126] In an optional embodiment, the determining module 303 is specifically used for:

[0127] Extract the current stack information from the memory dump file;

[0128] Based on the current stack trace information, locate the session identifier to which the crashed thread belongs;

[0129] Match the session identifier in the SQL context snapshot to determine the SQL being executed at that time;

[0130] Based on the SQL being executed at the time and the stack trace to pinpoint the crash point, the abnormal SQL was deduced.

[0131] By acquiring an SQL context snapshot, if a data node fails, a memory dump file is generated. Based on the memory dump file and the SQL context snapshot, abnormal SQL statements are identified, and a fault diagnosis report is generated based on the abnormal SQL statements. This allows for automatic fault diagnosis without manual intervention, improving the efficiency of fault diagnosis.

[0132] This application provides a computer-readable storage medium storing a computer program thereon, wherein the computer program, when executed by a processor, implements any of the above-described database fault diagnosis methods.

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

[0134] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0135] The technical content provided by the present invention has been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A database fault diagnosis method, characterized in that, The method includes: Get a snapshot of the SQL context; If a data node fails, a memory dump file is generated; Based on the memory dump file and the SQL context snapshot, the abnormal SQL was identified; A fault diagnosis report is generated based on the abnormal SQL.

2. The method according to claim 1, characterized in that, The process of obtaining the SQL context snapshot includes: Key information during the SQL execution process is recorded in real time to obtain the SQL context snapshot.

3. The method according to claim 2, characterized in that, The real-time recording of key information during SQL execution includes: Each time a new SQL statement is received, the identifier of the current SQL statement is stored in the session structure; Record the current execution stage of the SQL statement; Record the plan tree pointer corresponding to the current SQL.

4. The method according to claim 1, characterized in that, The memory dump file includes at least stack information; the determination of the abnormal SQL based on the memory dump file and the SQL context snapshot includes: The stack information is compared with the SQL context snapshot to locate the abnormal SQL.

5. The method according to claim 4, characterized in that, The step of comparing the stack information with the SQL context snapshot to locate the abnormal SQL includes: Extract the current stack information from the memory dump file; Based on the current stack information, locate the session identifier to which the crashed thread belongs; Match the session identifier in the SQL context snapshot to determine the SQL being executed at that time; Based on the SQL that was being executed at the time, and by locating the crash point through the stack trace, the abnormal SQL can be deduced.

6. A database fault diagnosis system, characterized in that, The system includes: The retrieval module is used to obtain a snapshot of the SQL context. The parsing module is used to generate a memory dump file if a data node fails. The determination module is used to determine the abnormal SQL based on the memory dump file and the SQL context snapshot; The report generation module is used to generate a fault diagnosis report based on the abnormal SQL.

7. The system according to claim 6, characterized in that, The acquisition module is specifically used for: Key information during the SQL execution process is recorded in real time to obtain the SQL context snapshot.

8. The system according to claim 7, characterized in that, The acquisition module is specifically used for: Each time a new SQL statement is received, the identifier of the current SQL statement is stored in the session structure; Record the current execution stage of the SQL statement; Record the plan tree pointer corresponding to the current SQL.

9. The system according to claim 6, characterized in that, The determining module is specifically used for: The stack information is compared with the SQL context snapshot to locate the abnormal SQL.

10. A computer-readable storage medium, characterized in that, It stores a computer program, wherein the computer program, when executed by a processor, implements any one of the database fault diagnosis methods as described in claims 1 to 5.

Images