11g v$active_session_history的新增列

简介: 很多知识我都还停留在10g,今天同事在ASH中直接就找到了SQL语句消耗的PGA,才发现,11gR2的ASH多了如此多的列1.标示这条ASH记录是否被刷入了磁盘  IS_AWR_SAMPLE                 dba_hist_active_sess_history中就没有这一列2.
很多知识我都还停留在10g,今天同事在ASH中直接就找到了SQL语句消耗的PGA,才发现,11gR2的ASH多了如此多的列

1.标示这条ASH记录是否被刷入了磁盘
  IS_AWR_SAMPLE                 dba_hist_active_sess_history中就没有这一列

2.SQL语句信息  
  SQL_OPNAME                    SQL_OPCODE的翻译名,SQL语句类型
 
3.对于递归SQL,捕获其父SQL的信息
  TOP_LEVEL_SQL_ID     
  TOP_LEVEL_SQL_OPCODE
 
  可以通过这个列,找到存过中最消耗资源的SQL,或者DDL递归调用中,最慢得SQL语句
  SELECT sql_id,count(*) FROM v$active_session_history
  WHERE TOP_LEVEL_SQL_ID='5w6mc35fa18tk'
  GROUP BY sql_id
  ORDER BY 2 DESC; 
 

4.在ASH中捕获执行计划信息,包括这个语句正在执行哪一步操作 
  SQL_PLAN_LINE_ID                                  
  SQL_PLAN_OPERATION                              
  SQL_PLAN_OPTIONS    
 
  可以通过这些列,找到SQL语句最慢得地方,就需要优化这个                            
    SELECT A.SQL_PLAN_HASH_VALUE,
           A.SQL_PLAN_LINE_ID,
           A.SQL_PLAN_OPERATION,
           A.SQL_PLAN_OPTIONS,
           B.OWNER || '.' || B.OBJECT_NAME OBJECT_NAME,
           COUNT(*)
      FROM V$ACTIVE_SESSION_HISTORY A, DBA_OBJECTS B
     WHERE A.SQL_ID = '11jpuymjh9vsc'
       AND A.CURRENT_OBJ# = B.OBJECT_ID(+)
     GROUP BY A.SQL_PLAN_HASH_VALUE,
          A.SQL_PLAN_LINE_ID,
          A.SQL_PLAN_OPERATION,
          A.SQL_PLAN_OPTIONS,
          B.OWNER || '.' || B.OBJECT_NAME
     ORDER BY COUNT(*) DESC; 


5.SQL一次执行的唯一标示符,  SQL_ID, SQL_EXEC_START, SQL_EXEC_ID 三列来标示一次SQL的执行
  并且,可以找到这次SQL的开始执行时间,以及计算出其这次已经执行了多少时间
  SQL_EXEC_ID                                       
  SQL_EXEC_START    
 
  判断一下一个SQL,有没有出现执行的很慢的时候,比如平时1s,有段时间,执行超过12s
    SELECT SQL_ID, SQL_EXEC_START, SQL_EXEC_ID, COUNT(*)
      FROM V$ACTIVE_SESSION_HISTORY A
     WHERE A.SQL_ID = '11jpuymjh9vsc'
     GROUP BY SQL_ID, SQL_EXEC_START, SQL_EXEC_ID
     ORDER BY COUNT(*) DESC                                 

6.并行增强,增加了QC_SESSION_SERIAL# 列,并且增加了PX_FLAGS状态列
  QC_SESSION_SERIAL#                                
  PX_FLAGS         
 
  QC_SESSION_ID <> SESSION_ID 的,都是并行子进程。增加了QC_SESSION_SERIAL#可以定义到唯一的一个协调者
 
7.Blocking增强,11g通过Blocking解决问题已经很容易了
  BLOCKING_INST_ID                    11g新增,怪的很,10g的v$session有该列,但是ASH没有
  BLOCKING_HANGCHAIN_INFO        指出BLOCKING_SESSION是否在hang chain上
  REMOTE_INSTANCE#          用于集群等待,标明需要请求的数据块应该由那个实例提供。只有cluster类等待才有这个
 
8.当前处理的对象,新增了一个row# ,以前已经有CURRENT_OBJ#,CURRENT_FILE#,CURRENT_BLOCK#了
  CURRENT_ROW#                                    

    可以检查TX等待柱塞的行,通过拼装ROWID可以找到柱塞的行。
    SELECT A.SQL_ID,
           A.CURRENT_OBJ#,
           A.CURRENT_FILE#,
           A.CURRENT_BLOCK#,
           A.CURRENT_ROW#,
           COUNT(*)
      FROM dba_hist_active_sess_history A
     WHERE A.EVENT = 'enq: TX - row lock contention'
     GROUP BY A.SQL_ID,
          A.CURRENT_OBJ#,
          A.CURRENT_FILE#,
          A.CURRENT_BLOCK#,
          A.CURRENT_ROW#
     ORDER BY COUNT(*) DESC

9.CONSUMER_GROUP
  CONSUMER_GROUP_ID,DBA_RSRC_CONSUMER_GROUPS对应                                 

10.Time Mobel
   TIME_MODEL             后面的IN,按照二进制组合起来的值,在这次采样间隔内,会话做了那些操作
   IN_CONNECTION_MGMT     connection management call elapsed time
   IN_PARSE               parse time elapsed
   IN_HARD_PARSE          hard parse elapsed time
   IN_SQL_EXECUTION       sql execute elapsed time
   IN_PLSQL_EXECUTION     PL/SQL execution elapsed time
   IN_PLSQL_RPC           inbound PL/SQL rpc elapsed time
   IN_PLSQL_COMPILATION   PL/SQL compilation elapsed time
   IN_JAVA_EXECUTION      Java execution elapsed time
   IN_BIND                repeated bind elapsed time
   IN_CURSOR_CLOSE       
   IN_SEQUENCE_LOAD       sequence load elapsed time
  
   当AWR中显示某个TM存在问题时,通过这些列,找到TOP 进程或者SQL
   存在硬解析的SQL,结果应该和v$sql去比较下
        SELECT SQL_PLAN_HASH_VALUE, COUNT(*)
          FROM V$ACTIVE_SESSION_HISTORY
         WHERE IN_HARD_PARSE = 'Y'
         GROUP BY SQL_PLAN_HASH_VALUE
         ORDER BY 2 DESC  
  
11.REPLAY特性的会话标示
   REPLAY_OVERHEAD       
   IS_REPLAYED           
   DBREPLAY_FILE_ID      
   DBREPLAY_CALL_COUNTER 

12.时间统计
   TM_DELTA_TIME         一次统计间隔
   TM_DELTA_CPU_TIME     在这个间隔内,CPU时间
   TM_DELTA_DB_TIME      在这个间隔内,DB时间
  
   因为ASH采样的粒度是1秒,但是进程并不是在1s内都ACTIVE的。该统计的粒度是微秒(百万分之一秒)
   TM_DELTA_TIME - TM_DELTA_DB_TIME = INACTIVE TIME
   TM_DELTA_DB_ TIME - TM_DELTA_CPU_TIME = WAIT TIME

13.IO网络统计,
   DELTA_TIME                          
   DELTA_READ_IO_REQUESTS              
   DELTA_WRITE_IO_REQUESTS             
   DELTA_READ_IO_BYTES                 
   DELTA_WRITE_IO_BYTES                
   DELTA_INTERCONNECT_IO_BYTES         

   统计时间内,物理读/写/心跳流量高的SQL
        SELECT SQL_ID,
               SUM(DELTA_READ_IO_REQUESTS),
               SUM(DELTA_WRITE_IO_REQUESTS),
               SUM(DELTA_READ_IO_BYTES),
               SUM(DELTA_WRITE_IO_BYTES),
               SUM(DELTA_INTERCONNECT_IO_BYTES)
          FROM V$ACTIVE_SESSION_HISTORY
         GROUP BY SQL_ID
         ORDER BY 2 DESC

14.PGA/TMP当前使用统计 
   PGA_ALLOCATED       
   TEMP_SPACE_ALLOCATED  

   select * from (
   select sample_time,session_id,sql_id,PGA_ALLOCATED,TEMP_SPACE_ALLOCATED from v$active_session_history
   where TEMP_SPACE_ALLOCATED is not null
    order by TEMP_SPACE_ALLOCATED desc
   ) where rownum<=20

15.其他
   IS_SQLID_CURRENT      指出该SQL_ID是否是正在执行的,该列具体意义不明
   TOP_LEVEL_CALL#                             
   TOP_LEVEL_CALL_NAME   v$toplevelcall中有对应,具体怎么用不明
相关文章
|
Prometheus 监控 Cloud Native
【监控利器Prometheus】——Prometheus+Grafana监控SpringBoot项目JVM信息
Prometheus+Grafana监控SpringBoot项目JVM信息 1. SpringBoot项目配置JVM采集 2. Prometheus配置 3. 配置grafana 4. 扩展-通过JMX Exporter监控JVM信息
【监控利器Prometheus】——Prometheus+Grafana监控SpringBoot项目JVM信息
|
6月前
|
人工智能 监控 JavaScript
CRM系统销售管理全流程解析:从MTL到RMS的数字化转型指南
在数字化转型浪潮下,CRM系统中的销售管理已成为企业增长的核心引擎。纷享销客以“全流程覆盖+智能化驱动+行业化适配”为核心,构建涵盖MTL、L2O、CPQ、RMS的端到端销售闭环,并深度融合AI技术,打造销售Agent生态,实现线索转化、客户洞察、报价履约等全场景智能赋能。通过MCR大客户管理体系,推动从短期成交向长期价值经营转型。其三层架构支持灵活定制与生态集成,已在智能制造、食品饮料、医疗健康等行业落地,助力神策数据、拓斯达、一舟股份等企业实现销售效率与战略协同的双重提升。未来,销售管理将迈向更智能、更协同、更个性化的新阶段,纷享销客持续以AI驱动企业可持续增长。
|
11月前
|
druid Java 应用服务中间件
五大主流数据库连接池的深度剖析与对比
HikariCP通过优化concurrentBag和fastStatementList等集合,提升了并发的读写效率。它采用threadlocal缓存连接,并大量运用CAS机制,以最大程度地减少lock的使用。从字节码的维度进行代码优化,确保方法尽量控制在35个字节码以内,以提升JVM处理效率。HikariCP在此基础上的进一步优化措施包括:利用ping命令进行mysql连接,以及通过Sharding-JDBC的Driver、Server和Sidecar三个版本,构建灵活多样的生态系统,满足不同需求和环境。对于线上应用,Sharding-JDBC-Driver可提供直连数据库的最优性能,而Sha
|
调度 数据安全/隐私保护
用户态和内核态 中断处理机制
用户态和内核态 中断处理机制
1057 0
|
缓存 运维 关系型数据库
数据库容灾 | MySQL MGR与阿里云PolarDB-X Paxos的深度对比
经过深入的技术剖析与性能对比,PolarDB-X DN凭借其自研的X-Paxos协议和一系列优化设计,在性能、正确性、可用性及资源开销等方面展现出对MySQL MGR的多项优势,但MGR在MySQL生态体系内也占据重要地位,但需要考虑备库宕机抖动、跨机房容灾性能波动、稳定性等各种情况,因此如果想用好MGR,必须配备专业的技术和运维团队的支持。 在面对大规模、高并发、高可用性需求时,PolarDB-X存储引擎以其独特的技术优势和优异的性能表现,相比于MGR在开箱即用的场景下,PolarDB-X基于DN的集中式(标准版)在功能和性能都做到了很好的平衡,成为了极具竞争力的数据库解决方案。
|
并行计算 关系型数据库 测试技术
PgSQL · 特性分析 · PostgreSQL 9.6 让多核并行起来
背景 经过多年的酝酿(从支持work process到支持动态fork共享内存,再到内核层面支持并行计算),PostgreSQL 的多核并行计算功能终于在2016年发布的9.6版本中正式上线,为PG的scale up能力再次拔高一个台阶,标志着开源数据库已经攻克了并行计算的难题。 相信有很多小伙伴已经开始测试了。 在32物理核的机器上进行了测试,重计算的场景,性能程线性提升。 目前并行计算支
6014 0
|
机器学习/深度学习 算法 C#
[视觉概述] 机器视觉应用方向、项目流程及学习思路总结
[视觉概述] 机器视觉应用方向、项目流程及学习思路总结
954 0
|
机器学习/深度学习 图形学 网络架构
ICLR 2022 | 纯MLP的点云网络:新架构PointMLP大幅提高点云分类准确率和推理速度
ICLR 2022 | 纯MLP的点云网络:新架构PointMLP大幅提高点云分类准确率和推理速度
1147 0
ICLR 2022 | 纯MLP的点云网络:新架构PointMLP大幅提高点云分类准确率和推理速度

热门文章

最新文章