WO2019001085A1 - 数据库性能监测方法、装置、计算机设备和存储介质 - Google Patents

数据库性能监测方法、装置、计算机设备和存储介质 Download PDF

Info

Publication number
WO2019001085A1
WO2019001085A1 PCT/CN2018/082529 CN2018082529W WO2019001085A1 WO 2019001085 A1 WO2019001085 A1 WO 2019001085A1 CN 2018082529 W CN2018082529 W CN 2018082529W WO 2019001085 A1 WO2019001085 A1 WO 2019001085A1
Authority
WO
WIPO (PCT)
Prior art keywords
monitoring
type
factor
space
size
Prior art date
Application number
PCT/CN2018/082529
Other languages
English (en)
French (fr)
Inventor
祁明远
徐海涛
王伟
Original Assignee
平安科技（深圳）有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 平安科技（深圳）有限公司 filed Critical 平安科技（深圳）有限公司
Publication of WO2019001085A1 publication Critical patent/WO2019001085A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/302—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system

Definitions

  • the application relates to a database performance monitoring method, device, storage medium and computer device.
  • each monitoring scheme has different monitoring indicators and corresponding algorithms.
  • the traditional database performance monitoring methods are for a specific database application, and the corresponding one or several common indicators of the application are monitored.
  • this method caused the performance monitoring of the database to be insufficiently comprehensive. When the database had performance fluctuations, it could not be discovered and processed in time and accurately.
  • a database performance monitoring method, apparatus, storage medium, and computer device are provided.
  • a database performance monitoring method includes: monitoring a number of factors of a first type of monitoring factor; monitoring a duration of a second type of monitoring factor; monitoring a spatial size of the third type of monitoring factor; and according to the number of factors, the duration, and the The size of the space determines the running state of the database; the running state includes a normal running state and an abnormal running state, and compares the number of factors, the duration or the space size corresponding to each monitoring factor, and the corresponding set threshold, when at least one exceeds the corresponding When the threshold is monitored, the database is determined to be in an abnormal running state; the first type of monitoring factor refers to a monitoring factor that reflects the running performance of the database according to the factor of the monitoring factor; the operating state includes normal The operating state and the abnormal running state; the second type of monitoring factor refers to a monitoring factor of a type that can reflect the running performance of the database according to the duration of the monitoring factor; and the third type of monitoring factor refers to the size of the monitoring factor A monitoring factor that reflects the type of performance of the database
  • a database performance monitoring device includes: a first type of monitoring module for monitoring a factor of a first type of monitoring factor; a second type of monitoring module for monitoring a duration of a second type of monitoring factor; and a third type of monitoring module, a space size for monitoring a third type of monitoring factor; a database performance determining module, configured to determine a running state of the database according to the number of factors, the duration, and the size of the space, and the number of factors and duration of each monitoring factor Or the size of the space, compared with the corresponding set threshold, when there is at least one monitoring factor exceeding the corresponding threshold, determining that the database is in an abnormal running state; the first type of monitoring factor refers to the number of factors according to the monitoring factor, a monitoring factor reflecting a type of running performance of the database; the operating state includes a normal running state and an abnormal running state; and the second type of monitoring factor refers to a type that can reflect a running performance of the database according to a duration of the monitoring factor.
  • a computer apparatus comprising a memory and one or more processors having stored therein computer readable instructions that, when executed by a processor, implement the steps of a database performance monitoring method provided in any one of the embodiments of the present application.
  • One or more non-volatile storage media storing computer readable instructions, when executed by one or more processors, cause one or more processors to implement a database provided in any one of the embodiments herein The steps of the performance monitoring method.
  • FIG. 1A is an application scenario diagram of a database performance monitoring method according to one or more embodiments
  • 1B is a flowchart of a database performance monitoring method in one or more embodiments
  • FIG. 2 is a flow chart showing the number of factors monitoring a first type of monitoring factor in one or more embodiments
  • 3 is a flow chart showing the duration of monitoring a second type of monitoring factor in one or more embodiments
  • FIG. 4 is a flow diagram of monitoring the spatial size of a third type of monitoring factor in one or more embodiments
  • Figure 5 is a block diagram of a database performance monitoring device in one or more embodiments
  • FIG. 6 is a block diagram of a database performance monitoring apparatus in another embodiment
  • Figure 7 is a block diagram of a database performance monitoring apparatus in still another embodiment
  • Figure 8 is a block diagram of a server in one or more embodiments.
  • the database performance monitoring method provided by the present application can be applied to an application environment as shown in FIG. 1A.
  • the administrator terminal 102 communicates with the server 104 over a network.
  • the server determines the running state of the database according to the number of factors, the duration, and the size of the space by monitoring the number of factors of the first type of monitoring factors, monitoring the duration of the second type of monitoring factors, and monitoring the spatial size of the third type of monitoring factors.
  • the abnormality level of the database is determined according to the number of factors, the length of time, and the size of the space, and the alarm information is sent to the administrator terminal according to the alarm mode corresponding to the abnormal level.
  • the administrator terminal 102 can be, but is not limited to, various personal computers, notebook computers, smart phones, tablet computers, and portable wearable devices, and the server 104 can be implemented with a stand-alone server or a server cluster composed of a plurality of servers.
  • a database performance monitoring method is provided, the method comprising:
  • Step S102 monitoring the number of factors of the first type of monitoring factor.
  • the monitoring factor refers to a factor that has an effect on the operational performance of the database. Such as the current process of the database, distributed transactions, session control, and rollback segment space.
  • the eigenvalue corresponding to the monitoring factor exceeds or is less than a certain trigger threshold, it may have a large impact on the running performance of the database, such as severely reducing the data processing capability of the database, and even causing downtime.
  • the corresponding feature values are not necessarily the same for different monitoring factors.
  • the feature value can be a factor number, a duration, a space size, and the like.
  • the trigger threshold corresponds to the eigenvalue and can be a specific eigenvalue. For example, it can be a specific number threshold, a duration threshold, a space threshold, and the like.
  • the server may monitor the monitoring factor that affects the running performance of the database according to a preset frequency, obtain the characteristic value of the corresponding monitoring factor, and compare the characteristic value with the corresponding trigger threshold to determine the running state of the database.
  • the running state of the database includes the normal running state and the abnormal running state. When an abnormal running state occurs, the data processing performance of the database is greatly reduced, and in severe cases, the system is down.
  • the first type of monitoring factor refers to a monitoring factor that reflects the type of performance of the database according to the number of factors of the monitoring factor. Specifically, it refers to a type of monitoring factor that has a certain influence on the running performance of the database when the number of factors of the monitoring factor exceeds or is less than a certain number.
  • the first type of monitoring factor can be a redo log file, a structured query language record submitted per data manipulation language, a current process, an exception wait event, a hierarchy of Btree indexes, a cursor opened or parsed in each session control, etc. Any one or combination of several monitoring factors.
  • the server may set a corresponding number threshold for each first type of monitoring factor, and compare the size between each first type of monitoring factor and a corresponding number threshold thereof, and determine according to the size.
  • the running state of the database The quantity threshold is used to reflect whether the number of factors of the corresponding first type of monitoring factor will cause a critical value of the database to operate abnormally.
  • the quantity threshold may be set according to the performance or parameters of the corresponding database, and the number thresholds of the first type of monitoring factors may be the same or different.
  • Step S104 monitoring the duration of the second type of monitoring factor.
  • the second type of monitoring factor refers to a monitoring factor that reflects the type of running performance of the database according to the duration of the monitoring factor (such as the length of time that the waiting time is waited for, etc.).
  • the second type of monitoring factor can be any combination of one or several monitoring factors such as distributed transaction or session control.
  • the server may set a corresponding duration threshold for each second type of monitoring factor, and compare the size between each second type of monitoring factor and a corresponding duration threshold, and determine according to the size.
  • the running state of the database The duration threshold is used to reflect whether the duration of the corresponding second type of monitoring factor causes a critical value of the database to operate abnormally.
  • the duration threshold may be set according to the performance or parameters of the corresponding database, and the duration thresholds corresponding to the second type of monitoring factors may be the same or different.
  • Step S106 monitoring the spatial size of the third type of monitoring factor.
  • the third type of monitoring factor refers to a monitoring factor that reflects the type of running performance of the database according to the size of the monitoring factor (such as the size of the occupied space in the database).
  • the third type of monitoring factor may be a combination of any one or several monitoring factors such as a rollback segment space, a session control in a temporary table space, and a self-growth sequence.
  • the server may set a corresponding spatial threshold for each of the third type of monitoring factors, and compare the size between each of the third type of monitoring factors and the corresponding spatial threshold, and determine according to the size.
  • the space threshold is used to reflect whether the duration of the corresponding third type of monitoring factor causes a critical value of the database to operate abnormally.
  • the duration threshold may be set according to performance or parameters of the corresponding database, and the spatial thresholds corresponding to the third type of monitoring factors may be the same or different.
  • Step S108 determining the running state of the database according to the number of factors, the duration, and the size of the space.
  • the server may determine whether the database is in an abnormal running state by combining the first type of factor number of the monitored sub-number, the duration of the second type of monitoring factor, and the space size of the third type of monitoring factor. . Specifically, the number of factors, the duration, or the space corresponding to the monitoring factor of each category detected in real time may be compared with a corresponding threshold, and when there is at least one monitoring factor exceeding the threshold, the The database is in an abnormal state. And acquiring information of a monitoring factor that causes the running state, and generating alarm information that carries the information of the monitoring factor.
  • an alarm information that the number of unavailable redo log files is excessive may be generated, and the alarm information may be sent to the corresponding management.
  • the terminal allows the administrator to adjust the database accordingly.
  • the above database performance monitoring method can be applied to various databases, such as an Oracle database, a Mysql database, a DB2 database, and a Sybase database.
  • the above database performance monitoring method by monitoring the state of the three types of monitoring factors, determining the running state of the database according to the factor of the first type of monitoring factor, the duration of the second type of monitoring factor, and the spatial size of the third type of monitoring factor. This makes it possible to comprehensively monitor the performance monitoring of the database, improving the timeliness and accuracy of the discovery of the abnormal operating state of the database.
  • the first type of monitoring factor includes unavailable redo log files, structured query language records submitted per data manipulation language, current process, exception wait events, Btree index hierarchy, and each session control A cursor that is opened or parsed.
  • step S102 includes:
  • Step S202 monitoring the number of unavailable redo log files.
  • the redo log file (ie, the Redo Log, also referred to as the redo log group) contains all the database change history, and all operation changes of the database are preceded by the write redo log buffer before the data block buffer.
  • the redo log file is written before the data file is written; when the commit action occurs, the redo log buffer change is flushed to the redo log file.
  • Redo-Log includes Online Redo Log and Archive Redo Log.
  • the status of the Redo-Log includes the Current state, the Active state, and the Inactive state.
  • the Current state indicates the Redo Log that the current database is using.
  • the Active state indicates that it is in use or occupied. However, the content in the RedoLog has not been archived, or the data in the file is not all written to the data file. Once the instance recovery is required, the contents of the file must be used.
  • the Inactive state indicates that the content in the Redo Log has been archived and the group is idle.
  • the available redo log files are Redo Logs in the Inactive state; the unavailable redo log files are Redo Logs in the Active state.
  • the number of Redo Logs in the Inactive state can be monitored in real time, and when it is less than a certain number, it may cause a Redo Wait wait event.
  • the server may set a corresponding quantity threshold for the redo log files that are not available, and generate an alarm information when the number of unavailable redo log files is greater than the quantity threshold.
  • the number threshold may be determined according to the total number of redo log files, such as a certain percentage of the total. For example, the number threshold may be set to 75% of the total number of redo log files, and when the number of available redo log files is greater than 75% of the total, an alarm message is generated.
  • Step S204 monitoring the number of structured query language records submitted by each data manipulation language.
  • the Data Manipulation Language includes Select, Update, Insert, and Delete statements, and each statement includes multiple SQLs.
  • the server can monitor the number of SQL records submitted per data manipulation language in real time. The greater the number, the slower the processing of database transactions and the excessive use of Redo space.
  • the number of SQL records that the server can submit for the data manipulation language is also set with a corresponding number threshold.
  • the quantity exceeds the corresponding quantity threshold it may be determined that the database is in an abnormal running state, and corresponding alarm information is generated.
  • a corresponding different number threshold may be set for different time periods, and the number of entries submitted in the DML is compared with the number of time periods in which the time period is located. For example, for a time period of 8:00-21:00, the corresponding number threshold is set to 1000; for 21:00 to 24:00, 0:00 to 8:00, the corresponding quantity threshold is set. It is 10,000.
  • the database can be set to a smaller number threshold during the peak period of data processing to prevent excessive space occupation and other data processing effects; and a larger number in the data processing trough period. Thresholds to improve performance for this data processing.
  • Step S206 monitoring the usage of the current process.
  • the server can also monitor the current process (Process) in real time according to a preset monitoring frequency, which is the usage of the Process.
  • a preset monitoring frequency which is the usage of the Process.
  • a corresponding number threshold may be set based on the maximum number of processes set by the database.
  • the maximum value can be set as a quantity threshold, or the quantity threshold can be set to a certain percentage of the maximum value, such as 95% of the maximum value, and the like. Therefore, when the usage amount reaches the quantity threshold, it is determined that the database is in an abnormal running state, and corresponding alarm information is generated.
  • Step S208 monitoring the number of abnormal waiting events.
  • the abnormal waiting event refers to one or several types of events in which the waiting time of the event waiting for processing exceeds the corresponding preset duration.
  • the types of database exception waiting events include Latch Free, Enqueue, DB File Scattered Read, DB File Sequential Read, Buffer Busy Waits and other wait type events.
  • the waiting time can be set to the same or different duration according to each type. For example, it can be uniformly set to 10 minutes. When the duration is exceeded, the corresponding event is determined to be an abnormal waiting event.
  • the server can count the number of exception waiting events in the waiting state at the current moment. When a large number of waiting events occur, the session cannot be ended, causing the JDBC (Java Data Base Connectivity) connection to be full, and the application cannot connect. database.
  • JDBC Java Data Base Connectivity
  • the lock wait exceeding the corresponding preset duration includes a database TM lock (table lock), a TX lock (transaction lock or row lock) waiting for a predetermined duration.
  • the preset duration that can be set for the TM lock (table lock) and TX lock wait can be any length, such as 10 minutes. Counts the number of TM locks (table locks) and TX locks that are currently in the wait state and exceed the corresponding preset duration.
  • a corresponding quantity threshold may be set for the quantity such that when the quantity is detected to reach the quantity threshold, it is determined that the database is in an abnormal operating state, and corresponding alarm information is generated.
  • Step S210 monitoring the number of levels of the level of the Btree index.
  • the Btree index is a common index structure in the database, and the smaller the number of levels (Blevel), the higher the efficiency of finding the index.
  • the server can monitor the size of the corresponding Blevel for each Btree index.
  • the threshold of the number of levels may be set.
  • the database is determined to be in an abnormal running state, and corresponding alarm information is generated.
  • the number of levels threshold can be set to three.
  • Step S212 monitoring the number of cursors opened or parsed in each session control.
  • the role of the cursor is to temporarily store the data blocks extracted from the database, including implicit Cursor, explicit Cursor, and dynamic Cursor.
  • a corresponding number threshold may be set for each of the Session open or parsed Cursors, such that when the number threshold is exceeded, it is determined that the database is in an abnormal running state, and corresponding alarm information is generated.
  • the number threshold may be determined according to the maximum value of the DB, such as 95% of the maximum value of the DB.
  • the cursor is opened or parsed in each session control by using a redo log file that is not available, a structured query language record submitted for each data manipulation language, a current process, an exception waiting event, a hierarchy of Btree indexes, and a session.
  • the first type of monitoring factor is monitored in quantity, so that the running status of the database is determined according to the quantity, and the comprehensiveness of database performance monitoring can be improved.
  • the second type of monitoring factor includes: distributed transactions and session control.
  • step S104 includes:
  • Step S302 monitoring the waiting time of the distributed transaction.
  • distributed things are usually processed automatically by the database and processed in a short period of time.
  • a corresponding waiting time threshold may be set, and the monitored waiting time is compared with the waiting time threshold, so that when the waiting time threshold is exceeded, the database is determined to be in an abnormal running state, and corresponding alarm information is generated.
  • the waiting time threshold may be set according to the performance of the database, and may be set to any suitable value, for example, may be set to 30 minutes.
  • the database can be monitored for more than 30 minutes of distributed transactions, and distributed locks only occur in databases with Dblink. If there is a connection interruption or a database site Crash during Commit or Rollback, the commit operation may not continue, causing the distributed transaction to be in a long wait state.
  • Step S304 monitoring the occupation duration of each session control.
  • the monitored session control includes a Session with a real-name user, a Session for which the OPR user connects to the DB, and a Session for the Mon user (Mon-User).
  • the real-name user may execute a session of a real-name user under the PAICDOM domain name (the real-name user only has the Select permission).
  • the time threshold of the duration of the session of the real-name user is set to 10 minutes, and the duration of the duration of the OSR user's session is 30 minutes.
  • step S302 and step S304 described above is not limited.
  • the monitoring of the performance of the database performance monitoring is improved by monitoring the duration of the second type of monitoring factors of the distributed transaction and the session control.
  • the third type of monitoring factor includes a rollback segment space, a session control in the temporary table space, and a self-growth sequence.
  • step S106 includes:
  • Step S402 monitoring the space size of the rollback segment space.
  • the size of the space indicates the occupied size of the rollback segment space in the table space.
  • the old data will be written in the UNDO tablespace.
  • the new data and rollback segment information will be written in the REDO tablespace.
  • the UNDO space contains multiple rollback segments. When there is too much data to be modified at one time, the more the rollback segment will be occupied, the longer it will take to do Commit or Rollback. Therefore, the size of the rollback segment space in the table space can be monitored.
  • a corresponding spatial threshold may be set such that when it is detected that the spatial size of the rollback segment space exceeds the spatial threshold, it is determined that the abnormal operating state is generated, and corresponding alarm information is generated.
  • the space threshold may be set according to the size of the table space, for example, may be set to 5% of the table space size.
  • Step S404 the monitoring session controls the size of the space in the temporary table space.
  • the temporary table space is used to store temporary objects such as temporary tables and intermediate sorting results. For example, some operations in the database: Select Distinct, Order By, Group By, Union All, etc. may use temporary table spaces.
  • the size of the space refers to the size of a Session in the temporary table space.
  • the corresponding spatial threshold may be set, so that when it is detected that the spatial size of a certain session exceeds the spatial threshold, it is determined that the abnormal operation state is generated, and corresponding alarm information is generated.
  • the space threshold may be set according to the size of the table space, for example, may be set to 5% of the table space size.
  • Step S406 monitoring the current spatial size of the self-growth sequence.
  • the self-growth sequence of the database generally grows automatically in steps and has a maximum setting. If the Sequence is set to Nocycle, the application cannot insert new data when the Sequence uses the maximum value. Therefore, the current space size of the Sequence can be monitored in real time.
  • the corresponding spatial threshold may also be set such that when it is detected that the spatial size of the sequence exceeds the spatial threshold, it is determined that the abnormal operating state is generated, and corresponding alarm information is generated.
  • the space threshold may be set according to a preset maximum value of the sequence, for example, may be set to 80% of the table space size.
  • the order of execution between the above steps S402, S404, and S406 is not limited.
  • the comprehensive performance of the database performance monitoring is further improved by setting the rollback segment space, the session control in the temporary table space, and the third type of monitoring factor of the self-growth sequence.
  • the method before step S108, further includes: monitoring a hit ratio of the lookup object in the shared pool; monitoring whether there is a structured query language statement that does not use the bind variable; and monitoring whether there is a failed object.
  • Step S108 includes: determining an operating state of the database according to a factor number, a duration, a space size, a hit ratio, a structured query language statement that does not use the bind variable, and the invalidated object.
  • the monitoring factor further includes a lookup object in the shared pool, a structured query language statement, and a failed object.
  • the corresponding trigger threshold may be a hit rate threshold, a structured query language statement with unused bind variables, and a presence invalid object.
  • the Shared Pool is the most important memory space in the SGA (System Global Area), mainly consisting of a library cache and a data dictionary cache.
  • the shared pool's memory space is dynamically distributed and is permuted according to the LRU algorithm (Least Recently Used). Therefore, the Shared Pool's Gets (Parse) and Pins (Execution) hit ratios are important indicators of its performance.
  • the hit rate in a preset period of time may be counted in real time, and a corresponding hit ratio threshold is set, and the hit ratio and the hit rate threshold are compared. If it is less than the hit rate threshold, it can be determined that it is in an abnormal running state, and corresponding alarm information is generated.
  • the hit rate threshold can be set to any suitable value according to the performance of the database, for example, can be set to 95%.
  • the root cause of object invalidation is that the dependency property between objects changes.
  • object A refers to the object B.EMAIL.
  • B object is executed by DDL to redefine the column "EMAIL”, then A refers to B. EMAIL will expire and need to be recompiled.
  • Dependencies between objects can be queried in DBA_DEPENDENCIES. Common invalid objects are View, Synonym, Procedure, Package, and so on.
  • the lookup object in the shared pool by further monitoring the hit ratio of the lookup object in the shared pool; monitoring whether there is a structured query language statement that does not use the bind variable; monitoring whether there is a invalid object, so that the above three types of monitoring factors can be combined and shared.
  • the lookup objects in the pool, the structured query language statements that do not use bind variables, and the invalidation objects are used to determine the running state of the database, which further improves the comprehensiveness of database running state monitoring.
  • the method further includes: when determining that the database is in an abnormal running state, determining an abnormal level of the database according to the number of factors, the length of time, and the size of the space; and according to the alarm mode corresponding to the abnormal level, to the preset administrator terminal. Send an alarm message.
  • the server may determine an abnormality level in an abnormal running state according to each of the above monitoring factors.
  • the abnormality level may include multiple, for example, may be divided into five levels according to the severity from light to heavy: Info, Warning, Minor, Major, and Serious ( Critical).
  • the alarm mode includes one or a combination of an email alarm, a short message alarm, and a telephone alarm.
  • an email alarm can be used for the abnormal running status of the Info, Warning, and Minor levels.
  • an email alert plus a telephone alert can be used.
  • the server can set a corresponding alarm notification object for each abnormal running state, and the administrator terminal corresponding to the alarm notification object sends the alarm information according to the preset alarm mode.
  • the alarm information includes detailed information of the monitoring factor that determines the abnormal operation and a corresponding solution, so that the alarm notification object can immediately process the database according to the alarm information.
  • the server can set the corresponding recipient or group in advance for the abnormal level of the corresponding level.
  • the email alarm will display the alarm title, alarm details and solution.
  • the telephone alarm can be preset with a corresponding call queue, and the call queue includes a corresponding alarm notification object, for example, 1-7 people can be set.
  • the alarm call is made according to the set telephone sequence, and the alarm notification object of the call is detected whether the telephone communication connection is successfully established. If so, then the next call is no longer called; otherwise, the second person to the last person is in order until one of the alarm notification objects successfully establishes a telephone communication connection. If the last person does not answer the alarm call, the loop re-circulates the call from the first person until someone picks up, ensuring that important alarms are notified to the system administrator in a timely manner.
  • the voice broadcast function can be called to automatically play the alarm information. For example, the corresponding generated alarm title and alarm time can be broadcasted to remind the alarm notification object to check the information of the abnormal operation of the mail in time.
  • a plurality of abnormal levels are set, and an abnormal level of the database is determined according to the number of factors, the length of time, and the size of the space; and the alarm information is sent to the preset administrator terminal according to the alarm mode corresponding to the abnormal level, so that the alarm notification is performed.
  • the object can receive the alarm information in a timely and effective manner, which improves the timeliness of the database that can be processed during abnormal operation.
  • steps in the flowchart of FIG. 1B-4 are sequentially displayed as indicated by the arrows, these steps are not necessarily performed in the order indicated by the arrows. Except as explicitly stated herein, the execution of these steps is not strictly limited, and the steps may be performed in other orders. Moreover, at least some of the steps in FIG. 1B-4 may include a plurality of sub-steps or stages, which are not necessarily performed at the same time, but may be performed at different times, these sub-steps or stages The order of execution is not necessarily performed sequentially, but may be performed alternately or alternately with at least a portion of other steps or sub-steps or stages of other steps.
  • a monitoring factor information table for the Oracle database is provided. It can monitor the 18 monitoring factors in the following table, and determine whether the characteristic value of each monitoring factor satisfies the corresponding trigger threshold, and determine the running state of the database according to the judgment result, and when it is determined that the abnormal operating state is further, The corresponding abnormality level, alarm mode, and alarm information are determined according to the monitoring factor and its characteristic value.
  • the specific trigger thresholds (such as duration, quantity, and space occupancy size) used to trigger the alarm may be not limited, and may be adjusted according to the performance of the database.
  • a database performance monitoring apparatus including:
  • the first type of monitoring module 502 is configured to monitor the number of factors of the first type of monitoring factor.
  • the second type of monitoring module 504 is configured to monitor the duration of the second type of monitoring factor.
  • the third type of monitoring module 506 is configured to monitor the spatial size of the third type of monitoring factor.
  • the database performance determining module 508 is configured to determine an operating state of the database according to a factor number, a duration, and a space size; the running state includes a normal running state and an abnormal running state, and the number, duration, or space size corresponding to each monitoring factor, and corresponding
  • the set threshold is compared, and when there is at least one monitoring factor exceeding the corresponding threshold, determining that the database is in an abnormal running state; wherein the first type of monitoring factor refers to a number of factors according to the monitoring factor, which may reflect the database a monitoring factor of a type of operational performance; the operational state includes a normal operating state and an abnormal operating state; and the second type of monitoring factor refers to a monitoring factor that reflects a type of operational performance of the database according to a duration of the monitoring factor; The third type of monitoring factor refers to a monitoring factor that can reflect the type of running performance of the database according to the size of the monitoring factor.
  • the first type of monitoring factor described above includes unavailable redo log files, structured query language records submitted by each data manipulation language, current process, exception wait events, levels of Btree indexes, and each A cursor that is opened or parsed in session control.
  • the first type of monitoring module is also used to monitor the number of redo log files that are not available; to monitor the number of structured query language records submitted per data manipulation language; to monitor the usage of current processes; to monitor the number of abnormal waiting events; The number of levels of the Btree index; and monitors the number of cursors opened or resolved in each session control.
  • the second type of monitoring factor comprises: distributed transaction and session control;
  • the second type of monitoring module 504 is also used to monitor the waiting time of distributed things; monitor the duration of each session control.
  • the third type of monitoring factor includes a rollback segment space, a session control in the temporary table space, and a self-growth sequence
  • the third type monitoring module 506 is further configured to monitor the space size of the rollback segment space; monitor the space size of the session control in the temporary table space; and monitor the current space size of the self-growth sequence.
  • another database performance monitoring device is provided.
  • the fourth type monitoring module 507 is configured to monitor the hit ratio of the lookup object in the shared pool; monitor whether there is a structured query language statement that does not use the bind variable; and monitor whether there is a invalid object.
  • the database performance decision module 508 determines the operational state of the database based on the factor number, duration, space size, hit rate, structured query language statements that do not use the bind variables, and the invalidated object.
  • the database performance monitoring apparatus further includes:
  • the alarm module 510 is configured to determine an abnormality level of the database according to the factor number, the duration, and the space when determining that the database is in an abnormal running state, and send the alarm information to the preset administrator terminal according to the alarm mode corresponding to the abnormal level.
  • the various modules in the above database performance monitoring device may be implemented in whole or in part by software, hardware, and combinations thereof.
  • the above modules may be embedded in the hardware in the processor or in the memory in the server, or may be stored in the memory in the server, so that the processor calls the corresponding operations of the above modules.
  • the processor can be a central processing unit (CPU), a microprocessor, a microcontroller, or the like.
  • a computer device which may be a server, and its internal structure diagram may be as shown in FIG.
  • the computer device includes a processor, memory, network interface, and database connected by a system bus.
  • the processor of the computer device is used to provide computing and control capabilities.
  • the memory of the computer device includes a non-volatile storage medium, an internal memory.
  • the non-volatile storage medium stores an operating system, computer readable instructions, and a database.
  • the internal memory provides an environment for operation of an operating system and computer readable instructions in a non-volatile storage medium.
  • the database of the computer device is used to store data.
  • the network interface of the computer device is used to communicate with an external terminal via a network connection.
  • the computer readable instructions are executed by the processor to implement a database performance monitoring method.
  • FIG. 8 is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation of the computer device to which the solution of the present application is applied.
  • the specific computer device may It includes more or fewer components than those shown in the figures, or some components are combined, or have different component arrangements.
  • a computer apparatus comprising a memory and one or more processors having stored therein computer readable instructions that, when executed by a processor, implement the steps of a database performance monitoring method provided in any one of the embodiments of the present application.
  • One or more non-volatile storage media storing computer readable instructions, when executed by one or more processors, cause one or more processors to implement a database provided in any one of the embodiments herein The steps of the performance monitoring method.
  • the readable storage medium which when executed, may include the flow of an embodiment of the methods as described above.
  • the storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM), or the like.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Mathematical Physics (AREA)
  • Quality & Reliability (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

一种数据库性能监测方法。该数据库性能监测方法包括：监控第一类监控因子的因子数；监控第二类监控因子的时长；监控第三类监控因子的空间大小；根据所述因子数、所述时长和所述空间大小确定数据库的运行状态；所述运行状态包括正常运行状态和异常运行状态。通过对三类监控因子的状态进行监控，根据第一类监控因子的因子数、第二类监控因子的时长以及第三类监控因子的空间大小来确定数据库的运行状态。

Description

数据库性能监测方法、装置、计算机设备和存储介质
相关申请的交叉引用
本申请要求于2017年06月29日提交中国专利局，申请号为2017105179774，申请名称为“数据库性能监测方法、装置、计算机设备和存储介质”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及一种数据库性能监测方法、装置、存储介质和计算机设备。
背景技术
用于监测数据库的性能的指标有很多，相应的监控方案也有多种。其中，每种监控方案都有不同的监控指标和对应算法。
传统的各种数据库性能监测方法中，都是针对某一特定的数据库应用，对相应的一种或几种该应用的常用指标进行监控。然而，发明人意识到，这种方法造成数据库的性能监控不够全面，当数据库有性能波动时，就无法及时、准确的发现和处理。
发明内容
根据本申请公开的各种实施例，提供一种数据库性能监测方法、装置、存储介质和计算机设备。
一种数据库性能监测方法，包括：监控第一类监控因子的因子数；监控第二类监控因子的时长；监控第三类监控因子的空间大小；根据所述因子数、所述时长和所述空间大小确定数据库的运行状态；所述运行状态包括正常运行状态和异常运行状态，将每个监控因子对应的因子数、时长或空间大小，和对应设置的阈值进行比较，当存在至少一个超过对应阈值的监控因子时，判定所述数据库处于异常运行状态；所述第一类监控因子是指根据监控因子的因子数，可以反映出数据库的运行性能的类型的监控因子；所述运行状态包括正常运行状态和异常运行状态；所述第二类监控因子是指根据监控因子的时长，可以反映出数据库的运行性能的类型的监控因子；及所述第三类监控因子是指根据监控因子的大小，可以反映出数据库的运行性能的类型的监控因子。
一种数据库性能监测装置，包括：第一类监控模块，用于监控第一类监控因子的因子数；第二类监控模块，用于监控第二类监控因子的时长；第三类监控模块，用于监控第三类监控因子的空间大小；数据库性能判定模块，用于根据所述因子数、所述时长和所述空间大小确定数据库的运行状态，将每个监控因子对应的因子数、时长或空间大小，和对应设置的阈值进行比较，当存在至少一个超过对应阈值的监控因子时，判定所述数据库处于异常运行状态；所述第一类监控因子是指根据监控因子的因子数，可以反映出数据库的运行性能的类型的监 控因子；所述运行状态包括正常运行状态和异常运行状态；所述第二类监控因子是指根据监控因子的时长，可以反映出数据库的运行性能的类型的监控因子；及所述第三类监控因子是指根据监控因子的大小，可以反映出数据库的运行性能的类型的监控因子。
一种计算机设备，包括存储器和一个或多个处理器，存储器中存储有计算机可读指令，计算机可读指令被处理器执行时实现本申请任意一个实施例中提供的数据库性能监测方法的步骤。
一个或多个存储有计算机可读指令的非易失性存储介质，计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器实现本申请任意一个实施例中提供的数据库性能监测方法的步骤。
本申请的一个或多个实施例的细节在下面的附图和描述中提出。本申请的其它特征和优点将从说明书、附图以及权利要求书变得明显。
附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。
图1A为根据一个或多个实施例中数据库性能监测方法的应用场景图；
图1B为一个或多个实施例中数据库性能监测方法的流程图；
图2为一个或多个实施例中监控第一类监控因子的因子数的流程图；
图3为一个或多个实施例中监控第二类监控因子的时长的流程图；
图4为一个或多个实施例中监控第三类监控因子的空间大小的流程图；
图5为一个或多个实施例中数据库性能监测装置的框图；
图6为另一个实施例中数据库性能监测装置的框图；
图7为又一个实施例中数据库性能监测装置的框图；
图8为一个或多个实施例中服务器的框图。
具体实施方式
为了使本申请的技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。
本申请提供的数据库性能监测方法，可以应用于如图1A所示的应用环境中。管理员终端102与服务器104通过网络进行通信。服务器通过监控第一类监控因子的因子数、监控第二类监控因子的时长及监控第三类监控因子的空间大小，根据所述因子数、所述时长和所述空间大小确定数据库的运行状态，当确定所述数据库为异常运行状态时，根据因子数、时长和空间大小确定数据库的异常等级，并按照异常等级对应的告警方式，向管理员终端发送告警信息。管理员终端102可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电 脑和便携式可穿戴设备，服务器104可以用独立的服务器或者是多个服务器组成的服务器集群来实现。在其中一个实施例中，如图1B所示，提供了一种数据库性能监测方法，该方法包括：
步骤S102，监控第一类监控因子的因子数。
在其中一个实施例中，监控因子是指对数据库的运行性能具有一定影响的因子。如包括数据库的当前进程、分布式事务、会话控制以及回滚段空间等等。当监控因子对应的特征值超过或小于一定的触发阈值时，则可能会对数据库的运行性能产生较大的影响，比如严重降低数据库的数据处理能力，甚至会造成宕机等。其中，针对不同的监控因子，其对应的特征值不一定行相同。该特征值可为因子数、时长、空间大小等。触发阈值和特征值相对应，可为一个具体的特征数值。比如，可为一个具体的数量阈值、时长阈值以及空间阈值等。
服务器可按照预设的频率对影响数据库的运行性能的监控因子进行监控，获取对应监控因子的特征值，并将该特征值和对应的触发阈值进行比较，以判定数据库的运行状态。数据库的运行状态包括正常运行状态和异常运行状态。当出现异常运行状态时，会使得数据库的数据处理性能大幅下降，严重情况下，还会导致系统宕机。
其中，第一类监控因子是指根据监控因子的因子数，可以反映出数据库的运行性能的类型的监控因子。具体地，是指对监控因子的因子数超过或小于一定数量的情况下，会对数据库的运行性能具有一定影响的类型的监控因子。比如，第一类监控因子可为重做日志文件、每次数据操纵语言提交的结构化查询语言记录、当前进程、异常等待事件、Btree索引的层级、每个会话控制中打开或解析的游标等其中的任意一种或几种监控因子的组合。
在其中一个实施例中，服务器可针对每个第一类监控因子，设置相应的数量阈值，并比较每个第一类监控因子和与之相应的数量阈值之间的大小，根据该大小来判定数据库的运行状态。其中，该数量阈值用于反映相应的第一类监控因子的因子数会是否会引起数据库出现运行异常的临界数值。该数量阈值可根据对应数据库的性能或参数等进行设置，各个第一类监控因子的数量阈值可相同或者不同。
步骤S104，监控第二类监控因子的时长。
本实施例中，第二类监控因子是指根据监控因子的时长(比如占用时长会等待时长等)，可以反映出数据库的运行性能的类型的监控因子。比如，该第二类监控因子可为分布式事务或会话控制等任意一种或几种监控因子的组合。
在其中一个实施例中，服务器可针对每个第二类监控因子，设置相应的时长阈值，并比较每个第二类监控因子和与之相应的时长阈值之间的大小，根据该大小来判定数据库的运行状态。其中，该时长阈值用于反映相应的第二类监控因子的时长是否会引起数据库出现运行异常的临界数值。该时长阈值可根据对应数据库的性能或参数等进行设置，各个第二类监控因子对应的时长阈值可相同或者不同。
步骤S106，监控第三类监控因子的空间大小。
本实施例中，第三类监控因子是指根据监控因子的大小(比如在数据库中的占用空间大小等)，可以反映出数据库的运行性能的类型的监控因子。比如，该第三类监控因子可为回滚 段空间、会话控制在临时表空间和自增长序列等任意一种或几种监控因子的组合。
在其中一个实施例中，服务器可针对每个第三类监控因子，设置相应的空间阈值，并比较每个第三类监控因子和与之相应的空间阈值之间的大小，根据该大小来判定数据库的运行状态。其中，该空间阈值用于反映相应的第三类监控因子的时长是否会引起数据库出现运行异常的临界数值。该时长阈值可根据对应数据库的性能或参数等进行设置，各个第三类监控因子对应的空间阈值可相同或者不同。
步骤S108，根据因子数、时长和空间大小确定数据库的运行状态。
在其中一个实施例中，服务器可结合实时监控到的第一类因监控子数的因子数大小、第二类监控因子的时长以及第三类监控因子的空间大小来判定数据库是否处于异常运行状态。具体地，可将实时检测到的每个类别的监控因子对应的因子数、时长或空间大小，和与之相对应阈值进行比较，当存在至少一个超过该阈值的监控因子时，即可判定该数据库处于异常运行状态。并可获取引起该运行状态的监控因子的信息，生成携带该监控因子的信息的告警信息。
比如，当检测到不可用的重做日志文件的数量超过对应预设数量时，则可生成不可用的重做日志文件的数量过多的告警信息，并可将该告警信息发送至对应的管理员终端，使得管理员可即时对数据库进行相应地调整。
在其中一个实施例中，上述的数据库性能监测方法可应用于多种数据库中，比如可应用于Oracle数据库、Mysql数据库、DB2数据库以及Sybase数据库等。
上述的数据库性能监测方法，通过对三类监控因子的状态进行监控，根据第一类监控因子的因子数、第二类监控因子的时长以及第三类监控因子的空间大小来确定数据库的运行状态，使得可对数据库的性能监控进行全面监控，提高了对数据库异常运行状态的发现的及时性和准确性。
在其中一个实施例中，第一类监控因子包括不可用的重做日志文件、每次数据操纵语言提交的结构化查询语言记录、当前进程、异常等待事件、Btree索引的层级和每个会话控制中打开或解析的游标。
如图2所示，步骤S102包括：
步骤S202，监控不可用的重做日志文件的数量。
本实施例中，重做日志文件(即Redo Log，也称重做日志组)包含所有的数据库变化历史，数据库的所有操作变化，均按照写入重做日志缓冲区先于数据块缓冲区、写入重做日志文件先于写入数据文件；当发生提交动作时，将重做日志缓冲区变化刷到重做日志文件。Redo-Log包括在线重做日志(Online Redo Log)与归档日志(Archive Redo Log)。
Redo-Log的状态包括Current状态、Active状态以及Inactive状态等。Current状态表示当前数据库正在使用的Redo Log。Active状态表示处于被使用或被占用的状态，不过该RedoLog中的内容还没有归档，或者文件中的数据没有全部写入数据文件，一旦需要实例恢复，必须借助于该文件中的内容。Inactive状态表示该Redo Log中的内容已经被归档了，该组处于空闲状态。可用的重做日志文件即为处于Inactive状态的Redo Log；不可用的重做日志文 件即为处于Active状态的Redo Log。
可实时监控处于Inactive状态的Redo Log的数量，其中，当其小于一定数量时，可能会引起Redo Wait等待事件。出现此问题的原因可能有两种：一是前端DML数据量过大日志容量不足，监控会抓出占用文件空间(即Redo Size)超过对应预设大小(比如该预设空间的大小为10M)的SQL(Structured Query Language)；二是后端日志归档有问题，Active状态切换慢。
服务器可针对不可用的重做日志文件设置相应的数量阈值，当不可用的重做日志文件的数量大于该数量阈值时，生成告警信息。其中，该数量阈值可根据重做日志文件的总数来确定，比如可设置成该总数的某一百分比。举例来说，可将该数量阈值设置为占重做日志文件的总数的75％，当可用的重做日志文件的数量大于总数的75％时，生成告警信息。
步骤S204，监控每次数据操纵语言提交的结构化查询语言记录的数量。
本实施例中，数据操纵语言(Data Manipulation Language，DML)包括Select、Update、Insert、Delete语句，每条语句中包含多条SQL。服务器可实时监控每次数据操纵语言提交的SQL记录的数量。该数量越多，会造成数据库事物处理缓慢、Redo空间占用过多等问题。
在其中一个实施例中，服务器可针对该数据操纵语言提交的SQL记录的数量，也设置了相应的数量阈值。当该数量超过相应的数量阈值时，可判定数据库处于异常运行状态，生成相应的告警信息。
在其中一个实施例中，可针对不同的时段设置对应不同的数量阈值，并将该每次DML中提交的条数与所处时间段该数量阈值进行比较。举例来说，可针对处于8:00-21:00内的时间段，设置相应的数量阈值为1000条；针对21：00至24：00、0：00～8：00，设置相应的数量阈值为10000。通过设置不同时间段对应的数量阈值，可使得数据库在数据处理高峰期设置较小的数量阈值，以防止占用过多空间，对其它数据处理的影响；而在数据处理低谷期设置较大的数量阈值，以提高对该数据处理的性能。
步骤S206，监控当前进程的使用量。
本实施例中，服务器还可按照预设的监控频率实时监控当前进程(Process)的数量，该数量即Process的使用量。当当前进程的使用量达到数据库所设置的最大值时，则将无法产生新的数据库(DB)连接。
在其中一个实施例中，可根据数据库所设置的进程数量的最大值，设置一个相应的数量阈值。可将该最大值即设置为数量阈值，或者将数量阈值设置为该最大值的某一百分比，比如为最大值的95％等。从而使得当该使用量达到数量阈值时，判定数据库处于异常运行状态，生成相应的告警信息。
步骤S208，监控异常等待事件的数量。
本实施例中，异常等待事件是指等待处理的事件的等待时长超过对应预设时长的一种或几种类型的事件。包括数据库异常等待事件和超过对应预设时长的锁等待。其中，该数据库异常等待事件的类型包括Latch Free,Enqueue,DB File Scattered Read,DB File Sequential Read,Buffer Busy Waits等几种等待类型的事件。等待时长可根据每个类型设置相同或不同的时长， 比如可统一设置为10分钟，当超过该时长时，则判定对应事件为异常等待事件。
服务器可统计当前时刻下，处于等待状态下的异常等待事件的数量，当出现大量等待事件时，会使得Session无法结束，导致JDBC(Java Data Base Connectivity，Java数据库连接)连接占满，应用无法连接数据库。
在其中一个实施例中，该超过对应预设时长的锁等待包括等待时长超过对应预设时长的数据库TM锁(表级锁)、TX锁(事务锁或行级锁)等待。同样地，可针对TM锁(表级锁)、TX锁等待所设置的预设时长可为任意时长，比如为10分钟。统计当前处于等待状态下，超过对应预设时长的TM锁(表级锁)、TX锁数量。
在其中一个实施例中，可针对该数量设置对应的数量阈值，使得当检测到该数量达到数量阈值时，判定数据库处于异常运行状态，生成相应的告警信息。
步骤S210，监控Btree索引的层级的层级数。
本实施例中，Btree索引是数据库中的一种常见的索引结构，其层级数(Blevel)越小，则查找索引的效率越高。服务器可针对每个Btree索引，监控对应的Blevel的大小。
在其中一个实施例中，可设置层级数阈值，当对应的使得当Btree索引的Blevel超过该层级数阈值时，判定数据库处于异常运行状态，生成相应的告警信息。优选地，层级数阈值可设置为3。
步骤S212，监控每个会话控制中打开或解析的游标的数量。
本实施例中，游标(Cursor)的作用是临时存储从数据库中提取的数据块，包含隐式Cursor、显式Cursor、动态Cursor三种。当一个会话控制(Session)打开或解析的Cursor的数量越多，则对数据库的性能影响越大。
在其中一个实施例中，可针对每个Session打开或解析的Cursor，设置对应的数量阈值，使得超过该数量阈值时，判定数据库处于异常运行状态，生成相应的告警信息。具体地，该数量阈值可根据DB的最大值来确定，如可设置为DB最大值的95％。
本实施例中，通过针对不可用的重做日志文件、每次数据操纵语言提交的结构化查询语言记录、当前进程、异常等待事件、Btree索引的层级以及每个会话控制中打开或解析的游标的第一类监控因子进行数量监控，使得根据该数量确定数据库的运行状态，可提高对数据库性能监控的全面性。
在其中一个实施例中，第二类监控因子包括：分布式事务和会话控制。如图3所示，步骤S104包括：
步骤S302，监控分布式事物的等待时长。
本实施例中，分布式(Distributed)事物通常会被数据库自动处理，并在很短的时间内处理完毕。当出现等待时长较长的分布式事物时，会影响数据库的处理性能。可设置相应的等待时长阈值，并将所监控的等待时长与该等待时长阈值进行比较，使得当超过该等待时长阈值时，判定数据库处于异常运行状态，生成相应的告警信息。具体的，该等待时长阈值可根据数据库的性能来设置，可设置为任意合适的数值，比如可设置为30分钟。可监控数据库等待超过30分钟的分布式事务，分布式锁仅发生在有Dblink的数据库中。如果在Commit或 Rollback的时候，出现了连接中断或某个数据库站点Crash的情况，则提交操作可能会无法继续，使得该分布式事物的处于长时间等待的状态。
步骤S304，监控每个会话控制的占用时长。
本实施例中，所监控的会话控制(Session)包括具有实名用户的Session、应用OPR用户连接DB的Session以及Mon用户(Mon-User)的Session。具体地，该实名用户可为PAICDOM域名下的实名用户，执行SQL(实名用户只有Select权限)的Session。可针对实名用户以及OPR用户的Session分别设置对应的时长阈值，比如可设置实名用户的Session的占用时长的时长阈值为10分钟，OPR用户的Session的占用时长的时长阈值为30分钟。使得可监控是否出现实名用户，执行SQL超过10分钟未完成的Sesssion，或者是否出现应用OPR用户连接DB超过30分钟的Session，若存在任意一种，则判定处于异常运行状态，生成相应的告警信息。
在其中一个实施例中，上述的步骤S302和步骤S304之间的执行顺序也不做限定。
本实施例中，通过对分布式事务和会话控制的第二类监控因子的时长进行监控，提高了对数据库性能监测的全面性。
在其中一个实施例中，第三类监控因子包括回滚段空间、会话控制在临时表空间和自增长序列。如图4所示，步骤S106包括：
步骤S402，监控回滚段空间的空间大小。
本实施例中，该空间大小表示回滚段空间在表空间中的占用大小。当某个Session在执行DML时，Commit之前，老的数据会写在UNDO表空间里，新数据和回滚段信息会写在REDO表空间里，该UNDO空间包含多个回滚段。当一次修改的数据过多时，回滚段就会占用越多，再做Commit或Rollback时会费时越久。因此，可监控回滚段空间在表空间中的占用大小。
在其中一个实施例中，可设置相应的空间阈值，使得当检测到回滚段空间的空间大小超过该空间阈值时，判定处于异常运行状态，生成相应的告警信息。具体地，该空间阈值可根据表空间的大小来设置，比如可设置为表空间大小的5％。
步骤S404，监控会话控制在临时表空间中的空间大小。
本实施例中，临时表空间是用来存储临时表、中间排序结果等临时对象，像数据库中一些操作：Select Distinct、Order By、Group By、Union All等都可能会用到临时表空间。该空间大小是指一个Session在临时表空间中的占用大小。
在其中一个实施例中，同样可设置相应的空间阈值，使得当检测到某一个Session的空间大小超过该空间阈值时，判定处于异常运行状态，生成相应的告警信息。具体地，该空间阈值可根据表空间的大小来设置，比如可设置为表空间大小的5％。
步骤S406，监控自增长序列的当前空间大小。
数据库的自增长序列(Sequence)一般是按步长自动增长，并且都有最大值设定，如果Sequence设置为Nocycle(不可循环的)，则Sequence用到最大值时，应用无法插入新数据。因此，可实时监控Sequence的当前空间大小。
在其中一个实施例中，同样可设置相应的空间阈值，使得当检测到Sequence的空间大小 超过该空间阈值时，判定处于异常运行状态，生成相应的告警信息。具体地，该空间阈值可根据预先设置的Sequence的最大值来设置，比如可设置为表空间大小的80％。
在其中一个实施例中，上述的步骤S402、步骤S404以及步骤S406之间的执行顺序也不做限定。
本实施例中，通过设置回滚段空间、会话控制在临时表空间和自增长序列的第三类监控因子，进一步提高了对数据库性能监测的全面性。
在其中一个实施例中，在步骤S108之前，还包括：监控共享池中的查找对象的命中率；监控是否存在未使用绑定变量的结构化查询语言语句；监控是否存在失效对象。步骤S108包括：根据因子数、时长、空间大小、命中率、未使用绑定变量的结构化查询语言语句和失效对象确定数据库的运行状态。
本实施例中，该监控因子还包括共享池中的查找对象、结构化查询语言语句以及失效对象。对应的触发阈值可为命中率阈值、存在未使用绑定变量的结构化查询语言语句以及存在失效对象。
在其中一个实施例中，共享池(Shared Pool)是SGA(System Global Area，系统全局区)中最重要的内存空间，主要是库缓存和数据字典缓存组成。Shared Pool的内存空间是动态分布的，根据LRU算法(Least Recently Used，最近最少使用算法)进行置换，因此，Shared Pool的Gets(Parse)和Pins(Execution)命中率是其性能的重要指标。
具体地，可实时统计在预设的一段时间内的该命中率，并设置对应的命中率阈值，比较该命中率和该命中率阈值的大小。若小于该命中率阈值，可判定处于异常运行状态，生成相应的告警信息。其中，命中率阈值可根据数据库的性能设置为任意合适的数值，比如可被设置为95％。
对象失效的根本原因是对象之间的依赖关系属性发生了变化，比如对象A的定义引用了对象B.EMAIL，当B对象被执行DDL重新定义列“EMAIL”后，则A因为引用了B.EMAIL则就会失效，需重新编译。对象之间的依赖关系可在DBA_DEPENDENCIES中查询，常见的失效对象有View、Synonym、Procedure、Package等。
当检测到某一对象所依赖的对象不存在时，可判定该对象依赖失效，即存在对象失效。当判定存在失效对象时，判定数据库处于有异常运行状态。
本实施例中，通过进一步监控共享池中的查找对象的命中率；监控是否存在未使用绑定变量的结构化查询语言语句；监控是否存在失效对象，使得可结合上述的三类监控因子以及共享池中的查找对象、未使用绑定变量的结构化查询语言语句以及失效对象这些监控因子来判定数据库的运行状态，进一步提高了对数据库运行状态监测的全面性。
在其中一个实施例中，上述方法还包括：当确定数据库为异常运行状态时，根据因子数、时长和空间大小确定数据库的异常等级；按照异常等级对应的告警方式，向预设的管理员终端发送告警信息。
本实施例中，服务器可根据上述各个监控因子确定处于异常运行状态的异常等级。其中，异常等级可包括多个，举例来说，可按照严重程度从轻到重依次划分为5个级别：通知(Info)、 警告(Warning)、一般(Minor)、重要(Major)以及严重(Critical)。其中，告警方式包含邮件告警、短信告警以及电话告警等其中的一种或几种的组合。举例来说，针对Info、Warning、以及Minor级别的异常运行状态，可采用邮件告警，针对Major以及Critical级别的异常运行状态，可采用邮件告警加电话告警的告警方式。
服务器可针对各个异常运行状态设置对应的告警通知对象，按照预设的告警方式该告警通知对象对应的管理员终端发送告警信息。该告警信息中包含判定引起异常运行的监控因子的详细信息以及对应的解决方案，使得告警通知对象可根据该告警信息对数据库即时进行处理。
以邮件告警为例说明，服务器可预先针对相应级别的异常等级，设置好相应的收件人或组，邮件告警会显示告警标题、告警的详细信息及解决方案。
以电话告警为例，电话告警可预先设置好相应的呼叫队列，该呼叫队列中包含相应的告警通知对象，比如可以设置1-7人。按照设置的电话先后顺序进行告警呼叫，并检测呼叫的告警通知对象是否成功建立电话通信连接。若是，则，则不再呼叫后面的电话；否则，按顺序第二人至最后一人，直至与其中一个告警通知对象是否成功建立电话通信连接为止。如果最后一人也没有接听告警电话，则循环从第一人开始重新循环呼叫，直到有人接叫，保证重要告警被及时通知到系统管理员。成功建立电话通信连接后，可调用语音播报功能语音自动播放告警信息。比如可播报相应生成的监控告警标题和告警时间，以提醒告警通知对象及时查看邮件获知异常运行的信息。
本实施例中，通过设置多个异常等级，并根据因子数、时长和空间大小确定数据库的异常等级；按照异常等级对应的告警方式，向预设的管理员终端发送告警信息，以使得告警通知对象可及时有效地接收到告警信息，提高了数据库在异常运行时可被处理的及时性。
应该理解的是，虽然图1B-4的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图1B-4中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。
在其中一个实施例中，如下表1所示，提供了一种Oracle数据库的监控因子信息表。可针对包含下表中的18个监控因子进行监控，并判断每个监控因子的特征值是否满足对应的触发阈值，并根据判断结果确定数据库的运行状态，且当判定处于异常运行状态时，进一步根据该监控因子及其特征值确定对应的异常等级、告警方式和告警信息。
表1 Oracle数据库的监控因子信息表
Figure PCTCN2018082529-appb-000001
Figure PCTCN2018082529-appb-000002
Figure PCTCN2018082529-appb-000003
Figure PCTCN2018082529-appb-000004
Figure PCTCN2018082529-appb-000005
在其中一个实施例中，上述的18项监控因子中具体的用于触发告警的各个触发阈值(比如时长、数量、空间占用大小)的数值可不做限定，可根据数据库的性能进行调整。
本实施例中，通过监控上述的18项监控因子，根据该18项监控因子的特征值是否满足对应的触发阈值来确定数据库的运行状态，可提高数据库监控的全面性，
在其中一个实施例中，如图5所示，提供了一种数据库性能监测装置，包括：
第一类监控模块502，用于监控第一类监控因子的因子数。
第二类监控模块504，用于监控第二类监控因子的时长。
第三类监控模块506，用于监控第三类监控因子的空间大小。
数据库性能判定模块508，用于根据因子数、时长和空间大小确定数据库的运行状态；运行状态包括正常运行状态和异常运行状态，将每个监控因子对应的因子数、时长或空间大小，和对应设置的阈值进行比较，当存在至少一个超过对应阈值的监控因子时，判定所述数 据库处于异常运行状态；其中，所述第一类监控因子是指根据监控因子的因子数，可以反映出数据库的运行性能的类型的监控因子；所述运行状态包括正常运行状态和异常运行状态；所述第二类监控因子是指根据监控因子的时长，可以反映出数据库的运行性能的类型的监控因子；及所述第三类监控因子是指根据监控因子的大小，可以反映出数据库的运行性能的类型的监控因子。
在其中一个实施例中，上述的第一类监控因子包括不可用的重做日志文件、每次数据操纵语言提交的结构化查询语言记录、当前进程、异常等待事件、Btree索引的层级和每个会话控制中打开或解析的游标。
第一类监控模块还用于监控不可用的重做日志文件的数量；监控每次数据操纵语言提交的结构化查询语言记录的数量；监控当前进程的使用量；监控异常等待事件的数量；监控Btree索引的层级数；及监控每个会话控制中打开或解析的游标的数量。
在其中一个实施例中，第二类监控因子包括：分布式事务和会话控制；及
第二类监控模块504还用于监控分布式事物的等待时长；监控每个会话控制的占用时长。
在其中一个实施例中，第三类监控因子包括回滚段空间、会话控制在临时表空间和自增长序列；
第三类监控模块506还用于监控回滚段空间的空间大小；监控会话控制在临时表空间中的空间大小；及监控自增长序列的当前空间大小。
在其中一个实施例中，如图6所示，提供了另一种数据库性能监测装置。包括：
第四类监控模块507，用于监控共享池中的查找对象的命中率；监控是否存在未使用绑定变量的结构化查询语言语句；监控是否存在失效对象。
数据库性能判定模块508根据因子数、时长、空间大小、命中率、未使用绑定变量的结构化查询语言语句和失效对象确定数据库的运行状态。
在其中一个实施例中，如图7所示，该数据库性能监测装置还包括：
告警模块510，用于当确定数据库为异常运行状态时，根据因子数、时长和空间大小确定数据库的异常等级；及按照异常等级对应的告警方式，向预设的管理员终端发送告警信息。
上述数据库性能监测装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于服务器中的处理器中，也可以以软件形式存储于服务器中的存储器中，以便于处理器调用执行以上各个模块对应的操作。该处理器可以为中央处理单元(CPU)、微处理器、单片机等。
在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图8所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机可读指令和数据库。该内存储器为非易失性存储介质中的操作系统和计算机可读指令的运行提供环境。该计算机设备的数据库用于存储数据。该计算机设备的网络接口用于与外部的终端通过网络连接 通信。该计算机可读指令被处理器执行时以实现一种数据库性能监测方法。
本领域技术人员可以理解，图8中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
一种计算机设备，包括存储器和一个或多个处理器，存储器中存储有计算机可读指令，计算机可读指令被处理器执行时实现本申请任意一个实施例中提供的数据库性能监测方法的步骤。
一个或多个存储有计算机可读指令的非易失性存储介质，计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器实现本申请任意一个实施例中提供的数据库性能监测方法的步骤。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机可读指令来指令相关的硬件来完成，所述的计算机可读指令可存储于一非易失性计算机可读取存储介质中，该计算机可读指令在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)等。
以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (20)

  1. 一种数据库性能监测方法，包括：
    监控第一类监控因子的因子数；
    监控第二类监控因子的时长；
    监控第三类监控因子的空间大小；
    根据所述因子数、所述时长和所述空间大小确定数据库的运行状态，将每个监控因子对应的因子数、时长或空间大小，和对应设置的阈值进行比较，当存在至少一个超过对应阈值的监控因子时，判定所述数据库处于异常运行状态；
    所述第一类监控因子是指根据监控因子的因子数，可以反映出数据库的运行性能的类型的监控因子；所述运行状态包括正常运行状态和异常运行状态；所述第二类监控因子是指根据监控因子的时长，可以反映出数据库的运行性能的类型的监控因子；及所述第三类监控因子是指根据监控因子的大小，可以反映出数据库的运行性能的类型的监控因子。
  2. 根据权利要求1所述的方法，其特征在于，所述第一类监控因子包括不可用的重做日志文件、每次数据操纵语言提交的结构化查询语言记录、当前进程、异常等待事件、Btree索引的层级和每个会话控制中打开或解析的游标；
    所述监控第一类监控因子的因子数，包括：
    监控所述不可用的重做日志文件的数量；
    监控每次数据操纵语言提交的结构化查询语言记录的数量；
    监控所述当前进程的使用量；
    监控所述异常等待事件的数量；
    监控所述Btree索引的层级的层级数；及
    监控所述每个会话控制中打开或解析的游标的数量。
  3. 根据权利要求1所述的方法，其特征在于，所述第二类监控因子包括：分布式事务和会话控制；
    所述监控第二类监控因子的时长，包括：
    监控所述分布式事物的等待时长；及
    监控每个会话控制的占用时长。
  4. 根据权利要求1所述的方法，其特征在于，所述第三类监控因子包括回滚段空间、会话控制在临时表空间和自增长序列；
    所述监控第三类监控因子的空间大小，包括：
    监控所述回滚段空间的空间大小；
    监控所述会话控制在临时表空间中的空间大小；及
    监控所述自增长序列的当前空间大小。
  5. 根据权利要求1所述的方法，其特征在于，在所述根据所述因子数、所述时长和所述空间大小确定数据库的运行状态之前，还包括：
    监控共享池中的查找对象的命中率；
    监控是否存在未使用绑定变量的结构化查询语言语句；
    监控是否存在失效对象；及
    所述根据所述因子数、所述时长和所述空间大小确定数据库的运行状态，包括：
    所述根据所述因子数、所述时长、所述空间大小、所述命中率、所述未使用绑定变量的结构化查询语言语句和所述失效对象确定数据库的运行状态。
  6. 根据权利要求1所述的方法，其特征在于，当确定所述数据库为异常运行状态时，根据所述因子数、所述时长和所述空间大小确定所述数据库的异常等级；及
    按照所述异常等级对应的告警方式，向预设的管理员终端发送告警信息。
  7. 一种数据库性能监测装置，包括：
    第一类监控模块，用于监控第一类监控因子的因子数；
    第二类监控模块，用于监控第二类监控因子的时长；
    第三类监控模块，用于监控第三类监控因子的空间大小；
    数据库性能判定模块，用于根据所述因子数、所述时长和所述空间大小确定数据库的运行状态，将每个监控因子对应的因子数、时长或空间大小，和对应设置的阈值进行比较，当存在至少一个超过对应阈值的监控因子时，判定所述数据库处于异常运行状态；
    所述第一类监控因子是指根据监控因子的因子数，可以反映出数据库的运行性能的类型的监控因子；所述运行状态包括正常运行状态和异常运行状态；所述第二类监控因子是指根据监控因子的时长，可以反映出数据库的运行性能的类型的监控因子；及所述第三类监控因子是指根据监控因子的大小，可以反映出数据库的运行性能的类型的监控因子。
  8. 根据权利要求7所述的装置，其特征在于，还包括：
    告警模块，用于当确定所述数据库为异常运行状态时，根据所述因子数、所述时长和所述空间大小确定所述数据库的异常等级；及按照所述异常等级对应的告警方式，向预设的管理员终端发送告警信息。
  9. 一个或多个存储有计算机可读指令的非易失性计算机可读存储介质，所述计算机可读指令被一个或多个处理器执行时，使得所述一个或多个处理器执行以下步骤：
    监控第一类监控因子的因子数；
    监控第二类监控因子的时长；
    监控第三类监控因子的空间大小；
    根据所述因子数、所述时长和所述空间大小确定数据库的运行状态，将每个监控因子对应的因子数、时长或空间大小，和对应设置的阈值进行比较，当存在至少一个超过对应阈值的监控因子时，判定所述数据库处于异常运行状态；
    所述第一类监控因子是指根据监控因子的因子数，可以反映出数据库的运行性能的类型的监控因子；所述运行状态包括正常运行状态和异常运行状态；所述第二类监控因子是指根据监控因子的时长，可以反映出数据库的运行性能的类型的监控因子；及所述第三类 监控因子是指根据监控因子的大小，可以反映出数据库的运行性能的类型的监控因子。
  10. 根据权利要求9所述的存储介质，其特征在于，所述第一类监控因子包括不可用的重做日志文件、每次数据操纵语言提交的结构化查询语言记录、当前进程、异常等待事件、Btree索引的层级和每个会话控制中打开或解析的游标；
    所述监控第一类监控因子的因子数，包括：
    监控所述不可用的重做日志文件的数量；
    监控每次数据操纵语言提交的结构化查询语言记录的数量；
    监控所述当前进程的使用量；
    监控所述异常等待事件的数量；
    监控所述Btree索引的层级的层级数；及
    监控所述每个会话控制中打开或解析的游标的数量。
  11. 根据权利要求9所述的存储介质，其特征在于，所述第二类监控因子包括：分布式事务和会话控制；
    所述监控第二类监控因子的时长，包括：
    监控所述分布式事物的等待时长；及
    监控每个会话控制的占用时长。
  12. 根据权利要求9所述的存储介质，其特征在于，所述第三类监控因子包括回滚段空间、会话控制在临时表空间和自增长序列；
    所述监控第三类监控因子的空间大小，包括：
    监控所述回滚段空间的空间大小；
    监控所述会话控制在临时表空间中的空间大小；及
    监控所述自增长序列的当前空间大小。
  13. 根据权利要求9所述的存储介质，其特征在于，所述计算机可读指令被所述处理器执行时还执行以下步骤：
    监控共享池中的查找对象的命中率；
    监控是否存在未使用绑定变量的结构化查询语言语句；
    监控是否存在失效对象；及
    所述根据所述因子数、所述时长和所述空间大小确定数据库的运行状态，包括：
    所述根据所述因子数、所述时长、所述空间大小、所述命中率、所述未使用绑定变量的结构化查询语言语句和所述失效对象确定数据库的运行状态。
  14. 根据权利要求9所述的存储介质，其特征在于，所述计算机可读指令被所述处理器执行时还执行以下步骤：
    当确定所述数据库为异常运行状态时，根据所述因子数、所述时长和所述空间大小确定所述数据库的异常等级；及
    按照所述异常等级对应的告警方式，向预设的管理员终端发送告警信息。
  15. 一种计算机设备，包括存储器及一个或多个处理器，所述存储器中储存有计算机可读指令，所述计算机可读指令被所述一个或多个处理器执行时，使得所述一个或多个处理器执行以下步骤：
    监控第一类监控因子的因子数；
    监控第二类监控因子的时长；
    监控第三类监控因子的空间大小；
    根据所述因子数、所述时长和所述空间大小确定数据库的运行状态，将每个监控因子对应的因子数、时长或空间大小，和对应设置的阈值进行比较，当存在至少一个超过对应阈值的监控因子时，判定所述数据库处于异常运行状态；
    所述第一类监控因子是指根据监控因子的因子数，可以反映出数据库的运行性能的类型的监控因子；所述运行状态包括正常运行状态和异常运行状态；所述第二类监控因子是指根据监控因子的时长，可以反映出数据库的运行性能的类型的监控因子；及所述第三类监控因子是指根据监控因子的大小，可以反映出数据库的运行性能的类型的监控因子。
  16. 根据权利要求15所述的计算机设备，其特征在于，所述第一类监控因子包括不可用的重做日志文件、每次数据操纵语言提交的结构化查询语言记录、当前进程、异常等待事件、Btree索引的层级和每个会话控制中打开或解析的游标；
    所述监控第一类监控因子的因子数，包括：
    监控所述不可用的重做日志文件的数量；
    监控每次数据操纵语言提交的结构化查询语言记录的数量；
    监控所述当前进程的使用量；
    监控所述异常等待事件的数量；
    监控所述Btree索引的层级的层级数；及
    监控所述每个会话控制中打开或解析的游标的数量。
  17. 根据权利要求15所述的计算机设备，其特征在于，所述第二类监控因子包括：分布式事务和会话控制；
    所述监控第二类监控因子的时长，包括：
    监控所述分布式事物的等待时长；及
    监控每个会话控制的占用时长。
  18. 根据权利要求15所述的计算机设备，其特征在于，所述第三类监控因子包括回滚段空间、会话控制在临时表空间和自增长序列；
    所述监控第三类监控因子的空间大小，包括：
    监控所述回滚段空间的空间大小；
    监控所述会话控制在临时表空间中的空间大小；及
    监控所述自增长序列的当前空间大小。
  19. 根据权利要求15所述的计算机设备，其特征在于，所述处理器执行所述计算机 可读指令时还执行以下步骤：
    监控共享池中的查找对象的命中率；
    监控是否存在未使用绑定变量的结构化查询语言语句；
    监控是否存在失效对象；及
    所述根据所述因子数、所述时长和所述空间大小确定数据库的运行状态，包括：
    根据所述因子数、所述时长、所述空间大小、所述命中率、所述未使用绑定变量的结构化查询语言语句和所述失效对象确定数据库的运行状态。
  20. 根据权利要求15所述的计算机设备，其特征在于，所述处理器执行所述计算机可读指令时还执行以下步骤：
    当确定所述数据库为异常运行状态时，根据所述因子数、所述时长和所述空间大小确定所述数据库的异常等级；及
    按照所述异常等级对应的告警方式，向预设的管理员终端发送告警信息。
PCT/CN2018/082529 2017-06-29 2018-04-10 数据库性能监测方法、装置、计算机设备和存储介质 WO2019001085A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710517977.4 2017-06-29
CN201710517977.4A CN107908518A (zh) 2017-06-29 2017-06-29 数据库性能监测方法、装置、存储介质和计算机设备

Publications (1)

Publication Number Publication Date
WO2019001085A1 true WO2019001085A1 (zh) 2019-01-03

Family

ID=61840517

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/082529 WO2019001085A1 (zh) 2017-06-29 2018-04-10 数据库性能监测方法、装置、计算机设备和存储介质

Country Status (2)

Country Link
CN (1) CN107908518A (zh)
WO (1) WO2019001085A1 (zh)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110399378B (zh) * 2018-04-17 2024-07-16 北京京东尚科信息技术有限公司 数据库系统锁操作分析方法及装置
CN109409700B (zh) * 2018-10-10 2022-03-08 网宿科技股份有限公司 一种配置数据确认方法、业务监测方法及装置
CN109491649A (zh) * 2018-11-20 2019-03-19 北京千丁互联科技有限公司 Dao代码生成方法及计算机终端
CN111581064A (zh) * 2020-03-31 2020-08-25 中国建设银行股份有限公司 基于oracle数据库的索引处理方法、系统、设备和存储介质
CN111767269B (zh) * 2020-06-24 2021-05-04 苏州紫焰网络科技有限公司 数据库实例的健康检测方法、装置、设备及存储介质
CN113204565A (zh) * 2021-05-28 2021-08-03 中国工商银行股份有限公司 数据库监控方法及装置
CN113641567B (zh) * 2021-10-13 2022-03-25 北京易真学思教育科技有限公司 一种数据库巡检方法、装置、电子设备及存储介质
CN114356888A (zh) * 2021-12-30 2022-04-15 中国民航信息网络股份有限公司 事务处理方法及装置、存储介质及电子设备
CN115080577B (zh) * 2022-05-27 2024-08-27 平安银行股份有限公司 数据统计周期切换方法、装置、设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101446914A (zh) * 2007-11-26 2009-06-03 阿里巴巴集团控股有限公司 一种数据库监控方法及装置
CN101876932A (zh) * 2009-11-30 2010-11-03 中国移动通信集团浙江有限公司 内存数据库监控的方法、系统及设备
CN104572401A (zh) * 2015-02-09 2015-04-29 浪潮软件股份有限公司 一种告警方法及告警系统
CN106202444A (zh) * 2016-07-14 2016-12-07 浪潮软件股份有限公司 一种数据库运维监控的实现方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101446914A (zh) * 2007-11-26 2009-06-03 阿里巴巴集团控股有限公司 一种数据库监控方法及装置
CN101876932A (zh) * 2009-11-30 2010-11-03 中国移动通信集团浙江有限公司 内存数据库监控的方法、系统及设备
CN104572401A (zh) * 2015-02-09 2015-04-29 浪潮软件股份有限公司 一种告警方法及告警系统
CN106202444A (zh) * 2016-07-14 2016-12-07 浪潮软件股份有限公司 一种数据库运维监控的实现方法

Also Published As

Publication number Publication date
CN107908518A (zh) 2018-04-13

Similar Documents

Publication Publication Date Title
WO2019001085A1 (zh) 数据库性能监测方法、装置、计算机设备和存储介质
US6405212B1 (en) Database system event triggers
CN105989194B (zh) 表数据比较的方法和系统
US10152513B2 (en) Managing record location lookup caching in a relational database
US7702741B2 (en) Configuring or reconfiguring a multi-master information sharing environment
US9384237B2 (en) High performance real-time relational database system and methods for using same
US6950823B2 (en) Transparent edge-of-network data cache
US9146956B2 (en) Statistical applications in OLTP environment
US11429594B2 (en) Synchronization between primary database and secondary database
US20140052729A1 (en) Optimized data stream management system
WO2021068488A1 (zh) 基于区块链的日志处理方法、装置、计算机设备及存储介质
US9201908B2 (en) Multi-layered multi-tenancy database architecture
WO2018036549A1 (zh) 分布式数据库查询方法、装置及管理系统
US9378235B2 (en) Management of updates in a database system
JP2016505981A (ja) セキュリティ関連システム状態のリアルタイム表現
US9600526B2 (en) Generating and using temporal data partition revisions
CN107562905A (zh) 数据的管理方法、服务器及计算机可读存储介质
CN112084206A (zh) 数据库的事务请求处理方法、相关设备及存储介质
US9747323B1 (en) Method for reconstruction of a distributed lock state after a node addition or removal using a consistent hash
CN110389967A (zh) 数据存储方法、装置、服务器及存储介质
US11347710B2 (en) Auto unload
CN111352746B (zh) 消息限流方法、存储介质
US20060064426A1 (en) Apparatus and method for inhibiting non-critical access based on measured performance in a database system
CN113672652A (zh) 一种数据访问方法、装置、设备及存储介质
CN108984431B (zh) 用于清空过期缓存的方法和装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18824036

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 29.07.2020)

122 Ep: pct application non-entry in european phase

Ref document number: 18824036

Country of ref document: EP

Kind code of ref document: A1