生产安全SQL存储过程调试

Question

我们有大量的嵌套SQL存储过程，以及许多不同的调试方法(因开发人员而异)。

迄今为止，我们的方法包括：

1. 一个可选的@debug参数，它会在运行时将过程传递给print消息(将变量向下传递给被调用的过程)。
2. 根据测试服务器名称表检查@@servername，并按上述方式检查print
3. 将过程所做的一切写入日志表(在生产和测试中)

其中哪一个更可取(为什么)，还是我们忽略了一个更好的方法？

Answer 1

您还应该考虑Server事件探查器。在中，选择Tools -> Server事件探查器。当分析器窗口打开时，选择“文件->新跟踪”。(我不知道其他RDBMS的具体情况，但它们必须拥有具有类似功能的工具。)

作为长期解决方案，您当然应该将业务逻辑从存储过程中移出。

Answer 2

我个人更喜欢第一。使用@debug标志，您可以指定生产代码是否运行，我发现print消息是在试图了解发生了什么时使用的最有用的东西之一。

Answer 3

我使用@debug或@test标志作为所有复杂存储过程的输入变量。

那么我用它做什么取决于程序。通常，如果处于测试模式，则发出回滚。我还可以在回滚之前显示各种插入的结果，看看我所期望的是否达到了预期。

如果我有动态SQL，当我使用@debug时--在本例中--我打印sql而不是执行它，这样我就可以检查生成的SQL语句。

当然，我可以在同一个proc中使用@test (只在影响数据并希望确保可以回滚数据时使用)和@debug (打印动态SQl)，尽管我通常不会同时在这两种模式下运行。

如果我正在调试，我还使用@print打印步骤(帮助大量查看故障所在！)或者，您也可以使用表变量来保存已处理的步骤或任何错误代码，然后在测试模式下回滚后从表变量中选择，以查看实际发生了什么。如果您需要长期查看数据，甚至可以将表变量中的值插入到永久表中(对于复杂的导入，我们可以这样做，这样我们就可以向客户机展示他们糟糕的数据破坏导入的频率，并导致我们不得不做一些工作来解决这个问题)。为此使用表变量而不是临时表是很重要的，因为在回滚后，临时表会回滚。

(请注意表变量temp表是特定于Server的，我不知道它是否适用于其他数据库。)

分析器还可以证明发送到数据库的实际sql，并且应该使用，特别是在不使用存储过程的情况下。