鎖類型選擇的確是Sybase數據庫設計的一個需要重要考慮的問題！也是Sybase開發和管理人員比較頭疼的問題，為此，來點關於lock的介紹性資料！
所支持的加鎖機制
全頁加鎖
全頁加鎖既是一個新術語，它又是由ASE（Adaptive Server Enterprise）在過去所支持的一種加鎖類型。這種類型有下列特性：
對所有可被訪問的頁面在頁面級加鎖
當各種類型的頁面以任何方式發生改變時，對這些排它性的頁面進行加鎖；而且這種加鎖機制一直保持到該事務終止；
當下一個所需的頁面已經成功地獲得，對那些已經釋放的的當前訪問頁進行共享頁面加鎖(如果采用了第三層ANSI隔離，則把這種加鎖機制保持到該事務終止為止)
采用頁級時間印記（timestamp）以確定是否發生改變，詳細信息記錄在事務日志中，以便在系統恢復時以向前或向後方式使用。
這種加鎖方式常常提供性能最高的解決方案，特別是當應用設計時已經考慮了這些特性時更是如此。但是，有一些應用系統，當發生某些活動時，這種對整個頁面進行加鎖的方式就可能會對系統性能產生有重大意義的影響。對於那些面對諸如文件系統或其它已經支持更細小尺度加鎖機制的數據庫廠家產品的一般環境而設計的應用系統而言，這種情況尤其如此。
此外，還存在一系列問題，它們要圍繞著更加困難的條件進行工作。它們通常要采用更加具有Sybase特性的解決方案。對於商用的應用軟件制造廠商而言，對他們是一個挑戰，因為這將要求他們必須跨越他們所支持的數據庫平台，去完成維護其原代碼的工作，而這個工作有相當工作量。在這個領域的基本問題如下：
對已經按照升序值創建的非群聚性索引的最末端葉型頁面存在著爭議
對非群聚性索引的表進行插入和查詢時可能發生死鎖；
在按照群聚性的索引值進行更新和對非群聚性索引的表進行查詢訪問之間可能發生死鎖；
在沒有作索引的表的最後一行可能發生沖突(盡管對最後的特定地址可以使用分區) ；
有可能使行數很少的表之間發生潛在的沖突(盡管對特定的地址可以使用填充因子[ fillfactors]和每頁最大行數[ max_rows_per_page]這兩個參數)
對每個頁面兩邊進行加鎖的需要常常被分割開來；
如果一個表特別小，以致在一個單一頁面中進行駐留，那麼對單一行的訪問實際上將破壞對整個表的加鎖機制。
僅對數據加鎖
僅對數據加鎖機制試圖去解決本文前一節所關注的主要問題(其他的議題將在其它功能領域中加以解決)。這種加鎖方式支持兩類不同的工作方式： 數據行加鎖和數據頁加鎖。在這兩種情況中，對於它們所支持的加鎖方式，都與以前的加鎖機制有所不同。僅對數據加鎖具有下列特性：
在索引頁面中不會破壞事務加鎖。相反，而是采用了一種稱之為鎖存的機制。鎖存是一種類似於旋轉鎖（spinlocks）的同步方法，它們與事務無關並且只保留很短的周期（一般而言，當一個任務在數據庫中物理上改變一小片數據時，這個周期相當於在共享存貯區中在一個2K的頁面改變某些字節數據的時間）一旦完成之後，這個任務將直接打開這個鎖存。當這種情況還可能臨時同其它組塊時 ，因為這種鎖存不能對服務器任務進行有上下文的切換，也不能涉及死鎖，並且只能保持主要的一小段時間，所以它們不能產生有顯著意義的爭用。
采用一個RID對單一行進行數據行加鎖(行標識[RID----Row ID]是邏輯頁號與所在頁面上該行號的組合)；
支持固定的行標識 RIDs, 它可以是向前的，允許不進行其RID的改變，就完成數據行的移動。當一行變大超過了它的可用空間時，采用上述結果對非群聚索引不需要進行任何改變。
不需要進行任何爭用就可以在表的尾部進行插入操作，這一功能已經增加進來。.
支持采用范圍加鎖、下一個關鍵字加鎖和無限大加鎖等方式對邏輯范圍值進行加鎖
支持由最頂層操作所導致的頁面分割。這些情況直接加以提交，"系統"事務可以導致在更短一點的時間周期裡保持分裂的頁面處於鎖定狀態。
為了支持這些變化，需要對采用的存貯表結構進行一系列改善。這些改進的主要效果如下：
群聚索引現在被存貯為象許多人所熟悉的IBM DB2產品所采用的“放置索引”（"placement indexes.”）方式。這種結構類似於非群聚性的索引，需要類似的空間總量。這種修正的結構導致了在數據初始存貯時可以按照順序跨數據頁進行存儲，但是當發生插入時，它們就要盡可能緊密存放以便在正確的邏輯頁面中不存在頁面分割。此外，在數據頁中的數據順序在新行增加時是不進行維護整理的。這種索引的應用使每個群聚化的索引周游增加了一次I/O操作。
行位移表已經增加到索引頁和數據頁中。這種增加和新的行索引行存貯格式具有使每個索引頁面所存貯的索引條目個數減少的潛在能力。
固定行標識（RIDS）。當一行移動時，對於分配新行位置的向前地址被放在用於駐留該行的位置上。當這種移動需要改變非群聚性索引時，對該行的訪問需要增加一次I/O操作以得到‘向前’的位置。
