ITPub博客

首页 > Linux操作系统 > Linux操作系统 > [20120224]itl的问题.txt

[20120224]itl的问题.txt

原创 Linux操作系统 作者:lfree 时间:2012-02-24 15:33:03 0 删除 编辑
昨天看awr报表,发现ITL waits,很少在前5位看到这个等待事件,当然解决很简单,是一个很小的表,仅仅占用1块,开发人员把它当作seq使用,真不知道程序员怎么想的???解决方法很简单,加大pctfree,然后move,在rebuild索引就ok了。

我仔细看了里面相关的语句,仅仅有一个事务有点慢,其它都很快,正常ITL waits不应该排这么前,感觉有点奇怪。作了一个测试:


1.建立测试环境:

SQL> select * from v$version ;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
PL/SQL Release 11.2.0.1.0 - Production
CORE    11.2.0.1.0      Production
TNS for Linux: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production

2.建立测试数据:
SQL> create table t pctfree 0 as select rownum id ,'test' name from dual connect by level<=1000;
SQL> create unique index i_t_id on t(id);
SQL> exec dbms_stats.gather_table_stats(ownname=>USER, tabname=>'T');

--我建立了一个表,pctfree=0,这样块内空余空间基本没有,仅仅两个ITL槽,不能在增加空间分配ITL槽。

SQL> select rowid from t where id=1;
ROWID
------------------
AAAUSUAAEAAAAO7AAA


SQL> select min(id),max(id) from t where rowid between 'AAAUSUAAEAAAAO7AAA' and 'AAAUSUAAEAAAAO7DDD';
   MIN(ID)    MAX(ID)
---------- ----------
         1        581

--可以确定id从1到581都在一个块中。

3.测试数据:

--修改数据,不commit.

打开会话1:
update t set name='TEST' where id=1;

打开会话2:
update t set name='TEST' where id=2;

打开会话3:
update t set name='TEST' where id=3;

打开会话4:
update t set name='TEST' where id=4;


也许还有些空间,能容纳3个ITL槽,在第4个会话的时候挂起。

在打开一个会话5执行,可以发现出现enq: TX - allocate ITL entry等待事件:
SQL> SELECT SID,SEQ#,EVENT FROM V$SESSION_WAIT WHERE event NOT IN (SELECT NAME FROM v$event_name WHERE wait_class = 'Idle');

       SID       SEQ# EVENT
---------- ---------- ----------------------------------------
       138        148 enq: TX - allocate ITL entry
        71        124 asynch descriptor resize

使用strace监测挂起进程:

$ strace -ttT -p 14378
Process 14378 attached - interrupt to quit
14:53:50.649628 gettimeofday({1330066430, 649778}, NULL) = 0 <0.000055>
14:53:50.649912 gettimeofday({1330066430, 649983}, NULL) = 0 <0.000056>
14:53:50.650084 gettimeofday({1330066430, 650115}, NULL) = 0 <0.000023>
14:53:50.650185 semtimedop(5210112, 0x7fbfff5748, 548682028960, NULL) = -1 EAGAIN (Resource temporarily unavailable) <3.001094>
14:53:53.651455 gettimeofday({1330066433, 651528}, NULL) = 0 <0.000054>
14:53:53.651624 gettimeofday({1330066433, 651702}, NULL) = 0 <0.000067>
14:53:53.651784 getrusage(RUSAGE_SELF, {ru_utime={0, 25996}, ru_stime={0, 22996}, ...}) = 0 <0.000052>
14:53:53.651972 gettimeofday({1330066433, 652035}, NULL) = 0 <0.000072>
14:53:53.652109 getrusage(RUSAGE_SELF, {ru_utime={0, 25996}, ru_stime={0, 22996}, ...}) = 0 <0.000018>
14:53:53.652259 gettimeofday({1330066433, 652300}, NULL) = 0 <0.000027>
14:53:53.652363 semtimedop(5210112, 0x7fbfff5748, 548682028960, NULL) = -1 EAGAIN (Resource temporarily unavailable) <3.001427>
14:53:56.653983 gettimeofday({1330066436, 654065}, NULL) = 0 <0.000062>
14:53:56.654174 gettimeofday({1330066436, 654235}, NULL) = 0 <0.000049>
14:53:56.654341 getrusage(RUSAGE_SELF, {ru_utime={0, 25996}, ru_stime={0, 22996}, ...}) = 0 <0.000064>
14:53:56.654522 gettimeofday({1330066436, 654590}, NULL) = 0 <0.000054>
14:53:56.654678 getrusage(RUSAGE_SELF, {ru_utime={0, 25996}, ru_stime={0, 22996}, ...}) = 0 <0.000055>
14:53:56.654873 gettimeofday({1330066436, 654951}, NULL) = 0 <0.000061>
14:53:56.655037 semtimedop(5210112, 0x7fbfff5748, 548682028960, NULL) = -1 EAGAIN (Resource temporarily unavailable) <3.001270>
14:53:59.656491 gettimeofday({1330066439, 656568}, NULL) = 0 <0.000053>
14:53:59.656674 gettimeofday({1330066439, 656735}, NULL) = 0 <0.000049>
14:53:59.656839 getrusage(RUSAGE_SELF, {ru_utime={0, 25996}, ru_stime={0, 22996}, ...}) = 0 <0.000060>
14:53:59.657013 gettimeofday({1330066439, 657090}, NULL) = 0 <0.000067>
14:53:59.657178 getrusage(RUSAGE_SELF, {ru_utime={0, 25996}, ru_stime={0, 22996}, ...}) = 0 <0.000052>
14:53:59.657372 gettimeofday({1330066439, 657450}, NULL) = 0 <0.000068>
14:53:59.657538 semtimedop(5210112, 0x7fbfff5748, 548682028960, NULL
Process 14378 detached

--可以发现系统调用semtimedop,这是一个linux的sleep信号,等待3秒再检测。

4.开始rollback操作:

打开会话1:
rollback ;

--检查会话4,会话4依旧挂起!

打开会话2:
rollback ;

--检查会话4,会话4依旧挂起!

打开会话3:
rollback ;

--检查会话4,会话4执行!
--可以发现,会话4必须要等待会话3结束事务,才能继续操作。

5.测试有5个会话的情况。

--修改数据,不commit.

打开会话1:
update t set name='TEST' where id=1;

打开会话2:
update t set name='TEST' where id=2;

打开会话3:
update t set name='TEST' where id=3;

打开会话4:
update t set name='TEST' where id=4;

打开会话5:
update t set name='TEST' where id=5;

在第4,5个会话的时候挂起。

打开会话1:
rollback ;

--检查会话4,5会话4依旧挂起,会话5执行!

打开会话2:
rollback ;

--检查会话4,会话4居然执行了!
--反复测试,仅仅在出现多个ITL等待时,前面的情况才不会出现!



来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/267265/viewspace-717089/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
熟悉oracle相关技术,擅长sql优化,rman备份与恢复,熟悉linux shell编程。

注册时间:2008-01-03

  • 博文量
    2322
  • 访问量
    6047502