转:oracle几组重要的常见视图-v$undostat,v$open_cursor,v$rowcache,v$session_longops,v$waitstat v$undostat v$open_cursor v$rowcache v$session_longops v$waitstat

本视图监控当前实例中undo空间以及事务如何运行。并统计undo空间开销,事务开销以及实例可用的查询长度。

V$UNDOSTAT中的常用列

  Endtime:以10分钟为间隔的结束时间

  UndoBlocksUsed:使用的undo块总数

  TxnConcurrency:事务并发执行的最大数

  TxnTotal:在时间段内事务执行总数

  QueryLength:查询长度的最大值

  ExtentsStolen:在时间段内undo区必须从一个undo段转到另一个的次数

  SSTooOldError:在时间段内'Snapshot Too Old'错误发生的次数

  UNDOTSN:这段时间内最后活动的undo表空间ID

视图的第一行显示了当前时间段的统计,其它的每一条记录分别以每10分钟一个区间。24小时循环,一天最多144条记录

示例:

select * from v$undostat;

 --oracle 12cpdb没数据,查询cdb

v$open_cursor

本视图列出session打开的所有cursors,很多时候都将被用到,比如:你可以通过它查看各个session打开的cursor数。

当诊断系统资源占用时,它常被用于联接v$sqlareav$sql查询出特定SQL(高逻辑或物理I/O)。然后,下一步就是找出源头。在应用环境,基本都是同一类用户登陆到数据库(V$SQLAREA中拥有相同的PARSING_USER_ID),而通过这个就可以找出它们的不同。V$SQLAREA中的统计项在语句完全执行后被更新(并且从V$SESSION.SQL_HASH_VALUE中消失)。因此,你不能直接找到session除非语句被再次执行。不过如果sessioncursor仍然打开着,你可以通过v$open_cursor找出执行这个语句的session

V$OPEN_CURSOR中的连接列

Column  View  Joined Column(s)

----------------------------- ---------------------------------------- -----------------------------

HASH_VALUE, ADDRESS V$SQLAREA, V$SQL, V$SQLTEXT HASH_VALUE, ADDRESS

SID V$SESSION   SID

示例:

1.找出执行某语句的session:
 SELECT hash_value, buffer_gets, disk_reads 
FROM V$SQLAREA
--WHERE disk_reads > 1000000 
ORDER BY buffer_gets DESC;

SELECT sid FROM V$SESSION WHERE sql_hash_value
SELECT sid FROM V$OPEN_CURSOR WHERE hash_Value
2.列出拥有超过400个cursor的sessionID
SELECT sid, count(0) ct FROM v$open_cursor 
GROUP BY sid HAVING COUNT(0) > 400 ORDER BY ct desc;
--事实上,v$open_cursor是一个相当常用的视图,特别是web开发应用的时候。仅通过它一个视图你就能分析出当前的连接情况,主要执行语句等。

v$rowcache

本视图显示数据字典缓存(也叫rowcache)各项统计。每一条记录包含不同类型的数据字典缓存数据统计,注意数据字典缓存有层次差别,因此同样的缓存名称可能不止一次出现。

V$ROWCACHE常用列

  PARAMETER:缓存名

  COUNT:缓存项总数

  USAGE:包含有效数据的缓存项数

  GETS:请求总数

  GETMISSES:请求失败数

  SCANS:扫描请求数

  SCANMISSES:扫描请求失败次数

  MODIFICATIONS:添加、修改、删除操作数

  DLM_REQUESTSDLM请求数

  DLM_CONFLICTSDLM冲突数

  DLM_RELEASESDLM释放数

使用V$ROWCACHE数据

1>.确认数据字典缓存是否拥有适当的大小。如果shared pool过小,那数据字典缓存就不足以拥有合适的大小以缓存请求信息。

2>.确认应用是否有效访问缓存。如果应用设计未能有效使用数据字典缓存(比如,大数据字典缓存并不有助于解决性能问题)。例如,DC_USERS缓存在过去某段时期内出现大量GETS,看起来像是数据库中创建了大量的不同用户,并且应用记录下用户频繁登陆和注销。通过检查logon比率以及系统用户数可以验证上述数据。同时解析比率也会很高,如果这是一个大型的OLTP系统的中间层,它可能在中间层更有效的管理个别帐户,允许中间层以单用户登陆成为应用所有者。通过保持活动连接来减少logon/logoff比率也同样有效。

3>.确认是否发生动态空间分配。DC_SEGMENTS, DC_USED_EXTENTS, 以及DC_FREE_EXTENTS大量的类似大小修改将指出存在大量动态空间分配。可行的解决方案包括指定下一个区大小或者使用本地管理表空间。如果发生空间分配的是临时的表空间,则可以为其指定真正的临时表空间(If the space allocation is occurring on the temp tablespace, then use a true temporary tablespace for the temp. )

4>.dc_sequences值的变化指出是否大量sequence号正在产生。

5>.搜集硬解析的证据。硬解析常表现为大量向DC_COLUMNS, DC_VIEWS 以及 DC_OBJECTS cachesgets

示例:

1.分组统计数据字典统计项
 SELECT parameter,sum("COUNT"),sum(usage),sum(gets),sum(getmisses),
       sum(scans),sum(scanmisses),sum(modifications),
       sum(dlm_requests),sum(dlm_conflicts),sum(dlm_releases)
  FROM V$ROWCACHE
 GROUP BY parameter;
2.检查数据字典的命中率
 select 1 - sum(getmisses) / sum(gets) "data dictionary hitratio"  from v$rowcache;

v$session_longops

本视图显示运行超过6秒的操作的状态。包括备份,恢复,统计信息收集,查询等等

要监控查询执行进展状况,你必须使用cost-based优化方式,并且:

  设置TIMED_STATISTICSSQL_TRACE参数值为true

  通过ANALYZEDBMS_STATS数据包收集对象统计信息。

你可以通过DBMS_APPLICATION_INFO.SET_SESSION_LONGOPS过程添加application-specific长运行操作信息到本视图。关于DBMS_APPLICATION_INFO.SET_SESSION_LONGOPS的更多信息可以浏览:Oracle Supplied PL/SQL Packages and Types Reference

V$SESSION_LONGOPS列说明

  SIDSession标识

  SERIAL#Session串号

  OPNAME:操作简要说明

  TARGET:操作运行所在的对象

  TARGET_DESC:目标对象说明

  SOFAR:至今为止完成的工作量

  TOTALWORK:总工作量

  UNITS:工作量单位

  START_TIME:操作开始时间

  LAST_UPDATE_TIME:统计项最后更新时间

  TIME_REMAINING:预计完成操作的剩余时间()

  ELAPSED_SECONDS:从操作开始总花费时间()

  CONTEXT:前后关系

  MESSAGE:统计项的完整描述

  USERNAME:执行操作的用户ID

  SQL_ADDRESS:用于连接查询的列

  SQL_HASH_VALUE:用于连接查询的列

  QCSID

示例:

 select sid,opname,sofar,totalwork,units,sql_hash_value from v$session_longops;
 select a.sql_text from v$sqlarea a,v$session_longops b where a.HASH_VALUE=b.SQL_HASH_VALUE;

v$waitstat

本视图保持自实例启动所有的等待事件统计信息。常用于当你发现系统存在大量的"buffer busy waits"据此做出适当调整

V$WAITSTAT中的常用列

  CLASS:块类别

  WAITS:本类块的等待次数

  TIME:本类块的总等待时间

等待发生的原因:

1.undo段头部:没有足够的回滚段

2.数据段头部/数据段空闲列:空闲列争夺

3.数据块冲突

4.缓存存在大量的CR复制

5.range检索时,索引列存在大量不连续

6.全表检索的表有大量被删除记录

7.高并发的读写块

  select * from v$waitstat order by 3 desc