实验:SQL Server和VMware这对冤家或致命

译文
运维 服务器运维 虚拟化
在本次试验中,我们使用WMPlayer 2.0.2.作为访客系统,使用Vista惠普作为主机系统。这个问题很有可能不影响ESX服务器,但是我们仍在等待VMware方面给予确认:ESX服务器完全尊重微软SQL Server在输入/输出方面的核心需求。

在本次试验中,我们使用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一起运行带来的优点压倒伴随的潜在风险吗?
 

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

责任编辑:张玉 来源: 51CTO
相关推荐

2010-11-08 14:45:44

SQL Server连

2018-12-24 18:12:41

SQL ServerMySQL数据库

2015-08-21 10:40:10

SQL Server备份还原

2011-07-06 08:58:56

2022-02-09 10:07:03

LinuxSQL Server

2010-10-22 10:59:43

SQL Server的

2009-05-22 16:42:02

MS SQLMySQL转换

2012-05-16 11:35:16

SQL Server拒绝访问

2018-08-16 10:18:21

公有云用户云厂商

2009-10-12 14:29:10

VMware Serv

2011-08-16 11:13:05

SQL ServerSQL语句前n条订单

2009-10-12 14:54:41

VMware Serv

2010-11-11 09:20:46

SQL Server创

2010-10-15 13:49:34

mysql和sql s

2009-08-18 10:48:33

2010-07-08 11:05:14

SQL Server数

2017-10-10 15:04:16

SQL数据库计算机

2011-03-31 09:30:27

SQL Server数管理SQL

2009-09-07 08:10:56

VMware Work

2010-11-10 14:47:11

SQL Server创
点赞
收藏

51CTO技术栈公众号