Oracle多粒度封锁机制研究.docx

Oracle多粒度封锁机制研究.docx

《Oracle多粒度封锁机制研究.docx》由会员分享，可在线阅读，更多相关《Oracle多粒度封锁机制研究.docx（20页珍藏版）》请在冰点文库上搜索。

Oracle多粒度封锁机制研究

Oracle多粒度封锁机制研究

1       引言—数据库锁的基本概念

为了确保并发用户在存取同一数据库对象时的正确性（即无丢失修改、可重复读、不读“脏”数据），数据库中引入了锁机制。

基本的锁类型有两种：

排它锁（Exclusivelocks记为X锁）和共享锁（Sharelocks记为S锁）。

排它锁：

若事务T对数据D加X锁，则其它任何事务都不能再对D加任何类型的锁，直至T释放D上的X锁；一般要求在修改数据前要向该数据加排它锁，所以排它锁又称为写锁。

共享锁：

若事务T对数据D加S锁，则其它事务只能对D加S锁，而不能加X锁，直至T释放D上的S锁；一般要求在读取数据前要向该数据加共享锁，所以共享锁又称为读锁。

2       Oracle 多粒度封锁机制介绍

根据保护对象的不同，Oracle数据库锁可以分为以下几大类：

（1）     DMLlock（datalocks，数据锁）：

用于保护数据的完整性；

（2）     DDLlock（dictionarylocks，字典锁）：

用于保护数据库对象的结构（例如表、视图、索引的结构定义）；

（3）     internallocks和latches（内部锁与闩）：

保护内部数据库结构；

（4）     distributedlocks（分布式锁）：

用于OPS（并行服务器）中；

（5）     PCMlocks（并行高速缓存管理锁）：

用于OPS（并行服务器）中。

本文主要讨论DML（也可称为datalocks，数据锁）锁。

从封锁粒度（封锁对象的大小）的角度看，OracleDML锁共有两个层次，即行级锁和表级锁。

2.1   Oracle的TX锁（行级锁、事务锁）

许多对Oracle不太了解的技术人员可能会以为每一个TX锁代表一条被封锁的数据行，其实不然。

TX的本义是Transaction（事务），当一个事务第一次执行数据更改（Insert、Update、Delete）或使用SELECT…FORUPDATE语句进行查询时，它即获得一个TX（事务）锁，直至该事务结束（执行COMMIT或ROLLBACK操作）时，该锁才被释放。

所以，一个TX锁，可以对应多个被该事务锁定的数据行。

在Oracle的每行数据上，都有一个标志位来表示该行数据是否被锁定。

Oracle不象其它一些DBMS（数据库管理系统）那样，建立一个链表来维护每一行被加锁的数据，这样就大大减小了行级锁的维护开销，也在很大程度上避免了其它数据库系统使用行级封锁时经常发生的锁数量不够的情况。

数据行上的锁标志一旦被置位，就表明该行数据被加X锁，Oracle在数据行上没有S锁。

2.2   TM锁（表级锁）

2.2.1   意向锁的引出

表是由行组成的，当我们向某个表加锁时，一方面需要检查该锁的申请是否与原有的表级锁相容；另一方面，还要检查该锁是否与表中的每一行上的锁相容。

比如一个事务要在一个表上加S锁，如果表中的一行已被另外的事务加了X锁，那么该锁的申请也应被阻塞。

如果表中的数据很多，逐行检查锁标志的开销将很大，系统的性能将会受到影响。

为了解决这个问题，可以在表级引入新的锁类型来表示其所属行的加锁情况，这就引出了“意向锁”的概念。

意向锁的含义是如果对一个结点加意向锁，则说明该结点的下层结点正在被加锁；对任一结点加锁时，必须先对它的上层结点加意向锁。

如：

对表中的任一行加锁时，必须先对它所在的表加意向锁，然后再对该行加锁。

这样一来，事务对表加锁时，就不再需要检查表中每行记录的锁标志位了，系统效率得以大大提高。

2.2.2   意向锁的类型

由两种基本的锁类型（S锁、X锁），可以自然地派生出两种意向锁：

意向共享锁（IntentShareLock，简称IS锁）：

如果要对一个数据库对象加S锁，首先要对其上级结点加IS锁，表示它的后裔结点拟（意向）加S锁；

意向排它锁（IntentExclusiveLock，简称IX锁）：

如果要对一个数据库对象加X锁，首先要对其上级结点加IX锁，表示它的后裔结点拟（意向）加X锁。

另外，基本的锁类型（S、X）与意向锁类型（IS、IX）之间还可以组合出新的锁类型，理论上可以组合出4种，即：

S+IS，S+IX，X+IS，X+IX，但稍加分析不难看出，实际上只有S+IX有新的意义，其它三种组合都没有使锁的强度得到提高（即：

S+IS=S，X+IS=X，X+IX=X，这里的“=”指锁的强度相同）。

所谓锁的强度是指对其它锁的排斥程度。

这样我们又可以引入一种新的锁的类型

共享意向排它锁（SharedIntentExclusiveLock,简称SIX锁）：

如果对一个数据库对象加SIX锁，表示对它加S锁，再加IX锁，即SIX=S+IX。

例如：

事务对某个表加SIX锁，则表示该事务要读整个表（所以要对该表加S锁），同时会更新个别行（所以要对该表加IX锁）。

这样数据库对象上所加的锁类型就可能有5种：

即S、X、IS、IX、SIX。

具有意向锁的多粒度封锁方法中任意事务T要对一个数据库对象加锁，必须先对它的上层结点加意向锁。

申请封锁时应按自上而下的次序进行；释放封锁时则应按自下而上的次序进行；具有意向锁的多粒度封锁方法提高了系统的并发度，减少了加锁和解锁的开销。

2.2.3   Oracle的TM锁（表级锁）

Oracle的DML锁（数据锁）正是采用了上面提到的多粒度封锁方法，其行级锁虽然只有一种（即X锁），但其TM锁（表级锁）类型共有5种，分别称为共享锁（S锁）、排它锁（X锁）、行级共享锁（RS锁）、行级排它锁（RX锁）、共享行级排它锁（SRX锁），与上面提到的S、X、IS、IX、SIX相对应。

需要注意的是，由于Oracle在行级只提供X锁，所以与RS锁（通过SELECT…FORUPDATE语句获得）对应的行级锁也是X锁（但是该行数据实际上还没有被修改），这与理论上的IS锁是有区别的。

下表为Oracle数据库TM锁的相容矩阵（Y=Yes，表示相容的请求； N=No，表示不相容的请求；-表示没有加锁请求）：

       T2

T1

S

X

RS

RX

SRX

-

S

Y

N

Y

N

N

Y

X

N

N

N

N

N

Y

RS

Y

N

Y

Y

Y

Y

RX

N

N

Y

Y

N

Y

SRX

N

N

Y

N

N

Y

-

Y

Y

Y

Y

Y

Y

表一：

Oracle数据库TM锁的相容矩阵

一方面，当Oracle执行SELECT…FORUPDATE、INSERT、UPDATE、DELETE等DML语句时，系统自动在所要操作的表上申请表级RS锁（SELECT…FORUPDATE）或RX锁（INSERT、UPDATE、DELETE），当表级锁获得后，系统再自动申请TX锁，并将实际锁定的数据行的锁标志位置位（指向该TX锁）；另一方面，程序或操作人员也可以通过LOCKTABLE语句来指定获得某种类型的TM锁。

下表总结了Oracle中各SQL语句产生TM锁的情况：

SQL语句

表锁模式

允许的锁模式

Select*fromtable_name……

无

RS、RX、S、SRX、X

Insertintotable_name……

RX

RS、RX

Updatetable_name……

RX

RS、RX

Deletefromtable_name……

RX

RS、RX

Select*fromtable_nameforupdate

RS

RS、RX、S、SRX

locktabletable_nameinrowsharemode

RS

RS、RX、S、SRX

locktabletable_nameinrowexclusivemode

RX

RS、RX

locktabletable_nameinsharemode

S

RS、S

locktabletable_nameinsharerowexclusivemode

SRX

RS

locktabletable_nameinexclusivemode

X

无

表二：

Oracle数据库TM锁小结

我们可以看到，通常的DML操作（SELECT…FORUPDATE、INSERT、UPDATE、DELETE），在表级获得的只是意向锁（RS或RX），其真正的封锁粒度还是在行级；另外，Oracle数据库的一个显著特点是，在缺省情况下，单纯地读数据（SELECT）并不加锁，Oracle通过回滚段（Rollbacksegment）来保证用户不读“脏”数据。

这些都极大地提高了系统的并发程度。

由于意向锁及数据行上锁标志位的引入，极大地减小了Oracle维护行级锁的开销，这些技术的应用使Oracle能够高效地处理高度并发的事务请求。

3       Oracle 多粒度封锁机制的监控

3.1   系统视图介绍

为了监控Oracle系统中锁的状况，我们需要对几个系统视图有所了解：

3.1.1   v$lock视图

v$lock视图列出当前系统持有的或正在申请的所有锁的情况，其主要字段说明如下：

字段名称

类型

说明

SID

NUMBER

会话（SESSION）标识；

TYPE

VARCHAR

（2）

区分该锁保护对象的类型；

ID1

NUMBER

锁标识1；

ID2

NUMBER

锁标识2；

LMODE

NUMBER

锁模式：

0（None），1（null）,2（rowshare）,3（rowexclusive）,4（share）,5（sharerowexclusive）,6（exclusive）

REQUEST

NUMBER

申请的锁模式：

具体值同上面的LMODE

CTIME

NUMBER

已持有或等待锁的时间；

BLOCK

NUMBER

是否阻塞其它锁申请；

表三：

v$lock视图主要字段说明

其中在TYPE字段的取值中，本文只关心TM、TX两种DML锁类型；

关于ID1、ID2，TYPE取值不同其含义也有所不同：

TYPE

ID1

ID2

TM

被修改表的标识（object_id）

0

TX

以十进制数值表示该事务所占用的回滚段号与该事务在该回滚段的事务表（Transactiontable）中所占用的槽号（slotnumber，可理解为记录号）。

其组成形式为：

 0xRRRRSSSS（RRRR=RBSnumber,SSSS=slot）。

以十进制数值表示环绕（wrap）次数，即该槽（slot）被重用的次数；

表四：

v$lock视图中ID1与ID2字段取值说明

3.1.2   v$locked_object视图

v$locked_object视图列出当前系统中哪些对象正被锁定，其主要字段说明如下：

字段名称

类型

说明

XIDUSN

NUMBER

回滚段号；

XIDSLOT

NUMBER

槽号；

XIDSQN

NUMBER

序列号；

OBJECT_ID

NUMBER

被锁对象标识；

SESSION_ID

NUMBER

持有锁的会话（SESSION）标识；

ORACLE_USERNAME

VARCHAR2（30）

持有该锁的用户的Oracle用户名；

OS_USER_NAME

VARCHAR2（15）

持有该锁的用户的操作系统用户名；

PROCESS

VARCHAR2（9）

操作系统的进程号；

LOCKED_MODE

NUMBER

锁模式，取值同表三中的LMODE；

表五：

v$locked_object视图字段说明

3.2   监控脚本

根据上述系统视图，可以编制脚本来监控数据库中锁的状况。

3.2.1   showlock.sql

第一个脚本showlock.sql，该脚本通过连接v$locked_object与all_objects两视图，显示哪些对象被哪些会话锁住：

/*showlock.sql*/

columno_nameformata10

columnlock_typeformata20

columnobject_nameformata15

selectrpad（oracle_username,10）o_name,session_idsid,

      decode（locked_mode,0,'None',1,'Null',2,'Rowshare',

      3,'RowExclusive',4,'Share',5,'ShareRowExclusive',6,'Exclusive'）lock_type,

      object_name,xidusn,xidslot,xidsqn

fromv$locked_object,all_objects

wherev$locked_object.object_id=all_objects.object_id;

3.2.2   showalllock.sql

第二个脚本showalllock.sql，该脚本主要显示当前所有TM、TX锁的信息；

/*showalllock.sql*/

selectsid,type,id1,id2,

       decode（lmode,0,'None',1,'Null',2,'Rowshare',

       3,'RowExclusive',4,'Share',5,'ShareRowExclusive',6,'Exclusive'）

       lock_type,request,ctime,block

fromv$lock

whereTYPEIN（'TX','TM'）;

4       Oracle 多粒度封锁机制示例

以下示例均运行在Oracle8.1.7上，数据库版本不同，其输出结果也可能有所不同。

首先建立3个会话，其中两个（以下用SESS#1、SESS#2表示）以SCOTT用户连入数据库，以操作Oracle提供的示例表（DEPT、EMP）；另一个（以下用SESS#3表示）以SYS用户连入数据库，用于监控；

4.1   操作同一行数据引发的锁阻塞

SESS#1：

SQL>select*fromdeptforupdate;

   DEPTNODNAME         LOC

-------------------------------------

       10account       70

       20research      8

       30sales         8

       40operations    8

SESS#3：

SQL>@showlock

O_NAME      SIDLOCK_TYPE      OBJECT_NAME    XIDUSNXIDSLOTXIDSQN

----------------------------------------------------------------

SCOTT        17Rowshare      DEPT                8      2  5861

SQL>@showalllock

 SIDTY       ID1       ID2LOCK_TYPE         REQUEST     CTIME     BLOCK

------------------------------------------------------------------------

  17TX    524290      5861Exclusive               0       761         0

  17TM     32970         0Rowshare               0       761         0

如第一个脚本showlock所示，执行完SELECT…FORUPDATE语句后， SESS#1（SID为17）在DEPT表上获得Rowshare锁；如第二个脚本showalllock所示，SESS#1获得的TX锁为Exclusive，这些都验证了上面的理论分析。

另外，我们可以将TX锁的ID1按如下方法进行分解：

SQL>selecttrunc（524290/65536）xidusn,mod（524290,65536）xidslotfromdual;

XIDUSNXIDSLOT

-------------

    8      2

分解结果与第一个脚本直接查出来的XIDUSN与XIDSLOT相同，而TX锁的ID2（5861）与XIDSQN相同，可见当LOCKTYPE为TX时，ID1实际上是该事务所占用的回滚段段号与事务表中的槽（SLOT）号的组合，ID2即为该槽被重用的次数，而这三个值实际上可以唯一地标识一个事务，即TRANSACTIONID，这三个值从系统表v$transaction中也可查到。

另外， DEPT表中有4条记录被锁定，但TX锁只有1个，这也与上面的理论分析一致。

继续进行操作：

SESS#2：

SQL>updatedeptsetloc=locwheredeptno=20;

该更新语句被阻塞，此时再查看系统的锁情况：

SESS#3：

SQL>@showlock

O_NAME      SIDLOCK_TYPE      OBJECT_NAME    XIDUSNXIDSLOTXIDSQN

----------------------------------------------------------------

SCOTT        17Rowshare      DEPT                8      2  5861

SCOTT        19RowExclusive  DEPT                0      0     0

SQL>@showalllock

 SIDTY       ID1       ID2LOCK_TYPE         REQUEST     CTIME     BLOCK

------------------------------------------------------------------------

  17TX    524290      5861Exclusive               0      3462         1

  17TM     32970         0Rowshare               0      3462         0

  19TM     32970         0RowExclusive           0         7         0

  19TX    524290      5861None                    6         7         0

在DEPT表上除了SESS#1（SID为17）持有Rowshare锁外，又增加了SESS#2（SID为19）持有的RowExclusive锁，但还没有为SESS#2分配回滚段（XIDUSN、XIDSLOT、XIDSQN的值均为0）；而从第二个脚本看到，SESS#2的TX锁的LOCK_TYPE为None，其申请的锁类型（REQUEST）为6（即Exclusive），而其ID1、ID2的值与SESS#1所持有的TX锁的ID1、ID2相同，SESS#1的TX锁的阻塞域（BLOCK）为1，这就说明了由于SESS#1持有的TX锁，阻塞了SESS#2的更新操作（SESS#2所更新的行与SESS#1所锁定的行相冲突）。

还可以看出，SESS#2先申请表级的TM锁，后申请行（事务）级的TX锁，这也与前面的理论分析一致。

下面，将SESS#1的事务进行回滚，解除对SESS#2的阻塞，再对系统进行监控。

SESS#3：

SQL>@showlock

O_NAME      SIDLOCK_TYPE      OBJECT_NAME    XIDUSNXIDSLOTXIDSQN

----------------------------------------------------------------

SCOTT        19RowExclusive  DEPT                2     10  5803

SQL>@showalllock

 SIDTY       ID1       ID2LOCK_TYPE         REQUEST     CTIME     BLOCK

------------------------------------------------------------------------

  19TX    131082      5803Exclusive               0       157         0

  19TM     32970         0RowExclusive           0       333         0

可以看到，SESS#1的事务所持有的锁已经释放，系统为SESS#2的事务分配了回滚段，而其TX锁也已经获得，并且ID1、ID2是其真正的TransactionID。

再将会话2的事务进行回滚。

SESS#2：

SQL>rollback;

Rollbackcomplete.

检查系统锁的情况：

SESS#3：

SQL>@showlock

norowsselected

SQL>@showalllock

norowsselected

可以看到，TM与TX锁已全部被释放。

4.2   实体（即本表）完整性引发的锁阻塞（带有主键约束的）

DEPT（部门）表有如下字段DEPTNO（部门编号），DNAME（部门名称），LOC（部门位置）；其中DEPTNO列为主键。

SESS#1

SQL>INSERTINTODEPT（DEPTNO）VALUES（50）;

1rowcreated.

SESS#3

SQL>@showlock

O_NAME      SIDLOCK_TYPE      OBJECT_NAME    XIDUSNXIDSLOTXIDSQN

----------------------------------------------------------------

SCOTT         7RowExclusive  DEPT                6