挂起

时间:2017-11-27 19:43:10

标签: oracle

我有一个Oracle Update语句,当同一个脚本中的先前类似更新在大约一小时内完成时,该语句就会挂起。

我有两张桌子:

表A:ID,Masked_Account,Original_Account(9,000多行,交叉引用表)。

表B:UID,Prefix_Pan,Pan,Masked(13亿行)。

我尝试在Table B Pan列匹配aTable A Original_Account列的每个实例中使用Table A Masked_Account列更新Table B Pan列。

我正在进行每批1亿条记录的批量更新以及随后的提交。

例如,下面列出的Update SQL脚本大约在一小时内完成:

UPDATE [TABLE B] optim
SET optim.PAN = (SELECT MASKED_ACCOUNT FROM [TABLE A] pans
                 WHERE optim.PAN = pans.ORIG_ACCOUNT), optim.MASKED = '1'
WHERE optim.OPTIM_UID BETWEEN 1200000000 AND 1300000000
AND EXISTS (SELECT 1
            FROM [TABLE A] pans
            WHERE optim.PAN = pans.ORIG_ACCOUNT);

我的上次更新SQL语句挂起并且永远不会完成:

UPDATE [TABLE B] optim
SET optim.PAN = (SELECT MASKED_ACCOUNT FROM [TABLE A] pans
                 WHERE optim.PAN = pans.ORIG_ACCOUNT), optim.MASKED = '1'
WHERE optim.OPTIM_UID > 1300000000
AND EXISTS (SELECT 1
            FROM [TABLE A] pans
            WHERE optim.PAN = pans.ORIG_ACCOUNT);

解释计划(dbms_xplan.display)结果:

Plan hash value: 4037184420

----------------------------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name                         | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------------------------
|   0 | UPDATE STATEMENT                      |                              |   250 |  9250 |   465K  (1)| 00:00:10 |
|   1 |  UPDATE                               | OPTIM_SMRY_FTR_CHKMC_EXTRACT |       |       |            |          |
|*  2 |   HASH JOIN RIGHT SEMI                |                              |   250 |  9250 |   239K  (1)| 00:00:05 |
|   3 |    INDEX STORAGE FAST FULL SCAN       | IDX_PANS_ORIG_ACCT           |    82 |   902 | 10123   (1)| 00:00:01 |
|   4 |    TABLE ACCESS BY INDEX ROWID BATCHED| OPTIM_SMRY_FTR_CHKMC_EXTRACT |    32M|   796M|   228K  (1)| 00:00:05 |
|*  5 |     INDEX RANGE SCAN                  | PK_OP_47                     |    22M|       | 53465   (1)| 00:00:02 |
|   6 |   TABLE ACCESS BY INDEX ROWID BATCHED | PANS                         |     1 |    22 |   604   (1)| 00:00:01 |
|*  7 |    INDEX RANGE SCAN                   | IDX_PANS_ORIG_ACCT           |     1 |       |     3   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("OPTIM"."PAN"="PANS"."ORIG_ACCOUNT")
   5 - access("OPTIM"."OPTIM_UID">1300000000)
   7 - access("PANS"."ORIG_ACCOUNT"=:B1)

Note
-----
   - dynamic statistics used: dynamic sampling (level=AUTO)

任何人都可以告诉我在最后一次更新SQL(optim.OPTIM_UID> 1300000000)上我需要采取哪些不同的做法,以便它不会挂起或我应该如何以不同方式处理整个更新过程?

0 个答案:

没有答案