ORACLE DELETE数据慢的案例

今天遇到一个有意思的案例，一开发同事告诉我他删除一个表的记录非常慢，已经快1个多小时了还没有完成。而且删除的记录只有1百多条。真是大跌眼镜的一件事情。最后发现该表与多个表有外键关联关系（这个表即是主表、又是从表），最后我禁用引用该表的外键约束后。一秒内删除了记录。然后启用外键约束关系。下面记录、分析一下解决过程的思路（下面是在测试环境的记录，数据量不一样）。

我去处理这个问题时，首先怀疑可能是SQL的阻塞、触发器、外键约束、高水位线等因素中的某一个导致DELETE操作慢，于是我打算一个一个排除，我先试着删除一条记录，然后去检查SQL的阻塞情况，结果使用下面SQL语句并没有发现SQL被阻塞。于是SQL的阻塞导致DELETE慢的原因被我排除了。

SELECT '节点 ' || A.INST_ID || ' SESSION ' || A.SID || ',' || A_S.SERIAL# ||

       ' 阻塞了 节点 ' || B.INST_ID || ' SESSION ' || B.SID || ',' || B_S.SERIAL# BLOCKINFO,

       A.INST_ID,

       A_S.SID,

       A_S.SCHEMANAME,

       A_S.MODULE,

       A_S.STATUS,

       A.TYPE LOCK_TYPE,

       A.ID1,

       A.ID2,

       DECODE(A.LMODE,

              0,

              'NONE',

              1,

              NULL,

              2,

              'ROW-S (SS)',

              3,

              'ROW-X (SX)',

              4,

              'SHARE (S)',

              5,

              'S/ROW-X (SSX)',

              6,

              'EXCLUSIVE (X)') LOCK_MODE,

       '后为被阻塞信息' ,

       B.INST_ID BLOCKED_INST_ID,

       B_S.SID BLOCKED_SID,

       B.TYPE BLOCKED_LOCK_TYPE,

       DECODE(B.REQUEST,

              0,

              'NONE',

              1,

              NULL,

              2,

              'ROW-S (SS)',

              3,

              'ROW-X (SX)',

              4,

              'SHARE (S)',

              5,

              'S/ROW-X (SSX)',

              6,

              'EXCLUSIVE (X)') BLOCKED_LOCK_REQUEST,

       B_S.SCHEMANAME BLOCKED_SCHEMANAME,

       B_S.MODULE BLOCKED_MODULE,

       B_S.STATUS BLOCKED_STATUS,

       B_S.SQL_ID BLOCKED_SQL_ID,

       OBJ.OWNER BLOCKED_OWNER,

       OBJ.OBJECT_NAME BLOCKED_OBJECT_NAME,

       OBJ.OBJECT_TYPE BLOCKED_OBJECT_TYPE,

       CASE

          WHEN B_S.ROW_WAIT_OBJ# <> -1 THEN

             DBMS_ROWID.ROWID_CREATE(1,

                                     OBJ.DATA_OBJECT_ID,

                                     B_S.ROW_WAIT_FILE#,

                                     B_S.ROW_WAIT_BLOCK#,

                                     B_S.ROW_WAIT_ROW#) 

          ELSE 

            '-1' 

          END BLOCKED_ROWID, --THE BLOCKED ROWID

       DECODE(OBJ.OBJECT_TYPE,

              'TABLE',

              'SELECT * FROM ' || OBJ.OWNER || '.' || OBJ.OBJECT_NAME ||

              ' WHERE ROWID=''' ||

              DBMS_ROWID.ROWID_CREATE(1,

                                      OBJ.DATA_OBJECT_ID,

                                      B_S.ROW_WAIT_FILE#,

                                      B_S.ROW_WAIT_BLOCK#,

                                      B_S.ROW_WAIT_ROW#) || '''',

              NULL)  BLOCKED_DATA_QUERYSQL

  FROM GV$LOCK     A,

       GV$LOCK     B,

       GV$SESSION  A_S,

       GV$SESSION  B_S,

       DBA_OBJECTS OBJ

 WHERE A.ID1 = B.ID1

   AND A.ID2 = B.ID2

   AND A.BLOCK > 0 --BLOCK THE OTHER SQL

   AND B.REQUEST > 0

   AND ((A.INST_ID = B.INST_ID AND A.SID <> B.SID) OR

       (A.INST_ID <> B.INST_ID))

   AND A.SID = A_S.SID

   AND A.INST_ID = A_S.INST_ID

   AND B.SID = B_S.SID

   AND B.INST_ID = B_S.INST_ID

   AND B_S.ROW_WAIT_OBJ# = OBJ.OBJECT_ID(+)

 ORDER BY A.INST_ID,A.SID;

接下来，我检查了该表的的触发器，结果并没有发现DELETE触发器。也就是说DELETE操作并不会触发任何触发器。触发器导致DELETE慢的怀疑也可以排除掉了。

SELECT * FROM DBA_TRIGGERS WHERE TABLE_NAME='INV_LOCATION_PALLETS'

我用show_space检查了一下这个表的高水位线，发现并没有问题，不需要收缩高水位线。高水位线这个因素也可以排除了。只剩下外键约束的影响了。于是检查了一下有哪些表是该表的从表，如下所示

SELECT /*+RULE*/ D.CONSTRAINT_NAME PK_NAME,

                 D.TABLE_NAME 

                 || '.' 

                 || D.COLUMN_NAME  PK_COLUMN,

                 A.CONSTRAINT_TYPE,

                 B.CONSTRAINT_NAME FK_NAME,

                 B.TABLE_NAME 

                 || '.' 

                 || B.COLUMN_NAME  FK_COLUMN

FROM   DBA_CONSTRAINTS A 

       JOIN DBA_CONS_COLUMNS B 

         ON A.CONSTRAINT_NAME = B.CONSTRAINT_NAME

            AND A.OWNER = B.OWNER

       JOIN DBA_CONSTRAINTS C 

         ON A.R_CONSTRAINT_NAME = C.CONSTRAINT_NAME

            AND A.R_OWNER = C.OWNER

       JOIN DBA_CONS_COLUMNS D 

         ON C.CONSTRAINT_NAME = D.CONSTRAINT_NAME

            AND C.OWNER = D.OWNER

WHERE  D.TABLE_NAME = 'INV_LOCATION_PALLETS' 

有时候也可以用下面语句查看引用这个表的外键引用关系

SELECT * FROM DBA_CONSTRAINTS WHERE R_CONSTRAINT_NAME='PK_INV_LOCATION_PALLETS'

如上所示，INV_LOCATION_PALLETS这个表有三个从表，而这里面有个表的记录很大，大概2千多万。所以导致DELETE操作很慢。

我们可以用跟踪当前会话，查看一下DELETE操作，就会发现它会去处理从表，检查从表有没有对应的记录，而这个外键刚好也没有索引（下面是使用tkprof命令格式化的内容）。在这篇Delete the data on the table very slow(删除数据慢)博客里面跟深入的介绍、分析了删除表删除数据慢的原因。在此不做过多赘述了。

DELETE INVENTORY.INV_LOCATION_PALLETS  

WHERE

 PALLET_ID =1039928

call     count       cpu    elapsed       disk      query    current        rows

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

Parse        1      0.00       0.00          0          0          0           0

Execute      1      0.00       0.00          0          3         26           1

Fetch        0      0.00       0.00          0          0          0           0

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

total        2      0.00       0.01          0          3         26           1

Misses in library cache during parse: 1

Optimizer mode: ALL_ROWS

Parsing user id: 5  

Rows     Row Source Operation

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

      1  DELETE  INV_LOCATION_PALLETS (cr=752149 pr=735050 pw=0 time=7550289 us)

      1   INDEX UNIQUE SCAN PK_INV_LOCATION_PALLETS (cr=3 pr=0 pw=0 time=38 us)(object id 59532)

********************************************************************************

select /*+ all_rows */ count(1) 

from

 "INVENTORY"."INV_REQ_HD" where "TO_PALLET_ID" = :1

call     count       cpu    elapsed       disk      query    current        rows

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

Parse        1      0.00       0.00          0          0          0           0

Execute      1      0.00       0.00          0          0          0           0

Fetch        1      0.75       0.74      70540      78205          0           1

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

total        3      0.75       0.74      70540      78205          0           1

Misses in library cache during parse: 0

Optimizer mode: ALL_ROWS

Parsing user id: SYS   (recursive depth: 1)

Rows     Row Source Operation

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

      1  SORT AGGREGATE (cr=78205 pr=70540 pw=0 time=743169 us)

      0   TABLE ACCESS FULL INV_REQ_HD (cr=78205 pr=70540 pw=0 time=743155 us)

********************************************************************************

select /*+ all_rows */ count(1) 

from

 "INVENTORY"."INV_REQ_HD" where "FROM_PALLET_ID" = :1

call     count       cpu    elapsed       disk      query    current        rows

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

Parse        1      0.00       0.00          0          0          0           0

Execute      1      0.00       0.00          0          0          0           0

Fetch        1      0.69       0.67      70528      78205          0           1

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

total        3      0.69       0.68      70528      78205          0           1

Misses in library cache during parse: 0

Optimizer mode: ALL_ROWS

Parsing user id: SYS   (recursive depth: 1)

Rows     Row Source Operation

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

      1  SORT AGGREGATE (cr=78205 pr=70528 pw=0 time=680000 us)

      0   TABLE ACCESS FULL INV_REQ_HD (cr=78205 pr=70528 pw=0 time=679987 us)

********************************************************************************

select /*+ all_rows */ count(1) 

from

 "INVENTORY"."INV_REQ_LINES" where "TO_PALLET_ID" = :1

call     count       cpu    elapsed       disk      query    current        rows

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

Parse        1      0.00       0.00          0          0          0           0

Execute      1      0.00       0.00          0          0          0           0

Fetch        1      3.30       3.23     296991     297868          0           1

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

total        3      3.30       3.23     296991     297868          0           1

Misses in library cache during parse: 0

Optimizer mode: ALL_ROWS

Parsing user id: SYS   (recursive depth: 1)

Rows     Row Source Operation

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

      1  SORT AGGREGATE (cr=297868 pr=296991 pw=0 time=3232134 us)

      0   TABLE ACCESS FULL INV_REQ_LINES (cr=297868 pr=296991 pw=0 time=3232122 us)

********************************************************************************

select /*+ all_rows */ count(1) 

from

 "INVENTORY"."INV_REQ_LINES" where "FROM_PALLET_ID" = :1

call     count       cpu    elapsed       disk      query    current        rows

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

Parse        1      0.00       0.00          0          0          0           0

Execute      1      0.00       0.00          0          0          0           0

Fetch        1      2.94       2.88     296991     297868          0           1

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

total        3      2.94       2.88     296991     297868          0           1

Misses in library cache during parse: 0

Optimizer mode: ALL_ROWS

Parsing user id: SYS   (recursive depth: 1)

Rows     Row Source Operation

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

      1  SORT AGGREGATE (cr=297868 pr=296991 pw=0 time=2885783 us)

      0   TABLE ACCESS FULL INV_REQ_LINES (cr=297868 pr=296991 pw=0 time=2885772 us)

********************************************************************************

begin

  sys.dbms_output.get_line(line => :line, status => :status);

end;

call     count       cpu    elapsed       disk      query    current        rows

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

Parse        4      0.00       0.00          0          0          0           0

Execute      4      0.00       0.00          0          0          0           4

Fetch        0      0.00       0.00          0          0          0           0

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

total        8      0.00       0.00          0          0          0           4

Misses in library cache during parse: 0

Optimizer mode: ALL_ROWS

Parsing user id: 5  

 

参考资料：

http://www.anbob.com/archives/1962.html/comment-page-1