SQLServer 2012异常问题(一)--故障转移群集+镜像环境导致作业执行失败

原文:SQLServer 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的格式即可;

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。