将数据迁移到同一文件组中的其他文件对空文件的性能影响
我们有一个数据库当前位于 15000 RPM 驱动器上，它只是一个日志数据库，我们希望将其移动到 10000 RPM 驱动器上。 虽然我们可以轻松地分离数据库、移动文件并重新附加，但这会导致我们试图避免的轻微中断。
因此，我们正在考虑将DBCC ShrinkFile 与EMPTYFILE 结合使用。 我们将在 10000 RPM 驱动器上创建一个比 15000 RPM 驱动器上现有文件稍大的数据和事务文件，然后执行 DBCC ShrinkFile with EMPTYFILE 来迁移数据。
这会产生什么样的影响？
We have a database currently sitting on 15000 RPM drives that is simply a logging database and we want to move it to 10000 RPM drives. While we can easily detach the database, move the files and reattach, that would cause a minor outage that we're trying to avoid.
So we're considering using DBCC ShrinkFile with EMPTYFILE. We'll create a data and a transaction file on the 10000 RPM drive slightly larger than the existing files on the 15000 RPM drive and then execute the DBCC ShrinkFile with EMPTYFILE to migrate the data.
What kind of impact will that have?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我已经尝试过这个并且运气好坏参半。 我遇到过文件无法清空的情况，因为它是主文件组中的主文件，但我也遇到过它工作完全正常的情况。
不过，它在工作时确实在数据库中持有巨大的锁。 如果您尝试在运行最终用户查询的实时生产系统上执行此操作，请忘记它。 他们会遇到问题，因为这需要一段时间。
I've tried this and had mixed luck. I've had instances where the file couldn't be emptied because it was the primary file in the primary filegroup, but I've also had instances where it's worked completely fine.
It does hold huge locks in the database while it's working, though. If you're trying to do it on a live production system that's got end user queries running, forget it. They're going to have problems because it'll take a while.
为什么不使用日志传送。 在 10.000 rpm 磁盘上创建新数据库。 设置从 15K RPM 的数据库到 10k RPM 的数据库的日志传送。 当两个数据库不同步时，停止日志传送并切换到 15K RPM 的数据库。
Why not using log shipping. Create new database on 10.000 rpm disks. Setup log shipping from db on 15K RPM to DB on 10k RPM. When both DB's are insync stop log shipping and switch to the database on 15K RPM.
这是连接到 SAN 的系统，还是直连存储？ 如果它是 SAN，则将 SAN 端迁移到新的 raid 组，服务器将永远不会知道发生了更改。
Is this a system connected to a SAN, or is it direct attached storage? If its a SAN do a SAN side migration to the new raid group and the server won't ever know there was a change.