说说ORACLE的封锁机制

设立封锁机制主要是为了对并发操作进行控制，对干扰进行封锁，保证数据的一致性和准确性。Oracle数据库封锁方式有三种：共享封锁，独占封锁，共享更新封锁
[b:8f4f63b9bb]封锁类型[/b:8f4f63b9bb]
Oracle　RDBMS的封锁类型可分为如下三类：

１、内部级封锁
内部级封锁是用于保护ORACLE内部结构，由系统内部实现，用户不能访问，因此我们不必对此做过多的了解。

２、DDL级封锁（字典/语法分析封锁）
DDL级封锁也是由ORACLE　RDBMS来控制，它用于保护数据字典和数据定义改变时的一致性和完整性。它是系统在对SQL定义语句作语法分析时自动地加锁，无需用户干予。字典/语法分析封锁共分三类：
（１）、字典操作锁：用于对字典操作时，锁住数据字典，此封锁是独占的，从而保护任何一个时刻仅能对一个字典操作。
（２）、字典定义锁：用于防止在进行字典操作时又进行语法分析，这样可以避免在查询字典的同时改动某个表的结构。
（３）、表定义锁：用于　一个SQL语句正当访问某个表时，防止字典中与该表有关的项目被修改。

３、DML级封锁
DML级封锁用于控制并发事务中的数据操纵，保证数据的一致性和完整性，其封锁对象可以是表或行。
对用户的数据操纵，Oracle可以自动为操纵的数据进行封锁，但如果有操纵授权，则为满足并发操纵的需要另外实施封锁。DML封锁可由一个用户进程以显式的方式加锁，也可通过某些SQL语句隐含方式实现。
DML锁有如下三种封锁方式：
（1）、共享封锁方式（SHARE）
（2）、独占封锁方式（EXCLUSIVE）
（3）、共享更新封锁（SHARE UPDATE）

其中SHARE，EXCLUSIVE用于表封锁，SHARE UPDATE用于行封锁。
1、共享方式的表封锁
共享方式的表封锁是对表中的所有数据进行封锁，该锁用于保护查询数据的一致性，防止其它用户对已封锁的表进行更更新。其它用户只能对该表再施加共享方式的锁，而不能再对该表施加独占方式的封锁，共享更新锁可以再施加，但不允许持有共享更新封锁的进程做更新。共享该表的所有用户只能查询表中的数据，但不能更新。共享方式的表封锁只能由用户用SQL语句来设置，基语句格式如下：
[quote:04b72348bd]LOCK TABLE <表名>[,<表名>]...
IN SHARE MODE [NOWAIT]
[/quote:04b72348bd]
执行该语句，对一个或多个表施加共享方式的表封锁。当指定了选择项NOWAIT，若该封锁暂时不能施加成功，则返回并由用户决定是进行等待，还是先去执行别的语句。
持有共享锁的事务，在出现如下之一的条件时，便释放其共享锁：
A、执行COMMIT或ROLLBACK语句。
B、退出数据库（LOG　OFF）。
C、程序停止运行。
共享方式表封锁常用于一致性查询过程，即在查询数据期间表中的数据不发生改变。

2、独占方式表封锁
独占方式表封锁是用于封锁表中的所有数据，拥有该独占方式表封锁的用户，即可以查询该表，又可以更新该表，其它的用户不能再对该表施加任何封锁（包括共享、独占或共享更新封锁）。其它用户虽然不能更新该表，但可以查询该表。
独占方式的表封锁可通过如下的SQL语句来显示地获得：
LOCK TABLE <表名>[,<表名>]....
IN EXCLUSIVE MODE [NOWAIT]
独占方式的表封锁也可以在用户执行DML语句INSERT、UPDATE、DELETE时隐含获得。
拥有独占方式表封锁的事务，在出现如下条件之一时，便释放该封锁：
（1）、执行COMMIT或ROLLBACK语句。
（2）、退出数据库（LOG OFF）
（3）、程序停止运行。
独占方式封锁通常用于更新数据，当某个更新事务涉及多个表时，可减少发生死锁。

DML锁有如下三种封锁方式：
（1）、共享封锁方式（SHARE）
（2）、独占封锁方式（EXCLUSIVE）
（3）、共享更新封锁（SHARE UPDATE）
其中SHARE，EXCLUSIVE用于表封锁，SHARE UPDATE用于行封锁。

1、共享方式的表封锁
共享方式的表封锁是对表中的所有数据进行封锁，该锁用于保护查询数据的一致性，防止其它用户对已封锁的表进行更更新。其它用户只能对该表再施加共享方式的锁，而不能再对该表施加独占方式的封锁，共享更新锁可以再施加，但不允许持有共享更新封锁的进程做更新。共享该表的所有用户只能查询表中的数据，但不能更新。共享方式的表封锁只能由用户用SQL语句来设置，基语句格式如下：
[quote:04b72348bd]LOCK TABLE <表名>[,<表名>]...
IN SHARE MODE [NOWAIT]
[/quote:04b72348bd]
执行该语句，对一个或多个表施加共享方式的表封锁。当指定了选择项NOWAIT，若该封锁暂时不能施加成功，则返回并由用户决定是进行等待，还是先去执行别的语句。
持有共享锁的事务，在出现如下之一的条件时，便释放其共享锁：
A、执行COMMIT或ROLLBACK语句。
B、退出数据库（LOG　OFF）。
C、程序停止运行。
共享方式表封锁常用于一致性查询过程，即在查询数据期间表中的数据不发生改变。

2、独占方式表封锁
独占方式表封锁是用于封锁表中的所有数据，拥有该独占方式表封锁的用户，即可以查询该表，又可以更新该表，其它的用户不能再对该表施加任何封锁（包括共享、独占或共享更新封锁）。其它用户虽然不能更新该表，但可以查询该表。
独占方式的表封锁可通过如下的SQL语句来显示地获得：
LOCK TABLE <表名>[,<表名>]....
IN EXCLUSIVE MODE [NOWAIT]
独占方式的表封锁也可以在用户执行DML语句INSERT、UPDATE、DELETE时隐含获得。
拥有独占方式表封锁的事务，在出现如下条件之一时，便释放该封锁：
（1）、执行COMMIT或ROLLBACK语句。
（2）、退出数据库（LOG OFF）
（3）、程序停止运行。
独占方式封锁通常用于更新数据，当某个更新事务涉及多个表时，可减少发生死锁。

3、共享更新封锁方式
共享更新封锁是对一个表的一行或多行进行封锁，因而也称作行级封锁。表级封锁虽然保证了数据的一致性，但却减弱了操作数据的并行性。行级封锁确保在用户取得被更新的行到该行进行更新这段时间内不被其它用户所修改。因而行级锁即可保证数据的一致性又能提高数据操作的迸发性。
可通过如下的两种方式来获得行级封锁：
（1）、执行如下的SQL封锁语句，以显示的方式获得：
LOCK TABLE <表名>[,<表名>]....
IN SHARE UPDATE　MODE [NOWAIT]
（2）、用如下的SELECT ...FOR UPDATE语句获得：
SELECT <列名>[,<列名>]...
FROM <表名>
WHERE <条件>
FOR UPDATE OF <列名>[,<列名>].....[NOWAIT]
一旦用户对某个行施加了行级封锁，则该用户可以查询也可以更新被封锁的数据行，其它用户只能查询但不能更新被封锁的数据行．如果其它用户想更新该表中的数据行，则也必须对该表施加行级锁．即使多个用户对一个表均使用了共享更新，但也不允许两个事务同时对一个表进行更新，真正对表进行更新时，是以独占方式封锁表，一直到提交或复原该事务为止。行锁永远是独占方式锁。
当出现如下之一的条件，便释放共享更新锁：
（１）、执行提交（COMMIT）语句；
（２）、退出数据库（LOG　OFF）
（３）、程序停止运行。
执行ROLLBACK操作不能释放行锁。
从上面讲述可见，ORACLE　RDBMS的加锁机制，解决了并发事务的相容与互斥问题。相容保证事务的并发性，互斥确保数据的一致性。不同用户锁的相容与互斥关系由下图给出。

其中最后一行最后一列为其它用户提供在不同行上设置SHARE UPDATE锁。但当用户１在某行上进行更新操作时，用户２只有等待用户１提交事务后，才能更新自己所封锁的行。

中最后一行最后一列为其它用户提供在不同行上设置SHARE UPDATE锁。但当用户１在某行上进行更新操作时，用户２只有等待用户１提交事务后，才能更新自己所封锁的行。

死锁

封锁虽然能够有效的解决并发操作，但是任何资源的独占都会有死锁的危险。例如：有两个事务T1，T2，T1对数据A施加独占封锁，T2对数据B施加了独占封锁。再假设T1要对数据B加锁，由于B已被T2独占封锁，因此T1置于等待状态，等待B被释放；现在若T2也要对A进行封锁，由于A已被T1独占封锁，因此T2也被置于等待状态。这样就形成了两个事务相互等待的状态，而且永远不能结束，此种情况称为死锁。
在Oracle系统中能自动发现死锁，并选择代价最小的，即完成工作量最少的事务予以撤消，释放该事务所拥有的全部锁，记其它的事务继续工作下去。
从系统性能上考虑，应该尽可能减少资源竞争，增大吞吐量，因此用户在给并发操作加锁时，应注意以下几点：
１、对于UPDATE和DELETE操作，应只封锁要做改动的行，在完成修改后立即提交。
２、当多个事务正利用共享更新的方式进行更新，则不要使用共享封锁，而应采用共享更新封锁，这样其它用户就能使用行级锁，以增加并行性。
３、尽可能将对一个表的操作的并发事务施加共享更新锁，从而可提高并行性。
４、在应用负荷较高的期间，不宜对基础数据结构（表、索引、簇和视图）进行修改。


ロック及び排他の説明

一、仕様書より、親テーブル、子テーブル全部更新の場合：

1 親テーブルのレコードをロックする。
＊重複なロックが不要

2 親テーブルのレコードを更新する。
＊業務のフィールド及び最終更新日時を全部更新する
＊最終更新日時が間違い場合、排他エラーが自動に出す、DBに更新できない

3 子テーブルのレコードを更新する。
＊業務のフィールド及び最終更新日時を全部更新する
＊排他しない、最終更新日時が間違い場合、エラーがない、DBに更新できる

二、仕様書より、子テーブルだけ更新の場合：
1 親テーブルのレコードをロックする
＊重複なロックが不要

2 子テーブルのレコードを更新する。
＊業務のフィールド及び最終更新日時を全部更新）
＊排他しない、最終更新日時が間違い場合、エラーがない、DBに更新できる

3 親テーブルのレコードを更新する。
＊最終更新日時だけを更新する
＊最終更新日時が間違い場合、排他エラーが自動に出す、DBに更新できない

三、単表更新の場合：
1 単表レコードを更新する。
＊業務のフィールド及び最終更新日時を全部更新
＊最終更新日時が間違い場合、排他エラーが自動に出す、DBに更新できない