GBASE 8s活锁、死锁问题的解决

        锁的问题(锁等待、死锁)大部分由于没有正确理解锁的管理、使用方式导致。要解决锁的问题，我们可以从如下几个方面进行尝试。

        1.GBase8s 数据库锁资源的设置 ONCONFIG 参数 LOCKS 设置即为数据库配置数量合适的锁。通过搜索online 日志是否有动态增加锁的情况：grep 'dynamically allocated' online.log 为表设置合理的锁模式、行级锁或者页级锁。

        2.应用程序锁使用模式设置 通过 onstat -g sql 查看 SESSION 使用的锁等待模式和隔离级别，要为不同的应用设置合理的隔离级别和锁等待模式。如在应用程序加入如下语句：

        set isolation to dirty read;

        set lock

        3．应用程序避免使用不必要的锁 许多应用程序的 SQL 语句由于没有正确地使用索引 INDEX，导致对整个表进行了锁定，导致并发遇到锁的问题。需要通过 SQL 优化和创建合理的索引，避免顺序扫描带来的锁冲突问题。

        由于顺序扫描导致的锁等待问题：创建表 test_lock，采用行级锁，并在c1 字段上创建索引，插入 3 行测试数据。

        create table test_lock (c1 int,c2 int,c3 char(10)) lock mode row;

        create index idx_test_lock on test_lock(c1);

        insert into test_lock values(1,1,'abc');

        insert into test_lock values(2,2,'abc');

        insert into test_lock values(3,3,'abc');

        Session 1 通过索引扫描来修改第 2 行记录：   

      Begin work;

        update test_lock set c3='new' where c1=2;

        此时，Session 1 将在第二行记录上加 X 锁。

        Session 2 通过 c2 字段以顺序扫描的方式来修改第 3 行记录。 

       Begin work;

        update test_lock set c3='new' where c2=3;

        由于 Session 2 采用顺序扫描方式，在扫描过程中发现第2 行记录加上了X锁，故提示锁冲突错误：

        244: Could not do a physical-order read to fetch next row.

        107: ISAM error: record is locked.

        如果在 c2 字段上加上索引，或者通过 c1=3 修改第三行记录，那么就不会出现锁的问题。

        4．应用程序优化避免过长占用锁 锁是一个公共资源，需要尽快释放锁资源，减少等待，如果每个事务都可以在微秒级别完成，那么锁就不会是我们关注的问题，减少锁占用的时间也是解决锁问题的关键。我们可以通过避免大事务，把大事务拆分多次提交，这样锁就能尽快释放。另外，优化应用的处理性能，如合理使用索引等，都可以加快事务的处理速度，可无形中解决锁冲突的可能性。

        5．设置合理的隔离级别 不同的隔离级别对锁的使用不一样，设置合理的隔离级别，可以提高应用程序的并发性，提高系统的处理能力，减少锁的冲突情况，避免读操作带来的锁问题。