营销型网站模板下载,wordpress网站特别慢,wordpress 图床,贺兰县住房和城乡建设局网站问题#xff1a; 用户的数据库在某个时间段出现连接数异常上涨问题#xff0c;时间持续5分钟左右#xff0c;并且问题期间应用无法正常连接请求数据库 从连接数的监控上可以看到数据库平常峰值不到100个连接#xff0c;在问题时间段突然上涨到400以上 问题分析#xff1a;…问题 用户的数据库在某个时间段出现连接数异常上涨问题时间持续5分钟左右并且问题期间应用无法正常连接请求数据库 从连接数的监控上可以看到数据库平常峰值不到100个连接在问题时间段突然上涨到400以上 问题分析 首先查询数据库当前节点的历史使用最大连接数以及process参数的配置推算问题时间段数据库的连接数是否已经达到上限从而导致应用无法正常连接请求数据库
---手动创建快照确保负载数据写入历史ash
exec dbms_workload_repository.create_snapshot();
---查询process参数历史最大值
select b.instance_number,b.begin_interval_time,b.end_interval_time,a.RESOURCE_NAME,a.CURRENT_UTILIZATION,a.MAX_UTILIZATION,a.LIMIT_VALUE from DBA_HIST_RESOURCE_LIMIT a,dba_hist_snapshot b where a.snap_idb.snap_id and a.dbidb.dbid and a.resource_name in(processes,sessions) and a.instance_numberb.instance_numberand b.begin_interval_timeto_date(2023/11/27 12:00:00,yyyy/mm/dd hh24:mi:ss) and b.begin_interval_timeto_date(2023/11/27 15:30:00,yyyy/mm/dd hh24:mi:ss)order by b.instance_number,b.begin_interval_time; 可以看到数据库的历史最大连接数为669数据库参数process配置为1500alert日志页没看到ORA-00020:maximum number of processes (xxx) exceeded的报错也就是说问题时间段数据库的连接数并没有达到上限询问用户应用的连接池配置得到回复是连接池最大连接为500低于数据库的历史最大连接数为669因此连接数异常上涨期间应用无法正常请求连接数据库的原因应该为数据库出现连接堆积导致应用连接池连接耗尽无法正常请求连接数据库 接下来分析数据库连接出现堆积上涨的原因查看问题时间段ASH里面的等等事件情况通过等待事件评估可能的原因以及下一步的分析方向
---查看某个时间段的等待事件数量
select event,count(*)
from v$active_session_history a
where sample_time between timestamp 2023-11-27 14:20:00 and timestamp 2023-11-27 14:25:00
group by event;
;
---查看某个等待事件的每分钟数量
select to_char(sample_time,yyyy-mm-dd hh24:mi),event,count(*)
from v$active_session_history a
where sample_time between timestamp 2023-11-27 14:20:00 and timestamp 2023-11-27 14:25:00 and eventlibrary cache pin
group by to_char(sample_time,yyyy-mm-dd hh24:mi),event
order by 1;
可以看到问题时间段数据库等待事件library cache pin在5分钟内出现了54885次等待短时间内出现这么高的等待肯定是有问题的并且从等待事件的类型以及经验来看极有可能是由于存储过程函数这类PL/SQL对象被某个会话独占持有所导致 注library cache pin等待一般是指会话在shared pool共享池里面申请对library cache库缓存对象(比如函数存储过程包)进行访问调用时(pin)由于该对象正在被独占访问或是有会话正在申请独占访问这时会话需要等待独占会话的释放期间出现的等待事件就是library cache pin等待 查看是否有直接的堵塞会话指向sid,可以看到大部份的会话的堵塞会话blocking_session都是空的没有看到直接的堵塞源只有出现少量的堵塞会话sid:2133,1516
select blocking_session,blocking_session_serial#,count(*)
from v$active_session_history a
where sample_time between timestamp 2023-11-27 14:20:00 and timestamp 2023-11-27 14:25:00 and eventlibrary cache pin
group by blocking_session,blocking_session_serial#
order by 3 查看被堵塞的会话执行的语句分析TOP 3的语句调用情况
select sql_id,count(*)
from v$active_session_history a
where sample_time between timestamp 2023-11-27 14:20:00 and timestamp 2023-11-27 14:25:00 and eventlibrary cache pin
group by sql_id
order by 2; 可以看到TOP前3个语句都同时调用了包app_interface_pkg这说明library cache pin的争用发生在包app_interface_pkg 接下来继续分析包是否发生了修改、编译或者重建这种需要获取独占模式的操作以及执行的会话 查看包app_interface_pkg最近一次的ddl时间以及创建时间并没有发现在问题时间段以及近期有发生过修改、编译或者重建的操作OS难道分析错方向先不管继续往下
alter session set nls_date_formatyyyy-mm-dd hh24:mi:ss;
select object_id,object_name,created,last_ddl_time
from dba_objects
where object_nameAPP_INTERFACE_PKG; 查看问题时间段所有会话的操作类型有一个重大的发现里面出现了CREATE PACKAGE创建包的独占模式操作
alter session set nls_date_formatyyyy-mm-dd hh24:mi:ss;
col machine for a20
select SQL_OPNAME,count(*)
from v$active_session_history a
where sample_time between timestamp 2023-11-27 13:20:00 and timestamp 2023-11-27 14:22:00
group by SQL_OPNAME; 查看这个执行CREATE PACKAGE的会话可以看到这个会话一执行就开始出现大面积的library cache pin等待这个会话一消失library cache pin等待也跟着消失并且执行的操作应该是没有成功的因为当时正在业务高峰期包一直被其他会话所调用这导致从开始到结束会话一直是在等待library cache pin去获取独占模式而等待的会话分别是我们之前查到的sid:2133,1516这也刚好解释了为什么之前看到包最近一次的ddl时间以及创建时间都没有发生过修改
alter session set nls_date_formatyyyy-mm-dd hh24:mi:ss;
col machine for a20
select sample_time,a.SESSION_ID, sql_id,blocking_session,blocking_session_serial#,event,SQL_OPNAME
from v$active_session_history a
where sample_time between timestamp 2023-11-27 14:27:04 and timestamp 2023-11-27 14:27:06
order by sample_time; 到这里问题已经变得清晰在问题时间段有会话执行了对包app_interface_pkg的CREATE PACKAGE操作对该包的library cache申请了独占模式导致后续调用该包的会话都出现了library cache pin等待最终引发了数据库会话连接堆积应用连接池连接耗尽无法正常请求连接数据库
问题解决 虽然通过sql_id没有查到具体的执行语句文本但从会话的执行程序pl/sql developer可以基本确认是人为执行的语句将会话查到的机器名交给用户进行进一步的查找后续得到确认在问题时间段应用运维人员确实是对包app_interface_pkg执行了编译的操作所导致 所以切记生产无小事三思而后行。
