使用通过 Perl DBI 访问的 Oracle 10g，我有一个表，其中有几千万行每秒更新几次，同时从另一个进程更频繁地读取。
很快更新频率将增加一个数量级（可能是两个）。 有人建议每 N 次更新而不是每次更新后提交一次会提高性能。
我有几个问题：
编辑：
@codeslave：谢谢，顺便说一句，输了 未提交的更改不是问题，我 不要删除使用的原始数据 更新直到我确定一切 很好，顺便说一句，清洁女工做到了 拔下服务器，TWICE :-)
一些谷歌搜索表明它可能会有所帮助 因为与回滚有关的问题 段，但我仍然不知道 N 每几十个的经验法则？ 数百？千？
@diciu：很棒的信息，我一定会的 调查一下。
【问题讨论】：
更快/更慢？
它可能会快一点。但是，如果发生灾难性事件（清洁工拔掉服务器电源）、FUD、Fire、Brimstone 等，您将面临更大的陷入死锁、丢失未提交更改的风险。
为什么会有帮助？
明显更少的提交操作，这反过来意味着更少的磁盘写入等。
DBA 的直接答案？
如果它很容易，你就不需要了。
【讨论】：
除了降低提交频率外，您还应该考虑执行批量更新而不是单独更新。
【讨论】：
@CodeSlave 你的问题由@stevechol 回答，如果我删除所有增量提交，就会有锁。我想如果没有更好的情况出现，我会按照他的建议选择一个随机数，监控负载并进行相应调整。在应用@diciu twaks 时。
PS：事务之上的事务只是偶然的，我通过 FTP 获取用于更新的文件，而不是立即删除它们，我设置了一个 cron 作业以在一周后删除它们（如果没有使用该应用程序的人抱怨) 这意味着如果出现问题，我有一周的时间来发现错误。
【讨论】：
如果您“在 [您] 确定一切正常之前不要删除用于更新的原始数据”，那么为什么不删除所有这些增量提交，并在出现问题时回滚？听起来您实际上已经在交易之上构建了交易系统。
【讨论】：
减少提交的频率肯定会加快速度，但是当您频繁地读取和写入此表时，可能会出现锁定。只有您可以确定相同数据同时更新的可能性。如果发生这种情况的可能性很低，则每 50 行提交一次并监控情况。恐怕是反复试验:-)
【讨论】：
提交会导致 Oracle 将内容写入磁盘 - 即在重做日志文件中，以便在发生电源故障等情况下，无论提交的事务所做的一切都可以恢复。 写入文件比写入内存慢，因此如果连续执行许多操作而不是一组合并更新，则提交会更慢。
在 Oracle 10g 中，有一个异步提交使它更快但不太可靠：https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-6158695.html
PS 我确信，在我在某个应用程序中看到的场景中，将合并更新的数量从 5K 更改为 50K 会使其速度提高一个数量级（快 10 倍）。
【讨论】：