我正在调试对 SSMS (2012) 中存储过程的调用。经常和代码中的各种随机点，弹出一个对话框：
Microsoft SQL Server Management Studio:
Unable to Step. Invalid Operation.
一旦我关闭对话框，调试似乎可以继续......我可以继续执行代码直到最后，没有任何明显的问题。迄今为止....
在这个 SF question 中，我询问了如何确定服务器正在与哪个 DC 对话。我们正在进行一些弹性测试，需要向客户证明，如果 DC 出现故障，还有其他 DC 可以承受压力。
使用nltest，我可以在任何给定时间确定我正在与哪个 DC 交谈。但是如果我们当前的 DC 失败了，我们如何强制服务器重新评估它可以与哪些其他 DC 通信，然后连接到一个...这样“nltest”将反映新的 DC？
理想情况下，我喜欢可以在同一个 Windows 会话中运行的某种操作，但到目前为止我们已注销并重新登录。我对登录/注销的担忧是缓存的凭据可能会使图片复杂化。
简而言之，如果发生 DC 故障，将服务器连接到辅助 DC 的最简单/最快/最安全的方法是什么？
……至少我是这么认为的。
我最近修改了我的开发服务器上的备份程序。我为用户数据库创建了一个维护计划，该计划在全天的关键点执行一些每周清理任务、每日完整备份和事务日志备份。
直到今天，一切都运行良好，当时收到一封电子邮件，通知我午餐时间备份失败。日志查看器没有透露太多信息，除了在日志条目结束之前成功备份了一定数量的数据库：
[snipped] Source: ... The package execution fa... The step failed.
不完全暴露
我突然想到，与以前的尝试相比，唯一的变化是我今天早上创建了一个新的（小而不起眼的）数据库。
我重新启动了 SQL Server 代理，并尝试手动重新运行（事务日志备份）步骤，但它再次失败。
但是，运行完整备份步骤（从而为我的新数据库创建第一个完整备份）有效 - 此外，再次重新运行事务日志备份步骤也有效。
由于缺少完整备份或以前的事务日志备份，事务日志备份似乎很困难。
这是预期的行为吗？一方面，在原始级别上，这种情况是有道理的，但实际上，我希望它能够更优雅地处理这种情况。
如果是这样，有没有办法自动处理这个问题？这种情况不会经常发生，但我不能指望在创建数据库时记得备份它，尤其是因为它仅处于开发的早期阶段。
如果不是，这种行为的可能原因是什么？我可以避免吗？