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