An AI-based database intelligent operation and maintenance method and device

Abstract

This invention relates to the field of database technology, and in particular to an AI-based intelligent database operation and maintenance method and apparatus. The method includes collecting raw data from different dimensions; preprocessing and extracting features from the raw data of each dimension; integrating features from the same time window across different dimensions to obtain a feature vector; acquiring the target feature vector corresponding to the current time window; performing collaborative analysis on the target feature vector to obtain detection results, predicted events, and abnormal events generated based on the detection results; reasoning about the abnormal events to determine their root causes; comprehensively analyzing the abnormal events, predicted events, and root causes; dynamically selecting a self-healing strategy from a preset strategy library; and using an automated script to run the self-healing strategy to restore the database. This invention can reduce the time-consuming and labor-intensive manual troubleshooting steps in traditional operation and maintenance, and shorten the average database recovery time.

Description

Technical Field

[0001] This invention relates to the field of database technology, and in particular to an AI-based intelligent database operation and maintenance method and apparatus. Background Technology

[0002] With the deepening of digital transformation, databases, as core foundational software, are directly related to the continuity of enterprise business in terms of stability, reliability, and performance. Therefore, database operation and maintenance work has become increasingly important and complex. In order to cope with the growing scale of database clusters and complex operating environments, major database vendors have launched centralized operation and maintenance management platforms.

[0003] Taking the leading domestic database, DM Database, as an example, DM Database provides DM Enterprise Manager (DEM). DEM is a web-based browser and server architecture (B / S) application that enables centralized monitoring and management of remote hosts and database instances by deploying agent services (hereinafter referred to as dmagent) on various database hosts. DEM is a powerful tool that integrates traditional desktop management tools, enabling unified management of individual database instances, data guardian clusters, read / write splitting clusters, data sharing clusters, and MPP (Massively Parallel Processing) clusters. Its main functions include: providing a wizard-driven interface to simplify the deployment, configuration, and startup / shutdown of various clusters; real-time monitoring of database instance running status, session, memory, and disk usage performance metrics, supporting custom alarm thresholds and sending alarms when metrics exceed these thresholds; providing a graphical interface for managing tables, indexes, users, and other objects in the database, and offering Structured Query Language (SQL) query and debugging tools; supporting the configuration of backup strategies and recovery operations; and managing database system parameters.

[0004] While traditional operations and maintenance (O&M) platforms like DM (Database Management Platform) are powerful, they primarily address database manageability and monitorability. They still have significant shortcomings in terms of intelligence and automation. For example, fault diagnosis heavily relies on human experience. When an alarm occurs, the database administrator (DBA) needs to log into the system, manually check various performance indicators, analyze massive amounts of log files, and combine their professional knowledge and experience to determine the root cause of the fault. This process is time-consuming, labor-intensive, and inefficient, and the accuracy of the diagnosis is highly dependent on the DBA's individual skill level. Furthermore, although traditional O&M platforms can execute some automated scripts, these usually require manual triggering and lack a complete automated closed loop from problem discovery to analysis to resolution. For instance, DEM can monitor disk space, but when space is running low, it can only issue an alarm and cannot automatically perform cleanup or expansion operations. This lack of self-healing capability leads to long system recovery times.

[0005] Therefore, overcoming the shortcomings of the existing technology is an urgent problem to be solved in this technical field. Summary of the Invention

[0006] In response to the above-mentioned deficiencies or improvement needs of existing technologies, this invention proposes an AI-based intelligent database operation and maintenance method and device, which can reduce the time-consuming and labor-intensive manual troubleshooting process in traditional operation and maintenance, and shorten the average database recovery time.

[0007] The embodiments of the present invention adopt the following technical solutions: In a first aspect, the present invention provides an AI-based intelligent database operation and maintenance method, specifically: collecting first raw data of different dimensions from the managed database; The first raw data of each dimension is preprocessed and features are extracted. Features from the same time window from different dimensions are integrated to obtain a feature vector. Obtain the target feature vector corresponding to the current time window, perform collaborative analysis on the target feature vector, and obtain the detection results, predicted events, and abnormal events generated based on the detection results; Based on a pre-constructed knowledge graph, the abnormal events are reasoned to obtain the root cause of the abnormal events; By comprehensively analyzing the abnormal events, the predicted events, and the root causes, a self-healing strategy is dynamically selected from a preset strategy library; and an automated script is used to run the self-healing strategy to restore the database.

[0008] Preferably, the method further includes: Based on the target feature vector, anomaly detection is performed on the database's operating status in the current time window, and detection results are generated. Based on the target feature vector, if it is predicted that the database will experience a specific failure within the target time window, a corresponding predicted event is generated. When the detection result is abnormal, the target feature vector corresponding to the detection result is obtained, and the detection result is classified based on the target feature vector to obtain the abnormal event.

[0009] Preferably, the step of performing anomaly detection on the database's operating status within the current time window based on the target feature vector and generating detection results includes: The target feature vector is input into a pre-trained unsupervised learning model to obtain an anomaly score output by the unsupervised learning model that deviates from the normal operation state of the database. If the abnormal score is greater than the dynamic threshold, the detection result is abnormal; if the abnormal score is less than or equal to the dynamic threshold, the detection result is normal.

[0010] Preferably, the step of generating a corresponding predicted event based on the target feature vector if it is predicted that the database will experience a specific failure within a target time window includes: The target feature vector is reconstructed to obtain the reconstruction error; The reconstruction error is continuously judged. If the reconstruction error continues to be greater than the normal threshold, long-term time-series prediction is performed based on the target feature vector to obtain the prediction sequence within the target time window and generate the prediction event.

[0011] Preferably, the step of reasoning about the abnormal event on a pre-constructed knowledge graph to obtain the root cause of the abnormal event includes: Determine the first target node corresponding to the abnormal event in the knowledge graph; Starting from the first target node, search downwards using a depth-first search method until a leaf node is reached or a preset maximum depth is reached, and the node at which the search stops is taken as the terminal node. Based on the terminal node, a predefined query rule is matched, and the query rule is used to query the database to locate the root cause of the abnormal event.

[0012] Preferably, the step of comprehensively analyzing the abnormal event, the predicted event, and the root cause, and dynamically selecting a self-healing strategy from a preset strategy library, includes: Among all the strategies in the preset strategy library, candidate self-healing strategies that partially or completely match the abnormal event, the predicted event, and the root cause are obtained. The performance metrics of each candidate self-healing strategy are weighted and summed to obtain the final score of each candidate self-healing strategy. The candidate self-healing strategy with the highest score is selected as the self-healing strategy.

[0013] Preferably, the method further includes: Collect secondary raw data from multiple levels and different dimensions from the managed database; Map and align the entities in the second original data with unique identifiers; By collaboratively analyzing the call chain and static dependency files, entities with unique identifiers are associated to build the dependency relationships between entities; The entities and dependencies are added to the knowledge graph to obtain a full dependency graph, which is then used to identify the root cause of the problem.

[0014] Preferably, the method further includes: Determine the second target node corresponding to the abnormal event in the full dependency graph; Starting from the second target node, identify all candidate cause paths originating from the target node in the full dependency graph, and update the initial weight of each node on the candidate cause path according to the call chain within the abnormal time window; Based on the updated initial weights of each node on the candidate cause path, and combined with the path information of the candidate cause path, the credibility of each candidate cause path is calculated. The candidate cause path with the highest credibility is taken as the root cause path, and the root cause result is generated based on each node on the root cause path.

[0015] Preferably, the method further includes: Obtain at least one search node that is directly connected to the second target node; For a search node, check whether there is a call chain from the second target node to the search node within the abnormal time window for the entity corresponding to the search node; If a call chain exists, the initial weight of the search node is increased; if no call chain exists, the initial weight of the search node is decreased. Continue searching downwards from the search node to the next search node, and change the initial weight of each search node according to the call chain, until a leaf node is reached or the preset maximum depth is reached, to obtain the candidate cause path after the initial weight change.

[0016] Secondly, the present invention provides an AI-based intelligent database operation and maintenance device, the device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the processor to perform the AI-based intelligent database operation and maintenance method of the first aspect.

[0017] Thirdly, the present invention also provides a non-volatile computer storage medium storing computer-executable instructions, which are executed by one or more processors to perform the AI-based intelligent database operation and maintenance method described in the first aspect.

[0018] Compared with existing technologies, the advantages of this invention are as follows: Based on the existing DEM architecture, it integrates artificial intelligence technology to construct a closed-loop intelligent operation and maintenance system that integrates data collection, intelligent analysis, and decision execution. It collects multi-dimensional data from the database in real time and uses a knowledge graph-driven inference engine to automatically perform cause analysis on abnormal events, quickly locating the root cause. Based on preset strategies or dynamically generated repair plans, it automatically triggers execution actions to achieve self-healing of faults. The entire process requires no manual intervention, significantly reducing the time-consuming and labor-intensive manual troubleshooting steps in traditional operation and maintenance, and also significantly shortening the average database recovery time. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments of the present invention will be briefly described below. Obviously, the drawings described below are merely some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without any creative effort.

[0020] Figure 1 This is an architecture diagram of an AI-based intelligent database operation and maintenance system provided in an embodiment of the present invention; Figure 2 This is a flowchart illustrating an AI-based intelligent database operation and maintenance method provided in an embodiment of the present invention. Figure 3 This is a schematic flowchart of the root cause analysis method provided in an embodiment of the present invention; Figure 4 This is a flowchart illustrating the method for constructing a fully dependent graph provided in an embodiment of the present invention; Figure 5 This is a flowchart illustrating the method for root cause analysis based on a full dependency graph provided in an embodiment of the present invention. Figure 6 A schematic diagram of the structure of an AI-based intelligent database operation and maintenance device provided in an embodiment of the present invention; The reference numerals in the attached figures are as follows: 21: Processor; 22: Memory. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0022] Unless the context otherwise requires, throughout the specification and claims, the term "comprising" is interpreted as openly inclusive, meaning "including, but not limited to." In the description of the specification, terms such as "one embodiment," "some embodiments," "exemplary embodiment," "example," "specific example," or "some examples" are intended to indicate that a particular feature, structure, material, or characteristic associated with that embodiment or example is included in at least one embodiment or example of this disclosure. The illustrative representations of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics mentioned may be included in any suitable manner in any one or more embodiments or examples; that is, although they may be incorporated into embodiments or examples using the above terms for reasons such as order and position, it does not limit them to be incorporated in combination by a single embodiment or example.

[0023] In the description of this invention, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of embodiments of this disclosure, unless otherwise stated, "a plurality of" means two or more. Furthermore, for example, the description may use the prefix "A" or "B" to describe the same type of nouns as two independent entities. In this case, the corresponding features defined with "A" and "B" are used only to distinguish between similar entities and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features.

[0024] In the description of this invention, the expression “A and / or B” (where A and B are used to formally represent specific features) will be used. The corresponding expression includes the following three combinations: only A, only B, and a combination of A and B.

[0025] As used in this invention, “about,” “approximately,” or “approximately” includes the stated value and the average value within an acceptable range of deviation from a particular value, wherein the acceptable range of deviation is determined by a person skilled in the art taking into account the measurement under discussion and the error associated with the measurement of the particular quantity (i.e., the limitations of the measurement system).

[0026] Furthermore, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0027] Example 1: This invention provides an AI-based intelligent database operation and maintenance method, which is applied to an AI-based intelligent database operation and maintenance system. (See reference...) Figure 1 The database intelligent operation and maintenance system architecture can be divided into four layers: data acquisition layer, data processing and analysis layer, intelligent decision-making and execution layer, and presentation and interaction layer. It exists as an enhancement module for the DEM platform. Specifically, the data acquisition layer collects data (including performance metrics, logs, configuration data, etc.) from the DM8 database / cluster via the dmagent agent; the data processing and analysis layer includes a data preprocessing module and an Artificial Intelligence (AI) model engine. The AI ​​model engine includes an intelligent anomaly detection module, a fault prediction module, and a fault classification and diagnosis module, used to analyze the processed data and output detection results, predicted events, and classified events; the intelligent decision-making and execution layer includes a Root Cause Analysis (RCA) module, a policy engine and knowledge base, and a self-healing and optimization execution module. The RCA module performs root cause analysis and obtains self-healing strategies for resolving anomalies based on the policy engine and knowledge base. The self-healing and optimization execution module automatically executes the self-healing strategies upon receiving them; the presentation and interaction layer is an extended DEM web interface used to receive execution results or status feedback and display them to the DBA.

[0028] like Figure 2 As shown, based on Figure 1 The present invention provides an AI-based intelligent database operation and maintenance system. Embodiment 1 of this invention provides an AI-based intelligent database operation and maintenance method, which specifically includes the following steps: Step 101: Collect the first raw data from different dimensions from the managed database.

[0029] In one embodiment, the data acquisition layer reuses and extends the existing dmagent agent of the DM8 platform to collect first-dimensional raw data from the managed DM8 database instances or clusters in real time and comprehensively. This first-dimensional raw data serves as the basis for the data processing and analysis layer. The first-dimensional raw data mainly includes performance metrics, log data, configuration data, and SQL execution data. Performance metrics include dozens of key performance indicators such as CPU utilization, memory utilization, disk input / output (I / O), network throughput, transactions per second, queries per second, session connections, lock wait, and cache hit rate. Log data includes alarm logs and event logs from the DM8 database, which record key events, errors, and warnings during database operation. Configuration data includes various parameter settings in the database configuration file. SQL execution data includes frequently executed SQL statement text, execution plans, CPU time, logical reads, and physical reads.

[0030] Furthermore, in addition to relying on the dmagent agent to collect the first raw data, this embodiment also supports integrating open-source monitoring data collectors (such as Prometheus exporters, Telegraf) to collect the first raw data, in order to better accommodate the first raw data from different dimensions.

[0031] Step 102: Preprocess the first raw data for each dimension and extract features. Integrate the features from the same time window from different dimensions to obtain a feature vector.

[0032] In one embodiment, the data processing and analysis layer preprocesses the first raw data for each dimension (e.g., cleaning, denoising, etc.) and extracts features from the preprocessed first raw data. The feature extraction process employs different strategies depending on the data type. For time-series performance index data, statistics such as mean, variance, maximum value, and trend slope are calculated within a fixed-length time window, and these statistics are used as features of the performance index data. Specifically, based on the performance index sampling period and the historical anomaly duration distribution, offline grid verification is performed using the median as the target window, and the window that optimizes anomaly detection is fixed to the aforementioned fixed length. For text-type log data, key structured information (such as timestamps, error codes, event types, and context identifiers) is accurately extracted using predefined regular expressions, and this structured information is used as features of the log data. After obtaining the features of all dimensions, the features are uniformly converted into numerical feature vectors that the model can process, and the multi-dimensional feature vectors are aligned and integrated according to the same time window; that is, one time window corresponds to one feature vector.

[0033] Step 103: Obtain the target feature vector corresponding to the current time window, perform collaborative analysis on the target feature vector to obtain detection results, predicted events, and abnormal events generated based on the detection results.

[0034] In one embodiment, in the data processing and analysis layer, instead of processing all feature vectors of the time window at once, the feature vectors of one time window are analyzed in a sliding manner each time. The specific window corresponding to the analysis time is called the current time window, and the target feature vector of the current time window is obtained for comprehensive analysis.

[0035] In one embodiment, the data processing and analysis layer includes a pre-trained intelligent anomaly detection module, a fault prediction module, and a fault classification and diagnosis module, and further includes a collaborative scheduling unit for unified control of the execution order, data flow, and result aggregation of the three modules. The collaborative scheduling unit acquires the target feature vector corresponding to each current time window and distributes it in parallel to the intelligent anomaly detection module and the fault prediction module. The intelligent anomaly detection module performs anomaly detection on the database's operating status within the current time window based on the target feature vector, outputs the detection result (normal or abnormal), and generates a result confidence level corresponding to the detection result. The fault prediction module predicts the fault risk within the target time window based on the target feature vector. When it predicts that the database will experience a specific fault within the target time window, it generates a corresponding predicted event (e.g., disk space will be exhausted within 6 hours) and generates a confidence level corresponding to the predicted event. When the prediction trigger condition is not met, it outputs a "no predicted event" flag and the corresponding confidence level or a null value. The collaborative scheduling unit, carrying the target feature vector, detection result, and confidence level of the same current time window (and possibly the predicted event and its confidence level output by the fault prediction module within the same window as auxiliary context), triggers the execution of the fault classification and diagnosis module. Specifically, the fault classification and diagnosis module obtains the target feature vector corresponding to the detection result, classifies the detection result based on the target feature vector to obtain the abnormal event type (e.g., I / O bottleneck, lock contention, memory leak, etc.), and generates the confidence level corresponding to the abnormal event. The collaborative scheduling unit aligns and encapsulates the detection result, predicted event, and (generated when the detection result is abnormal) abnormal event according to the time window to form the collaborative analysis output of the current time window, which is used for subsequent root cause reasoning and self-healing strategy selection.

[0036] Step 104: Based on the pre-constructed knowledge graph, reason about the abnormal event to obtain the root cause of the abnormal event.

[0037] In one embodiment, DEM can currently sort CPU time and I / O time statistics for the top k SQL queries by time period, but DBAs need to manually determine whether it is a "normal business peak" or an "abnormally slow SQL," lacking automatic identification capabilities. In addition, even if it is determined to be an "abnormally slow SQL" problem, it cannot automatically determine whether the slow SQL is due to missing indexes, unreasonable parameters, outdated statistics, or the root cause of storage layer problems.

[0038] In one embodiment, after the data processing and analysis layer analyzes an anomaly, predicts a fault, or diagnoses an anomaly type, the intelligent decision-making and execution layer is responsible for finding the cause, formulating a strategy, and executing the strategy. The intelligent decision-making and execution layer includes a root cause analysis module, a strategy engine and knowledge base, and a self-healing and optimization execution module. That is, the root cause analysis module further delves into the root cause of the abnormal event and, through the strategy engine and knowledge base, locates the self-healing strategy to solve the abnormal event. The self-healing and optimization execution module automatically executes the located self-healing strategy. Upon receiving an abnormal event (such as "lock wait") and related context information from the data processing and analysis layer, the root cause analysis module performs reasoning on the knowledge graph and combines it with predefined rules (such as "querying the V$LOCK view to locate the lock source and lock holder") to ultimately pinpoint the specific blocking session and SQL statement. The predefined rules are based on the manual diagnostic experience of database administrators (DBAs) and operations personnel, as well as existing standard operating procedures (SOPs). They solidify the "trigger node type to query SQL template to result judgment logic (which view to query and how to judge)" into the rule base and continuously iterate and update it based on historical fault cases and DBA feedback.

[0039] Furthermore, a Graph Neural Network (GNN) model can be introduced to learn and reason directly on the knowledge graph, automatically discovering the deep causal relationships hidden between metrics, logs, and configurations, thereby improving the automation level and accuracy of the root cause analysis module.

[0040] Step 105: Analyze the abnormal events, the predicted events, and the root causes comprehensively, dynamically select a self-healing strategy from the preset strategy library, and run the self-healing strategy using an automated script to restore the database.

[0041] In one embodiment, the system maintains a pre-defined policy library. This library stores a large number of operational contingency plans in the form of "IF-THEN" rules. These plans are response strategies based on previously occurring and successfully resolved anomalies, as well as strategies for predicted events. Furthermore, the pre-defined policy library is extensible; DBAs can continuously add new handling experiences and response strategies. An example of a pre-defined policy library is as follows: IF Fault Type = "Slow SQL Query" AND Root Cause = "Full Table Scan" THEN Action 1: Analyze the tables and fields involved in the query.

[0042] Action 2: Generate the recommended CREATE INDEX statement.

[0043] Action 3: Push optimization suggestions (including estimated performance improvements) to the DBA for approval.

[0044] Specifically, among all strategies in the preset strategy library, candidate self-healing strategies that partially or completely match the abnormal event, the predicted event, and the root cause are obtained through precise matching, fuzzy matching, and range matching. The performance metrics of each candidate self-healing strategy are weighted and summed to obtain the final score for each strategy. The candidate self-healing strategy with the highest score is selected as the self-healing strategy. The performance metrics include historical success rate, average execution time, average repair time reduction effect, rollback difficulty, resource consumption cost, and strategy confidence. Historical success rate refers to the proportion of times the self-healing strategy has successfully resolved faults after being adopted and executed in the past; average execution time refers to the average time spent executing the self-healing strategy; average recovery time reduction effect refers to the average time required for the database to return to normal after executing the self-healing strategy, compared to the reduction achieved by not executing or executing other strategies; rollback difficulty refers to the complexity of the rollback operation and the degree of impact on business if the self-healing strategy fails or produces side effects; resource consumption cost refers to the computing, storage, network, and other resources consumed in executing the self-healing strategy; strategy confidence refers to the degree of matching between the current abnormal event, predicted event, and root cause and the IF condition of the self-healing strategy. The system comprehensively evaluates the performance indicators of each candidate self-healing strategy, assigns corresponding weights to different performance indicators (or reduces their weights), and integrates multi-dimensional information to generate the optimal self-healing strategy. This strategy library + strategy scoring method reduces the reliance on the DBA's personal experience, and the self-healing strategy can continuously adjust its priority through machine learning to achieve self-optimization, enabling the system to automatically select and execute the optimal strategy in DBA-authorized mode. Among them, the policy confidence score is a quantitative matching score used to measure the degree of consistency between the current fault scenario and the preset policy triggering conditions. Its calculation is based on multi-attribute fuzzy matching, rather than simple Boolean judgment.

[0045] In one embodiment, the method for obtaining the policy confidence score is as follows: align the current scenario's abnormal event type, predicted event type, root cause object (e.g., table name, SQL ID, disk path), and related key indicator values ​​(e.g., CPU utilization 90%) with the attributes defined in the policy IF condition. When aligning with the attributes defined in the policy IF condition, a precise matching method is used for discrete attributes (e.g., event type, error code). That is, if a discrete attribute is completely consistent with the attribute defined in the policy IF condition, the score is 1; otherwise, it is 0. For example, if the current abnormal event is "lock wait" and the policy IF condition is "lock wait," this item scores 1. For textual attributes (e.g., SQL fragments, log keywords), a fuzzy matching method is used. That is, a text similarity algorithm (e.g., Jaccard similarity, cosine similarity based on word vectors) is used to calculate the score, ensuring that the score range is [0,1]. For numerical attributes (such as "connection count > 100"), a range matching method is used. This means calculating the score based on the degree to which the current metric value meets the threshold condition, ensuring the score range is [0,1]. For example, a sigmoid function can be used for smooth mapping: when the metric value is far above the threshold, the score is close to 1; when it slightly exceeds the threshold, the score is approximately 0.6; and when it is below the threshold, the score is close to 0. The scores of each attribute are then weighted and summed to obtain the final policy confidence score. The weights can be set based on operational experience; for example, the weight of root causes is usually higher than that of abnormal events. High confidence indicates a high degree of agreement between the current scenario and the policy's preset conditions; low confidence indicates only partial agreement or a weak agreement. This method of calculating policy confidence makes policy selection more flexible and can handle fault scenarios that are not entirely consistent with the preset template but are essentially the same.

[0046] Furthermore, reinforcement learning techniques can be introduced to treat the database environment as an intelligent agent. By continuously trying and failing in a simulated environment, the system can automatically learn the optimal combination of recovery strategies under different fault scenarios, rather than simply relying on a predefined rule base.

[0047] In one embodiment, in addition to feature extraction from log data using regular expressions, more advanced natural language processing models, such as Transformer or BERT (Bidirectional Encoder Representations from Transformers), can be introduced to train log classification and named entity recognition models. These models can then be used to deeply understand the semantics of log text, thereby more accurately identifying anomalies and locating faults from unstructured logs.

[0048] Specifically, a massive amount of historical logs are collected, and operations and maintenance experts are asked to annotate log lines related to faults (such as errors, warnings, and key information indicating performance problems). A log classification model is trained using pre-trained models such as BERT for fine-tuning. The trained model can classify log lines into categories such as normal information, known errors, unknown anomalies, or performance alerts. The training process for the log classification model is as follows: historical alert logs, event logs, and audit logs are collected from the managed database and its upstream applications or middleware. Logs from different sources are standardized to the same format (logs must include at least the log body, source component, host identifier, instance identifier, and timestamp), and deduplication, anonymization, and template preprocessing are performed (variable parameters are replaced with placeholders to reduce noise). A set of log line categories is defined, including normal information, known errors, unknown anomalies, and performance alerts. Operations and maintenance experts label the log lines according to the unified annotation specifications and record the associated fault tickets, alarm IDs, and root cause objects, which are then used as optional tags. The auxiliary field divides the labeled log lines into training, validation, and test sets proportionally. A pre-trained language model (e.g., BERT) is used as the encoder, and a classification head (fully connected layer + Softmax) is connected to its output. The cross-entropy loss is used as the objective function for fine-tuning the training. On the validation set, macro-average F1 or weighted F1 is used as the early stopping metric to solidify the model parameters with the optimal validation metric. The maximum class probability of the Softmax output of the classification model is used as the confidence score of the classification result of the log line. Temperature scaling can be used to calibrate the probability to improve the interpretability of the confidence score, resulting in a well-trained log classification model.

[0049] Simultaneously, a named entity recognition model is trained. The trained named entity recognition model can extract key entities (such as error codes, IP addresses, usernames, object names, and timestamps) from logs. The specific training process of the named entity recognition model is as follows: Define a set of entity types, including error codes, IP addresses, usernames, object names, SQL identifiers, instance names or database names, timestamps, etc.; Use the BIO annotation scheme to divide the samples of each log into training set, validation set, and test set according to the characters of each log in chronological order, so as to avoid logs in the same fault window appearing in the training set and validation set at the same time, which would lead to data leakage; Feed the log text into a word segmenter that is matched with the pre-trained model for word segmentation, and truncate or slice excessively long sequences to obtain the model input tensor or word segmented sequence for entity boundary annotation, so as to obtain sequence samples with entity labels. Using the same pre-trained language model as the encoder, a token-level classification head (optionally connected to a CRF layer to constrain label transition) is connected to its output. Fine-tuning training is performed using token-level cross-entropy loss (or CRF negative log-likelihood) as the objective function. Entity-level Precision / Recall / F1 evaluation is performed on the validation set, and early stopping is implemented to solidify the optimal model parameters. The category and corresponding confidence of each entity span are output (e.g., the mean or minimum value of the token probabilities within the span is taken as the span confidence).

[0050] When new logs are generated, the log classification model identifies "unknown anomalies" or "performance alerts" in real time. Logs of the same type generated within a short period are clustered. Log lines identified as "unknown anomalies" or "performance alerts" by the log classification model are collected within a fixed aggregation time window (e.g., 5 minutes, or consistent with the aforementioned feature time window). First, coarse grouping is performed based on the log classification results and key entity combinations (such as database instance name, host IP, and error code). For each log line, a pre-trained language model encoder outputs its semantic vector representation (reusing the encoder part of the log classification model). Then, density clustering is performed within the group based on semantic vector similarity to automatically merge log lines with highly consistent semantics. The system identifies noise points to obtain several clusters of similar abnormal logs. For each cluster, representative log lines (e.g., several near the cluster center) and high-frequency entities within the cluster are selected as a summary. This summary is then fed into a Transformer-based sequence-to-sequence summary generation model (e.g., a T5 summary model finely tuned on historical operation and maintenance logs—fault phenomenon description corpus) to generate a semantic summary. Subsequently, named entity recognition is performed on this semantic summary to obtain a set of summary entities. The summary entities are then associated with knowledge graph nodes. Combined with the time window of the anomaly occurrence, the system retrieves associated nodes in the knowledge graph that are connected to the entity and show abnormal indicators in the same window. This is used to align log fault phenomena with underlying indicator anomalies and assist in locating the fault domain.

[0051] In one embodiment, the self-healing and optimization execution module is responsible for executing the generated self-healing strategy. The system has built-in various automated scripts (such as SQL scripts, Shell scripts, Ansible Playbooks, etc.) and securely runs these scripts on the database host through the execution channel provided by the dmagent agent or the standard Secure Shell (SSH) protocol, thereby realizing the automated execution of the self-healing strategy.

[0052] In one embodiment, after the self-healing strategy is approved by the DBA, the DBA can trigger the execution script with a single click to automatically complete the repair operation. The system also supports semi-automatic approval, and can achieve fully automatic execution in low-risk scenarios. In the pilot test, common faults such as disk cleanup, expired statistics, and index rebuilding can be handled with little or no human intervention.

[0053] For example, in slow SQL optimization scenarios, after DBA confirmation, the module automatically connects to the database and executes the CREATEINDEX script. In disk space warning scenarios, when the fault prediction module predicts that the disk is about to be full, the policy engine matches the "disk cleanup" policy, and the execution module automatically runs a shell script that cleans up expired backup files or log files in the specified directory according to the rules. In automatic parameter tuning scenarios, if the system detects that the current parameter configuration is mismatched with the load, causing performance degradation, the policy engine suggests adjusting parameters such as MEMORY_TARGET and BUFFER in the database initialization file. After obtaining authorization, the execution module can call logic similar to the AutoParaAdj.sql script provided by DM to calculate the optimal parameter values, generate a new configuration file, and schedule a database service restart during off-peak hours to make the changes take effect.

[0054] Furthermore, in addition to using Shell scripts, SQL scripts, and Ansible scripts, other mainstream automated operation and maintenance tools, such as SaltStack and Puppet, can also be integrated to adapt to the existing technology stacks of different enterprises.

[0055] In this embodiment, based on the existing DEM architecture, artificial intelligence technology is integrated to construct a closed-loop intelligent operation and maintenance system that combines data acquisition, intelligent analysis, and decision execution. It collects multi-dimensional data from the database in real time and uses a knowledge graph-driven inference engine to automatically perform attribution analysis on abnormal events, quickly locating the root cause. Based on preset strategies or dynamically generated repair plans, it automatically triggers actions to achieve self-healing of faults. The entire process requires no manual intervention, significantly reducing the time-consuming and labor-intensive manual troubleshooting steps in traditional operation and maintenance, and also significantly shortening the average database recovery time.

[0056] In one embodiment, the presentation and interaction layer extends the existing web interface of DM DEM by adding a brand-new intelligent operation and maintenance cockpit page. This page graphically and visually displays real-time anomaly alarms and fault prediction alarms to DBAs; fault diagnosis reports and root cause analysis results; automatically generated optimization suggestions and self-healing operation records; and future trend prediction charts for key indicators. DBAs can approve or reject self-healing operations with a single click on this interface, enabling human-machine collaboration. The system records DBAs' feedback for model retraining and optimization of the preset strategy library.

[0057] In one embodiment, the unsupervised learning model can be an intelligent anomaly detection module. This module is trained using an unsupervised learning algorithm (such as an isolated forest or an autoencoder). During training, feature vectors from different dimensions but belonging to the same time window during historical normal operation are used to train the model, enabling the intelligent anomaly detection module to learn data information about the normal operation state of the database. Once the intelligent anomaly detection module receives the processed feature vectors, it outputs an anomaly score. Specifically, the target feature vector is input into the pre-trained unsupervised learning model to obtain an anomaly score, which represents the degree of deviation from the normal operation state of the database. If the anomaly score is greater than a dynamic threshold, the detection result is considered anomaly; if the anomaly score is less than or equal to the dynamic threshold, the detection result is considered normal. The dynamic threshold is pre-set based on the statistical distribution of anomaly scores calculated by the unsupervised learning model on historical normal data during the training phase. Compared to a static threshold, this method can capture complex correlations between multi-dimensional indicators and is more sensitive to unknown types of anomalies and slowly changing performance degradation issues.

[0058] Furthermore, to enable the system to distinguish between increased latency due to peak business activity (overall cluster center drift) and individual SQL anomalies (internal cluster anomalies), i.e., how to differentiate whether slow SQL queries are caused by normal business operations or genuine anomalies, this embodiment uses a slow SQL scenario in the database as an example for detailed description. Specifically, the data acquisition layer collects database-related data, including SQL-level features, runtime features, and environmental features. SQL-level features include SQL text fingerprints (hash values ​​obtained after standardizing the SQL), the number of bind variables, the number of associated tables, the number of indexes used, and cost estimates for each operation in the execution plan. Runtime features include average execution time, P95 execution time, average logical reads, physical reads, number of returned rows, and concurrent executions. Environmental features include the current database buffer hit rate, I / O latency, and CPU utilization. The SQL features from the database's historical normal business periods are clustered using k-means clustering or DBSCAN (Density-Based Spatial Clustering of Applications with Noise) to obtain multiple SQL clusters with different patterns involved when the database is running normally (e.g., statistical queries, short SQL queries for online transactions, etc.). Each cluster contains different SQL features. Within each cluster, a local anomaly model based on a Gaussian-distributed single-class support vector machine is built (the model is trained using the same method as the intelligent anomaly detection module). When a new SQL statement arrives, it is first categorized into the most similar SQL cluster based on its feature vector. Then, the anomaly score is calculated using the corresponding single-class SVM model and compared with the dynamic threshold of that cluster. If the anomaly score exceeds the dynamic threshold, it indicates that the slow SQL statement is truly abnormal. If the anomaly score does not exceed the dynamic threshold, it indicates that the slow SQL statement is in a normal business scenario. This method avoids interference between SQL statements from different business models and can more accurately distinguish between business peaks and real anomalies. The dynamic threshold is dynamically determined based on the historical normal data of each SQL cluster. That is, during the training phase, the single-class SVM model is trained using the feature vectors of all historical normal SQL statements within the cluster, and their respective distances to the hyperplane are calculated as anomaly scores. The upper limit of these scores (e.g., the 95th percentile or "mean + 3 standard deviations") is taken as the dynamic anomaly threshold of that cluster.

[0059] In one embodiment, since the DBSCAN algorithm can automatically discover clusters of arbitrary shapes and identify noise points (i.e., SQL statements that are inherently abnormal), the DBSCAN algorithm is used as a k-means clustering algorithm to explain in detail the method for obtaining multiple SQL clusters. Specifically, the features extracted from historical SQL statements (including execution plan hash, number of tables accessed, index usage flags, range of returned rows, execution time quantiles, etc.) are standardized. The DBSCAN algorithm connects based on the density of feature vectors, clustering SQL statements with similar execution patterns into clusters (such as "point query cluster", "report analysis cluster", "update transaction cluster"). Parameters such as neighborhood radius and minimum sample size can be determined through historical data tuning. Each generated SQL cluster is automatically or semi-automatically labeled with a business tag (such as "order query" or "user login") for subsequent understanding.

[0060] In one embodiment, static thresholds are used to monitor CPU, memory, disk, etc. in existing DEMs. However, this requires DBAs to manually adjust the thresholds, which varies greatly across different environments, easily leading to alarm storms or missed alarms. Furthermore, it offers almost no effective early warning for slow resource leaks (such as memory leaks). This embodiment, based on Long Short-Term Memory (LSTM) networks and temporal autoencoders, can accurately predict disk space, memory usage, connection count, etc., for more than 24 hours in the future.

[0061] The LSTM network contains cell states that allow it to learn and maintain long-term dependencies. When inputted as a time series (e.g., disk usage over the past 7 days), the LSTM identifies the overall trend component (a stable daily increase of 2%). Brief, sudden peaks or troughs (short-term fluctuations) are treated as noise by the LSTM, and their impact is smoothed out in long-term predictions. The LSTM outputs a predicted sequence for a future period (e.g., 24 hours). If this predicted sequence consistently and smoothly approaches a dangerous threshold, it is considered a long-term trend risk. The temporal autoencoder, trained on historical normal data, learns how to perfectly reconstruct (compress and decompress) a normal, smooth indicator sequence. Specifically, the temporal autoencoder reconstructs the target feature vector, obtaining a reconstruction error. When encountering transient anomalies, the reconstruction error exhibits a brief spike and quickly recovers. Although such fluctuations can be detected, the prediction module maintains its original judgment of the long-term trend, avoiding false triggers. The system continuously assesses the reconstruction error. If the reconstruction error consistently exceeds the normal threshold, it performs long-term time-series prediction based on the target feature vector to obtain a prediction sequence within the target time window, generating a predicted event. That is, when an indicator begins to consistently deviate from its historical normal pattern (e.g., the baseline of disk usage itself begins to rise), the reconstruction error will remain high, indicating that the system's original normal pattern has been broken and a new trend is forming, thus triggering a predictive alarm and generating a corresponding predicted event. This method significantly improves the accuracy of predicted event alarms and reduces the false alarm rate (a range can be estimated, such as a 30%-50% reduction in false alarms). The normal threshold is calculated by the system using data from the database's healthy operating baseline period before deployment. Typically, the 95th percentile of the reconstruction error distribution (or the mean + 3 times the standard deviation) is used as the threshold. Depending on the business and model, it can be automatically calculated from the baseline data and periodically reassessed.

[0062] In one embodiment, the method for determining the persistence of reconstruction error is as follows: a time window (e.g., 5 consecutive sampling points) is set, the average value of reconstruction error within the window and the proportion that continuously exceeds the static baseline threshold are calculated. If the average value of reconstruction error is significantly higher than the baseline (e.g., >2 times the baseline) and the proportion exceeding the threshold is greater than a set value (e.g., 80%), it is determined to be a persistent anomaly, thereby triggering the subsequent long-term prediction process. This method avoids false predictions due to instantaneous jitter. When a long-term time-series prediction is triggered, the system intelligently predicts key operational indicators based on a time-series prediction model (such as LSTM, Transformer, or Prophet). This model receives target features from the current moment, integrates historical sequence data from the past 24 hours, and incorporates exogenous variables such as "whether it's a working day" and "current hour" to more comprehensively capture the patterns of indicator changes. The model outputs the predicted indicator value for the next 6 hours and its 95% confidence interval. The system then compares the prediction results with a preset resource capacity threshold. If the prediction indicates that the indicator will exceed the threshold at some point in the future (e.g., 4 hours later), an early warning event is automatically generated (e.g., disk utilization will reach 95% in 4 hours, potentially causing a failure). This mechanism upgrades the operational mode from passive response to proactive prevention, significantly improving system reliability and resource management efficiency. The preset resource capacity threshold is set by the operations team based on the Service Level Agreement (SLA) and the safety margin of resource levels, serving as the safety upper limit for triggering the early warning (e.g., disk utilization reaching 95%). The determination of this safety margin takes into account the capacity inflection point at the time of historical failures, the reserve space recommended by the manufacturer or system, and the response time required to perform expansion or cleanup operations. During system operation, it will also be periodically calibrated and optimized in combination with the growth trend of resource capacity and the actual time required for disposal.

[0063] Furthermore, to enable the fault prediction module to automatically adapt to different workload patterns and effectively identify slowly growing risks, several specific time points can be introduced as additional input features. For example, business calendar information (such as weekdays / weekends, peak or off-peak periods, holiday markers, etc.) can be input into the fault prediction module along with the target feature vector. Simultaneously, system version change points or key parameter adjustment points can be included as exogenous variables in the model to indicate that the system behavior may experience overall drift after these time points. Compared to traditional static threshold methods, this strategy not only captures potential risks more accurately but also provides a clear time window for the self-healing module (e.g., "disk will be full within 6 hours"), thereby triggering preventative operations such as cleanup and expansion in advance.

[0064] In one embodiment, a supervised learning algorithm, such as XGBoost (eXtreme GradientBoosting) or Random Forest, is used to train the fault classification and diagnosis module. Historical anomaly data is labeled manually or semi-automatically to build an anomaly sample library. Each sample contains a feature vector at the time of the anomaly and a corresponding fault type label (e.g., lock contention, slow SQL, disk failure, network jitter, memory leak, improper parameter configuration, expired statistics, etc.). The feature vector is generated from the original data, which includes snapshots of indicators at each layer at the time of the anomaly (e.g., key performance indicators of the system, database, storage, network, etc.), relevant log features (e.g., error codes, keywords, etc.), and key entities in the root cause analysis results (e.g., specific table names, storage volumes, service nodes, etc.). The feature vector includes the anomaly score of the anomaly detection module, the fluctuation pattern of indicators (e.g., sudden increase in CPU, sudden increase in I / O latency, etc.), and the degree of anomaly of each node on the cross-layer path (quantified by combining dependency graph and RCA module). Finally, each sample, in the form of feature vector and fault type label, is used for training and inference of the XGBoost multi-classification model. After training, when the intelligent anomaly detection module detects a new anomaly, the system extracts the corresponding feature vector in real time and inputs it into the trained classification model. The classification model outputs the most likely fault type, thereby helping maintenance personnel quickly locate the root cause of the problem and improving the efficiency and accuracy of fault diagnosis.

[0065] like Figure 3 As shown, this embodiment provides a root cause analysis method, which specifically includes the following steps: Step 201: Determine the first target node corresponding to the abnormal event in the knowledge graph.

[0066] In one embodiment, the system pre-constructs a knowledge graph describing knowledge in the database operation and maintenance domain. The knowledge graph consists of an entity-edge-entity structure, where entities include performance metrics, configuration parameters, log events, SQL statements, database objects, etc., and edges represent the influence relationships between them (such as "a certain parameter affects the cache hit rate" or "a certain SQL operation causes lock waiting"). When an abnormal event is received, the root cause analysis module determines the first target node corresponding to the abnormal event in the knowledge graph through the associated entities in the abnormal event.

[0067] Step 202: Starting from the first target node, search downwards using a depth-first search method until a leaf node is reached or the preset maximum depth is reached, and the node at the stopping point is taken as the terminal node.

[0068] In one embodiment, the system starts with a first target node and uses a depth-first search strategy to traverse the knowledge graph downwards. Starting from the first target node, it sequentially explores its child nodes, recursively exploring until either of the following termination conditions is met: reaching a leaf node (i.e., an end-operation node with no child nodes), or the depth of the current search path reaches a preset maximum depth threshold. At this point, the currently reached node is marked as the terminal node, and further expansion of that branch ends. The maximum depth threshold can be set based on operational experience to ensure that the search covers the vast majority of meaningful causal chains while avoiding infinite searches or getting bogged down in overly trivial details. Typically, the internal fault propagation path of a database can locate an actionable root cause within 3-5 hops. For example, based on operational experience, setting the maximum depth threshold to 3 means that starting from an abnormal node (such as a "slow query"), it explores a maximum of three levels of relationships downwards. For example, the search path could be from slow query to wait event (lock) to blocked session to specific SQL text. This experience-based maximum depth threshold balances search efficiency and coverage.

[0069] Step 203: Based on the terminal node, match the predefined query rules, use the query rules to query the database, and locate the root cause of the abnormal event.

[0070] In one embodiment, to further analyze the root cause of the anomaly, database-related query rules can be predefined. These rules can then be used to match and detect the execution plan and system metadata, thereby identifying potential configuration defects, inaccurate statistics, or missing indexes. For example, querying the V$LOCK view can locate the lock source and lock holder.

[0071] In one embodiment, a series of query rules are predefined in the rule base. Each query rule includes a trigger node type, a query template, and judgment logic. When the search reaches the terminal node (such as lock waiting), the system searches for all query rules with the trigger node type being lock waiting. For example, one query rule might be: "IF node='lock waiting' THEN execute SQL: SELECT * FROM V$LOCK WHERE BLOCK=1; and analyze the results." The system automatically executes this SQL query template, obtains real-time data, and then analyzes the results based on the judgment logic. For example, if the query returns records, the SESSION_ID and SQL_ID are extracted and output as part of the root cause. This localization method encodes manual diagnostic experience (which view to check, how to judge) into automatically executable rules, thus automating the diagnostic steps.

[0072] The current solution of this invention primarily focuses on the database layer, but can also extend the scope of monitoring and analysis upstream to the application layer and downstream to the operating system and hardware layers. By collecting full-stack data, an end-to-end dependency relationship and performance topology are constructed to achieve cross-domain fault correlation analysis and root cause localization, resolving the common dilemma of debating whether the problem lies with the application or the database.

[0073] like Figure 4 As shown, this embodiment provides a method for constructing a fully dependent graph, which specifically includes the following steps: Step 301: Collect second raw data from multiple levels and different dimensions from the managed database.

[0074] In one embodiment, a plug-in data collection module can be added to dmagent to collect secondary raw data from multiple levels and dimensions. Specifically, application server data can be collected via Java Management Extensions (JMX) interfaces; operating system data can be collected via file systems and system commands (such as vmstat, iostat, and netstat); and storage and switch hardware data can be collected via Simple Network Management Protocol (SMAP) or vendor Software Development Kits (SDKs). Application layer data includes thread pool utilization, request queue length, response time distribution, error rate (5xx), and Java database connection pool status of application servers (such as Tomcat and WebLogic); query per second rate, latency, and backend error code distribution of middleware; and business error codes, interface names, and request identifiers in application logs. Operating system layer data includes CPU load distribution and context switch count; kernel-level I / O queue length, process-level CPU or memory usage, and file system-level disk usage. Hardware layer data includes server temperature, fan speed, and power status collected through the Intelligent Platform Management Interface (IPMI) and / or vendor agent services; and storage system logical unit number (LUN) latency, number of read / write operations per second, bandwidth, disk failure status, network switching device port packet loss rate, and number of error packets.

[0075] Optionally, a unified full-stack monitoring data model can be designed, which interfaces with third-party data collectors (such as Prometheus Exporter, Telegraf, etc.) to enable the third-party data collectors to collect secondary raw data from multiple levels and different dimensions.

[0076] Step 302: Map and align the unique identifiers of the entities in the second raw data.

[0077] In one embodiment, the second raw data is converted into an internal unified format, and the indicator data from different layers are uniformly named and encoded. For example, application services, database instances, operating system hosts, storage volumes, network devices, etc. are uniformly defined as resource entities; CPU_USAGE, DB_CONNECTION_USED, APP_LATENCY_P99, etc. are uniformly defined as indicator types; and "Application A depends on database instance 1" and "Data file of database instance 1 is located in storage volume 1" are uniformly defined as relations.

[0078] Step 303: Collaboratively analyze the call chain and static dependency files, associate entities with unique identifiers, and build the dependency relationships between entities.

[0079] In one embodiment, dependencies between entities are constructed by combining call chain tracing identifiers with static configuration parsing. Specifically, on one hand, a TraceID is injected into the application request and passed to the database. On the database side, enhanced auditing functions or proxies associate the TraceID with executed SQL, session information, etc. By analyzing log sequences under the same TraceID, real-time call dependencies from application service A to database instance B to specific table C can be dynamically constructed. This dependency reflects the actual business access path. On the other hand, application configuration files (such as datasource.url in application.yml) are parsed to obtain declarative dependencies of application service A on database instance B; the database's physical storage configuration is also parsed to obtain physical deployment dependencies (e.g., tablespace T contains data file F, and data file F is stored on volume V). The system aligns and merges the real-time dependencies discovered by the dynamic call chain with the configuration dependencies obtained by static parsing. If they are consistent, the confidence of the dependency relationship is enhanced. If the static configuration exists but the dynamic configuration does not discover it, it may indicate that the function has not been called recently. If the dynamic configuration discovers it but the static configuration does not declare it, it may mean that there is unconventional access that needs to be monitored. Through the above methods, the real-time performance and accuracy of the full dependency graph can be ensured.

[0080] Step 304: Add the entity and the dependency relationship to the knowledge graph to obtain a full dependency graph, and use the full dependency graph to identify the root cause of the problem.

[0081] In one embodiment, the dependencies in step 203 are encoded into the entities and edges of the operation and maintenance knowledge graph to obtain a full dependency graph. The entities in the full dependency graph include application service nodes, database instance nodes, operating system host nodes, storage nodes, and network nodes; edge types include call, deployment, storage, and network paths. This full dependency graph can be stored using a graph database (such as Neo4j) to enable fast querying and traversal during subsequent root cause analysis. The full dependency graph constructed using the method in step 303 is a combination of dynamic and static information, containing both stable architectural relationships and real-time traffic characteristics. When an anomaly occurs, upstream and downstream tracing along the call chain and the full dependency graph can be performed to identify the root cause of the problem. For example, if a decrease in the number of queries per second in the database is detected, the tracing identifiers of the call chain can be used to trace which application interfaces experienced a large number of timeouts, thus determining whether it is a problem with a single business interface or a global database bottleneck. Similarly, if an increase in disk I / O latency is detected, the full dependency graph can be used to determine whether it is a problem with a single LUN or a Redundant Array of Independent Disks (RAID), or a problem with a network storage link.

[0082] like Figure 5 As shown, this embodiment provides a method for root cause analysis based on a full dependency graph. The method specifically includes the following steps: Step 401: Determine the second target node corresponding to the abnormal event in the full dependency graph.

[0083] In one embodiment, an abnormal event within the current time window is received from the data processing and analysis layer. This abnormal event may originate from an aggregation of abnormal events from the application layer, database layer, operating system layer, and hardware layer. The abnormal event includes a timestamp, associated entity, abnormal indicator, and abnormal score. The second target node corresponding to the abnormal event in the full dependency graph can be determined through the associated entity.

[0084] Step 402: Starting from the second target node, identify all candidate cause paths originating from the target node in the full dependency graph, and update the initial weight of each node on the candidate cause path according to the call chain within the abnormal time window.

[0085] In one embodiment, in the full dependency graph, all possible candidate cause paths are searched downstream from the second target node. It is necessary to ensure that the candidate cause paths contain abnormal indicators, where the abnormal time window refers to the target event window corresponding to the current abnormal event.

[0086] In one embodiment, the initial weight of each node on the candidate cause path is updated based on the call chain data within the abnormal time window. Specifically, this involves: obtaining at least one search node directly connected to the second target node; for a search node, checking whether the entity corresponding to the search node has a call chain from the second target node to the search node within the abnormal time window; if a call chain exists, increasing the initial weight of the search node; if no call chain exists, decreasing the initial weight of the search node; continuing to search downwards from the search node for the next search node, and changing the initial weight of each search node according to the call chain, until a leaf node is reached or a preset maximum depth is reached, thus obtaining the candidate cause path with the changed initial weights. For example, in one candidate cause path, when searching downstream from application service A to database instance 1, it is checked whether a call chain from application service A to database instance 1 exists within the abnormal time window. If it exists, the initial weight of database instance 1 is increased; if not, the initial weight of database instance 1 is decreased. The preset maximum depth can be set based on the experience of the operations and maintenance personnel.

[0087] Step 403: Based on the updated initial weights of each node on the candidate cause path, and combined with the path information of the candidate cause path, calculate the credibility of each candidate cause path, take the candidate cause path with the highest credibility as the root cause path, and generate the root cause result based on each node on the root cause path.

[0088] In one embodiment, a causal scoring model can be introduced into the intelligent decision-making and execution layer and trained based on the statistical characteristics of each path in the full dependency graph. This training method differs from the simple priority ranking of single-point alarms and can better utilize the knowledge of the full dependency graph. The causal scoring model performs statistics based on the path information of candidate cause paths (including path length, degree of abnormality of each node, order of occurrence of abnormalities, historical similar failures, etc.) and the updated initial weights of each node on the candidate cause path. It outputs the credibility of each candidate cause path as the root cause path and selects the candidate cause path with the highest credibility as the root cause path. For example, if the final calculated path with the highest credibility is: storage volume 1 experiences an abnormality, causing I / O latency in tablespace 1, which in turn causes slow queries in database instance 1, and the slow queries ultimately cause the interface response of application service A to time out, then this path is selected as the final root cause path.

[0089] In one embodiment, a candidate cause path P consists of n nodes (N1, N2, ..., N...). n The nodes are arranged in sequence, where N1 is the second target node corresponding to the abnormal event (i.e., the observed fault phenomenon, such as interface timeout), and N...n This is the terminal node where the root cause path search terminates (i.e., the inferred root cause, such as an uncommitted transaction). Node N i depth Defined as from the starting node N1 to node N i The number of jumps, that is, = 0, = 1, ..., = n-1), the formula for calculating the credibility of each candidate cause path is as follows:

[0090] Where C(P) represents the confidence score of the root cause path; the higher the score, the greater the likelihood that the path is a true root cause chain. n represents the total number of nodes in the root cause path, and i represents the index of a node in the root cause path, with i ranging from 1 to n. Represents node N i The updated weights, whose initial values ​​are based on node type (e.g., hardware nodes have higher weights than application nodes), have been dynamically updated according to the call chain data within the abnormal time window. Represents node N i depth, = i - 1, where depth represents node N i The causal distance from the observed fault phenomenon (starting node) is α. The greater the depth, the more likely the node is to be a distant and fundamental cause. α represents the depth decay factor, which is a constant between 0 and 1 (e.g., α is 0.8). This indicates that the contribution of a node's weight decreases as depth increases, ensuring that while remote nodes contribute, their contribution is not amplified indefinitely. β represents the specific reward coefficient of the root cause path, a non-negative constant used to adjust the strength of the reward. S(P) represents the specific reward score of the root cause path, a constant assigned based on whether the root cause path contains specific, actionable evidence.

[0091] In one embodiment, the formula for calculating the credibility of a root cause path balances the coherence of the causal chain (through weights and decay factors) with the specificity of the evidence (through reward scores), thereby enabling a more accurate identification of the most likely true root cause chain from multiple possible dependency paths. The assignment method for S(P) is as follows: if at least one node in the root cause path contains a specific anomaly indicator value in its description, then S(P) = S1; if at least one node in the root cause path is associated with a queryable specific database object (such as a table name, index name, or SQL_ID), then S(P) = S2; if both conditions are met, then S(P) = S1 + S2. S1 and S2 are both preset reward scores, which encourage the system to prioritize paths with solid evidence and clear direction, rather than merely theoretical dependency chains.

[0092] In one embodiment, the deepest node with the highest node weight or anomaly score is identified from the root cause path with the highest credibility and designated as the primary root cause. For example, if the root cause path is from interface timeout to slow query to lock wait to uncommitted transaction, the node with the uncommitted transaction has the highest weight and is designated as the primary root cause. Specific evidence associated with this node is automatically extracted, such as the transaction's SESSION_ID, the uncommitted SQL text, and the OBJECT_ID holding the lock. The system fills this information into a predefined template to generate a root cause report. The root cause report includes root cause location (e.g., database layer uncommitted transaction causing lock blocking), root cause object (e.g., session ID is 1357, user identifier is APP_USER, uncommitted SQL statement is UPDATE orders SET ... WHERE ...), and impact chain (e.g., the lock held by this transaction blocks other sessions (session ID: ...)). Access to the same resource ('2468') slows down its query, which in turn causes the upstream order query interface to time out. Related metrics (e.g., a sudden increase in the number of lock waits, and a significant increase in the row_lock_wait time of the related table orders) are highlighted on the DEM interface, and the root cause path in the full dependency graph is displayed in a floating position.

[0093] In one embodiment, the root cause result includes the root cause level (hardware / operating system / database / application), the precise object (such as a storage disk, a SQL statement, or an application interface), and the scope of impact (which business interfaces and database instances are affected).

[0094] This invention also supports richer interaction methods. For example, when the root cause of the intelligent decision-making and execution layer output is uncertain, users can proactively ask the DBA questions in a dialogue format to guide the DBA to provide more information and assist the system in making the final strategy selection. The DBA can also query the system for performance issues through natural language, and the system will parse the intent and return an analysis report.

[0095] In one embodiment, the intelligent decision-making and execution layer includes an uncertainty assessment unit, an interactive question generation unit, an expert feedback collection and structured coding unit, and a decision correction and feedback learning unit. When the confidence level of the results given by the anomaly detection model, fault classification model, or root cause analysis module is lower than a preset threshold, the uncertainty assessment unit triggers a human-machine collaborative process. Specifically, the interactive question generation unit automatically generates semi-structured questions highly relevant to the current fault scenario based on the entities corresponding to the root causes and their associated indicators in the knowledge graph, according to a predefined template, and pushes them to the DEM's web interface. The DBA provides expert judgment through optional answers and supplementary text descriptions. The expert feedback collection and structured coding unit converts the DBA's answers into structured tags (e.g., fault type confirmation, change event type, root cause entity confirmation, etc.) and writes them into the anomaly sample library and knowledge graph. The decision correction and feedback learning unit corrects the current root cause score based on the expert confirmation results and adjusts the priority of the self-healing strategy. During subsequent model retraining, it assigns greater loss weight to the rejected root causes, thereby achieving continuous adaptive optimization of the model and the preset strategy library. This method can realize a closed loop of human-machine collaborative decision-making. Compared with the existing operation and maintenance platform that only provides static approval functions, it can make full use of the DBA's professional knowledge to continuously improve the accuracy and interpretability of system decisions.

[0096] Example 2: Based on the AI-based intelligent database operation and maintenance method provided in the foregoing embodiments, the present invention also provides an AI-based intelligent database operation and maintenance apparatus that can be used to implement the above method, such as... Figure 6 The diagram shown is a schematic representation of the device architecture according to an embodiment of the present invention. The AI-based intelligent database operation and maintenance device of this embodiment includes one or more processors 21 and a memory 22. Figure 6 Take a processor 21 as an example.

[0097] Processor 21 and memory 22 can be connected via a bus or other means. Figure 6 Taking the example of a connection between China and Israel via a bus.

[0098] The memory 22, as a non-volatile computer-readable storage medium for AI-based intelligent database operation and maintenance, can be used to store non-volatile software programs and non-volatile computer-executable programs, such as the AI-based intelligent database operation and maintenance method in the aforementioned embodiments. The processor 21 executes various functional applications and data processing of the AI-based intelligent database operation and maintenance device by running the non-volatile software programs, instructions, and modules stored in the memory 22, thereby implementing the AI-based intelligent database operation and maintenance method of the aforementioned embodiments.

[0099] Memory 22 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, memory 22 may include memory remotely located relative to processor 21, which can be connected to processor 21 via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0100] The program instructions / modules are stored in memory 22. When executed by one or more processors 21, they execute the AI-based intelligent database operation and maintenance method described in the foregoing embodiments, for example, executing the methods described above. Figures 2-5 The steps shown.

[0101] This invention also provides a non-volatile computer storage medium storing computer-executable instructions that are executed by one or more processors, for example... Figure 6 One of the processors 21 enables the above-described one or more processors to execute the AI-based intelligent database operation and maintenance method in the foregoing embodiments, for example, to execute the above-described... Figures 2-5 The steps shown.

[0102] It is worth noting that the information interaction and execution process between the modules and units in the above-mentioned device and system are based on the same concept as the processing method embodiment of the present invention. For details, please refer to the description in the method embodiment of the present invention, and will not be repeated here.

[0103] Those skilled in the art will understand that all or part of the steps in the various methods of the embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

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

Claims

1. An AI-based intelligent database operation and maintenance method, characterized in that, include: Collect primary raw data from different dimensions from the managed database; The first raw data of each dimension is preprocessed and features are extracted. Features from the same time window from different dimensions are integrated to obtain a feature vector. Obtain the target feature vector corresponding to the current time window, perform collaborative analysis on the target feature vector, and obtain the detection results, predicted events, and abnormal events generated based on the detection results; Based on a pre-constructed knowledge graph, the abnormal events are reasoned to obtain the root cause of the abnormal events; By comprehensively analyzing the abnormal events, the predicted events, and the root causes, a self-healing strategy is dynamically selected from a preset strategy library. The self-healing strategy is then run using an automated script to restore the database.

2. The AI-based intelligent database operation and maintenance method according to claim 1, characterized in that, The method further includes: Based on the target feature vector, anomaly detection is performed on the database's operating status in the current time window, and detection results are generated. Based on the target feature vector, if it is predicted that the database will experience a specific failure within the target time window, a corresponding predicted event is generated. When the detection result is abnormal, the target feature vector corresponding to the detection result is obtained, and the detection result is classified based on the target feature vector to obtain the abnormal event.

3. The AI-based intelligent database operation and maintenance method according to claim 2, characterized in that, The step of performing anomaly detection on the database's operating status within the current time window based on the target feature vector and generating detection results includes: The target feature vector is input into a pre-trained unsupervised learning model to obtain an anomaly score output by the unsupervised learning model that deviates from the normal operation state of the database. If the abnormal score is greater than the dynamic threshold, the detection result is abnormal; if the abnormal score is less than or equal to the dynamic threshold, the detection result is normal.

4. The AI-based intelligent database operation and maintenance method according to claim 2, characterized in that, Based on the target feature vector, if it is predicted that the database will experience a specific failure within a target time window, a corresponding predicted event is generated, including: The target feature vector is reconstructed to obtain the reconstruction error; The reconstruction error is continuously judged. If the reconstruction error continues to be greater than the normal threshold, long-term time-series prediction is performed based on the target feature vector to obtain the prediction sequence within the target time window and generate the prediction event.

5. The AI-based intelligent database operation and maintenance method according to claim 1, characterized in that, The step of reasoning about the abnormal event on a pre-constructed knowledge graph to obtain the root cause of the abnormal event includes: Determine the first target node corresponding to the abnormal event in the knowledge graph; Starting from the first target node, search downwards using a depth-first search method until a leaf node is reached or a preset maximum depth is reached, and the node at which the search stops is taken as the terminal node. Based on the terminal node, a predefined query rule is matched, and the query rule is used to query the database to locate the root cause of the abnormal event.

6. The AI-based intelligent database operation and maintenance method according to claim 1, characterized in that, The comprehensive analysis of the abnormal event, the predicted event, and the root cause dynamically selects a self-healing strategy from a preset strategy library, including: Among all the strategies in the preset strategy library, candidate self-healing strategies that partially or completely match the abnormal event, the predicted event, and the root cause are obtained. The performance metrics of each candidate self-healing strategy are weighted and summed to obtain the final score of each candidate self-healing strategy. The candidate self-healing strategy with the highest score is selected as the self-healing strategy.

7. The AI-based intelligent database operation and maintenance method according to claim 1, characterized in that, The method further includes: Collect secondary raw data from multiple levels and different dimensions from the managed database; Map and align the entities in the second original data with unique identifiers; By collaboratively analyzing the call chain and static dependency files, entities with unique identifiers are associated to build the dependency relationships between entities; The entities and dependencies are added to the knowledge graph to obtain a full dependency graph, which is then used to identify the root cause of the problem.

8. The AI-based intelligent database operation and maintenance method according to claim 7, characterized in that, The method further includes: Determine the second target node corresponding to the abnormal event in the full dependency graph; Starting from the second target node, identify all candidate cause paths originating from the target node in the full dependency graph, and update the initial weight of each node on the candidate cause path according to the call chain within the abnormal time window; Based on the updated initial weights of each node on the candidate cause path, and combined with the path information of the candidate cause path, the credibility of each candidate cause path is calculated. The candidate cause path with the highest credibility is taken as the root cause path, and the root cause result is generated based on each node on the root cause path.

9. The AI-based intelligent database operation and maintenance method according to claim 8, characterized in that, The method further includes: Obtain at least one search node that is directly connected to the second target node; For a search node, check whether there is a call chain from the second target node to the search node within the abnormal time window for the entity corresponding to the search node; If a call chain exists, the initial weight of the search node is increased; if no call chain exists, the initial weight of the search node is decreased. Continue searching downwards from the search node to the next search node, and change the initial weight of each search node according to the call chain, until a leaf node is reached or the preset maximum depth is reached, to obtain the candidate cause path after the initial weight change.

10. An AI-based intelligent database operation and maintenance device, characterized in that, include: At least one processor; And a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the processor for performing the AI-based intelligent database operation and maintenance method as described in any one of claims 1-9.

Images