为了备份一张大表（使用SELECT .. INTO ..），我在一台有 4 个 CPU 和 16 GB RAM 的机器上花了将近 4 个小时。操作期间没有外部应用程序/进程访问该表。
表大小为 220 GB，SELECT .. INTO是一个简单的（即SELECT * INTO BACKUP_TABLE FROM ORIGINAL_TABLE）
这是一个测试环境，基于此，我需要估算生产环境中相同操作的执行时间。生产环境有 40 个 CPU 和 64 个 RAM。
CPU 相同，两个系统的 I/O 系统相同。（即磁盘类型和磁盘布局相同）。
考虑到生产服务器的处理能力提高 10 倍，估计生产的 SELECT .. INTO .. 将在不到一个小时内完成是否现实？
如果无法根据上述情况回答这个问题，我是否应该重新运行测试并收集一些指标？如果是，这些指标应该是什么？
在此先感谢您提供您对此的想法！
在 SQL Server 2008 R2 上，
SELECT...INTO查询不符合并行性（这是在 SQL Server 2014 中引入的）。因此，不幸的是，生产中增加的 CPU 数量不会帮助您的整体运行时间。您可以使用预先创建的 重新运行测试
BACKUP_TABLE，然后用于INSERT INTO...SELECT查看并行性如何影响测试。无论并行度如何，由于您要复制 220 GB 的表，因此您的主要瓶颈可能是磁盘速度。专门将所有这些写入事务日志。我会检查以确保您不会遇到文件增长事件（将生产日志文件预先增长到测试实例的大小）。
我会再次运行你的测试并测量等待统计数据，看看你有多少
WRITELOG等待。您可以为此使用 Paul Randal 的脚本：捕获一段时间的等待统计信息
在插入运行时多次运行此操作，例如 30、60 或 90 秒的时间间隔，以了解瓶颈所在的位置。
您提到您的测试是在没有针对此表的其他并发活动的系统上运行的。可能影响您的测试的另一件事是
SELECT INTO查询是否被其他进程阻止。