SQL Server数据库镜像是对于数据库可用性的软件解决方案。镜像在每个数据库级别被部署，并只能在完整恢复模式下工作。由于磁盘空间的问题，需要移动镜像数据库到一个不同的位置。我们想不停机、不破坏镜像来完成这个任务。需要在不同的环境做测试。
对于启用了数据库镜像的数据库的文件移动，我们只有有限的选择。常规方法如下：
技术上来讲，这是可行的，但是它需要停机时间，并且尤其对于大数据库，移动和恢复需要大量额外时间。
给定的停机时间是客户端总是会考虑的，我们得找到一个不停机的方案。以下步骤说明了如何不停机移动数据库文件而不用打扰同步数据库镜像。
对于镜像实例：
-
在主服务器上暂停镜像（可选）。
-
在镜像服务器上使用Alter database语句来指向一个新位置。
-
停止镜像SQL Server服务。
-
移动镜像数据库文件到一个新位置，并确保文件上的权限也还在。
-
启动镜像SQL Server服务。
-
在主服务器数据库上恢复镜像，并验证镜像成功恢复。
对于主实例：
-
故障转移数据库到镜像服务器，以至于镜像服务器现在作为主服务器。
-
在新的主服务器上暂停镜像（可选）。
-
在新的镜像服务器上使用Alter database语句来指向一个新位置。
-
停止新镜像的SQL Server服务。
-
移动新的镜像数据库文件到一个新位置，并确保文件上的权限也还在。
-
启动新镜像的SQL Server服务。
-
在主服务器数据库上恢复镜像，并验证镜像成功恢复。
如果详细查看以上计划，可以看到应用程序会话在镜像数据库故障转移期间会重连。当应用程序负载在主服务器上运行时，停止镜像SQL Server服务，物理移动数据库文件，然后启动镜像SQL Server服务。所以无需停机时间。
然而，你要确保在主服务器上有足够的日志空间，因为镜像状态将会被断开（不只是一个库，而是实例上所有镜像的数据库）。当镜像状态断开时，日志记录不会从主服务器发送到镜像服务器，将会累积在主服务器。一旦镜像实例启动，镜像状态变为同步中，主服务器将会开始发送日志记录到镜像服务器。
我们可以通过以下T-SQL来检查所有镜像数据库的文件位置，来验证是否修改成功：
Select DB_NAME(dbid),name,filename
from sysaltfiles
where DB_NAME(dbid) in (Select DB_NAME(database_id)
from sys.database_mirroring where mirroring_state is not null)
order by 1
总的来讲，当移动数据库时可以保持数据库镜像不用停机。对于见证服务器无需任何操作，在活动期间一直保持在线状态。首先这个方案应该在测试环境验证后，再在生产环境实施。非常重要的是，我们注意到在异步镜像模式，也可以参照这种做法，只是需要在应用停机的情况下来实施。
在以下应用场景下会移动镜像数据库的数据或日志文件的位置：
-
磁盘空间不足
数据库服务器上，配置了镜像的数据库所在磁盘空间不足，可以迁移MDF或LDF文件到新的磁盘。
-
加速镜像数据库追上主库
在主库从宕机中恢复后，成为了新主库的镜像数据库，为了加速镜像数据库追上主库，可以将数据和日志文件移动到性能更优的磁盘，如SSD上。
