”这SQL作业一直每天都运行好好的，咋突然就不生效了？”
碰到这种突发问题，我心里是淡定的，事情不可能莫名发生的，因为是SQL作业问题，首先需要查看作业历史记录
果然一个大大的X明显的不要不要的，继续看错误内容：
已以用户 NT AUTHORITYNETWORK 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，果然，错误没了，再测试下，没问题，注销服务器，收工，问题解决！
[ps：后续又因为服务器配置变更导致问题：无法启动链接服务器 "MOSSDB" 的 OLE DB 访问接口 "SQLNCLI10" 的嵌套事务。由于 XACT_ABORT 选项已设置为 OFF，因此必须使用嵌套事务，需要重启服务，原因是嵌套的存储过程在事务执行的过程中有人进行了变更，导致死锁]
综上，事务调用事务风险还是大了