實驗：SQL Server和VMware這對冤家或致命
譯文在本次試驗中，我們使用WMPlayer 2.0.2.作為訪客系統，使用Vista惠普作為主機系統。這個問題很有可能不影響ESX服務器，但是我們仍在等待VMware方面給予確認：ESX服務器完全尊重微軟SQL Server在輸入/輸出方面的核心需求。
現在虛擬機變得越來越流行。它們常常用于在物理機上創建“安全沙箱”。管理員們可能會往這些虛擬機里面裝入一些程序，偶爾會裝入SQL Server。遺憾的是，將SQL Server裝入到虛擬機里面可能會帶來災難！
我們不妨短暫回顧一下30年前的數據庫狀況。所有數據庫在擁有存儲過程、分區視圖、XML及如今的所有其他附加功能之前，它們的一項關鍵特性是什么？自一開始，所有數據庫（MySQL等“玩具”數據庫除外）都包括某種類型的預寫式日志機制，以確保數據完整性。MS SQL中的LDF日志，甲骨文數據庫中的Undo（撤消）日志和redo（重做）日志，它們都確保了執行COMMIT（提交）語句后，保證數據保存起來。
為了在Windows上實現這一機制，SQL Server為輸入輸出操作標上了WRITETHRU和NOBUFFERING這兩個標記。SQL Server讀取時，它使用自己的高速緩存來讀取數據，而不使用操作系統的高速緩存。SQL Server寫入時，它要求操作系統等到該操作完成。請注意：SQL Server將一切置于其掌控之下，根本不使用操作系統的高速緩存。這是SQL Server與其他應用程序之間的一個關鍵區別（見圖1）。
圖1
從主機系統的角度來看，當SQL Server在虛擬機里面運行時，會發生什么情況呢？主機系統并不知道“安全沙箱”里面的內容。至于里面運行的是Windows、Linux還是另一款操作系統，主機系統一無所知。這就使得它完全不知道虛擬機里面的操作系統標記。因此，當虛擬機“請求”主機系統寫入數據時，滿足該請求的方式與普通的非SQL Server應用程序完全一樣。寫入操作非同步完成，使用高速緩存（同樣見圖1）。
這個區別會帶來幾個影響，既有好的影響，也有壞的影響。先來說說好的影響，性能監視器（Perfmon）工具的數據顯示，VMWare下的SQL Server運行起來常常速度更快（見圖2）！
圖2
考慮到性能監視器工具只是每秒更新一次圖表，只好人為減慢輸入輸出系統的速度，才能觀察到其影響。如圖所示，寫入操作在虛擬機上完成后（以垂直的綠線為分界點），物理機上仍然有寫入操作。
這帶來了不好的影響。請注意：COMMIT（提交）語句在虛擬機上執行時，數據并沒有送到輸入輸出系統。數據僅僅發送到了物理機。遺憾的是，SQL Server與VMWare一起運行時，停電等干擾因素會導致你丟失報告為“已提交”的事務數據。更為糟糕的是，萬一出現這種干擾因素，高速緩存就會改變寫入順序，導致數據庫被損壞！
#p# 我們搭建了一個試驗環境，表明SQL Server在VMWare平臺下運行時，停電會給數據完整性帶來什么樣的影響。我們在物理機和虛擬機上建立了SQL Server 2005的兩個實例，分別稱之為 ZOOSTATION和VZOO。每個服務器實例都有專門為本次試驗創建的VMTest數據庫。虛擬服務器使用Linked服務器與物理服務器連接起來。兩個VMTest數據庫都含有同樣的數據表：demotable（每個數據表都有81832行），里面的數據一模一樣。
為了測試停電后虛擬機數據庫的完整性，我們執行了如下操作：在同樣的分布式事務中，在物理數據庫和虛擬數據庫上執行了同樣的UPDATE（更新）語句。這一更新操作把“2_”添加到了demotable表中每一行的開頭。
執行提交語句后，
立即移除數據/日志所在的外部驅動器，模擬操作系統崩潰。模擬了操作系統崩潰后，我們重新開啟兩個SQL服務器。在物理機上，一切都正常，數據也按預期的那樣更新。遺憾的是，在虛擬機上，我們看到了好多錯誤。
VMTest數據庫狀態為“In Recovery”（恢復中），如我的SQL Server Management Studio所示。
我們將VMTest數據庫的狀態設為“Emergency”（緊急狀態），以讀取里面的數據。
這樣一來，數據庫可以訪問（但只能讀取）。我們試圖使用SQL Server Management Studio的Open Table（打開表）命令，從demotable讀取實際的數據。我們看到下列結果：
SQL Management Studio只能讀取demotable里面原始的81832行中的3965行。一些數據丟失了。我們發現，許多TextData值是以“1_”開頭，而不是像上一次事務表示的那樣以“2_”開頭。
手動執行SELECT（選擇）語句出現了另一個錯誤。
***的結論是，要認識到SQL Server在VMWare下無法運行，這點很重要。雖然有時SQL Server似乎會運行，但是會導致數據庫不穩定。我們將整個試驗重復了無數次，每一次物理機上的數據庫都毫發未損，可是虛擬機上的數據庫被損壞。沒有警告，沒有危險信號，也沒有警報。到時擺在你面前的可能就是被損壞的數據庫。
所以現在該由你自己來決定：捫心自問，讓SQL Server與VMWare一起運行帶來的優點壓倒伴隨的潛在風險嗎？
