sql - 批量插入分区表和表级锁

Question

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

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

下面举个例子来说明。

让我们成为一张 table :

 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;

第 1 节:

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

第 2 节:

alter table fg_test truncate partition p1;
--table truncated

第 1 节:

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

第 2 节:

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

Doc on Diret-Path Insert在这个问题上非常突然，只是说:

During direct-path INSERT, the database obtains exclusive locks on the table (or on all partitions of a partitioned table). As a result, users cannot perform any concurrent insert, update, or delete operations on the table, and concurrent index creation and build operations are not permitted.

How Direct-Path INSERT Works没有解释为什么所有分区都需要锁。
为什么常规插入不锁定未受影响的分区？ (我的直觉是锁定是在块级别完成的)

Answer 1

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

第 1 节:

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

第 2 节:

alter table fg_test truncate partition p1;
--table truncated

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

编写锁定整个表的功能更容易。它运行得更快，因为不需要跟踪更新了哪些分区。

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