ESTDB数据库2020/4/29下午16点附近出现业务卡顿现象。
可以发现问题SQL为(SQL_ID fr0nhywcycrsa)。占问题时段数据库资源消耗的52.69%，通过对此SQL语句的执行效率进行分析，我们发现：
对SQL_ID fr0nhywcycrsa?进行分析，可以发现此SQL存在执行速度快、慢等不同效率的SQL。通常对于此类问题可以使用SQL绑定执行计划的方法来解决。
在进行执行计划绑定后发现存在SQL未使用绑定的执行计划的情况。使用SQLHC工具进行分析，可以发现原因是数据库中存在P1BEMADM及P1FEMADM两个用户，SQL_ID fr0nhywcycrsa两个用户均在执行，即两个用户使用了相同的SQL语句。
绑定执行的原理是使SQL在执行时比如访问A1索引再到B1表的这样的过程，但是两个用户下存在索引名称不一致问题，这时在绑定执行计划时就出现了AAA用户下绑定成功，BBB用户在执行时存在无法找到A1索引问题。
同时同时两个用户下相同名称、结构的表还存在数据量巨大差异、索引名称及建索引的列不一致问题，在不同数据量时会存在使用不同执行计划时效率更好的问题，导致在绑定执行计划时无法找到一个合适的执行计划。
排查步骤如下：
1、数据库集群的基本配置信息
TESTDB系统数据库使用了Oracle RAC架构，使用了HPUX+11.2.0.4版本两节点RAC数据库，业务程序禁用了RAC的负载均衡，主要连接在数据库节点1上进行业务操作。
2.2 故障时段数据库的信息
2.2.1 性能分析(AWR/ASH报告)
由于15点到16点之间问题出现频繁，故主要以该时间段的AWR进行分析，可以发现TOP SQLfr0nhywcycrsa占用较多的CPU资源。
在故障时间段的AWR报告中，可以看到CPU使用率在平均65%左右，主要的资源消耗在看到在SQL_ID fr0nhywcycrsa，占比52%。在下面章节对此SQL执行效率进行分析。
2.2.2 问题SQL的分析
对SQL_ID fr0nhywcycrsa?进行分析，可以发现此SQL存在执行速度快、慢等不同效率的SQL。通常对于此类问题可以使用SQL绑定执行计划的方法来解决。
在进行执行计划绑定后发现存在SQL未使用绑定的执行计划的情况。使用SQLHC工具进行分析，可以发现原因是数据库中存在P1BEMADM及P1FEMADM两个用户，SQL_ID fr0nhywcycrsa两个用户均在执行，即两个用户使用了相同的SQL语句。
绑定执行的原理是使SQL在执行时比如访问A1索引再到B1表的这样的过程，但是两个用户下存在索引名称不一致问题，这时在绑定执行计划时就出现了AAA用户下绑定成功，BBB用户在执行时存在无法找到A1索引问题。
同时两个用户下相同名称、结构的表还存在数据量巨大差异的问题。
两个用户SQL执行效率以及IOT表上相关索引信息如下：
SQL不同执行计划对应的执行速度：
IOT表上索引情况：
IOT表上的数据差异：
三、总结建议与后续处理方案
3.1 故障总结分析
通过分析4/29日下午问题时段的数据，可以发现问题SQL为(SQL_ID fr0nhywcycrsa)。占问题时段数据库资源消耗的52.69%，通过对此SQL语句的执行效率进行分析，我们发现：
对SQL_ID fr0nhywcycrsa?进行分析，可以发现此SQL存在执行速度快、慢等不同效率的SQL。通常对于此类问题可以使用SQL绑定执行计划的方法来解决。
在进行执行计划绑定后发现存在SQL未使用绑定的执行计划的情况。使用SQLHC工具进行分析，可以发现原因是数据库中存在P1BEMADM及P1FEMADM两个用户，SQL_ID fr0nhywcycrsa两个用户均在执行，即两个用户使用了相同的SQL语句。
绑定执行的原理是使SQL在执行时比如访问A1索引再到B1表的这样的过程，但是两个用户下存在索引名称不一致问题，这时在绑定执行计划时就出现了AAA用户下绑定成功，BBB用户在执行时存在无法找到A1索引问题。
同时同时两个用户下相同名称、结构的表还存在数据量巨大差异、索引名称及建索引的列不一致问题，在不同数据量时会存在使用不同执行计划时效率更好的问题，导致在绑定执行计划时无法找到一个合适的执行计划。
3.2优化建议
1.目前由于P1BEMADM用户数据量大，执行效率较差主要集中在此处，因此建议首先对P1BEMADM用户下此SQL相关表及索引进行碎片整理、重建等，从底层数据存储层面进行优化；其次对于此SQL，建议进行优化后再进行SQL执行计划的绑定，保持优化后的SQL执行效率高效、稳定。