三、 大数据量操作的时候发生的切换
1、对表进行大量插入，执行1千万遍，如下语句
insert into aa
select * from sys.sysprocesses
go 10000000
2、在执行以上大量插入过程中，进行故障转移
ALTER AVAILABILITY GROUP alwayson01 FAILOVER
3、转移时间30秒，下图为转移过程恢复alwayson01数据库的日志记录；在恢复过程中发现有大量redo操作，需要等待日志写入到新副本，才能切换。由此可见如果大数据量操作时候发生切换，由于要实现同步，切换将会很缓慢。
测试总结
切换过程会先停止原主副本的操作，新主副本实现同步；若存在大事务则需要大量io和cpu重做事务，因此切换会存在延迟或者失败。
四、 手动切换后如何实现用户权限同步
1、 在CLUSTEST03\CLUSTEST03新建用户uws_test，具有alwaysOn01的读写权限。
2、 切换后，客户端需要继续使用uws_test连接
数据库，必须要求SERVER03也存在uws_test用户，并同时存在读写权限。需要新建与CLUSTEST03\CLUSTEST03相同sid的uws_test用户，由于当前SERVER03的副本不可使用，因此不能赋予其他权限。
-- Login: uws_test
CREATE LOGIN [uws_test]
WITH PASSWORD = 0x0200C660EBCDC35F583546868ADFF2DC0D7213C30E373825E4E6781C024122E646A86355D040FDB12AAC523499FCEE799BB4F78DA47131E40DB33180434EA80C9873F0B19A9E HASHED,
SID = 0xE4382508B889704E8291DBF759B5BDA8, DEFAULT_DATABASE = [master], CHECK_POLICY = OFF, CHECK_EXPIRATION = OFF
3、 执行切换语句后，查看SERVER03上uws_test用户权限是否已经同步。
ALTER AVAILABILITY GROUP alwayson01 FAILOVER
测试总结
1、 只有在备机新建相同sid的用户才能实现权限同步。
2、 若只是新建相同名字的用户，则会导致切换后，数据库存在孤立用户，相同名字的用户也不会有权限。
五、 主\辅助副本自动备份切换实现测试
1、 利用一下语句，确认首选备份
if ( sys.fn_hadr_backup_is_preferred_replica('alwayson01'))=1
begin
print '开始备份'
print '结束备份'
end
else
print '不备份'
2、 当前实例在SERVER03上，目前是以首选辅助副本未备份。
因此会有以下三种情况
情况一：在SERVER03不能执行备份，应该在CLUSTEST03\CLUSTEST03上执行
2.1 在SERVER03上不能执行备份，如下图所示
2.2 在CLUSTEST03\CLUSTEST03上能执行备份，如下图所示
情况二：CLUSTEST03\CLUSTEST03挂机，可在主副本SERVER03上备份
2.3 将CLUSTEST03\CLUSTEST03脱机，如下所示界面
2.4 可在SERVER03上执行备份
情况三：主备发生切换，可在SERVER03备份，不能在CLUSTEST03\CLUSTEST03上备份
2.5 将主副本切换到CLUSTEST03\CLUSTEST03
2.6 可在SERVER03【新辅助副本】上备份
2.7 不可在CLUSTEST03\CLUSTEST03【新主副本】上备份
相关文章：
AlwaysOn可用性组功能测试(1)-故障转移测试
AlwaysOn可用性组功能测试(2)-SQL Server群集故障转移
最新内容请见作者的GitHub页：http://qaseven.github.io/
