資料庫伺服器

資料庫伺服器

運行在區域網路中的一台或多台計算機和資料庫管理系統軟體共同構成了資料庫伺服器,為客戶套用提供服務,這些服務是查詢、更新、事務管理、索引、高速快取、查詢最佳化、安全及多用戶存取控制等。伺服器可以移植到功能更強的計算機上,不涉及處理數據的重新分布問題。

簡介

運行在區域網路中的一台或多台 計算機和 資料庫管理系統 軟體共同構成了資料庫伺服器,資料庫伺服器為客戶套用提供服務,這些服務是查詢、更新、事務管理、 索引、高速快取、查詢最佳化、安全及多用戶存取控制等。

處理方法

相信各位站長在租用伺服器的時候,都有出現過伺服器數據丟失的情況,數據丟失不可怕,可怕的是丟失後無法恢復,在此教各位幾種數據丟失的修複方法:

一、伺服器租用的存儲非常重要的,這個我想大家都知道,硬碟作為伺服器的主要存儲設備,硬碟是一種技術含量高、製造精密的設備,伺服器硬碟已經達到1萬轉以上,普通的SATA硬碟也非常接近這個轉速,在實際的套用中,一點小問題都可能造成伺服器硬碟的故障,所以一般伺服器租用都採用 Raid磁碟陣列存儲,這樣就可以增加伺服器硬碟的抗故障能力。

二、除了以上的方法外,對於一些重要的數據還要進行實時的備案,推薦企業用戶、商務用戶架構的網路伺服器,選用磁帶機配合專業備份軟體(VeritasNetbackup、CAArcserver),定時進行備份,如果條件允許的話最好能每天備份。

三、因為個人的錯誤操作原因,導致伺服器檔案不小心被刪除或者丟失的話,可在網上下載一些恢復軟體(DataRecove,Easyrecove 等)嘗試來進行恢得,當然,做之前可以先用Ghost軟體做個磁碟全備份,同時在恢復時最好是接從盤。如果你對自己的恢復結果不滿意,還可以到電腦城找專業的數據恢復公司幫你進行硬碟數據恢復。

四、要經常關心伺服器的運行狀況,對於伺服器的指示和警示燈要多留意。一般來講,伺服器租用外觀都有每一塊硬碟指示燈,正常情況下一般會是綠色,指示燈出現特殊情況時,就需要採用相關措施,仔細檢查硬碟設備是否正常。一旦硬碟受損或者出現故障,不要擅自處理,要找有經驗的技術人員作出詳細檢查再作處理方案。

優缺點

(1) 減少編程量

資料庫伺服器提供了用於數據操縱的標準接口API。

(2) 資料庫安全保證好

資料庫伺服器提供監控性能、並發控制等工具。由DBA統一負責授權訪問資料庫及網路管理。

(3) 數據可靠性管理及恢復好

資料庫伺服器提供統一的資料庫備份和恢復、啟動和停止資料庫的管理工具。

(4) 充分利用計算機資源

資料庫伺服器把數據管理及處理工作從客戶機上分出來,使網路上各計算機的資源能各盡其用。

(5) 提高了系統性能

● 能大大降低網路開銷。

● 協調操作,減少資源競爭,避免死鎖。

資料庫伺服器資料庫伺服器

● 提供在線上查詢最佳化機制。

(6) 便於平台擴展

● 多處理器(相同類型)的水平擴展。

● 多個伺服器計算機的水平擴展。

● 垂直擴展:伺服器可以移植到功能更強的計算機上,不涉及處理數據的重新分布問題。

選擇方法

當一個新的業務系統開發完成後,需要在一個區域乃至全國推廣此套用軟體,如何根據業務規模來選擇伺服器配置、內外置磁碟大小、以及網路頻寬,是一件複雜的事情。

一個最真實的評估,是建立一個接近真實業務套用的操作環境,進行各種壓力測試,測算出不同的用戶數量下,系統的回響時間和吞吐量,並得出當時伺服器的各種資源的利用率情況,對硬體資源的完整評估,需要考慮下列三個方面:

伺服器性能的評估

客戶端工作站或前端桌面的評估

通訊網卡和網路頻寬的評估

如果不能建立準確的壓力測試環境,需要根據工業界的Benchmark對伺服器進行評估,推算出符合業務規模的伺服器配置,同時要考慮在做系統管理時所消耗的資源,如在做備份、恢復、問題診斷、性能分析時、軟體維護時都會對資源帶來附加的消耗,對重要資源要考慮為將來留下升級和可擴展的餘地,下列是一些通用的原則:

處理器:要考慮高峰時的處理器的能力,並適當保留一些緩衝,確保在業務增長時,系統有擴展的餘地。如果要保持快速的回響能力,應當為CPU保留20%至40%的富餘量。

記憶體:要為運行在此伺服器的所有套用軟體考慮記憶體,所需要的記憶體主要依賴於用戶數、應用程式類型、進程的方式、和應用程式處理的數據量決定。

磁碟:評估業務的實際用戶的數據量,以此推算出磁碟的最小個數,不要忘記選擇備份設備(如磁帶機)。

IO槽:儘量保留更多的IO槽,防止將來插更多的PCI卡。

網路:選擇合適的網卡,保證網路不是系統的瓶頸。

在評估資料庫伺服器性能時,最困難的事情是如何把握準確度問題,到底考慮哪些因素等。理想情況下,應考慮下列要素:

交易的複雜性

交易率

數據讀/寫比例

並發連線數目

並發交易數目

資料庫最大表的大小

性能度量的目標

根據各種Benchmark測試結果和對各種生產系統的檢測,下表概括了CPU、磁碟、記憶體頁面、網路和虛存頁交換的利用率,可看出一個伺服器如果其利用率保持在Good 所標示的範圍內時,是一種理想的模式。

基於rPerf的推算,評估資料庫伺服器的CPU

rPerf(Relative performance)是從IBM公司解析模型得出的商務處理性能估計值。該模型模擬部分系統的操作,如中央處理器、高速快取和記憶體,該模型沒有模擬磁碟和網路的輸入/輸出操作。雖然採用了一般資料庫和作業系統的參數,但該模型不能反映出具體的資料庫或AIX版本。除非單獨說明,否則rPerf均在系統推出時估計。IBM pSeries 640-B80為基準參照系統,其值為本。雖然rPerf可用於比較商業處理性能,但實際的系統性能可能不同,取決於許多因素,包括系統硬體配置和軟體設計與配置。

評估資料庫伺服器的性能,需要理解交易的類型、高峰期的情況、用戶數量、在高峰時每個用戶的交易數量。假如在高峰時,有三種典型的交易類型:輕的、一般的、重的。需要知道高峰時,每種交易的並發用戶數目。假定尖峰時間為:10:00-11:00,每個用戶的交易數目如下:

輕的交易 =120 交易/用戶

一般的交易= 60 交易/用戶

重的交易 = 15交易/用戶

下面舉例說明如何計算所需的rPerf值,假定某公司的情況如下:

業務尖峰時間: 10:00-11:00=1Hour=3600秒

交易類型: 無複雜查詢的簡單套用

相對交易類型,用戶數目分布:輕的=2000, 一般=50, 重的=5

在高峰時,每個用戶的交易數量:

輕的=120交易/用戶

一般=60交易/用戶

重的=15交易/用戶

對於rPerf=1的伺服器,每個交易回響的CPU秒

輕的=1

一般=3

重的=15

最大的CPU利用率:60%

根據上述公式,可推算出不同交易類型所對應的rPerf值。

輕的交易:NU*TX*CS/PP=2000*120*1/3600=66.0

一般交易:NU*TX*CS/PP=50*60*3/3600=2.5

重的交易:NU*TX*CS/PP=5*15*15/3600=0.3

所需的總的rPerf/MC=(66.0+2.5+0.3)/0.7=98.3 rPerf

基於TPC-C的推算,評估資料庫伺服器的CPU

TPC-C基準是事務處理委員會建立的一個專門演示線上事務處理性能(OLTP)的性能基準,它的測量方法是為了使客戶能夠評估不同的線上事務處理系統的性能,這些事務進程於一個可控制的狀態下在一個標準的資料庫中運行。

TPC-C測試包括5個典型的OLTP事務,它們是:

新訂單:一個用戶提交一個新的訂單

支付:更新用戶的賬戶餘額以反映一個支付

交付:訂單的交付(通過一個批事務處理實現)

訂單狀態:返回用戶最新訂單的狀態

庫存水平:監控當前倉庫庫存

TPC-C的事務處理是在一個9個表的資料庫上實現的事務處理過程包括:更新、插入、刪除、終止,以及對主和次級鍵的訪問,每種事務處理90%的回響時間應小於或等於5秒,其中,庫存水平的回響時間可以在20秒以內。

TPC-C的吞吐量值是終端活動水平的直接結果,如每一個倉庫有10個終端,在每一個終端上上述5個事務都是可用的,一個遠程的終端仿真器被用來在性能測試過程中進行必要的事務混合工作。這個混合代表著一個完整的訂單商務處理流程:錄入、支付、檢驗、交付。更專業的是,這個必要的混合被定義為產生一個相等數量的新訂單和支付事務,以及在每10個新訂單事務中產生一個交付事務,一個訂單狀態檢驗事務和一個庫存水平檢驗事務

遠程終端仿真器也被用來測量每一個事務的回響時間,以及用來模擬鍵入時間及思考時間,鍵入時間是指在終端上錄入數據所花費的時間,思考時間是指操作人員在終端讀取事務的結果,進行下一個事務請求之前所花費的時間。每一個事物都有一個最小鍵入時間和最小思考時間。另外,這個回響時間必須在一個給定的極限值之下。

TPC-C基準測試的結果--TPC-C的吞吐量(tpmC),代表的是系統的最大的持續性能,它被定義為系統每分鐘可以處理多少個新訂單事務,與此同時,系統還在處理其他四種事務類型(支付、訂單狀態、交付、庫存水平)。所有5個TPC-C事務都有某個限定的用戶回響時間要求,其中新訂單事務的回響時間是5秒以內。因此如果一個系統的TPC-C值是100tpmC/min,說明該系統在每分鐘處理其他的混合的TPC-C事務的工作的同時,可以產生100個新訂單事務。

如何使用TPC-C進行伺服器的評估

由上可知,TPC-C測試基準主要用於測試主機伺服器每分鐘能夠處理的在線上交易筆數,測試產生的單位結果是TPM值(Transaction Per Minute,即每分鐘處理的交易比數)。

TPC-C雖然客觀的反映了各個計算機廠商的系統處理性能,並且測試基準也在不斷完善以更加貼近現實套用的交易環境,但是仍然無法與紛繁多樣的各類實際套用完全吻合;而且參加TPC測試的主機系統都做了適當程度的系統最佳化。因此,在實際業務套用系統選擇主機伺服器乘載體時,必須考慮到多方面的因素,以最大程度的做到適合套用系統的生產需求。

以下計算公式是IBM公司在金融綜合業務系統的實際套用中總結的經驗方法論,基本反映了金融業務特點對主機處理能力的需求:

TPM=TASK x 80% x S x F / (T x C)

其中:

TASK:為每日業務統計峰值交易量

T:為每日峰值交易時間,假設每日80%交易量集中在每天的4小時,即240分鐘內完成:T=240。

S:為實際銀行業務交易操作相對於標準TPC-C測試基準環境交易的複雜程度比例。由於實際的金融業務交易的複雜程度與TPC?C標準測試中的交易存在較大的差異,須設定一個合理的對應值。以普通儲蓄業務交易為例,一筆交易往往需要同時打開大量資料庫表,取出其相關數據進行操作,相對於TPC-C標準交易的複雜度,要複雜很多;根據科學的統計結果,每筆交易操作相比較於TPC標準測試中的每筆交易的複雜度此值可設定為10~20。

C:為主機CPU處理餘量。實際套用經驗表明,一台主機伺服器的CPU利用率高於80%則表明CPU的利用率過高會產生系統瓶頸,而利用率處於75%時,是處於利用率最佳狀態。因此,在推算主機性能指標時,必須考慮CPU的冗餘,設定C=75%。

F:為系統未來3~5年的業務量發展冗餘預留。

綜上所述,為保障在線上業務處理性能要求,我們可推算得出主機所需的處理能力,據此得出相應的機型和配置。

相關詞條

相關搜尋

熱門詞條

聯絡我們