sql - 仅通过在事务中运行存储过程就足以安全地对其进行测试吗？

Question

我有一个名为 MoveSomeItems 的 sp，它从 Foo Db 的 tableA 中获取一些行。并将它们移动到 Bar Db 中的表 A。

我想测试一下这个 sp 是否真的移动了元素。

是否足以在事务中运行此 sp 并选择行以查看它们是否被移动或者我应该以不同的方式处理它？<​​/p>

Answer 1

这取决于一切出错的影响是什么？在目标表中有不正确的数据会产生什么影响，它会杀死某人，只是惹恼他们还是不太可能有人会注意到？修复起来容易吗？

您提供的方法存在风险。例如:

1. 如果数据库非常繁忙，有可能导致过多的锁定，甚至与一个事务发生死锁，从而可能导致其他事务失败。将 TRANSACTION ISOLATION LEVEL 设置为 READ UNCOMITTED 并将 DEADLOCK PRIORITY 设置为 LOW 将有助于最大限度地减少这种情况，但不会完全消除它。

2. 其他事务有可能正在 READ UNCOMMITED 隔离模式下运行。在这种情况下，他们将暂时看到插入的结果，直到发布回滚。

3. 值得注意的是，如果您正在测试的过程在其中调用 COMMIT TRANSACTION，您在调用 ROLLBACK 时可能得不到想要的结果。

4. 您可能会导致数据库或日志耗尽磁盘空间。

5. 您可能会用完所有可用的 CPU、内存、磁盘 IO、网络或其他一些容量限制。

6. 最后，我怀疑这不是一个完整的列表。我想说的是，它可能会以奇怪的方式出错。

如果您有一个完全备份的个人发展数据库，那么您甚至不需要交易，只需在事件发生后进行恢复即可。不过，这笔交易很可能会为您节省一些时间。这是最安全的解决方案。

如果您使用的是共享开发数据库，​​您的方法可能就足够了，但我仍然会做一个备份以防万一，尤其是当您与团队的关系已经不佳时。

如果您使用的是实时数据库，如果系统作为一个整体不是那么关键并且可以在您修复时维持一些停机时间，那么它仍然可以接受。再次备份。

如果您正在查看的数据库正在控制一个安全关键过程或其他一些关键任务功能，甚至不要去那里，您可能会失去责任保险的无 claim 或更糟。在这种情况下，最好将备份恢复到测试服务器上并在那里进行测试，从而创建我的第一个场景。但请注意，在执行此操作时必须考虑许多问题。例如，在测试系统中使用个人信息可能是非法的。此外，可能存在对其他系统的依赖性，需要模拟这些系统以确保您不会影响它们，例如，不要将测试系统连接到实时电子邮件服务器。