Database operation and maintenance method, system and storage medium

Abstract

The present specification provides a database operation and maintenance method, system and storage medium, the method comprising: in response to detecting a database anomaly, determining a target expert role corresponding to the current anomaly from pre-generated expert roles; and performing database anomaly diagnosis by the target expert role in a tree search manner to obtain a diagnosis result. The present disclosure constructs an intelligent database operation and maintenance system based on a large language model, which can quickly respond to operation and maintenance problems existing in the database without manual intervention, thus saving the training cost of the DBA. Moreover, due to the use of a large language model, it can better utilize existing operation and maintenance knowledge to infer the root cause of the current anomaly and / or the solution to the current anomaly, with good generalization and high availability, thus improving the diagnostic accuracy and efficiency of database operation and maintenance in complex scenarios.

Description

Technical Field

[0001] This specification relates to the field of databases, and in particular to a database operation and maintenance method, system, and storage medium. Background Art

[0002] Database operation and maintenance is a challenging issue. Currently, we can rely on the experience and knowledge of database administrators (DBAs) to perform operation and maintenance tasks, but the training cost of DBAs is high and there may be problems with untimely responses.

[0003] Although some databases are equipped with semi-automatic operation and maintenance tools, these tools cannot utilize operation and maintenance knowledge, have poor generalization, and have no reasoning ability. Database operation and maintenance solutions need to be improved. Summary of the invention

[0004] To overcome the problems existing in the related art, this specification provides a database operation and maintenance method, system and storage medium.

[0005] According to a first aspect of an embodiment of this specification, a database operation and maintenance method is provided, the method comprising:

[0006] In response to detecting a database anomaly, determining a target expert role corresponding to the current anomaly from among pre-generated expert roles; wherein each expert role supports handling a type of database operation and maintenance problem;

[0007] According to the tree search method, the target expert role performs database anomaly diagnosis to obtain a diagnosis result; wherein the diagnosis result includes the root cause of the current anomaly and / or a solution to the current anomaly.

[0008] According to a second aspect of an embodiment of this specification, a database operation and maintenance device is provided, the device comprising:

[0009] A determination module, configured to, in response to detecting a database anomaly, determine a target expert role corresponding to the current anomaly from among pre-generated expert roles; wherein each expert role supports processing a type of database operation and maintenance problem;

[0010] The inference module is used to perform database anomaly diagnosis by the target expert role in a tree search manner to obtain a diagnosis result; wherein the diagnosis result includes the root cause of the current anomaly and / or a solution to the current anomaly.

[0011] According to a third aspect of the embodiments of this specification, a database operation and maintenance system is provided, the system comprising: a database; a large language model, the model being used to execute the steps of any one of the methods described in the first aspect above.

[0012] According to a fourth aspect of the embodiments of this specification, there is provided a computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the steps of the method as described in any one of the first aspects.

[0013] According to a fifth aspect of the embodiments of this specification, a computer program product is provided, comprising a computer program / instruction, which, when executed by a processor, implements the steps of the method described in any one of the first aspects.

[0014] The technical solutions provided by the embodiments of this specification may have the following beneficial effects:

[0015] In the embodiments of the present specification, by constructing an intelligent database operation and maintenance system based on a large language model, it is possible to quickly respond to operation and maintenance problems existing in the database without the need for human intervention, thereby saving the training costs of the DBA. Moreover, due to the use of a large language model, it is possible to better utilize existing operation and maintenance knowledge to infer the root cause of the current anomaly and / or the solution to the current anomaly, with good generalization and high availability, thereby improving the diagnostic accuracy and efficiency of database operation and maintenance in complex scenarios.

[0016] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present specification. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the specification and, together with the description, serve to explain the principles of the specification.

[0018] Figure 1 This is one of the flowcharts of a database operation and maintenance method provided by an exemplary embodiment.

[0019] Figure 2 This is the second flowchart of a database operation and maintenance method provided by an exemplary embodiment.

[0020] Figure 3 This is the third flowchart of a database operation and maintenance method provided by an exemplary embodiment.

[0021] Figure 4 This is the fourth flowchart of a database operation and maintenance method provided by an exemplary embodiment.

[0022] Figure 5 This is the fifth flowchart of a database operation and maintenance method provided by an exemplary embodiment.

[0023] Figure 6 This is the sixth flowchart of a database operation and maintenance method provided by an exemplary embodiment.

[0024] Figure 7 It is a flowchart of a document knowledge extraction method provided by an exemplary embodiment.

[0025] Figure 8 It is a flowchart of a large model diagnosis based on a search tree provided by an exemplary embodiment.

[0026] Fig. 9 This is the seventh flow chart of a database operation and maintenance method provided by an exemplary embodiment.

[0027] Fig.10 It is a structural diagram of a database operation and maintenance device provided by an exemplary embodiment.

[0028] Fig.11 It is a structural diagram of a server provided by an exemplary embodiment. DETAILED DESCRIPTION

[0029] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementations described in the following exemplary embodiments do not represent all implementations consistent with this specification. Instead, they are merely examples of devices and methods consistent with some aspects of this specification as detailed in the appended claims.

[0030] The terms used in this specification are for the purpose of describing specific embodiments only and are not intended to limit this specification. The singular forms "a", "the" and "the" used in this specification and the appended claims are also intended to include plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0031] It should be understood that although the terms first, second, third, etc. may be used in this specification to describe various information, this information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of this specification, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0032] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0033] Database operation and maintenance aims to detect, analyze, and resolve abnormal events in the database system to ensure high reliability and efficient load execution of the database. However, database anomalies are extremely diverse and cannot be effectively covered by predefined empirical rules. For example, a database vendor received nearly 1,000 abnormal event feedbacks in a few months. These events mostly involved various aspects of the database and underlying system modules, such as query optimization, locking mechanism, system configuration, etc. In addition, these modules show complex correlations with system indicators. For example, high central processing unit (CPU) utilization may be due to high concurrent submissions or a large number of computing operations. Therefore, in many abnormal scenarios, different diagnostic strategies need to be tried, such as analyzing different system views until the root cause of the anomaly and the solution for abnormal recovery are determined.

[0034] Therefore, database operation and maintenance is a challenging problem. Currently, one possible implementation solution is to perform operation and maintenance tasks according to the DBA's experience and knowledge. Common processes include:

[0035] (1)Exception notification.

[0036] A database user reports an anomaly, e.g., "A regular query is 120% slower...".

[0037] (2) Alarm detection.

[0038] After receiving the user's notification, the DBA first investigates the alarms triggered during the corresponding time period. For example, the DBA finds a "CPU High" alarm, indicating that the total CPU usage exceeds 90% and lasts for 2 minutes.

[0039] (3) Analysis of abnormal indicators.

[0040] Next, the DBA further explores more CPU-related metrics, such as the number of running or blocked processes and the number of query calls. By analyzing these metrics, the DBA draws the conclusion that the problem is caused by some resource-intensive queries, for example.

[0041] (4) Analysis of abnormal events.

[0042] The DBA retrieves query templates from database views, such as statistics of the top-k slow queries, and finds that there is one query that consumes nearly 60% of the CPU time.

[0043] (5)Optimization suggestions.

[0044] The DBA tries to optimize abnormal queries using experience or tools (for example, index updates, SQL rewrites).

[0045] The above operation and maintenance process is iterative in nature. For example, if the DBA does not find any abnormal queries, he may turn to investigating the input / output (I / O) indicators. In addition, the DBA needs to write an operation and maintenance report to help users understand, which includes the root cause and detailed operation and maintenance process.

[0046] However, there is a significant gap between the limited capabilities of human DBAs and the arduous operation and maintenance problems. First, it takes a lot of time to train a human DBA, usually ranging from several months to several years, and requires understanding a large amount of relevant documents, such as database tuning guides and necessary practical operations. Second, it is almost impossible to hire enough human DBAs to manage huge database instances, such as millions of instances on cloud databases. Third, human DBAs may not be able to provide timely responses in emergencies, especially when dealing with problems related to multiple database modules, which may result in significant economic losses. Therefore, if typical exceptions can be resolved automatically, it will reduce the burden on human DBAs and save resources.

[0047] Based on this, another implementation solution is to equip the database with semi-automatic operation and maintenance tools. However, these tools have several limitations. First, they are built based on empirical rules or small-scale machine learning models, such as classifiers, which have poor understanding of scenarios and cannot utilize operation and maintenance knowledge. Second, they cannot flexibly adapt to scenario changes. For empirical methods, manually updating and verifying the rules in the latest version of the document is a tedious task. Learning methods, such as the optimized distributed gradient boosting library XGBoost and K-Nearest Neighbors (KNN), require redesigning input indicators and labels, and retraining models for new scenarios. Third, these methods do not have reasoning capabilities similar to human DBAs, such as recursively exploring system views based on preliminary analysis results to infer root causes and solutions.

[0048] To this end, this specification aims to build an intelligent diagnosis system based on a large language model.

[0049] Considering that database operation and maintenance requires a lot of domain-related knowledge, some general models cannot directly diagnose the root cause (hereinafter referred to as "root cause"). For example, the accuracy of these general models is less than 50%. Building the above system mainly includes three challenges:

[0050] The first aspect is how to improve the understanding of general operation and maintenance issues of large models.

[0051] Although existing large models have been pre-trained on extensive corpora, large models still have difficulty in making effective diagnosis without appropriate prompts, e.g., lack of database domain knowledge. Challenges include extracting useful knowledge from long documents, e.g., relevance across sections, matching appropriate knowledge given a context, e.g., detecting alerts for high node load, and retrieving potentially useful tools, e.g., database catalogs.

[0052] The second aspect is how to improve the single root cause abnormality diagnosis capability of large models.

[0053] Under the guidance of operation and maintenance knowledge and tools, large models need to make careful inferences about given anomalies. First, unlike many large model tasks, database diagnosis is usually an interactive process that requires multiple analyses, and large models have the problem of early stopping. Second, large models have the problem of "hallucination", and it is crucial to design strategies to guide large models to conduct in-depth and reasonable analysis.

[0054] The third aspect is how to enhance the diagnostic capability of large models for multi-root cause anomalies.

[0055] It is difficult for a single large model to accurately analyze complex anomalies within a limited time budget, for example, those with multiple root causes and requiring analysis of fine-grained metrics. Therefore, it is critical to design an efficient diagnosis mechanism in which multiple large models can collaborate to solve complex database problems, for example, by cross-examination, improving the accuracy and efficiency of diagnosis in complex scenarios.

[0056] In the embodiments of this specification, a database operation and maintenance method, system and storage medium are proposed, which can accurately analyze the root cause of the exception and provide optimization strategies for different abnormal alarms by using methods such as knowledge extraction based on summary tree search, prompt learning based on document knowledge and tool matching, large model reasoning based on thinking tree, and asynchronous collaboration based on multiple models.

[0057] The following is an introduction to the database operation and maintenance method provided by the present invention.

[0058] Figure 1 FIG. 1 is a flowchart of a database operation and maintenance method provided by an exemplary embodiment. Figure 1 As shown, the method can be performed by a large language model, and the method includes:

[0059] Step S101, obtaining knowledge blocks and / or tools required for database anomaly diagnosis.

[0060] In some embodiments, the above-mentioned knowledge blocks and / or tools can be prepared offline. Figure 2 As shown, it is not introduced here.

[0061] In some embodiments, after the above-mentioned knowledge blocks and / or tools are acquired, if the diagnosis document is not updated, step S101 does not need to be performed again.

[0062] Step S102: Generate a diagnosis prompt message.

[0063] In some embodiments, when the above-mentioned knowledge blocks and / or tools are ready, the diagnostic prompt message can be generated based on the diagnostic prompt generation module of the large language model (hereinafter referred to as the large model). The diagnostic prompt message is used to provide context-aware prompts to the target expert roles involved in the database anomaly diagnosis process. The specific implementation process can be referred to Figure 3 As shown, it is not introduced here.

[0064] Step S103: The target expert role performs database anomaly diagnosis in a tree search manner to obtain a diagnosis result.

[0065] In some embodiments, if the large language model detects a database anomaly, it may determine one or more target expert roles corresponding to the current anomaly from among a plurality of pre-generated expert roles.

[0066] In the disclosed embodiment, each expert role can support processing a type of database operation and maintenance problems.

[0067] For example, expert #1 supports handling IO issues, expert #2 supports handling memory issues, expert #3 supports handling load issues, expert #4 supports handling slow query issues, and so on.

[0068] It is understandable that each expert role can acquire knowledge blocks related to this type of database operation and maintenance problems, and / or can use tools related to this type of database operation and maintenance problems.

[0069] In one example, the tools in the embodiments of the present disclosure may include but are not limited to monitoring tools, optimization tools, etc. Among them, the monitoring tools may include but are not limited to system monitoring tools, data monitoring tools, etc.

[0070] Among them, system monitoring tools include vmstat for reporting virtual memory statistics, iostat for reporting CPU statistics, etc., and database monitoring tools include audit, kcache, etc.

[0071] Among them, the optimization tools may include but are not limited to configuration tools and optimization tools, wherein the configuration tools include learning rate adjustment (warm-up), knob, etc., and the optimization tools include hints, rewrites, etc.

[0072] In some embodiments, database diagnosis is performed in a tree search manner in order to identify potential root causes and / or solutions using the knowledge blocks and / or tools prompted by the above-mentioned diagnostic prompt messages.

[0073] Considering the database diagnosis process, large language models may have hallucinations or instability, such as incorrect Application Programming Interface (API) requests, overly broad analysis and other challenges, resulting in diagnosis failure.

[0074] Because, in the embodiments of this specification, it is proposed that a mind tree strategy can be adopted, where the large language model explores multiple possible paths and selects the path with the highest effect for further exploration. And through the reflection mechanism, the large language model can backtrack when no useful information is found, thereby increasing the possibility of obtaining a reasonable diagnosis result. The specific process can be referred to Figure 4 As shown, it is not introduced here.

[0075] Step S104: multiple target expert roles perform collaborative diagnosis.

[0076] In some embodiments, each target expert role can perform a diagnosis based on step S103 to obtain a diagnosis result. Finally, the large language model can modify each diagnosis result in combination with the diagnosis results provided by multiple target expert roles, and finally provide a more reliable and reasonable diagnosis result. The specific process can be referred to Figure 5 As shown, it is not introduced here.

[0077] In some embodiments, when the number of target expert roles is 1, step S104 may not be performed.

[0078] In the above embodiment, by constructing an intelligent database operation and maintenance system based on a large language model, it is possible to quickly respond to operation and maintenance problems existing in the database without manual intervention, saving the training cost of the DBA. Moreover, due to the use of a large language model, it is possible to better utilize existing operation and maintenance knowledge to infer the root cause of the current anomaly and / or the solution to the current anomaly. It has good generalization and high availability, and improves the diagnostic accuracy and efficiency of database operation and maintenance in complex scenarios.

[0079] Figure 2 FIG. 1 is a flowchart of another database operation and maintenance method provided by an exemplary embodiment. Figure 2As shown, step S101 may include:

[0080] Step S101 - 1 , establishing a summary tree, and obtaining knowledge blocks required for database anomaly diagnosis from the summary tree.

[0081] In some embodiments, step S101-1 may include:

[0082] Step S101 - 1 - 1 , split each diagnostic document according to the chapter structure and chapter content to obtain multiple document blocks.

[0083] In one example, multiple diagnostic documents for handling database operation and maintenance issues may be collected.

[0084] In one example, each diagnosis document may be split by keywords, such as “tenant example”, “database usage example”, etc.

[0085] In one example, when splitting a diagnostic document, the size of each document block obtained by the splitting should not exceed the size of the largest document block that the large language model can process. For example, the large language model can process a maximum of 4000 tokens, and the size of each document block obtained by the splitting can be less than or equal to 4000 tokens. If the size of a document block is greater than 4000 tokens, it can continue to be split.

[0086] In one example, the purpose of the split is to allow the large language model to accurately summarize or indicate in advance using appropriate cues without missing any details.

[0087] Step S101 - 1 - 2 , constructing a summary tree for each of the diagnosis documents according to the chapter relationship.

[0088] In one example, the title of the diagnosis document may be used as the root node of the summary tree, and each document block may be used as another node of the summary tree, such as a leaf node.

[0089] In one example, each node of the summary tree may include the content of the document block and a summary of the content of the document block.

[0090] For example, for node i of the summary tree, its child nodes represent a subsection of chapter i. Node i consists of two parts: (1) the content of chapter i; (2) the summary of chapter i created by inputting the content into a large language model and using summary prompts, i.e., p summarize= "Briefly summarize the content provided... Your summary will serve as an index for others to find technical details related to database maintenance... Note the examples even if the content covers other topics." The generated summary serves as a text index for node i, making it possible to match document blocks with similar content or relationships (such as cross-references).

[0091] Step S101-1-3, delete the document block or add it to the existing knowledge block.

[0092] In one example, the large language model can parse the content of each document chunk i, including the content from node i and its child nodes, and compare it with the summaries of other document chunks with similar content. This process can be indicated by the extraction hint of the large language model, i.e., p extract = "Given a chunk summary, extract diagnostic experience from the chunk. If unsure, explore diagnostic experience in chunks from child nodes or chunks with similar summaries", thereby aggregating the chunks of documents with similar summary content

[0093] Through the above process, knowledge related to the key points in the summary can be detected.

[0094] In one example, for each detected knowledge C i , decide whether to keep C in a mixed way i Specifically, if the large language model represents C i If it is unlikely to be redundant (for example, it is determined based on the summary that part of the content of the document block is not included in the existing knowledge block), the document block can be added to the knowledge block. Otherwise, the document block can be deleted.

[0095] For example, C i Perform manual inspection and if any new knowledge or insights are found, even if C i There is a lot of overlap with some existing knowledge, so C can also be retained i This approach ensures that most diagnostic knowledge is stored in the local knowledge base and reduces the proportion of redundant information.

[0096] The above steps S101-1-1 to S101-1-3 may also be performed, for example Figure 7 As shown, by splitting the diagnostic document into chapters, initializing the summary tree, and generating a summary (i.e. Figure 7 ), thereby extracting document knowledge based on the generated summary tree and adding the document block to the knowledge block.

[0097] Step S101 - 2 , preparing tools required for database anomaly diagnosis.

[0098] In one example, at least one of the tools can be configured, and an API description can be provided for each tool, which can include: explaining the API's function, usage method, returned data type, etc. Each API can be registered in the prompt of the large language model so that the API can be used in the diagnosis process, thereby achieving the purpose of using the above tools.

[0099] The tools may include monitoring tools, optimization tools, etc. The specific contents have been introduced in the aforementioned embodiments and will not be repeated here.

[0100] In the above embodiment, the knowledge blocks and / or tools required for database anomaly diagnosis can be prepared in advance, thereby improving the accuracy and efficiency of diagnosis and having high usability.

[0101] Figure 3 FIG. 1 is a flowchart of another database operation and maintenance method provided by an exemplary embodiment. Figure 3 As shown, step S102 may include:

[0102] Step S102-1, generating description information of the current exception.

[0103] The description information may include but is not limited to at least one of the following: alarm occurrence time; exception summary; severity level; additional features.

[0104] Among them, serious results can be, for example, warnings or serious warnings.

[0105] Among them, additional features may include, for example, whether the anomaly has been resolved.

[0106] Step S102-2, matching the abnormality indicator in the description information with the tool required for database diagnosis, and determining the tool most relevant to the current abnormality.

[0107] In one example, considering the wide variety of tools used by different databases, such as monitoring, indexing, query rewriting, query hints, etc., the disclosed embodiment can adjust a pre-trained model to match the context of the description information, such as anomaly indicators, with the tools required for previously prepared database diagnosis, thereby determining the tool most relevant to the current anomaly.

[0108] Step S102-3: perform a keyword search on the knowledge blocks required for database diagnosis according to the abnormality indicators in the description information, and determine the knowledge blocks most relevant to the current abnormality.

[0109] In one example, the keyword search method may be, for example, the BM25 algorithm, to identify the knowledge block most relevant to the current anomaly.

[0110] Step S102-4, collecting historical messages.

[0111] In an example, the historical message may include, but is not limited to, historical tool call results and / or historical diagnosis records.

[0112] Step S102-5: Generate a diagnosis prompt message according to the prompt template.

[0113] In one example, a prompt template such as Figure 6 As shown, the large language model can generate a diagnostic prompt message based on the above description information, the tool most relevant to the current anomaly, the knowledge block most relevant to the current anomaly, and the historical message. The diagnostic prompt message is used to provide context-aware prompts to the target expert role during the database anomaly diagnosis process.

[0114] In the above embodiment, the generated diagnostic prompt message can be used to provide context-aware prompts to the large model during the diagnosis process without the need for human intervention, thus saving the DBA training cost. In addition, due to the use of a large language model, the existing operation and maintenance knowledge can be better utilized to infer the root cause of the current exception and / or the solution to the current exception.

[0115] Figure 4 FIG. 1 is a flowchart of another database operation and maintenance method provided by an exemplary embodiment. Figure 4 As shown, step S103 may include:

[0116] Step S103-1, constructing a root node of a search tree for the current exception.

[0117] In some embodiments, a search tree may be constructed for the current abnormality. First, a root node of the search tree may be constructed. The root node of the search tree may include but is not limited to a target of a diagnostic task and / or a diagnostic prompt message.

[0118] The goal of the diagnostic task may be, for example, to first analyze the current status in each state and use some tool API calls to change the state to the next state.

[0119] The diagnostic prompt information may include, for example, common diagnostic steps, available tool APIs, etc.

[0120] This step can guide the large language model to explore potential actions and promote the addition of new tree nodes.

[0121] Step S103-2: taking the root node of the search tree as the parent node, performing benefit evaluation on each leaf node to determine the total benefit score of each leaf node.

[0122] In some embodiments, in order to expand the search tree and select the optimal path to obtain the diagnosis result, the root node of the search tree can be used as the parent node, and the total benefit score of the existing leaf nodes can be evaluated according to the following criteria:

[0123] Temporary benefit score; Long-term benefit score; Selection frequency.

[0124] In one example, if the output of the current node (here referring to the current leaf node) includes a solution, the large language model can simulate the current exception and deploy the solution proposed by the leaf node through an optimization tool, thereby calculating the reduction in workload cost before and after implementing the solution. The reduction in workload cost is the first value, which can be used as the immediate benefit score of the current leaf node.

[0125] If the output of the current node (here, the current leaf node) does not include a solution, the immediate benefit score of the current node is 0. Of course, it can also be other values, such as a negative value, which is not limited in the present disclosure.

[0126] In one example, the evaluation of long-term effects can be performed by a large model with a local database. For example, the current node (here, the current leaf node) is used as a candidate, and detailed prompts are prepared, such as first analyzing all candidates, and then selecting the best candidate, etc., thereby specifying that the benefit score evaluator of the large model focuses on the following long-term evaluation dimensions:

[0127] Whether the current node can provide the diagnosis result; the degree to which the current node solves the current abnormality; the overlap rate between the diagnosis result provided by the current node and the diagnosis result provided by the ancestor node of the current node.

[0128] Whether the current node can provide the diagnosis result can also be referred to as the proximity of completing the task, for example, whether the current leaf node has a diagnosis result, such as whether there is a root cause and / or solution.

[0129] The degree to which the current node resolves the current anomaly may also be referred to as an anomaly resolution degree, such as a benefit value.

[0130] The efficiency of the current node in providing the diagnosis result may be, for example, the overlap rate between the diagnosis result provided by the current node and the diagnosis result provided by the ancestor node of the current node.

[0131] Exemplarily, the large model can convert the long-term benefit score of the current leaf node into the total number of valid votes through multiple rounds of voting by using the Upper Confidence Bound Apply to Tree (UCT) function.

[0132] In one example, the selection frequency of the current leaf node is equal to the maximum number of times an ancestor node of the current leaf node is selected plus 1.

[0133] The ancestor nodes include the parent node of the current leaf node, the parent node of the parent node, and all nodes extending upward along the path of the tree.

[0134] The formula for selecting the frequency is as follows:

[0135] Selection frequency = max(number of ancestor node selections) + 1

[0136] Assume that the ancestor nodes of a leaf node are A, B, and C, of ​​which A is selected 3 times, B is selected 2 times, and C is selected 1 time. Then the selection frequency of the current leaf node is 3+1=4.

[0137] Based on the above process, after the large model evaluates the immediate benefit score, long-term benefit score and selection frequency of the current leaf node respectively, the UCT function can be used to calculate the total benefit score of the current leaf node.

[0138] Step S103-3: adding the leaf node with the highest total benefit score as a new child node to the search tree.

[0139] In some embodiments, the large model can generate a new diagnostic prompt message based on the information of the leaf node with the highest total benefit score. The diagnostic prompt message is used to provide context-aware prompts to the target expert role during the database anomaly diagnosis process. The specific generation method has been introduced in the previous embodiment and will not be repeated here.

[0140] Furthermore, the new diagnostic prompt message can be decomposed into multiple paragraphs. If each paragraph begins with a preset field, it is determined that the new diagnostic prompt message indicates a legal behavior. The preset fields include but are not limited to "thinking", "action", and "input parameters", for example Figure 6 shown.

[0141] If at least one paragraph does not start with a preset field, it can be determined that the new diagnostic prompt message indicates illegal behavior, and the large model can regenerate a new diagnostic prompt message until the regenerated new diagnostic prompt message indicates legal behavior. Or when the number of times the new diagnostic prompt message is regenerated reaches the preset number, the large model can switch to other leaf nodes to continue exploration, or end the exploration. By regenerating new diagnostic prompt messages, the "hallucination" of the large model can be effectively avoided, and the diagnostic accuracy and efficiency of database operation and maintenance in complex scenarios can be improved.

[0142] When the new diagnostic prompt message indicates a legal behavior, the large model can generate a new child node in the exploration tree, wherein the new child node includes the diagnostic status information of the parent node, the new diagnostic prompt message, and the diagnostic result corresponding to the new child node, such as the obtained usage tool node and knowledge node.

[0143] The large model can add the new child node to the search tree, that is, add the leaf node with the highest total benefit score as a new child node to the search tree, thereby promoting the expansion and continuous updating of the exploration tree.

[0144] Step S103 - 4 , re-evaluate the total benefit score of each node on the path.

[0145] In some embodiments, the total benefit score of each node on the path from the root node to the new child node can be re-evaluated, for example, to prompt the big model to do some reflection to continue subsequent attempts. These contents can be added to the prompts of each node and can affect the big model's evaluation of the total benefit score.

[0146] In the embodiment of the present disclosure, the large model can determine nodes that do not include useful information based on the re-evaluated total benefit score. These nodes can be called designated nodes, and the large model can delete these designated nodes to improve diagnostic efficiency.

[0147] Furthermore, the new child node can be used as a new parent node, and the step of performing benefit evaluation on each leaf node and determining the total benefit score of each leaf node can be returned to execute until the number of iterations reaches a preset number and no new diagnosis result is identified.

[0148] In some embodiments, the large model may use the new child node in the exploration tree as a new parent node and return to execute the above steps 103 - 2 to 103 - 4 until the number of iterations reaches a preset number and no new diagnosis result is identified.

[0149] Step S103-5, obtaining the diagnosis result based on the content of the leaf node with the highest total benefit score.

[0150] In the above embodiment, the large model can automatically perform reasoning and can better utilize existing operation and maintenance knowledge to infer the root cause of the current exception and / or the solution to the current exception. It has good generalization and high availability, and improves the diagnostic accuracy and efficiency of database operation and maintenance in complex scenarios.

[0151] Figure 5 FIG. 1 is a flowchart of another database operation and maintenance method provided by an exemplary embodiment. Figure 5 As shown, step S104 may include:

[0152] Step S104 - 1 , multiple target expert roles simultaneously perform database anomaly diagnosis, and determine the diagnosis result provided by each target expert role as an alternative diagnosis result.

[0153] In some embodiments, the large model can initialize multiple expert roles based on the knowledge clustering results, and each expert role supports the use of different knowledge blocks and / or tools to solve a corresponding type of database operation and maintenance problems.

[0154] In order to avoid wasting resources and improve diagnostic efficiency, a description of the current anomaly is generated for the current anomaly, such as the time period when the anomaly occurred, the type of alarm, the severity, etc. Based on the description information, a large model such as GPT-4 can be used to select multiple target expert roles that are most relevant to the description information of the current anomaly. For example, for a high load (load_high) alarm, a CPU expert role can be selected, and for another example, for a memory overflow (out_of_memory) alarm, a memory expert role can be selected.

[0155] When multiple target expert roles are selected, each target expert role can perform database anomaly diagnosis simultaneously. For example, each target expert role adopts the above steps 103-1 to S103-5 to obtain corresponding diagnosis results. At this time, the diagnosis results obtained by each target expert role can be called alternative diagnosis results.

[0156] Step S104 - 2 : sharing the candidate diagnosis results among the plurality of target expert roles, so that each target expert role can modify the provided candidate diagnosis results.

[0157] In some embodiments, the diagnostic process can be augmented by an asynchronous communication mechanism. For example, the asynchronous communication mechanism is based on a publish-subscribe model. That is, a target expert role can publish its own findings or updates, which are automatically passed to other target expert roles that have subscribed to these specific types of updates. This enables sharing of respective alternative diagnostic results between multiple target expert roles.

[0158] Among them, the large model can analyze the alternative diagnosis results provided by each of the target expert roles, extract key information, and generate a summary corresponding to each alternative diagnosis result based on the key information.

[0159] For example, a target expert role requires dozens of iterations to provide in-depth analysis, resulting in a large number of analysis records. Therefore, it is crucial to effectively summarize key information from these records. To this end, the rows of the records (r t), including the input of a specific tool and the corresponding results, or related knowledge. Specifically, for each step t, a cumulative summary (s t-1 ), encapsulates the previous actions and results. t When a large model is assigned to r t The main ideas of t-1 , thus obtaining a new summary s t .

[0160] Furthermore, each target expert role may make suggestions for improving the alternative diagnosis results and the summary provided by each target expert role based on the alternative diagnosis results and the summary provided by other target expert roles. review = "Please review the above diagnostic results and provide necessary suggestions to correct erroneous analysis or unclear results."

[0161] Furthermore, after cross-examination, the alternative diagnosis results provided by each of the target expert roles can be re-evaluated, and even more inferences can be made, such as the survey tool analyzing more relevant abnormal indicators or settings. Additional evidence can be incorporated through the above process to correct the alternative diagnosis results provided by each of the target expert roles.

[0162] Step S104 - 3 , obtaining the diagnosis result based on the candidate diagnosis results corrected by the multiple target expert roles.

[0163] In one example, the current abnormal diagnosis result may be determined based on the alternative diagnosis results corrected by the multiple target expert roles, and illustratively, a detailed diagnosis report may be generated.

[0164] The diagnostic report may include but is not limited to at least one of the following:

[0165] Exception overview (title); exception date; detailed exception description information (such as explanation of alarm rules); root cause of the exception (which can be obtained from the above diagnosis results); solution (which can be obtained from the above diagnosis results); detailed diagnosis process.

[0166] In the above embodiment, multiple target expert roles can perform collaborative diagnosis to infer the root cause of the current exception and / or the solution to the current exception, which has good generalization and high availability, and improves the diagnostic accuracy and efficiency of database operation and maintenance in complex scenarios.

[0167] The above process is further illustrated below with examples.

[0168] The disclosed embodiment provides a database system operation and maintenance method, which extracts offline knowledge from documents, prepares functional APIs from existing tools, matches appropriate knowledge and APIs to large model prompts for online diagnosis, and supports a tree search-based algorithm to accurately and effectively use tools and combine knowledge for analysis. In addition, the disclosed embodiment also designs a collaborative diagnosis mechanism to improve the accuracy and efficiency of diagnosis through the cooperation of multiple large models.

[0169] The system operation and maintenance method of the above database has a flow chart as follows: Figure 6 As shown, the specific steps include:

[0170] (1) Prepare the knowledge and tools required for offline database diagnosis.

[0171] (1-1) Figure 7 As shown, since diagnostic documents are uncommon in the pre-training corpus and some parts of the documents have relationships such as cross-references, document knowledge extraction is performed, a summary tree representing the document structure is established, and knowledge blocks are extracted from the tree (for example, traversing parent-child nodes or nodes with similar summaries and reference relationships).

[0172] (1-1-1) Split documents based on the structure and content of sections (e.g., split applications by keywords such as "tenant examples"). If a chunk exceeds the maximum chunk size that the big model can handle (e.g., 4000 tokens), further recursively split it into smaller chunks. This allows the big model to accurately summarize or extract knowledge using appropriate hints (e.g., "avoid missing any details").

[0173] (1-1-2) Next, based on the chapter relationship, a tree structure is initialized, where the root node is the document title and other nodes represent segmented document blocks. For each node i, its child nodes represent a subsection of chapter i. Node i consists of two parts: (1) the content of chapter i; (2) the summary of chapter i created by inputting the content into the large model and using the summary prompt, i.e., p summarize = "Briefly summarize the content provided... Your summary will serve as an index for others to find technical details related to database maintenance... Note the examples even if the content covers other topics." The generated summary serves as a text index for node i, allowing matching of blocks with similar content or relationships (such as cross-references).

[0174] (1-1-3) After generating the summary tree, the large model parses each document block i (containing the content from node i and its children) and compares it with the summaries of other blocks with similar content. This process is guided by the extraction hint, i.e., p extract= "Given a chunk's summary, extract diagnostic experience from the chunk. If unsure, explore diagnostic experience in chunks from child nodes or chunks with similar summaries."

[0175] In this way, knowledge related to the key points in the summary is detected. For each detected knowledge C i , decide whether to keep C in a mixed way i Specifically, if the large model represents C i is unlikely to be redundant (compared to existing knowledge), the knowledge block will be added. Otherwise, i Perform manual inspection and if any new insights are found, even if C i There is a significant overlap with some existing knowledge, and C can also be retained i This approach ensures that most diagnostic knowledge is stored in the local knowledge base and reduces the proportion of redundant information.

[0176] (1-2) Tool preparation: Configure the diagnostic tool and provide an API description, including an explanation of the API's functions, usage methods, returned data types, etc. And register the API to the prompt of the large model for use in the diagnostic process.

[0177] (2) Expert role generation: All extracted knowledge blocks are clustered and a prompt template (e.g., expert role, task description, basic diagnostic steps, available tools, etc.) is generated for each cluster to represent the characteristics of a large model expert. For example, a large model expert is responsible for analyzing CPU problems (knowledge) and can use tools such as cpu_usage_api and index_tuning_api. In this way, each large model expert handles a specific database problem domain.

[0178] (2-1) Diagnostic prompt generation. When all necessary knowledge and tools are in place, diagnostic prompt generation is responsible for creating context-aware prompts that guide the diagnostic process. According to the prompt template, each new prompt in actual diagnosis requires three basic types of information:

[0179] (2-1-1) Exception description. The triggered alert, including the time of occurrence, exception summary, severity level (e.g., warning or critical), and additional features (e.g., "resolved" exception status).

[0180] (2-1-2) Tool preparation. Due to the wide variety of tools used by different databases (e.g., monitoring, indexing, query rewriting, query hints), the invention fine-tunes a pre-trained Sentence-BERT model to match the current context (e.g., when the big model does not know which indicator is abnormal) and related tools (e.g., fetch_abnormal_metrics API).

[0181] (2-1-3) Knowledge block preparation. Instruct the big model on how to use the acquired abnormal indicators for diagnosis. Use keyword search methods (e.g., BM25 algorithm) to identify the most relevant knowledge blocks.

[0182] (2-1-4) History messages, contain important information such as past tool call results, which are critical for tree search-based diagnosis (e.g., making decisions through previous steps).

[0183] (3) Figure 8 As shown in the figure, tree search-based diagnosis. Tree search-based diagnosis aims to identify potential root causes and solutions using generated prompts (calling tools or following knowledge analysis). For database diagnosis, large models face challenges such as hallucinations and unstable large model reactions (e.g., wrong API requests, overly broad analysis), which may lead to diagnostic failure. To address this problem, a thinking tree strategy is adopted, in which the large model explores multiple possible reasoning chains and selects the most beneficial chain to explore (based on the voting and selection frequency mechanism of the large model). In addition, through the reflection mechanism, the large model can trace back to the previous step when the current step fails to find useful information, significantly increasing the possibility of obtaining reasonable diagnostic results.

[0184] (3-1) Start building a search tree with "Input Parameters" as the root node, which contains the goal of the task (e.g., "At each state, you first need to analyze the current situation and use some tool API calls to change the state to the next state...") and related input information, such as common diagnostic steps and available tool APIs. This initial step guides the large model to explore potential actions and promotes the addition of new tree nodes.

[0185] (3-2) In order to expand the search tree, the benefit scores of existing leaf nodes are first evaluated according to three criteria, including immediate benefit feedback in the database, long-term benefit of the large model enhanced with knowledge, and selection frequency.

[0186] (3-2-1) The immediate benefit is calculated by simulating an anomaly in the database, deploying the proposed solution (through an optimization tool), and measuring the reduction in workload cost when the output of the node contains a solution; otherwise, the immediate benefit is set to zero.

[0187] (3-2-2) Long-term benefits are evaluated by a large model with a local knowledge base. With existing leaf nodes as candidates, detailed prompts are prepared (e.g., “First analyze all candidates, then select the best candidate…”) to guide the large model evaluator to focus on (1) the closeness of completing the task (e.g., whether there is a root cause or solution), (2) the degree of anomaly resolution (e.g., the immediate benefit value), and (3) the efficiency of anomaly resolution (e.g., the overlap rate with the analysis results of ancestor nodes). Through multiple rounds of voting, the long-term benefits of leaf nodes are quantified as the total number of valid votes.

[0188] (3-2-3) The selection frequency is calculated as the maximum number of times an ancestor node is selected plus one.

[0189] (3-2-4) Based on steps (1-1-2-1) to (1-1-2-3), apply the UCT function to calculate the total benefit score of the leaf node.

[0190] (3-3) Expand a new child node of an existing tree node with the highest benefit score (if there are multiple ties, select one randomly). This involves prompting the large model with the information of the selected node to suggest new effective actions, which is mainly divided into four sub-steps:

[0191] (3-3-1) Input the information in the selected node, and the big model generates a "new message" as a suggested action.

[0192] (3-3-2) Break the new message into paragraphs (e.g., separated by newline characters), and check whether the first three paragraphs start with "thinking", "action", and "input parameters", respectively. If so, the message represents a legal action. Otherwise, the message is an illegal action that requires the large model to be regenerated (e.g., regenerated up to three times, and then switched to other nodes or ended exploration).

[0193] (3-3-3) Generate a new node, which contains the diagnosis status of its parent node, the message generated by the large model, and the result information. The result information is the result (tool node) or knowledge retrieval result (knowledge node) of executing the command synthesized from the "action" and "input parameter" segments.

[0194] (3-3-4) Add this new node as a child node to the selected tree node, facilitating its expansion and continuous updating of the search tree.

[0195] (3-4) For each node on the path from the root node to the selected node, the benefit of taking the action is re-evaluated using the big model (e.g., the prompt "do some reflection to carry forward to the next attempt"), which is added to the prompt of the child node and affects the evaluation of the big model during the calculation of the benefit score. Nodes that are considered to contain no useful information are marked as "pruned" to improve the diagnostic efficiency.

[0196] (3-5) Repeat the above steps (3-2) to (3-4). If no new root cause (leaf node with effective solution) is identified within a certain number of iterations (e.g., 20 steps), the algorithm terminates by outputting the root cause and solution of the leaf node with the highest benefit score.

[0197] (4) Since the cost of tree search-based diagnosis increases with the knowledge of the equipment and the number of tools, the collaborative diagnosis mechanism aims to utilize multiple large model experts to improve the diagnosis performance.

[0198] (4-1) Initialize multiple large model experts based on the knowledge clustering results. Each expert is equipped with different knowledge and necessary tools.

[0199] (4-2) Next, in order to avoid wasting resources and improve diagnostic efficiency, given an anomaly, first generate a description of the anomaly (e.g., time period, alarm type, severity, etc.). Then, based on the anomaly description, use a large model (e.g., GPT-4) to select a group of experts most relevant to the anomaly description. For example, for a load_high alarm, select a CPU expert; for an out_of_memory alarm, select a memory expert.

[0200] (4-3) The selected experts perform diagnosis simultaneously. Each expert has a unique role setting and domain knowledge. The diagnosis process is enhanced through an asynchronous communication mechanism, which is built on a publish-subscribe model. That is, the experts "publish" their findings or updates, and then this information is automatically "delivered" to other experts who have subscribed to these specific types of updates (e.g., all other selected experts).

[0201] (4-4) All participating large model experts discover and correct diagnostic errors made by other experts through cross-examination, thus ensuring a more accurate diagnosis.

[0202] (4-4-1) An expert needs dozens of iterations to provide in-depth analysis, which results in a large number of analysis records. Therefore, it is crucial to effectively summarize key information from these records. To this end, the rows of the records are gradually summarized (r t ), including the input of a specific tool and the corresponding results, or related knowledge. Specifically, for each step t, a cumulative summary (s t-1 ), encapsulates the previous actions and results. t When a large model is assigned to r t The main ideas of t-1 , thus obtaining a new summary s t .

[0203] (4-4-2) Next, each expert makes suggestions for improvement based on the other experts’ diagnostic results and the summarized procedures. Review prompts writing, p review = "Please review the above diagnostic results and provide necessary suggestions to correct erroneous analysis or unclear results."

[0204] (4-4-3) After cross-review, each expert re-evaluates their initial diagnosis and even makes more inferences (e.g., calling the tool to analyze more relevant indicators or settings). In this way, they can incorporate additional evidence, revise assumptions, or overlook aspects in the diagnosis results.

[0205] (4-5) Based on the diagnosis results of the selected experts, a detailed diagnosis report is generated for a given anomaly, including (1) title (anomaly overview), (2) anomaly date, (3) detailed anomaly description (e.g., explanation of the alarm rule), (4) root cause (extracted from the diagnosis results), (5) solution (extracted from the diagnosis results), and (6) detailed diagnosis process.

[0206] An embodiment of the method of the present invention is described below. The flowchart of the embodiment is as follows: Fig. 9 As shown:

[0207] The knowledge base and tools for assuming the data of the method of the present invention have been constructed in advance, and the abnormality diagnosis process in the database is as follows:

[0208] (1) When the database status becomes abnormal, the abnormal monitoring will trigger an alarm input to the abnormality analyzer;

[0209] (2) Based on the alarm in step (1) and basic database information (e.g., query statistics during the alarm period), the anomaly analyzer generates an anomaly description.

[0210] (3) Based on the anomaly description generated in step (2), select relevant large model experts (e.g., CPU experts and slow query experts) for the given anomaly.

[0211] (4) Based on the given knowledge and tools, context-aware prompts are created for each big model expert selected in step (3) to guide big model expert diagnosis, including (i) role description, which outlines the expertise and responsibilities of the big model; (ii) anomaly description, which provides details of the triggered alarm (e.g., occurrence time, anomaly summary, severity level); (iii) diagnostic tools (e.g., monitoring, indexing, query optimization) matched to the diagnostic context through the fine-tuned Sentence-BERT model; (iv) knowledge blocks identified through keyword search methods (e.g., BM25); and (v) historical messages, which provide necessary background information (e.g., previous tool call results) to help the subsequent tree search-based diagnosis.

[0212] (5) Based on the hints generated in step (4), the tree search strategy guided the CPU large model expert to explore three reasoning chains and ten diagnostic steps, and finally selected the chain with the highest benefit value (based on database feedback and large model voting evaluation) as the expert's diagnosis result.

[0213] (6) The experts selected in step (3) perform asynchronous diagnosis (using different tools and knowledge blocks) and refine the diagnostic findings through cross-review.

[0214] (7) The selected large model experts collaborate to generate an analysis report on input anomalies.

[0215] It should be noted that in Fig. 9 Typical anomalies include but are not limited to at least one of the following: slow query execution (also known as slow query); full system resources; database downtime; database crash, etc. For this typical anomaly, after database macro-indicator analysis, database fine-grained indicator analysis, and database session analysis, analysis results are obtained to determine the root cause of the typical anomaly. For example, the root cause of slow query includes but is not limited to complex query structure, the root cause of full system resources includes but is not limited to load non-conflict, large table data insertion, etc., the root cause of database downtime may include but is not limited to long-running query, deadlock, etc., and the root cause of database crash may include but is not limited to disk control full...

[0216] In the above embodiments, tools can be used to collect scenario information, such as query analysis based on flame graphs, or to promote optimization solutions, such as selecting appropriate index combinations, so as to achieve the purpose of accurate inference. In addition, basic logical reasoning can be performed to formulate reasonable diagnostic activations, save costs and time costs, and to a certain extent reduce the operation and maintenance pressure of human DBAs, such as solving typical anomalies that cannot be supported by empirical rules. In addition, the large model used in the present disclosure has high generalization and high flexibility.

[0217] In some embodiments, Fig.10 As shown, Fig.10 1 is a schematic diagram of a database operation and maintenance device provided by an exemplary embodiment, the device comprising:

[0218] Determination module 1001, for determining, in response to detecting a database anomaly, a target expert role corresponding to the current anomaly from among pre-generated expert roles; wherein each expert role supports processing a type of database operation and maintenance problem;

[0219] The inference module 1002 is used to perform database anomaly diagnosis by the target expert role in a tree search manner to obtain a diagnosis result; wherein the diagnosis result includes the root cause of the current anomaly and / or a solution to the current anomaly.

[0220] Fig.11 is a schematic structural diagram of a server provided by an exemplary embodiment. Fig.11 At the hardware level, the device includes a processor 1102, an internal bus 1104, a network interface 1106, a memory 1108, and a non-volatile memory 1110, and may also include hardware required for other functions. One or more embodiments of this specification can be implemented based on software. For example, a large model is deployed on the server, and the processor 1102 reads the corresponding computer program from the non-volatile memory 1110 to the memory 1108 and then runs it. Of course, in addition to the software implementation, one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0221] Based on the same concept as the above method, this specification also provides a computer-readable storage medium on which computer instructions are stored. When the instructions are executed by a processor, the steps of the method described in any of the above embodiments are implemented.

[0222] Based on the same concept as the above method, this specification also provides a computer program product, including a computer program / instruction, which implements the steps of the method described in any of the above embodiments when executed by a processor.

[0223] In addition, the present disclosure also provides a database operation and maintenance system, which may include a database; a large language model; wherein the model may execute the steps of the method described in any of the above embodiments.

[0224] Those skilled in the art will readily appreciate other embodiments of the specification after considering the specification and practicing the invention claimed herein. The specification is intended to cover any variations, uses or adaptations of the specification that follow the general principles of the specification and include common knowledge or customary techniques in the art that are not claimed in the specification. The specification and examples are to be considered exemplary only, and the true scope and spirit of the specification are indicated by the following claims.

[0225] It should be understood that the present description is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present description is limited only by the appended claims.

[0226] The above description is only a preferred embodiment of this specification and is not intended to limit this specification. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of this specification should be included in the scope of protection of this specification.

Claims

1. A database operation and maintenance method, characterized in that: The method comprises: In response to detecting a database anomaly, determining a target expert role corresponding to the current anomaly from among pre-generated expert roles; wherein each expert role supports handling a type of database operation and maintenance problem; According to the tree search method, the target expert role performs database anomaly diagnosis to obtain a diagnosis result; wherein the diagnosis result includes the root cause of the current anomaly and / or a solution to the current anomaly; The method further comprises at least one of the following: Acquire the knowledge blocks needed to diagnose database anomalies; Get the tools you need to diagnose database anomalies; The acquisition of knowledge blocks required for database abnormality diagnosis includes: Each diagnostic document is split according to the chapter structure and chapter content to obtain multiple document blocks; wherein the diagnostic document is used to handle database operation and maintenance issues; According to the chapter relationship, a summary tree is constructed for each of the diagnostic documents; wherein the root node of the summary tree is the title of the diagnostic document, and each leaf node corresponds to one of the document blocks; wherein each node of the summary tree includes the content of the document block and a summary of the content of the document block; If it is determined based on the summary that the content of the document block is already included in an existing knowledge block, deleting the document block; and / or If it is determined based on the summary that part of the content of the document block is not included in the existing knowledge block, adding the content of the document block to the existing knowledge block; The acquisition of tools required for database anomaly diagnosis includes: Configure at least one of the tools and provide an application programming interface API description for each of the tools; Registering each API to support the use of each of the APIs; Wherein, the method further comprises: Generate description information of the current exception; Matching the abnormality indicator in the description information with the tools required for database diagnosis to determine the tool most relevant to the current abnormality; According to the abnormality index in the description information, a keyword search is performed on the knowledge blocks required for database diagnosis to determine the knowledge block most relevant to the current abnormality; Collecting historical messages; wherein the historical messages include historical tool call results and / or historical diagnostic records; According to the prompt template, a diagnostic prompt message is generated based on the description information, the tool most relevant to the current exception, the knowledge block most relevant to the current exception, and the historical message; wherein the diagnostic prompt message is used to provide context-aware prompts to the target expert role during the database exception diagnosis process.

2. The method according to claim 1, characterized in that The number of the target expert roles is 1, and the target expert roles perform database anomaly diagnosis in a tree search manner to obtain a diagnosis result, including: Constructing a root node of a search tree for the current exception; wherein the root node of the search tree includes a target of a diagnostic task and / or a diagnostic prompt message; Taking the root node of the search tree as the parent node, performing benefit evaluation on each leaf node, and determining the total benefit score of each leaf node; Adding the leaf node with the highest total benefit score as a new child node to the search tree; Re-evaluate the total benefit score of each node on the path; wherein the path is the path from the root node to the new child node; adding the re-evaluated total benefit score of each node to the corresponding node, and deleting the designated node; wherein the designated node is a node determined to not include useful information based on the re-evaluated total benefit score; The new child node is used as a new parent node, and the step of performing benefit evaluation on each leaf node to determine the total benefit score of each leaf node is returned until the number of iterations reaches a preset number and no new diagnosis result is identified; The diagnosis result is obtained based on the content of the leaf node with the highest total benefit score.

3. The method according to claim 2, characterized in that The method further comprises: If the output of the current node includes a solution, the instant benefit score of the current node is a first value, otherwise the instant benefit score of the current node is 0; wherein the first value is equal to the reduction in workload cost before and after implementing the solution calculated by simulating the current anomaly and deploying the solution; For each long-term evaluation dimension, the score of the current node is quantified to determine the long-term benefit score of the current node; wherein the long-term evaluation dimension includes at least one of the following: whether the current node can provide the diagnosis result; the degree to which the current node solves the current abnormality; the efficiency of the current node in providing the diagnosis result; The selection frequency of the current node is equal to the maximum number of times the ancestor node of the current node is selected plus 1; Based on the immediate benefit score, the long-term benefit score and the selection frequency of the current node, the total benefit score of the current node is calculated.

4. The method according to claim 2, characterized in that: The step of adding the leaf node with the highest total benefit score as a new child node to the search tree includes: Based on the information of the leaf node with the highest total benefit score, a new diagnosis prompt message is generated; wherein the diagnosis prompt message is used to provide context-aware prompts to the target expert role during the database anomaly diagnosis process; In the case where the new diagnostic prompt message indicates a legal behavior, a new child node is generated in the search tree; wherein the new child node includes the diagnostic status information of the parent node, the new diagnostic prompt message and the diagnostic result corresponding to the new child node; Add the new child node to the search tree.

5. The method according to claim 4, characterized in that The method further comprises: Decomposing the new diagnostic prompt message into paragraphs; If each paragraph begins with a preset field, it is determined that the new diagnosis prompt message indicates a legal behavior.

6. The method according to claim 1, characterized in that The number of the target expert roles is multiple, and the target expert roles perform database anomaly diagnosis in a tree search manner to obtain a diagnosis result, including: The database anomaly diagnosis is performed by a plurality of target expert roles simultaneously, and the diagnosis result provided by each target expert role is determined as an alternative diagnosis result; Sharing the candidate diagnosis results among a plurality of the target expert roles, so that each of the target expert roles can modify the provided candidate diagnosis results; The diagnosis result is obtained based on the candidate diagnosis results corrected by the multiple target expert roles.

7. The method according to claim 6, characterized in that The step of sharing the candidate diagnosis results among the plurality of target expert roles so that each target expert role modifies the provided candidate diagnosis results includes: Analyze the alternative diagnosis results provided by each target expert role to extract key information; Based on the extracted key information, generating a summary corresponding to each of the candidate diagnosis results; According to the alternative diagnosis results and summaries provided by the multiple target expert roles, adjusting the alternative diagnosis results and the summary provided by each target expert role; The alternative diagnosis results provided by each target expert role are re-evaluated so that each target expert role modifies the provided alternative diagnosis results.

8. The method according to any one of claims 1 to 7, characterized in that: Determining a target expert role corresponding to the current anomaly from among the pre-generated expert roles includes: Based on the description information of the current exception, among the pre-generated expert roles, an expert role that best matches the description information is determined as the target expert role.

9. A database operation and maintenance system, characterized in that: The system comprises: database; A large language model, wherein the model is used to perform the steps of the method described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that: Computer instructions are stored thereon, and when the instructions are executed by a processor, the steps of the method according to any one of claims 1 to 8 are implemented.

Images