❶ 如何提高sql Server 2000 的性能
現在的伺服器,配置超過4G就很多,在配置SQL Server資料庫伺服器後,很多人只選默認的設置,雖然可以正常使用,可是卻大量浪費了內存空間(SQL服務使用的內存不會超過1.8G),系統性能也不能因為的大內存而提升,這是很可惜的。下面介紹一種方法教你如何提高SQL Server 2000的性能。 配置的過程如下：(如果伺服器的內存少於4G,不用配置) 1.打開系統中的大內存支持(windows) 要啟用Windows 2000 Advanced Server或Windows 2000 Datacenter Server支持 大於4GB的物理內存，必須將參數 /pae添加到boot.ini文件中。 [boot loader]timeout=0default=multi(0)disk(0)rdisk(0)partition(1)WINNT [operating systems] multi(0)disk(0)rdisk(0)partition(1)WINNT= "Microsoft Windows 2000 Advanced Server" /fastdetect改為[boot loader]timeout=0default=multi(0)disk(0)rdisk(0)partition(1)WINNT [operating systems] multi(0)disk(0)rdisk(0)partition(1)WINNT= "Microsoft Windows 2000 Advanced Server" /fastdetect /pae 改好後,重啟系統。 2.啟用鎖定內存頁選項(windows) 啟用鎖定內存頁選項 在"開始"菜單上單擊"運行"子菜單，然後在"打開"框中鍵入"gpedit.msc"。 在"組策略"控制台上，展開"計算機配置"，然後展開"Windows設置"。 展開"安全設置"，然後展開"本地策略"。 選擇"用戶許可權分配"復選框。 詳細資料窗格中隨即顯示出策略。 在詳細資料窗格中，雙擊"鎖定內存頁"。 在"本地安全策略設置"對話框中，單擊"添加"按鈕。 在"選擇用戶或組"對話框中，添加有權運行sqlservr.exe的帳戶。 3.啟用SQL的AWE 若要啟用AWE，請將awe enabled設置為1。除非指定了max server memory的值，否 則SQL Server將保留幾乎所有可用內存，只留下128MB或更少。 如果已成功啟用該選項，則當SQL Server 2000實例啟動時，SQL Server錯誤日誌中將 出現"已啟用地址窗口擴展"這條消息。 awe enabled 是高級選項。如果正在使用sp_configure系統存儲過程更改該設置，則只有 當show advanced options設置為 1 時才能更改awe enabled。 code如下,設定SQL 使用6G的內存： sp_configure 』show advanced options』, 1 RECONFIGUREGOsp_configure 』awe enabled』, 1 RECONFIGUREGOsp_configure 』max server memory』, 6144 RECONFIGURE GO 必須重新啟動SQL Server 2000實例才能使更改生效。 net stop mssqlserver
❷ SQLServer性能調優如何定位和解決
不需要Item_Photo欄位數據，那麼我們可以修改SQL，只取我們需要的欄位數據，就可以避免這個問題，提高SQL性能，另外根據我的經驗，開發人員習慣性使用SELECT *，從不管那些數據是需要還是不需要的，先全部取過來再說，這種習慣性行為確實不是一個好習慣。
❸ SQLSERVER 怎樣 加索引 能顯著提高速度
SQLSERVER 怎樣 加索引 能顯著提高速度
1、評估索引本身的佔用空間，當索引相對於其數據本身過大可能會無明顯作用。這種情況
體現在：表很小，索引列過多，索引碎片過多。當索引在select 中不起作用時，你還必須
在insert 和update、delete 這些操作中去維護這些不起作用的數據。
2、In 語句不一定不能使用索引，where id in(1,2)和where id =1 or id=2是等效的，這
里的in 和not in 的性能是相同的。而不能使用索引的原因是嵌套查詢： where id in(sel
ect 1 union select 2).
❹ 通過使用正確的search arguments來提高SQL Server資料庫的性能
原文地址：http://www.sqlpassion.at/archive/2014/04/08/improving-query-performance-by-using-correct-search-arguments/
今天的文章給大家談談在SQL
Server上關於indexing的一個特定的性能問題。
問題
看看下面的簡單的query語句，可能你已經在你看到過幾百次了
--
Results
in
an
Index
Scan
SELECT
*
FROM
Sales.SalesOrderHeader
WHERE
YEAR(OrderDate)
=
2005
AND
MONTH(OrderDate)
=
7
GO
上門的代碼查詢一個銷售信息，需要一個特定的月份和年份的，這不是很復雜。但是不幸的的事，這個qeury的效率不行，即使OrderDate這一列已經做了Non-Clustered
Index。可以看看下面的qeury執行圖，你能看到Query
Optimizer已經選擇了定義在列OrderDate下的Non-Clustered
Index，但是SQL
Server卻做了Index的一個完整掃描，而不是期待中的Seek
operation。
這實際上不是SQL
Server的限制，而是relational
database都是這樣的。只要你對一個做了index的列（Search
Argument）加了函數操作，資料庫引擎就必須再次掃描這個index，而不是去直接執行seek
operation
解決方案
為了解決上門的問題，必須要避免在列上門直接應該函數，比如上面的問題可以用下面的代碼來代替
--
Results
in
an
Index
Seek
SELECT
*
FROM
Sales.SalesOrderHeader
WHERE
OrderDate
>=
�'
AND
OrderDate
<
�'
GO
我們重寫的這個query語句，能達到同樣的效果，不用函數MONTH了。從此query的執行圖來看，SQL
Server執行了seek
operation，在查詢的范圍內進行的scan。所以，如果你要在where查詢中用到函數，用到表達式的右側，來避免性能問題。比如下面的例子。
--
Results
in
an
Index
Scan
SELECT
*
FROM
Sales.SalesOrderHeader
WHERE
CAST(CreditCardID
AS
CHAR(4))
=
'
GO
這個query會使SQL
Server掃描了整個Non-Clustered
Index。所以當表變得更大的時候，這個擴展性等各方面就很差了。如果把函數放在表達式的右側，SQL
Server就能執行seek
operation了
--
Results
in
an
Index
Seek
SELECT
*
FROM
Sales.SalesOrderHeader
WHERE
CreditCardID
=
CAST('
AS
INT)
GO
總結
通過今天的blog，我想你們已經認識到了不要在做過indexed的列上直接應用函數，不然SQL
Server會掃描你整個index，而不是做seek
operation。當你的表變得越來越大的時，你會崩潰的。
譯後記
這也是我在看微軟SQL
Server認證考試Exam70-461的TrainingKit的時候，它書裡面反復強調的。簡單來講就是保證不要直接用函數作用在做過index的列上，要用函數的話，變通到表達式的右側來。至於為什麼會影響性能。因為我對index還不熟悉，我理解的不是很清晰。
我大概猜想如下，先記下，歡迎討論。
對某一個列做index，是不是類似對這一列的數據做一個hash映射，當在查找這一列的數據的時候，直接可以做O(1)的操作（是不是就是它講的seek
operation）。如果對這一列使用了函數，SQL
Server的機制就是不會重新做一個作用了函數後的列的hash，它就簡單的一個一個的比較了。是O(N)的操作了。
❺ 如何提高sqlserver伺服器cpu使用率
解決法有兩種：第一種、打開SQL選中SQLServer,右鍵，屬性。選擇服務。把啟動模式改成手動或者禁止就可以了。第二種、是安裝了SQL的。打開SQLServer服務管理器，反選「當OS啟動時自動啟動服務」即可。
❻ 如何提高ArcSDE SQLServer的性能
ArcGIS客戶端所在的機器需要至少512M的可用內存，ArcSDE Server所在的機器可用的內存不能少於1G。可以使用windows的任務管理查看可用內存。可以關閉一些不使用的應用程序來釋放可用內存或者使用資料庫企業管理器來調整內存後再測試是否性能有提升。
3. 重建表上的索引來提高性能。詳細信息可以查看下面的詳細鏈接。SQLServer的腳本運行在Query Analyzer, 位於Manager > Tools > SQL Query Analyzer.索引重建後查看效率有沒有提升。
4. 使用ArcCatalog的Analyze功能增加FeatureClass信息統計的頻率。在FeatureClass上右鍵選擇Analyze並選擇所有的表。
5. 查看SDE Server和客戶端應用之間是否有網路堵塞。性能是否與連接到Server的用戶數量？高的網路堵塞會嚴重影響性能。
6. 測試使用以下的ArcCatalog的直連方式，看看性能是否有提升。
Server : <blank>
Service : sde:sqlserver:<DATASOURCE>
Database : sde
Username : sde
Password : <SDE_User_Password>
DATASOUCE是SQLServer實例名稱，如果不指定，就使用機器名。
7 提高ArcSDE圖層的性能，具體信息可以查看相關的鏈接信息。
8 在%SDEHOME%\etc\giomgr.defs修改MINBUFSIZE和MAXBUFSIZE的值並導入新值使用ArcSDE命令：
BUFSIZE 409600 # minimum buffer size > 4096
MAXBUFSIZE 819200 # maximum buffer size > MINBUFSIZE
使用sdeconfig命令導入新的值，如：
sdeconfig -o import -f C:\arcgis\ArcSDE\sqlexe\etc\giomgr.defs -i 5151 -D DBOG -u sde -p sde
9 查看最新的補丁是否被應用，具體信息可以查看下面的連接。
❼ SQLServer求優化
我一不太會優化，提供你一些優化的方法吧
操作符優化
in 操作符
用in寫出來的sql的優點是比較容易寫及清晰易懂，這比較適合現代軟體開發的風格。
但是用in的sql性能總是比較低的，從oracle執行的步驟來分析用in的sql與不用in的sql有以下區別：
oracle試圖將其轉換成多個表的連接，如果轉換不成功則先執行in裡面的子查詢，再查詢外層的表記錄，如果轉換成功則直接採用多個表的連接方式查詢。由此可見用in的sql至少多了一個轉換的過程。一般的sql都可以轉換成功，但對於含有分組統計等方面的sql就不能轉換了。
推薦方案：在業務密集的sql當中盡量不採用in操作符。
not in操作符
此操作是強列推薦不使用的，因為它不能應用表的索引。
推薦方案：用not exists 或（外連接+判斷為空）方案代替
<> 操作符（不等於）
不等於操作符是永遠不會用到索引的，因此對它的處理只會產生全表掃描。
推薦方案：用其它相同功能的操作運算代替，如
a<>0 改為 a>0 or a<0
a<>』』 改為 a>』』
is null 或is not null操作（判斷欄位是否為空）
判斷欄位是否為空一般是不會應用索引的，因為b樹索引是不索引空值的。
推薦方案：用其它相同功能的操作運算代替，如
a is not null 改為 a>0 或a>』』等。
不允許欄位為空，而用一個預設值代替空值，如業擴申請中狀態欄位不允許為空，預設為申請。
建立點陣圖索引（有分區的表不能建，點陣圖索引比較難控制，如欄位值太多索引會使性能下降，多人更新操作會增加數據塊鎖的現象）
> 及 < 操作符（大於或小於操作符）
大於或小於操作符一般情況下是不用調整的，因為它有索引就會採用索引查找，但有的情況下可以對它進行優化，如一個表有100萬記錄，一個數值型欄位a，30萬記錄的a=0，30萬記錄的a=1，39萬記錄的a=2，1萬記錄的a=3。那麼執行a>2與a>=3的效果就有很大的區別了，因為a>2時oracle會先找出為2的記錄索引再進行比較，而a>=3時oracle則直接找到=3的記錄索引。
like操作符
like操作符可以應用通配符查詢，裡面的通配符組合可能達到幾乎是任意的查詢，但是如果用得不好則會產生性能上的問題，如like 『%5400%』 這種查詢不會引用索引，而like 『x5400%』則會引用范圍索引。一個實際例子：用yw_yhjbqk表中營業編號後面的戶標識號可來查詢營業編號 yy_bh like 『%5400%』 這個條件會產生全表掃描，如果改成yy_bh like 』x5400%』 or yy_bh like 』b5400%』 則會利用yy_bh的索引進行兩個范圍的查詢，性能肯定大大提高。
union操作符
union在進行表鏈接後會篩選掉重復的記錄，所以在表鏈接後會對所產生的結果集進行排序運算，刪除重復的記錄再返回結果。實際大部分應用中是不會產生重復的記錄，最常見的是過程表與歷史表union。如：
select * from gc_dfys
union
select * from ls_jg_dfys
這個sql在運行時先取出兩個表的結果，再用排序空間進行排序刪除重復的記錄，最後返回結果集，如果表數據量大的話可能會導致用磁碟進行排序。
推薦方案：採用union all操作符替代union，因為union all操作只是簡單的將兩個結果合並後就返回。
select * from gc_dfys
union all
select * from ls_jg_dfys
sql語句索引的利用
對條件欄位的一些優化
採用函數處理的欄位不能利用索引，如：
substr(hbs_bh,1,4)=』5400』，優化處理：hbs_bh like 『5400%』
trunc(sk_rq)=trunc(sysdate)， 優化處理：
sk_rq>=trunc(sysdate) and sk_rq
進行了顯式或隱式的運算的欄位不能進行索引，如：
ss_df+20>50，優化處理：ss_df>30
『x』||hbs_bh>』x5400021452』，優化處理：hbs_bh>』5400021542』
sk_rq+5=sysdate，優化處理：sk_rq=sysdate-5
hbs_bh=5401002554，優化處理：hbs_bh=』 5401002554』，註：此條件對hbs_bh 進行隱式的to_number轉換，因為hbs_bh欄位是字元型。
條件內包括了多個本表的欄位運算時不能進行索引，如：
ys_df>cx_df，無法進行優化
qc_bh||kh_bh=』5400250000』，優化處理：qc_bh=』5400』 and kh_bh=』250000』
應用oracle的hint（提示）處理
提示處理是在oracle產生的sql分析執行路徑不滿意的情況下要用到的。它可以對sql進行以下方面的提示
目標方面的提示：
cost（按成本優化）
rule（按規則優化）
choose（預設）（oracle自動選擇成本或規則進行優化）
all_rows（所有的行盡快返回）
first_rows（第一行數據盡快返回）
執行方法的提示：
use_nl（使用nested loops方式聯合）
use_merge（使用merge join方式聯合）
use_hash（使用hash join方式聯合）
索引提示：
index（table index）（使用提示的表索引進行查詢）
其它高級提示（如並行處理等等）
oracle的提示功能是比較強的功能，也是比較復雜的應用，並且提示只是給oracle執行的一個建議，有時如果出於成本方面的考慮oracle也可能不會按提示進行。根據實踐應用，一般不建議開發人員應用oracle提示，因為各個資料庫及伺服器性能情況不一樣，很可能一個地方性能提升了，但另一個地方卻下降了，oracle在sql執行分析方面已經比較成熟，如果分析執行的路徑不對首先應在資料庫結構（主要是索引）、伺服器當前性能（共享內存、磁碟文件碎片）、資料庫對象（表、索引）統計信息是否正確這幾方面分析。
❽ 如何利用索引提高SQLServer數據處理的效率
在良好的資料庫設計基礎上，能有效地使用索引是SQL Server取得高性能的基礎，SQL Server採用基於代價的優化模型，它對每一個提交的有關表的查詢，決定是否使用索引或用哪一個索引。因為查詢執行的大部分開銷是磁碟I/O，使用索引提高性能的一個主要目標是避免全表掃描，因為全表掃描需要從磁碟上讀表的每一個數據頁，如果有索引指向數據值，則查詢只需讀幾次磁碟就可以了。
所以如果建立了合理的索引，優化器就能利用索引加速數據的查詢過程。但是，索引並不總是提高系統的性能，在增、刪、改操作中索引的存在會增加一定的工作量，因此，在適當的地方增加適當的索引並從不合理的地方刪除次優的索引，將有助於優化那些性能較差的SQL Server應用。實踐表明，合理的索引設計是建立在對各種查詢的分析和預測上的，只有正確地使索引與程序結合起來,才能產生最佳的優化方案。本文就SQL Server索引的性能問題進行了一些分析和實踐。
一、聚簇索引(clustered indexes)的使用
聚簇索引是一種對磁碟上實際數據重新組織以按指定的一個或多個列的值排序。由於聚簇索引的索引頁面指針指向數據頁面，所以使用聚簇索引查找數據幾乎總是比使用非聚簇索引快。每張表只能建一個聚簇索引，並且建聚簇索引需要至少相當該表120%的附加空間，以存放該表的副本和索引中間頁。建立聚簇索引的思想是：
1、大多數表都應該有聚簇索引或使用分區來降低對表尾頁的競爭，在一個高事務的環境中，對最後一頁的封鎖嚴重影響系統的吞吐量。
2、在聚簇索引下，數據在物理上按順序排在數據頁上，重復值也排在一起，因而在那些包含范圍檢查(between、<、<=、>、>=)或使用group by或order by的查詢時，一旦找到具有范圍中第一個鍵值的行，具有後續索引值的行保證物理上毗連在一起而不必進一步搜索，避免了大范圍掃描，可以大大提高查詢速度。
3、在一個頻繁發生插入操作的表上建立聚簇索引時，不要建在具有單調上升值的列(如IDENTITY)上，否則會經常引起封鎖沖突。
4、在聚簇索引中不要包含經常修改的列，因為碼值修改後，數據行必須移動到新的位置。
5、選擇聚簇索引應基於where子句和連接操作的類型。
聚簇索引的侯選列是：
1、主鍵列,該列在where子句中使用並且插入是隨機的。
2、按范圍存取的列，如pri_order > 100 and pri_order < 200。
3、在group by或order by中使用的列。
4、不經常修改的列。
5、在連接操作中使用的列。
二、非聚簇索引(nonclustered indexes)的使用
SQL Server預設情況下建立的索引是非聚簇索引，由於非聚簇索引不重新組織表中的數據，而是對每一行存儲索引列值並用一個指針指向數據所在的頁面。換句話說非聚簇索引具有在索引結構和數據本身之間的一個額外級。一個表如果沒有聚簇索引時,可有250個非聚簇索引。每個非聚簇索引提供訪問數據的不同排序順序。在建立非聚簇索引時，要權衡索引對查詢速度的加快與降低修改速度之間的利弊。另外，還要考慮這些問題：
1、索引需要使用多少空間。
2、合適的列是否穩定。
3、索引鍵是如何選擇的，掃描效果是否更佳。
4、是否有許多重復值。
對更新頻繁的表來說，表上的非聚簇索引比聚簇索引和根本沒有索引需要更多的額外開銷。對移到新頁的每一行而言，指向該數據的每個非聚簇索引的頁級行也必須更新，有時可能還需要索引頁的分理。從一個頁面刪除數據的進程也會有類似的開銷，另外，刪除進程還必須把數據移到頁面上部，以保證數據的連續性。所以，建立非聚簇索引要非常慎重。非聚簇索引常被用在以下情況：
1、某列常用於集合函數(如Sum,....)。
2、某列常用於join,order by,group by。
3、查尋出的數據不超過表中數據量的20%。
三、覆蓋索引(covering indexes)的使用
覆蓋索引是指那些索引項中包含查尋所需要的全部信息的非聚簇索引，這種索引之所以比較快也正是因為索引頁中包含了查尋所必須的數據,不需去訪問數據頁。如果非聚簇索引中包含結果數據,那麼它的查詢速度將快於聚簇索引。
但是由於覆蓋索引的索引項比較多,要佔用比較大的空間。而且update操作會引起索引值改變。所以如果潛在的覆蓋查詢並不常用或不太關鍵，則覆蓋索引的增加反而會降低性能。
四、索引的選擇技術
p_detail是住房公積金管理系統中記錄個人明細的表，有890000行，觀察在不同索引下的查詢運行效果，測試在C/S環境下進行，客戶機是IBM PII350(內存64M),伺服器是DEC Alpha1000A(內存128M),資料庫為SYBASE11.0.3。
1、 select count(*) from p_detail where
op_date>』19990101』 and op_date<』
19991231』 and pri_surplus1>300
2、 select count(*),sum(pri_surplus1) from p_detail
where op_date>』19990101』 and
pay_month between『199908』 and』199912』
不建任何索引查詢1 1分15秒
查詢2 1分7秒
在op_date上建非聚簇索引查詢1 57秒
查詢2 57秒
在op_date上建聚簇索引查詢1 <1秒
查詢2 52秒
在pay_month、op_date、pri_surplus1上建索引查詢1 34秒
查詢2 <1秒
在op_date、pay_month、pri_surplus1上建索引查詢1 <1秒
查詢2 <1秒
從以上查詢效果分析，索引的有無，建立方式的不同將會導致不同的查詢效果，選擇什麼樣的索引基於用戶對數據的查詢條件,這些條件體現於where從句和join表達式中。一般來說建立索引的思路是：
(1)主鍵時常作為where子句的條件，應在表的主鍵列上建立聚簇索引，尤其當經常用它作為連接的時候。
(2)有大量重復值且經常有范圍查詢和排序、分組發生的列，或者非常頻繁地被訪問的列，可考慮建立聚簇索引。
(3)經常同時存取多列，且每列都含有重復值可考慮建立復合索引來覆蓋一個或一組查詢，並把查詢引用最頻繁的列作為前導列，如果可能盡量使關鍵查詢形成覆蓋查詢。
(4)如果知道索引鍵的所有值都是唯一的，那麼確保把索引定義成唯一索引。
(5)在一個經常做插入操作的表上建索引時，使用fillfactor(填充因子)來減少頁分裂，同時提高並發度降低死鎖的發生。如果在只讀表上建索引，則可以把fillfactor置為100。
(6)在選擇索引鍵時，設法選擇那些採用小數據類型的列作為鍵以使每個索引頁能夠容納盡可能多的索引鍵和指針，通過這種方式，可使一個查詢必須遍歷的索引頁面降到最小。此外，盡可能地使用整數為鍵值，因為它能夠提供比任何數據類型都快的訪問速度。
五、索引的維護
上面講到,某些不合適的索引影響到SQL Server的性能,隨著應用系統的運行,數據不斷地發生變化,當數據變化達到某一個程度時將會影響到索引的使用。這時需要用戶自己來維護索引。索引的維護包括：
1、重建索引
隨著數據行的插入、刪除和數據頁的分裂，有些索引頁可能只包含幾頁數據，另外應用在執行大塊I/O的時候，重建非聚簇索引可以降低分片，維護大塊I/O的效率。重建索引實際上是重新組織B-樹空間。在下面情況下需要重建索引：
(1)數據和使用模式大幅度變化。
(2)排序的順序發生改變。
(3)要進行大量插入操作或已經完成。
(4)使用大塊I/O的查詢的磁碟讀次數比預料的要多。
(5)由於大量數據修改，使得數據頁和索引頁沒有充分使用而導致空間的使用超出估算。
(6)dbcc檢查出索引有問題。
當重建聚簇索引時，這張表的所有非聚簇索引將被重建。
2、索引統計信息的更新
當在一個包含數據的表上創建索引的時候，SQL Server會創建分布數據頁來存放有關索引的兩種統計信息：分布表和密度表。優化器利用這個頁來判斷該索引對某個特定查詢是否有用。但這個統計信息並不動態地重新計算。這意味著，當表的數據改變之後，統計信息有可能是過時的，從而影響優化器追求最有工作的目標。因此，在下面情況下應該運行update statistics命令：
(1)數據行的插入和刪除修改了數據的分布。
(2)對用truncate table刪除數據的表上增加數據行。
(3)修改索引列的值。
六、結束語
實踐表明，不恰當的索引不但於事無補，反而會降低系統的執行性能。因為大量的索引在插入、修改和刪除操作時比沒有索引花費更多的系統時間。例如下面情況下建立的索引是不恰當的：
1、在查詢中很少或從不引用的列不會受益於索引，因為索引很少或從來不必搜索基於這些列的行。
2、只有兩個或三個值的列，如男性和女性(是或否)，從不會從索引中得到好處。
另外，鑒於索引加快了查詢速度，但減慢了數據更新速度的特點。可通過在一個段上建表，而在另一個段上建其非聚簇索引，而這兩段分別在單獨的物理設備上來改善操作性能。
❾ 如何利用sqlserver2014提高資料庫讀寫性能
1.沒有更多的伺服器，而是這個伺服器除了搭配資料庫、集中採集器(就是數據解析、告警、存儲的程序)，還要支持30w點的北向介面(SNMP)，在程序沒有優化之前CPU常年佔用80%以上。因為項目要求要使用雙機熱備，為了省事，減少不必要的麻煩，我們把相關的服務放在一起，以便能夠充分利用HA的特性（外部購買的HA系統)
2.系統數據正確性要求極其變態，要求從底層採集系統到最上層的監控系統，一條數據都不能差
我們的系統架構如下，可以看到，其中資料庫壓力非常之大，尤其在LevelA節點：
3.硬體配置如下：
CPU：英特爾® 至強® 處理器 E5-2609 (4核, 2.40GHz, 10MB, 6.4 GT/s)
內存：4GB (2x2GB) DDR3 RDIMM Memory, 1333MHz,ECC
硬碟：500GB 7200 RPM 3.5'' SATA3 硬碟，Raid5.
4.資料庫版本
採用的是SQLServer2012標准版，HP提供的正版軟體，缺少很多企業版的NB功能。
寫入瓶頸