oracle-故障处理-如何通过相关视图分析数据库实时性能问题

简介:

排查思路

1. 查看数据库active session 的等待事件

  SELECT s.inst_id,s.wait_class, s.event, COUNT (*)
    FROM gv$session s
   WHERE status = 'ACTIVE'
GROUP BY s.inst_id,s.wait_class, s.event
ORDER BY 4 DESC;

2.查看active session 正在执行的sql

SELECT q.sql_text,
       q.sql_fulltext,
       s.sql_exec_start,
       s.sql_exec_id,
       s.sql_id,
       s.*
  FROM gv$session s, v$sql q
 WHERE s.sql_id = q.sql_id AND s.status = 'ACTIVE' AND s.TYPE = 'USER';

3.查看是否有锁等待

col sql_id for a20
col status for a10
col event for a40
col wait_class for a20
col program for a30

WITH s AS
 (SELECT * FROM gv$session)
SELECT LEVEL,
       lpad(' ', (LEVEL - 1) * 5, ' ') || nvl(s.username, '(oracle)') AS username,
       s.inst_id,
       s.sid,
       s.serial#,
       s.sql_id,
       s.status,
       s.event,
       s.blocking_session,
       s.wait_class,
       s.seconds_in_wait,
       --s.machine,
       --s.module,
       s.program 
       --,to_char(s.logon_time, 'YYYY-MM-DD HH24:MI:SS') AS logon_time
  FROM s
 WHERE LEVEL > 1
    OR EXISTS (SELECT 1 FROM s s2 WHERE s2.blocking_session = s.sid)
CONNECT BY PRIOR s.sid = s.blocking_session
 START WITH s.blocking_session IS NULL; 

4. 查看那些对象被锁住,被哪个session锁住,锁的类型,session正在执行的sql

  SELECT p.inst_id,
         p.spid,
         p.BACKGROUND,
         l.session_id sid,
         s.serial#,
         s.username,
         s.osuser,
         s.status,
         s.event,
         o.object_name,
         l.locked_mode,
         s.program,
         s.logon_time,
         s.sql_id
    FROM gv$process p,
         gv$locked_object l,
         dba_objects o,
         gv$session s
   WHERE     l.object_id = o.object_id
         AND l.session_id = s.sid
         AND p.addr = s.paddr
ORDER BY sid, s.serial#;

5. 查看访问某个对象(表、存储过程等)的Session:

select /*+rule+*/ s.inst_id,s.username,s.sid,s.serial#,s.event,s.sql_id,
 'alter system kill session ''' || s.sid || ',' || s.serial# || ',@' ||s.inst_id || ''' immediate;' kill_script  from gv$session s
 where s.sid in (select /*+rule */ SID  from  gv$access where object =upper('tableA')) and type='USER'; 

SELECT /*+ rule */
       DISTINCT
       s.inst_id,
       s.username,
       s.sid,
       s.serial#,
       s.status,
       s.event,
       s.sql_id,
       s.sql_exec_id,
       s.sql_exec_start,
        s.blocking_session,
       s.wait_class,
       s.seconds_in_wait,
       s.machine,
       s.module,
       s.program 
       ,to_char(s.logon_time, 'YYYY-MM-DD HH24:MI:SS') AS logon_time
       'alter system kill session ''' || s.sid || ',' || s.serial# || ',@' ||s.inst_id || ''' immediate;' kill_session_script,
       'kill -9 ' || p.spid kill_process_script
  FROM gv$session s, gv$access a, gv$process p
 WHERE     s.inst_id = a.inst_id
       AND s.sid = a.sid
       AND p.addr = s.paddr
       AND s.TYPE = 'USER'
       and a.object =upper('tableA')
       --  AND s.status = 'KILLED'
       -- AND s.username = 'userA'; 
<!-- 获得表、索引、视图、存储过程、函数的DDL

select dbms_metadata.get_ddl('TABLE','TABLE_NAME','TABLE_OWNER') from dual;
select dbms_metadata.get_ddl('INDEX','INDEX_NAME','INDEX_OWNER') from dual;
select dbms_metadata.get_ddl('VIEW','VIEW_NAME','VIEW_OWNER') from dual;
select dbms_metadata.get_ddl('PROCEDURE','PROCEDURE_NAME','PROCEDURE_OWNER') from dual;
select dbms_metadata.get_ddl('FUNCTION','FUNCTION_NAME','FUNCTION_OWNER') from dual;  -->

6. kill session

SELECT /*+ rule */
       DISTINCT
       s.inst_id,
       s.username,
       s.sid,
       s.serial#,
       s.status,
       s.event,
       s.sql_id,
       s.sql_exec_id,
       s.sql_exec_start,
       s.PLSQL_OBJECT_ID,
       s.PREV_EXEC_ID,
       s.PREV_EXEC_START,
       s.blocking_session,
       s.BLOCKING_INSTANCE,
       s.BLOCKING_SESSION_STATUS,    
       s.wait_class,
       s.seconds_in_wait,
       s.machine,
       s.module,
       s.program,
       p.spid,
       p.PGA_USED_MEM/1024/1024,
       p.PGA_ALLOC_MEM/1024/1024,
       p.PGA_MAX_MEM/1024/1024
       ,to_char(s.logon_time, 'YYYY-MM-DD HH24:MI:SS') AS logon_time,
       'alter system kill session ''' || s.sid || ',' || s.serial# || ',@' ||s.inst_id || ''' immediate;' kill_session_script,
       'kill -9 ' || p.spid kill_process_script
  FROM gv$session s,  gv$process p
 WHERE     s.inst_id = a.inst_id
       AND s.sid in (select /*+rule */ SID  from  gv$access where object =upper('tableA'))
       AND p.addr = s.paddr
       AND s.TYPE = 'USER'
       --  AND s.status = 'KILLED'
        AND s.username = 'userA';
目录
相关文章
|
10月前
|
缓存 关系型数据库 BI
使用MYSQL Report分析数据库性能(下)
使用MYSQL Report分析数据库性能
590 158
|
10月前
|
缓存 监控 关系型数据库
使用MYSQL Report分析数据库性能(中)
使用MYSQL Report分析数据库性能
632 156
|
10月前
|
缓存 监控 关系型数据库
使用MYSQL Report分析数据库性能(上)
最终建议:当前系统是完美的读密集型负载模型,优化重点应放在减少行读取量和提高数据定位效率。通过索引优化、分区策略和内存缓存,预期可降低30%的CPU负载,同时保持100%的缓冲池命中率。建议每百万次查询后刷新统计信息以持续优化
752 161
|
负载均衡 算法 关系型数据库
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
本文聚焦 MySQL 集群架构中的负载均衡算法,阐述其重要性。详细介绍轮询、加权轮询、最少连接、加权最少连接、随机、源地址哈希等常用算法,分析各自优缺点及适用场景。并提供 Java 语言代码实现示例,助力直观理解。文章结构清晰,语言通俗易懂,对理解和应用负载均衡算法具有实用价值和参考价值。
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
|
SQL 关系型数据库 数据库
【YashanDB知识库】OM仲裁节点故障后手工切换方案和yasom仲裁重新部署后重新纳管数据库集群方案
本文介绍了主备数据库集群的部署、OM仲裁故障切换及重新纳管的全过程。首先通过解压软件包并调整安装参数完成数据库集群部署,接着说明了在OM仲裁故障时的手动切换方案,包括关闭自动切换开关、登录备节点执行切换命令。最后详细描述了搭建新的yasom仲裁节点以重新纳管数据库集群的步骤,如生成配置文件、初始化进程、执行托管命令等,确保新旧系统无缝衔接,保障数据服务稳定性。
|
11月前
|
缓存 关系型数据库 MySQL
MySQL数据库性能调优:实用技术与策略
通过秉持以上的策略实施具体的优化措施,可以确保MySQL数据库的高效稳定运行。务必结合具体情况,动态调整优化策略,才能充分发挥数据库的性能潜力。
592 0
|
11月前
|
存储 人工智能 数据库
视图是什么?为什么要用视图呢?数据库视图:定义、特点与应用
本文三桥君深入探讨数据库视图的概念与应用,从定义特点到实际价值全面解析。视图作为虚拟表具备动态更新、简化查询、数据安全等优势,能实现多角度数据展示并保持数据库重构的灵活性。产品专家三桥君还分析了视图与基表关系、创建维护要点及性能影响,强调视图是提升数据库管理效率的重要工具。三桥君通过系统讲解,帮助读者掌握这一常被忽视却功能强大的数据库特性。
2661 0
|
SQL 关系型数据库 MySQL
如何优化SQL查询以提高数据库性能?
这篇文章以生动的比喻介绍了优化SQL查询的重要性及方法。它首先将未优化的SQL查询比作在自助餐厅贪多嚼不烂的行为,强调了只获取必要数据的必要性。接着,文章详细讲解了四种优化策略:**精简选择**(避免使用`SELECT *`)、**专业筛选**(利用`WHERE`缩小范围)、**高效联接**(索引和限制数据量)以及**使用索引**(加速搜索)。此外,还探讨了如何避免N+1查询问题、使用分页限制结果、理解执行计划以及定期维护数据库健康。通过这些技巧,可以显著提升数据库性能,让查询更高效流畅。
|
物联网 测试技术 API
时序数据库 InfluxDB 3.0 版本性能实测报告:写入吞吐量提升效果验证
TSBS 测试表明,对于少于 100 万台设备的数据集,InfluxDB OSS 3.0 的数据写入速度实际上比 InfluxDB OSS 1.8 更慢。 对于 100 万台及以上设备的数据集,InfluxDB OSS 3.0 的数据写入性能才开始超过 InfluxDB OSS 1.8。 InfluxDB OSS 3.0 的数据写入接口与 InfluxDB 1.8 并不兼容,用户无法顺利迁移。
1332 7

推荐镜像

更多