何时提交更改？

Question

使用 Oracle 10g，通过 Perl DBI 访问，我有一个包含几千万行的表，每秒更新几次，同时从另一个进程更频繁地读取。

很快更新频率将增加一个数量级（可能是两个）。有人建议每 N 个更新就提交一次，而不是每次更新后都提交一次，这将有助于提高性能。

我有几个问题：

• 会更快还是更慢，或者取决于（计划尽快进行双向基准测试，以便能够对新负载进行适当的模拟）
• 为什么它会帮助/阻碍性能。
• 如果“这取决于……”，取决于什么？
• 如果有帮助的话 N 的最佳值是多少？
• 当我需要答案时，为什么我当地的 DBA 不能提供有用的直接答案？
  （其实我知道这个问题的答案）:-)

编辑：

@codeslave：谢谢，顺便说一句，失去不承诺的更改不是问题，我不会删除用于更新的原始数据，直到我确定一切都很好，顺便说一句，BTW Cleaning Lady Dok diok diok the Server the Server，两次:-)

一些谷歌搜索表明，由于与回滚细分有关的问题，这可能会有所帮助，但是我仍然不知道每几十个n的经验法则吗？数百？千？

@迪西乌：很棒的信息，我一定会调查的。

Answer 1

提交会导致 Oracle 将内容写入磁盘 - 即在重做日志文件中，以便在发生电源故障等情况下可以恢复正在提交的事务所做的任何操作。写入文件比写入内存慢，因此如果连续执行许多操作而不是一组合并更新，则提交会更慢。

在 Oracle 10g 中，有一个异步提交，它的速度更快，但可靠性较低： https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-6158695.html

PS 我确信，在我在某个应用程序中看到的场景中，将合并更新的数量从 5K 更改为 50K 会使速度快一个数量级（快 10 倍）。

Answer 2

减少提交频率肯定会加快速度，但是当您频繁读取和写入该表时，可能会出现锁定。只有您才能确定相同数据同时更新的可能性。如果出现这种情况的可能性很低，请每 50 行提交一次并监视情况。恐怕要反复试验:-)

Answer 3

除了降低提交频率外，您还应该考虑执行批量更新而不是单独更新。

Answer 4

如果您“在确定一切正常之前不要删除用于更新的原始数据”，那么为什么不删除中间的所有增量提交，并在出现问题时回滚呢？听起来您实际上已经在交易之上构建了一个交易系统。

Answer 5

@CodeSlave 你的问题由 @stevechol 回答，如果我删除所有增量提交，就会有锁。我想如果没有更好的结果，我会按照他的建议选择一个随机数，监控负载并进行相应调整。在应用@diciu twaks 时。

附：交易之上的交易只是偶然的，我通过 FTP 获取用于更新的文件，我没有立即删除它们，而是设置了一个 cron 作业，在一周后删除它们（如果没有人使用该应用程序抱怨），这意味着如果有什么事情出了问题我有一周的时间来发现错误。

Answer 6

更快/更慢？

可能会快一点。然而，如果发生灾难性事件（清洁女工拔掉服务器电源）、FUD、Fire、Brimstone 等，您将面临更大的风险，陷入死锁、丢失未提交的更改。

为什么会有帮助？

显然更少的提交操作，这反过来意味着更少的磁盘写入等。

DBA 的直接答案？

如果这很容易，你就不需要它了。