”这SQL作业一直每天都运行好好的,咋突然就不生效了?”
碰到这种突发问题,我心里是淡定的,事情不可能莫名发生的,因为是SQL作业问题,首先需要查看作业历史记录
果然一个大大的X明显的不要不要的,继续看错误内容:
已以用户 NT AUTHORITY\NETWORK SERVICE 的身份执行。 事务(进程 ID 51)与另一个进程被死锁在 锁 | 通信缓冲区 资源上,并且已被选作死锁牺牲品。请重新运行该事务。 [SQLSTATE 40001] (错误 1205). 该步骤失败。
死锁?,好好的事务咋会死锁了,查看前一天所有员工工作记录,发现没有任何人对这个作业里面的存储过程做过更改,保险起见,还是人工喊了句:“昨天有没人改XXX啊?” “木有哦” “改它有钱拿嘛” “XXX是啥?” 好吧,你们赢了,既然这个PRO(存储过程)没人动,那就是其他的事务挂了干扰了这里面的操作,从而导致死锁了,木办法,死办法了,看存储过程,一打开,不愧是别人写的代码,上千行啊,作为一个好久没看过代码的非主流程序员,压力无限大啊,压制住想吐的心理,查找所有对表发生更改的操作,筛选出可能受影响的表,再找员工工作记录(吐槽下员工工作记录非常重要),果然昨天有人对其中的表做了更改,于是找到对应的人,好吧,事情差不多明了,问题就出在这二货的代码上,对方表现的很无辜,“我测试过啊,代码运行正常,为什么自动执行就出错了,巴拉巴拉...”不吐槽程序员的失误了,继续定位问题:
问题发生情况:
在SQL存储过程中对其他服务器的SQL数据库进行操作,外加个前提:使用了事务
错误信息:
无法执行该操作,因为链接服务器 "xxxxx" 的 OLE DB 访问接口 "SQLNCLI" 无法启动分布式事务
找了下资料,http://www.cnblogs.com/qanholas/archive/2013/05/15/3080013.html 大神们都是这种标答,标答不愧为标答,写的太详细了,考虑了各种情况,但是吐槽啊,内容太多,找到有用的信息好难,我这里对内容进行下筛选,问题基本就是服务器配置问题,解决方案如下,来个有图有真相吧:
步骤一:进入服务器(那个出错的链接服务器),找到控制面板--管理工具--组件服务(知道命令行打开组件服务的就直接打开吧)
步骤二:组件服务--计算机---我的电脑---右键---属性
步骤三:属性窗口:选择MSDTC--安全配置
步骤四:勾上下图那些圈圈,然后确认了(到这一步如果你发现没勾,那么恭喜你,勾上问题就解决了,如果发现已经勾上了,那么sorry,你只能按照上面大神的链接,一个个去排查了,GOOD LUCK!)
确认后,去执行出错的那个PRO,果然,错误没了,再测试下,没问题,注销服务器,收工,问题解决!