等待事件系列(1)--User I/O类型(下)


等待事件系列(1)--User I/O类型(下)


全文可参考:http://www.cnblogs.com/lhrbest/articles/5835420.html 

 BLOG文档结构图

wps2D38.tmp 


6.3   db file parallel read

SELECT *

FROM   v$event_name

WHERE  NAME IN ('db file parallel read');

wps2D72.tmp 

V$SESSION_WAIT这个视图里面,这个等待事件有三个参数P1P2P3,其中P1为files代表有多少个文件被读取所请求,P2为blocks代表总共有多少个BLOCK被请求,P3为requests代表总共有多少次I/O请求。

db file parallel read物理读等待事件涉及到的数据块均是不连续的,同时可以跨越extent,这点不像db file scattered read

这是一个很容易引起误导的等待事件,实际上这个等待事件和并行操作(比如并行查询,并行DML)没有关系。这个事件发生在数据库恢复的时候,当有一些数据块需要恢复的时候,Oracle会以并行的方式把他们从数据文件中读入到内存中进行恢复操作当Oracle从多个数据文件中并行的物理读取多个BLOCK到内存的不连续缓冲中(可能是高速缓存区或者是PGA)的时候可能就会出现这个等待事件。这种并行读取一般出现在恢复操作中或者是从缓冲中预取数据达到最优化(而不是多次从单个BLOCK中读取buffer prefetch以优化多个单块读)。这个事件表明会话正在并行执行多个读取的需求。注意:在11g之前,这个等待事件发生在数据文件的恢复过程中,但11g中新增了prefetch的特性,所以也可能导致这个等待事件的产生。

如果在等待时间中这个等待事件占的比重比较大,可以按照处理db file sequential read等待事件的方法来处理这个事件。

若是由于prefetch引起的性能问题,我们可以通过添加隐含参数来解决该问题。可以参考bloghttp://blog.itpub.net/26736162/viewspace-2123473

set pagesize 9999

set line 9999

col NAME format a40

col KSPPDESC format a50

col KSPPSTVL format a20

SELECT a.INDX,

       a.KSPPINM NAME,

       a.KSPPDESC,

       b.KSPPSTVL

FROM   x$ksppi  a,

       x$ksppcv b

WHERE  a.INDX = b.INDX

and lower(a.KSPPINM) IN ('_db_block_prefetch_quota','_db_block_prefetch_limit','_db_file_noncontig_mblock_read_count');

ALTER SYSTEM SET  "_db_block_prefetch_quota"=0 SCOPE=SPFILE SID='*';

ALTER SYSTEM SET  "_db_block_prefetch_limit"=0 SCOPE=SPFILE SID='*';

ALTER SYSTEM SET  "_db_file_noncontig_mblock_read_count"=0 SCOPE=SPFILE SID='*';

 

SYS@oraESKDB1> set pagesize 9999

SYS@oraESKDB1> set line 9999

SYS@oraESKDB1> col NAME format a40

SYS@oraESKDB1> col KSPPDESC format a50

SYS@oraESKDB1> col KSPPSTVL format a20

SYS@oraESKDB1> SELECT a.INDX,

  2         a.KSPPINM NAME,

  3         a.KSPPDESC,

  4         b.KSPPSTVL

  5  FROM   x$ksppi  a,

  6         x$ksppcv b

  7  WHERE  a.INDX = b.INDX

  8  and lower(a.KSPPINM) IN ('_db_block_prefetch_quota','_db_block_prefetch_limit','_db_file_noncontig_mblock_read_count');

 

      INDX NAME                                     KSPPDESC                                           KSPPSTVL

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

       881 _db_block_prefetch_quota                 Prefetch quota as a percent of cache size          10

       883 _db_block_prefetch_limit                 Prefetch limit in blocks                           0

      1156 _db_file_noncontig_mblock_read_count     number of noncontiguous db blocks to be prefetched 11

 

SYS@oraESKDB1> ALTER SYSTEM SET  "_db_file_noncontig_mblock_read_count"=0 SCOPE=SPFILE SID='*';

 

System altered.

 

SYS@oraESKDB1> ALTER SYSTEM SET  "_db_block_prefetch_quota"=0 SCOPE=SPFILE SID='*';

 

System altered.

 

SYS@oraESKDB1> ALTER SYSTEM SET  "_db_block_prefetch_limit"=0 SCOPE=SPFILE SID='*';

 

System altered.

 

SYS@oraESKDB1> ALTER SYSTEM SET  "_db_file_noncontig_mblock_read_count"=0 SCOPE=SPFILE SID='*';

 

 

6.4   db file single write

这个等待事件通常只发生在一种情况下,就是Oracle 更新数据文件头信息时(比如发生Checkpoint)。 

当这个等待事件很明显时,需要考虑是不是数据库中的数据文件数量太大,导致Oracle需要花较长的时间来做所有文件头的更新操作(checkpoint)。

 

SELECT *

FROM   v$event_name

WHERE  NAME IN ('db file single write');

wps2D83.tmp 

这个等待事件有三个参数:

l file#: 需要更新的数据块所在的数据文件的文件号。查询文件号的SQL语句是:SELECT * FROM v$datafile WHERE file# = ;

l block#需要更新的数据块号,如果BLOCK号不是1,则可以通过如下查询查出Oracle正在写入的对象是什么:

SELECT  segment_name ,  segment_type ,                                          

owner , tablespace_name                         

FROM  sys.dba_extents                        

WHERE  file_id =                           

AND                          

BETWEEN block_id AND block_id + blocks -1

l blocks需要更新的数据块数目(通常来说应该等于1,或Oracle写入file#的数据文件中从BLOCK#开始写入的BLOCK的数量。头一般来说都是BLOCK1,操作系统指定的文件头是BLOCK0,如果BLOCK号大于1,则表明Oracle正在写入的是一个对象而不是文件头。

 

6.5   direct path read(直接路径读DPR

直接路径读等待事件的3个参数分别是:file#(指绝对文件号)、first block#block数量。

SELECT * FROM V$EVENT_NAME A WHERE A.NAME = 'direct path read';

wps2D84.tmp 

这个等待事件有三个参数:

file number: 等待I/O读取请求的文件的绝对文件号

first dba: 等待I/O读取请求的第一个BLOCK

block cnt: 以first block为起点,总共有多少个连续的BLOCK被请求读取

由参数P1P2推得访问的数据对象:

select s.segment_name, s.partition_name

  from dba_extents s

where  between s.block_id and (s.block_id + s.blocks -1) and s.file_id =

 

直接路径读(direct path read)通常发生在Oracle直接读取数据到PGA,这个读取不需要经过SGA这类读取通常在以下情况被使用:

① 大量的磁盘排序IO操作 在排序操作(order by, group by, union, distinct, rollup,合并连接)时,由于PGA中的SORT_AREA_SIZE空间不足,无法在PGA中完成排序,需要利用temp表空间进行排序,当从临时表空间中读取排序结果时,会产生direct path read从10g开始表现为direct path read temp等待事件。

② 大量的Hash Join操作,利用temp表空间保存hash区。使用HASH连接的SQL语句,将不适合位于内存中的散列分区刷新到临时表空间中。为了查明匹配SQL谓词的行,临时表空间中的散列分区被读回到内存中(目的是为了查明匹配SQL谓词的行)ORALCE会话在direct path read等待事件上等待。

③ SQL语句的并行查询,并行查询从属进程 使用并行扫描的SQL语句也会影响系统范围的direct path read等待事件。在并行执行过程中,direct path read等待事件与从属查询有关,而与父查询无关,运行父查询的会话基本上会在PX Deq:Execute Reply上等待,从属查询会产生direct path read等待事件。

④ 预读操作

⑤ 串行全表扫描(Serial  Table  Scan)大表的全表扫描,在Oracle11g中,全表扫描的算法有新的变化,根据表的大小、高速缓存的大小等信息,决定是否绕过SGA直接从磁盘读取数据。而10g则是全部通过高速缓存读取数据,称为table scan(large)11g认为大表全表时使用直接路径读,可能比10g中的数据文件散列读(db file scattered reads)速度更快,使用的latch也更少。

 

最常见的是第一种情况。在DSS系统中,存在大量的Direct path read是很正常的,但是在OLTP系统中,通常显著的直接路径读都意味着系统应用存在问题,从而导致大量的磁盘排序读取操作。

db file sequential readdb file scattered readdirect path read是常见的集中数据读方式,图简要述了这3种方式的读取示意。

wps2D85.tmp 

 

大量的direct path read等待时间最可能是一个应用程序问题。 

direct path read事件由SQL语句驱动,这些SQL语句执行来自临时的或常规的表空间的直接读取操作。当输入的内容大于PGA中的工作区域时,带有需要排序的函数的SQL语句将排序结果写入到临时表空间中 临时表空间中的排序顺序串随后被合并,用于提供最终的结果。读取排序结果时, Oracle会话在direct path read等待事件上等待。

对于这一写入等待,我们应该找到I/O操作最为频繁的数据文件(如果有过多的排序操作,很有可能就是临时文件),分散负载,加快其写入操作。

DB_FILE_DIRECT_IO_COUNT初始化参数可能影响direct path read的性能。

直接读取可能按照同步或异步的方式执行,取决于平台和初始化参数disk_asynch_io参数的值。使用异步I/O时,系统范围的等待的事件的统计可能不准确,会造成误导作用。

该事件一般不可能显示为主要的瓶颈,但它实际上也许是就是祸首。由于ORACLE统计等待时间的方式会造成统计的时间量不准确(如:从属查询产生的时间无法进行统计),所以对该事件不应该使用v$session_event视图中的total_waittime_waited进行估计,应该使用v$sesstat视图中的直接读取操作次数(physical reads direct)进行判断:

select a.NAME,

       b.SID,

       b.VALUE,

       round((sysdate - c.LOGON_TIME) * 24) hours_connected

  from vstatnamea,vstatnamea,vsesstat b, v$session c

where b.SID = c.SID

   and a.STATISTIC# = b.STATISTIC#

   and b.VALUE > 0

   and a.NAME = 'physical reads direct'

order by b.VALUE;

direct path read事件产生的原因,我们需要判断该事件正在读取什么段(如:散列段、排序段、一般性的数据文件),由此可判断产生该事件的原因是什么,可使用以下语句进行查询:

SELECT a.event,

       a.sid,

       c.sql_hash_value hash_vale,

       decode(d.ktssosegt,

              1,

              'SORT',

              2,

              'HASH',

              3,

              'DATA',

              4,

              'INDEX',

              5,

              'LOB_DATA',

              6,

              'LOB_INDEX',

              NULL) AS segment_type,

       b.tablespace_name,

       b.file_name

  FROM vsessionwaita,dbadatafilesb,vsessionwaita,dbadatafilesb,vsession c, x$ktsso d

WHERE c.saddr = d.ktssoses(+)

   AND c.serial# = d.ktssosno(+)

   AND d.inst_id(+) = userenv('instance')

   AND a.sid = c.sid

   AND a.p1 = b.file_id

   AND a.event = 'direct path read'

UNION ALL

SELECT a.event,

       a.sid,

       d.sql_hash_value hash_value,

       decode(e.ktssosegt,

              1,

              'SORT',

              2,

              'HASH',

              3,

              'DATA',

              4,

              'INDEX',

              5,

              'LOB_DATA',

              6,

              'LOB_INDEX',

本页内容版权归属为原作者,如有侵犯您的权益,请通知我们删除。

mysql存储过程小试牛刀 - 2016-09-03 14:09:13

(1). 格式 MySQL 存储过程创建的格式: CREATE PROCEDURE 过程名 ([ 过程参数 [,...]]) [ 特性 ...] 过程体 这里先举个例子: mysql DELIMITER //   mysql CREATE PROCEDURE proc1(OUT s int)     - BEGIN      - SELECT COUNT(*) INTO s FROM user;       - END      - //   mysql DELIMITER ;    注: ( 1 )这里
【故障处理】队列等待之 enq: TX - row lock contention 1    BLOG 文档结构图   2    前言部分 2.1    导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识, ~O(∩_∩)O~ : ① enq: TX - row lock contention 等待事件的解决 ② 一般等待事件的解决办法 ③ 队列等待的基本知识 ④  ADDM 的使用 ⑤ 如何获取历史执行计划 ⑥ 查询绑定变量的具体值 ⑦ 很多有用的查询性
       ORA-01408:such column list already indexed问题的原因是当新建一个索引时,索引对应的字段和字段顺序和已经存在的索引相同。        最近一个需求,是将主键索引转成HASH分区的主键索引,需要新建一个索引,然后将现有的主键索引去掉。如果直接新建一个字段相同且字段顺序相同的索引,就会报ORA-01408。当然,可以将现有的主键索引先删掉,但这样在新索引建立之前,无法保证数据的唯一性,并且按主键的更新删除操作会因为无索引而变的很慢。        我们可
继续上次分析的一个问题,一个简单的SQL语句执行计划有些奇怪,明明可以走唯一性索引但是却走了另外一个索引。 当然了,最后逐步定位,发现是在直方图的地方有一些差别。取消直方图之后,执行计划立刻恢复了正常。 当然问题来了,这个是为什么呢,收集统计信息中的auto选项是什么含义呢。为什么两个数据类型一样的(varchar2(64))的列,境遇却大大不同。 我们来看看一些统计信息的数据。 为了跟进一步验证数据的分布律和选取代价,我们查询它的直方图信息。 SQL   select to_char(endpoint_v
首先说明_fairness_threshold参数仅在RAC环境下才有意义,让我对这个参数引起关注是在某一次查询v$cr_block_server时,发现该视图有一个名为FAIRNESS_DOWN_CONVERTS的字段,官方文档里将其解释为:Number of times an instance receiving a request has down-converted an X lock on a block because it was not modifying the block 该参数相关性
    今天看到有一个网友提了一个问题,描述很简短     测试DG时,主库不能宕机,如何测试failover?     其实这个需求从业务层面来说是合理的,一个数据量很大的核心数据库,如果需要做灾难演练,就希望在备库上做一下演练工作,而这个演练其实又不想影响到目前的主库,而且又希望能够尽可能模拟真实的情况,我想这样对于运维部门来说是最具有考核力度,而对于开发业务部门来说是最受欢迎的,因为他们什么都不需要改动。 而从技术角度来看,似乎有一些地方需要考量,如果备库Failover为主库,那么这个主库肯定是可以

简单分析percona-zabbix-templates - 2016-09-01 04:09:15

    当Zabbix和Percona两者相遇,会擦出不少的开源火花来,众人拾柴火焰高,最终受益的还是大部分运维人员。     我很早就用过Percona提供的MySQL监控模板,但是却没有刨根问底,只是简单使用而已,自从定制了Orabbix之后,我还是信心满满,MySQL的数据字典相对要少很多,监控起来可能想必Oracle要少很多,不过关于Percona的这个插件,我还是带着好奇之心,内部是否有很多独门秘籍,我想好好学学那些监控项对应的SQL,好好弥补我对于MySQL监控的一些空缺,所以简单分析这个模板就
问题描述 : 近期的 rman 备份中,归档日志的备份没有被删除, rman 的脚本和策略都没变过,归档的备份一直保留,每过一段时间就要物理删除备份,很是奇怪。 rman的 configure 如下 RMAN show all; RMAN configuration parameters for database withdb_unique_name HUBSRAC are: CONFIGURE RETENTION POLICY TO REDUNDANCY 2; CONFIGURE BACKUP OPTI
一 前言  纳西姆.尼古拉斯.塔勒布的经典著作《黑天鹅》中对“黑天鹅现象”的定义是 - 不可预测,人们事前往往低估其发生的可能性 - 造成极大影响 - 事后回头再看,又觉得此事发生的有理 二 分析   稳定性 是一项衡量基础系统是否永续服务的绝对指标,作为资深DBA从业人员,相信大多数公司运维团队都会制定稳定性的SLA指标达到N个9,为用户提供Full-Time 服务。然而前一段时间各种"黑天鹅”式的因素导致一系列的系统故障,严重影响了C端B端的用户的使用体验。 故 障 是数据库系统或者说业务系统的“脆弱
最近有个同事碰到一个问题,想让我给点思路。我大体了解了一下,是一个系统目前在做压力测试,但是经业务反馈发现某个环节的处理时间有些长,排查了一圈,最后这件事情就落在了DB这边,希望DB能够给点意见,是否存在一些性能瓶颈。     我们从开发同学那里得到的一个基本的SQL语句,根据关键字从v$sql中做了提取,发现对应的SQL语句的执行时间还是OK的。 得到的SQL语句如下: SQL_ID        SQL_FULLTEXT ------------- ---------------------------