36. 解決常見的效能問題
發現問題
一般效能瓶頸
SQL Server組態設定
本章總結
在整本書中,您看到了可以使用的工具和可以修改的參數,來幫助您發現與解決效能問題。例如,前一章學到如何利用 SQL 陳述式和預存程序來辨識問題,以及如何調整那些陳述式和程序達成最佳化效能。本章則幫助您簡單地找到需要的資訊,以便解決各種效能問題,並檢視一些其他章節討論過跟效能有關的主題,提供檢驗效能問題的參考方案,與說明一些與效能監視和系統調整有關的附加資訊。
我們將從復習 瓶頸 (bottleneck)的定義開始。然後看看如何使用 Windows 2000 系統監視器(在 Windows NT 中稱為效能監視器),以及如何使用 Microsoft SQL Server Enterprise Manager 來確定效能問題是否存在。接著是如何解決一般效能問題,該問題發生在好幾種層級中,包括應用程式、SQL Server、作業系統和硬體等層級。用在系統容量計畫的主要規則已經在 第 6 章 說明過,但本章還會再復習一次,因為它們可以用來分析現有的系統,以確定是否需要附加硬體來改善效能。最後將復習前幾章提過的好幾種 SQL Server 設定參數,用來調整系統效能的改變方式。
在本章的結尾,您將可以識別效能瓶頸,並確定導致瓶頸的原因。雖然不是每次都能解決問題,但是只要肯花時間以及資源來處理這些問題,大部分問題是可以解決的。
什麼是瓶頸
瓶頸 一詞通常用來討論軟體和硬體效能問題,也就是系統中一個元件或一組元件可能限制系統效能的狀況。例如,缺少足夠容量的 I/O 子系統會導致一個嚴重的瓶頸-它會使整個系統變慢。(在本章的
<I/O子系統> 一節中會詳細的討論這種情況。)幾乎所有系統中活動的元件都可能導致瓶頸。瓶頸可以由一個元件所引起,例如一個磁碟,或由一組元件所引起,例如I/O子系統,或由不同元件的組合所引起。例如,您可能首先檢測到一個 I/O 子系統瓶頸。解決這個問題的方法是透過增加更多的磁碟來支援發生問題系統中的 I/O 數量(硬體解決方案),或透過最佳化低效率查詢來減少 I/O 的發生(軟體解決方案),或兩者都使用。當 I/O 問題被解決時,可能會發現現在產生 CPU 瓶頸,並需要增加 CPU 的速度或 CPU 的數量。
發現問題
要確定系統是否有問題存在,首先要觀察系統效能。例如,使用者是否在執行資料庫查詢或修改時,受到比預期更慢的反應時間。這是效能問題或瓶頸的一般狀況。也許您會注意到,當執行某種查詢時,系統上所有其他的操作會執行得比平常慢。因此將著重於造成問題的最佳化查詢,或者在較少使用者存取系統時,試著同時執行查詢來找出原因。
另一個確定是否有問題存在的途徑是定期的測試和監控系統。可以使用的工具包括 Windows 2000 系統監視器和 SQL Server Enterprise Manager。本節會學習如何使用這兩種工具檢查系統的狀況,也將學習用在監視 SQL Server 過程的 sp_wh 0-7356-1266-8預存程式。
說明
如果需要使用 SQL Profiler和SQL Query Analyzer 來偵測和 SQL 陳述式有關的效能問題,請參閱
第 35 章 。系統監視器
Windows2000 系統監視器不僅支援 Windows2000 計數器,也支援 SQL Server計數器。這些計數器監控系統功能隨時間的變化以確定系統中的狀態,例如 CPU 利用的百分率或 SQL Server 快取命中比率。(本章也提供關於特定效能計數器的資訊。)您可以隨時觀察監視器,或將資料記錄到檔案中,以後再檢視。
要使用系統監視器監視系統,請依下列步驟進行:
圖36-1 Windows 2000 效能監視器 |
圖36-2 「新增計數器」對話方塊 |
圖36-3 即時系統監視器 |
要將效能資料存入記錄檔中,請跟著下面程序:
圖36-4 「新記錄檔設定」對話方塊 |
圖36-5 新的記錄檔案視窗中的「記錄檔」籤頁 |
您可以在有規律的基礎上使用效能監視器來檢查系統的狀態。每日或每星期的監控是個好主意,這樣您可以瞭解您的系統,以便於當異常的現象發生時,您能夠識別這個現象的原因。將效能資料保存到記錄檔案以備稍後的檢查,這也是建議的方法-記錄檔案中的資料總會派上用場,您可以比較系統更改前後的效能資料,確定這個更改是否是好的。您也可以使用這些記錄檔來比較使用者和系統活動是如何從一種狀態變更到另一種狀態的。例如,您可能注意到,在本月的最近幾天,使用者活動比其他時間要多。這樣您將確保您的系統能夠處理在這些尖峰值時的負載。
圖36-6 效能 視窗,顯示一個新計數器記錄的項目 |
Enterprise Manager
除了自動的日常管理功能以外,Enterprise Manager 可以用來協助監控 SQL Server 過程與鎖定。(請參閱 第 19 章 關於鎖定的資訊。)例如,您可以收集關於程序鎖定和物件鎖定的資料-在這些情況下,一個物件可以是資料表、資料庫或暫存資料表。要檢視這些資訊,請按照下列步驟操作。
圖36-7 展開 Enterprise Manager 中的「目前活動」資料夾 |
圖36-8 Enterprise Manager 中的「處理器資訊」 |
圖36-9 顯示在「鎖定/處理序識別碼」窗格的 SPID |
圖36-10 「處理序詳細資訊」對話方塊 |
圖36-11 展開的「鎖定/處理序識別碼」資料夾 |
鎖定模式可以是下列之一:
鎖定的狀態可以是下列之一:
圖36-12 展開的「鎖定/物件」資料夾 |
圖36-13 檢視物件的鎖定資訊 |
sp_who 預存程序
您也可以在 Query Analyzer 或 OSQL 提示中執行下面指令,來檢視程序的資訊:
sp_who active GO
在 Query Analyzer 中執行這個指令的結果如圖36-14。如果一個程序被鎖定了,blk欄位將顯示正在鎖定程序的SPID。
當使用者抱怨交易太慢時,您可以執行這個指令來找出問題。很多時候您會發現大部份被封鎖的程序是被另一個程序封鎖的,一旦找出產生問題的程序所在,就能確定封鎖這麼久的原因。
圖36-14 執行 sp_who 的結果 |
您應該經常監控鎖定,以確定是否有些程序佔有一個鎖定的時間太長,以及是否程序經常被其他程序封鎖(它們有 WAIT 狀態)。但是通常使用者的抱怨多半由於封鎖問題引起的回應時間太慢。如果封鎖發生得太頻繁或太長時間,您可能要確定哪個程序佔有獨占鎖定或資料表鎖定。這些鎖定可能是導致封鎖的原因,並監控程序執行的 SQL 陳述式。然後如果可能試著最佳化這些陳述式,使它們更快的釋放鎖定或避免佔有資料表鎖定。一般而言,一個程序用很多時間等待獲得一個鎖定時,該程序會使用更多的時間來完成。因此,減少鎖定競爭可以提高交易回應時間。
相關資訊
關於鎖定的更多資訊,請參閱< 線上叢書 >並索引 顯示鎖定 ,並選擇在 找到的主題 對話方塊中的 顯示鎖定資訊 。
一般效能瓶頸
您已經瞭解如何使用效能監視工具,如系統監視器、Enterprise Manager、Query Analyzer 和 Profiler,而您也準備要對付效能瓶頸了。在本節中,我們將看到一些很普通的效能瓶頸和不同的解決方案。這些瓶頸大部分是相互關聯的,且一個瓶頸可能偽裝成另一種瓶頸的形式。您必須尋找硬體和軟體導致的瓶頸-很多效能問題發生於瓶頸的組合。可能導致瓶頸的硬體包括 CPU、記憶體和 I/O 子系統;可以導致瓶頸的軟體包括 SQL Server 應用程式和 SQL 陳述式。下面章節我們將更詳細地檢驗每種問題。
CPU
一個普通的效能問題就是缺少馬力。系統的處理能力取決於系統中 CPU 的數量、類型和速度。如果您沒有足夠的 CPU 能力,您可能無法快速的處理交易以令使用者滿意。要使用系統監視器來確定 CPU 利用的百分率,請檢查 Processor 物件中的 %Processor Time 計數器(選擇多處理器系統中的所有 CPU)。如果您的 CPU 長時間執行在 75% 或更高的情況下(75% 是根據
第 6 章 設定的規則所要求的最大值),您更可能遇到 CPU 瓶頸。如果您看到了低於 60% 的穩定 CPU 使用率,您仍然可以透過在系統中增加更快的 CPU 或更多的 CPU 中獲益。在決定升級您的 CPU 之前,確定監控了系統的其他特性。例如,如果您的 SQL陳述式效率很低,您可能執行了很多非必要的程序,而最佳化這些陳述式就可以幫助您降低 CPU 利用。或者假設 SQL Server 資料快取的快取命中比率低於 90%。您可能需要增加記憶體到資料快取中(也就是增加 max server memory 參數或增加系統的實體記憶體),這允許更多的資料存入快取和更少的實體磁碟 I/O 操作,導致了較低的 CPU 使用率。有時只增加處理器,您就可以獲得更好的系統效能,特別是您從單處理器系統開始。然而,並不是所有應用程式都能適應多處理器系統的規模。SQL Server 本身的延展性很好,但並不是所有執行的 SQL 陳述式都需要延展性。一個程序一次只能在一個 CPU 上執行,而且對於單個 SQL 陳述式單個 CPU 已經足夠了。為了效能的延展,您的 SQL Server 必須同時執行很多 SQL 陳述式-多個陳述式可以同時在不同 CPU 上執行,因此多個 CPU 能同時處理這些陳述式。
一般而言,您可以透過使用更多和更快的 CPU 來提高效能。然而,在某些情況下,在增加更快的 CPU 之同時,您必須擴大記憶體和 I/O 容量,否則您可能只將這個瓶頸轉移到另一個位置,甚至可能是新的 CPU。例如,如果您原來有一個 CPU 瓶頸,而您透過增加一個 CPU 解決了這個問題,但您可能會發現您的系統執行了更多的工作,因此導致了更多的磁碟 I/O,然後您會發現一個 I/O 瓶頸的發生。另外,確保檢查您決定增加的 CPU 的快取大小。CPU 的快取越大,效能將越好,特別是在多處理器系統中。
簡單地說,如果您決定您需要更多的處理能力,您可以增加 CPU 或用更快的代替現有 CPU。例如,如果您的系統有兩個 CPU,但是可以擴展為四個,那麼可以增加兩個同類型的 CPU,或替換四個全新更快的 CPU。如果您的系統已經具有了最大數量的 CPU,而您又需要更多的處理能力,那麼就用更快的 CPU 來替換它們。例如,讓我們假設您有四個 200 MHz 的 CPU。您可以用更快的 CPU 來替換它們,例如 500 MHz。更快的 CPU 將執行更快的完成程序。
記憶體
記憶體是 SQL Server 效能最關鍵性的元件之一。由於記憶體和 I/O 子系統的關連性,因此它是非常重要的。例如,在 I/O 密集型系統中(執行大量 I/O 的系統),可以讓 SQL Server 用來儲存資料的記憶體越多,所必須執行的實體 I/O 越少。這是因為資料可以在資料快取中找到,而不是在磁碟中。SQL Server 具有一個複雜的快取系統,透過盡可能從記憶體中存取資料來提高系統效能,而不存取磁碟,因為存取磁碟將提供較低的效能。您可以從記憶體中存取的資料越多,您的系統效能越好,這是因為執行的實體 I/O 越少。記憶體存取要比實體磁碟存取快得多。
在一些情況下,記憶體數量的不足可能導致明顯的磁碟瓶頸。這是因為系統無法有效地進行快取將導致更多的實體磁碟 I/O 操作。要看 SQL Server 正在使用多少系統記憶體,就用系統監視器來檢查 SQL Server:Memory Manager 物件中的 Total Server Memory (KB)計數器。如果 SQL Server 沒有用到如您預期的記憶體大小,也許就要調整記憶體的參數設定(如本章稍後 <SQL Server組態設定> 一節所述。)。
要確定您是否有足夠的快取數量,請使用效能監視器來檢查 SQL Server:Buffer Manager 物件中的 Buffer Cache Hit Ratio 計數器。通常的規則是您需要有 90% 或更高的快取命中比率。如果這個命中比率低於 90%,請增加更多的記憶體。注意,在一些情況下,您的系統無法達到 90% 的快取是由於應用程式的特性。這可能是因為相同的資料分頁很少被重新使用,而系統又頻繁地刷新快取中舊的資料分頁以存入新的資料分頁。
說明
SQL Server 2000 根據系統可用記憶體和記憶體參數設定,動態地為緩衝快取分配記憶體。一些外部資源(例如列印程序和其他的應用程式等)可能導致 SQL Server 釋放大部分的記憶體來為其他程序使用。仔細監控系統記憶體,如果可能的話,請將 SQL Server 分隔在它自己的系統中。關於使用記憶體參數的詳細說明,請參閱 第 30 章 以及本章後面的 < SQL Server組態設定 > 一節。
I/O 子系統
在 I/O 子系統中的瓶頸是資料庫系統中最容易發生的硬體問題。它僅次於撰寫拙劣的 SQL 陳述式,拙劣的 SQL 陳述式是最大的效能問題。幸運的是,I/O 子系統也是最容易解決的效能問題之一。在很多情況下,增加磁碟可以完全消除這個效能瓶頸。
I/O 子系統問題來自於磁碟只能以特定速率工作的事實。例如,一個磁碟可能具有每秒85次 I/O 的處理能力。如果磁碟負荷過多,那麼這些磁碟的 I/O 會產生佇列,而 SQL Server 將遇到較長的 I/O 等待時間。這些較長的 I/O 等待時間可能導致過長時間的鎖定佔有,或執行緒在等待資源時處於空閒狀態。最終結果將是整個系統的效能受損,進而導致憤怒的使用者抱怨他們的交易使用太長的時間。
在大多數情況下,I/O 子系統效能問題的發生是因為 I/O 子系統沒有正確的規劃它所執行的負載。關於規劃的主題在
第 5 章 和 第 6 章 中已詳細討論,但讓我們在這裏簡單的回顧一下。大小的規劃是必須的,因為單一磁碟每秒可以執行 I/O 次數受到限制。當交易記錄檔執行多數循序性 I/O 時,就會像交易記錄檔一樣,磁碟可能達到每秒 150 次 I/O 而不會負載過量。另一方面,當資料檔案執行隨機性 I/O 時,就像資料檔案一樣,相同的磁碟可能只有每秒 85 次 I/O。如果系統需要執行更高的 I/O,那麼等待時間將變得很長。
要確定是否過度使用磁碟機,請使用效能監視器物件 PhysicalDisk 和 LogicalDisk監控計數器(稍後將在本節中討論)。計數器收集關於實體和邏輯磁碟 I/O 行為的資料,例如每秒磁碟中發生的讀取和寫入。您必須使用 Windows NT/2000 指令 DISKPERF 啟動磁碟效能計數器。這些計數器在安裝作業系統時可用,但您應該知道如何啟動與關閉計數器。計數器在收集數據時會佔用系統資源,如 CPU 的時間,因此您應該只在要監視系統 I/O 時使用它們。您可使用 Windows NT/2000 指令 DISKPERF 來啟動或關閉計數器。
要知道 DISKPERF 是否啟動,請在命令提示字元下鍵入下列指令:
diskperf
如果 DISKPERF 已經啟動,您將看到這個訊息:"本系統的實體磁碟效能計數器已設為啟動"。如果 DISKPERF 沒有開啟,您將看到這個訊息:"本系統的邏輯和實體磁碟效能計數器現在設定為不啟動。"
要啟動 DISKPERF,請在命令提示字元下鍵入下列指令:
diskperf -Y
要停用 DISKPERF,請執行該指令:
diskperf -N
在 DISKPERF 生效前,您必須重新啟動電腦。鍵入下面指令來看更多的DISKPERF 選項:
diskperf ?
有特殊重要性的計數器是 Disk Writes/Sec、Disk Reads/Sec、Avg. Disk Queue Length、Avg. Disk Sec/Write和Avg. Disk Sec/Read。這些計數器可以幫助您確定磁碟子系統是否過度使用。PhysicalDisk 和 LogicalDisk 物件都提供這些計數器。如果要詳細檢視這些計數器提供的資訊,當增加計數器時,請在 新增計數器 對話方塊中按一下 說明 。
我們來看一個使用計數器的例子。假設您的系統有一個 I/O 瓶頸,您將檢查PhysicalDisk 物件中的 Avg. Disk Sec/Transfer、Avg. Disk Sec/Read和Avg. Disk Sec/Write 計數器,因為它們監視磁碟需要執行讀寫的時間量,過長的等待時間表示您過度使用磁碟機或磁碟陣列。一般的規則是這些計數器的正常讀數在千分之 1 到 15 秒(0.001到0.015)之間,但是在尖峰時期可能達到千分之 20 秒(0.020)。如果您觀察到高於千分之 20 秒的數值,您可能會遇到一個 I/O 子系統效能問題。
同時也檢查 Disk Writes/Sec 和 Disk Reads/Sec。讓我們假定這些值計數器顯示每個磁碟每秒 20 次寫入和 20 次讀取,總共 40 次 I/O,且容量為每秒 85 次 I/O。同時如果您的磁碟等待時間較長的話,磁碟機就可能故障了。另一方面,如果磁碟執行每秒 100 次 I/O,且等待時間大約千分之 20 秒或更多,則您需要增加磁碟來提高效能。
使用 RAID 陣列時,如果您想確定您的系統正在執行的 I/O 有多少的話,就將在效能監視器中看到的每秒 I/O 次數除以陣列中磁碟的總數量和 RAID 資源佔用的因數。下表列出了使用 RAID 技術時產生讀寫的實體 I/O 次數。
表36-1 每個RAID層級讀寫執行的實體I/O次數 |
RAID層級 | 讀取 | 寫入 |
---|---|---|
0 | 1 | 1 |
1或10 | 1 | 2 |
5 | 1 | 4 |
一般情況下,更正 I/O 子系統瓶頸的最佳途徑是增加更多的磁碟。但是請記得考慮 I/O 瓶頸的其他可能原因,例如較低的快取命中速率以及執行交易的 I/O 太多。(在大多數情況下,快取命中速率低於 90% 就太低了。)如果您發現了一個 I/O 瓶頸,請回顧 第 6 章 中的說明,來確定您系統需要的磁碟數量。
故障元件
有時您的系統可能遇到由故障元件引起的效能問題。如果故障元件沒有完全失效而僅僅是效能降低,那這可能是一個很難排除的問題,因為問題的多樣性和複雜性以及它的解決方案已經超出了本書的範圍。但是這裏有幾個辨識故障元件問題的訣竅:
應用程式
造成效能問題的另一個系統元件是 SQL Server 應用程式。這些問題可能發生在應用程式碼或在應用程式執行時的 SQL 陳述式中。本節提供一些提示和準則,用來解決和 SQL Server 應用程式有關的效能問題。
最佳化執行計劃
正如我們在 第 35 章 所看到的,選擇一個最佳的執行計劃和資料存取方法對於查詢是很重要的。不幸的是,並沒有一定的公式來確定最佳的計劃。SQL Server 自動選擇查詢最佳化器的計算為最佳的執行計劃。隨著您熟悉聯結操作的不同類型,您可能可以透過分析以確定最佳執行計劃。通常您需要試過各種不同的計畫後,才能找到最佳方法。
使用索引
正如我們在 第 17 章 和 第 35 章 所看到的,正確索引的使用對於好的效能是十分重要的。使用索引來找出所需的資料,這只需要 10 到 20 個 I/O 操作,而透過資料表掃描找出所需的資料,則可能需要成千上萬的 I/O 操作。不過必須謹慎地使用索引。記住,在使用 INSERT、UPDATE 或 DELETE 陳述式修改資料表的各種資料時,索引將自動更新,顯示更改後的資料,因此會產生比平常更多的 I/O 操作。注意不要建立太多索引,否則用來維護這些索引的資源佔用可能會影響資料修改的效能。
使用預存程序
正如我們在 第 21 章 中所看到的,預存程序被用來在伺服器上執行預先包裝和預先編譯的SQL陳述式。從應用程式呼叫預存程序對效能有所幫助,因為改善了伺服器上 SQL 陳述式的可重複使用性,也減少了網路的流量。由於預存程序執行在伺服器上,可以減少用戶端和伺服器之間傳送的資料數量,您可以在預存程序中將程序程式化並將資料篩選處理,而不用在應用程式中執行這些動作。
SQL Server 組態設定
SQL Server 2000 使用虛擬方式自行調整組態,但是有些調整參數仍然可以用來變更您的系統操作和執行的方式。在本節中,您將學到如何設定這些選項,以及它們如何影響到您系統的操作。在大多數情況下,是不需要更改這些參數的,但是瞭解它們是什麼以及它們做什麼使您有機會決定是否更改它們。您可以使用 Enterprise Manager 或 sp_configure 來設定。
要使用 Enterprise Manager,請在您要設定的伺服器名稱上按右鍵並從快顯功能表中選擇 內容 ,顯示 SQL Server屬性 視窗。這個視窗包含9個頁籤,每個頁籤都有您可以設定的選項。下面將說明這些頁籤以及它們的選項。
當使用 sp_configure 設定這些選項時,某些選項是設定為進階(advanced)的。(下面幾節將說明哪些是進階選項。)您必須將 show advanced options 選項設定為1(啟用),這樣才可以使用 sp_configure 來更改一個進階選項。預設情況下該選項設定為0(禁用)。(當使用 Enterprise Manger 來設定進階選項時,您不需要擔心這個選項。)要設定 show advance options,請使用下面的陳述式:
sp_configure "show advanced options", 1 GO
通常,要使用 sp_configure 設定某個選項,請使用下面的語法:
sp configure "option name", value
affinity mask 選項
affinity mask 選項是用來指定在多處理器環境中,SQL Server 執行緒可以在哪些CPU 上執行。預設值為0,指定由 Windows 2000 排程演算法來決定執行緒關連性。非零值設定了一個 bitmap,用來定義可以執行 SQL Server 的 CPU。十進位數值1(或二進位位元遮罩值00000001)指明只使用CPU 1、2(或00000010)指明只使用CPU 2、3(或00000011)指明使用CPU 1和CPU 2,等等。
這個選項是進階選項,表示在使用 sp_configure 設定該選項時,必須設定 show advanced options 為1。它也可以用 Enterprise Manager 來設定。要這樣做,請選擇 SQL Server屬性 視窗中的 處理器 頁籤,在 處理器控制 區域,選擇您要 SQL Server 使用的 CPU 旁的核取方塊。按一下 套用 和 確定 來儲存更改。您必須停止並重新啟動 SQL Server,使該更改生效。
在指定的 SQL Server 系統上,您必須設定 affinity mask 選項,允許 SQL Server使用所有的 CPU。在沒有指定的 SQL Server 系統上(包括需要 CPU 時間的其它處理程序),您可能要試著設定 affinity mask,這樣 SQL Server 才會留下一個 CPU 不用而用其餘的 CPU。
lightweight pooling 選項
lightweight pooling 選項用來設定 SQL Server 使用 lightweight 執行緒或細微模式(fibers)。使用細微模式可以減少內容切換(context switches),允許 SQL Server(而不使用 Windows NT 或 Windows 2000 的排程程式)掌控排程。如果您的應用程式在多處理器系統中執行,且您看到了大量的內容切換,您可能需要將 lightweight pooling 參數設定為1,這將啟用 lightweight pooling,然後監控內容切換的數量,來核對它們是否已經減少了。預設值為 0,這樣會禁用細微模式。
lightweight pooling選項也是一個進階選項,在使用sp_configure 設定該選項時,必須將show advanced options設定為1。它也可以用Enterprise Manager來設定。選擇 SQL Server屬性 視窗中的 處理器 頁籤,在 處理器控制 區域,選取 使用Windows NT Fibers 核取方塊來啟用該選項,或者清除這個核取方塊來禁用該選項。按一下 套用 ,按一下 確定 ,然後停止並重新啟動SQL Server以使該選項生效。
max server memory選項
SQL Server 動態地分配記憶體。要指定 SQL Server 分配給緩衝集區的最大記憶體數(單位為MB),您可以設定 max server memory 選項。因為 SQL Server 需要一些時間來釋放記憶體,所以如果您有其他的應用程式定期的需要記憶體,那麼應該設定 max server memory,這樣 SQL Server 就會為其他應用程式保留一部分記憶體。預設值為 2147483647,這表示 SQL Server 請求系統能盡量提供記憶體,而當其他應用程式需要記憶體和釋放記憶體時,動態地分配和解除分配記憶體。建議在 SQL Server 系統中使用這個設定。如果您要更改這個設定,請計算您可以給 SQL Server 的最大記憶體數量,從全部的實體記憶體中減去 Windows 2000 需要的記憶體加上其他非 SQL Server 使用需要的記憶體。
這是一個進階選項,在使用 sp_configure 設定該選項時,show advanced options 必須被設定為1。要使用 Enterprise Manager 來設定該選項,在 SQL Server 屬性 視窗中選擇 記憶體 頁籤,並調整 最大值(MB) 滑動桿。接著按一下 動態設定SQL Server的記憶體 。這個選項的更改將立即生效,不需要停止並重新啟動 SQL Server。(如果按一下 使用定量的記憶體 ,您就能設定記憶體的固定值。這可以限制 SQL Server 分配記憶體的量,而在記憶體分配到固定值後,不再釋放記憶體。)
min server memory 選項
min server memory 選項指定分配給 SQL Server 緩衝集區的最小記憶體數,單位為 MB。在 SQL Server 為其他應用程式保留過多記憶體的系統中,設定這個參數將很有用。例如,伺服器當成資料庫伺服器的同時,還用作列印和檔案服務,在這種環境中,SQL Server 可能釋放太多的記憶體給這些其他的應用程式。這樣會減慢使用者的回應時間。
min server memory 的預設值為0,允許 SQL Server 動態的分配和解除分配記憶體。建議使用這個設定,但是如果您的伺服器不只用作 SQL Server,可能就需要更改這些設定。
這是一個進階選項,在使用 sp_configure 設定該選項時,show advanced options 必須被設定為 1。您可以使用 Enterprise Manager 來設定該選項,請在 SQL Server 屬性 視窗中選擇 記憶體 頁籤,調整 最小值(MB) 滑動桿,並按一下 動態設定SQL Server的記憶體 。這個選項的更改將立即生效,不需要停止並重新啟動 SQL Server。
recovery interval選項
recovery interval 選項定義了系統在故障事件中回復的最大時間,單位為分鐘。SQL Server 使用這個設定以及內建的演算法,決定執行自動檢查點的頻率,這樣回復工作將在指定的分鐘數內完成。根據在系統中有多少工作發生,SQL Server 決定兩次檢查點之間應該有多久的間隔時間。如果有很多工作要執行,檢查點執行的頻率將比平常多。執行的工作越少,從失效回復的時間越少。另外,回復間隔越長,檢查點間允許的間隔時間越長。
透過減少檢查點數量來增加回復間隔將提高效能(由於檢查點導致大量的磁碟寫入,這將使使用者交易時間慢幾秒鐘),但它也增加了回復 SQL Server 所需要的時間。預設值為 0,指定 SQL Server 確定間隔-大約1分鐘的回復時間。增加 recovery interval 選項是有風險的。通常使用 5 到 15 分鐘的值,但這完全取決於您在系統失效時是否能冒等待 5 到 15 分鐘的風險來等待資料庫的回復。一般說來,您可能要增加 recovery interval,以減少每個檢查點的頻率以及它們大量的寫入,因此允許使用者在 I/O 子系統中更自由的執行他們的交易,而不會中斷。
這是一個進階選項,在使用 sp_configure 設定該選項時,show advanced options 必須被設定為 1。要使用 Enterprise Manager 設定這個選項,請在 SQL Server 屬性 視窗中選取 資料庫設定 頁籤,並在 復原間隔(分鐘) 文字方塊中鍵入一個值。這個選項的更改將立即生效,不需要停止並重新啟動 SQL Server。
本章總結
在本章中,您學到了成為 DBA 將遇到的一般效能問題。您也看到如何使用系統監視器和 Enterprise Manger 來監控系統,並幫助定位效能瓶頸。另外您還學到了如何檢測以及解決一般系統效能問題。
本書讓您學習如何管理 SQL Server 2000、何謂管理 SQL Server 2000 和為什麼要管理 SQL Server 2000。您現在應該可以有效的管理和調整您的 SQL Server 系統了,並能夠順利有效地執行日常管理任務。我們希望您能夠喜歡閱讀這本書,就像我們在寫作本書時獲得樂趣一樣。