Database health examination method and device, equipment, storage medium and program product

Abstract

The invention provides a database health examination method and device, equipment, a storage medium and a program product, and relates to the technical field of database management. The method comprises the following steps: collecting system resource indexes according to data collection frequency, wherein the system resource indexes comprise at least one of the following items: storage space utilization rate, memory consumption growth rate, input / output delay and snapshot table size; judging whether the system resource index meets a preset database health state or not; under the condition that the system resource index does not meet the preset database health state, a dynamic adjustment strategy is triggered, and the dynamic adjustment strategy comprises at least one of reducing the data collection frequency, reducing the number of items of the system resource index and cleaning historical snapshot data. The method is used for improving the database stability and the resource utilization rate.

Description

Technical Field

[0001] This application relates to the field of database management technology, and in particular to a database health check method, apparatus, device, storage medium, and program product. Background Technology

[0002] In modern enterprise database systems, as business scale expands and data volume surges, databases need to handle high-concurrency requests while ensuring the availability and responsiveness of critical business services. To guarantee stable database operation, database health checks are performed to generate database performance reports. Therefore, knowing how to check database health is crucial.

[0003] Currently, existing database health check methods mainly perform checks at a fixed frequency and with preset granularity. This method requires triggering snapshot operations at preset time intervals to collect statistical information and a large number of fine-grained indicators during database operation, and then storing this data in a snapshot table.

[0004] However, existing database health check methods rely on fixed frequencies and preset granularity, leading to resource waste and making it difficult to guarantee the stability of the database system. Summary of the Invention

[0005] This application provides a database health check method, apparatus, device, storage medium, and program product to improve database stability and resource utilization.

[0006] Firstly, this application provides a database health check method, including:

[0007] System resource indicators are collected according to the data collection frequency. The system resource indicators include at least one of the following: storage space utilization rate, memory consumption growth rate, input / output latency, and snapshot table size.

[0008] Determine whether the system resource indicators meet the preset database health status;

[0009] If the system resource indicators do not meet the preset database health status, a dynamic adjustment strategy is triggered. The dynamic adjustment strategy includes at least one of the following: reducing the data collection frequency, reducing the number of system resource indicators, and clearing historical snapshot data.

[0010] In one possible implementation, the system resource indicators failing to meet the preset database health status include at least one of the following:

[0011] The storage space utilization rate exceeds the utilization rate threshold;

[0012] The memory consumption growth rate exceeds the growth rate threshold;

[0013] The input / output delay exceeds the delay threshold;

[0014] The size of the snapshot table exceeds the size threshold.

[0015] In one possible implementation, the storage space utilization rate is calculated based on the actual storage space utilization rate and a first dynamic weight; the memory consumption growth rate is calculated based on the actual memory consumption growth rate and a second dynamic weight; the input / output latency is calculated based on the actual input / output latency and a third dynamic weight; and the snapshot table size is calculated based on the actual snapshot table size and a fourth dynamic weight.

[0016] The first dynamic weight, the second dynamic weight, the third dynamic weight, and the fourth dynamic weight are all dynamically adjusted according to the current business scenario.

[0017] In one possible implementation, during the process of determining whether the system resource indicators meet the preset database health status, if any system resource indicator does not meet the preset database health status, the determination of the undetermined indicators among the system resource indicators is stopped, and it is determined that the system resource indicator does not meet the preset database health status.

[0018] In one possible implementation, reducing the data acquisition frequency includes: reducing the number of snapshot data generation times by adjusting the snapshot generation interval parameter;

[0019] The reduction of the number of system resource indicators includes: disabling the collection of non-core statistical items by modifying database configuration parameters;

[0020] The cleanup of historical snapshot data includes: deleting snapshot records that have exceeded the retention period by performing a cleanup task.

[0021] In one possible implementation, the method further includes:

[0022] The system periodically checks subsequent system resource indicators. When the subsequent system resource indicators all meet the preset database health status for multiple consecutive periods, the original operating parameters before the dynamic adjustment strategy was implemented are restored.

[0023] In one possible implementation, the method further includes:

[0024] Based on historical resource consumption data, a time series forecasting model is used to predict future resource trends and obtain the forecast results.

[0025] The data collection frequency is adjusted based on the prediction results.

[0026] Secondly, this application provides a database health check device, comprising:

[0027] The data acquisition module is used to collect system resource indicators according to the data acquisition frequency. The system resource indicators include at least one of the following: storage space utilization rate, memory consumption growth rate, input / output latency, and snapshot table size.

[0028] The judgment module is used to determine whether the system resource indicators meet the preset database health status.

[0029] The triggering module is used to trigger a dynamic adjustment strategy when the system resource indicators do not meet the preset database health status. The dynamic adjustment strategy includes at least one of the following: reducing the data collection frequency, reducing the number of system resource indicators, and clearing historical snapshot data.

[0030] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0031] The memory stores computer-executed instructions;

[0032] The processor executes computer execution instructions stored in the memory, causing the processor to perform the method described in any of the first aspects above.

[0033] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method described in any of the first aspects above.

[0034] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the method described in any of the first aspects above.

[0035] This application provides a database health check method, apparatus, device, storage medium, and program product. It collects system resource indicators according to a data acquisition frequency. These system resource indicators include at least one of the following: storage space utilization rate, memory consumption growth rate, input / output latency, and snapshot table size, laying the foundation for subsequent database health status assessment. The system determines whether the system resource indicators meet a preset database health status. If the system resource indicators do not meet the preset database health status, a dynamic adjustment strategy can be triggered. This dynamic adjustment strategy includes at least one of the following: reducing the data acquisition frequency, reducing the number of system resource indicators, and clearing historical snapshot data, thereby reducing response latency and improving database stability and resource utilization. Attached Figure Description

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

[0037] Figure 1 A flowchart illustrating a database health check method provided in this application;

[0038] Figure 2 A flowchart illustrating a control method based on a Health Check Agent provided for this application;

[0039] Figure 3 A flowchart illustrating a periodic health check method for a database provided in this application;

[0040] Figure 4 A flowchart illustrating a database health check threshold determination method provided in this application;

[0041] Figure 5 A flowchart illustrating another database health check method provided in this application;

[0042] Figure 6 A schematic diagram of the structure of a database health check device provided in this application;

[0043] Figure 7 This is a schematic diagram of the structure of an electronic device provided in this application.

[0044] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0045] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0046] In this application, the term "comprising" and its variations can refer to non-limiting inclusion; the term "or" and its variations can refer to "and / or". The terms "first", "second", etc., in this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. In this application, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0047] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation access points for users to choose to authorize or refuse.

[0048] Furthermore, the technical solution involved in this application, which involves big data analysis of user information (including but not limited to personal biometrics, identity data, consumption data, asset data, electronic terminal operation data, etc.) and the use of artificial intelligence technology for automated decision-making, and makes decisions that have a significant impact on personal rights based on the results of automated decision-making, provides users with corresponding operation entry points for users to choose to agree to or reject the results of automated decision-making; if the user chooses to reject, the process will proceed to the expert decision-making process.

[0049] First, let's explain some of the terms used in this application:

[0050] Health check scheduler: refers to the module that periodically triggers health check tasks.

[0051] Snapshot table: refers to the table in the performance reporting system that stores snapshot data.

[0052] One-vote veto mechanism: refers to the logical design that triggers a downgrade strategy when any core indicator exceeds the threshold.

[0053] Statistical granularity refers to the level of detail in performance data collection.

[0054] Structured Query Language (SQL) is a standardized programming language used to interact with relational databases for querying, updating, defining, and controlling data.

[0055] In modern enterprise database systems, as business scale expands and data volume surges, databases need to handle high-concurrency requests while ensuring the availability and responsiveness of critical business services. To guarantee stable database operation, database health checks are performed to generate database performance reports. Therefore, knowing how to check database health is crucial.

[0056] Currently, existing database health check methods mainly perform checks at a fixed frequency and with preset granularity. This method requires triggering snapshot operations at preset time intervals to collect statistical information and a large number of fine-grained indicators during database operation, and then storing this data in a snapshot table.

[0057] However, existing database health check methods rely on fixed frequencies and preset granularity, leading to resource waste and difficulty in ensuring database system stability. Considering these problems, this application proposes a method for database health checks that does not rely on fixed frequencies and preset granularity. This method improves database stability and resource utilization.

[0058] The entity performing this database health check method can be, for example, a database performance reporting system. Optionally, the database performance reporting system can be any existing electronic device with processing capabilities, such as a terminal or a server. In some embodiments, the database performance reporting system can also be deployed in a server cluster or cloud environment. This application does not limit the deployment environment of the database performance reporting system.

[0059] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments.

[0060] The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0061] Figure 1 This is a flowchart illustrating a database health check method provided in this application. Figure 1 As shown, the method includes:

[0062] S101. Collect system resource indicators according to the data acquisition frequency. The system resource indicators include at least one of the following: storage space utilization rate, memory consumption growth rate, input / output latency, and snapshot table size.

[0063] For example, the data collection frequency can be the time interval for periodically detecting and acquiring system resource indicators.

[0064] For example, system resource indicators can be key quantitative data that reflect the operating status of system resources.

[0065] For example, storage space utilization can be the percentage of the total capacity of the storage medium that has been used.

[0066] For example, the memory consumption growth rate can be the rate of change in memory usage per unit of time.

[0067] For example, input / output latency can be the average time taken to complete one data read / write operation.

[0068] For example, the snapshot table size can be the storage space occupied by the database table that stores data snapshots.

[0069] As one possible implementation, the database performance reporting system can calculate the storage space utilization rate based on the actual storage space utilization rate and a first dynamic weight; the memory consumption growth rate based on the actual memory consumption growth rate and a second dynamic weight; the input / output latency based on the actual input / output latency and a third dynamic weight; and the snapshot table size based on the actual snapshot table size and a fourth dynamic weight. The database performance reporting system can dynamically adjust the first dynamic weight, the second dynamic weight, the third dynamic weight, and the fourth dynamic weight according to the current business scenario.

[0070] Optionally, the database performance reporting system can identify different business scenarios based on business load type, business importance, and resource consumption characteristics. For example, different business scenarios may include high-concurrency write scenarios, read-write intensive scenarios, data backup scenarios, and routine stable scenarios. Preset common database business scenarios are also included.

[0071] Optionally, the database performance reporting system can label core influencing indicators for each scenario and establish a correspondence between business scenarios and dynamic weights. For example, for high-concurrency write scenarios, the first dynamic weight is set to 0.15, the second dynamic weight to 0.35, the third dynamic weight to 0.4, and the fourth dynamic weight to 0.1. For read-write intensive scenarios, the first dynamic weight is set to 0.1, the second dynamic weight to 0.45, the third dynamic weight to 0.35, and the fourth dynamic weight to 0.1. For data backup scenarios, the first dynamic weight is set to 0.3, the second dynamic weight to 0.1, the third dynamic weight to 0.1, and the fourth dynamic weight to 0.5. For data backup scenarios, the first dynamic weight is set to 0.25, the second dynamic weight to 0.25, the third dynamic weight to 0.25, and the fourth dynamic weight to 0.25.

[0072] Optionally, the database performance reporting system can use a scenario identification module to monitor features such as business request type, request frequency, and snapshot generation status in real time to determine the current business scenario. After identifying the current business scenario, the database performance reporting system can retrieve the corresponding four dynamic weights from the rule base.

[0073] Optionally, the database performance reporting system can obtain the storage space utilization rate by calculating the product of the actual storage space utilization rate and the first dynamic weight; the memory consumption growth rate by calculating the actual memory consumption growth rate and the second dynamic weight; the input / output latency by calculating the actual input / output latency and the third dynamic weight; and the snapshot table size by calculating the actual snapshot table size and the fourth dynamic weight. Based on the four system resource indicator values ​​obtained above, the current business scenario label, and the weight configuration information, corresponding tables are constructed and stored in the database.

[0074] Using the methods described above, the storage space utilization rate can be calculated based on the actual storage space utilization rate and the first dynamic weight; the memory consumption growth rate can be calculated based on the actual memory consumption growth rate and the second dynamic weight; the input / output latency can be calculated based on the actual input / output latency and the third dynamic weight; and the snapshot table size can be calculated based on the actual snapshot table size and the fourth dynamic weight. This lays the foundation for subsequent database health checks. Dynamically adjusting the first, second, third, and fourth dynamic weights according to the current business scenario can enhance the accuracy of database health status determination.

[0075] Optionally, the database performance reporting system can collect system resource metrics at preset fixed intervals through system configuration files or the monitoring platform interface. The system can also automatically adjust the data collection frequency based on system load. For example, if processor utilization exceeds 80%, the system determines it as a high load and increases the data collection frequency; if processor utilization is below 40%, the system determines it as a low load and decreases the data collection frequency.

[0076] As one possible implementation, the database performance reporting system can also use a time series forecasting model to predict future resource trends based on historical resource consumption data, and then adjust the data collection frequency according to the forecast results.

[0077] For example, historical resource consumption data can be a collection of raw and statistical data of system resource indicators collected and stored within a historical period.

[0078] For example, a time series forecasting model can be a mathematical model that analyzes the patterns of data change and predicts future values ​​based on historical data arranged in an ordered manner along the time dimension.

[0079] Optionally, the database performance reporting system can filter outliers and missing values ​​generated during historical data collection, mapping system resource metrics from different dimensions to the same numerical range to obtain preprocessed historical resource consumption data. This historical resource consumption data is then sorted by timestamp and stored in a time-series database.

[0080] Optionally, the database performance reporting system can use an Application Programming Interface (API) to divide historical resource consumption data in the time series database into training and validation sets, which are then input into the time series prediction model. The training set allows the time series prediction model to learn data change patterns. Based on set timed prediction trigger conditions, the latest historical data is input to cause the time series prediction model to output future resource trend prediction results. For example, the timed prediction trigger condition could be to perform a prediction every 30 minutes.

[0081] Optionally, if the future trend is that the fluctuation range of the indicator in the next hour is less than 5%, the database performance reporting system can determine that the prediction result is a stable resource trend; if the future trend is that the memory consumption growth rate in the next hour is greater than 10%, the database performance reporting system can determine that the prediction result is an upward resource trend; if the future trend is that the input / output latency continues to decrease in the next hour, the database performance reporting system can determine that the prediction result is a downward resource trend.

[0082] Optionally, the database performance reporting system can predefine the correspondence rules between prediction results and data collection frequency, and dynamically adjust the data collection frequency based on the prediction results and the aforementioned correspondence rules. For example, if the prediction result indicates a stable resource trend, the database performance reporting system can maintain the current low data collection frequency. If the prediction result indicates an increasing resource trend, the database performance reporting system can increase the data collection frequency to a high frequency. If the prediction result indicates a decreasing resource trend, the database performance reporting system can gradually reduce the data collection frequency back to its initial state.

[0083] By employing the methods described above, and using time series forecasting models to predict future resource trends based on historical resource consumption data, prediction results can be obtained, providing a basis for subsequent adjustments to the data collection frequency. Adjusting the data collection frequency according to these prediction results improves the foresight and accuracy of resource management.

[0084] In some embodiments, the database performance reporting system can periodically detect subsequent system resource indicators. When the subsequent system resource indicators are detected to meet the preset database health status for multiple consecutive periods, the original operating parameters before the dynamic adjustment strategy was implemented are restored.

[0085] Optionally, the database performance reporting system can set health threshold ranges for each indicator based on historical stable database resource indicator data, and store the thresholds in the system configuration library. It can also configure differentiated thresholds for different time periods based on peak business characteristics.

[0086] Subsequent periodic monitoring of system resource indicators

[0087] Optionally, the database performance reporting system can be configured with a detection cycle that matches the adjusted collection frequency. Based on the status determination module, it periodically acquires the subsequent system resource indicators reported by the collection module and compares each indicator to see if it is within the preset health threshold range.

[0088] Optionally, the database performance reporting system can use this status determination module to count the number of consecutive compliance testing periods. If an indicator exceeds the health threshold in a certain period, the consecutive compliance count is reset. If the number of consecutive periods reaches a preset threshold, it is determined that the system has returned to a stable operating state. The database performance reporting system can read pre-stored original operating parameters from the configuration library, overwrite the current adjusted parameters, and restore parameters such as collection frequency and reporting interval. It also records the parameter restoration time and comparisons of parameters before and after restoration.

[0089] By using the above method, subsequent system resource indicators are periodically detected. When the subsequent system resource indicators meet the preset database health status for multiple consecutive cycles, the original operating parameters before the dynamic adjustment strategy is implemented are restored, thereby achieving dynamic balance in resource management and improving resource utilization.

[0090] S102, determine whether the system resource indicators meet the preset database health status.

[0091] Optionally, the database performance reporting system can set threshold ranges for each dimension of system resource indicators. For example, the healthy threshold range for storage space utilization can be [0, 75%], the warning threshold is (75%, 85%), and the critical threshold is greater than 85%; the healthy threshold for hourly memory consumption growth rate is less than or equal to 5%, and the abnormal threshold is greater than 5%; the healthy threshold for input / output latency is less than or equal to 50ms, and the abnormal threshold is greater than 50ms; the healthy threshold for snapshot table size has a daily growth rate of less than or equal to 10%, and the abnormal threshold has a daily growth rate of greater than 10%.

[0092] Optionally, the database performance reporting system can compare system resource indicator values ​​with corresponding threshold ranges and output the health status, warning status, or critical status of a single system resource indicator. If any system resource indicator triggers a critical threshold, the database performance reporting system determines that the database is in an unhealthy state.

[0093] Optionally, the database performance reporting system can configure differentiated thresholds based on business load scenarios and database deployment architecture. For example, during data synchronization periods between distributed database nodes, the input / output latency health threshold can be adjusted to less than 80ms. Correlation judgment rules can also be set based on the relationships between system resource metrics. For example, if storage space utilization is ≤75%, input / output latency is ≤50ms, and hourly memory consumption growth rate is ≤5%, the database is considered to be in a healthy state.

[0094] Optionally, the database performance reporting system can assign weight coefficients to various system resource indicators based on their priority in impacting database health. Based on the system resource indicator values ​​and weight coefficients, a comprehensive health score is calculated, and the final judgment result is output according to the comprehensive health score. For example, if the comprehensive health score is ≥0.8, the database is determined to be in a healthy state; if the comprehensive health score is greater than 0.6 but less than 0.8, the database is determined to be in a warning state; if the comprehensive health score is less than or equal to 0.6, the database is determined to be in a critical state.

[0095] S103, if the system resource indicators do not meet the preset database health status, a dynamic adjustment strategy is triggered. The dynamic adjustment strategy includes at least one of the following: reducing the data collection frequency, reducing the number of system resource indicators, and cleaning up historical snapshot data.

[0096] As one possible implementation, the system resource indicators that do not meet the preset database health status include at least one of the following: the storage space utilization rate exceeds the utilization rate threshold; the memory consumption growth rate exceeds the growth rate threshold; the input / output latency exceeds the latency threshold; and the snapshot table size exceeds the size threshold.

[0097] Optionally, if the database is in an unhealthy state, the database performance reporting system can encapsulate the name of the abnormal indicator, the difference between the actual value and the threshold, the current business scenario, and the weight configuration into a trigger signal. This trigger signal can then be input to the dynamic adjustment module via a message queue. The dynamic adjustment module can then parse this trigger signal and retrieve a preset adjustment strategy.

[0098] As one possible implementation, the database performance reporting system can reduce the number of snapshots generated and decrease the data collection frequency by adjusting the snapshot generation interval parameter. It can also reduce the number of system resource metrics by modifying database configuration parameters to disable the collection of non-core statistics. Furthermore, the system can clean up historical snapshot data by performing cleanup tasks to delete snapshot records that have exceeded their retention period.

[0099] For example, if storage space utilization exceeds a utilization threshold, the database performance reporting system can reduce the number of snapshot data generations and decrease the data collection frequency by adjusting the snapshot generation interval parameter. If memory consumption growth rate exceeds a growth rate threshold, or if input / output latency exceeds a latency threshold, the database performance reporting system can reduce the number of system resource metrics by modifying database configuration parameters to disable the collection of non-core statistics. If the snapshot table size exceeds a size threshold, the database performance reporting system can clean up historical snapshot data by executing a cleanup task to delete snapshot records that have exceeded their retention period.

[0100] By adjusting the snapshot generation interval parameter to reduce the number of snapshot data generations, the data collection frequency can be reduced. By modifying the database configuration parameters to disable the collection of non-core statistical items, the number of system resource indicators can be reduced. By executing cleanup tasks to delete snapshot records that have exceeded the retention period, historical snapshot data can be cleaned up, improving resource management efficiency, thereby improving resource utilization and database stability.

[0101] As one possible implementation, the database performance reporting system can, during the process of determining whether the system resource indicators meet the preset database health status, if any system resource indicator does not meet the preset database health status, stop judging the unjudged indicators among the system resource indicators and determine that the system resource indicators do not meet the preset database health status.

[0102] Optionally, the database performance reporting system can preset a fixed judgment order based on the severity of the impact of each system resource indicator on database health, and perform indicator judgments sequentially according to this fixed order. For example, the judgment order could be: memory consumption growth rate, input / output latency, storage space utilization, and snapshot table size.

[0103] Optionally, the database performance reporting system can also adjust the judgment order in real time based on the current business scenario and dynamic weight configuration results. For example, in a high-concurrency write scenario, the input / output latency judgment order is elevated to first place; in a data backup scenario, the snapshot table size judgment order is elevated to second place.

[0104] Optionally, the database performance reporting system can extract the actual values ​​of individual system resource indicators sequentially according to a preset judgment order and compare them with the corresponding preset health thresholds. After each system resource indicator is verified, it immediately determines whether the termination trigger condition is met. If the current system resource indicator meets the health status, the database performance reporting system can continue to execute the judgment process for the next indicator; if the current system resource indicator does not meet the health status, the database performance reporting system can trigger an interrupt command to stop the extraction and verification operations of all unjudged system resource indicators and freeze the judgment process.

[0105] Optionally, the database performance reporting system can generate a conclusion that "system resource indicators do not meet the preset database health status" based on the triggered interruption event, and simultaneously record the name of the non-compliant indicator, the actual value, the threshold range, and a list of indicators that were not judged at the time of termination.

[0106] Optionally, the database performance reporting system can execute preset processing solutions based on results indicating that the health status is not met. For example, based on results indicating that the health status is not met, the database performance reporting system can increase the data collection frequency, push operation and maintenance alarm information, or initiate resource expansion, etc.

[0107] By using the above method, in the process of determining whether the system resource indicators meet the preset database health status, if any system resource indicator does not meet the preset database health status, the determination of the undetermined indicators in the system resource indicators will be stopped, and it will be determined that the system resource indicator does not meet the preset database health status, thereby shortening the response cycle and improving database stability and resource utilization.

[0108] In this embodiment, system resource indicators are collected according to the data acquisition frequency. These system resource indicators include at least one of the following: storage space utilization rate, memory consumption growth rate, input / output latency, and snapshot table size, laying the foundation for subsequent assessment of database health status. The system resource indicators are then assessed to determine if they meet a preset database health status. If the system resource indicators do not meet the preset database health status, a dynamic adjustment strategy can be triggered. This dynamic adjustment strategy includes at least one of the following: reducing the data acquisition frequency, reducing the number of system resource indicators, and clearing historical snapshot data, thereby reducing response latency and improving database stability and resource utilization.

[0109] Figure 2 This application provides a flowchart illustrating a control method based on a Health Check Agent. Figure 2 As shown, the method includes:

[0110] This method is embedded in the database performance reporting system. It performs periodic detection, determines thresholds, and then issues intelligent alerts. After the intelligent alerts are issued, dynamic degradation is implemented.

[0111] Figure 3 This is a flowchart illustrating a periodic health check method for a database provided in this application. Figure 3 As shown, the method includes:

[0112] Step 1: Start the "Health Check Scheduler" process. This scheduler is a timed trigger that executes once every T minutes.

[0113] Step Two: Indicator Collection and Evaluation: Access the "Health Indicator Collection and Evaluation Tool" and perform two operations:

[0114] (1) Collect core metrics: including storage space utilization, memory consumption growth rate, average response time of input / output interfaces, and snapshot table size / number of rows;

[0115] (2) Compare with the threshold configuration table to evaluate whether the indicators meet the preset normal standards.

[0116] Step 3: Status Branch Judgment: Determine whether all indicators are normal;

[0117] If the indicator is abnormal, proceed to step four; if the indicator is normal, proceed to step five.

[0118] Step 4: Enter the "Dynamic Adjustment Actuator" and perform two types of operations:

[0119] (1) Trigger alarm: Complete logging and send notification;

[0120] (2) Implement dynamic degradation strategies: including reducing sampling frequency, reducing statistical granularity, and cleaning up historical snapshots.

[0121] Step 5: Enter "Waiting for the next inspection cycle (XX minutes later)" to wait for the next timed scheduling to be triggered.

[0122] Optionally, the health check scheduler can be responsible for triggering a health check task once based on a configurable period (such as every 5 minutes).

[0123] Optionally, the health indicator collector and evaluator can collect key system and self-indicators during each inspection task and compare them with preset thresholds.

[0124] Optionally, the dynamic adjustment actuator can first trigger an alarm when any one or more indicators exceed the threshold, and then automatically execute a predefined degradation strategy to adjust the data collection behavior.

[0125] Optionally, the database performance reporting system can automatically and proactively collect key indicators reflecting its own health and impact on the database system at fixed, configurable time intervals, providing a data foundation for subsequent evaluations.

[0126] Optionally, the database performance reporting system can perform periodic checks, including the following:

[0127] (1) Trigger source: Implemented by an independent health check scheduler embedded in the system. This scheduler can be a background daemon, a scheduled task, or a task managed by the database's built-in job scheduler.

[0128] (2) Execution cycle: The check cycle T can be defined in the configuration table (e.g., 5 minutes by default). The scheduler wakes up once every time T to trigger a health check job.

[0129] (3) Metrics Collection: After the check job is triggered, the health metric collector starts working by executing a series of predefined diagnostic commands and SQL statements. For example, the database performance reporting system can collect tablespace utilization from storage space; it can also collect memory pool growth based on memory consumption; it can also collect average database input / output latency based on input / output interface overhead; and it can also collect the number of rows or size of the master snapshot table based on internal system information.

[0130] (4) Database system view: query tablespace name, status, size, etc.

[0131] (5) Operating system tools: Outside the database, a broader view of system resources can be obtained by calling system commands.

[0132] (6) Internal counter: Reads internal state variables such as the number of snapshots and memory usage.

[0133] Figure 4 This is a flowchart illustrating a database health check threshold determination method provided in this application. Figure 4 As shown, the method includes:

[0134] Starting with "starting threshold judgment", threshold checks for four indicators are performed sequentially:

[0135] The first item: Determine whether the storage space utilization rate exceeds the threshold;

[0136] Second item: If the result of the first item is "no", continue to determine "whether the memory consumption growth rate exceeds the threshold";

[0137] Third item: If the result of the second item is "no", continue to determine whether the "average input / output response time exceeds the threshold";

[0138] Fourth item: If the result of the third item is "no", continue to determine whether the "snapshot table size exceeds the threshold".

[0139] If the judgment result of any of the above indicators is "yes", then the status will be marked as "abnormal".

[0140] If all four indicators result in "No", then the status will be marked as "Healthy".

[0141] Using the above method, the real-time indicator data collected in the first step is compared with preset, scientific thresholds to intelligently determine whether the current system is healthy and whether there is a risk of "statistical inflation" or "performance overload".

[0142] Optionally, the threshold configuration can store all thresholds in a configuration table, allowing administrators to optimize them according to specific environments and business tolerances.

[0143] Optionally, the evaluation engine can be a health metric evaluator that receives the collected metrics and logically compares each one with the thresholds in the configuration table. If a metric exceeds the threshold, it is marked as "abnormal".

[0144] Optionally, the decision-making logic could employ a "veto mechanism," where if any core indicator exceeds a threshold, the overall health status is deemed "abnormal," requiring immediate intervention. This design is conservative and safe, ensuring that any potential risks are detected.

[0145] Optionally, when the system is determined to be "abnormal", the database administrator should be notified immediately in a clear and traceable manner, and detailed contextual information should be provided to facilitate quick identification of the root cause of the problem.

[0146] Optionally, alarm triggering can be handled by the alarm module in the dynamically adjusted actuator. An alarm is triggered immediately upon receiving an "abnormal" status signal from the evaluator.

[0147] Optionally, the alarm content can be a detailed report containing structured data. For example, the alarm content may include the abnormal time, abnormal metric, current value, threshold, and suggested actions. Suggested actions could include, for example, "The system has automatically triggered a degradation strategy; please pay attention."

[0148] Optionally, alarm channels can include primary and secondary channels. The primary channel (internal log) writes alarm information to the database's alarm log file or a dedicated KWR health check log. This is the most reliable and essential channel. The secondary channel (external notification) can integrate external interfaces to send alarm information to the administrator via application software or other means.

[0149] Optionally, upon receiving an alert, a predefined "degradation" strategy can be automatically and rapidly executed to proactively reduce system resource consumption, curbing "statistical bloat" and performance degradation at the source, and ensuring the stability of the database's main business. The degradation strategy is not simply shutting down the system, but rather implementing fine-grained resource control while ensuring minimum monitoring capabilities.

[0150] Optionally, the degradation strategy execution can be handled by the degradation module in the dynamic adjustment executor. Core degradation methods can include reducing the sampling frequency, reducing statistical granularity, and proactively cleaning up historical data. Reducing the sampling frequency can be achieved by adjusting the interval for automatically creating performance snapshots from a high frequency (e.g., 5 minutes) to a low frequency (e.g., 30 minutes or 1 hour). This directly reduces the frequency of data collection and storage. Reducing statistical granularity can be achieved by dynamically adjusting the database's statistical information collection level and disabling some non-core, high-cost statistical items. Proactively cleaning up historical data can be achieved by automatically initiating a safe data cleanup task, for example, retaining only the snapshot data from the most recent 24 hours, automatically archiving or deleting earlier data, and immediately freeing up storage space.

[0151] Optionally, degradation can be temporary. The database performance reporting system continues to perform periodic checks during degradation. When the health check results for N consecutive cycles (e.g., 3 cycles) all return to "healthy," it automatically reverts to the normal monitoring configuration, i.e., the previous degradation strategy is revoked. This forms a complete, self-healing closed-loop control system.

[0152] Figure 5 A flowchart illustrating another database health check method provided in this application. Figure 5 As shown, the method includes:

[0153] Step 1: Start the health check scheduler

[0154] When the database performance reporting system is enabled, the health check scheduler starts simultaneously as a background daemon or scheduled task. Based on the time parameters in the configuration table, it periodically sends check signals to the "Health Indicator Collector and Evaluator".

[0155] Step Two: Health Indicator Collection and Assessment

[0156] Once the evaluator is triggered, it performs the following operations:

[0157] (1) Metrics collection: Collect current health metrics by querying database system views, operating system tools, or internal counters. Core metrics include: database space size (current_storage_usage), memory growth (current_mem_increase), input / output latency (current_io_latency), and snapshot table size (current_snapshot_size).

[0158] (2) Threshold evaluation: The collected real-time indicators are compared with the thresholds in the configuration table one by one. If the real-time indicator exceeds the threshold, it is marked as abnormal.

[0159] For example, the configuration item check interval (check_interval) can be the time interval between two health checks, such as 5 minutes. The configuration item storage usage threshold (storage_usage_threshold) can be the disk usage threshold of the tablespace where the relevant data (such as snapshot tables) resides, such as 85%. The configuration item memory increase threshold (mem_increase_threshold) can be the size growth rate threshold of the relevant memory pool (such as a statistical region in shared memory) within two check intervals, such as 10%.

[0160] For example, the configuration option `io_latency_threshold` can be the average physical input / output response time threshold for the database instance, such as 50 milliseconds. The configuration option `snapshot_table_size_threshold` can be the physical size threshold for core snapshot tables (such as `kwr_snapshots`), such as 1 gigabyte. The configuration option `degraded_sample_freq` can be the frequency at which the database performance reporting system automatically creates snapshots after a degradation is triggered, such as 30 minutes. The configuration option `degraded_stats_level` can be the adjusted statistics collection level after a degradation is triggered, such as collecting only critical items.

[0161] Step 3: Decision Making

[0162] If all collected metrics are below or equal to their corresponding thresholds, KWR is considered to be operating healthily, the check ends, and the system waits for the next cycle. If any metric exceeds its threshold, the process enters the "Dynamic Adjustment Actuator".

[0163] Step 4: Dynamically Adjust Execution

[0164] Once the actuator is activated, it performs the following two operations in sequence:

[0165] (1) Triggering an alarm:

[0166] Record a warning-level message in the database alarm log or dedicated health check log, including: the triggered metric, current value, threshold, timestamp, etc. You can also notify the database administrator via external interfaces such as email and SMS.

[0167] (2) Implement dynamic degradation strategies: Automatically execute a series of predefined degradation operations to alleviate system load. These operations are temporary and designed to help systems weather periods of resource scarcity. Specific strategies include:

[0168] Reduce snapshot sampling frequency: Modify the time interval for automatically creating snapshots. For example, change the automatic snapshot creation interval from the default 60 minutes to 30 minutes.

[0169] Reduce the granularity of statistical information: Lower the level of statistical information collection by modifying database parameters or calling internal procedures.

[0170] Automatically clean up historical snapshots: Start a cleanup task that only keeps the most recent N snapshots (e.g., 24), deletes earlier historical snapshots, and directly frees up storage space.

[0171] Optionally, after the system undergoes dynamic adjustment and resource pressure is alleviated, in subsequent health checks, if all indicators return to within the normal threshold for M consecutive cycles (e.g., 3 cycles), the dynamic adjustment actuator can automatically restore the previous configuration, that is, adjust the sampling frequency and statistical granularity back to normal values, restoring comprehensive monitoring capabilities. This recovery mechanism can be designed into the system to provide complete closed-loop control.

[0172] The above are the method embodiments provided in this application. The apparatus provided in this application will be described below.

[0173] Figure 6 This application provides a schematic diagram of the structure of a database health check device, as shown below. Figure 6 As shown, the database health check device 600 provided in this embodiment includes: a data acquisition module 601, a judgment module 602, and a triggering module 603. Among them,

[0174] The acquisition module 601 is used to acquire system resource indicators according to the data acquisition frequency. The system resource indicators include at least one of the following: storage space utilization rate, memory consumption growth rate, input / output latency, and snapshot table size.

[0175] The judgment module 602 is used to determine whether the system resource indicators meet the preset database health status.

[0176] Trigger module 603 is used to trigger a dynamic adjustment strategy when the system resource indicators do not meet the preset database health status. The dynamic adjustment strategy includes at least one of the following: reducing the data collection frequency, reducing the number of system resource indicators, and cleaning up historical snapshot data.

[0177] Optionally, the acquisition module 601 is further configured to: calculate the storage space utilization rate based on the actual storage space utilization rate and a first dynamic weight; calculate the memory consumption growth rate based on the actual memory consumption growth rate and a second dynamic weight; calculate the input / output latency based on the actual input / output latency and a third dynamic weight; and calculate the snapshot table size based on the actual snapshot table size and a fourth dynamic weight.

[0178] The first dynamic weight, the second dynamic weight, the third dynamic weight, and the fourth dynamic weight are all dynamically adjusted according to the current business scenario.

[0179] Optionally, the acquisition module 601 is also used to periodically detect subsequent system resource indicators. When the subsequent system resource indicators are detected to meet the preset database health status for multiple consecutive periods, the original operating parameters before the dynamic adjustment strategy was implemented are restored.

[0180] Optionally, the acquisition module 601 is also used to predict future resource trends based on historical resource consumption data using a time series prediction model, and obtain prediction results; and adjust the data acquisition frequency according to the prediction results.

[0181] Optionally, the trigger module 603 is further configured to determine if the system resource indicators do not meet the preset database health status, including at least one of the following:

[0182] The storage space usage exceeds the usage threshold;

[0183] The memory consumption growth rate exceeds the growth rate threshold;

[0184] The input / output delay exceeds the delay threshold;

[0185] The size of the snapshot table exceeds the size threshold.

[0186] Optionally, the trigger module 603 is further configured to, during the process of determining whether the system resource indicators meet the preset database health status, if any system resource indicator does not meet the preset database health status, stop the determination of the undetermined indicators among the system resource indicators and determine that the system resource indicators do not meet the preset database health status.

[0187] Optionally, the trigger module 603 is also used to reduce the number of snapshot data generation times by adjusting the snapshot generation interval parameter; the reduction of the number of system resource indicators includes: disabling the collection of non-core statistical items by modifying database configuration parameters; the cleaning of historical snapshot data includes: deleting snapshot records that have exceeded the retention period by executing a cleaning task.

[0188] This embodiment provides a database health check device that can execute the methods provided in any of the above method embodiments. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0189] Figure 7 This is a schematic diagram of the structure of an electronic device provided in this application. Figure 7 As shown, the electronic device 700 provided in this embodiment includes at least one processor 701 and a memory 702. Optionally, the device 700 further includes a communication component 703. The processor 701, memory 702, and communication component 703 are connected via a bus 704.

[0190] In a specific implementation, at least one processor 701 executes computer execution instructions stored in memory 702, causing at least one processor 701 to perform the above-described method.

[0191] The specific implementation process of processor 701 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0192] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0193] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0194] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0195] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0196] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0197] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0198] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0199] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0200] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0201] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0202] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0203] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0204] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0205] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A database health check method, characterized by, The method includes: System resource indicators are collected according to the data collection frequency. The system resource indicators include at least one of the following: storage space utilization rate, memory consumption growth rate, input / output latency, and snapshot table size. Determine whether the system resource indicators meet the preset database health status; If the system resource indicators do not meet the preset database health status, a dynamic adjustment strategy is triggered. The dynamic adjustment strategy includes at least one of the following: reducing the data collection frequency, reducing the number of system resource indicators, and clearing historical snapshot data.

2. The method according to claim 1, characterized in that, The system resource indicators failing to meet the preset database health status include at least one of the following: The storage space utilization rate exceeds the utilization rate threshold; The memory consumption growth rate exceeds the growth rate threshold; The input / output delay exceeds the delay threshold; The size of the snapshot table exceeds the size threshold.

3. The method according to claim 2, characterized in that, The storage space utilization rate is calculated based on the actual storage space utilization rate and the first dynamic weight; the memory consumption growth rate is calculated based on the actual memory consumption growth rate and the second dynamic weight. The input / output latency is calculated based on the actual input / output latency and the third dynamic weight; the snapshot table size is calculated based on the actual snapshot table size and the fourth dynamic weight. The first dynamic weight, the second dynamic weight, the third dynamic weight, and the fourth dynamic weight are all dynamically adjusted according to the current business scenario.

4. The method according to claim 2 or 3, characterized in that, In the process of determining whether the system resource indicators meet the preset database health status, if any system resource indicator does not meet the preset database health status, the determination of the undetermined indicators among the system resource indicators is stopped, and it is determined that the system resource indicator does not meet the preset database health status.

5. The method according to any one of claims 1-3, characterized in that, The reduction of the data acquisition frequency includes: reducing the number of times snapshot data is generated by adjusting the snapshot generation interval parameter; The reduction of the number of system resource indicators includes: disabling the collection of non-core statistical items by modifying database configuration parameters; The cleanup of historical snapshot data includes: deleting snapshot records that have exceeded the retention period by performing a cleanup task.

6. The method according to any one of claims 1-3, characterized in that, The method further includes: The system periodically checks subsequent system resource indicators. When the subsequent system resource indicators all meet the preset database health status for multiple consecutive periods, the original operating parameters before the dynamic adjustment strategy was implemented are restored.

7. The method according to any one of claims 1-3, characterized in that, The method further includes: Based on historical resource consumption data, a time series forecasting model is used to predict future resource trends and obtain the forecast results. The data collection frequency is adjusted based on the prediction results.

8. A database health check device, characterized in that, include: The data acquisition module is used to collect system resource indicators according to the data acquisition frequency. The system resource indicators include at least one of the following: storage space utilization rate, memory consumption growth rate, input / output latency, and snapshot table size. The judgment module is used to determine whether the system resource indicators meet the preset database health status. The triggering module is used to trigger a dynamic adjustment strategy when the system resource indicators do not meet the preset database health status. The dynamic adjustment strategy includes at least one of the following: reducing the data collection frequency, reducing the number of system resource indicators, and clearing historical snapshot data.

9. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 7.

11. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 7.

Images