鎖類型選擇的確是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操作以得到‘向前’的位置。
一般而言，索引將更小和更短，這是因為如下原因：
從每個葉級頁面中采用雙重鍵限制機制來限制雙重鍵（Duplicate key）例如，如果值“綠”（"GREEN”）在下列行標識（RIDs）值等於123-1，234-2，和345-3的行中, 就分別存貯值“綠”（"GREEN”），123-1，234-2，345-3，而不是存貯值“綠”（"GREEN,”）三次。在每個索引頁中每個值只存貯一次。
在非群聚性索引樹的非葉型結點中將後綴實行壓縮(例如，如果鍵值是"GREEN”和"HAMILTON”，而在這兩個值之間發生分裂，那麼就在非頁級索引頁面中存儲"G”和"H”)。
數據頁和數據行加鎖
只對數據加鎖機制支持兩種方式：數據頁加鎖和數據行加鎖。這些與它們的工作方式和所提供的功能相類似。這兩種方式僅在對數據訪問產生阻礙作用時，在加鎖的尺度上有所區別。在數據頁加鎖方式下再采用數據行加鎖方式具有兩種作用（一種起正向作用，另一種起反向作用）。首先，較小尺度加鎖機制的使用可能導致減少爭用與沖突，然而當大量數據發生變化時，就有可能對加鎖產生大量阻礙的情況發生。
特定使用的加鎖類型
除非對配置參數加以特定，對所有的表都予置了隱含的全頁面加鎖機制。
sp_configure ‘lock scheme’, [allpages | datapages | datarows]
當數據庫從原先版本的服務器中轉儲出來重新加載時，所有的表都被定義為全頁面加鎖的表。當建立一個新表時，可以不使用這個缺省值，可采用如下的句法格式：
create table <tablename>;… lock [allpages | datapages | datarows]
為了在使用的一個表中改變加鎖類型，可以采用如下的句法格式：
alter table <tablename>; lock [allpages | datapages | datarows]
在一個現存的表中改變加鎖方式，將引起下列三種行動後果發生：
首先，如果一張表從全頁加鎖轉變為僅對數據加鎖，或者從僅對數據加鎖轉變為全頁加鎖，在這兩種類型之間就要對表進行選擇以允許進行存貯格式改變。如果這是一個分區表，就要同時假定必要的並行級別和工作線程已經配置好的情況下，才能執行。
其次, 對表中的群聚性索引必須重新創建。因為我們能保證數據，所以如果從全頁加鎖方式轉換為只對數據加鎖時，這種重新創建可以通過"with sorted_data"來完成。然而，當從僅對數據加鎖機制轉換為全頁加鎖方式時，就要進行並行的索引創建操作。（請注意：如果這是一個分區表時，那麼並行等級和工作線程的數目必須加以配置才能允許進行這種改變，否則這種遷移將會失敗）
最後，非群聚性的索引將被重建，如果服務器已經為並行處理所加以配置，當進行本步驟時將加以采用。
由於這些活動同潛在的工作量有關，從全頁加鎖機制改變為僅對數據加鎖或從僅對數據加鎖改變為全頁加鎖機制都可能是耗費時間的活動。為了標注這一點，有以下一些選擇：
如果可能的話，應該配置使用並行方式。這至少對執行非群聚性索引的哈斯（雜湊，即hashed）創建方法是必須的，但是如果可能的話，采用分區表和分區掃描將使系統得到更大的改進。
在選擇進入和創建群聚性的索引之後，該任務將被設置檢查點（checkpointed ）所以，如果有充分的硬件資源，通過允許在任何一個時間點上，檢查點任務可以具有多於10個（系統缺省值）的異步I/O請求，利用dbcc進行調諧將能夠帶來有益的效果。(‘maxwritedes’, number)
進一步作為降低使用檢查點成本的一種方法，在相關的高速緩沖池（cache pool）、大數據量的I/O操作中，采用對高淘汰程度進行標記的方法，並允許清潔程序（好象家庭主婦一樣）保持特別活躍的狀態，將為那些檢查點需要從高速緩沖池中刷新較“髒”的頁面的而增加的I/O操作次數，並因此花費了在檢查點上的時間，都能夠大大減少作出貢獻。
如果預先進行了配置，則可以對並行的選擇進入可以使用預先分配的盤區。所以，通過將sp_configure number of pre-allocated extents設置為16也將對系統性能有明顯的積極的效果。
備注：在僅對數據加鎖類型之間進行改變不需要對數據進行備份， 而且執行起來只需很短的一段時間。
[以上為摘自sybase公司站點上的資料]
據我個人使用經驗，我覺得對於並行性較高的應用要充分考慮使用行級鎖，這樣對於提高並發性能至關重要！當然，事務都存在利弊兩方面，使用行級鎖，也會帶來一些相應的弊端，比如使用的鎖越多，占用的內存也越多，在使用行級鎖的表上頻繁的進行數據刪除、插入操作久而久之會造成數據庫碎片的大量生成，數據庫性能會下降，這就需要定時進行reorg操作，但該操作比較耗時，且影響業務！
提問：(zxar )
幾個疑問，盼指點
1。allpages-locks是不是就是表鎖，我以前一直是這麼理解的，但是現在有疑問的是，如果我的where從句裡的條件是針對索引的，它是對所有滿足條件的頁加鎖，還是不管條件，對
