A database operation monitoring system based on AI technology

Abstract

This invention relates to the field of database monitoring technology and discloses a database operation monitoring system based on AI technology. The system includes modules for database operation data acquisition, multi-dimensional data fusion processing, operation status feature modeling, abnormal state identification and assessment, and dynamic monitoring strategy generation. The system first hierarchically divides the database operation environment to obtain basic data acquisition units, collecting various types of operation data such as operation logs and resource usage at a preset sampling frequency and generating time-series fused data. Then, it uses an AI analysis framework to abstractly model the operation status, extracting multi-dimensional operation features such as performance characteristics and abnormal fluctuation characteristics to identify local and overall abnormal states. Finally, it dynamically adjusts monitoring parameters based on abnormal states to achieve real-time dynamic monitoring of the database operation environment. This system can improve the accuracy and real-time performance of database monitoring, promptly detect anomalies, and optimize monitoring strategies.

Description

Technical Field

[0001] This invention relates to the field of database monitoring technology, specifically to a database operation monitoring system based on AI technology. Background Technology

[0002] In today's era of rapid information technology development, databases, as core components for data storage and management, are crucial for stable operation. With the explosive growth of data volume and increasingly complex application scenarios, database operation faces numerous challenges, and traditional monitoring systems are gradually becoming inadequate to meet the demands.

[0003] Traditional database monitoring systems often employ a static monitoring model, pre-setting fixed monitoring indicators and thresholds, lacking adaptability to dynamic changes in the database operating environment. When the database size increases or business scenarios change, fixed monitoring parameters cannot accurately reflect the actual operating status, potentially leading to delayed anomaly detection or false alarms. For example, during major e-commerce promotions, database load changes drastically, making it difficult for traditional systems to adjust monitoring strategies in a timely manner, impacting the efficiency of problem detection and handling.

[0004] Its data collection methods also have limitations, typically collecting only single-dimensional data, such as CPU utilization and memory usage, which cannot comprehensively reflect the database's operational status. In complex business scenarios, database anomalies may be caused by a combination of factors, and single-dimensional data is insufficient to accurately identify the root cause of the anomaly. For example, increased database response latency may be due to hardware failure, inefficient query statements, or excessive data volume. Traditional systems, lacking multi-dimensional data correlation analysis, struggle to quickly locate the problem.

[0005] Traditional systems lack intelligent analysis capabilities, and their processing of collected data is mostly limited to simple statistics and threshold comparisons, failing to delve into the underlying patterns and anomalies. With the development of AI technology, the demand for intelligent database monitoring is becoming increasingly urgent, requiring systems to automatically learn normal database operation modes and accurately identify abnormal behavior. However, most existing monitoring systems have not effectively integrated AI technology, resulting in insufficient intelligent analysis capabilities and an inability to meet the monitoring needs of complex scenarios.

[0006] Traditional monitoring systems rely on manual intervention to adjust monitoring strategies, failing to automatically optimize based on database operating status. When database anomalies occur, manually adjusting monitoring strategies is time-consuming and labor-intensive, potentially missing the optimal response time. In large-scale distributed database environments, manually managing monitoring strategies across multiple database nodes is even more challenging, leading to low monitoring efficiency. Summary of the Invention

[0007] The purpose of this invention is to provide a database operation monitoring system based on AI technology to solve the problems mentioned in the background.

[0008] To achieve the above objectives, the present invention provides the following technical solution: a database operation monitoring system based on AI technology, the system comprising:

[0009] The database operation data acquisition module is used to hierarchically divide the database operation environment within a preset range to obtain basic data acquisition units and extract the operation data acquisition intervals corresponding to the basic data acquisition units.

[0010] The multi-dimensional data fusion processing module is used to collect multi-type database operation data corresponding to the operation data acquisition interval according to a preset sampling frequency, and generate time-series fusion data based on the multi-type database operation data;

[0011] The running state feature modeling module is used to abstract the database running state of the running data collection interval based on the time series fusion data to obtain a state abstract model, and to extract the multi-dimensional running features corresponding to the state abstract model using a preset AI analysis framework.

[0012] An abnormal state identification and evaluation module is used to identify local abnormal states of the database in the running data acquisition interval based on the multi-dimensional operating characteristics, and to determine the overall abnormal state of the database based on the local abnormal states.

[0013] The dynamic monitoring strategy generation module is used to dynamically adjust the database monitoring parameters based on the local abnormal state and the overall abnormal state, and to use the database monitoring parameters to perform real-time dynamic monitoring of the database operating environment to obtain the real-time operating status of the database.

[0014] Preferably, when the database operation data acquisition module divides the database operation environment within a preset range into hierarchical levels to obtain basic data acquisition units, it is used for:

[0015] Identify the initial coverage area of ​​the database operating environment within a preset range, and extract the primary boundary value corresponding to the range value of the initial coverage area;

[0016] The database operating environment is divided into first-level data units according to the primary boundary value.

[0017] Identify the secondary coverage area of ​​the first-level data unit and extract the secondary boundary value corresponding to the range value of the secondary coverage area;

[0018] The first-level data unit is divided into second-level units according to the secondary boundary value to obtain the second-level data unit.

[0019] The database operating environment, the first-level data unit, and the second-level data unit are used as data nodes, and the association path between the database operating environment, the first-level data unit, and the second-level data unit is constructed.

[0020] A basic data acquisition unit is generated based on the data nodes and the associated paths;

[0021] When constructing the association path between the database operating environment, the first-level data unit, and the second-level data unit, the following is included:

[0022] Extract the overlap ratio between the database operating environment and the coverage of the first-level data unit to determine the basic association strength;

[0023] Extract the intersection density of the running data between the first-level data unit and the second-level data unit to determine the secondary association strength;

[0024] Path weights are set according to the basic association strength and the secondary association strength. The path from the database operating environment to the first-level data unit is taken as the primary association path, and the path from the first-level data unit to the second-level data unit is taken as the secondary association path.

[0025] The association path is constructed using the primary association path and the secondary association path.

[0026] Preferably, when the multi-dimensional data fusion processing module collects multi-type database operation data corresponding to the operation data acquisition interval according to a preset sampling frequency, it is used for:

[0027] The initial collection time point and time interval of the database running data in the running data collection interval are determined according to the sampling frequency;

[0028] The data acquisition nodes are determined based on the initial collection time point and the time interval.

[0029] The data acquisition node collects operation log data, resource usage data, and response latency data corresponding to the database in the running data acquisition interval.

[0030] The operation log data, resource usage data, and response latency data are integrated into multi-type database operation data corresponding to the operation data collection interval.

[0031] Preferably, when generating time-series fused data based on the multi-type database operating data, the multi-dimensional data fusion processing module is used to:

[0032] Extract the time identifiers corresponding to the runtime data of the various database types;

[0033] The multi-type database operation data corresponding to the time identifiers are arranged in chronological order.

[0034] The sorted multi-type database runtime data is used as time-series fusion data.

[0035] Preferably, when the operation state feature modeling module abstracts the database operation state of the operation data acquisition interval based on the time-series fusion data to obtain a state abstract model, it is used for:

[0036] Extract multi-type database operation data from different nodes within the same time period from the time-series fusion data, and extract operation log data from different nodes within the multi-type database operation data;

[0037] Extract key events from the operation log data of different nodes one by one, and construct logical relationships between the operation log data of different nodes based on the key events;

[0038] Identify the core event sequence based on the logical association, and summarize the typical operation mode of the database based on the occurrence order of the core event sequence;

[0039] A set of status labels for database operation is generated based on the typical pattern. A feature vector space for database operation is generated based on the set of status labels. The statistical regularity of the operation log data is mapped to the feature vector space to obtain the operation abstract model corresponding to the database operation.

[0040] Abstract the resource consumption data and response latency data in the multi-type database operation data;

[0041] The state abstract model is determined based on the abstracted resource usage data, the abstracted response latency data, and the operation abstract model.

[0042] Preferably, when the running state feature modeling module extracts the multi-dimensional running features corresponding to the state abstract model using a preset AI analysis framework, it is used to:

[0043] The performance characteristics of the state abstract model are extracted using an AI analysis framework, wherein the performance characteristics include processing throughput characteristics, response timeliness characteristics, and resource utilization characteristics.

[0044] Extract the abnormal fluctuation characteristics and load distribution characteristics of the state abstract model;

[0045] The performance characteristics, the abnormal fluctuation characteristics, and the load distribution characteristics are defined as multi-dimensional operating characteristics.

[0046] Preferably, when the abnormal state identification and evaluation module identifies local abnormal states of the database in the operational data acquisition interval based on the multi-dimensional operational characteristics, it is used to:

[0047] The performance characteristics in the multidimensional operating characteristics are compared with the pre-set standard performance characteristics to obtain the first comparison coefficient, and the first comparison coefficient is converted into the first outlier.

[0048] The abnormal fluctuation characteristics in the multidimensional operating characteristics are compared with the pre-set standard fluctuation characteristics to obtain the second comparison coefficient, and the second comparison coefficient is converted into the second outlier.

[0049] The load distribution characteristics in the multidimensional operating characteristics are compared with the pre-set standard distribution characteristics to obtain the third comparison coefficient, and the third comparison coefficient is converted into the third outlier.

[0050] Calculate the average anomaly value corresponding to the first anomaly value, the second anomaly value, and the third anomaly value, and determine the local anomaly state of the database in the running data collection interval based on the average anomaly value.

[0051] Preferably, when the dynamic monitoring strategy generation module dynamically adjusts the database monitoring parameters based on the local abnormal state and the overall abnormal state, it is used to:

[0052] The first monitoring density and monitoring period of the first-level data unit are determined based on the overall abnormal state.

[0053] The monitoring focus of the second-level data unit is determined by the local abnormal state, and the second monitoring density and monitoring depth of the monitoring focus are configured.

[0054] Adjust the database monitoring parameters of the first-level data unit according to the first monitoring density and the monitoring period;

[0055] Adjust the database monitoring parameters of the second-level data unit according to the second monitoring density and the monitoring depth.

[0056] Preferably, when the dynamic monitoring strategy generation module uses the database monitoring parameters to perform real-time dynamic monitoring of the database operating environment and obtain the real-time operating status of the database, it is used to:

[0057] The database monitoring parameters are used to collect real-time monitoring data of the database operating environment.

[0058] Analyze the status quantification indicators corresponding to the real-time monitoring data;

[0059] The real-time operating status of the database is determined based on the analyzed state quantification indicators.

[0060] Preferably, the step of constructing logical associations for operation log data under different nodes based on the key events includes:

[0061] Identify the triggering conditions and execution results of the key events, and extract the causal relationships between the events;

[0062] Statistically analyze the frequency of occurrence of the key events within the same time window and extract the co-occurrence relationships of the events;

[0063] The causal relationship and the co-occurrence relationship are taken as the core elements of logical association. Key events with causal relationship are connected by directed edges, and key events with co-occurrence relationship are connected by undirected edges.

[0064] Logical associations are constructed based on the directed edges and the undirected edges.

[0065] Compared with the prior art, the beneficial effects of the present invention are:

[0066] In the data acquisition phase, by dividing the database operating environment into hierarchical levels and constructing basic data acquisition units, we can more precisely and comprehensively cover all aspects of database operation, ensuring the integrity and systematic nature of the collected data and providing a reliable foundation for subsequent analysis. This hierarchical acquisition method allows for targeted setting of acquisition parameters according to the characteristics and needs of different levels, thereby improving data acquisition efficiency.

[0067] The multi-dimensional data fusion processing module collects operational data from various types of databases at a preset sampling frequency and generates time-series fusion data, enabling a multi-dimensional and time-series description of the database's operational status. By integrating operation log data, resource usage data, and response latency data, the relationships between data become clearer, facilitating analysis of the database's operational status from multiple perspectives and laying the foundation for accurate anomaly identification.

[0068] The operational status feature modeling module utilizes an AI analysis framework to process time-series fusion data, extracting multi-dimensional operational features to achieve the abstraction and modeling of the database's operational status. By constructing a state abstract model, it is possible to deeply explore typical patterns and potential laws in database operation, enabling the monitoring system to more accurately understand the normal operating status of the database and providing a scientific basis for anomaly identification.

[0069] The anomaly identification and assessment module compares multi-dimensional operational characteristics with standard characteristics, calculates the anomaly mean to determine local anomalies, and then uses this to determine the overall anomaly status, improving the accuracy and comprehensiveness of anomaly identification. This multi-dimensional anomaly assessment method can more comprehensively consider various influencing factors, reduce false alarms and missed alarms, and ensure timely detection of database anomalies.

[0070] The dynamic monitoring strategy generation module dynamically adjusts database monitoring parameters based on local and overall anomaly states, achieving intelligent and adaptive adjustment of monitoring strategies. Different monitoring densities, time periods, and depths are set for different data units at different levels, ensuring rational allocation of monitoring resources, improving monitoring efficiency, and enabling more targeted focus on potential problem areas for timely detection and handling of anomalies.

[0071] By using adjusted monitoring parameters to perform real-time dynamic monitoring of the database operating environment, the real-time operating status of the database can be obtained in a timely manner, providing the latest monitoring information to operation and maintenance personnel, enabling them to make quick decisions and take corresponding measures to ensure the stable operation of the database. Attached Figure Description

[0072] Figure 1 This is a schematic diagram illustrating the working principle of the AI-based database operation monitoring system described in this invention.

[0073] Figure 2 Design diagram for data acquisition operations for multiple types of databases;

[0074] Figure 3 Design diagram for dynamic adjustment of database monitoring parameters;

[0075] Figure 4 Design diagram for constructing a state abstraction model. Detailed Implementation

[0076] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0077] Please see Figures 1-4 The present invention relates to a database operation monitoring system based on AI technology, the system comprising:

[0078] The database operation data acquisition module is used to hierarchically divide the database operation environment within a preset range to obtain basic data acquisition units and extract the operation data acquisition intervals corresponding to the basic data acquisition units.

[0079] The multi-dimensional data fusion processing module is used to collect multi-type database operation data corresponding to the operation data acquisition interval according to a preset sampling frequency, and generate time-series fusion data based on the multi-type database operation data;

[0080] The running state feature modeling module is used to abstract the database running state of the running data collection interval based on the time series fusion data to obtain a state abstract model, and to extract the multi-dimensional running features corresponding to the state abstract model using a preset AI analysis framework.

[0081] An abnormal state identification and evaluation module is used to identify local abnormal states of the database in the running data acquisition interval based on the multi-dimensional operating characteristics, and to determine the overall abnormal state of the database based on the local abnormal states.

[0082] The dynamic monitoring strategy generation module is used to dynamically adjust the database monitoring parameters based on the local abnormal state and the overall abnormal state, and to use the database monitoring parameters to perform real-time dynamic monitoring of the database operating environment to obtain the real-time operating status of the database.

[0083] Example 1: In the specific implementation of the database operation data acquisition module, the key step is to hierarchically divide the database operation environment within a preset range to obtain the basic data acquisition unit. The specific operation is as follows:

[0084] It is necessary to identify the initial coverage scope of the database operating environment within the preset range. This preset range can be a specific data center, a complete database cluster system, or the database operating environment in a specific business scenario. For example, assuming the preset range is the database operating environment supporting core business operations within an enterprise's data center, then the initial coverage scope includes all relevant hardware devices within that data center, such as database servers, storage devices, network switches, and load balancers, as well as the software environment running on this hardware, including the database management system, operating system, and related middleware. It may also involve business application systems related to database operation and their interaction interfaces.

[0085] Extract the primary boundary value corresponding to the initial coverage range. Determining this primary boundary value requires considering various factors, such as the type of hardware equipment, the division of functional areas, the hierarchical structure of the software system, and the module division of business applications. For example, based on hardware equipment type, the primary boundary value can be set as a threshold categorizing hardware equipment into different types such as server, storage, and network; or based on functional areas, the data center can be divided into core business areas, testing areas, backup areas, etc., and the primary boundary value is the key parameter distinguishing these functional areas.

[0086] The database operating environment is divided into first-level data units based on the primary dividing line values. Taking hardware device type as an example, first-level data units may include database server units, storage device units, network device units, etc. Each first-level data unit has relatively independent functions and characteristics and is a major component of the entire database operating environment.

[0087] Identify the secondary coverage of the first-level data unit. Taking the database server unit as an example, its secondary coverage includes the specific hardware configuration of all servers within the unit (such as CPU model, number of cores, clock speed, memory capacity and type, disk capacity, speed, interface type, etc.), the installed operating system version, the version and configuration parameters of the database management system, the server's IP address in the network, and the network security zone it is located in.

[0088] Next, extract the secondary boundary values ​​corresponding to the range values ​​of the secondary coverage area. For database server units, the secondary boundary values ​​can be determined based on factors such as CPU performance parameters (e.g., whether the clock speed is higher than a certain value), memory capacity (e.g., whether it is greater than a certain threshold), and the version of the database management system (e.g., whether it is the latest stable version). For example, a CPU clock speed of 2.5GHz can be used as a secondary boundary value to distinguish between high-performance servers and ordinary-performance servers.

[0089] The first-level data units are further divided into second-level data units based on the secondary boundary value. Continuing with the database server unit as an example, if the secondary boundary value is set to a CPU clock speed of 2.5GHz, then the second-level data units may include high-performance server groups (CPU clock speed ≥ 2.5GHz) and ordinary server groups (CPU clock speed < 2.5GHz). Each second-level data unit is a further refinement of the first-level data unit, possessing more specific characteristics and attributes.

[0090] The database runtime environment, first-level data units, and second-level data units are considered as data nodes. These data nodes represent different levels and granularities of components within the database runtime environment and form the basis for constructing relationships.

[0091] The process begins by constructing the association paths between the database runtime environment, the first-level data units, and the second-level data units. When constructing these paths, the overlap ratio between the database runtime environment and the first-level data units is first extracted to determine the basic association strength. The overlap ratio can be calculated as the proportion of the first-level data unit within the database runtime environment, such as the proportion of database server units in the overall hardware of the database runtime environment, or their importance weight. A higher overlap ratio indicates a stronger association between the first-level data unit and the database runtime environment, and thus a greater basic association strength.

[0092] Extract the intersection density of operational data between the first-level and second-level data units to determine the strength of secondary associations. Operational data intersection density can be determined by analyzing the correlation and sharing degree of operational data between the two. For example, the higher the degree of intersection between high-performance server groups and database server units in operational data such as CPU utilization, memory usage, and database transaction volume, the closer their association and the stronger the secondary association.

[0093] Path weights are set based on the strength of the primary and secondary associations. Path weight is an indicator of the importance of an association path; the higher the weight, the more important the path's role in data transmission, state impact, etc. Paths from the database operating environment to first-level data units are considered primary association paths because these paths represent the association between the whole and its main components, and typically have high primary association strength and path weight. Paths from first-level data units to second-level data units are considered secondary association paths; their association strength and weight are relatively lower than primary association paths, but they are still important parts of the complete association structure.

[0094] By constructing association paths through primary and secondary association paths, a hierarchical and clearly defined network structure is formed.

[0095] Basic data acquisition units are generated based on these data nodes and their associated paths. A basic data acquisition unit is an organic whole containing data nodes at different levels and their relationships. It comprehensively and systematically describes the structure and composition of the database operating environment, providing clear objectives and scope for subsequent data acquisition work. Through this hierarchical division and association construction, the basic data acquisition unit can grasp the overall state of the database operating environment while also delving into detailed levels, ensuring that the collected data is comprehensive, systematic, and relevant. This lays a solid foundation for subsequent multidimensional data fusion processing and operational status feature modeling.

[0096] Example 2: In the specific implementation of the multi-dimensional data fusion processing module, collecting multi-type database operation data corresponding to the operation data acquisition interval according to the preset sampling frequency and generating time-series fusion data is a key step in realizing database operation monitoring. The specific implementation method is as follows:

[0097] The initial collection time and time interval of database data within the operational data collection period need to be determined based on the preset sampling frequency. The preset sampling frequency can be set according to factors such as the business importance of the database, the data update frequency, and the system resource load. For example, for databases supporting core transaction business, a higher sampling frequency can be set, such as once per second, to capture changes in high-frequency transaction data in real time; while for non-core business databases, a lower sampling frequency can be set, such as once per minute or once every five minutes, to balance data collection accuracy and system resource consumption. The determination of the initial collection time point needs to be combined with the system startup time or the monitoring task trigger time. For example, after the system completes initialization at 6:00 AM every day, 6:00:00 can be used as the initial collection time point to ensure that the collection process is synchronized with the normal operation cycle of the database. The time interval is directly calculated from the sampling frequency. If the sampling frequency is once per second, the time interval is 1 second; if it is once per minute, the time interval is 60 seconds.

[0098] Data acquisition nodes are determined based on the initial collection time and time intervals. These nodes are systematically distributed along the timeline, forming an evenly spaced time sequence. For example, if the initial collection time is 6:00:00 and the sampling frequency is once per minute, the data acquisition nodes will be 6:00:00, 6:01:00, 6:02:00, and so on. Each data acquisition node corresponds to a specific time point to trigger the data acquisition operation, ensuring the timeliness and periodicity of data collection. In practical applications, the system maintains a list of data acquisition nodes, recording the specific timestamp of each node, and executes the data acquisition task at the corresponding time point using a timer or task scheduling mechanism.

[0099] The system collects operation log data, resource usage data, and response latency data for the database within the specified data acquisition period through data acquisition nodes. Operation log data covers various database operation records, including SQL statement execution (such as SELECT, INSERT, UPDATE, DELETE, etc.), transaction start and commit, index creation and deletion, user login and logout, etc. This data is typically stored in the database's log files. The system needs to read and extract key information in real time through the log parsing module, such as operation type, operation object (such as table name, field name), operation initiator, and operation timestamp. Resource usage data mainly includes the usage of hardware resources such as CPU utilization, memory usage, disk I / O rate, and network bandwidth consumption, as well as the system resource usage of database processes. The system can obtain this data by calling API interfaces provided by the operating system (such as the `top` and `iostat` commands in Linux, and performance counters in Windows) or the database's own monitoring views (such as Oracle's V$ views). For example, it can periodically query the CPU's user-mode and kernel-mode usage and idle rate, and record the used and available memory space. Response latency data is used to measure the database's response speed to client requests, including query response time, transaction processing time, and connection establishment time. The system can embed probe programs in the database connection layer or application interface layer to capture the request sending time and response receiving time in real time, calculating the time difference as response latency data. For example, when a client sends a query request, the probe records the request sending time t1, and when the database returns the result, it records the time t2. t2-t1 is the response latency of that query.

[0100] After collecting operation log data, resource usage data, and response latency data, this data needs to be integrated into multi-type database operation data corresponding to the operational data collection period. During the integration process, the various data types are first standardized, unifying data formats and units. For example, CPU utilization data from different sources are uniformly converted to percentage format, and response latency data is uniformly converted to milliseconds. Then, a uniform timestamp is added to each data entry to ensure data temporal consistency. Next, different types of data are linked and integrated according to chronological order and operational relevance to form a dataset containing multi-dimensional information. For example, for the database operation status at a certain point in time, the integrated data should include the operation log records for that time, the corresponding CPU and memory usage, and the response latency data of related requests, enabling various data types to be correlated and mutually corroborated, comprehensively reflecting the database's operational status at that point in time.

[0101] When generating time-series fusion data, the first step is to extract the timestamps corresponding to the runtime data from multiple database types. Each data entry is timestamped during collection; this timestamp serves as the timestamp, typically using a format accurate to milliseconds or microseconds to ensure time precision. For example, a timestamp of "2025-06-25 10:30:45.123" in an operation log entry indicates that the operation occurred on June 25, 2025, at 10:30:45.123 milliseconds.

[0102] The system arranges the various database operation data corresponding to the time stamps in chronological order. It reorders all data according to the order of the time stamps, forming a strictly ascending sequence. For example, data with the time stamp "2025-06-25 10:00:00.000" is processed first, followed by data with the time stamp "2025-06-25 10:00:01.000", and so on, ensuring the continuity and orderliness of the data on the timeline. During the sorting process, if multiple data points from the same time point appear (such as operation log data and resource usage data collected within the same millisecond), they are arranged according to the priority of the data type or preset rules. For example, operation log data is placed before resource usage data so that subsequent analysis can first understand the operation behavior and then examine the resource consumption.

[0103] The sorted multi-type database operation data is used as time-series fusion data. This time-series fusion data is a dataset arranged chronologically and containing multi-dimensional operational information. It organically integrates information such as database operation behavior, resource usage, and response performance during operation, forming a time series that comprehensively reflects the database's operational status. For example, within a certain time period, the time-series fusion data will sequentially record the SQL operation content, CPU utilization changes, memory usage fluctuations, and response latency at each point in time. This allows the system to trace the database's operational trajectory and discover patterns and anomalies during operation by analyzing this time-series data.

[0104] Through the above steps, the multidimensional data fusion processing module realizes the orderly collection and fusion of operational data from multiple types of databases. The generated time-series fusion data provides structured and time-series basic data for subsequent operational status feature modeling, ensuring the accuracy and effectiveness of subsequent analysis.

[0105] Example 3: In the process of the running state feature modeling module abstracting the database running state of the running data collection period based on time-series fusion data and obtaining a state abstract model, it is necessary to achieve in-depth deconstruction of the database running logic through multi-dimensional data processing. The specific implementation method is as follows:

[0106] Extracting various types of database operation data from different nodes within the same time period from time-series fusion data. For example, within a 10-minute time period, it is necessary to synchronously extract operation log data, CPU utilization, memory usage, disk I / O rate, and other resource consumption data for each server node in the database cluster, as well as response latency data for client requests. Different nodes may include master database servers, slave servers, storage nodes, or network switching nodes, etc. The various types of data for each node need to be mapped to a specific time window, such as using 1 minute as the minimum time unit, grouping and extracting the data for each minute of that time period from each node to ensure time alignment of data from different nodes within the same time period.

[0107] After extracting various data types, the focus shifts to processing operation log data, specifically extracting operation log data from different nodes. For example, the operation logs of the master server node might contain transaction commit records and large table query operations, while the logs of storage nodes might involve data block read / write operations, and the logs of network nodes might contain connection establishment and termination records. This operation log data needs to be stored categorized by node type and retain complete timestamp information for subsequent event correlation analysis.

[0108] Extract key events from the operation log data at different nodes one by one. The definition of key events is based on the business logic and technical characteristics of the database operation. For example, for transaction operations, key events include transaction start, data modification, transaction commit or rollback; for query operations, key events include query statement parsing, index usage, and result set return; for system operations, key events include database startup, backup task start, parameter changes, etc. During the extraction process, key fields in the log entries need to be identified through log parsing algorithms, such as event type identifier, operation object, operation result status code, etc. For example, the transaction commit event can be extracted from the log entry "[2025-06-25 14:30:22]TRANSACTIONCOMMIT:ID=1234,TABLE=USER_DATA", with event ID 1234 and operation table USER_DATA.

[0109] When constructing logical relationships between operation log data across different nodes based on key events, the first step is to identify the triggering conditions and execution results of the key events and extract the causal relationships. For example, if a log record shows "Index INDEX_EMPLOYEE creation failed," and a subsequent log record shows "Query speed for the EMPLOYEE table decreased significantly," then it can be inferred that the index creation failure is the cause of the decreased query speed, and the two constitute a causal relationship. In practical implementation, it is necessary to analyze the log context before and after the event, and determine the causal chain through time sequence and semantic relationships. For example, if event B occurs shortly after event A, and the operation object of event A is the same as the affected object of event B, then a causal relationship may exist.

[0110] The system analyzes the frequency of key events occurring within the same time window to extract co-occurrence relationships. For example, if the "user login failed" and "IP address blacklist addition" events frequently occur simultaneously within a 5-minute time window, it indicates a co-occurrence relationship between the two events. The system sets time window thresholds (e.g., 1 minute, 5 minutes) and counts the frequency of key events within each window. When the number of co-occurrences of two events exceeds the preset threshold, a co-occurrence relationship is determined to exist.

[0111] Using causal and co-occurrence relationships as the core elements of logical association, key events with causal relationships are connected by directed edges, with the direction of the directed edges pointing from the cause event to the result event, such as from the "index creation failure" event to the "query speed decrease" event. Key events with co-occurrence relationships are connected by undirected edges, indicating that the two events frequently coexist in time, such as "user login failure" and "IP blacklist addition" connected by an undirected edge. In this way, an event association graph containing directed and undirected edges is constructed, intuitively displaying the logical relationships in the operation log data of different nodes.

[0112] The system identifies core event sequences based on logical relationships. A core event sequence refers to a set of critical events that play a decisive role in the system's state during database operation. For example, in a database backup scenario, a core event sequence might include events such as "backup task start," "data file read," "compression process start," "backup file write," and "backup completion confirmation." These events, in sequence, constitute a complete backup process. The system analyzes the path weights and event influences in the event relationship graph to select event sequences that occur frequently and have a significant impact on the system's state as core event sequences. For example, it determines the criticality of each event in the sequence by calculating its in-degree and out-degree in the relationship graph.

[0113] Based on the order of occurrence of core event sequences, typical database operation modes are summarized. These typical modes include normal operation mode, high load mode, backup mode, and fault recovery mode. For example, the core event sequences "frequent transaction commits," "CPU utilization consistently above 80%," and "gradually increasing response latency" can be summarized as a high load operation mode; while "periodic backup task execution," "increased I / O usage during backup," and "resource release after backup completion" can be summarized as a backup mode. During the summarization process, it is necessary to compare with a pattern library in historical data and use pattern recognition algorithms in machine learning (such as Hidden Markov Models and clustering algorithms) to classify the core event sequences, matching existing typical patterns or discovering new patterns.

[0114] A set of database operation status labels is generated based on typical patterns. These labels include "Normal," "Warning," "Abnormal," "High Load," and "Backing Up," with each label corresponding to a set of characteristics of the typical pattern. For example, the "High Load" label corresponds to characteristics such as transaction commit frequency exceeding a threshold and persistently high CPU and memory usage in the core event sequence; the "Backing Up" label corresponds to the characteristic that backup-related core events are currently being executed. The generation of status labels requires establishing a mapping relationship between labels and typical patterns to form quantifiable judgment criteria. For example, "CPU utilization exceeding 90% for 10 consecutive minutes and response latency exceeding 500ms" is marked as "High Load."

[0115] A feature vector space for database operation is generated based on a set of status labels. This feature vector space is a multi-dimensional space, with each dimension corresponding to a quantifiable feature metric, such as transaction volume, CPU utilization, or response latency quantile. For example, a three-dimensional feature vector space might contain three dimensions: {transaction throughput, memory usage, and average response time}. Each status label corresponds to a region or vector range within this space. The statistical patterns of the operation log data are mapped to the feature vector space. For example, calculating the average transaction throughput, peak memory usage, and quantile of average response time over a certain period forms a specific feature vector. The position of this vector in the space corresponds to the relevant status label, thus obtaining an abstract operational model for the database operation. This model abstractly represents the database's operational state in the form of mathematical vectors.

[0116] While processing operation log data, it is necessary to abstract resource usage data and response latency data from various types of database operation data. Abstraction of resource usage data includes standardizing raw data such as CPU utilization and memory usage (e.g., normalizing to the [0,1] interval), smoothing filtering (removing noise fluctuations), and feature extraction (e.g., calculating statistics such as mean, variance, and peak value). For example, the raw CPU utilization data per minute is converted into the mean and standard deviation for that period, serving as the abstracted features. Abstraction of response latency data includes calculating the response time quantiles (e.g., P50, P90, P99) and the fluctuation range of response times for different types of requests. For example, calculating the P99 response time for query requests reflects the maximum response latency for 99% of query requests.

[0117] The state abstract model is determined based on the abstracted resource usage data, abstracted response latency data, and operational abstract model. The state abstract model is a comprehensive model integrating operational behavior characteristics, resource usage characteristics, and response performance characteristics. For example, the feature vectors from the operational abstract model are merged with the statistical characteristics of resource usage and the quantile characteristics of response latency to form a higher-dimensional feature vector that comprehensively reflects the database's operational status. In practical implementation, feature fusion techniques from machine learning can be used, such as integrating different types of features into a unified model representation through weighted summation or neural network mapping. This allows the state abstract model to reflect both the logical connections at the operational level and the operational status at the resource and performance levels, providing comprehensive feature input for subsequent AI analysis.

[0118] Through the above steps, the operational status feature modeling module realizes the transformation from raw time-series data to an abstract status model. This process, through layer-by-layer abstraction and multi-dimensional fusion, transforms the complex database operational status into a structured feature representation, providing a solid model foundation for subsequent use of AI technology to extract operational features and identify abnormal states, and ensuring the depth and accuracy of the monitoring system's analysis of the database operational status.

[0119] Example 4: When the running state feature modeling module extracts multi-dimensional running features corresponding to the state abstract model using a preset AI analysis framework, it is necessary to combine multi-dimensional feature analysis with AI algorithms to achieve a deep characterization of the database running state. The specific implementation method is as follows:

[0120] Taking a distributed database cluster of an e-commerce platform as an example, this cluster carries core business operations such as daily product browsing and order processing. After the system obtains the state abstract model of the database cluster, it first uses an AI analysis framework to extract its performance characteristics. Extracting throughput characteristics requires analyzing the number of transactions and query operations processed by the database per unit of time. For example, during the peak shopping period at 10 AM daily, the AI ​​analysis framework extracts the number of transaction commits in the order database during that time period from the state abstract model, such as the number of order creation transactions and product inventory update transactions completed per minute. It also counts the number of complex query operations, such as multi-table join queries and full-text search queries, thus forming specific data on throughput characteristics. Response timeliness characteristics focus on the database's response speed to various requests. The AI ​​analysis framework extracts response time data for different business scenarios from the state abstract model, such as the average response time for order query requests and the 95th percentile response time for product detail page loading requests. This data reflects the database's timeliness performance when handling different types of requests. Extracting resource utilization features involves the efficiency of hardware resources such as CPU, memory, and disk. The AI ​​analysis framework obtains the CPU utilization of each database node from the state abstraction model, such as the CPU user mode and kernel mode utilization distribution of the master node during peak periods, memory cache hit rate, such as the InnoDB buffer pool hit rate, and disk I / O throughput and average response time, etc., and comprehensively reflects the resource utilization through these data.

[0121] After extracting performance characteristics, the AI ​​analysis framework further extracts abnormal fluctuation characteristics from the state abstract model. Taking this e-commerce database as an example, abnormal fluctuation characteristics mainly analyze the fluctuations of database operation data over time. For instance, at 3 PM on a certain day, the system detects that the number of order creation transactions suddenly drops from a normal 2000 transactions per minute to 500 transactions per minute within 10 minutes, and then recovers to normal levels within 5 minutes. The AI ​​analysis framework captures the amplitude, duration, and frequency of this data fluctuation, including it as part of the abnormal fluctuation characteristics. Simultaneously, the framework also analyzes abnormal fluctuations in resource usage data, such as memory usage fluctuating drastically in a short period, suddenly surging from a normal 60% utilization rate to 95%, and then quickly falling back. This abnormal fluctuation pattern is also extracted and recorded.

[0122] Load distribution feature extraction focuses on the distribution of database load across various nodes and time periods. In this e-commerce distributed database, load distribution may involve the read / write load allocation between master and slave nodes, as well as the load of database shards corresponding to different business modules. The AI ​​analysis framework extracts the number of read and write requests for each master and slave node from the state abstraction model. For example, it examines whether the proportion of write operations handled by the master node is reasonable, whether the read requests handled by the slave nodes are balanced, and whether any slave node is overloaded due to handling too many read requests. Simultaneously, the framework analyzes the load distribution over different time periods, such as the load difference between weekdays and weekends, and the load variation patterns between peak and off-peak periods, thereby forming load distribution features.

[0123] When extracting throughput features from performance characteristics, AI analytics frameworks may employ sliding window statistics to calculate transaction and query volumes across different time windows, capturing short-term and long-term throughput trends. For example, sliding windows of varying lengths (5 minutes, 1 hour, 1 day, etc.) can be set, and the mean and variance of throughput within each window can be calculated to comprehensively reflect throughput variations. For response timeliness features, the framework may use quantile statistics to calculate response times at different percentiles, providing a more comprehensive description of the response time distribution, rather than just the average, which can be influenced by a few extreme values.

[0124] When extracting abnormal fluctuation features, AI analysis frameworks may employ methods from statistical process control, such as setting upper and lower limits. When data exceeds these limits, it is considered an abnormal fluctuation. For example, for CPU utilization, the framework calculates the mean and standard deviation during normal operation based on historical data, sets the mean plus or minus three times the standard deviation as the control limit, and considers an abnormal fluctuation when CPU utilization exceeds this limit, extracting the relevant fluctuation features. Furthermore, the framework may also use anomaly detection algorithms from machine learning, such as Isolation Forest and One-Class SVM, to identify abnormal fluctuation patterns in the data. These algorithms can automatically learn the distribution characteristics of normal data, thereby detecting fluctuations that deviate from normal patterns.

[0125] For extracting load distribution characteristics, AI analysis frameworks may employ a combination of visualization and statistical analysis. For example, they might generate heatmaps of the load on each node to visually display the load distribution, while simultaneously calculating load balancing indices, such as the ratio of the standard deviation to the mean of the load on each node, to quantify the degree of load balance. The framework may also analyze load variation patterns over time, such as the presence of periodic load fluctuations or sudden load spikes; this information is crucial for understanding the load distribution characteristics of the database.

[0126] The extracted performance characteristics, abnormal fluctuation characteristics, and load distribution characteristics are defined as multi-dimensional operational characteristics. In the example of this e-commerce database, these multi-dimensional operational characteristics may include peak processing throughput, response timeliness indicators for different business requests, utilization rate of various hardware resources, amplitude and frequency of data fluctuations, and load balancing degree of master-slave nodes. These multi-dimensional operational characteristics comprehensively describe the database's operational status from different perspectives, providing rich feature inputs for subsequent anomaly identification and assessment.

[0127] By processing the state abstract model through an AI analysis framework, the abstract model is transformed into concrete features. These features can effectively reflect the database's operational status and potential problems. For example, throughput features can help determine whether the database can meet business needs, response timeliness features can reflect the quality of user experience, resource utilization features can indicate whether there is resource waste or bottlenecks, abnormal fluctuation features can warn of potential failures, and load distribution features can guide the adjustment of load balancing strategies.

[0128] Throughout the extraction process, the AI ​​analysis framework automatically mines valuable features from the state abstraction model based on preset algorithms and rules, without requiring manual intervention, thus improving the efficiency and accuracy of feature extraction. Furthermore, by combining specific business scenarios and database characteristics, the extracted features are targeted and practical, better serving database operation monitoring and anomaly identification.

[0129] Example 5: When the anomaly identification and evaluation module identifies local anomalies in the database within the data acquisition range based on multi-dimensional operational characteristics, anomaly localization needs to be achieved through multi-dimensional feature comparison and quantitative analysis. The specific implementation method is as follows:

[0130] Taking a financial institution's core transaction database as an example, this database handles tens of thousands of transactions daily, including fund transfers and account inquiries. When the system acquires multi-dimensional operational characteristics of a specific data collection period from this database, it first compares the performance characteristics within these multi-dimensional characteristics with pre-defined standard performance characteristics. Performance characteristics include throughput, response timeliness, and resource utilization. Standard performance characteristics are benchmark values ​​set based on historical normal operation data and business requirements. For example, the standard characteristic for throughput is set as the peak transaction period from 9:00 AM to 11:00 AM daily, requiring at least 5,000 transfer transactions per minute. The AI ​​analysis framework compares the actual number of transfer transactions per minute within this collection period with 5,000 transactions to obtain the first comparison coefficient. If the actual processing volume is 4,000 transactions, the first comparison coefficient is 0.8. Then, the first comparison coefficient is converted into the first outlier. The conversion rule can be set according to the importance of the business. For example, when the comparison coefficient is less than 1, the outlier = (1 - comparison coefficient) × 100, that is, the first outlier is (1 - 0.8) × 100 = 20.

[0131] Next, the abnormal fluctuation characteristics in the multidimensional operational features are compared with the pre-defined standard fluctuation characteristics. The standard fluctuation characteristics are derived from historical data statistics; for example, the normal fluctuation range of database CPU utilization is the mean ± 15%. Suppose that within the collection period, the CPU utilization of a database node suddenly spikes from the mean of 60% to 85% within 10 minutes, exceeding the upper limit of the standard fluctuation range (60% + 15% = 75%). Then, the difference between the actual fluctuation amplitude and the upper limit of the standard fluctuation is calculated to obtain the second comparison coefficient, i.e., (85% - 75%) / 75% ≈ 0.133. The second comparison coefficient is then converted into a second outlier, which can be done by converting the outlier to the comparison coefficient multiplied by 100; that is, the second outlier is 13.3.

[0132] Next, the load distribution characteristics in the multi-dimensional operational features are compared with the pre-defined standard distribution characteristics. The standard distribution characteristics are set according to the load balancing requirements of the distributed database; for example, the difference in read / write load between master and slave nodes should not exceed 30%. If, during the collection period, the master node undertakes 70% of the write operations, while the slave node only undertakes 30%, compared to the standard distribution characteristic requirement that the master node's write operations should not exceed 50%, a third comparison coefficient is obtained: (70% - 50%) / 50% = 0.4. This third comparison coefficient is then converted into a third outlier, such as outlier = comparison coefficient × 100, meaning the third outlier is 40.

[0133] Calculate the mean anomaly value corresponding to the first, second, and third outliers, i.e., (20 + 13.3 + 40) / 3 ≈ 24.43. Based on this mean anomaly value, determine the local anomaly state of the database within the data collection period. If the preset anomaly threshold is 20, when the mean anomaly value of 24.43 exceeds the threshold, it is determined that a local anomaly exists within the data collection period. For example, it can be located that the master node of the financial database has a local anomaly due to excessive write load.

[0134] After identifying local anomalies, the overall database anomaly status needs to be determined based on these local anomalies. For example, if a financial database consists of multiple master-slave node clusters, and similar local anomalies of excessively high write load are detected in multiple data collection intervals (such as intervals where multiple master nodes reside), and the average anomaly value generally exceeds the threshold, then it can be comprehensively judged that the overall database may be in an anomaly state where the load balancing strategy has failed. If only a few intervals show local anomalies, and the average anomaly value in other intervals does not exceed the threshold, then the determination of the overall anomaly status needs to consider the scope and severity of the impact of the local anomalies, such as whether the local anomaly leads to increased transaction response latency in core business operations, or whether it affects the normal operation of other nodes.

[0135] When the dynamic monitoring strategy generation module dynamically adjusts database monitoring parameters based on local and overall anomaly states, taking this financial database as an example, it first determines the first monitoring density and monitoring period for the first-level data unit based on the overall anomaly state. If the overall anomaly state indicates that the load balancing strategy has failed, the first-level data unit can be set as a "master-slave node cluster," and the first monitoring density needs to be increased. For example, the frequency of collecting load data once every 10 minutes can be adjusted to once every 2 minutes, and the monitoring period can be extended to cover the entire 24 hours of the day to track load changes in real time.

[0136] By identifying localized anomalies, the monitoring focus of the second-level data unit can be determined, and the secondary monitoring density and depth can be configured accordingly. For localized anomalies indicating excessive write load on the master node, the second-level data unit can be designated as the "master node write operation module," with monitoring focusing on the source, type, and resource consumption of write operations within this module. The secondary monitoring density is increased to collect write operation logs every 30 seconds, and the monitoring depth is increased, including not only collecting the number of write operations but also analyzing detailed information such as specific SQL statements, involved table structures, and index usage.

[0137] Adjust the database monitoring parameters of the first-level data unit according to the first monitoring density and monitoring period. For example, modify the monitoring script of the master-slave node cluster, change the data collection frequency from 10 minutes / time to 2 minutes / time, and set a scheduled task to cover the entire day to ensure real-time collection of load data.

[0138] Adjust the database monitoring parameters of the second-level data unit according to the second monitoring density and monitoring depth. For example, in the database monitoring configuration of the master node, add detailed log recording parameters for write operation SQL, set it to capture the complete SQL text, execution plan and resource consumption indicators of write operation once every 30 seconds, and store these data in a dedicated monitoring log table for subsequent analysis.

[0139] When using database monitoring parameters to perform real-time dynamic monitoring of the database operating environment and obtain the real-time operating status of the database, the system uses the adjusted monitoring parameters to collect real-time monitoring data of the database operating environment, such as the latest load distribution of the master-slave node cluster and the specific SQL execution status of the master node write operation module.

[0140] Analyze the status quantification indicators corresponding to real-time monitoring data, such as calculating whether the latest collected master node write operation volume still exceeds the standard value, analyzing whether the specific SQL statements that cause excessive write load are high-frequency abnormal statements, and evaluating whether the resource consumption of these statements is reasonable.

[0141] The real-time operating status of the database is determined based on the analyzed status quantification indicators. If the write operation volume of the master node has dropped to the standard range and the abnormal SQL statement has been identified and optimized, the real-time operating status of the database is considered to have returned to normal. If the write load is still too high and the specific cause cannot be located, it may be necessary to further adjust the monitoring strategy or trigger the alarm mechanism to prompt the operation and maintenance personnel to intervene.

[0142] Throughout the implementation process, local anomalies were identified through quantitative comparison of multi-dimensional operational characteristics. Then, the database status was assessed from a local to a global perspective, and monitoring parameters were dynamically adjusted. This enabled accurate identification and targeted monitoring of database anomalies. This data-driven monitoring strategy adjustment mechanism can flexibly configure monitoring intensity based on the actual operating status of the database, ensuring monitoring accuracy while avoiding resource waste. It provides an effective monitoring solution for scenarios such as finance, where database stability requirements are extremely high.

[0143] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0144] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A database operation monitoring system based on AI technology, characterized in that, The system includes: The database operation data acquisition module is used to hierarchically divide the database operation environment within a preset range to obtain basic data acquisition units and extract the operation data acquisition intervals corresponding to the basic data acquisition units. The multi-dimensional data fusion processing module is used to collect multi-type database operation data corresponding to the operation data acquisition interval according to a preset sampling frequency, and generate time-series fusion data based on the multi-type database operation data; The running state feature modeling module is used to abstract the database running state of the running data collection interval based on the time series fusion data to obtain a state abstract model, and to extract the multi-dimensional running features corresponding to the state abstract model using a preset AI analysis framework. An abnormal state identification and evaluation module is used to identify local abnormal states of the database in the data acquisition interval based on the multi-dimensional operating characteristics, and to determine the overall abnormal state of the database based on the local abnormal states. The database consists of a cluster of multiple master-slave nodes. When local abnormalities are detected in multiple data acquisition intervals and the average value of the abnormalities generally exceeds the threshold, it is determined that the database as a whole is in an abnormal state. A dynamic monitoring strategy generation module is used to dynamically adjust the database monitoring parameters based on the local abnormal states and the overall abnormal states, and to use the database monitoring parameters to perform real-time dynamic monitoring of the database operating environment to obtain the real-time operating status of the database. When the operational status feature modeling module abstracts the database operational status of the operational data acquisition interval based on the time-series fusion data to obtain a status abstract model, it is used for: Extract multi-type database operation data from different nodes within the same time period from the time-series fusion data, and extract operation log data from different nodes within the multi-type database operation data; Extract key events from the operation log data of different nodes one by one, and construct logical relationships between the operation log data of different nodes based on the key events; Identify the core event sequence based on the logical association, and summarize the typical operation mode of the database based on the occurrence order of the core event sequence; A set of status labels for database operation is generated based on the typical pattern. A feature vector space for database operation is generated based on the set of status labels. The statistical regularity of the operation log data is mapped to the feature vector space to obtain the operation abstract model corresponding to the database operation. Abstract the resource consumption data and response latency data in the multi-type database operation data; The state abstract model is determined based on the abstracted resource usage data, the abstracted response latency data, and the operation abstract model. When the operational state feature modeling module extracts the multidimensional operational features corresponding to the state abstract model using a preset AI analysis framework, it is used for: The performance characteristics of the state abstract model are extracted using an AI analysis framework, wherein the performance characteristics include processing throughput characteristics, response timeliness characteristics, and resource utilization characteristics. Extract the abnormal fluctuation characteristics and load distribution characteristics of the state abstract model; The performance characteristics, the abnormal fluctuation characteristics, and the load distribution characteristics are defined as multi-dimensional operating characteristics.

2. The database operation monitoring system based on AI technology as described in claim 1, characterized in that, When the database operation data acquisition module divides the database operation environment within a preset range into hierarchical levels to obtain basic data acquisition units, it is used for: Identify the initial coverage area of ​​the database operating environment within a preset range, and extract the primary boundary value corresponding to the range value of the initial coverage area; The database operating environment is divided into first-level data units according to the primary boundary value. Identify the secondary coverage area of ​​the first-level data unit and extract the secondary boundary value corresponding to the range value of the secondary coverage area; The first-level data unit is divided into second-level units according to the secondary boundary value to obtain the second-level data unit. The database operating environment, the first-level data unit, and the second-level data unit are used as data nodes, and the association path between the database operating environment, the first-level data unit, and the second-level data unit is constructed. A basic data acquisition unit is generated based on the data nodes and the associated paths; When constructing the association path between the database operating environment, the first-level data unit, and the second-level data unit, the following is included: Extract the overlap ratio between the database operating environment and the coverage of the first-level data unit to determine the basic association strength; Extract the intersection density of the running data between the first-level data unit and the second-level data unit to determine the secondary association strength; Path weights are set according to the basic association strength and the secondary association strength. The path from the database operating environment to the first-level data unit is taken as the primary association path, and the path from the first-level data unit to the second-level data unit is taken as the secondary association path. The association path is constructed using the primary association path and the secondary association path.

3. The database operation monitoring system based on AI technology as described in claim 1, characterized in that, When the multi-dimensional data fusion processing module collects multi-type database operation data corresponding to the operation data acquisition interval according to a preset sampling frequency, it is used for: The initial collection time point and time interval of the database running data in the running data collection interval are determined according to the sampling frequency; The data acquisition nodes are determined based on the initial collection time point and the time interval. The data acquisition node collects operation log data, resource usage data, and response latency data corresponding to the database in the running data acquisition interval. The operation log data, resource usage data, and response latency data are integrated into multi-type database operation data corresponding to the operation data collection interval.

4. The database operation monitoring system based on AI technology as described in claim 1, characterized in that, When generating time-series fused data based on the multi-type database operating data, the multi-dimensional data fusion processing module is used for: Extract the time identifiers corresponding to the runtime data of the various database types; The multi-type database operation data corresponding to the time identifiers are arranged in chronological order. The sorted multi-type database runtime data is used as time-series fusion data.

5. The database operation monitoring system based on AI technology as described in claim 1, characterized in that, When the abnormal state identification and evaluation module identifies local database abnormal states in the operational data acquisition interval based on the multi-dimensional operational characteristics, it is used for: The performance characteristics in the multidimensional operating characteristics are compared with the pre-set standard performance characteristics to obtain the first comparison coefficient, and the first comparison coefficient is converted into the first outlier. The abnormal fluctuation characteristics in the multidimensional operating characteristics are compared with the pre-set standard fluctuation characteristics to obtain the second comparison coefficient, and the second comparison coefficient is converted into the second outlier. The load distribution characteristics in the multidimensional operating characteristics are compared with the pre-set standard distribution characteristics to obtain the third comparison coefficient, and the third comparison coefficient is converted into the third outlier. Calculate the average anomaly value corresponding to the first anomaly value, the second anomaly value, and the third anomaly value, and determine the local anomaly state of the database in the running data collection interval based on the average anomaly value.

6. The database operation monitoring system based on AI technology as described in claim 1, characterized in that, When the dynamic monitoring strategy generation module dynamically adjusts the database monitoring parameters based on the local and overall abnormal states, it is used to: The first monitoring density and monitoring period of the first-level data unit are determined based on the overall abnormal state. The monitoring focus of the second-level data unit is determined by the local abnormal state, and the second monitoring density and monitoring depth of the monitoring focus are configured. Adjust the database monitoring parameters of the first-level data unit according to the first monitoring density and the monitoring period; Adjust the database monitoring parameters of the second-level data unit according to the second monitoring density and the monitoring depth.

7. The database operation monitoring system based on AI technology as described in claim 1, characterized in that, When the dynamic monitoring strategy generation module uses the database monitoring parameters to perform real-time dynamic monitoring of the database operating environment and obtain the real-time operating status of the database, it is used for: The database monitoring parameters are used to collect real-time monitoring data of the database operating environment. Analyze the status quantification indicators corresponding to the real-time monitoring data; The real-time operating status of the database is determined based on the analyzed state quantification indicators.

8. The database operation monitoring system based on AI technology as described in claim 1, characterized in that, The logical association of operation log data under different nodes based on the key events includes: Identify the triggering conditions and execution results of the key events, and extract the causal relationships between the events; Statistically analyze the frequency of occurrence of the key events within the same time window and extract the co-occurrence relationships of the events; The causal relationship and the co-occurrence relationship are taken as the core elements of logical association. Key events with causal relationship are connected by directed edges, and key events with co-occurrence relationship are connected by undirected edges. Logical associations are constructed based on the directed edges and the undirected edges.

Images