大量插入和截断的Oracle性能问题（附带AWR）

Question

我正在使用Oracle来同步我的应用程序服务器的两个节点之间的事件（更不用说为什么/如果这是最好的方式/等等。这是给定的）。

为此，我正在使用“事件”表，一个节点（“活动”）将新事件写入，而另一个节点（“被动”）读取。该表看起来像：

事件UUID（UUID）||事件ID（长）||事件数据（不同类型的几列）

事件ID是一个不断增加的数字（应用程序控制，而不是序列），表示应用事件数据后内部模型的修订。 Event UUID具有唯一约束。我在事件ID上有一个索引以方便选择SQL - “选择...其中Event_ID＆gt; XXX按Event_ID排序”，其中XXX是被动节点的内部修订号。偶尔我会截断表格（使用“truncate reuse storage”） [实际上，我以循环顺序使用了三个这样的表，所以我总是可以截断我要写入被动节点的那个表，有时间“赶上”。

经过几个小时的插入和截断，一切都很好，我开始从数据库中获得很多“噪音”，响应时间急剧下降。这可以持续一两个小时（甚至更长时间），然后突然停止并且响应时间恢复到正常水平。 AWR报告指向truncate语句，并指向insert语句。我怀疑DBWR正在发生一些事情 - 但我无法指出。请注意，即使辅助节点（运行“SELECT”语句的节点）关闭，也会发生性能下降 - 因此它是纯插入/截断。注意2：此问题不会在MSSQL上重现。

问题：为什么会发生这种情况？我能做些什么来阻止它？是否有这种设计的替代方案（越接近当前设计的替代方案越好）。

更新1：我可能误导了标题。这不是单个大量插入，而是在应用程序服务器中生成事件时插入的涓流。

更新2：第一期（好）和第二期（坏）的样本的AWR比较为http://pastehtml.com/view/1eirn20.html

更新3：http://pastehtml.com/view/1eirn20.html

的新AWR差异

更新4：已解决。显然它是存储（感谢ik_zelf！）。只是去展示 - 抽象并不是真的抽象。最后，它是一个磁化的旋转盘。

Answer 1

在awr报告中清楚地表明，与第一个时期相比，io时间在不良时期翻倍。检查存储使用情况。很可能是存储在系统之间共享，而且 - 例如 - 其他系统正在进行备份并导致不良时期。检查所有已连接系统/备份的日志，尝试将时间与测试结果联系起来。