inix锁信息 问题介绍.doc

1、 理解2锁什么是锁？锁 是一种软件机制，用于控制对数据库中的数据的访问。在出现同时读取和更新数据的多用户环境中，锁能够确保每个事务的原子性、隔离、一致性和持续性（ACID）不受到威胁，并且维护数据的完整性。锁的粒度Informix 提供各种粒度的锁。它们是： 数据库锁：针对整个数据库的锁 表锁：针对整个表的锁 页锁：针对整页数据的锁 行锁：针对一个数据行的锁 字节锁：在包含 VARCHAR 的行上的锁 键锁：在索引中的一个键值上的锁 锁的粒度越粗，它就能锁住越多的数据库对象。例如，对于能够在一个磁盘页上包含 4 行的表，在该页放置一个锁将锁住其中包含的所有 4 个行。相反，如果使用行锁，那么将仅锁住一个行。因此，锁的粒度越粗，并发性就越低，从而影响到性能，尤其是应用程序试图访问相同的行集时。不过，粗粒度也意味着在某些情况下锁住相同数量的行需要的锁数量更少。例如，锁住整个表仅需要一个表锁。表的锁模式创建一个表时，它的默认锁粒度是页锁。可以在创建表的过程中使用 LOCK MODE 子句覆盖默认值。例如：CREATE TABLE t1(c1 int) LOCK MODE ROW;这个上下文中的锁模式表明访问表时需要使用的锁的粒度。如果从 CREATE SQL 语句省略掉这个 LOCK MODE 子句，那么就使用默认的锁模式。 如果表已经创建，那么可以使用 ALTER TABLE 语句更改锁模式。对于以上提到的表 t1 例子，您可以使用下面的 ALTER 语句将锁模式从行锁更改页锁：dbaccess db1 -ALTER TABLE t1 LOCK MODE(PAGE);可以使用配置参数 DEF_TABLE_LOCKMODE 更改已创建的表的默认锁模式。该参数的值可以是 ROW 或 PAGE。例如，如果 DEF_TABLE_LOCKMODE 设置为 ROW，那么数据库服务器重启之后创建的表的默认锁模式将为 ROW。类似地，可以使用环境变量 IFX_DEF_TABLE_LOCKMODE 实现相同的效果。注意：如果从运行 oninit 以启动服务器的窗口设置环境变量，那么通过环境变量指定的默认锁模式将对所有会话有效。然而，如果仅在特定客户端会话环境中设置锁模式，那么它仅对特定会话有效。清单 1 - 4 显示了检查表的锁模式的不同方法（表名为 t1；数据库名为 db1）：清单 1. 使用 dbschemadbschema -d db1 -t t1 -ss 清单 2. 输出create table informix.t1 ( c1 integer ) extent size 16 next size 16 lock mode row;清单 3. 使用 oncheckoncheck -pt db1:t1Output:TBLspace Report for db1:informix.t1 Physical Address 1:64070 Creation date 07/14/2009 04:51:27 TBLspace Flags 802 Row Locking TBLspace use 4 bit bit-maps Maximum row size 4 Number of special columns 0 Number of keys 0 Number of extents 1 Current serial value 1 Current SERIAL8 value 1 Current BIGSERIAL value 1 Current REFID value 1 Pagesize (k) 2 First extent size 8 Next extent size 8 Number of pages allocated 8 Number of pages used 1 Number of data pages 0 Number of rows 0 Partition partnum 1049067 Partition lockid 1049067 Extents Logical Page Physical Page Size Physical Pages 0 1:64999 8 8清单 4. 使用 dbaccess 从数据库的系统目录表查询系统表dbaccess db1 - select * from systables where tabname=t1;tabname t1owner informixpartnum 1049067tabid 100rowsize 4ncols 1nindexes 0nrows 0.00created 07/14/2009version 6553601tabtype Tlocklevel Rnpused 0.00fextsize 16nextsize 16flags 0sitedbnametype_xid 0am_id 0pagesize 2048ustlowtssecpolicyid 0protgranularity字段 “locklevel” 为 R，表明这是一个行锁。另外，使用 onstat -k 来监控锁模式。这将在 “使用 onstat 实用程序监控锁” 小节进行介绍。回页首锁的类型数据库、表、页和行（在这个小节中统称为对象）通过不同类型的锁来控制对自身的访问。IDS 使用以下类型的锁：共享锁当需要读取数据并且不允许更改行时，那么就可以在该对象（比如表、页或行）上设置一个共享锁。一个对象可以由不同的会话设置多个共享锁。因此，可以在需要时在一个对象上设置多个共享锁。更新/提升锁可以在需要更新的对象上设置更新锁。如果一个对象已经设置了共享锁，另一个会话还可以在其上设置一个更新锁。如果需要更改对象，那么更新锁必须提升为独占锁。不过，为了实现独占锁，在提升过程中该对象不能包含共享锁或更新锁。独占锁当一个会话请求单独使用某个对象时，可以在该对象上放置一个独占锁。如果一个对象上已经放置了独占锁，那么其他会话就不能再在该对象上放置其他类型的锁。INSERT、UPDATE 和 DELETE 语句在它们所更改的行上使用这个锁。在事务完成之后将释放该锁。onstat 实用程序和 syslocks 表使用以下符号表示锁的类型： 共享锁 - S 更新锁 - U 独占锁 - X 在某些情况下，可以通过放置一个意向锁（intent lock）来表明要放置特定锁的意向。例如，意向共享锁的表示符号为 IS。在使用 SELECT 语句期间通常可以在表上看到 IS 锁。在使用 INSERT、UPDATE 或 DELETE 语句期间通常可以在表上看到意向独占锁。 表 1 使用这些符号列出了一个兼容性矩阵，显示当一个会话已经在某个对象上放置了特定的锁时，另一个会话可以在该对象上请求的锁。表 1. 锁兼容性矩阵持有 X 锁持有 U 锁持有 S 锁持有 IS 锁持有 SIX 锁持有 IX 锁请求 X 锁No No No No No No 请求 U 锁No No Yes Yes No No 请求 S 锁No Yes Yes Yes No No 请求 IS 锁No Yes Yes Yes Yes Yes 请求 SIX 锁No No No Yes No No 请求 IX 锁No No No Yes No Yes 回页首锁请求失败当会话请求锁失败时，数据库服务器的默认行为是返回一个错误。要让该会话等待拥有锁的会话释放锁，请在运行预定语句之前运行以下 SQL 语句：SET LOCK MODE TO WAIT;这将让会话一直等到锁释放。如果要设置固定的等待期限（例如，5 秒），则使用以下语句：SET LOCK MODE TO WAIT 5;回到默认行为：SET LOCK MODE TO NOT WAIT;SET LOCK MODE 语句仅在会话级别有效。我们通过以下例子查看锁模式的行为：清单 5. 开始会话dbaccess - -DROP DATABASE db1;CREATE DATABASE db1 WITH BUFFERED LOG;CREATE TABLE t1 (c1 int);INSERT INTO t1 VALUES (1);清单 6. 会话 Adbaccess db1 -BEGIN WORK;UPDATE t1 SET c1=5;清单 7. 会话 Bdbaccess db1 -SELECT* FROM t1;清单 8. 收到的错误244: Could not do a physical-order read to fetch next row.107: ISAM error: record is locked.清单 9. onstat -g sql 输出$ onstat -g sqlIBM Informix Dynamic Server Version 11.50.FC4 - On-Line - Up 1 days 06:16:34 - 149504 KbytesSess SQL Current Iso Lock SQL ISAM F.E.Id Stmt type Database Lvl Mode ERR ERR Vers Explain30 - db1 CR Not Wait 0 0 9.24 Off输出结果显示 db1 的隔离级别为 “Committed Read”（后面将讨论隔离级别）。因为表 t1 上有一个未提交的更新，错误提示需要使用锁定的记录。 让我们在会话 B 中尝试使用 SET LOCK MODE WAIT 语句：SET LOCK MODE TO WAIT;SELECT* FROM t1;这个会话并没有立即返回错误，而是等待锁释放。现在，在会话 A 中，完成事务：COMMIT WORK;在会话 B 中，现在是等待提交结束之后才返回查询结果。2、 死锁当两个会话都持有它们需要使用的锁时就会导致死锁。结果是两个会话都等待对方释放锁。不过，数据库服务器可以检测到这种情况并阻止它发生。例如：T1：读取行 A 并在其上放置一个锁。T2：读取行 B 并在其上放置一个锁。T1：在行 B 上请求一个锁。T2：在行 A 上请求一个锁。IDS 维护一个内部锁表。为了防止出现死锁，IDS 将检查内部锁表，查看在会话等待锁期间是否会导致死锁。发生的情况如下所示：T1：将锁模式设置为等待。T2：将锁模式设置为等待。T1：读取行 A 并在其上放置一个锁。T2：读取行 B 并在其上放置一个锁。T1：在行 B 上请求一个锁；必须等待 T2 在行 B 上释放该锁。T2：在行 A 上请求一个锁，但被拒绝了，因为等待该锁的释放会导致死锁。IDS 从内部锁表检测到： T1 持有行 A 上的锁 T2 持有行 B 上的锁 T1 等待 T2 持有的行 B 上的锁 如果允许 T2 等待 T1 在行 A 上持有的锁，那么将出现死锁。因此，锁请求被拒绝，并返回错误 (-143 ISAM error: deadlock detected)。检查 onstat -p 的输出看看是否有死锁：清单 10. 检查 onstat -p 输出中的死锁$ onstat -pIBM Informix Dynamic Server Version 11.50.FC4 - On-Line - Up 2 days 22:34:37 - 157696 KbytesProfiledskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached13851 44301 1894394 99.27 22604 41159 429311 94.73isamtot open start read write rewrite delete commit rollbk1178884 64495 88313 413795 46723 58450 5657 17833 16gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs0 0 0 0 0 0 0ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes0 0 0 89.23 13.32 366 70849bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans191 0 750183 5 0 6 4010 6770ixda-RA idx-RA da-RA RA-pgsused lchwaits231 2 3080 3313 254查看 “deadlks” 字段，您可以看到在数据库服务器上线至今发生了 5 个死锁事件。如果频繁发生死锁，请检查应用程序并交错使用频繁更改的行。通过减少锁等待时间可以降低出现死锁的几率。对于分布式事务，会话在返回错误之前使用 DEADLOCK_TIMEOUT 配置参数等待来自远程数据库的响应。在 onstat -p 输出中的 “dlouts” 字段显示分布式死锁超时的统计数据。日志和非日志数据库在日志数据库中，数据库服务器记录其事务以及在事务期间持有的锁。一般都能够识别到事务持有的锁，除非事务没有提交或被回滚。非日志数据库中没有事务，但仍然使用锁。尽管很容易错过，但是服务器在执行 Data Manipulation Language 时使用锁，并且在该语句完成之后快速释放锁。3、 监控锁onstat 实用程序监控锁数据库服务器使用的锁保持在一个内部锁表中。使用 onstat -k 命令可以监控数据库服务器持有的锁的类型和粒度。onstat -k 命令的输出包含以下字段：表 2. onstat -k 命令输出包含的字段字段说明address锁表中的锁的位置。如果用户线程正在等待这个锁，那么该锁的地址就会出现在 onstat -u（用户）输出的 wait 字段中。wtlist等待锁的用户线程列表的第一项，如果存在的话。owner持有锁的线程的共享内存地址。这个地址与 onstat -u（用户）输出中的 address 字段中的地址对应。当持有者值显示在圆括号中时，它表示事务结构的共享内存地址。仅当为全局事务分配锁时才会发生这种情况。这个地址与 onstat -G 输出的 address 字段对应。lklist刚才列出的持有者持有的链接锁列表中的下一个锁。type使用以下符号表示锁的类型： HDR - 头部 B - 字节 S - 共享 X - 独占 I - 意向 U - 更新 IX - 意向独占 IS - 意向共享 SIX - 共享意向独占 tblsnum行标识号码。rowid 提供以下锁信息： 如果 rowid 为 0，那么这个锁是一个表锁。 如果 rowid 以两个 0 结尾，那么这个锁是一个页锁。 如果 rowid 小于等于 6 位数并且不以 0 结尾，那么这个锁可能是一个行锁。 如果 rowid 大于 6 位数，那么该锁可能是一个索引键-值锁。 key#/bsiz索引键值号，或为 VARCHAR 锁锁定的字节数。如果这个字段包含 “K-” 并且其后接一个值，那么这是一个键锁。该值标识要锁住的索引。例如，K-1 表示为表定义的第一个索引包含一个锁。回页首onstat -k 命令的示例输出这个例子使用不遵从 ANSI 的日志数据库和两个表：CREATE DATABASE db1 WITH LOG;CREATE TABLE t1 (c1 int);CREATE TABLE t2 (c1 int) LOCK MODE ROW;以下值被插入到这两个表中：INSERT INTO t1 VALUES (1);INSERT INTO t2 VALUES (1);INSERT INTO t2 VALUES (2);执行以下语句：BEGIN WORK;UPDATE t1 SET c1=5;UPDATE t2 SET c1=5;onstat -k 的输出：清单 11. onstat -k 的输出$ onstat -kIBM Informix Dynamic Server Version 11.50.FC4 - On-Line - Up 2 days 21:39:44 - 157696 KbytesLocksaddress wtlist owner lklist type tblsnum rowid key#/bsiz10a3134d8 0 111535cd8 0 HDR+S 100002 204 010a44bcd8 0 111535488 0 S 100002 204 010a44bd58 0 111536528 0 S 100002 204 010a44c4d8 0 111537e18 0 HDR+S 100002 202 011348b028 0 111537e18 10a44c4d8 HDR+IX 1001ef 0 011348b0a8 0 111537e18 11348b028 HDR+X 1001ef 100 011348b128 0 111537e18 11348b0a8 HDR+IX 1001f0 0 011348b2a8 0 111537e18 11348b128 HDR+X 1001f0 101 0 U11348b328 0 111537e18 11348b2a8 HDR+X 1001f0 102 0 U 9 active, 80000 total, 16384 hash buckets, 2 lock table overflows该输出包含以下信息： 表锁： o 查看地址为 11348b028 的行，其 rowid 为 0，表明这个锁是表锁。IX 表明其类型为意向独占。 页锁： o 查看地址为 11348b0a8 的行，其 rowid 的最后两位为 00，表明这个锁是页锁。类型 X 表明它是独占锁。这是针对 t1 的，它使用页级锁模式。 行锁： o 查看地址为 11348b328 的行，其 rowid 为 0x102，表明这个锁是行锁，在这里为独占锁。这是针对 t2 的，它使用行级锁模式。 数据库锁： o 查看地址为 10a3134d8 的行，表上有一个行锁。不过，tblsnum 0x100002 是一个数据库 tblspace，它是在服务器中保持数据库列表的特殊表。因此，它行上的锁相当于锁定数据库。类型 S 表明该锁是一个共享锁。 要在 onstat -k, 中找出 tblsnum 的表名，需要对 systables 表使用以下语句：清单 12. 识别 tbslnum 的表名SELECT * FROM systables WHERE partnum=1049072;Output:tabname t2owner informixpartnum 1049072tabid 101rowsize 4ncols 1nindexes 0nrows 0.00created 07/20/2009version 6619137tabtype Tlocklevel Rnpused 0.00fextsize 16nextsize 16flags 0sitedbnametype_xid 0am_id 0pagesize 2048ustlowtssecpolicyid 0protgra