我有Execute SQL Script包，其中包含插入大约150K记录的脚本。
这里的问题是当我在虚拟机中执行包时，它需要25分钟左右的物理机器中的相同包装，需要2分钟
问题1？为什么花费这么多时间在VM中加载相同的数据。 问题2？如何解决这个性能问题。
物理机配置有4GB Ram和250GB HD + Windows服务器2008 R2 + SQL Server 2008 R2标准版。 虚拟机具有相同的配置
更新：问题在于VM中的SQL Server。
问题1？为什么花费那么多时间在VM中运行相同的脚本。
问题2？如何解决这个性能问题。
物理机和VM中的batabases架构都是相同的。其他数据库也是一样的。两台机器中的表都没有应用索引。数据类型相同。我说的硬盘具有相同的配置。
两台机器都没有RAID。
物理机具有2.67GHz RAM四核并且在虚拟机中具有 2.00GHz RAM四核
SQL PM的版本：
Microsoft SQL Server 2008 R2（RTM） - 10.50.1600.1（X64）2010年4月2日15:48:46版权所有（c）Windows NT 6.1上的Microsoft Corporation标准版（64位）（Build 7601：Service Pack 1） ）
SQL PM的版本：
Microsoft SQL Server 2008 R2（RTM） - 10.50.1600.1（X64）2010年4月2日15:48:46版权所有（c）Windows NT 6.1上的Microsoft Corporation标准版（64位）（Build 7601：Service Pack 1） ）（管理程序）
我执行了脚本执行计划两者都是相同的，因为计划没有区别。
供应商是HP ML350机器。
在同一台物理服务器上有近20台虚拟机，其中7台服务器处于活动状态。
答案 0 :(得分：1)
这里有一篇关于为VM实现正确设置SQL配置的文章：Best Practices for SQL Server。以下是摘录，但文章包含其他提示和良好的性能测试计划：
存储配置问题是导致SQL性能问题的首要原因。通常会出现这些问题，因为DBA请求VI管理员的虚拟磁盘，VI管理员将VMDK放在可能满足或不满足DBA性能需求的LUN上。例如：
- 虚拟机的VMDK文件放置在没有足够主轴的VMFS卷上。
- 许多VMDK文件放置在单个VMFS卷上，可以使用更多的磁盘轴。
- 放在同一个LUN上的数据库和日志文件，你猜对了，可以使用更多的主轴。
对某些人来说这可能是显而易见的，但这个问题一次又一次地发生。 VI管理员应该了解一些有助于理解和避免此问题的技术项目：
- 根据DB文件的IO要求，确定一定数量 应该保证这个文件的主轴。这意味着它 必须将VMDK放在VMFS卷上以支持SQL Server 要求和该卷的所有其他要求。
- 混合顺序活动（例如日志文件更新）和随机活动 （例如数据库访问）导致随机行为。这意味着 在虚拟前物理环境中的LUN配置 可能不足以满足整合环境。这是 在存储性能：VMFS和协议中讨论了一些内容。
- 当存储不符合SQL Server的要求时，设备延迟 或者内核延迟（排队时间）会增加。阅读这些内容 存储性能分析和监控中的计数器。
答案 1 :(得分：0)
此问题的最常见原因是缺少RAM。在一台小型4GB RAM机器上安装所有设备是你的问题。
当您尝试将这些150k行加载到内存中时（请记住，SSIS中发生的所有内容都在内存中），页面文件正在处理很多行。
虚拟机上的页面文件比物理机上的页面文件慢很多。
要解决此问题，请增加虚拟机上的RAM量。
答案 2 :(得分：0)
我有类似的问题。
两台客户机（一台物理机，一台虚拟机）使用SQLCMD执行批处理。此批处理在物理服务器上调用存储过程（因此，这不是内存问题，因为详细说明仅在服务器端）。
从物理机执行的批处理需要20分钟。从虚拟机执行的批处理需要1小时20分钟。
使用SQL分析器我注意到在执行缓慢的情况下，有一个等待类型ASYNC_NETWORK_IO。
虚拟化网络层可能未经过优化。
您是否可以运行SQL事件探查器并检查是否看到等待类型ASYNC_NETWORK_IO？