INFORMIX的鎖技術

 
       INFORMIX使用鎖技術解決在多用戶訪問數據庫情況下,對同一對象訪問的併發控制問題。INFORMIX支持複雜的、可伸縮性的鎖技術。 

 鎖的類型 

          INFORMIX有三種不同類型的鎖。它們在不同的情況下使用。 
           1. SHARED鎖 
               SHARED鎖只保留對象的可讀性。當鎖存在時,對象不能改變。多個程序可對同個對象加SHARED鎖。 
            2. EXCLUSIVE鎖 
                只能使單個程序使用。在程序要改變對象時使用。當其他鎖存在時,EXCLUSIVE鎖不能使用。當使用了EXCLUSIVE  鎖後,其他鎖不能用於同一對象。 
            3. PROMOTABLE鎖 
                 實現更新的目的。PROMOTABLE鎖可以放在已經有SHARED鎖的記錄,但不能放在已經有PROMOTABLE鎖和EXCLUSIVE鎖的地方。當記錄上無其他鎖(含SHARED 鎖)情況下,這時在程序準備改變鎖的記錄時,PROMOTABLE鎖可以提升爲EXCLUSIVE鎖。如果在已有SHARED鎖的記錄上設置了PROMOTABLE鎖,在PROMOTABLE鎖可以提升到EXCLUSIVE鎖之前需要刪除SHARED 鎖。PROMOTABLE鎖只能在INFORMIX Universal Server中支持。
鎖的範圍 
                            
         INFORMIX對於數據鎖定提供了三種不同的方式,範圍由大到小分別是數據庫、表、記錄級鎖。使用的時機要看應用狀況而定。 

     1. 數據庫級鎖 
         你可以用CONNECT, DATABASE, 或 CREATE   DATABASE語句打開數據庫。打開數據庫的操作就在數據庫上設置了SHARED鎖。只要程序打開一個數據庫,SHARED鎖就會阻止其他程序刪除數據庫或在數據庫上設置EXCLUSIVE鎖。你可以用語句DATABASE 
         database name EXCLUSIVE鎖定整個數據庫。若此時其他用戶正在使用該數據庫,該操作將返回錯誤。 
          一旦設置了EXCLUSIVE鎖,其他程序就不能打開數據庫,因爲打開時要放置一個SHARED鎖。只有數據庫關閉時,數據庫鎖才釋放。你可以用DISCONNECT或CLOSE  DATABASE顯示地處理,也可以運行其他的DATABASE語句隱含的處理。一般數據庫級EXCLUSIVE鎖是獨佔數據庫資源,防止其他程序訪問數據庫。它使得程序非常簡單,不會產生併發效果。常用在非高峯時期要改變大量數據時如數據庫備份過程。 

 2. 表級鎖 
            INFORMIX提供兩種模式表級鎖:EXCLUSIVE MODE 和SHARE   MODE。你可以鎖整個表。在某些情況下,這個操作是自動進行。當INFORMIX處理下列語句時,一般鎖整個的表:
ALTER  INDEX 、ALTER TABLE 、CREATE INDEX、DROP INDEX 、RENAME COLUMN、RENAME TABLE 。該語句結束或事務結束會釋放該鎖。在某些查詢語句中,INFORMIX也自動鎖整個表。 
         你可以用LOCK   TABLE語句顯示地鎖整個表。該語句允許你對整個表設置EXCLUSIVE鎖或SHARED鎖。當你程序從表中讀取數據時,SHARED鎖防止表中數據更新。INFORMIX   Universal Server 通過設置隔離級別實現更大程度併發數據保護。 
        表級EXCLUSIVE鎖防止對同個表的併發使用。因此,如果其他許多程序要使用該表時,系統性能會受到嚴重影響。類似數據庫級EXCLUSIVE鎖,表級EXCLUSIVE鎖常用在非高峯時期要改變大量數據時。例如,有些應用在高峯期間並不更新表,它們可以在非高峯期間定期以批處理方式更新。
       通過UNLOCK TABLE table name 解除鎖。當存在事務時,事務結束時解除鎖。 
 3. 記錄級、頁級、鍵字級鎖 
                            
         表的一個記錄是可設置鎖的最小對象。一個程序可以鎖一個記錄或記錄的集合,同時其他程序可以操作同一個表的其他記錄。Universal Server 以磁盤頁面(disk pages)爲單位存儲數據。一個磁盤頁面包含一個或多個記錄。在有些情況下,頁級鎖比單個鎖更好些。其他數據庫服務器可能不存在頁級、鍵字級鎖。
         在Universal   Server上,當你創建表時,你可以選擇使用記錄級鎖或頁級鎖。其他的數據庫服務器不提供這種選擇。頁級、記錄級鎖有相同的效果。當Universal Server需要鎖一個記錄時,根據表創建時的鎖模式,鎖這個記錄或記錄所在的頁面。在一定情況下,數據庫服務器需要鎖一個不存在的記錄。它的效果相當於在記錄將要存在的地方放一個鎖。當表使用記錄鎖時,對假想的記錄使用鍵字鎖。當表使用頁級鎖時,含有或可能含有鍵字的索引頁將被設置鍵級鎖。 

 鎖的時期 
         程序控制數據庫級鎖的時期。數據庫關閉時,數據庫鎖級也就釋。表級、記錄級、索引級鎖的時期依賴於使用的SQL語句以及是否使用事務。如果數據庫沒有使用事務,也就是說,事務日誌不存在並且你沒有使用COMMIT WORK語句,當運行UNLOCK  TABLE語句時,表級鎖就釋放。當使用了事務時,事務結束,表級、記錄級、索引級鎖都釋放。修改時鎖的處理 
          當數據庫服務器通過一個更新遊標取一條記錄時,它在該記錄上設置一個PROMOTABLE鎖。如果這個動作成功,數據庫服務器知道其他程序不能改變此記錄。因爲PROMOTABLE鎖不是獨佔的,其他程序能夠繼續讀這條記錄。由於在取此記錄的程序執行UPDATE、DELETE語句或簡單地取下一條記錄之前,它可能花一些時間。這樣就提高了性能。當它改變一個記錄時,數據庫服務器在這條記錄上設置一個EXCLUSIVE鎖。如果它已經有一個PROMOTABLE鎖,它將鎖改爲EXCLUSIVE狀態。 
 EXCLUSIVE鎖的時期依賴於是否使用事務。如果沒有使用事務,被修改的記錄寫到磁盤上就會釋放該鎖。當使用了事務時,鎖就會保持到事務的結束。這個動作防止其他程序使用可能回滾到原來狀態的記錄。
        當使用了事務時,只要刪除記錄鍵級鎖就會設置。使用鍵級鎖解決下列錯誤:程序A刪除一個記錄,程序B插入有同樣鍵的記錄。程序A回滾事務,使數據庫服務器恢復了刪除的記錄,這時程序B插入的記錄怎麼辦?通過鎖索引,數據庫服務器等到程序A提交事務時才插入記錄。
     由於 Universal  Server數據庫服務器管理自己的鎖,所以它能提供不同類型的鎖。其他的數據庫服務器是通過操作系統的特性實現鎖,所以不能提供多種選擇。有些操作系統通過操作系統服務方式向外提供鎖函數。在這些系統,數據庫支持SET  LOCK  MODE語句。而有些操作系統不支持內核級的特性,數據庫這時通過在數據庫目錄下產生小文件實現鎖。這些文件帶有.lok後綴。如果你的程序使用單個SELECT語句或沒有用FOR  UPDATE聲明的遊標提取一個記錄,此記錄不管是否被一個未完成的交易上鎖會馬上被提取。這樣能產生最好的性能。當你使用FOR    UPDATE聲明的遊標時,它在提取前將當前記錄上鎖。如果當前記錄已經有鎖,隨着選擇模式的不同,程序會等待或返回錯誤。當取下一個記錄時,數據庫看當前記錄是否更新(使用帶WHERE CURRENT OF 的UPDATE 鎖的模式 )
    鎖的模式決定程序遇到被鎖的數據會產生怎樣的結果。當程序要提取或修改一個上鎖的記錄時,會有下面幾種情況:
                            1、 數據庫馬上通過SQLCODE變量或SQLSTATE結構給程序返回一個錯誤代碼。
                            2、 在數據解鎖前,數據庫將程序掛起。
                            3、數據庫將程序掛起一段時間。如果鎖還未解,數據庫給程序返回一個錯誤代碼。 
    你可以通過SET LOCK MODE模式選擇以上結果。 
     如果你喜歡程序等待(對大多數程序而言這是最好的選擇),運行下列語句:SET LOCK MODE TO WAIT。 
                           
    當設置了鎖模式後,程序常忽視其他併發程序的存在性。如果程序需要訪問其他程序已上鎖的記錄時,它等待別的程序解鎖,然後繼續。延遲的時間常不可預測。
    等待解鎖不利的一面就是可能會等待很長時間。如果不能接受很長延遲,程序可以運行下列語句:SET LOCK   MODE TO    NOT   WAIT選擇不等待。當程序需要一個鎖記錄時,它馬上返回一個錯誤代碼,且當前的SQL語句終止。這時,程序必須回滾當前的交易再試一次。程序開始時,數據庫初始設置爲不等待。
     當你使用UNIVERSAL SERVER時,你有另外的選擇。你可以讓數據庫設置等待時間的上限。你可用下列語句:SETLOCK MODE TO WAIT 18讓數據庫有18秒等待上限。若期間鎖還沒有解開,將返回錯誤代碼。 
          在每個程序都選擇了鎖等待模式情況下,有可能出現死鎖。死鎖是程序之間相互阻塞,每個程序在其他程序要訪問的對象上設置了鎖。UNIVERSAL   SERVER在單個網絡服務器情況下會馬上檢測到死鎖。如果程序選擇了鎖等待模式,通過給程序返回錯誤代碼,你就知道你遇到了死鎖。而在多個數據庫服務器的情況下,UNIVERSAL  SERVER不能馬上檢測到。每個數據庫服務器都設置鎖等待的上限。如果超時,數據庫服務器就認爲發生了死鎖且返回相關的錯誤代碼。數據庫管理員可以設置和修改等待時間的上限。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章