CN106547860B - 一种分布式数据库性能故障的定位方法 - Google Patents

一种分布式数据库性能故障的定位方法 Download PDF

Info

Publication number
CN106547860B
CN106547860B CN201610921283.2A CN201610921283A CN106547860B CN 106547860 B CN106547860 B CN 106547860B CN 201610921283 A CN201610921283 A CN 201610921283A CN 106547860 B CN106547860 B CN 106547860B
Authority
CN
China
Prior art keywords
resource
distributed database
performance
positioning
use condition
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.)
Expired - Fee Related
Application number
CN201610921283.2A
Other languages
English (en)
Other versions
CN106547860A (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.)
Chang'an Communication Technology Co ltd
National Computer Network and Information Security Management Center
Original Assignee
Chang'an Communication Technology Co ltd
National Computer Network and Information Security Management Center
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 Chang'an Communication Technology Co ltd, National Computer Network and Information Security Management Center filed Critical Chang'an Communication Technology Co ltd
Priority to CN201610921283.2A priority Critical patent/CN106547860B/zh
Publication of CN106547860A publication Critical patent/CN106547860A/zh
Application granted granted Critical
Publication of CN106547860B publication Critical patent/CN106547860B/zh
Expired - Fee Related 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/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
    • 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/21—Design, administration or maintenance of databases

Landscapes

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

Abstract

本发明提供一种分布式数据库性能故障的定位方法，获取用户发出的SQL语句并定位SQL语句；在分布式数据库的节点中查找出存在性能故障的问题节点；比较问题节点与非问题节点的SQL语句的执行计划；查找并判断问题节点的资源使用情况；判断是否完成全部的问题节点的定位；检查并修正协调器的性能。本发明提出的方法极大的缩短了在分布式数据库环境下性能故障定位的时间，实现了对性能故障的有效且准确可靠地定位，进而减少了维护时间与成本，提高了分布式数据库的运行稳定性。

Description

一种分布式数据库性能故障的定位方法
技术领域
本发明涉及数据库优化领域，具体涉及一种分布式数据库性能故障的定位方法。
背景技术
近年来随着互联网和移动互联网的发展，企业存储的数据量成几何级数的增加，传统的数据库存储数据的方式变得越来越不实用，新的数据存储架构被发明出来。
分布式数据库存储架构师对传统单节点数据库的一种扩展，允许数据在更多节点上存储，同时对系统的业务逻辑不会产生太大的影响，是很多企业优先选择的一种大数据存储和处理的解决方案。
但是分布式数据库架构给运维人员带来了更多维护上的问题，最突出的一个就是分布式数据库性能问题的定位，由于用户的查询请求发生在多个数据库节点，当出现性能问题时，需要在多个节点上进行问题定位，这要比单台数据库上性能定位困难的多，这对于DBA来说，是一个很大的挑战，当MPP的节点越多，这种故障定位会越困难，目前行业里对于分布式数据库的性能定位方法研究很少。
因此，如何设计一种能有效定位分布式数据库性能故障的方法，是亟待解决的问题。
发明内容
有鉴于此，本发明提供的一种分布式数据库性能故障的定位方法，该方法极大的缩短了在分布式数据库环境下性能故障定位的时间，实现了对性能故障的有效且准确可靠地定位，进而减少了维护时间与成本，提高了分布式数据库的运行稳定性。
本发明的目的是通过以下技术方案实现的：
一种分布式数据库性能故障的定位方法，所述方法包括如下步骤：
步骤1.获取用户发出的SQL语句并定位所述SQL语句；
步骤2.在分布式数据库的节点中查找出存在性能故障的问题节点；
步骤3.比较所述问题节点与非问题节点的所述SQL语句的执行计划；
若所述执行计划不同，则修正性能故障，完成分布式数据库性能故障的定位；
若所述执行计划相同，进入步骤4；
步骤4.查找并判断所述问题节点的资源使用情况；
若资源使用情况没有资源问题，则进入步骤5；
若资源使用情况存在资源问题，则修正资源问题，完成分布式数据库性能故障的定位；
步骤5.判断是否完成全部的问题节点的定位；
若否，则返回步骤2；
若是，则检查并修正协调器的性能，完成分布式数据库性能故障的定位。
优选的，所述步骤1包括：
1-1.用户发出反馈操作问题的SQL语句；
1-2.从协调器日志中获取所述SQL语句；
1-3.分别登录到分布式数据库集群的每一台数据库，定位所述SQL语句。
优选的，所述步骤2包括：
2-1.用脚本的方式在分布式数据库的全部节点中查找出存在性能故障的问题节点；
2-2.在所述问题节点上查看所述SQL语句的执行计划。
优选的，所述步骤4包括：
4-1.查找并判断所述问题节点的资源使用情况；
若资源使用情况没有资源问题，则进入4-2；
若资源使用情况存在资源问题，则修正资源问题，完成分布式数据库性能故障的定位；
4-2.出具整体性能分析报告，并进入步骤5。
优选的，若当前分布式数据库的业务类型为OLTP，则所述4-1包括：
a.在业务类型为OLTP的当前分布式数据库中，查看所述问题节点的CPU、并发数指标及内存使用情况；
b.根据操作系统级别确定所述问题节点的资源使用情况是否存在资源问题；
若否，则进入4-2；
若是，则修正资源问题，完成分布式数据库性能故障的定位。
优选的，若当前分布式数据库的业务类型为OLAP，则所述4-1包括：
c.在业务类型为OLAP的当前分布式数据库中，查看所述问题节点的磁盘IO、网络IO及内存使用情况；
d.在操作系统中确定所述问题节点的资源使用情况是否存在资源问题；
若否，则进入4-2；
若是，则修正资源问题，完成分布式数据库性能故障的定位。
优选的，若当前分布式数据库的业务类型为OLTP与OLAP的混合型，则所述4-1包括：
e.在业务类型为OLTP与OLAP的混合型的当前分布式数据库中，比较所述问题节点的OLTP与OLAP资源占用量；
若OLTP的资源占用量大于OLAP的资源占用量，则进入f；
若OLAP的资源占用量大于OLTP的资源占用量，则进入h；
f.在业务类型为OLTP的当前分布式数据库中，查看所述问题节点的CPU、并发数指标及内存使用情况；
g.根据操作系统级别确定所述问题节点的资源使用情况是否存在资源问题；
若否，则进入4-2；
若是，则修正资源问题，完成分布式数据库性能故障的定位。
h.在业务类型为OLAP的当前分布式数据库中，查看所述问题节点的磁盘IO、网络IO及内存使用情况；
i.在操作系统中确定所述问题节点的资源使用情况是否存在资源问题；
若否，则进入4-2；
若是，则修正资源问题，完成分布式数据库性能故障的定位。
优选的，所述步骤5包括：
5-1.判断是否完成全部的问题节点的定位；
若否，则返回步骤2；
若是，则进入5-2；
5-2.查看协调器日志来获取协调器在合并汇总数据时的效率；
5-3.根据所述协调器在合并汇总数据时的效率值，得到所述协调器的性能；
5-4.判断所述协调器的性能；
若所述协调器存在性能问题，则修正优化性能问题，完成分布式数据库性能故障的定位，；
若所述协调器未存在性能问题，则判断为用户方的网络故障。
从上述的技术方案可以看出，本发明提供了一种分布式数据库性能故障的定位方法，获取用户发出的SQL语句并定位SQL语句；在分布式数据库的节点中查找出存在性能故障的问题节点；比较问题节点与非问题节点的SQL语句的执行计划；查找并判断问题节点的资源使用情况；判断是否完成全部的问题节点的定位；检查并修正协调器的性能。本发明提出的方法极大的缩短了在分布式数据库环境下性能故障定位的时间，实现了对性能故障的有效且准确可靠地定位，进而减少了维护时间与成本，提高了分布式数据库的运行稳定性。
与最接近的现有技术比，本发明提供的技术方案具有以下优异效果：
1、本发明所提供的技术方案中，获取用户发出的SQL语句并定位SQL语句；在分布式数据库的节点中查找出存在性能故障的问题节点；比较问题节点与非问题节点的SQL语句的执行计划；查找并判断问题节点的资源使用情况；判断是否完成全部的问题节点的定位；检查并修正协调器的性能。极大的缩短了在分布式数据库环境下性能故障定位的时间。
2、本发明所提供的技术方案，实现了对性能故障的有效且准确可靠地定位，进而减少了维护时间与成本，提高了分布式数据库的运行稳定性。
3、本发明提供的技术方案，应用广泛，具有显著的社会效益和经济效益。
附图说明
图1是本发明的一种分布式数据库性能故障的定位方法的流程图；
图2是本发明的定位方法中步骤1的流程示意图；
图3是本发明的定位方法中步骤2的流程示意图；
图4是本发明的定位方法中步骤4的流程示意图；
图5是本发明的定位方法中步骤5的流程示意图；
图6是本发明的一种分布式数据库性能故障的定位方法的具体应用例中的定位流程示意图；
图7是是本发明的具体应用例中的优化流程示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
如图1所示，本发明提供一种分布式数据库性能故障的定位方法，包括如下步骤：
步骤1.获取用户发出的SQL语句并定位SQL语句；
步骤2.在分布式数据库的节点中查找出存在性能故障的问题节点；
步骤3.比较问题节点与非问题节点的SQL语句的执行计划；
若执行计划不同，则修正性能故障，完成分布式数据库性能故障的定位；
若执行计划相同，进入步骤4；
步骤4.查找并判断问题节点的资源使用情况；
若资源使用情况没有资源问题，则进入步骤5；
若资源使用情况存在资源问题，则修正资源问题，完成分布式数据库性能故障的定位；
步骤5.判断是否完成全部的问题节点的定位；
若否，则返回步骤2；
若是，则检查并修正协调器的性能，完成分布式数据库性能故障的定位。
如图2所示，步骤1包括：
1-1.用户发出反馈操作问题的SQL语句；
1-2.从协调器日志中获取SQL语句；
1-3.分别登录到分布式数据库集群的每一台数据库，定位SQL语句。
如图3所示，步骤2包括：
2-1.用脚本的方式在分布式数据库的全部节点中查找出存在性能故障的问题节点；
2-2.在问题节点上查看SQL语句的执行计划。
如图4所示，步骤4包括：
4-1.查找并判断问题节点的资源使用情况；
若资源使用情况没有资源问题，则进入4-2；
若资源使用情况存在资源问题，则修正资源问题，完成分布式数据库性能故障的定位；
4-2.出具整体性能分析报告，并进入步骤5。
其中，若当前分布式数据库的业务类型为OLTP，则4-1包括：
a.在业务类型为OLTP的当前分布式数据库中，查看问题节点的CPU、并发数指标及内存使用情况；
b.根据操作系统级别确定问题节点的资源使用情况是否存在问题；
若否，则进入4-2；
若是，则修正问题，完成分布式数据库性能故障的定位。
其中，若当前分布式数据库的业务类型为OLAP，则4-1包括：
c.在业务类型为OLAP的当前分布式数据库中，查看问题节点的磁盘IO、网络IO及内存使用情况；
d.在操作系统中确定问题节点的资源使用情况是否存在问题；
若否，则进入4-2；
若是，则修正问题，完成分布式数据库性能故障的定位。
其中，若当前分布式数据库的业务类型为OLTP与OLAP的混合型，则4-1包括：
e.在业务类型为OLTP与OLAP的混合型的当前分布式数据库中，比较问题节点的OLTP与OLAP资源占用量；
若OLTP的资源占用量大于OLAP的资源占用量，则进入f；
若OLAP的资源占用量大于OLTP的资源占用量，则进入h；
f.在业务类型为OLTP的当前分布式数据库中，查看问题节点的CPU、并发数指标及内存使用情况；
g.根据操作系统级别确定问题节点的资源使用情况是否存在资源问题；
若否，则进入4-2；
若是，则修正资源问题，完成分布式数据库性能故障的定位。
h.在业务类型为OLAP的当前分布式数据库中，查看问题节点的磁盘IO、网络IO及内存使用情况；
i.在操作系统中确定问题节点的资源使用情况是否存在资源问题；
若否，则进入4-2；
若是，则修正资源问题，完成分布式数据库性能故障的定位。
如图5所示，步骤5包括：
5-1.判断是否完成全部的问题节点的定位；
若否，则返回步骤2；
若是，则进入5-2；
5-2.查看协调器日志来获取协调器在合并汇总数据时的效率；
5-3.根据协调器在合并汇总数据时的效率值，得到协调器的性能；
5-4.判断协调器的性能；
若协调器存在性能问题，则修正优化性能问题，完成分布式数据库性能故障的定位，；
若协调器未存在性能问题，则判断为用户方的网络故障。
本发明提供一种分布式数据库性能故障的定位方法的具体应用例，如下：
一、定位：
如图6所示，当出现性能问题时，我们按照如下思路和方法来定位性能问题：
1)从协调器日志中获取用户发出的SQL语句：
2)分别登录到分布式数据库集群的每一台数据库上，通过如下方法定位到该语句：
Select*from v$SQL where sql_text like‘％SQL关键字％’；
关于分别在每台数据库中获取SQL以及执行计划的操作，可以通过脚本的方式一次性的从所有节点上获取到，这样节省了工程师的操作时间。
3)确定出哪些节点SQL执行速度缓慢。
4)在有性能问题的节点上查看该SQL的执行计划：
通过关联V$SQL和v$SQL_PLAN可以找到该SQL的执行计划。
5)将性能差节点上的SQL执行计划和性能好节点的SQL执行计划作比较，看看执行计划是否改变。
如果执行计划改变，需要工程师仔细分析执行计划改变的原因，这不是本专利设计的问题。
如果执行计划并未改变，需要进一步查看性能问题节点的资源使用情况：
6)用top查看CPU和内存使用情况，iostat查看IO资源使用情况。
7)还可以通过做一个AWR报告来进一步为数据库做一次整体性能分析。
8)如果排除所有节点数据库性能问题，则需要进一步检查协调器的性能问题；可以通过查看协调器的日志来获取协调器在合并汇总数据时的效率。
二、优化：
1、数据库性能来自于系统资源的争用，定位资源瓶颈是数据库性能优化最核心的指导思想。
2、确定数据库上承载的业务类型。如图7所示，从数据库的角度来看，通常把数据库承载的业务分成三类，OLTP，OLAP以及二者的混合体，确定业务类型，对后续的性能分析具有的方向标作用。
3、下面列出三种类型数据库的资源定位思路:
a)OLTP指交易非常频繁的业务系统，此业务类型的数据库资源瓶颈多发生在CPU上，以及内存中各种程序资源的争用等环节。
我们通过top，free等命令，来看到系统的CPU，内存的使用情况，从操作系统级别确定系统的资源瓶颈。内存不足通常是由于业务繁忙，服务器需要分配更多的内存在存放处理的数据；CPU繁忙也说明的业务的放慢，CPU需要大量的计算。接着，我们可以对数据库做一个性能分析报告，以Oracle数据库为例，可以做一个AWR性能报告，以便于确定哪些SQL语句消耗了最多的内存或者CPU,从而对这些SQL进行分析优化，使之达到最优性能的程度。
并发数是OLTP类型系统最应该关注的指标，大并发会直接导致系统资源耗尽，通过在数据库服务器上使用netstat–an命令可以查看当前系统的链接数，同时在数据库层面也可以查看当前有哪些连接在操作数据库，以Oracle数据库为例，可以通过以下命令：
Select*v$session
来查看数据库中的所有链接已经它们消耗的资源情况。
b)OLAP通常是数据仓库类型业务系统，此业务类型的数据库，由于处理的数据量大，资源瓶颈多发生在磁盘IO，网络IO,内存等环节。
通过watch|iostat命令，可以从操作系统观察到系统IO负载情况，当确认操作系统的IO比较大时，可以进一步在数据库中分析哪些SQL占用了大量的IO,方法和上面一样，对数据库做一个性能分析报告，以Oracle为例，可以做一个AWR性能分析报告，AWR报告中可以很容易找到消耗IO最多的SQL语句，技术人员拿到这些语句后进行分析优化，减少对IO资源的使用。
c)OLTP和OLAP混合型业务系统，此类业务兼有OLTP和OLAP业务类型的特点，因此在a,b部分介绍的资源瓶颈，在此中业务类型中都会存在，应该确定两种业务中那种对资源的消耗更大，然后根据a，b的原则去确定资源瓶颈所在。
通过以上思路，确定数据库的资源瓶颈所在，然后实施有针对性的解决方案，具体技术细节不属于本文论述范围，不再赘述。
5)通过有瓶颈的资源，找到“肇事者”：
就一台数据库本身而言，它不存在性能问题，数据库的性能下降，都是由它上面运行的业务施加给它的，业务是通过执行SQL把性能问题带给了数据库，因此所有性能问题，都是由运行的SQL引起的，通过深入分析SQL运行过程中对各种资源的消耗情况，可以判断出那些SQL对系统性能造成了影响。
6)对SQL性能的评估：
a)评价一条SQL执行的效率，需要遵顼一下两个原则：
并不是执行时间长的SQL就需要优化。
很多人看到执行时间长的SQL就想要优化它，这是比较片面的，因为SQL是处理数据的语言，处理数据就需要时间，当数据量很大从而要使用更多的系统资源时，本身就是需要时间的。
b)SQL执行快慢都是相对的：
根据a段的结论，一条SQL执行慢，并不足以断定它存在性能问题，只有对这条SQL多次执行结果进行纵向对比，才能确定某次SQL执行的效率是否异常，来决定是否需要优化。
7)性能优化的程度的判定：
性能优化需要一个尺度的把握，需要遵守两个原则：
(1)只要处理数据，就需要消耗时间；
(2)优化的同时，考虑成本的投入。
原则一强调的是性能优化的度，不能毫无根据的追求处理速度更快，需要明白，数据处理总是需要时间的，即使再快的设备，再优化的程序，处理数据都需要时间，随着处理数据量的增大，处理数据的时间都会同样的增加。
原则二强调的是优化成本，要通盘考虑优化造成的成本增加，比如更换更快的磁盘，增加更多的内存，重新编写程序代码等成本，性能优化永远是企业范畴的事情，不是一个纯粹科研课题，要全面考虑优化带来的性能提升和成本投入的平衡，达到一个最佳平衡点。
以上实施例仅用以说明本发明的技术方案而非对其限制，尽管参照上述实施例对本发明进行了详细的说明，所属领域的普通技术人员依然可以对本发明的具体实施方式进行修改或者等同替换，而这些未脱离本发明精神和范围的任何修改或者等同替换，其均在申请待批的本发明的权利要求保护范围之内。

Claims (8)

1.一种分布式数据库性能故障的定位方法，其特征在于，所述方法包括如下步骤：
步骤1.获取用户发出的SQL语句并定位所述SQL语句；
步骤2.在分布式数据库的节点中查找出存在性能故障的问题节点；
步骤3.比较所述问题节点与非问题节点的所述SQL语句的执行计划；
若所述执行计划不同，则修正性能故障，完成分布式数据库性能故障的定位；
若所述执行计划相同，进入步骤4；
步骤4.查找并判断所述问题节点的资源使用情况；
若资源使用情况没有资源问题，则进入步骤5；
若资源使用情况存在资源问题，则修正资源问题，完成分布式数据库性能故障的定位；
步骤5.判断是否完成全部的问题节点的定位；
若否，则返回步骤2；
若是，则检查并修正协调器的性能，完成分布式数据库性能故障的定位。
2.如权利要求1所述的方法，其特征在于，所述步骤1包括：
1-1.用户发出反馈操作问题的SQL语句；
1-2.从协调器日志中获取所述SQL语句；
1-3.分别登录到分布式数据库集群的每一台数据库，定位所述SQL语句。
3.如权利要求1所述的方法，其特征在于，所述步骤2包括：
2-1.用脚本的方式在分布式数据库的全部节点中查找出存在性能故障的问题节点；2-2.在所述问题节点上查看所述SQL语句的执行计划。
4.如权利要求1所述的方法，其特征在于，所述步骤4包括：
4-1.查找并判断所述问题节点的资源使用情况；
若资源使用情况没有资源问题，则进入4-2；
若资源使用情况存在资源问题，则修正资源问题，完成分布式数据库性能故障的定位；
4-2.出具整体性能分析报告，并进入步骤5。
5.如权利要求4所述的方法，其特征在于，若当前分布式数据库的业务类型为OLTP，则所述4-1包括：
a.在业务类型为OLTP的当前分布式数据库中，查看所述问题节点的CPU、并发数指标及内存使用情况；
b.根据操作系统的资源使用情况确定所述问题节点的资源使用情况是否存在资源问题；
若否，则进入4-2；
若是，则修正资源问题，完成分布式数据库性能故障的定位。
6.如权利要求4所述的方法，其特征在于，若当前分布式数据库的业务类型为OLAP，则所述4-1包括：
c.在业务类型为OLAP的当前分布式数据库中，查看所述问题节点的磁盘IO、网络IO及内存使用情况；
d.在操作系统中确定所述问题节点的资源使用情况是否存在资源问题；
若否，则进入4-2；
若是，则修正资源问题，完成分布式数据库性能故障的定位。
7.如权利要求4所述的方法，其特征在于，若当前分布式数据库的业务类型为OLTP与OLAP的混合型，则所述4-1包括：
e.在业务类型为OLTP与OLAP的混合型的当前分布式数据库中，比较所述问题节点的OLTP与OLAP资源占用量；
若OLTP的资源占用量大于OLAP的资源占用量，则进入f；
若OLAP的资源占用量大于OLTP的资源占用量，则进入h；
f.在业务类型为OLTP的当前分布式数据库中，查看所述问题节点的CPU、并发数指标及内存使用情况；
g.根据操作系统的资源使用情况确定所述问题节点的资源使用情况是否存在资源问题；
若否，则进入4-2；
若是，则修正资源问题，完成分布式数据库性能故障的定位；
h.在业务类型为OLAP的当前分布式数据库中，查看所述问题节点的磁盘IO、网络IO及内存使用情况；
i.在操作系统中确定所述问题节点的资源使用情况是否存在资源问题；
若否，则进入4-2；
若是，则修正资源问题，完成分布式数据库性能故障的定位。
8.如权利要求1所述的方法，其特征在于，所述步骤5包括：
5-1.判断是否完成全部的问题节点的定位；
若否，则返回步骤2；
若是，则进入5-2；
5-2.查看协调器日志来获取协调器在合并汇总数据时的效率；
5-3.根据所述协调器在合并汇总数据时的效率值，得到所述协调器的性能；
5-4.判断所述协调器的性能；
若所述协调器存在性能问题，则修正优化性能问题，完成分布式数据库性能故障的定位；
若所述协调器未存在性能问题，则判断为用户方的网络故障。
CN201610921283.2A 2016-10-21 2016-10-21 一种分布式数据库性能故障的定位方法 Expired - Fee Related CN106547860B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201610921283.2A CN106547860B (zh) 2016-10-21 2016-10-21 一种分布式数据库性能故障的定位方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610921283.2A CN106547860B (zh) 2016-10-21 2016-10-21 一种分布式数据库性能故障的定位方法

Publications (2)

Publication Number Publication Date
CN106547860A CN106547860A (zh) 2017-03-29
CN106547860B true CN106547860B (zh) 2020-06-02

Family

ID=58392161

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610921283.2A Expired - Fee Related CN106547860B (zh) 2016-10-21 2016-10-21 一种分布式数据库性能故障的定位方法

Country Status (1)

Country Link
CN (1) CN106547860B (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110764981A (zh) * 2019-09-09 2020-02-07 北京新数科技有限公司 一种it机房的一体化运维管理方法及装置
CN110750512A (zh) * 2019-09-09 2020-02-04 北京新数科技有限公司 一种数据库性能评价管理方法及装置
CN113886205A (zh) * 2021-09-28 2022-01-04 招商银行股份有限公司 数据库性能瓶颈定位分析方法、装置、系统及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1383514A (zh) * 2000-04-07 2002-12-04 联合想象计算机公司 直观管理网络计算机系统的方法和装置
CN101395602A (zh) * 2005-12-29 2009-03-25 亚马逊科技公司 用于分布式文件存储和索引服务的方法和装置
CN101453398A (zh) * 2007-12-06 2009-06-10 怀特威盛软件公司 一种新型分布式网格超级计算系统及方法
CN101763389A (zh) * 2008-12-23 2010-06-30 中兴通讯股份有限公司 一种数据库资源的调控装置及方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1383514A (zh) * 2000-04-07 2002-12-04 联合想象计算机公司 直观管理网络计算机系统的方法和装置
CN101395602A (zh) * 2005-12-29 2009-03-25 亚马逊科技公司 用于分布式文件存储和索引服务的方法和装置
CN101453398A (zh) * 2007-12-06 2009-06-10 怀特威盛软件公司 一种新型分布式网格超级计算系统及方法
CN101763389A (zh) * 2008-12-23 2010-06-30 中兴通讯股份有限公司 一种数据库资源的调控装置及方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ORACLE数据库性能问题查找方法探讨;黄晖;《计算技术与信息发展》;20100629(第4期);第61-62页 *

Also Published As

Publication number Publication date
CN106547860A (zh) 2017-03-29

Similar Documents

Publication Publication Date Title
US10642832B1 (en) Reducing the domain of a subquery by retrieving constraints from the outer query
Aboutorabiª et al. Performance evaluation of SQL and MongoDB databases for big e-commerce data
US9996558B2 (en) Method and system for accessing a set of data tables in a source database
US9946750B2 (en) Estimating statistics for generating execution plans for database queries
CN103176974B (zh) 优化数据库中访问路径的方法和装置
CN111539633A (zh) 一种业务数据质量的稽核方法、系统、装置和存储介质
CN106547860B (zh) 一种分布式数据库性能故障的定位方法
CN108694221B (zh) 数据实时分析方法、模块、设备和装置
US9355147B2 (en) Access plan for a database query
US20200081903A1 (en) Splitting transaction and analysis queries
CN104778185A (zh) 异常结构化查询语言sql语句确定方法及服务器
CN105808588B (zh) 基于众包模型的分布式定向垂直信息搜索系统和方法
CN103631788A (zh) 基于共享数据库的车辆制造质量问题诊断系统
US20210201909A1 (en) Index suggestion engine for relational databases
CN105683941A (zh) 调节企业数据仓库资源使用
US20140089255A1 (en) Foreign key identification in database management systems
CN108255852B (zh) Sql执行方法及装置
CN110377519B (zh) 大数据系统的性能容量测试方法、装置、设备及存储介质
CN115335821A (zh) 卸载统计收集
CN107644382A (zh) 保单信息统计方法和装置
US8548980B2 (en) Accelerating queries based on exact knowledge of specific rows satisfying local conditions
CN115329011A (zh) 数据模型的构建方法、数据查询的方法、装置及存储介质
CN108932258A (zh) 数据索引处理方法及装置
US7725461B2 (en) Management of statistical views in a database system
CN112199401B (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
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20200602

Termination date: 20201021

CF01 Termination of patent right due to non-payment of annual fee