先感谢一下我的同事们最先发现此 问题 ，鸣谢：向飞、志刚、海云 最近在生产环境发现一个诡异的 问题 ； 环境：WINDOWS 2012+SQLSERVER 2012 SP1，双节点的故障转移群集+单节点的SQLSERVER 2012 SP1实例（镜像） 生产数据库是从SQLSERVER 2008R2迁移到2012的
先感谢一下我的同事们最先发现此问题，鸣谢：向飞、志刚、海云
最近在生产环境发现一个诡异的问题；
环境：WINDOWS 2012+SQLSERVER 2012 SP1，双节点的故障转移群集+单节点的SQLSERVER 2012 SP1实例（镜像）
生产数据库是从SQLSERVER 2008R2迁移到2012的，迁移过程很顺利，按照一般经验，可能导致数据库所有者丢失，因此在迁移后手动修改数据库所有者为sa，与此同时还有个job在做这个库的归档（定期清理历史数据到本地的历史库中，delete、insert操作）；
迁移后尝试运行job均可正常执行；第二天以镜像方式做灾备，搭建完镜像环境后，归档的job报错：无法登录到服务器“(local)”。
后测试尝试重建作业也无效，再创建一个新作业，只在这个做了镜像的库上执行“select 1”，同样报错（按理说select 1是不会记录日志的，因此也就不会影响到镜像）
最后通过查询代理错误日志，发现如下错误：
确实，MultiSubnetFailover参数必须要开启AlwaysOn属性后才能使用。但为何在只建立镜像的环境下，SQL Agent仍会通过这个连接选项连接到镜像实例？
此外，我又做了两个测试：
测试A：在开启过AlwaysOn选项的单实例（非群集环境）上，先关闭AlwaysOn选项，删除并重建端点，搭建镜像环境；
测试B：在从未开启过AlwaysOn选项的单实例（非群集环境）上（新装的虚机），搭建镜像环境；
上述两次测试，JOB均可顺利执行，并未出现此前在群集环境下的问题；
由此，基本可以排除此问题受AlwaysOn选项的影响的可能，反而是对群集环境才有此类的现象；
目前的群集环境不便开启AlwaysOn选项，因此无法做进一步测试来验证上面的观点，有兴趣的童鞋可以继续测试一下；
PS：经过陈桑的提点，这个问题可以曲线解决；
创建job步骤的时候，连接数据库选为非镜像库（如master），同时修改要执行的SQL，将对象名改为database.schema.object的格式即可；
