row cache lock等待事件一例

上线前第一次预演：有多进程ctas大表的时候数据中出现了大量的row cache lock，由于前期也用同样的脚本导过一次，速度很快，就没有非空闲等待事件，所以很奇怪，既然问题出现了，只奇怪是没用的，row cache只有看看v$rowcache

发现有三个cache#的getmisses很大，而且一直在高速增加，是dc_tablespace_quotas、dc_segment，看来是由于ctas的速度导致segment分配速度跟不上导致的，但是我查看了表空间的可用空间很多哦，再说了10g难道还会出现碎片问题吗。

另外我在查看表空间的时候发现查看表空间大小的脚本执行速度奇慢，脚本如下：

COLUMN dummy NOPRINT
COLUMN pct_used FORMAT 999.9        HEADING "%|Used"
COLUMN name     FORMAT a20          HEADING "Tablespace Name"
COLUMN Kbytes   FORMAT 9,999,999,999  HEADING "KBytes"
COLUMN used     FORMAT 9,999,999,999  HEADING "Used"
COLUMN free     FORMAT 9,999,999,999  HEADING "Free"
COLUMN largest  FORMAT 999,999,999  HEADING "Largest"
BREAK ON report
COMPUTE sum OF kbytes ON REPORT
COMPUTE sum OF free   ON REPORT
COMPUTE sum OF used   ON REPORT
set pagesize 2000
set linesize 120
--SPOOL tablespace_size.lst
SELECT
    NVL(b.tablespace_name,nvl(a.tablespace_name,'UNKOWN')) name
  , kbytes_alloc                                           kbytes
  , kbytes_alloc-NVL(kbytes_free,0)                        used
  , NVL(kbytes_free,0)                                     free
  , ((kbytes_alloc-NVL(kbytes_free,0))/kbytes_alloc)*100   pct_used
  , NVL(largest,0)                                         largest
FROM   ( SELECT   SUM(bytes)/1024 Kbytes_free
                , MAX(bytes)/1024 largest
                , tablespace_name
         FROM sys.dba_free_space
         GROUP BY tablespace_name
       ) a
     , ( SELECT   SUM(bytes)/1024 Kbytes_alloc
                , tablespace_name
         FROM sys.dba_data_files
         GROUP BY tablespace_name
       ) b
WHERE a.tablespace_name (+) = b.tablespace_name
order by pct_used desc
/

查看执行计划，发现问题出在recyclebin$这个表上，这个是10g的回收站，于是我查看了这个表空间的中bin$对象的总大小，发现正好占用了剩余的空间，只不过显示出来是可用空间，所以这里应该是由于ctas过程中是在recyclebin中分配的了，为了证实这个问题，做了个10046，发现猜测没错，tkprof之后trc中出现了大量的delete recyclebin$此类语句，由此问题得到证实，为了保证不耽误以后的预演和正式上线，决定关闭recyclebin功能，没办法，空间有限啊，等上线结束之后再启动吧，反正是动态参数，于是alter system set recyclebin=off scope=both sid='*';并清理回收站中已有的segment，purge dba_recyclebin;由于对象太多，导致清理过程耗费了很大时间，清理完之后，重新分析了一下dictionary，再次查询表空间大小的时候，只消耗1秒左右。

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

转载于:http://blog.itpub.net/16158219/viewspace-592462/