1．1 性能指標
數據庫性能一般用兩個方面的指標來衡量：響應時間和吞吐量。響應越快，吞吐量越大，數據庫性能越好。響應時間和吞吐量有些情況下不能一起得到改善。
1．2 調優級別
對Sybase數據庫性能調優，可以從四個方面進行：
一) 操作系統級：對網絡性能、操作系統參數、硬件性能等作改進。
二) SQL Server級：調整存取方法，改善內存管理和鎖管理等。
三) 數據庫設計級：採用降範式設計，合理設計索引，分佈存放數據等。
四) 應用程序級：採用高效SQL語句，合理安排事務，應用游標，處理鎖。
本文對第一、第三、第四方面的內容不做討論，第二方面提到的概念只適用於Sybase數據庫。
1．3 調優工具
在分析Sybase數據庫的性能時，要用到一些數據庫系統本身提供的性能調優工具，包括幾個系統存儲過程：
名稱 功能簡要介紹
sp_sysmon 企業級系統性能報告工具
sp_lock 查看鎖的情況
sp_who 查看線程的活動情況
sp_procqmode 存儲過程的查詢處理模式
sp_configure 配置SQL Server系統級參數
sp_estspace 估計創建一個表需要的空間和時間
sp_spaceused 估計表的總行數及表和索引佔用的空間
sp_monitor 監視CPU、I/O的統計活動情況
在利用isql等一些工具時，還可以設置查詢會話中的幾個選項，來顯示SQL語句執行時的各種統計分析結果：
指令 On 的含義
set noexec on/off 分析SQL語句後，還要執行
set statistics io on/off 統計SQL執行所需I/O
set statistics time on/off 統計SQL語句執行耗時
set showplan on/off 顯示查詢計劃
1．4 sp_sysmon 的使用
企業級性能報告工具、系統存儲過程 sp_sysmon 的使用方法：
在isql 下，首先輸入 sp_sysmon 'begin_sample' 啟動一個報告採樣過一段時間後，再輸入 sp_sysmon 'end_sample' 結束上次報告採樣
或者緊跟一參數 sp_sysmon 'end_sample', "dcache" 結束上次報告採樣， 但只顯示數據緩衝（Data Cache Management）這一部分的情況。
能替換dcache的可選參數如下表所示：
參數 參數全稱，內容範圍解釋
Dcache Data Cache Management，數據緩衝
Kernel Kernel Utilization，有關引擎、網絡和I/O等情況
Wpm Worker Process Management
Parallel Parallel Query Management
Taskmgmt Task Management
Appmgmt Application Management
Esp ESP Management
Housekeeper Housekeeper Task Activity
Monaccess Monitor Access to Executing SQL
Xactsum Transaction Profile
Xactmgmt Transaction Management
Indexmgmt Index Management，索引管理
Mdcache Metadata Cache Management
Locks Lock Management，鎖管理
Pcache Procedure Cache Management
Memory Memory Management
Recovery Recovery Management
Diskio Disk I/O Management，磁盤I/O管理
Netio Network I/O Management
1．5
用sp_sysmon可以得到數據庫系統的性能基準報告，但要在比較穩定的狀態下產生，方可作為參考和對照的依據。
1．6 理解存儲方法
只有清楚數據庫存儲數據的底層細節，如數據頁、索引頁的物理結構，每一行的大小計算，不同類型列佔用的寬度等等問題，才能對各種調優措施有個深入領會。關於這個問題，比較複雜和細緻，請自行參閱有關書籍。
一般地，對於更改數據的操作，要盡量促進數據庫進行直接更新（ Direct Updates ），所以要遵守以下幾條原則：
1）除非必要，避免使用允許null值的列和可變長度的列。
2）如果varchar 和 varbinary 列填充得比較滿，毫不猶豫轉成 char 和 binary 列。對於建表時指定的頁填充率（page fillfactor）參數，要權衡確定數值大小。一般：小值，適合於有許多隨機插入的表，該表的數據經常被刪除，又經常被增加；大值，適合於大多數的數據被增加到表末尾，如客票系統的售票存根和退票存根表。
2 SQL Server級的調優
2．1 管理共享內存
數據庫性能優化的首要方面是最優管理內存。數據庫佔用的共享內存分成數據緩衝（data cache）、存儲過程緩衝（Procedure cache）等幾塊。在isql 下使用 sp_configure 'cache' 可以看到存儲過程緩衝所佔百分比（procedure cache percent），整個數據緩衝大小（total data cache size） 等參數。
2．1．1 存儲過程緩衝（Procedure cache）
存儲過程緩衝保持以下對象的查詢計劃：
Procedures ：存儲過程
Triggers ：觸發器
Views ：視圖
Rules ：規則
Defaults ：缺省
Cursors ：游標
存儲過程不可重入，意即每個並發用戶調用都會在內存中產生一個拷貝。
Procedure, triggers, and views 當它們被裝載到procedure cache中時，被查詢優化器優化，建立查詢計劃。如果存儲過程在緩衝中，被調用時就不需要重新編譯。如果procedure cache太小，存儲過程就會經常被其他調入內存的存儲過程沖洗掉，當再次被調用時，存儲過程又被調入內存，再重新編譯，用戶請求因此不得不等待。最嚴重的情況，如果procedure cache不夠，存儲過程甚至都不能運行。所以在內存足夠的情況下，procedure cache percent 參數盡可能大一些。
2．1．2 數據緩衝（Data Cache）
數據緩衝用來緩存數據頁和索引頁，是除去存儲過程緩衝，系統其他佔用的緩衝外的剩餘內存空間。通過給服務器增加物理內存擴大數據緩衝，是最有效的方法。當然，如果不能加內存，就只能通過減少存儲過程緩衝的比例等方法來擴大數據緩衝了。通過 sp_configure "extent I/O buffers", 20（可調） 命令，在Data Cache中保留一些頁專用於創建索引時使用，可以顯著提高創建索引的性能。但要注意每開闢一個緩衝佔用16K 字節的系統內存。
2．1．3 命名緩衝
通過如下的命令：
1>; sp_helpcache
2>; go
查看某客票數據庫中命名緩衝，得到的結果如下：
Cache Name Config Size Run Size Overhead
------------------------ ------------- ---------- ----------
DS30_Tran_Log 20.00 Mb 20.00 Mb 2.05 Mb
Systemtable 20.00 Mb 20.00 Mb 2.05 Mb
default data cache 0.00 Mb 4462.86 Mb 464.97 Mb
left_base_center 16.00 Mb 16.00 Mb 1.57 Mb
price_cache 8.00 Mb 8.00 Mb 0.85 Mb
可以看出有4個命名緩衝，分別綁定客票系統的應用日誌表、一些重要且常用的系統表、余票表、票價系列表，另外1個是缺省數據緩衝。這種配置還不是最合理，應該進一步把Systemtable這個命名緩衝細分成很多個，每一個單獨存放一張系統表。
2．1．4 緩衝策略
緩衝策略是指把數據提前讀入內存的機制，分預取策略(Prefetch rategy，即大I/O策略)和取後馬上丟棄策略(Fetch-and-Discard)、提示策(Hints)等幾種。可以在三個級別上設置表數據的預取策略(Prefetch Strategy，即大I/O策略)於：對像級，會話級，查詢級。如果三個級別上都有設置，它們發生作用的優先順序是：對像級 >; 會話級 >; 查詢級。對於如何在查詢級利用指定的緩衝池，可以查看下面例子（使用4K緩衝池）：
select au_fname, au_lname
from authers (prefetch 4)
where au_id in ( A372020631, ..., A1887081515 )
go
DSS應用往往得益於大的I/O，應該放開large I/O strategy預取策略。
如果一個應用傾向於OLTP特徵，用戶能在會話級關掉Prefetch來提高性能。對於OLTP應用，關閉large I/O strategy預取策略。對於所取到的頁不會有重用的情況，放開fetch-and-discard策略。客票系統對存根數據進行統計的應用，如財收日結賬，營銷分析數據整理模塊和綜合查詢等，都可以利用這一結論。查看幾個操作頻繁且較大的表上的緩衝策略，用如下命令：
sp_cachestrategy center,seat_area
sp_cachestrategy center,sale_record0505
2．2 管理鎖
2．2．1 頁鎖升級閥限
優化鎖的重要考慮是設置頁級鎖升級升級成表級鎖的閥限。要盡量避免頁鎖很快升級成表級鎖。在某客票數據庫中，用sp_configure 『lock』可以看到如下結果：
deadlock checking period 500 0 1000 1000
number of locks 5000 46875 200000 200000
page lock promotion HWM 200 0 10000 10000
page lock promotion LWM 200 0 200 200
page lock promotion PCT 100 0 90 90
可以看到頁鎖升級的閥限有三個：HWM（最高點） 為10000，LWM（最低點）為200，PCT為90。Sybase數據庫內部根據PCT值按公式PCT*TAB_SZ/100得出計算閥限，如果計算閥限 < LWM, 鎖升級發生在LWM值；如果計算閥限 < HWM，鎖升級發生在HWM值。如果 LWM < 計算閥限 < HWM ，鎖升級發生在PCT*TAB_SZ/100值。
鎖升級閥限設置分對像級和服務器級兩種。
針對對像級設置（數據庫上的表或表上的索引），配置命令是：
sp_setpglockpromote {"database" | "table"}, objname, new_lwm,new_hwm, new_pct
針對服務器級設置，配置命令是：
sp_setpglockpromote server, NULL, new_lwm, new_hwm, new_pct。
如果要刪除掉對像級上的頁鎖升級閥限，用：
sp_dropglockpromote {"database" | "table"}, objname
2．2．2 減少鎖爭奪的方法：
1）降範式設計數據庫，創建冗余表。
2）把堆表（沒有聚族索引的表）分區。
3）對於小表，使用fillfactor和max_rows_per_page來減少行密度，從而使各行數據分佈到許多頁（此方法適用於SQL Server 11版，對於11.9.2版以後的Sybase數據，有了行級鎖，此方法必要性不大）。
2．3 管理臨時庫(tempdb)
管理臨時庫一個重要原則是要避免臨時表跨多個設備，可以把tempdb從master設備中分離出來，放到一個單獨的設備上去。這樣可以減少存取系統表時對I/O資源的爭奪。用sp_dropsegment 存儲過程從master設備中移除tempdb的default段和system段。為了進一步提高tempdb的I/O速度，可以考慮把tempdb整個放在RAM 驅動器或固態存儲設備上，存取速度是一般磁盤的1000倍。一般情況下，tempdb會非常頻繁地爭奪和佔用缺省數據緩衝，因為查詢會話中有許多臨時表要創建、計算和刪除。所以推薦把tempdb綁定到它自己的命名緩衝，這樣可以防止臨時對像在內存中的活動沖洗掉缺省數據緩衝中的其他對象，利於在多個緩衝間展開I/O。在使用臨時表的時候，還有一個原則：盡量縮小表規模和行的寬度，每一行只包括必要的列。例如在用select * into生成臨時表時，如果只需要幾個列的數值，就不要用這樣的語句，而直接選取需要的列。
2．4 使用多引擎（Multiple Network Engines）
如果操作系統使用了多個CPU，那麼用sp_configure 配置數據庫的參數：在線引擎數(max online engines)，可以擴展系統的網絡I/O容量，分佈網絡I/O到各個引擎，從而提高性能，允許更多的用戶連接。
在用戶登錄數據庫時，總是先登錄到引擎0，由引擎0在可用引擎隊列中選擇一個掛最少連接的引擎來傳遞socket描述符，從而重定向連接到那個引擎，由該引擎去處理跟此用戶連接相關的所有網絡活動。
對於多引擎SMP結構，SQL Server引入了自旋鎖(spinlock)的一種數據結構，在多個引擎間共享。對於不同類型的任務，在哈希表上分配不同的自旋鎖，有頁鎖自旋鎖、表鎖自旋鎖和地址自旋鎖。
自旋鎖的配置：
sp_configure "page lock spinlock ratio", newval
sp_configure "table lock spinlock ratio", newval
sp_configure "address lock spinlock ratio", newval
增大數值，可以減少碰撞，提高並發操作度。但是每一個自旋鎖結構要佔用256字節的內存。
如果數據庫發生1279錯，可能原因：
1）不允許足夠的鎖，解決辦法是用sp_configure 調大 number of locks 數值
2）在engine freelock 緩衝中沒有足夠的鎖，解決辦法是用sp_configure調大 max engine freelocks 數值。
如果數據庫系統使用了4個引擎，那麼每個引擎的自由鎖緩衝中包含：each engine-specific freelock cache 包含 5000 * .20 /4 = 250 個鎖。
在平時，經常用sp_monitor和sp_sysmon監視CPU使用率，如果所有CPU的利用率高於85%，增加CPU，然後增大數據庫的引擎數，可以改善性能。
2．5 設備使用的優化
把最常插入的表分區，放在多個設備上，這樣可以創建多個頁鏈，從而改善多個並發插入時的性能，因為每一個插入都要找到頁鏈，頁鏈有多個，就允許多個插入同時進行。這一點，尤其適用於客票系統的存根表和訂票存根表（CG30_RRT），所帶來的性能改善會非常明顯。
物理I/O的代價遠大於邏輯I/O，所以要盡量減少磁盤進行物理I/O的次數，盡量多進行內存中的邏輯I/O。使用statistics io工具和sp_sysmon，來觀察磁盤I/O。可以配置使用大的I/O來減少物理I/O的次數，方法有三個：
1）用更多的磁盤；
2）表和索引分開到不同的磁盤；
3）增加一次I/O系統參數值的大小。
SQL Server總是為I/O請求建立一個磁盤檢查的調度環，用sp_configure "I/O polling process count"來提高數值，加長環，可以降低引擎的檢查次數，提高吞吐量。但較小的值一般有助於減少響應時間。
對於可用的磁盤I/O控制塊，要查看操作系統文檔，用sp_configure "disk i/o structures"配置，這個數值要盡可能高。
分離日誌和數據，到不同的設備；給tempdb自己的設備；分離表和索引到不同的設備。這些方法都可以減少I/O。
2．6 對事務處理的調優
2．6．1 事務類型
事務處理無外乎三種：1,OLTP; 2, DSS; 3, OLTP + DSS 的混合負載
OLTP（聯機事務處理）的特點：
數據插入、修改和刪除頻繁。
經常操作的是單個記錄。
當不適當設計時，傾向於碰撞和衝突。
DSS（決策支持系統）的特點：
數據修改不太頻繁。
如果有插入和刪除，是大批量的。
平時一般是只讀操作。
表連接很常見。
有比較特別的查詢。
OLTP + DSS 混合負載的特點權衡：
在性能方面要比較，是要吞吐量還是響應時間。
在鎖方面要比較，是要並發性強呢還是要數據一致性強。
2．6．2 事務管理原則
一般的事務管理原則有：
1) 分解大的事務成多個小的事務。如客票數據的備份操作中，要刪除過期數據，如果設計小事務做循環，便不會影響應用，完全可以做到任何時候備份和刪除，不一定非得等服務器閒的時候做。
2) 避免在單個事務中更新或刪除大量的數據行。比如客票系統的席位庫數據清理，即使在服務器閒的時候做這種操作，也會鎖定整個表，影響售票。
3) 盡量用可以接受的最低孤立級(isolation level)，來提高並發度。如在余票查詢等功能的應用中，使用這種孤立級，便可以最大程度地降低對售票的影響。
4) 提高事務吞吐量的措施包括：避免延遲更新；盡可能使用存儲過程等等。
2．6．3 跟事務特徵相關的數據庫可調參數或特性
相對於OLTP應用，SQL Server有一些特性來滿足要求。
1) 命名緩衝（Named cache）
對於命名緩衝，可以配置多個不同大小的內存池，來滿足不同的應用需求。對於多個引擎的情況，命名緩衝還有一項重要的功能是降低自旋鎖的內部爭奪。
2) 日誌I/O緩衝大小可配置
sp_logiosize ["default" | "size" | "all" ]
缺省值是4K，但如果4K內存池沒有配置，SQL Server會使用2K大小的內存池
3) 堆表可分區，分佈插入操作到各個設備
適用於頻繁插入的表和有並發BCP倒入數據的表，如客票系統的售票存根和退票存根表。
4) 鎖升級閥限可配置。
相對於DSS應用，SQL Server也有一些特性來滿足要求
1) 應用大的 I/O 緩衝池
用sp_poolconfig來配置。
2) 綁定熱表到命名緩衝
如 sysindexes, syslogs, 注意如果把 syslogs 放到單獨的緩衝中，可以減少在缺省或其他命名緩衝上的自旋鎖爭奪。對於客票系統的train_dir, stop_time, 票價表, 取票存儲過程相關的表都可以放在單獨的命名緩衝上。
3) 取後丟棄緩衝策略 (Fetch-and-discard cache strategy)
不會沖洗掉緩衝中的常用對象，可以減少MRU鏈的爭奪，較少對OLTP事務的干擾。
對於收入統計應用，統計過往存根表中的數據，可以應用這一策略。
2．7 網絡方面的調優
Sybase客戶和服務器之建傳遞的是TDS包，缺省大小是512字節。對於要傳輸大批量數據的應用，如BCP、 文本/圖像的取用、大結果集SQL語句，要用下面的配置命令配置大的TDS包大小。
sp_configure "default network packet size", nnn
sp_configure "maximum network packet size", nnn
對於isql 和bcp，可以在應用級指定TDS包的大小：isql -Usa -P –Annn，bcp -Usa -P –Annn。
注意在調大maximum network packet size的參數後，要增大 additional network memory 參數，來適應 maximum network packet size 的要求。