SQL SERVER 2000壓力測試 (轉)[@more@]

SERVER 2000壓力測試:namespace prefix = o ns = "urn:schemas--com::office" />

 -- 大記錄量，大資訊容量

隨著Microsoft的新一代關係 2000（以下簡稱SQL2K）的釋出，業界紛紛瞄準了它的，尤其是針對於 8的效能比較。在一系列的測試中，SQL2K的的確確沒有辜負對它的期望，獲得了相當不錯的成績，終於肩負起對抗Oracle，搶佔高階資料庫市場的使命。

在關聯式資料庫的應用當中，當隨著數量級或者容量級的資料急劇膨脹，很多資料庫的效能就飛速下降。因此在要求嚴格的應用中，通常Oracle資料庫是作為的首選，然而其高昂的價格卻讓人望而卻步。隨著SQL2K的到來，我們期待著Microsoft的SQL2K在大記錄量和大容量的情況下能有優秀的表現。在此，我們針對SQL2K在這兩方面表現的效能作了測試。

測試計劃：

整個測試過程分為兩個部分，第一部分是資料庫大容量狀態下的情況，第二部分是資料庫在大記錄量下的執行情況。為了方便測試，我們編寫了一個進行各種資料庫操作，並進行紀錄。

在兩個部分的測試中，我們分別在空資料庫環境下進行各種資料庫基本操作，並記錄各個操作所需要的時間，然後再插入了大容量/大記錄量的資料後，再作同樣的操作並紀錄操作所需時間。最後對前後的時間進行比較。當然，由於傳輸等問題，可能導致一些誤差，但是這對我們的測試不會有太大的影響。

測試準備：

★  測試環境：

OS： 2000 Server

Database：Microsoft SQL Server 2000

Database Server：ADV2000

★  建立資料庫：

使用“企業管理器”在資料庫上建立資料庫test，並且設定其大小為10GB，以避免在預設容量大小下，隨著資料庫容量增加而導致伺服器動態分配空間的時候引起開銷。

隨後再在test資料庫上建立一個Tab表，包含以下幾個欄位：

欄位名

資料型別

欄位情況

可否為空

id

Int，4

主鍵，自加

不可

name

Char, 10

不可

age

Int,  4

不可

Photo

Image, 16

可

（表一）

  ★ 並且我們使用 6編寫了一個測試程式，採用ADO介面，連線資料庫伺服器ADV2000。測試程式主要完成一下的功能：

1、  插入2000條資料（insert）

2、  選擇1000條資料（）

3、  1000條資料（update）

4、  刪除1000條資料（delete）

5、  插入100，000條帶圖片資料（用於大容量測試）/插入1，000，000條不帶圖片測試（用於大記錄量測試）

測試過程

整個測試過程分為大容量資料測試和大記錄量資料測試：

大容量資料測試：

在大容量的資料測試中，我們透過插入圖片來使資料庫的容量膨脹，所以在以下的所有資料庫操作中，例如插入資料，都是指的插入帶圖片的資料。測試中選擇了一張41,958位元組的圖片，並且大容量測試是在插入100,000條記錄以後的測試，因此我們可以大致估計當時的資料表的容量為 (41958 * 100000) / (1024 * 1024) = 4001.43MB。

首先透過測試程式按順序進行如下測試，在空表中“插入2000條紀錄->選擇1000條記錄->更新1000條記錄->刪除1000條記錄”，並記錄下各操作所需要的時間。測試結果如下圖和表中：

ectratio="t">

（圖一）

Insert 2000條紀錄

Select 1000條紀錄

Update 1000條紀錄

Delete 1000條紀錄

132.781 S

41.94 S

0.841 S

1.552S

（表二）

上面的測試是在空資料表中進行資料庫各種基本操作的測試，並且記錄了所需要的時間。然後我們插入100，000條帶有圖片的紀錄，使資料表的資料量膨脹到4001.43MB，接下來的工作就是測試大容量環境下的各種資料庫操作情況。

(圖二)

同樣按照以上的的步驟進行測試：“插入2000條紀錄->選擇1000條記錄->更新1000條記錄->刪除1000條記錄”，並記錄下各操作的時間，如下：

（圖三）

Insert 2000條紀錄

Select 1000條紀錄

Update 1000條紀錄

Delete 1000條紀錄

139.05 S

42.36 S

0.971 S

2.264 S

（表三）

透過對比，我們發現：

在大記錄量（百萬條記錄得資料量下），對SQL2K的影響並不算大，其效能影響也比較小，從下圖以看出來：

（圖四）

從這個柱狀圖可以反映出在需要大量時間的SQL操作中，SQL2K在大容量資料環境下的效能基本能保持，不會有太多的效能下降。但是從後面兩個只需要極短時間執行的SQL操作從圖中無法反映出什麼情況。

那讓我們透過計算再來看一下了，下面是在大容量資料環境下，同樣操作增加的時間與初始資料庫環境下所需時間的百分比：

Insert 2000條紀錄

Select 1000條紀錄

Update 1000條紀錄

Delete 1000條紀錄

4.72%

1.001%

15.46%

45.88%

（表四）

從表中中可以看出，Update和Delete操作的時候，好像在大容量環境下的效能損失嚴重。但是考慮到，因為存取的資料庫伺服器與客戶端位於不同的機器上，雖然透過100M的內部網連線，但是由於網路的問題，導致了存取中網路的延時。當操作所需要的時間比較大的時候，這一點延時對時間比例影響不大，而一旦操作所需要的時間比較短的時候，這個延時就顯得尤為突出了。

對於Delete操作中的45.55%的效能損失，還有一個原因是，當刪除紀錄的時候，資料庫會重建。當資料量太大的原因下，導致了重建索引耗費了較多的時間。

大記錄量資料測試：

在大記錄量環境下的測試，為了讓大容量測試不影響這次測試，首先我們徹底刪除掉大容量測試中使用的表Tab，並且重新建立一個完全一樣的新表Tab用於此次測試。

這個測試中的步驟和上一個測試基本一樣，同樣測試了空表狀況下的各個基本資料庫操作所需要的時間，但是，這個測試中我們沒有插入圖片，photo欄位沒有插入任何東西，保持為空：“插入2000條紀錄->選擇1000條記錄->更新1000條記錄->刪除1000條記錄”，如下所示：

（圖五）

Insert 2000條紀錄

Select 1000條紀錄

Update 1000條紀錄

Delete 1000條紀錄

16．274 S

0.07 S

0.04 S

0.04 S

（表五）

在大容量資料環境下，我們插入的是100，000條帶有圖片的資料，從而導致了資料量達到了4001MB，而在這次的大記錄量環境下的測試，100，000條資料量可能已經不能滿足我們的需要，我們希望能在更高資料量環境下進行測試，以便於增大添入大數量級資料前後操作效率的差異，因此選擇了插入1，000，000條資料。

（圖六）

完成我們的大數量級的資料插入以後，進行下一步的測試紀錄：“插入2000條紀錄->選擇1000條記錄->更新1000條記錄->刪除1000條記錄”，記錄下每一個操作所需要的時間，如下所示：

（圖七）

Insert 2000條紀錄

Select 1000條紀錄

Update 1000條紀錄

Delete 1000條紀錄

16．574 S

0.05 S

0.05 S

0.051 S

（表六）

比較兩種狀況下的測試結果：

（圖八）

  從第一個操作Insert來看，同樣SQL2K在大記錄量環境下效能損失不大，但是其它幾個操作結果從這個圖中依舊無法表現出來，我們只能透過增加時間百分比來作比較：

Insert 2000條紀錄

Select 1000條紀錄

Update 1000條紀錄

Delete 1000條紀錄

1.84%

-28.6%

25%

27.5%

（表七）

透過增長時間的百分比可以看出在這幾個操作中效能有所損失，但是我們卻無法派出是否是因為這些操作時間太短，因為網路而引起的誤差。

四、測試結果

總結：雖然在測試中，因為很多的SQL操作因為所需要的時間過短，而導致受到網路傳輸的影響。但是我們仍然可以透過所需時間較長的SQL操作進行總結：

無論是在大容量（數GB單位）還是大記錄量（百萬條記錄量）環境下，SQL SERVER 2000的效能都能保持較高的水平。一般情況下的效能損失不到5%，因此完全能夠滿足我們通常的實際應用。

但是因為等條件的限制下，我們無法對更大容量（十GB、百GB乃至TB容量級），更大記錄量（千萬，億級資料量）的環境下進行測試。

總體說來，在普通的企業級應用中，SQL SERVER 2000已經是能夠滿足我們的要求。