• 转 event 'utl_file I/O':


    The ASH report shows tables and data files with wait event 'utl_file I/O':

    Utl_file

     

    CHANGES

     No changes.

    CAUSE

    ASH reports retrieve data from the dba_hist_active_sess_history view. The information in that view is aggregated from what happened in between each sample from v$active_session_history, which means that it can potentially include multiple events (such as CPU and I/O events).

    In the following example , code is executed that performs CPU and I/O operations in a short period of time:

    alter system flush buffer_cache;
    alter system flush shared_pool;

    connect system/manager
    set time on
    set timing on
    set serveroutput on
    declare
    x number;
    begin
    dbms_output.enable(1000000);
    for i in (select s.*,rownum r from dba_source s) loop
     x:=dbms_utility.get_hash_value(i.name,1,163830000);
     if mod(x,99)=0 then 
      dbms_output.put('+');
     else
      dbms_output.put('.');
     end if;
     if mod(i.r,30000)=0 then
      dbms_output.put_line('*');
     end if;
    end loop;
    end;
    /

    If we query v$active_session_history, we see:


    column event format a30 
    column p1p2p3 format a20
    select sample_id,NVL(event, 'CPU') AS event,p1||'-'||p2||'-'||p3 p1p2p3, TM_DELTA_CPU_TIME,TM_DELTA_DB_TIME,DELTA_READ_IO_REQUESTS
    from v$active_session_history
    where (session_id,SESSION_SERIAL#)=(select sid,serial# from v$session where sid=(select sid from v$mystat where rownum=1))
    order by sample_id
    /


      SAMPLE_ID EVENT                          P1P2P3               TM_DELTA_CPU_TIME TM_DELTA_DB_TIME DELTA_READ_IO_REQUESTS
    ---------- ------------------------------ -------------------- ----------------- ---------------- ----------------------
        125687 CPU                            1-9720-8                        141978           126117                    311
        125688 CPU                            1-31856-16                     1093833          1105182                    142
        125689 CPU                            1-75808-16                                                                 100
        125690 CPU                            1-77248-16                     2009695          2020332                     66
        125691 CPU                            1-79952-16                                                                  64

    Notice that all of the EVENTs listed are CPU events but the PL/SQL must have had to perform I/O. This I/O is reflected in DELTA_READ_IO_REQUESTS. By looking at the columns p1,p2,p3, it can be found some residual values from what probably was a 'db file scattered read' where p1 is file_no, p2 block_id , and p3 is blocks.
    This is confirmed by looking up those blocks in the data dictionary.

    SQL> select segment_name from dba_extents where file_id =1 and 9720 between block_id and block_id+blocks;

    SEGMENT_NAME
    ---------------------------------------------------------------------------------
    SOURCE$

    SQL> select segment_name from dba_extents where file_id =1 and 79952  between block_id and block_id+blocks;

    SEGMENT_NAME
    ---------------------------------------------------------------------------------
    SOURCE$

      

    SOLUTION

    This is expected behavior.

    The wait event surfaces when a PL/SQL program is running SQLs and using UTL_FILE in close proximity. Multiple IOs to the DB and UTL_FILE calls were executed in fast succession and the p1p2p3 sampled were residual from DB IO events to the datafiles. The "utl_file I/O" event was included as part of the sample. So when the ASH report is generated, both the "utl_file I/O" event  and the information of datafiles accessed are present.

  • 相关阅读:
    三级指针
    外挂指针
    内存四区(1)(转载)
    内存四区(3)(转载)
    劫持(1)
    过滤劫持和函数回调(2)
    劫持程序(3)
    dll注入实现MFC程序劫持(4)
    virtual hust 2013.6.20 数论基础题目 I
    virtual hust 2013.6.20 数论基础题目 D
  • 原文地址:https://www.cnblogs.com/feiyun8616/p/8329482.html
Copyright © 2020-2023  润新知