在某天晚上,业务人员把数据库迁至新库,通过数据泵导入导出这种方式迁至新库上。
新库与老库均为rac环境
在第二天上午,业务人员突然报说数据库处理单子的速度变的很慢,一上午压了2000个单子。
出现这种情况的原因有这么几种:
1.导数的时候没有导统计信息
2.表和索引的统计信息变了
3.是否产生了不同的计划任务
这里我就能想到这么三点,可能会有各种不同的问题,下面我们跟业务人员要一下跑的业务语句
select SERIAL_NUMBER,
ORD_NO,
USER_ID,
ACCNO,
ACTION_TYPE,
START_DATE,
RETURN_DATE,
RECONFIG_REASON,
DEAL_FLAG,
RETURN_CODE,
RETURN_DESC,
BACK_REASON,
LOGTIME,
CW_STATE,
CW_desc,
DL_STATE,
DL_DESC,
HD_FLAG,
ORDER_ID,
WORK_ORDER_ID
from (select *
from fwkt_new.tif_rs_info t2
where deal_flag = '0'
and rownum < 500
union
select *
from fwkt_new.tif_rs_info t
where deal_flag = '1'
and rownum < 80000);
以上是业务人员的处理单子的sql语句
拿到sql语句,我们首先分析下老库和新库的执行计划是否一致
老库的执行计划
新库的执行计划
对比两个库,执行计划两边完全一致,并没有说执行计划有变。
那这个问题出现在哪儿呢?
后来又有业务人员说登陆数据库慢,会不会是登录数据库慢导致业务处理的速度变慢了呢?
原来业务人员使用的是数据库连接地址是scan,用scan ip可以负载均衡,但是会产生大量的gc,还会导致闩锁的出现。所以让业务人员把scan ip禁掉,让应用使用vip去连接数据库
改完之后,数据库的处理速度有改善,但是处理速度改善的不是很明显,说明还是有问题,到底是什么问题导致数据库处理的速度变慢呢?
连接数据库慢,会不会是监听有问题导致的呢?
遂登陆grid用户查看监听信息
在这之间没有做截图,我口述一下吧!!!
lsnrctl status
发现节点1和节点2的监听注册信息不一致。
然后登陆数据库查看service_name
发现两边的service_name也不一致
更改数据库的service_name名称与节点1和节点2保持一致,并且节点1和节点2可以支持多个service_name的名称。
更改完毕,重新加载一下数据库的监听,并在数据库里面注册一下监听的信息。
所有操作完成之后,业务人员说积压的单子瞬间就没了。
至此,问题解决。
总结一下:
这究其原因就是oracle数据库里面的service_name不一致,导致监听的注册信息不一致,会导致数据库处理速度变慢,所以大家在改任何数据库参数的时候一定要小心谨慎。