在本次試驗(yàn)中，我們使用WMPlayer 2.0.2.作為訪客系統(tǒng)，使用Vista惠普作為主機(jī)系統(tǒng)。這個(gè)問題很有可能不影響ESX服務(wù)器，但是我們?nèi)栽诘却齎Mware方面給予確認(rèn)：ESX服務(wù)器完全尊重微軟SQL Server在輸入/輸出方面的核心需求。

現(xiàn)在虛擬機(jī)變得越來越流行。它們常常用于在物理機(jī)上創(chuàng)建“安全沙箱”。管理員們可能會(huì)往這些虛擬機(jī)里面裝入一些程序，偶爾會(huì)裝入SQL Server。遺憾的是，將SQL Server裝入到虛擬機(jī)里面可能會(huì)帶來災(zāi)難！

我們不妨短暫回顧一下30年前的數(shù)據(jù)庫狀況。所有數(shù)據(jù)庫在擁有存儲(chǔ)過程、分區(qū)視圖、XML及如今的所有其他附加功能之前，它們的一項(xiàng)關(guān)鍵特性是什么？自一開始，所有數(shù)據(jù)庫（MySQL等“玩具”數(shù)據(jù)庫除外）都包括某種類型的預(yù)寫式日志機(jī)制，以確保數(shù)據(jù)完整性。MS SQL中的LDF日志，甲骨文數(shù)據(jù)庫中的Undo（撤消）日志和redo（重做）日志，它們都確保了執(zhí)行COMMIT（提交）語句后，保證數(shù)據(jù)保存起來。

為了在Windows上實(shí)現(xiàn)這一機(jī)制，SQL Server為輸入輸出操作標(biāo)上了WRITETHRU和NOBUFFERING這兩個(gè)標(biāo)記。SQL Server讀取時(shí)，它使用自己的高速緩存來讀取數(shù)據(jù)，而不使用操作系統(tǒng)的高速緩存。SQL Server寫入時(shí)，它要求操作系統(tǒng)等到該操作完成。請注意：SQL Server將一切置于其掌控之下，根本不使用操作系統(tǒng)的高速緩存。這是SQL Server與其他應(yīng)用程序之間的一個(gè)關(guān)鍵區(qū)別（見圖1）。

 
圖1

從主機(jī)系統(tǒng)的角度來看，當(dāng)SQL Server在虛擬機(jī)里面運(yùn)行時(shí)，會(huì)發(fā)生什么情況呢？主機(jī)系統(tǒng)并不知道“安全沙箱”里面的內(nèi)容。至于里面運(yùn)行的是Windows、Linux還是另一款操作系統(tǒng)，主機(jī)系統(tǒng)一無所知。這就使得它完全不知道虛擬機(jī)里面的操作系統(tǒng)標(biāo)記。因此，當(dāng)虛擬機(jī)“請求”主機(jī)系統(tǒng)寫入數(shù)據(jù)時(shí)，滿足該請求的方式與普通的非SQL Server應(yīng)用程序完全一樣。寫入操作非同步完成，使用高速緩存（同樣見圖1）。

這個(gè)區(qū)別會(huì)帶來幾個(gè)影響，既有好的影響，也有壞的影響。先來說說好的影響，性能監(jiān)視器（Perfmon）工具的數(shù)據(jù)顯示，VMWare下的SQL Server運(yùn)行起來常常速度更快（見圖2）！
 

 
圖2

考慮到性能監(jiān)視器工具只是每秒更新一次圖表，只好人為減慢輸入輸出系統(tǒng)的速度，才能觀察到其影響。如圖所示，寫入操作在虛擬機(jī)上完成后（以垂直的綠線為分界點(diǎn)），物理機(jī)上仍然有寫入操作。

這帶來了不好的影響。請注意：COMMIT（提交）語句在虛擬機(jī)上執(zhí)行時(shí)，數(shù)據(jù)并沒有送到輸入輸出系統(tǒng)。數(shù)據(jù)僅僅發(fā)送到了物理機(jī)。遺憾的是，SQL Server與VMWare一起運(yùn)行時(shí)，停電等干擾因素會(huì)導(dǎo)致你丟失報(bào)告為“已提交”的事務(wù)數(shù)據(jù)。更為糟糕的是，萬一出現(xiàn)這種干擾因素，高速緩存就會(huì)改變寫入順序，導(dǎo)致數(shù)據(jù)庫被損壞！

#p# 我們搭建了一個(gè)試驗(yàn)環(huán)境，表明SQL Server在VMWare平臺(tái)下運(yùn)行時(shí)，停電會(huì)給數(shù)據(jù)完整性帶來什么樣的影響。我們在物理機(jī)和虛擬機(jī)上建立了SQL Server 2005的兩個(gè)實(shí)例，分別稱之為 ZOOSTATION和VZOO。每個(gè)服務(wù)器實(shí)例都有專門為本次試驗(yàn)創(chuàng)建的VMTest數(shù)據(jù)庫。虛擬服務(wù)器使用Linked服務(wù)器與物理服務(wù)器連接起來。兩個(gè)VMTest數(shù)據(jù)庫都含有同樣的數(shù)據(jù)表：demotable（每個(gè)數(shù)據(jù)表都有81832行），里面的數(shù)據(jù)一模一樣。

為了測試停電后虛擬機(jī)數(shù)據(jù)庫的完整性，我們執(zhí)行了如下操作：在同樣的分布式事務(wù)中，在物理數(shù)據(jù)庫和虛擬數(shù)據(jù)庫上執(zhí)行了同樣的UPDATE（更新）語句。這一更新操作把“2_”添加到了demotable表中每一行的開頭。

 執(zhí)行提交語句后，

 立即移除數(shù)據(jù)/日志所在的外部驅(qū)動(dòng)器，模擬操作系統(tǒng)崩潰。模擬了操作系統(tǒng)崩潰后，我們重新開啟兩個(gè)SQL服務(wù)器。在物理機(jī)上，一切都正常，數(shù)據(jù)也按預(yù)期的那樣更新。遺憾的是，在虛擬機(jī)上，我們看到了好多錯(cuò)誤。

VMTest數(shù)據(jù)庫狀態(tài)為“In Recovery”（恢復(fù)中），如我的SQL Server Management Studio所示。

我們將VMTest數(shù)據(jù)庫的狀態(tài)設(shè)為“Emergency”（緊急狀態(tài)），以讀取里面的數(shù)據(jù)。

這樣一來，數(shù)據(jù)庫可以訪問（但只能讀?。Ｎ覀冊噲D使用SQL Server Management Studio的Open Table（打開表）命令，從demotable讀取實(shí)際的數(shù)據(jù)。我們看到下列結(jié)果： 

SQL Management Studio只能讀取demotable里面原始的81832行中的3965行。一些數(shù)據(jù)丟失了。我們發(fā)現(xiàn)，許多TextData值是以“1_”開頭，而不是像上一次事務(wù)表示的那樣以“2_”開頭。

手動(dòng)執(zhí)行SELECT（選擇）語句出現(xiàn)了另一個(gè)錯(cuò)誤。

***的結(jié)論是，要認(rèn)識(shí)到SQL Server在VMWare下無法運(yùn)行，這點(diǎn)很重要。雖然有時(shí)SQL Server似乎會(huì)運(yùn)行，但是會(huì)導(dǎo)致數(shù)據(jù)庫不穩(wěn)定。我們將整個(gè)試驗(yàn)重復(fù)了無數(shù)次，每一次物理機(jī)上的數(shù)據(jù)庫都毫發(fā)未損，可是虛擬機(jī)上的數(shù)據(jù)庫被損壞。沒有警告，沒有危險(xiǎn)信號(hào)，也沒有警報(bào)。到時(shí)擺在你面前的可能就是被損壞的數(shù)據(jù)庫。
所以現(xiàn)在該由你自己來決定：捫心自問，讓SQL Server與VMWare一起運(yùn)行帶來的優(yōu)點(diǎn)壓倒伴隨的潛在風(fēng)險(xiǎn)嗎？
 

原文地址：http://www.sqlsolutions.com/articles/articles/SQL_Server_and_VMware-A_Potentially_Fatal_Combination.htm