GaussDB分区表业务锁问题

• 故障现象

使用分区表业务，出现等锁超时。

使用分区表业务，出现死锁。

• 故障原因

可能原因有以下：

事务块/存储过程中同时进行分区DDL、DML等混合业务

在一个分区DDL命令中执行多个DDL操作

进行合并分区等同时作用多个源分区的操作

• 处理方法

步骤 1     在在《特性指南》中“分区表 > 分区表并发控制”章节给出了分区表表锁、分区锁的设计规格，可以参考对应资料部分进行定位和排查。

步骤 2     判断是否在事务块/存储过程中同时进行分区DDL、DML等混合业务。

步骤 3     事务块/存储过程中执行的混合业务，会依次给业务作用的表、分区加上对应业务级别的锁。如果业务设计不合理，可能会导致互锁，出现死锁场景；如果在事务块/存储过程中同时进行分区DDL、DML等混合业务，会持有目标分区锁直到事务/存储过程结束，其他并发业务会持续等锁，可能出现锁超时场景。

步骤 4     下面的业务就会出现死锁场景：

--业务一：
begin;
delete from t1 partition (p1);
alter table t1 truncate partition p2 update global index;
commit; 

--业务二：
begin;
delete from t1 partition (p2);
alter table t1 truncate partition p1 update global index;
commit;

步骤 5     下面的业务会持锁到事务结束：

begin;
alter table t1 truncate partition p2 update global index;
copy t1 from '/home/omm/test.dat';
commit;

步骤 6     判断是否在一个分区DDL命令中执行多个DDL操作。

步骤 7     如果在一个分区DDL命令中先后对不同分区进行DDL操作，会依次给不同分区加写锁。如果并发的DQL/DML恰好作用在这些分区，且顺序相反，就可能出现死锁场景。

步骤 8     下面的并发业务就会出现死锁场景：

--业务一：
alter table t1 truncate partition p2, truncate partition p1;

--业务二：
delete from t1; --先扫描p1，再扫描p2

步骤 9     判断是否进行了合并分区等同时作用多个源分区的操作。

步骤 10    这种场景下的死锁原因与上面场景是一样，也是由于串行加锁导致的。

步骤 11    业务原因导致的锁超时/死锁，需要分析业务模型，对业务进行改造。

----结束