标签： 锁

南大通用GBase 8a在执行时。为避免并发冲突保证一致性，会持有一些锁来保证自己需要的资源在执行期间不会出现问题。锁在SQL执行完毕后会自动释放掉。在某些特殊场景下，特别是一些老版本集群，出现需要强行释放掉锁的需求，比如SQL长时间无法结束，而该SQL持有的锁又导致其它的SQL无法正常运行，同时环境又不能重启节点服务时，可以考虑本文的方法强行释放SQL持有的锁。

在GBase 8a里，create database是权限最高的DDL语句，其需要一个db_lock独占锁，如果其它SQL在使用该库，则需要等待，从现象看是被卡住了。即使运行create database if not exists一样要等待锁。

南大通用GBase 8a的客户一个业务执行完成后没有释放锁，且没有关闭连接，导致后续该库的其它DDL业务卡住，本文介绍长时间处于checking permissions阶段的SQL的排查和处理方法。

南大通用GBase 8a定位于大数据分析场景，当前已知版本最小的锁粒度为表级(包括表分区级），暂时不支持行级锁。可以选择使用GBase 8s产品，或者UP平台来同时处理8s和8a数据库。

南大通用GBase 计算节点表锁超时参数table_lock_wait_timeout

南大通用GBase 8a数据库集群内部，通过锁机制来实现资源的并行操作，其等待超时参数通过gcluster_lock_timeout设置，默认是0一直等待。

南大通用GBase 8a的数据库集群，提供了gcadmin showlock的管理员命令,查看集群锁的情况。但一个SQL持续处于check permisison状态时，可以通过这个命令找到哪个session在占用这这个表的锁，获得锁的时间等。

南大通用GBase 8a 数据库在做同步时，会先比较主备分片的差异，然后将不同的数据做同步。 本次同步操作完成后，会再次检查是否已经一致。如果一致则清理掉异常标记，如果还有差异，则会再次同步。这个机制如果遇到了频繁变动的表，比如一直在加载，且频率很高，至少入库时间短于一次同步的时间，就会造成同步一直无法完成的情况。