批量插入分区表和表级锁定

Question

我想知道核心原因（引擎所做的段，块，锁的机制）为什么批量插入（使用直接路径）锁定整个表，所以如果我插入分区，我不能截断另一个分区插入不会影响（显然）

传统的插入（没有附加提示）允许截断一些不受影响的分区。（注意我说的是非提交的事务。）

下面举例说明它。

让我们成为一张桌子：

 CREATE TABLE FG_TEST 
   (COL NUMBER ) 
  PARTITION BY RANGE (COL) 
 (PARTITION "P1"  VALUES LESS THAN (1000), 
  PARTITION "P2"  VALUES LESS THAN (2000));

Insert into table fg_test values (1);
insert into table fg_test values (1000);
commit;

第一节：

insert into table fg_test select * from fg_test where col >=1000;
--1 rows inserted;

第二节：

alter table fg_test truncate partition p1;
--table truncated

第一节：

rollback;
insert /*+append */ into table fg_test select * from fg_test where col >=1000;
--1 rows inserted;

第二节：

alter table fg_test truncate partition p1;
--this throws ORA-00054: resource busy and acquire with NOWAIT specified 
--or timeout expired

关于Diret-Path Insert的Doc在这个主题上是非常突然的，只是说：

在直接路径INSERT期间，数据库获取表（或分区表的所有分区）上的独占锁。 因此，用户无法对表执行任何并发插入，更新或删除操作，并且不允许并发索引创建和构建操作。

Direct-Path INSERT如何工作并不能解释为什么所有分区都需要锁定。 为什么传统插件不能锁定不受影响的分区？ （我的直觉是锁是在块级完成的）

Answer 1

你的前提稍有不妥。 如果使用分区扩展子句，则直接路径插入不会锁定整个表。

第一节：

insert /*+append */ into fg_test partition (p2)
select * from fg_test where col >=1000;

第二节：

alter table fg_test truncate partition p1;
--table truncated

新的问题是： 当不使用分区扩展子句时，为什么传统和直接路径插入具有不同的锁定机制？ 这种澄清使问题更容易，但如果没有内部知识，下面的答案仍然只是猜测。

---

编写锁定整个表的功能更容易。 并且运行速度更快，因为无需跟踪更新的分区。

通常不需要更细粒度的锁。 大多数使用直接路径写入的系统或进程一次只更新一个大表。 如果确实需要更细粒度的锁，则可以使用分区扩展子句。 它不太方便，因为一次只能引用一个分区。 但它有99.9％的时间足够好。

Answer 2

我在asktom.oracle.com上找到了以下答案：

问汤姆：插入APPEND提示

汤姆解释了许多内部工作的，但为什么甲骨文锁定整个表而不是只受影响的分区的原因尚不清楚。

也许这只是一个设计决策（例如，不希望大型的大型直接负载可能被一个小的未经通信的事务阻塞，因此锁定所有分区......）