對ORACLE資料鎖的一點體會

該貼的部分內容是針對帖中帶的附件（一位大俠關於鎖的理解），提的理解/疑問，
大家在讀此貼前，請先閱讀該文。


先說說各型別的鎖：共享鎖，排它說，共享排它鎖（對錶定義共享，對錶操作的記錄排它）。

1、我對文章中意向鎖的理解，就是：對錶的記錄進行操作之前，先對錶定義（包括表結構、約束等）
加了共享鎖，這是為了避免對錶的DDL操作。

比如：當你往TAB1插入一條記錄時，該表的一個欄位COL8是允許為空的，插入這條記錄的該欄位
的值是空的，此時，若不對該表定義加共享鎖，則另外一SESSION對TAB1.COL8加非空約束，
那該表結構修改就與插入的記錄發生衝突了。所以，當執行DML操作是，必定對操作的表加DDL
共享鎖。

這是我理解的意向鎖。

2、文章中提及，記錄行是無共享鎖。我對此觀點表示不同：當插入/修改子表時，對應的父表的主鍵
記錄應該被加共享鎖，因為此時要保證父鍵的存在。經，當插入/修改/刪除子表時，父表
確實被加了SS鎖，此時可以對父表的主鍵做插入動作，但不允許做修改/刪除。這符合邏輯。因為
插入操作並不影響主外來鍵的關係。但刪除/修改則可能。


3、SHARE VS ROW SHARE有什麼區別？

我猜想：ROW SHARE是（級別=2）對錶加表定義共享鎖，SHARE（級別=4）是對錶定義及表“所有”的
記錄加共享鎖。但這樣就有問題：1、SELECT FOR UPDATE產生TM=2、對查詢出來的記錄產生TX=6的
鎖，那這樣應該與：表“所有”的記錄加共享鎖 相沖突了？但實際並不是，實際上，當對錶加SHARE
鎖時，還是可以對該表執行 SELECT FOR UPDATE，但卻不可以執行DML操作！

現我只能這樣理解，雖然產生了TX=6 的事務鎖，但實際上，還並沒有真正修改記錄。和真正的
INSERT ，UPDATE， DELETE 操作還是有區別的。也就是：SELECT FOR UPDATE這個鎖有點特別：
對加了共享鎖的記錄，還可以SELECT FOR UPDATE，但若想執行DML語句，則不可以，因為該表的
“所有” 記錄都加了共享鎖。

4、若照第3點的理解，那SRX就是對錶加共享鎖，對錶的所有記錄加排它鎖。這是我的猜測，不知道
在什麼地方會使用上這種鎖。

總結：檢視了ORACLE的文件，其並不解釋如何定義的各級別的鎖，為什麼會這樣定義，理由、用途何
在？現在我想使用各型別鎖，來對ORACLE鎖的各級別定義說明：

0、無
1、NULL，可以某些情況下，如分散式的查詢會產生此鎖。
2、SS，表結構共享鎖
3、SX，表結構共享鎖+被操作的記錄的排它鎖
4、S， 表結構共享鎖+所有記錄共享鎖
5、SRX 表結構共享鎖+所有記錄排它鎖
6、X 表結構排它鎖+所有記錄排它鎖


其中 SELECT FOR UPDATE是比較特殊的一種情況：由於其不修改記錄，所以對這些記錄而言，
並未產生真正的排它鎖，這與DML操作產生的排它鎖相比，是有差別的，但由於不允許在這些記錄“再”
加SELECT FOR UPDATE，所以，也不是純粹的共享鎖，我認為其是介於共享鎖和排它鎖之間的一種特殊
的情況，因此，ORACLE在對錶加了S鎖後，還允許對該表執行SELCT FOR UPDATE，但實際上，此時此語句
已經無意義了，因為加了S鎖的表不允許DML操作，故，此語句於普通的SELECT 語句無差別。
[@more@]對ORACLE資料鎖的一點體會