4. 設計Microsoft SQL Server 系統
系統元件和選項
資料庫排列
應用程式
本章總結
在正式安裝 SQL Sever 作業系統之前,必須事先計劃如何架設屬於您的 SQL Server 系統,以避免後續操作的麻煩,甚至還得重新安裝。本書如提到 SQL Server 系統,代表這台電腦是在跑 SQL Server 主程式的電腦,若是只提到系統一詞,則代表是使用者裝有 SQL Sever 資料庫的電腦。
這一章我們會學到 Microsoft Window 2000 和 SQL Server 的不同版本,幾種可存取 SQL Server 的前端應用程式,以及 SQL Server 和前端應用程式的結合對系統延展性與執行效能的影響。
系統需求
在決定整個系統的需求之前,首先得考慮系統的目的。看看要用幾台電腦,以及如何用才能達到架設這個系統的目的。這一章我們先看看一般人架設的目的。到 第5章 和 第6章 再來討論如何配合目的來設計、安裝硬體設備。
在這一章我們也會討論到系統的功能,以及如何設定這些功能。在設定服務項目之前,我們首先要了解將要架設的系統會跑哪些類型的應用程式。
系統應用程式
少了應用程式,SQL Server 資料庫也沒啥存在的必要。應用程式可使 SQL Server使用方便。有些應用程式一看便知是個資料庫,有些則不然。不論何種應用程式,都得在最短的時間內解決使用者的需求。否則使用者只好去買更好的軟體囉!
應用程式的類型可以功能性區分。一般可分為三大類型:線上交易處理 (OLTP) 系統、決策支援系統 (DSS)和批次處理系統。這三種類型有不同的系統需求,也可能用到截然不同類型的應用軟體。
線上交易處理
當一堆使用者同時在線上存取資料,就被分類為線上交易處理。還有一點很重要的特質,就是這些使用者同時等候系統回應。線上交易處理系統有幾種模式,如:
- 線上購物 這種模式當然是因應電子商務蓬勃發展。應用的範圍譬如說當您在網路上購物填資料買東西時總得等待資料傳送,這就是一種線上交易的模式。當然存取資料的時間越短就能讓您快快完成交易行為。
- 商店購物 當店員刷過您的信用卡那一剎那,您的資料就透過層層系統進入資料庫中交易了。
- 商業系統 每家公司都會透過自己的一套應用程式進入資料庫。這可以是薪資系統、購物系統等各式各樣的系統。這些應用程式可以是內部網路的應用程式,或是用 C++、Microsoft Visual Basic 等各種語言寫的程式。總之不管什麼應用程式,資料的來源都是來自資料庫。
所有的線上交易系統有一個共通點,那就是─等,正確的說法應該是用者都需要等待系統的回應。所以好的系統是設計合理的回應時間。(就是不要讓人家等太久啦!)
決策支援系統
決策支援系統,顧名思義就是可以支援您做企業上決策的系統。使用者可以丟出問題,再參考運算後出來的結果。下列幾種問題就是決策支援系統可以回答的問題:
- 找出公司每個地區誰最會賣,什麼產品賣最多?
- 找出產品的季節性。
- 如果減價大拍賣會怎樣?
- 平均每個地區的業務拿了多少佣金?
決策支援系統和線上交易處理系統的不同處,在於前者可以有耐心地等待一個結果,因為系統也許得花上一點時間來分析這些複雜的問題。這並不是說使用者就不在乎這次得等多久,而是總產值 (與其浪費一堆人的時間) 和回覆時間 (不如浪費一個人的時間) 是可以互相協調的。
批次處理系統
批次處理系統離線處理無後端使用者的元件,以下是這類系統典型的運作形式:
- 每日資料重整 有的決策支援系統需要每晚重新整理資料,批次處理系統則將這個步驟自動化。
- 資料轉換 這項作業和前述作業有些類似,不過這裡會進行資料轉換。
- 資料清除 清除如重複的帳戶使用者。
- 離線佈告 可由客戶 每晚的佈告組成。
批次處理系統通常不會有使用者在一旁等待作業的完成,但這類型的系統還是要在一定的時間範圍內完成作業,如晚上的資料重整就不能到早上使用者都上線了還沒完成。
設備需求
介紹完這三種不同類型的應用程式,您可以知道在設計一個資料庫伺服器之前,了解系統要跑什麼類型的應用程式是很重要的了。在下幾節您會學到每種類型的系統均有自己的設備需求和特質。所以設備需求和特質決定了是否採用分散式處理系統。
要求服務範圍
服務範圍是設計一個系統最重要的一環。服務項目通常清楚的列入服務範圍同意書 (SLA)內。SLA 是服務提供者和顧客之間的同意書,是否真的需要很正式的一份 SLA 通常取決於客人。
舉例來說,如果您和外面的公司簽定資料庫服務,提供這項服務的公司大多會給您一份 SLA,這可以視為一份有法律效力的同意書。但如果是由公司內部某部門提供資料庫的服務,可能就沒這麼正式。不管是哪一種 SLA,都會列出應該包含的服務範圍,有時也會一併列出毀約的處罰。
當服務範圍確認,就可以設計適合的系統提供服務了。以下我們將討論影響設計的層面:
執行效能規定
SLA 內重要的一點就是詳述系統設備的最低要求。一份典型的 SLA 會附上表格,並列出一個應用程式可支援的數種交易形式,完成交易所需要的基本服務,及選擇性的附上完成 90﹪─ 95﹪ 交易時所需的時間。如 SLA 可能列出一項服務內容:「加入新客戶名單」,如要完成這項服務的90﹪需兩秒鐘,完成全部則需三秒鐘。
提供服務的公司或單位必須徹底作到服務的範圍以免違約,DBA 更要確認服務的執行。您必須定期檢視系統狀況及功能制定計劃,當系統有問題發生,必須視程度強化其系統功能。
運作能力範圍
除了包含設備需求,SLA 也可考慮加入系統的運作能力範圍。系統運作能力範圍可分為幾個種類,如硬碟空間能力範圍、使用者能力範圍及網路連結能力範圍等。您必須確保您的系統有足夠的能力執行需求。
經常檢視您的系統,如果發現系統達到能力範圍的臨界點,要立即處理。在 第六章 中,我們會就細節討論如何適時強化系統資源。
系統最佳執行時間
除了規劃系統的執行效能和運作能力範圍,SLA 通常也會規範系統的最佳執行時間。所謂系統最佳執行時間就是我們規定使用者可使用系統的時間。SLA 可能規定一天24小時都是系統最佳執行時間,或規定特定的幾個小時為最佳執行時間。要維護這項服務,DBA 必須計劃性的作固定備份和回復的動作。
系統元件和選項
現在您有了應用程式類型和製定服務範圍的概念,我們可以開始看看如何決定安裝合適的軟體。這裡有四種版本的 Windows 2000 和三種版本的 SQL Server 2000 供您挑選。這一節會教您各版本的不同性與適用性。
Windows 2000 的四個版本
Windows 2000 的四個版本就功能性的多寡依序是 Windows 資料中心、Windows 2000 高階伺服器版、Windows 2000 伺服器版,最後是 Windows 2000 專業版。以下會介紹每種版本的功能性,方便您找到適合您系統的版本,而不是胡亂的買個最貴的版本交差。
Windows 2000 專業版
Windows 2000 專業版適用於一般的桌上型電腦。通常,用到 Windows 2000 專業版的電腦,會用到的大約只是 SQL Server 2000 用戶端元件。當然,如果您想在自己的電腦上跑 SQL Server 2000 的話,可以加裝 SQL Server 2000 個人版。不過個人版僅允許您在自己的電腦上存取資料,不允許透過其他的系統存取。
相關資訊
只有 SQL Server 個人版 (和用戶端元件) 才可安裝在 Windows 2000 專業版上。
Windows 2000 伺服器版
Windows 2000 伺服器版是用來設定伺服器電腦的。也就是說安裝了 Windows 2000 伺服器版的電腦,就可以允許其他系統來存取其資源。Windows 2000 伺服器版支援的 SQL Server 版本是 SQL Server 標準版。Windows 2000 僅支援4個以下的 CPU 和 4 GB 以下的記憶體,超過就不行了!SQL Server 2000 也容許遠端存取。
注意
只有 SQL Server 標準版、個人版和 SQL Server 用戶端元件可以安裝在Windows 2000 伺服器版上。
Windows 2000 高階伺服器版
Windows 2000高階伺服器版也是用來設定伺服器電腦的。和 Windows 2000 伺服器一樣,高階伺服器版也允許其他系統作遠端存取。除了有伺服器版的功能外,高階版支援到8個 CPU 和8個記憶體。如果要支援 Microsoft Cluster Services (MSCS)的離誤功能,也必須要用到這個版本。除了支援 MSCS,這個版本還與 SQL Server 2000 共同支援 clustering technology、可更新的分散式檢視表。
注意
要在 SQL Server 2000 內使用到8個 CPU 和記憶體,就必須跑 SQL Server 企業版。其他如 SQL 的標準版、個人版和 Server 用戶端元件,都是可以架在 Windows 2000 高階伺服器版的 SQL 版本。
Windows 2000 資料中心版除了包括其他版本所有的功能外,更增加了對CPU 和記憶體的支援。這個版本可支援到64個 CPU 及64個記憶體。要使用 Windows 2000 資料中心版需向其配套的硬體廠商購買,對產品的服務則由此應廠商提供。
注意
要在 SQL Server 2000 內使用到64個 CPU 和記憶體,就必須跑 SQL Server 企業版。其他如 SQL 的標準版、個人版和 Server 用戶端元件,都是可以架在 Windows 2000 資料中心的 SQL 版本。
SQL Server 的三個版本
像 Windows 2000 一樣,SQL Sever 也提供了幾個版本供使用者選擇。選擇的方向取決於使用者將要使用多少 CPU 和記憶體。以下我們就來看看這四個版本。
用戶端軟體
一個 SQL Sever 用戶端元件由 network libraries 及允許用戶進入資料庫存取的功能所組成。這兩項是允許其他系統進入 SQL Server 存取很重要的特性,因此每個 SQL Server 版本都具有這些特性。
個人版
這是為小型資料庫而設計的版本。這個版本只允許主機端存取,其他的系統無法透過連線存取主機端資料。
標準版
這個版本是 SQL Sever 2000 兩款伺服器專用版本中的其中一款。這個版本的所有功能都和企業版一樣,唯一不同的是標準版只允許最多4個 CPU 和記憶體的存取。
企業版
這個版本支援 Windows 2000 的所有功能,但 SQL Sever 2000 只能在 Windows 2000 高階伺服器版或資料中心上才能運作。企業版還支援2-node 離誤 clustering 和可更新的分散式檢視表。
以下列舉 Windows 2000 和 SQL Server 2000 的功能性。
表 4-1 版本比較 Windows 2000個人版 Windows 2000標準版 Windows 2000企業版 Windows 2000專業版 功能限制 無資料提供 無資料提供 無用戶者存取 Windows 2000 伺服器版 功能限制 可支援到4個CPU和 可支援到4個CPU和 無用戶者存取 2GB的記憶體 4GB的記憶體 Windows 2000 高階伺服器版 功能限制 可支援到4個CPU和 支援MSCS 無用戶者存取 2GB的記憶體 可支援到8個CPU和 8GB的記憶體 Windows 2000 資料中心 功能限制 可支援到4個CPU和 支援MSCS 無用戶者存取 2GB的記憶體 可支援64個CPU和 64GB的記憶體 系統選項
除了選擇適合的 SQL Server 及 Windows 2000 版本外,有幾項其他的系統選項也可以選擇性的安裝。這些選項分別是 MSCS、SQL Server 2000複製選項和可更新的分散式檢視表 (SQL Server 2000企業版的新功能)。以下就來討論這幾種選項。
MSCS
MSCS 是Microsoft Cluster Services(Microsoft叢集服務)的縮寫,是必須在Windows 2000 和 SQL Server 2000 共同作用才可執行的功能。安裝 MSCS 的電腦可以視為備用或離誤的電腦。當軟體或硬體產生錯誤時,MSCS 可以立即回復資料。
MSCS 要有一個磁碟共享的子系統到兩台系統上 in the cluster,SQL Server 內的交易記錄檔、資料夾和執行檔都要放在這個子系統內。當主系統發生問題,會有「遺失心跳」的一個訊號產生,這時備份電腦會截取主系統電腦的IP位置和系統名稱,讓系統在備份電腦上運作。使用者將感覺不到主系統發生了問題。
相關資訊
一個叢集離誤和系統同樣需要有回復及立即重新開機的功能。MSCS 不提供容錯功能-僅提供快速回復。
SQL Server 複寫
SQL Server 複製選項可將 SQL Server 資料庫內的資料複寫一份到另一個資料庫系統。複製的方法有三種-快照式複寫、交易式複寫及合併式複寫。三種型式的複製均採訂閱模式,就是訂閱者可以接收由發行者發出的複製版本這樣的模式。
快照式複寫
快照式複寫是以定時快照的方式將檔案複製供其他系統使用。快照的動作需要使用者設定使用後才會執行工作,以避免影響系統的運作。快照式複寫的缺點是複製出來的版本,最新的資料僅止於上一次複製出來的版本,至於這個所謂最新版本可能已是幾個鐘頭前的版本了。
交易式複寫
這種類型的複寫方式在前端的處理和之前的快照式是相同的。不同處在於當交易類型的複製法啟動之後,發行者就不斷的讀取交易記錄檔並將讀取的資料傳給訂閱者。訂閱者這邊就會保持一份較新的複製,當然在傳送的過程中是會有遲滯的。
合併式複寫
合併式複寫和其他兩種類型複寫不同的地方在於,合併式複寫會同時在發行者與訂閱者端更新。SQL Server 利用觸發程序和時間戳記(timestamp)整合不同的複寫系統。合併式複寫在需要以多重執行緒方式進行複寫程序時很適用,當然系統要承受的負擔會比其他兩種複寫類型來得重。
可更新分散式檢視表
SQL Server 2000 推出的可更新分散式檢視表可讓系統間共享邏輯資料庫,加強了系統的延展性。邏輯資料庫可以分布到很多台電腦,使資料庫更具功能性。 第十八章 會就可更新分散式檢表作更詳細的討論。
資料庫排列
設計資料庫另一個重點就是資料排列。這裡的設計包括輸出後呈現給使用者的排列格式,如交易記錄檔、資料檔案等的排列。事先設計好您所想要的排列方式是很重要的,因為排列方式一旦決定之後更改起來就很費事了。 第五章 和 第六章 中我們會討論排列的細節。
交易記錄檔
交易記錄檔對系統穩定與否很重要。交易記錄檔記錄著一個系統所有資料的更動,當系統發生問題時也要靠交易記錄檔回復系統資料,因此必須將記錄檔放在適合的地方。最好使用陣列輸出入裝置保護交易記錄檔,當硬碟出了問題也不致損壞此記錄檔。
此外,這個檔案應放置於執行效能較高的裝置上,因為交易必須先存檔記錄後才能進行下一筆交易,若裝置的系統執行效能低,則會影響整個系統的執行效能。其他要注意的是記錄檔需有容錯性,這一部份的細節我們會在下一章討論。
當放置交易記錄檔的空間存滿,便會停止交易,所以要配置一個足夠的空間來存放交易記錄檔。交易檔可藉備份把空間釋放出來,但由於備份也可能會影響系統執行效能,有些DBA會先較大的空間存放記錄檔,約每個小時或每天備份一次。就空間上來說,最好設計能有足夠的空間存放八個小時的交易量且無須間中備份。以後您會發現其實這種是一種簡化的交易記錄檔。
資料檔案
資料檔案和交易記錄檔有不同的呈列方式。呈列的方式取決於使用者進入檔案的方式。檔案應分散存放在不同的硬碟上,分散各硬碟的負擔。我們會在下一章詳細的討論這部分。
您要準備足夠的空間來應付資料的成長。當資料成長,索引也跟著成長。所以必須定期的執行空間容量規劃測試,確保還有足夠的空間存放資料。
在學會了規劃資料檔案、計算空間、評估執行效能和以陣列式裝置配置子系統硬碟,下一個要考慮的就是是否允許容錯。當輸入輸出裝置子系統確認後,就可將資料檔案平均分配在各控制器和硬碟上。
應用程式
在這一節您會學到如何設計一個應用程式,並考慮其執行效能、延展性及成長性。
層次架構
一個應用程式的基本架構可以有很多種類型,各類型間的不同在於這個應用軟體包含了多少層次的系統架構。很多資料庫應用軟體的行銷重點就放在該軟體是採幾層次的系統架構。
層次架構比較
每一個資料庫應用程式皆可分為三層不同的服務範圍,分別是:
- 資料庫服務 :這是資料庫系統的後端部分,儲存資料庫的地方。
- 應用程式服務 :這是資料庫的應用程式或運算邏輯。
- 顯示服務 :這是屬於使用者的介面,這個服務必須負責把運算結果以使用者可以理解的形式呈現。
這些應用程式可分為一層式架構、兩層及三層式架構。這些架構的分隔在於該應用程式如何將上述三項服務分組。請先參照圖4-1的架構示意圖,之後會再仔細介紹這三種架構。
圖4-1 應用軟體架構示意圖 一層式架構即是三種服務元件都在安裝在同一系統上執行。以這種架構為主的應用軟體不處理系統平台外的需求。如 Microsoft Access database 就是一例。
現在已經很少有資料庫應用程式僅單採用一層式架構,尤其是 Windows 2000 支援的軟體。在 SQL Server 更是找不出支援此架構的資料庫應用軟體。有一種架構是您在一台電腦上同時安裝 Enterprise Manager 和資料庫,看來似乎是採這種模式,但其實這並不算是一層式架構,因為在這裡應用軟體其實是運用 SQL Server 網路上的元件來執行運作的。
兩層式架構
兩層式架構是將顯示服務和資料庫分別放在不同的系統上。而顯示服務(使用者介面)已內含運用程式邏輯。SQL Server Enterprise Manger 就是採這種架構。在這裡的使用者介面和程式邏輯均放置在 Enterprise Manager 內,但資料部分則是放在另一個裝有 SQL Server 資料庫的系統上。
兩層式架構是很常見的一種架構。很多這種架構的應用程式是以支援 Winodws API 的語言(如 Microsoft Visual C++ 或 Visual Basic)寫成的。在這種架構,使用者必須和 SQL Server 資料庫連線。但是這種連結有時是沒有效率的,因為很可能連線的應用程式都在閒置狀態,卻又佔住連線。
三層式架構
三層式架構是將資料庫、應用程式和顯示服務層放在不同的系統上。這種架構利用中間的應用程式層,多工連結至顯示服務層,以此來減少使用者直接與 SQL Server 連線的機會。此外,中間的應用程式層也可大量的執行運算邏輯,使 SQL Server 好好的扮演資料遞送的角色。
對於 Web 架構的應用程式是兩層式或三層式則是有些爭議。其實您可以做個簡單的分析,如果說顯示服務端只是透過終端處理機或瀏覽器就可瀏覽資料庫資料,那此應用程式就很可能是採兩層式架構。
如上述所見,如果將服務範圍分開,您就可以運用到很多不同的系統了。在實際的應用方面,很多系統就是把一台資料庫伺服器連結到不同的應用程式伺服器上以服務更多的用戶。所以當您設計一個系統時,就得考慮使用者的多寡以及系統將支援哪種應用程式。
執行效能與延展性
當您在架構一個應用程式及資料庫時,要考慮此結構是否具執行效能及延展性。下列的選項可能會影響這系統的執行效能與延展性。
- 使用暫存工作 暫存工作表適用於較小規模的資料庫,對較大規模的資料庫則不適用。
- 使用彙總函數功能 使用彙總函數功能如 MIN( )、MAX( ) 和 AVG( )的比例和資料的多寡有絕對的關係。所以要小心不要因為使用了這個功能而影響系統執行效能。
- 使用索引 當資料量越來越大時,就需要用到索引,我們會在 第十七章 繼續討論索引。
- 使用交易 明確的交易使用可以確保整個運作過程的完整性。不過,當同時連線的使用者數量成長時,盡可能降低資源鎖定是相當重要的。
如上所述,當您設計一個系統時必須考慮許多層面以因應工作量的成長。如果能在設計之初就可將系統以最佳化的技巧來設計,便可設定出一個有延展性的系統了。
本章總結
如本章所述,在設計 SQL Server 系統的同時要將很多事情列入考慮。而且因為每個公司的需求不盡相同,即使您專職系統設計,您所設計的每一個系統也很難跑出一樣的設計效果,更別說可以找到一個人簡單的告訴您要怎樣來設計您的系統了。
本章討論了幾個設計上的要點。您必須了解一個公司的最佳執行時間需求,並基於此而設計合適的系統。這些可能包括設計資料中心的數量、將系統叢集化、使用陣列輸出入裝置或複製功能。此外,系統的延展性和其執行效能也是整體設計的考量範圍,最後還要注意應用程式的執行效能。這些項目會避免日後使用者數量增加時讓系統處理速度變慢。
在下一章,我們會對許多本章介紹過的項目深入探討。下一章會告訴您關於 I/O子系統的運作,其執行效能與容錯功能,以及如何計劃與安裝一個好的 I/O 子系統。