镜像是sql server高可用性方案的一种。配置比较简单，但是有多种模式。如果镜像出现异常，在不同模式下的表现形式也是各异的。这里，我们演练在不同模式下，出现异常后，可能的效果，这样能帮助我们选择合适的模式，以及了解在对数据库镜像做维护期间，需要注意的地方。
【数据库镜像的模式】
数据库镜像主要有这么几种模式:
· high performance模式 （也就是异步模式）
数据库在principle的事务，不需要得到mirror的确认，可以直接完成。principle数据库性能会比较好。但是mirror跟principle之间事务传递可能延迟。
· high safety 模式 （也就是同步模式）没有 witness服务器
数据库在principle的事务，需要马上得到mirror的确认，才能完成。这种情况下，mirror和principle的数据是同步的。但是因为所有的事务需要mirror的确认，所以性能可能会有所影响。
· high satefy模式 （也就是同步模式）有 witness服务器
如果带有witness，那么一旦principle数据库有异常，无法连通，则在witness服务器的见证下，会做自动切换。镜像数据库会变成主数据库，以继续提供服务。
【high performance模式下，出现异常】
· mirror数据库有问题，这时候principle数据库会处于 (principle, disconnected) 状态。在这种情况下，principle数据库依旧能正常服务。当mirror数据库恢复正常后，数据会自动进行同步，同步后，principle服务器会恢复到 (principle, synchronized) 正常状态。这种情况虽然不会对服务造成问题，但是我们应该尽快恢复mirror数据库，否则，在principle端，日志会累积，变得越来越大。会占满磁盘空间。
· principle数据库有问题，无法连接，这时候应用当然不能使用。mirror数据库处于 (mirror, disconnected/in recovery) 状态。这时候我们有两种选择，1. 尽快恢复principle数据库运营。2. 使用forcing service方法把mirror数据库改为主数据库以继续服务。对于forcing service方法，我们要注意:
1. 完全停掉旧的principle 数据库，以避免出现两边同时做数据更新。
2. 在mirror服务器上，我们用下面命令把mirror数据库改为主数据库:
alter database set partner force_service_allow_data_loss
3. 使用forcing service会导致数据有丢失的可能。如果在原先的主数据库数据还没来得及传送到镜像数据库, 那么该部分数据会被丢失。所以使用forcing service我们需要权衡。
4. 原先的主数据库起来后，mirror会处于暂停状态，我们可以恢复镜像，把原来的主数据库为新的镜像数据库 (当然，会导致部分数据永久丢失) 。或者把原先的主数据库去除镜像设置，改为普通数据库，查看在原主数据库上写入而在原镜像数据库上没有写入的记录，然后手工倒入到新的主数据库上。用这种办法倒数据，我们需要对应用非常熟悉。
【high satefy模式没有witness，出现异常】
· mirror数据库有问题，无法连接，principle数据库会处于 (principle, disconnected) 状态。在这种情况下，principle数据库依旧能正常服务。当mirror服务器恢复正常后，数据会自动进行同步，同步后，principle数据库会处于 (principle, synchronized) 正常状态。这种情况虽然不会对服务造成问题，但是我们应该尽快恢复mirror数据库，否则，在principle数据库上，日志会累积，变得越来越大。最后可能导致磁盘满。
· principle服务器有问题，这时候应用当然不能使用。mirror数据库处于 (mirror, disconnected/in recovery) 状态。这时候我们有两种选择，1. 尽快恢复principle数据库。2. 使用forcing service方法把mirror数据库改为principle以继续服务。