| 今天有點時間，試驗了一下DB2的並發鎖機制，結果，和MSSQL的差不多： 1、DB2的缺省行為，事務以可執行的SQL開始，以COMMIT或ROLLBACK結束； 2、DB2缺省是否提交，以工具的不同而不同，這也是DB2的特點，對外界環境依賴比較明顯，比如：用戶認證就是，依賴操作系統或第三方認證。 3、今天我的試驗過程是這樣： （1）先啟動DB2CLP，db2cmd->db2 （2）連接TEST數據庫，connect to test （3）創建一個試驗表，create table test(id int,aa varchar(10)) （4）驗證表結構，describe table test （5）插入兩行數據，insert into test values(1,'aaaa') insert into test values(2,'bbbb') （6）驗證數據，select * from test h 歷史命令； r n 運行第n條命令； e n編輯第n條命令； （7）update test set aa='cccc' where id=1 （8）啟動另一個DB2CLP,update test set aa='dddd' where id=1,結果沒什么阻塞，大為震驚，都說ORACLE的鎖獨步天下，沒想到DB2的鎖也是獨步天下啊。回頭覺得不對勁，查了一下 DB2的文檔，結果DB2是否自動提交依賴於接口或工具，那么DB2CLP的這個選項缺省是什么呢？ （9）DB2CLP下查各種命令選項，list command options; （10）結果選項c 缺省為ON,打開的，意味着在DB2CLP中，缺省對SQL命令是自動提交的。 （11）把C 選項改為OFF，update command options using c off,注意在每個DB2CLP中都要改，因為這個命令只會影響到當前連接。 （12）修改完三個DB2CLP連接中的C 選項后，開始試驗； （13）第一個DB2CLP中，update test set aa='eeee' where id=1; 第二個DB2CLP中，update test set aa='ffff' where id=1; 結果阻塞；然后在第三個DB2CLP中，update test set aa='GGGG' where id=2; 也是阻塞，說明db2不但阻塞了同行數據的修改，這是正常的，而且也阻塞了不同行但在一個 page頁中的行的修改，看來它得鎖模型也是和MSSQL一樣，屬於悲觀模型。 這段時間把各種系統的鎖模型進行了比較，結果發現，DB2和MSSQL比較相似的，之前，我對MSSQL的鎖進行了更進一步的跟蹤，發現MSSQL對未提交事務涉及的表是加表級鎖的，這會阻塞其他事務對該事務涉及表的修改操作。同時，也會阻塞其他事務的讀操作。 而對於ORACLE和MYSQL來說，是不會產生這種表或塊級阻塞的，主要還是因為鎖模型的不同，主要還是觀念的原因吧，或者說是樂觀和悲觀的原因。談不上誰好誰壞，大家只看到了並發度，而沒看到樂觀鎖會給應用帶來的壞處，就一味的說悲觀鎖不好，不可否認ORACLE等系統的樂觀鎖會帶來系統性能上的好處，讓大家用着會舒服，可應用上的處理就會麻煩些，這也是DB2,MSSQL始終不改變這點的原因，觀念不同而已。 |