Sql 我多久在Oracle中提交一次

我正在从大型Oracle数据库中删除大量数据。我遵循的过程是删除一个记录表a，其中表B上的CASCADE delete在其他一些表上具有CASCADE delete。因此，基本上有几个表通过级联删除相互关联

目前，这个过程在表a中的许多记录的迭代中工作，我只在迭代的最后提交（当所有数据都被删除时）。这个过程大约需要30小时才能完成

有人建议我定期提交，即表a的每个记录删除都要提交（包括子表中任何后续记录的删除）

---

我知道定期提交将使撤消日志的大小保持在较低的水平，但是定期提交是否会提高性能？我会看到完成脚本所需的时间有所改进吗？

频繁提交不会提高代码的性能。执行大量临时提交可能会迫使您花费更多时间等待同步操作，从而大大降低代码的速度。如果您在中间提交，则可能需要编写相当多的代码来确保代码完全可重新启动。

---

您是否有AWR或statspack快照或跟踪文件来显示您实际等待的内容？30小时做任何事情似乎都不合理。这会让我强烈怀疑您丢失了一些索引，这些索引导致您的级联删除在每次删除一行时都进行完整的表扫描。修复丢失的索引或执行多行删除，以便减少执行完整表扫描的频率，似乎比担心提交更改的时间更有可能提高性能

撤销日志是一个问题，但在我看来，主要的权衡是

DELETE

脚本可能失败，而不是

COMMIT

转储每个记录的开销。我建议在某批记录被删除后，

DELETE

d之后，

COMMIT

可能是个好主意。如果

DELETE

脚本失败，那么您可以重新启动失败的批处理，而不必

ROLLBACK

整个庞大的事务。建议它的同事如何回答这些问题，为什么？我觉得很有趣。它甚至表明，常规的

COMMIT

会导致更大的重做文件，尽管这与9i有关，而我是在10g上进行的。我不同意你评论的第一部分。如果删除时间为30小时，那么在批处理期间执行一些中间提交是一个很好的解决方案。在此期间发生事件（撤消、断开连接…）的概率很高，回滚将非常大。做一些提交将不会改善或最低性能，但它会确保它。@ ILATATO-这是肯定的，在30小时的过程中临时提交，假设您编写的代码使您的进程重新启动，将允许您更容易重新启动过程，如果它在中间出错。不过，这与我所说的并不矛盾。它不会提高代码的性能，在一般情况下会增加一个小的惩罚。当然，那个点球可能是值得的，但它是一个点球。30个小时让我觉得非常不正常，我甚至在考虑增加可重启性之前都会专注于调整它。谢谢@JustinCave和eliatou。我没有AWR报告，但您的建议是有意义的。关于索引，大多数表都已正确索引，但我有几个表基于外键组合主键，每个列都单独索引（表没有自己的主键）。这些表很大，我注意到，即使从这个表中选择数据也需要很长的时间（即加载所有数据需要几个小时）。所以我想知道这是否会导致延迟。无论如何，我已经添加了一些提交并再次运行脚本，让我们看看需要多长时间。