CN112181840A - 一种数据库状态的确定方法及装置、设备、存储介质 - Google Patents

一种数据库状态的确定方法及装置、设备、存储介质 Download PDF

Info

Publication number
CN112181840A
CN112181840A CN202011062106.6A CN202011062106A CN112181840A CN 112181840 A CN112181840 A CN 112181840A CN 202011062106 A CN202011062106 A CN 202011062106A CN 112181840 A CN112181840 A CN 112181840A
Authority
CN
China
Prior art keywords
database
resource consumption
sql statement
information
consumption information
Prior art date
Legal status (The legal status 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 status listed.)
Granted
Application number
CN202011062106.6A
Other languages
English (en)
Other versions
CN112181840B (zh
Inventor
梁梓锋
胡盼盼
卢道和
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
WeBank Co Ltd
Original Assignee
WeBank Co Ltd
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 WeBank Co Ltd filed Critical WeBank Co Ltd
Priority to CN202011062106.6A priority Critical patent/CN112181840B/zh
Publication of CN112181840A publication Critical patent/CN112181840A/zh
Priority to PCT/CN2021/117017 priority patent/WO2022068540A1/zh
Application granted granted Critical
Publication of CN112181840B publication Critical patent/CN112181840B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3688—Test management for test execution, e.g. scheduling of test suites
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3055—Monitoring arrangements for monitoring the status of the computing system or of the computing system component, e.g. monitoring if the computing system is on, off, available, not available
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/242—Query formulation
    • G06F16/2433—Query languages

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Computer Hardware Design (AREA)
  • Mathematical Physics (AREA)
  • Computational Linguistics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Computing Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本申请实施例公开了一种数据库状态的确定方法及装置、设备、存储介质，其中，该方法包括：确定在所述数据库中执行的SQL语句；从信息数据库获取第一资源消耗信息，其中，所述第一资源消耗信息是通过在备用数据库上执行所述SQL语句而得到的所述备用数据库所在设备的资源消耗信息；根据所述第一资源消耗信息对所述SQL语句的消耗进行计算，得到资源消耗分值；根据所述资源消耗分值确定所述数据库的运行状态。

Description

一种数据库状态的确定方法及装置、设备、存储介质
技术领域
本申请实施例涉及但不限于金融科技(Fintech)的信息技术，尤其涉及一种数据库状态的确定方法及装置、设备、存储介质。
背景技术
在金融科技(Fintech)的应用场景下，定位高消耗语句的方式效率很低，且有一定的凭借经验和运气的技巧。普遍上认为高消耗语句等价于慢查询。然而，在系统资源已经完全被占用的情况下，会让一些原本效率很高的语句也成为慢查询，导致排查难度变大，难以准确的确定异常位置。因此，如何准确的确定异常是本领域技术人员需要重点考虑的问题。
发明内容
有鉴于此，本申请实施例提供一种数据库状态的确定方法及装置、设备、存储介质。
本申请实施例的技术方案是这样实现的：
一方面，本申请实施例提供一种数据库状态的确定方法，所述方法包括：确定在所述数据库中执行的SQL语句；从信息数据库获取第一资源消耗信息，其中，所述第一资源消耗信息是通过在备用数据库上执行所述SQL语句而得到的所述备用数据库所在设备的资源消耗信息；根据所述第一资源消耗信息对所述SQL语句的消耗进行计算，得到资源消耗分值；根据所述资源消耗分值确定所述数据库的运行状态。
又一方面，本申请实施例提供一种数据库状态的确定装置，所述装置包括：第一确定模块，用于确定在所述数据库中执行的SQL语句；第一获取模块，用于从信息数据库获取第一资源消耗信息，其中，所述第一资源消耗信息是通过在备用数据库上执行所述SQL语句而得到的所述备用数据库所在设备的资源消耗信息；计算模块，用于根据所述第一资源消耗信息对所述SQL语句的消耗进行计算，得到资源消耗分值；第二确定模块，用于根据所述资源消耗分值确定所述数据库的运行状态。
再一方面，本申请实施例提供一种数据库状态的确定设备，包括存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述方法中的步骤。
还一方面，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述方法中的步骤。
本申请实施例提供的数据库状态的确定方法，一方面，通过确定在所述数据库中执行的SQL语句；从信息数据库获取第一资源消耗信息，其中，所述第一资源消耗信息是通过在备用数据库上执行所述SQL语句而得到的所述备用数据库所在设备的资源消耗信息，这样，通过确定在数据库上执行的SQL语句，然后在备用数据库上回顾当前执行的SQL语句，获取备用数据库所在设备的资源消耗信息，从而确定所述SQL语句准确的资源消耗信息。如此，可以通过备用数据库串行的测试SQL语句的第一资源消耗信息，避免在原数据库上测试SQL语句时，因SQL语句并发执行共享公用设备资源而带来的第一资源消耗信息检测不准确的情况；并且，避免了在原数据库上测试SQL语句时，因锁机制而导致正常业务逻辑无法访问正在测试的数据，进而避免了测试SQL语句对业务逻辑的影响，保证了业务逻辑的正常运行。另一方面，根据所述第一资源消耗信息对所述SQL语句的消耗进行计算，得到资源消耗分值，这样，可以通过计算将所述SQL语句的消耗量化，并根据量化后的分值，准确找到资源消耗高的SQL语句，从而对所述数据库的运行状态进行准确的判断。
附图说明
图1A为本申请实施例数据库状态的确定方法的实现流程示意图；
图1B为本申请实施例数据库状态的确定方法的实现流程示意图；
图2A为本申请实施例数据库状态的确定方法的实现流程示意图；
图2B为本申请实施例采集到SQL语句获取的第一资源消耗信息和第二资源消耗信息的示意图；
图3A为本申请实施例数据库状态的确定方法的实现流程示意图；
图3B为本申请实施例数据库状态的确定方法的实现流程示意图；
图4为本申请实施例数据库状态的确定方法的实现流程示意图；
图5A为本申请实施例数据库状态的确定方法的实现流程示意图；
图5B为本申请实施例获得资源消耗信息方法的实现流程示意图；
图5C为本申请实施例资源消耗信息的获取方法的实现流程示意图；
图6为本申请实施例数据库状态的确定装置的组成结构示意图；
图7为本申请实施例中数据库状态的确定设备的一种硬件实体示意图。
具体实施方式
为了使本申请的目的、技术方案和优点更加清楚，下面结合附图和实施例对本申请的技术方案进一步详细阐述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。
在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。
如果申请文件中出现“第一/第二”的类似描述则增加以下的说明，在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。
除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。
下面结合附图和实施例对本申请的技术方案进一步详细阐述。
本申请实施例提供一种数据库状态的确定方法，图1A为本申请实施例数据库状态的确定方法的实现流程示意图，如图1A所示，该方法包括：
步骤S101，确定在所述数据库中执行的SQL语句；
这里，在所述数据库中执行的SQL语句包括所述数据库正在执行的SQL语句和已经执行的SQL语句，也就是说，步骤S101中的SQL语句可以看作是待处理的目标SQL语句，下面步骤是确定目标SQL语句是否是引起所述数据库异常的原因。
这里，所述数据库为待检测异常的数据库，所述数据库可以为MYSQL、SQL Server和Oracle等。
这里，所述SQL语句可以为以下之一：1)数据操纵语言(Data ManipulationLanguage，DML)，例如，Select、Insert、Update、Delete；2)数据定义语言(Data definitionlanguage，DDL)，例如，Create、Alter、Drop；3)数据控制语言(Data Control Language，DCL)，例如，GRANT、DENY、REVOKE。
在一些实施例中，所述数据库为MYSQL，当检测到数据库所在设备的资源消耗信息发生告警时，例如，CPU/IO等发生告警时，执行show processlist获取当前执行SQL语句。
步骤S102，从信息数据库获取第一资源消耗信息，其中，所述第一资源消耗信息是通过在备用数据库上执行所述SQL语句而得到的所述备用数据库所在设备的资源消耗信息；
这里，所述信息数据库用于存储所述SQL语句运行时的资源消耗信息，所述资源消耗信息至少包括第一资源消耗信息。
这里，获得所述第一资源消耗信息的过程包括：在备用数据库上执行所述SQL语句；读取不同时段执行所述SQL产生的负载信息；根据所述负载信息计算平均负载信息，将所述平均负载信息作为第一资源消耗信息。
这里，所述备用数据库与原数据库完全一致，且不存在实际的业务访问，在所述备用数据库上执行所述SQL语句时可以采用串行的方式，这样，既可以测试执行所述SQL语句时，备用数据库所在设备的资源消耗信息，也不会影响实际的线上的业务对数据库的访问。
在一些实施例中，所述备用数据库与原数据库在同一台设备例如服务器上，运行所述备用数据库获得的设备的资源消耗信息即为待检测异常的数据库的设备的资源消耗信息。
在另一种实施例中，所述备用数据库与原数据库不在同一台设备例如服务器上，但所述备用数据库所在的设备与原数据库所在的设备具有相同的运行环境，此时，可以将所述备用数据库所在设备的资源消耗信息视为待检测异常的数据库的设备的资源消耗信息。
步骤S103，根据所述第一资源消耗信息对所述SQL语句的消耗进行计算，得到资源消耗分值；
这里，所述资源消耗分值为所述SQL语句的能耗值，可以通过所述第一资源消耗信息和SQL语句的能耗计算公式得到。
步骤S104，根据所述资源消耗分值确定所述数据库的运行状态。
在一些实施例中，所述步骤S104，根据所述资源消耗分值确定所述数据库的运行状态包括：步骤S1041，预设语句消耗程度与分数值的对应关系；其中，语句消耗程度可以看作是不同的消耗等级，在实施的时候可以是，等级越高或者程度越高意味着分数值越高，当然本领域的技术人员还可以设置其他对应关系；在一些实施例中，可以参见表1。步骤S1042，根据所述资源消耗分值和所述对应关系，确定所述数据库的语句消耗程度；步骤S1043，根据所述语句消耗程度，确定所述数据库的运行状态。一般来说，语句消耗程度越高，数据库的运行状态越容易为异常状态，其中运行状态可以包括正常状态或异常状态，在实施的时候可以设置一些数据库的参数，根据参数是否超过阈值来确定数据库是否处于异常状态，例如响应时间为例，在响应时间超过特定阈值的情况下，确定数据库运行在异常状态。
本申请实施例提供的数据库状态的确定方法，一方面，通过确定在所述数据库中执行的SQL语句；从信息数据库获取第一资源消耗信息，其中，所述第一资源消耗信息是通过在备用数据库上执行所述SQL语句而得到的所述备用数据库所在设备的资源消耗信息，这样，通过确定在数据库上执行的SQL语句，然后在备用数据库上回顾当前执行的SQL语句，获取备用数据库所在设备的资源消耗信息，从而确定所述SQL语句准确的资源消耗信息。如此，可以通过备用数据库串行的测试SQL语句的第一资源消耗信息，避免在原数据库上测试SQL语句时，因SQL语句并发执行共享公用设备资源而带来的第一资源消耗信息检测不准确的情况；并且，避免了在原数据库上测试SQL语句时，因锁机制而导致正常业务逻辑无法访问正在测试的数据，进而避免了测试SQL语句对业务逻辑的影响，保证了业务逻辑的正常运行。另一方面，根据所述第一资源消耗信息对所述SQL语句的消耗进行计算，得到资源消耗分值，这样，可以通过计算将所述SQL语句的消耗量化，并根据量化后的分值，准确找到资源消耗高的SQL语句，从而对所述数据库的运行状态进行准确的判断。
本申请实施例提供一种数据库状态的确定方法，图1B为本申请实施例数据库状态的确定方法的实现流程示意图，如图1B所示，该方法包括：
步骤S110，确定在所述数据库中执行的SQL语句；
步骤S120，从信息数据库获取第一资源消耗信息和第二资源消耗信息，其中，所述第一资源消耗信息是通过在备用数据库上执行所述SQL语句而得到的所述备用数据库所在设备的资源消耗信息，所述第二资源消耗信息是所述数据库的慢查询日志中记录的SQL语句的资源消耗信息；
这里，所述慢查询日志记录的内容是：在数据库中，例如MySQL中响应时间超过参数long_query_time(单位秒，默认值10)设置的值并且扫描记录数不小于min_examined_row_limit(默认值0)的SQL语句。举例说明，在MySQL中，当slow_query_log参数设置为ON，可以搜寻到时间超过慢查询定义的时间(即1S)SQL语句，当long_query_time执行后会浏览所有SQL语句，当某些SQL语句执行超过设定时间后，系统会自动的将该条语句记录到日志中。
在一些实施例中，所述第一资源消耗信息包括以下至少之一：设备的CPU使用率、IO使用率、网络流量使用情况、内存使用情况；所述第二资源消耗信息至少包括扫描行数。
这里，所述第二资源消耗信息将对所述第一资源消耗信息产生影响。例如，当所述扫描行数大于1000万行时，所述设备CPU使用率上升2％-10％。
步骤S130，根据所述第一资源消耗信息和所述第二资源消耗信息对所述SQL语句的消耗进行计算，得到资源消耗分值；
这里，根据所述第二资源消耗信息是否大于预设阈值，可以判断是否对所述第一资源消耗信息的数值进行调整。当需要调整时，可以根据调整后的所述第一资源消耗信息对所述SQL语句的消耗进行计算，得到资源消耗分值。
步骤S140，根据所述资源消耗分值确定所述数据库的运行状态。
本申请实施例提供的数据库状态的确定方法，通过从信息数据库获取第二资源消耗信息；并根据所述第一资源消耗信息和所述第二资源消耗信息对所述SQL语句的消耗进行计算。这样，可以充分考虑到所述第二资源消耗信息对所述第一资源消耗信息的影响，从而更为准确的确定所述第一资源消耗信息，进而能够更为准确的计算出当前SQL语句的资源消耗分值，提高判断所述数据库运行状态的准确性。
本申请实施例提供一种数据库状态的确定方法，图2A为本申请实施例数据库状态的确定方法的实现流程示意图，如图2A所示，该方法包括：
步骤S201，确定在所述数据库中执行的SQL语句；
步骤S202，从信息数据库获取第一资源消耗信息和第二资源消耗信息，其中，所述第一资源消耗信息是通过在备用数据库上执行所述SQL语句而得到的所述备用数据库所在设备的资源消耗信息，所述第二资源消耗信息是所述数据库的慢查询日志中记录的SQL语句的资源消耗信息；
在一些实施例中，所述第一资源消耗信息包括以下至少之一：设备的CPU使用率、IO使用率、网络流量使用情况、内存使用情况；所述第二资源消耗信息至少包括扫描行数。
步骤S203，获取已训练的资源能耗模型；
这里，根据所述资源能耗模型可以计算出SQL语句的资源消耗，将SQL语句的资源消耗分值化，从而根据分值判断一个SQL语句是否属于高消耗语句。
在一些实施例中，训练所述资源能耗模型包括：
步骤S2031，预设SQL语句消耗程度与分数值的对应关系；
这里，如表1所示，可以看出SQL语句消耗程度与分数值的对应关系。
表1SQL语句消耗程度与分数值的对应关系
分数(分) SQL语句消耗程度
>80 极高消耗
60～80 高消耗
40～60 中消耗
30～40 低消耗
<30分 极低消耗
这里，预设SQL语句消耗程度与分数值的对应关系可以根据分数判断一个SQL语句是否属于高消耗语句。
这里，单个设备例如服务器资源的利用率与SQL语句的消耗呈线性正相关，以CPU为例，虽然设备完全处于空闲状态，其能耗也会消耗最高能耗的10％。
步骤2032，根据慢查询日志中SQL语句的所述第一资源消耗信息和所述第二资源消耗信息，训练所述资源能耗模型；
这里，在所述根据慢查询日志中SQL语句的所述第一资源消耗信息和所述第二资源消耗信息，训练所述资源能耗模型之前，所述方法还包括：步骤2033，获取所述慢查询日志中SQL语句的所述第一资源消耗信息和所述第二资源消耗信息。这里，获取所述第一资源消耗信息可以通过在备用数据库上执行所述SQL语句时获取；获取所述第二资源消耗信息可以通过在慢查询日志中获取。
这里，所述慢查询日志中SQL语句成为高消耗SQL语句的概率较大，因此，采用所述慢查询日志中SQL语句的第一资源消耗信息和所述第二资源消耗信息训练所述资源能耗模型。
这里，判断所述第二资源消耗信息大于特定阈值时，为所述第一资源消耗信息增加偏移量，所述偏移量为2％-10％。例如，当所述扫描行数大于1000万行时，所述设备CPU使用率上升2％-10％。在实施过程中，首先，判断第二资源消耗信息是否大于特定阈值，在大于特定阈值的情况下，为所述第一资源消耗信息增加偏移量，然后，根据偏移后的所述第一资源消耗信息训练所述资源能耗模型。
这里，资源能耗模型包括公式(1)至公式(4)：
Figure BDA0002712687730000091
其中P(u)表示设备的能耗，k表示设备完全空闲时的能耗与最高能耗的百分比(如CPU的10％)，Pmax表示资源的最高能耗，u表示单个资源的利用率，所述单个资源可以为以下之一：CPU、IO、网络流量、内存。在实际环境中利用率在不同的时间有不同的取值，所以资源利用率可以用时间函数u(t)表示，E表示一定时间内SQL语句资源的总能耗，i表示某个单个资源(如CPU)，i大于等于1且小于等于n，n表示第n个单个资源，t0表示SQL语句执行的起始时间，t1表示SQL语句执行的结束时间。
通过线性回归分析，分析CPU、内存、磁盘IO和网络资源的利用率和SQL语句能耗之间的关系，得出线性多资源能耗模型，具体来说就是确定变量y与解释变量x之间的关系，如公式(2)所示：
y ＝ β0 + β1x1 + β2x2 + β3x3 + β4x4 (2)；
其中，y表示SQL语句的实际能耗，数值上等于公式(1)中计算出的E，β0、β1、β2、β3、β4为回归系数，x1、x2、x3、x4分别为CPU、内存、磁盘IO和网络资源的利用率，使用矩阵可以表示成公式(3)：
y＝ β0+ Xβ (3)；
其中：
Figure BDA0002712687730000101
合并得出以下SQL语句的能耗模型，如公式(4)所示：
E＝β0+β1*Ucpu+β2*Umem+β3*Udiskio+β4*Unet
(4)；
其中，E表示能耗，Ucpu表示CPU使用情况，Umem表示内存使用情况，Udiskio表示磁盘IO使用情况，Unet表示网络使用情况。该模型中各个参数都是基于实际生产使用过程中产生的大数据进行验证分析，能较为准确的计算出节点能耗。
这里，公式(2)与公式(4)的对应关系为：Ucpu->x1；Umem->x2；Udiskio->x3；Unet->x4。这里，所述参数取值可以为：β0->15；β1->0.2；
Figure BDA0002712687730000102
β3->0.5；
Figure BDA0002712687730000103
在一些实施例中，计算的所述β0、β1、β2、β3、β4的参数取值每一次都会有小范围波动，所述参数取值处于一个范围区间内，所述范围区间可以为在上述参数取值的基础上加减0.3。
步骤S204，根据所述第一资源消耗信息和所述第二资源消耗信息，按照所述资源能耗模型对所述SQL语句的消耗进行计算，得到资源消耗分值；
举例说明，图2B为本申请实施例采集到SQL语句获取的第一资源消耗信息和第二资源消耗信息的示意图，根据图2B所示，SQL1对应的第一资源消耗信息为：Ucpu->10；Umem->1；Udiskio->20；Unet->25；SQL1对应的第二资源消耗信息为：扫描行数->1；SQL2对应的第一资源消耗信息为：Ucpu->80；Umem->2；Udiskio->80；Unet->90；SQL2对应的第二资源消耗信息为：扫描行数->1000；SQL3对应的第一资源消耗信息为：Ucpu->10；Umem->4；Udiskio->20；Unet->49；SQL3对应的第二资源消耗信息为：扫描行数->10000；SQL4对应的第一资源消耗信息为：Ucpu->40；Umem->5；Udiskio->40；Unet->60；SQL4对应的第二资源消耗信息为：扫描行数->100000；SQL5对应的第一资源消耗信息为：Ucpu->60；Umem->7；Udiskio->60；Unet->70；SQL5对应的第二资源消耗信息为：扫描行数->1000000；SQL6对应的第一资源消耗信息为：Ucpu->80；Umem->10；Udiskio->80；Unet->89；SQL6对应的第二资源消耗信息为：扫描行数->10000000。
将上述数据代入公式(4)进行计算，可以得到对应的SQL语句的资源消耗分值：SQL1得分为28.58分为极低消耗语句；…；SQL5得分为73分，为高消耗语句；SQL6得分为82分，为极高消耗语句。
步骤S205，根据所述资源消耗分值确定所述数据库的运行状态。
本申请实施例提供的数据库状态的确定方法，通过根据所述第一资源消耗信息和所述第二资源消耗信息，按照所述资源能耗模型对所述SQL语句的消耗进行计算，得到资源消耗分值，这样，能够按照所述资源能耗模型，根据所述第一资源消耗信息和所述第二资源消耗信息，对当前在数据库中运行的SQL语句进行资源消耗的评分，提升了设备出现异常时及时展现并快速定位问题SQL语句的能力。
本申请实施例提供一种数据库状态的确定方法，图3A为本申请实施例数据库状态的确定方法的实现流程示意图，如图3A所示，该方法包括：
步骤S301，查询所述数据库的慢查询日志，得到在所述数据库中执行的SQL语句；
这里，可以通过设置备用数据库的long_query_time参数为0，得到当前SQL语句的执行情况。
步骤S302，在所述备用数据库上执行所述SQL语句，得到所述第一资源消耗信息；
这里，需要说明的是，不在原数据库上确定所述第一资源消耗信息的原因为：1)原数据库(数据库)由于存在实际的业务访问，同一时间存在多条语句在执行，统计语句的实际消耗无法精确；2)执行DML语句(Data Manipulation Language,数据操纵语言)，测试语句与正常运行语句分享相同的事务空间，锁竞争会导致的几乎乃至完全锁住的情况，完全无法访问表或者整个数据库；3)DDL语句(Data Definition Language，数据库模式定义语言)无法在原数据库上测试，因为DDL语句在数据库层面无法进行回滚。
这里，需要说明的是，采用备用数据库确定所述第一资源消耗信息的原因为：1)备用数据库中的数据与原数据库完全一致，且不存在实际的业务访问，完全的可以串行的测试SQL语句的具体消耗情况，不会影响实际的线上的业务；2)目前在相关技术中，进行在线的DDL操作的工作操作方式都类似：创建与原数据库结构一致的临时表，该临时表已经是按要求修改后的表结构了，缓慢增量的从原数据库中复制数据，同时记录原数据库的更改(所有的INSERT,DELETE,UPDATE操作)并应用到临时表。当工具确认表数据已经同步完成，它会进行替换工作，将临时表更名为原数据库。pt-online-schema-change，LHM和oak-online-alter-table这些工具都使用同步的方式，当原数据库有变更操作时利用一些事务的间隙时间将这些变化同步到临时表。通过工具使用异步的方式会将变更写入到changelog表中，然后重复的将changelog表的变更应用到临时表。所有的这些工具都使用触发器来识别原数据库的变更操作，但是此方式无法在备用数据库上使用的原因在于，触发器是以解释型代码的方式保存的。举例说明，MySQL不会预编译这些代码，会在每次的事务空间中被调用，它们被添加到被操作的表的每个查询行为之前的分析和解释器中。因此，备用数据库由于只是通过binlog日志进行同步，是无法使用触发器进行复制；3)修改表结构可以用于测试，或者用于评估负载开销。基于触发器的表结构修改操作只能通过基于语句复制的方式来进行，离原数据库操作还有一定的距离，不能真实的反映实际情况。4)为了提高DDL语句能在备用数据库上执行效率，可以采用无触发器的表复制机制，规避DDL语句测试后无法回滚的问题。
在一些实施例中，所述步骤S302，在所述备用数据库上执行所述SQL语句，得到所述第一资源消耗信息，包括：
步骤S3021A，连接备用数据库并创建复制表；
在实施过程中，可以通过调用SQL语句资源训练模块实现对备用数据库的连接。
步骤S3022A，拷贝数据到复制表；
这里，需要说明的是，在拷贝过程中如有新增数据，将通过备用数据库生成的binlog文件提炼出相关的DML操作，重新在复制表中进行重演。
步骤S3023A，对复制表进行数据库操作，以获得第一资源消耗信息；
这里，所述数据库操作为与原数据库一致的DDL操作，获得实际DDL操作的第一资源消耗信息；
步骤S3024A，删除复制表。
这里，需要说明的是，在复制表中获得第一资源消耗信息之后，需要删除复制表，恢复备用数据库环境，保持主备数据库的一致性。
这里，需要说明的是，采用步骤S3021A至步骤S3024A的方法得到所述第一资源消耗信息有以下优点：1)无触发器。在分析binlog日志的形式来监听表中的数据变更的情况下，工作模式是异步的，只有当原始表的更改被提交后才会将变更同步到临时表，而原来触发器的方案在原始表查询中共享相同的事务空间，查询原始表时，会出现竞争锁，产生触发器在另外一张表会独占竞争锁的情况。在这种情况下，同步方式的锁争夺直接关系到原数据库的并发写性能。在实际过程中，当竞争锁接近或者结束时，数据库可能会由于竞争锁而被阻塞住，导致其他业务逻辑无法访问被锁住的数据。触发锁在创建或销毁时需要元数据锁，创建或销毁都会有延时。例如，在频繁操作的表中，当表结构修改完成后，删除触发器可能需要数秒到分钟的时间。2)可测试。因为binlog日志文件和原数据库负载关系不大，因此，在原数据库上执行修改表结构的操作可以准确的体现出这些操作锁产生的影响。
在一些实施例中，所述步骤S302，在所述备用数据库上执行所述SQL语句，得到所述第一资源消耗信息，包括：
步骤S3021B，在停止所述备用数据库与所述数据库之间的同步操作的情况下，记录所述设备当前负载信息为第一负载信息；
这里，停止所述同步操作可以通过停止备用数据库的binlog同步线程实现；这里，在停止之后，可以通过操作系统命令获取所述设备的当前第一负载信息。这里，所述第一负载信息为第一时段的负载信息集合，例如，可以包括：CPU/IO等负载信息。
举例说明，当操作系统为LINUX时，可以采用系统命令iostat-mx 1获取此时备用数据库所在设备的第一负载信息，例如，CPU的负载L1，或，IO的负载P1。
步骤S3022B，在所述备用数据库上执行所述SQL语句，得到第二负载信息；
这里，所述第二负载信息为第二时段的负载信息集合，所述第二时段的起始时刻大于所述第一时段的结束时刻。
举例说明，在获得第一负载信息之后，在不同时段内，不断获取负载信息，例如，在不同时段内，分别获取CPU的负载L2、L3、L4、…、LN，或者，在不同时段内，分别获取IO的负载P2、P3、P4、…、PN。此时，所述第二负载信息为{{L2，L3，L4，…，LN}，{P2，P3，P4，…，PN}，…}。
这里，得到第二负载信息之后，设置通过设置参数autocommit＝0，实现不主动提交数据库操作，以在获取执行访问的SQL语句的元数据后，回滚SQL语句。这里，所述回滚的SQL语句可以为DML语句，例如，对数据的增删改查等操作。
步骤S3023B，根据所述第一负载信息和所述第二负载信息，确定所述第一资源消耗信息。
这里，所述第一资源消耗信息为资源消耗信息的集合。这里，所述第一资源消耗信息可以包括两类信息：1)系统负载信息；所述系统负载为一个集合，(CPU使用率，IO使用率，…)，例如，{{L1，L2，L3，L4，…，LN}，{P1，P2，P3，P4，…，PN}，…}。2)平均负载信息。例如，CPU的平均负载信息为：[(L2+L3+L4+…)-t1*L1]/t1，这里，所述第一负载信息由不同指标的平均负载信息组成，例如，图2B中的CPU＝10，表示通过[(L2+L3+L4+…)-t1*L1]/t1公式计算出的CPU平均负载为10，对应于CPU使用率为10％。
步骤S303，将所述第一资源消耗信息，录入所述信息数据库；
这里，所述信息数据库可以为SQL相关的配置数据库。
步骤S304，从信息数据库获取第一资源消耗信息，其中，所述第一资源消耗信息是通过在备用数据库上执行所述SQL语句而得到的所述备用数据库所在设备的资源消耗信息；
步骤S305，根据所述第一资源消耗信息对所述SQL语句的消耗进行计算，得到资源消耗分值；
步骤S306，根据所述资源消耗分值确定所述数据库的运行状态。
本申请实施例提供的数据库状态的确定方法，通过在备用数据库上执行所述SQL语句，得到所述第一资源消耗信息，这样，一方面，可以通过备用数据库串行的测试SQL语句的第一资源消耗信息，避免在原数据库上测试SQL语句时，因SQL语句并发执行共享公用设备资源而带来的第一资源消耗信息检测不准确的情况。另一方面，避免了在原数据库上测试SQL语句时，因锁机制而导致正常业务逻辑无法访问正在测试的数据，进而避免了测试SQL语句对业务逻辑的影响，保证了业务逻辑的正常运行。
本申请实施例提供一种数据库状态的确定方法，图3B为本申请实施例数据库状态的确定方法的实现流程示意图，如图3B所示，该方法包括：
步骤S310，从数据库网关层获得在所述数据库中执行的SQL语句；
步骤S320，在所述备用数据库上执行所述SQL语句，得到所述第一资源消耗信息；
在一些实施例中，所述步骤S320，在所述备用数据库上执行所述SQL语句，得到所述第一资源消耗信息，包括：步骤S331，在停止所述备用数据库与所述数据库之间的同步操作的情况下，记录所述设备的当前负载信息为第一负载信息；步骤S332，在所述备用数据库上执行所述SQL语句，得到第二负载信息；步骤S333，根据所述第一负载信息和所述第二负载信息，确定所述第一资源消耗信息。
步骤S330，将所述第一资源消耗信息，录入所述信息数据库；
这里，如果数据库所在的设备与所述备用数据库所在的设备不是同一设备的情况下，向所述备用数据库所在的设备发送所述SQL语句，以使得在所述备用数据库上执行所述SQL语句，得到所述第一资源消耗信息；然后数据库所在的设备从所述备用数据库所在的设备上获取第一资源消耗信息。
步骤S340，从信息数据库获取第一资源消耗信息，其中，所述第一资源消耗信息是通过在备用数据库上执行所述SQL语句而得到的所述备用数据库所在设备的资源消耗信息；
步骤S350，根据所述第一资源消耗信息对所述SQL语句的消耗进行计算，得到资源消耗分值；
步骤S360，根据所述资源消耗分值确定所述数据库的运行状态。
本申请实施例提供的数据库状态的确定方法，通过从数据库网关层获得在所述数据库中执行的SQL语句，解决了没有在慢查询日志里面的SQL语句的系统资源消耗信息无法确定的问题，增加了数据库状态确定的可靠性。
本申请实施例提供一种数据库状态的确定方法，该方法包括：
步骤S401，在检测到所述数据库的设备发生告警的情况下，将所述数据库当前执行的SQL语句确定为在所述数据库中执行的SQL语句；
这里，所述设备告警的情况可以为：设备的CPU，或者，IO使用率高于预先设定的阈值。这里，获取当前执行的SQL语句可以通过在所述数据库执行show processlist实现。
步骤S402，从信息数据库获取第一资源消耗信息，其中，所述第一资源消耗信息是通过在备用数据库上执行所述SQL语句而得到的所述备用数据库所在设备的资源消耗信息；
步骤S403，根据所述第一资源消耗信息对所述SQL语句的消耗进行计算，得到资源消耗分值；
步骤S404，在根据所述资源消耗分值确定所述数据库运行在异常状态的情况下，确定所述设备的告警原因是：所述数据库运行在异常状态。
在实施过程中，根据所述资源消耗分值大于预设的阈值，确定所述SQL语句为高消耗语句，所述数据库运行状态异常，所述设备告警。
在一些实施例中，所述方法还包括：步骤S405A，从信息数据库未获取到第一资源消耗信息和第二资源消耗信息的情况下，确定所述数据库运行在异常状态的原因是：所述数据库执行所述SQL语句。
举例说明，如果有存在的新执行的SQL语句没有在信息数据库中记录，则直接推送出来，大概率是新上的SQL语句导致的数据库运行异常。
在一些实施例中，所述方法还包括：步骤S405B，在所述资源消耗分值超过预先设定的阈值的情况下，确定所述数据库运行在异常状态；步骤S406B，确定导致所述数据库运行在异常状态的原因是：所述数据库执行所述SQL语句；步骤S407B，在所述资源消耗分值超过未预先设定的阈值的情况下，排除导致所述数据库运行在异常状态的原因是：所述数据库执行所述SQL语句。
举例说明，预设资源消耗分值大于60分时，所述SQL语句为高消耗语句，当计算得到的资源消耗分值为75分时，确定所述SQL语句为高消耗语句，确定所述设备的告警原因为：运行了当前的SQL语句后数据库运行状态异常。
在一些实施例中，所述方法还包括：步骤S405C，对比所述SQL语句的执行计划与执行所述SQL语句的实际顺序；步骤S406C，在所述SQL语句的执行计划与执行所述SQL语句的实际顺序不同的情况下，确定导致所述数据库运行在异常状态的原因是：所述数据库改变所述SQL语句的执行顺序；步骤S407C，在所述SQL语句的执行计划与执行所述SQL语句的实际顺序相同且存在未训练数据定义语言的情况下，确定导致所述数据库运行在异常状态的原因是：所述数据库中数据定义语言异常。
举例说明，经过计算确定无高消耗的语句后，则对比现存语句的执行计划情况。如果有执行计划发生改变的，确定导致所述数据库运行在异常状态的原因是：所述数据库改变所述SQL语句的执行顺序。
举例说明，如果无执行计划发生改变的，则大概率有执行了DDL(Data DefinitionLanguage,数据定义语言)，例如，删除一个数量级较高的表，导致CPU、IO等设备例如服务器资源突增。
在一些实施例中，所述方法还包括：步骤S408，推送异常信息。
举例说明，通过邮件、短信、微信、web前端展示等形式推送出来，帮助提升定位到异常问题的效率。
在一些实施例中，所述方法还包括：
步骤S41，确定在所述数据库中执行的SQL语句；
步骤S42，从信息数据库获取第一资源消耗信息和第二资源消耗信息，其中，所述第一资源消耗信息是通过在备用数据库上执行所述SQL语句而得到的所述备用数据库所在设备的资源消耗信息，所述第二资源消耗信息是所述数据库的慢查询日志中记录的SQL语句的资源消耗信息；
步骤S43，根据所述第一资源消耗信息和所述第二资源消耗信息对所述SQL语句的消耗进行计算，得到资源消耗分值；
步骤S44，在判断所述资源消耗分值大于预先设定的阈值的情况下，展示所述设备的预告警信息；
步骤S45，将所述资源消耗分支对应的SQL语句确定为核算SQL语句；
步骤S46，计算所述核算SQL语句的资源消耗分值，以防止误判；
步骤S47，判断所述核算SQL语句的资源消耗分值与所述预先设定的阈值的大小关系，以确定所述数据库的运行状态。
本申请实施例提供的数据库状态的确定方法，一方面，通过在检测到所述数据库的设备发生告警的情况下，确定在所述数据库中执行的SQL语句；这样，可以通过对所述服务的实时检测及时进行计算，从而及时发现数据库运行状态的异常，如此，可以避免相关技术中根据告警后，再登录数据库查询执行情况，提高了异常检测的效率。另一方面，通过对比所述SQL语句的执行计划与执行所述SQL语句的实际顺序；避免忽略因执行顺序导致的数据库状态，进而避免了异常确定时效的不可控，提高数据库状态的确定效率。
本申请实施例提供一种数据库状态的确定方法，图4为本申请实施例数据库状态的确定方法的实现流程示意图，如图4所示，该方法包括：
步骤S410，确定在所述数据库中执行的SQL语句；
这里，可以通过执行show processlist获取当前执行SQL语句。
在一些实施例中，所述当前执行SQL语句可以为至少两条，所述至少两条SQL语句，可以为对不同数据库中数据的操作，也可以为对同一数据库中不同表中数据的操作。
步骤S420，确定所述执行的SQL语句的指纹ID；
这里，所述指纹ID为根据执行SQL语句，转化成抽象的SQL语句后，对所述抽象的SQL语句进行加密，得到的字符串。这里，所述加密可以通过LINUX系统下md5sum工具实现。
这里，所述步骤S420，确定所述执行的SQL语句的指纹ID，包括：
步骤S421，对所述执行的SQL语句按照数据库标识进行分组；
这里，需要说明的是，登录任一数据库时，需要通过USE关键字+数据库名称，才能使用对应数据库。这里，需要说明的是，当两条执行相同操作的SQL查询不同的表时，由于查询的表中所包括的数据量的不同，可以会发生在一个数据库中，所述SQL为高负载高消耗的语句，但是，在另一个数据量较小的数据库中，所述SQL可能为低消耗语句。考虑到这一情况，在步骤S420，确定所述执行的SQL语句的指纹ID中，首先需要对所述执行的SQL语句按照数据库标识进行分组。
步骤S422，将分组后的SQL语句进行归一化，得到SQL指纹；
这里，所述分组后的SQL语句可能包括访问不同表的SQL语句。
这里，所述归一化可以包括以下之一：1)将多值INSERT语句缩短为单个VALUES()列表；2)去除SQL语句的注释；3)替换所有的文字；4)用单个空格字符替换连续空格字符；5)将整个查询的SQL语句转化为小写字符；6)用一个占位符替换IN()和VALUES()列表中的文字；7)将多个相同的UNION查询合并为一个查询。
这里，需要说明的是，以上步骤可以按顺序进行，也可以进行随机组合。
这里，替换所有的文字可以采用带引号的字符串进行替换，也可以采用其他数据类型进行替换，此处不作具体限定。这里，在进行文字替换的过程中，可以使用预定义替换规则，例如，将“NULL”被视为文字。例如，可以采用十六进制数据类型对文字进行替换，也可以采用其他类型数据对文字进行替换。
举例说明，在预定义替换规则为嵌入到标识符中的数字也被替换的情况下，类似名称的表将被指纹识别为相同的值，例如，users_2019和users_2020。
步骤S423，对所述SQL指纹进行加密，得到指纹ID。
举例说明，两个SQL语句分别为：1)SELECT name,password FROM user WHERE id＝'111111'；2)SELECT name,password FROM user WHERE id＝56。此时，可以将两个SQL语句抽象为：SELECT name,password FROM user WHERE id＝？，抽象后的SQL语句即为SQL指纹。经过LINUX系统下的md5sum工具将此SQL指纹转化为指纹ID：843421dd49ca87e126d8d7f1939a25b2。
步骤S430，根据所述指纹ID，查询所述信息数据库，得到所述第一资源消耗信息和第二资源消耗信息，其中，所述第一资源消耗信息是通过在备用数据库上执行所述SQL语句而得到的所述备用数据库所在设备的资源消耗信息，所述第二资源消耗信息是所述数据库的慢查询日志中记录的SQL语句的资源消耗信息；
这里，需要说明的是，所述指纹ID为所述信息数据库的主键，通过所述指纹ID可以在信息数据库快速获取所述第一资源消耗信息和第二资源消耗信息。
步骤S440，根据所述第一资源消耗信息和所述第二资源消耗信息对所述SQL语句的消耗进行计算，得到资源消耗分值；
步骤S450，根据所述资源消耗分值确定所述数据库的运行状态。
本申请实施例提供的数据库状态的确定方法，通过确定所述执行的SQL语句的指纹ID；根据所述指纹ID，查询所述信息数据库，得到所述第一资源消耗信息和第二资源消耗信息。这样，可以为查询所述第一资源消耗信息和第二资源消耗信息提供主键(指纹ID)，提高信息查询效率。
相关技术中，采用慢查询日志和show processlist定位的方法，实现高消耗语句的定位。1)根据慢查询日志定位。在所述运行结果中可以查看查询响应时间超过设定参数的SQL语句。MySQL的慢查询日志记录的内容是：在MySQL中响应时间超过参数long_query_time(单位秒，默认值10)设置的值并且扫描记录数不小于min_examined_row_limit(默认值0)的语句。当slow_query_log参数设置为ON，可以搜寻到时间超过慢查询定义的时间(即1S)SQL语句。参数long_query_time执行后会浏览所有SQL语句，当某些SQL语句执行超过设定时间后，系统会自动的将该条语句记录到日志中。所以，在慢查询日志中可以查询响应时间超过设定参数的SQL语句。2)使用show processlist定位，查询正在执行的慢查询。在实施例过程中，高消耗查询语句正在执行，已经导致数据库负载偏高了，而由于高消耗查询还没执行完，因此慢查询日志还看不到任何语句。此时，可以使用show processlist命令判断正在执行的会话情况。show processlist显示哪些线程正在运行。如果有PROCESS权限，则可以看到所有线程。否则，只能看到当前会话的线程。如果不使用FULL关键字，在info字段中只显示每个语句的前100个字符，如果想看语句的全部内容可以使用full修饰(showfull processlist)。在实施例过程中，可以通过它的执行时间是否大于1S来判断是否是慢查询SQL。
可以看出，相关技术中存在缺点：(1)使用查看慢查询日志协助定位：不具备实时性，需要SQL语句执行完才会记录到日志中。并且当一个高消耗且未执行完的语句在数据库中执行时，其它正常SQL语句的执行效率也会被影响，进而也成为慢查询被记录在慢查询日志中。若此时使用慢查询日志进行异常分析，则会出现南辕北辙，定位异常的方向错误的情况。(2)使用show processlist协助定位：当一个高消耗且未执行完的语句在数据库中执行时，其它正常SQL语句的执行效率也会被影响。此时得出的结果虽然能看到高消耗的语句在结果中，但是由于有成百上千个被影响的语句同时显示在屏幕中。在这些语句中，定位哪个语句才是真正的高消耗语句，经缺乏准确性和高效性，若采用杀死进程的方式进行确定会对现有业务逻辑产生影响。
由于相关技术定位高消耗语句的方式效率很低，且有一定的凭借经验和运气的技巧。普遍上认为高消耗语句等价于慢查询。然而，在系统资源已经完全被占用的情况下，会让一些原本效率很高的语句也成为慢查询，导致排查难度变大，难以准确的确定异常位置。
由此，本申请实施例提供一种数据库状态的确定方法，通过对慢查询日志以及实时SQL语句在备节点的回顾执行，获得其准确的资源消耗信息，并将所述资源消耗信息进行记录。最后，在异常发生时基于对异常SQL语句的消耗计算，进行准确的告警。
本申请实施例提供一种数据库状态的确定方法，图5A为本申请实施例数据库状态的确定方法的实现流程示意图，如图5A所示，该方法包括：
步骤S501，监控主数据库主机资源负载情况；
步骤S502，判断所述负载情况是否异常；
步骤S503，获取主数据库语句执行情况；
步骤S504，将所述执行情况存储至信息数据库；
步骤S505，获取SQL语句的元数据信息存储至信息数据库；
步骤S506，根据指纹ID从信息数据库读取负载信息；
步骤S507，根据所述负载信息定位异常SQL。
本申请实施例提供一种数据库状态的确定方法，该方法包括：
步骤S510，在检测到数据库所在的设备发生告警的情况下，获取当前执行的SQL语句；
这里，所述设备告警的情况可以为：设备的CPU，或者，IO使用率高于预先设定的阈值。这里，获取当前执行的SQL语句可以通过在所述数据库执行show processlist实现。
步骤S520，确定所述执行的SQL语句的指纹；
这里，所述指纹可以为根据所述执行的SQL语句转化成的抽象的SQL语句。
举例说明，所述执行的SQL语句为：SELECT name,password FROM user WHERE id＝'111111'，对应地，转化成的抽象的SQL语句为：SELECT name,password FROM userWHERE id＝？。
步骤S530，对所述指纹进行加密，得到指纹ID；
这里，加密可以通过md5sum工具实现。这里，所述指纹ID具有唯一性，是SQL语句的唯一标识ID。
步骤S540，根据所述指纹ID，查询资源消耗信息；
这里，所述资源消耗信息至少包括：第一资源消耗信息和第二资源消耗信息。所述资源消耗信息存储在信息数据库中，所述信息数据库的主键为所述指纹ID。所述信息数据库存储的数据至少包括：SQL的设备资源和数据库资源消耗信息。所述SQL的设备资源可以为：设备CPU使用率、IO使用率、网络流量使用情况、内存使用情况等；所述数据库资源消耗信息可以为：锁等待时间、扫描行数、SQL并发执行数量等。
这里，每一所述SQL的设备资源和数据库资源消耗信息在实际环境中的利用率在不同的时间有不同的取值，可以用时间函数u(t)表示。
这里，所述步骤S540中资源消耗信息的获取包括：
图5C为本申请实施例资源消耗信息的获取方法的实现流程示意图，如图5C所示，该方法包括：
步骤S541，调用SQL语句资源训练模块连接备用服务器中的备用数据库创建一个和服务器上的数据库中的原始表一样表结构的复制表。
步骤S542，将所述原始表中的数据拷贝到复制表；
这里，在将所述原始表中的数据拷贝到复制表的拷贝过程中，原始表的新增数据通过备用数据库的备用数据库生成的binlog文件通过提炼出与此表相关的DML操作，重新在复制表中进行重演。
步骤S543，对所述复制表进行与数据库一致的数据库操作，获得资源消耗信息；
举例说明，对所述复制表进行与数据库一致的DDL操作，获得实际DDL操作时，SQL语句对应的资源消耗信息。
这里，获得所述资源消耗信息需要首先获取访问数据库的SQL语句。获取数据的SQL语句可以通过以下两种方式：1)通过查询慢查询日志获取；2)在数据库的网关获取。其中，通过查询慢查询日志获取需要在主节点上访问慢查询日志，在无法查看慢查询日志，或没有慢查询日志时，采用在数据库的网关获取的方法进行SQL语句获取。
在一些实施例中，所述步骤S543，对所述复制表进行与数据库一致的数据库操作，获得资源消耗信息，包括：
图5B为本申请实施例获得资源消耗信息方法的实现流程示意图，如图5B所示，该方法包括：
步骤S5431，获得访问数据库的SQL的语句；
这里，在没有慢查询日志，或者，无法访问慢查询日志的情况下，可以通过数据库网关层获得访问数据库的SQL语句。
在一些实施例中，所述获得访问数据库的SQL的语句为：通过查询慢查询日志获取访问数据库的SQL的语句。
在另一些实施例中，所述获得访问数据库的SQL的语句为：在数据库的网关获取访问数据库的SQL的语句。
步骤S5432，记录所述SQL语句的执行情况；
这里，可以通过设置备用数据库的long_query_time参数为0实现记录所有SQL的执行情况。
步骤S5433，获取此时备用设备的负载信息；
这里，执行步骤S5433A之前，可以停止备用数据库的同步线程，例如，停止binlog同步线程，并使用LINUX操作系统命令iostat-mx 1获取此时备用数据库的设备的负载信息，例如，CPU/IO等，这里，所述单一负载信息在一段时间t1的资源消耗用L1表示。这里，需要计算出在t1时段内多种资源消耗。
步骤S5434，将所述系统负载和平均负载录入信息数据库；
这里，所述信息数据库可以为SQL相关的配置数据库。
这里，所述系统负载信息为t1时段内多种资源消耗，例如，CPU，IO，网络流量，内存利用率等，对应的标记为L1、L2、L3和L4。所述平均负载可以通过
Figure BDA0002712687730000251
计算，其中j表示第j种资源消耗，共有m种资源。
在所述步骤S5434之前，所述方法还包括步骤S54341，回滚SQL语句；
这里，可以通过在备用数据库设置参数autocommit＝0，以实现数据库操作不主动提交，这样，便于在获取执行访问的SQL语句的元数据后，回滚SQL语句，例如，回滚DML语句。
步骤S54342，计算SQL语句执行期间的系统负载和平均负载；步骤S5436，将所述系统负载和平均负载录入信息数据库；
这里，所述信息数据库可以为SQL相关的配置数据库。
步骤S544，最后把复制表删掉，恢复主备用数据库的主备用数据库环境。
步骤S550，利用所述资源消耗信息和资源能耗模型将SQL语句的资源消耗分值化；
这里，步骤S550中，所述利用所述资源消耗信息和资源能耗模型将SQL语句的资源消耗分值化，包括：
步骤S551，预设SQL语句消耗程度与分数值的对应关系；
这里，如表1所示，可以看出SQL语句消耗程度与分数值的对应关系。这里，预设SQL语句消耗程度与分数值的对应关系可以根据分数判断一个SQL语句是否属于高消耗语句。
这里，单个设备资源的利用率与SQL语句的消耗呈线性正相关，以CPU为例，虽然设备完全处于空闲状态，其能耗也会消耗最高能耗的10％。
步骤S552，根据所述资源消耗信息，确定语句消耗的资源；
这里，根据所述资源能耗模型可以计算出SQL语句的资源消耗，将SQL语句的资源消耗分值化，从而根据分值判断一个SQL语句是否属于高消耗语句。
这里，资源能耗模型包括公式(5)至公式(8)：
Figure BDA0002712687730000261
其中P(u)表示设备的能耗，k表示设备完全空闲时的能耗与最高能耗的百分比(如CPU的10％)，Pmax表示资源的最高能耗，u表示单个资源的利用率，所述单个资源可以为CPU，IO，网络流量和内存。在实际环境中利用率在不同的时间有不同的取值，所以资源利用率可以用时间函数u(t)表示，E表示一定时间内SQL语句资源的总能耗，i表示某个单个资源(如CPU)，i大于等于1且小于等于n，n表示第n个单个资源，t0表示SQL语句执行的起始时间，t1表示SQL语句执行的结束时间。
通过线性回归分析，分析CPU、内存、磁盘IO和网络资源的利用率和SQL语句能耗之间的关系，得出线性多资源能耗模型，具体来说就是确定变量y与解释变量x之间的关系，如公式(6)所示：
y＝β0+β1x1+β2x2+β3x3+β4x4 (6)；
其中，y表示SQL语句的实际能耗，数值上等于公式(5)中计算出的E，β0、β1、β2、β3、β4为回归系数，x1、x2、x3、x4分别为CPU、内存、磁盘IO和网络资源的利用率，使用矩阵可以表示成公式(7)：
y＝β0+Xβ (7)；
其中：
Figure BDA0002712687730000262
合并得出以下SQL语句的能耗模型，如公式(8)所示：
E＝15+0.2*Ucpu+(5.5e-2)*Umem+0.5*Udiskio+(4.2e-4)*Unet (8)；
其中E表示能耗，Ucpu表示CPU使用情况，Umem表示内存使用情况，Udiskio表示磁盘IO使用情况，Unet表示网络使用情况。该模型中各个参数都是基于实际生产使用过程中产生的大数据进行验证分析，能较为准确的计算出节点能耗。
代入数据，可知实例中的SQL语句可以推算出：
SQL1得分为28.58分为极低消耗语句；
…
SQL5得分为73分，为高消耗语句；
SQL6得分为82分，为极高消耗语句。
这里，在单个设备的情况下，设备资源的利用率与SQL语句的消耗呈线性正相关。所述设备资源可以为中央处理器(Central Processing Unit，CPU)的占用率。例如，在一个SQL语句A的CPU占用率为70％，另一个SQL语句B的CPU占用率为30％的情况下，语句A的消耗大于语句B。
步骤S560A，在所述资源消耗分值超过预先设定的阈值的情况下，确定超过所述阈值的SQL语句导致数据库异常。
在一些实施例中，所述方法还包括：步骤S560B，在检测到所述SQL语句的资源消耗信息未存储在信息数据库的情况下，确定所述SQL语句导致数据库异常。
在一些实施例中，所述方法还包括：步骤S560C，在所述资源消耗分值未超过预先设定的阈值的情况下，对比SQL语句的执行计划与实际执行顺序；
步骤S570C，在SQL语句的执行计划与实际执行顺序不同的情况下，确定执行顺序改变导致数据库异常。
在另一些实施例中，所述方法还包括：步骤S560D，在所述资源消耗分值未超过预先设定的阈值且执行计划与实际执行顺序相同的情况下，确定异常数据定义语言导致数据库异常。
这里，如果步骤S560A，步骤S570B，步骤S570C的异常情况都无出现，则异常可以是由于执行了DDL(Data Definition Language,数据定义语言)导致的，例如，删除一个数据量较大的表，导致CPU、IO等设备资源突增。
在一些实施例中，所述方法还包括：步骤S580，推送异常消息。
这里，可以通过邮件、短信、微信、web前端展示等形式推送异常消息，帮助提升定位到异常问题的效率。
基于前述的实施例，本申请实施例提供一种数据库状态的确定装置，该装置包括所包括的各单元、以及各单元所包括的各模块，可以通过数据库状态的确定设备中的处理器来实现；当然也可通过具体的逻辑电路实现；在实施的过程中，处理器可以为中央处理器(CPU)、微处理器(MPU)、数字信号处理器(DSP)或现场可编程门阵列(FPGA)等。
图6为本申请实施例数据库状态的确定装置的组成结构示意图，如图6所示，所述装置600包括第一确定模块601、第一获取模块602、计算模块603和第二确定模块604，其中：
第一确定模块601，用于确定在所述数据库中执行的SQL语句；
第一获取模块602，用于从信息数据库获取第一资源消耗信息，其中，所述第一资源消耗信息是通过在备用数据库上执行所述SQL语句而得到的所述备用数据库所在设备的资源消耗信息；
计算模块603，用于根据所述第一资源消耗信息对所述SQL语句的消耗进行计算，得到资源消耗分值；
第二确定模块604，用于根据所述资源消耗分值确定所述数据库的运行状态。
在一些实施例中，所述装置600，还包括第二获取模块，其中：第二获取模块，用于从信息数据库获取第二资源消耗信息，其中，所述第二资源消耗信息是所述数据库的慢查询日志中记录的SQL语句的资源消耗信息；所述计算模块603还用于根据所述第一资源消耗信息和所述第二资源消耗信息对所述SQL语句的消耗进行计算，得到资源消耗分值。
在一些实施例中，所述计算模块603包括获取单元和计算单元，其中：获取单元，用于获取已训练的资源能耗模型；计算单元，用于根据所述第一资源消耗信息和所述第二资源消耗信息，按照所述资源能耗模型对所述SQL语句的消耗进行计算，得到资源消耗分值。
在一些实施例中，所述第一确定模块601用于查询所述数据库的慢查询日志，得到在所述数据库中执行的SQL语句；所述装置600，还包括执行模块和录入模块，其中：执行模块，用于在所述备用数据库上执行所述SQL语句，得到所述第一资源消耗信息；录入模块，用于将所述第一资源消耗信息，录入所述信息数据库。
在一些实施例中，所述第一确定模块601，用于从数据库网关层获得在所述数据库中执行的SQL语句；对应地，所述装置600，还包括执行模块和录入模块，其中：执行模块，用于在所述备用数据库上执行所述SQL语句，得到所述第一资源消耗信息；录入模块，用于将所述第一资源消耗信息，录入所述信息数据库。
在一些实施例中，所述执行模块包括记录单元、获得单元和第一确定单元，其中：记录单元，用于在停止所述备用数据库与所述数据库之间的同步操作的情况下，记录所述设备的当前负载信息为第一负载信息；获得单元，用于在所述备用数据库上执行所述SQL语句，得到第二负载信息；第一确定单元，用于根据所述第一负载信息和所述第二负载信息，确定所述第一资源消耗信息。
在一些实施例中，所述装置600，还包括第三确定模块和第四确定模块，其中：第三确定模块，用于在检测到所述数据库的设备发生告警的情况下，将所述数据库当前执行的SQL语句确定为在所述数据库中执行的SQL语句；第四确定模块，用于在根据所述资源消耗分值确定所述数据库运行在异常状态的情况下，确定所述设备的告警原因是：所述数据库运行在异常状态。
在一些实施例中，所述第一获取模块602和所述第二获取模块包括第二确定单元和查询单元，其中：第二确定单元，用于确定所述执行的SQL语句的指纹ID；查询单元，用于根据所述指纹ID，查询所述信息数据库，得到所述第一资源消耗信息和第二资源消耗信息。
在一些实施例中，所述第四确定模块，还用于从信息数据库未获取到第一资源消耗信息和第二资源消耗信息的情况下，确定所述数据库运行在异常状态的原因是：所述数据库执行所述SQL语句。
在一些实施例中，所述第二确定模块604，还用于在所述资源消耗分值超过预先设定的阈值的情况下，确定所述数据库运行在异常状态；所述装置600，还包括第三确定单元和排除单元，其中：第三确定单元，用于确定导致所述数据库运行在异常状态的原因是：所述数据库执行所述SQL语句；排除单元，用于在所述资源消耗分值超过未预先设定的阈值的情况下，排除导致所述数据库运行在异常状态的原因是：所述数据库执行所述SQL语句。
在一些实施例中，在所述资源消耗分值未超过预先设定的阈值的情况下，所述装置还包括对比模块、第五确定模块和第六确定模块：对比模块，用于对比所述SQL语句的执行计划与执行所述SQL语句的实际顺序；第五确定模块，用于在所述SQL语句的执行计划与执行所述SQL语句的实际顺序不同的情况下，确定导致所述数据库运行在异常状态的原因是：所述数据库改变所述SQL语句的执行顺序；第六确定模块，用于在所述SQL语句的执行计划与执行所述SQL语句的实际顺序相同且存在未训练数据定义语言的情况下，确定导致所述数据库运行在异常状态的原因是：所述数据库中数据定义语言异常。
以上装置实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请装置实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。
需要说明的是，本申请实施例中，如果以软件功能模块的形式实现上述的数据库状态的确定方法，并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台数据库状态的确定设备(可以是个人计算机、服务器等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read Only Memory，ROM)、磁碟或者光盘等各种可以存储程序代码的介质。这样，本申请实施例不限制于任何特定的硬件和软件结合。
对应地，本申请实施例提供一种数据库状态的确定设备，包括存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述方法中的步骤。
对应地，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述方法中的步骤。
这里需要指出的是：以上存储介质和设备实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请存储介质和设备实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。
需要说明的是，图7为本申请实施例中数据库状态的确定设备的一种硬件实体示意图，如图7所示，该设备700的硬件实体包括：处理器701、通信接口702和存储器703，其中
处理器701通常控制设备700的总体操作。
通信接口702可以使设备通过网络与其他设备通信。
存储器703配置为存储由处理器701可执行的指令和应用，还可以缓存待处理器701以及设备700中各模块待处理或已经处理的数据(例如，图像数据、音频数据、语音通信数据和视频通信数据)，可以通过闪存(FLASH)或随机访问存储器(Random Access Memory，RAM)实现。
应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本申请的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。
需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。
上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元；既可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。
另外，在本申请各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。
本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(Read Only Memory，ROM)、磁碟或者光盘等各种可以存储程序代码的介质。
或者，本申请上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台设备(可以是个人计算机、服务器等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本申请的实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (14)

1.一种数据库状态的确定方法，其特征在于，所述方法包括：
确定在所述数据库中执行的SQL语句；
从信息数据库获取第一资源消耗信息，其中，所述第一资源消耗信息是通过在备用数据库上执行所述SQL语句而得到的所述备用数据库所在设备的资源消耗信息；
根据所述第一资源消耗信息对所述SQL语句的消耗进行计算，得到资源消耗分值；
根据所述资源消耗分值确定所述数据库的运行状态。
2.根据权利要求1所述的方法，其特征在于，所述方法还包括：
从信息数据库获取第二资源消耗信息，其中，所述第二资源消耗信息是所述数据库的慢查询日志中记录的SQL语句的资源消耗信息，所述第二资源消耗信息至少包括扫描行数；
对应地，所述根据所述第一资源消耗信息对所述SQL语句的消耗进行计算，得到资源消耗分值，包括：根据所述第一资源消耗信息和所述第二资源消耗信息对所述SQL语句的消耗进行计算，得到资源消耗分值；其中，所述第一资源消耗信息包括以下至少之一：设备CPU使用率、IO使用率、网络流量使用情况、内存使用情况。
3.根据权利要求2所述的方法，其特征在于，所述根据所述第一资源消耗信息和所述第二资源消耗信息对所述SQL语句的消耗进行计算，得到资源消耗分值，包括：
获取已训练的资源能耗模型；
根据所述第一资源消耗信息和所述第二资源消耗信息，按照所述资源能耗模型对所述SQL语句的消耗进行计算，得到资源消耗分值。
4.根据权利要求1所述的方法，其特征在于，所述确定在所述数据库中执行的SQL语句，包括：查询所述数据库的慢查询日志，得到在所述数据库中执行的SQL语句；
对应地，所述方法还包括：
在所述备用数据库上执行所述SQL语句，得到所述第一资源消耗信息；
将所述第一资源消耗信息，录入所述信息数据库。
5.根据权利要求1所述的方法，其特征在于，所述确定在所述数据库中执行的SQL语句，包括：
对应地，所述方法还包括：
在所述备用数据库上执行所述SQL语句，得到所述第一资源消耗信息；
将所述第一资源消耗信息，录入所述信息数据库。
6.根据权利要求4或5所述的方法，其特征在于，所述在所述备用数据库上执行所述SQL语句，得到所述第一资源消耗信息，包括：
在停止所述备用数据库与所述数据库之间的同步操作的情况下，记录所述设备的当前负载信息为第一负载信息；
在所述备用数据库上执行所述SQL语句，得到第二负载信息；
根据所述第一负载信息和所述第二负载信息，确定所述第一资源消耗信息。
7.根据权利要求1所述的方法，其特征在于，所述方法还包括：在检测到所述数据库的设备发生告警的情况下，将所述数据库当前执行的SQL语句确定为在所述数据库中执行的SQL语句；
对应地，所述方法还包括：
在根据所述资源消耗分值确定所述数据库运行在异常状态的情况下，确定所述设备的告警原因是：所述数据库运行在异常状态。
8.根据权利要求2所述的方法，其特征在于，所述从信息数据库获取第一资源消耗信息，从信息数据库获取第二资源消耗信息，包括：
确定所述执行的SQL语句的指纹ID；
根据所述指纹ID，查询所述信息数据库，得到所述第一资源消耗信息和第二资源消耗信息。
9.根据权利要求2或3或8所述的方法，其特征在于，所述方法还包括：
从信息数据库未获取到第一资源消耗信息和第二资源消耗信息的情况下，确定所述数据库运行在异常状态的原因是：所述数据库执行所述SQL语句。
10.根据权利要求1至5、或7至8任一项所述的方法，其特征在于，所述根据所述资源消耗分值确定所述数据库的运行状态，包括：在所述资源消耗分值超过预先设定的阈值的情况下，确定所述数据库运行在异常状态；
对应地，所述方法还包括：
确定导致所述数据库运行在异常状态的原因是：所述数据库执行所述SQL语句；
在所述资源消耗分值超过未预先设定的阈值的情况下，排除导致所述数据库运行在异常状态的原因是：所述数据库执行所述SQL语句。
11.根据权利要求10所述的方法，其特征在于，在所述资源消耗分值未超过预先设定的阈值的情况下，所述方法还包括：
对比所述SQL语句的执行计划与执行所述SQL语句的实际顺序；
在所述SQL语句的执行计划与执行所述SQL语句的实际顺序不同的情况下，确定导致所述数据库运行在异常状态的原因是：所述数据库改变所述SQL语句的执行顺序；
在所述SQL语句的执行计划与执行所述SQL语句的实际顺序相同且存在未训练数据定义语言的情况下，确定导致所述数据库运行在异常状态的原因是：所述数据库中数据定义语言异常。
12.一种数据库状态的确定装置，其特征在于，所述装置包括：
第一确定模块，用于确定在所述数据库中执行的SQL语句；
第一获取模块，用于从信息数据库获取第一资源消耗信息，其中，所述第一资源消耗信息是通过在备用数据库上执行所述SQL语句而得到的所述备用数据库所在设备的资源消耗信息；
计算模块，用于根据所述第一资源消耗信息对所述SQL语句的消耗进行计算，得到资源消耗分值；
第二确定模块，用于根据所述资源消耗分值确定所述数据库的运行状态。
13.一种数据库状态的确定设备，包括存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1至11任一项所述方法中的步骤。
14.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1至11任一项所述方法中的步骤。
CN202011062106.6A 2020-09-30 2020-09-30 一种数据库状态的确定方法及装置、设备、存储介质 Active CN112181840B (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202011062106.6A CN112181840B (zh) 2020-09-30 2020-09-30 一种数据库状态的确定方法及装置、设备、存储介质
PCT/CN2021/117017 WO2022068540A1 (zh) 2020-09-30 2021-09-07 一种数据库状态的确定方法及装置、设备、存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011062106.6A CN112181840B (zh) 2020-09-30 2020-09-30 一种数据库状态的确定方法及装置、设备、存储介质

Publications (2)

Publication Number Publication Date
CN112181840A true CN112181840A (zh) 2021-01-05
CN112181840B CN112181840B (zh) 2023-09-26

Family

ID=73948207

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011062106.6A Active CN112181840B (zh) 2020-09-30 2020-09-30 一种数据库状态的确定方法及装置、设备、存储介质

Country Status (2)

Country Link
CN (1) CN112181840B (zh)
WO (1) WO2022068540A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112765017A (zh) * 2021-01-08 2021-05-07 中国工商银行股份有限公司 基于MySQL数据库的数据查询性能测试方法和装置
WO2022068540A1 (zh) * 2020-09-30 2022-04-07 深圳前海微众银行股份有限公司 一种数据库状态的确定方法及装置、设备、存储介质
WO2022156647A1 (zh) * 2021-01-25 2022-07-28 华为技术有限公司 一种数据库管理方法及装置

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115941701B (zh) * 2022-10-13 2023-06-23 华能信息技术有限公司 一种基于微服务架构的动态配置方法
CN115658701B (zh) * 2022-12-27 2023-03-14 北京仁科互动网络技术有限公司 数据库流量控制方法、装置、设备及存储介质

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2293059A1 (en) * 1999-12-22 2001-06-22 Ibm Canada Limited-Ibm Canada Limitee Accommodation of data definition statements in the sharing of dynamic sql statements
CN105183614A (zh) * 2015-11-03 2015-12-23 华夏银行股份有限公司 一种数据库故障预测方法及装置
US20160078079A1 (en) * 2014-09-17 2016-03-17 Futurewei Technologies, Inc. Statement based migration for adaptively building and updating a column store database from a row store database based on query demands using disparate database systems
CN106649584A (zh) * 2016-11-18 2017-05-10 北京奇虎科技有限公司 一种主从式数据库系统中的索引处理方法和装置
CN108197306A (zh) * 2018-01-30 2018-06-22 平安科技（深圳）有限公司 Sql语句处理方法、装置、计算机设备和存储介质
US20190228008A1 (en) * 2016-09-28 2019-07-25 Ping An Technology (Shenzhen) Co., Ltd. Method, device, server and storage apparatus of reviewing sql
CN111352921A (zh) * 2020-02-19 2020-06-30 中国平安人寿保险股份有限公司 基于elk的慢查询监控方法、装置、计算机设备及存储介质

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6816874B1 (en) * 1999-09-10 2004-11-09 International Business Machines Corporation Method, system, and program for accessing performance data
CN110309171B (zh) * 2018-02-26 2021-08-20 华为技术有限公司 数据库查询方法、服务器和系统
CN109213664A (zh) * 2018-08-23 2019-01-15 北京小度信息科技有限公司 Sql语句的性能分析方法、装置、存储介质和电子设备
CN110362611B (zh) * 2019-07-12 2021-07-09 拉卡拉支付股份有限公司 一种数据库查询方法、装置、电子设备及存储介质
CN112181840B (zh) * 2020-09-30 2023-09-26 深圳前海微众银行股份有限公司 一种数据库状态的确定方法及装置、设备、存储介质

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2293059A1 (en) * 1999-12-22 2001-06-22 Ibm Canada Limited-Ibm Canada Limitee Accommodation of data definition statements in the sharing of dynamic sql statements
US20160078079A1 (en) * 2014-09-17 2016-03-17 Futurewei Technologies, Inc. Statement based migration for adaptively building and updating a column store database from a row store database based on query demands using disparate database systems
CN105183614A (zh) * 2015-11-03 2015-12-23 华夏银行股份有限公司 一种数据库故障预测方法及装置
US20190228008A1 (en) * 2016-09-28 2019-07-25 Ping An Technology (Shenzhen) Co., Ltd. Method, device, server and storage apparatus of reviewing sql
CN106649584A (zh) * 2016-11-18 2017-05-10 北京奇虎科技有限公司 一种主从式数据库系统中的索引处理方法和装置
CN108197306A (zh) * 2018-01-30 2018-06-22 平安科技（深圳）有限公司 Sql语句处理方法、装置、计算机设备和存储介质
CN111352921A (zh) * 2020-02-19 2020-06-30 中国平安人寿保险股份有限公司 基于elk的慢查询监控方法、装置、计算机设备及存储介质

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022068540A1 (zh) * 2020-09-30 2022-04-07 深圳前海微众银行股份有限公司 一种数据库状态的确定方法及装置、设备、存储介质
CN112765017A (zh) * 2021-01-08 2021-05-07 中国工商银行股份有限公司 基于MySQL数据库的数据查询性能测试方法和装置
WO2022156647A1 (zh) * 2021-01-25 2022-07-28 华为技术有限公司 一种数据库管理方法及装置

Also Published As

Publication number Publication date
CN112181840B (zh) 2023-09-26
WO2022068540A1 (zh) 2022-04-07

Similar Documents

Publication Publication Date Title
CN112181840B (zh) 一种数据库状态的确定方法及装置、设备、存储介质
CN110569214B (zh) 用于日志文件的索引构建方法、装置及电子设备
US10417265B2 (en) High performance parallel indexing for forensics and electronic discovery
US10521407B2 (en) Grouping of database objects
CN111881011A (zh) 日志管理方法、平台、服务器及存储介质
JP2003141075A (ja) ログ情報管理装置及びログ情報管理プログラム
GB2574282A (en) Data consistency verification method and system minimizing load of original database
CN113242157B (zh) 一种分布式处理环境下的集中式数据质量监测方法
US9998544B2 (en) Synchronization testing of active clustered servers
US20180032567A1 (en) Method and device for processing data blocks in a distributed database
CN110659282A (zh) 数据路由的构建方法、装置、计算机设备和存储介质
CN111159161A (zh) 基于etl规则的数据质量监控及预警系统和方法
WO2020228287A1 (zh) IoT-MQ 的消息存储方法、装置、计算机设备和存储介质
Sallam et al. Result-based detection of insider threats to relational databases
US8041687B2 (en) Dynamic generation of XML Schema for backend driven data validation
CN115329011A (zh) 数据模型的构建方法、数据查询的方法、装置及存储介质
US11023449B2 (en) Method and system to search logs that contain a massive number of entries
US10838947B2 (en) Consistency check for foreign key definition
CN114116733B (zh) 配电自动化系统数据异常操作检测和追溯系统及方法
CN111045869B (zh) 一种数据备份方法、装置及可读存储介质
Alabdulkarim et al. Polygraph: a plug-n-play framework to quantify anomalies
CN110874469A (zh) 数据库高危操作检测方法、装置、计算机设备和存储介质
US20220391751A1 (en) Uncertainty determination
CN114637736B (zh) 一种数据库拆分方法和装置
CN111814001B (zh) 反馈信息的方法和装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant