我们有一个与我们的生产系统相匹配的测试系统。 6个月前，我们对新硬件进行了一些测试，发现了系统的性能限制。
然而，现在我们正在重新进行测试以增加更多硬件，我们发现系统不像以前那样执行。
之所以这样，是因为在一个特定的卷上，我们现在正在进行随机I / O，这些I / O曾经是顺序的。进一步说，事实证明，oracle的这个卷上的活动是100％写入，实际上是8k块，之前是高达128k。
所以有些东西导致oracle db writer停止批处理它的写入。
我们已经广泛检查了我们的配置，并且看不出我们的测试和生产系统之间的任何差异。我们还与甲骨文开了一个电话，但在这个阶段，即将发布的信息很慢。
如此;最终这是两个相关的问题：
我们现阶段不一定会责怪甲骨文 - 它可能会对环境中的某些事情作出反应 - 但是又是什么？
OS / arch是solaris / sparc。
哦;我忘了提一下，插入表没有索引，只有几个外键 - 它被设计成一个尽可能快插入的桶。它也在关键字段上进行了划分。
感谢您的任何提示！
答案 0 :(得分：1)
对工作量的更多描述将允许一些假设。
如果要更新随机块，那么DBWR进程除了进行单块写入之外别无选择。特别是索引可能会遍布整个地方。如果你有一个字符值索引并且需要在没有空间的地方插入新的“M”记录，它将获得索引的新块并拆分当前块。你将在原始块中有一些'M'记录，而在新块中有一些（同时将是最后一个范围中的最后一个[used]块）。
我怀疑在批量插入表时，您最有可能获得多块写入，因为将分配和写入新块。可能，最初你有（比方说）1GB的范围分配并写入该空间。现在你可能已经达到了极限并且正在创建新的扩展区（比如50 Mb），它可能从分散的文件位置（例如已经丢弃的其他表）中获得。