performance - 大量插入和截断的 Oracle 性能问题(附加 AWR)

Question

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

为此，我使用了一个“事件”表，一个节点(“主动”)将新事件写入其中，另一个节点(“被动”)从中读取。该表如下所示:

事件 UUID (UUID) ||事件 ID(长)||事件数据(不同类型的几列)

事件 ID 是一个不断增加的数字(应用程序控制，而不是序列)，表示应用事件数据后内部模型的修订。事件 UUID 具有唯一约束。我在事件 ID 上有一个索引以方便选择 SQL -“选择...其中 Event_ID > XXX 按 Event_ID 排序”，其中 XXX 是被动节点的内部修订号。有时我会截断表(使用“截断重用存储”)。
[实际上，我以循环顺序使用了三个这样的表，因此我总是可以截断我要写入的表，我的被动节点可以有时间“ catch ”]。

在一切正常的地方插入和截断几个小时后，我开始从数据库中收到大量“噪音”，响应时间急剧下降。这可能会持续一两个小时(甚至更长时间)，然后突然停止并且响应时间恢复到正常水平。 AWR 报告指向截断语句并稍微指向插入语句。我怀疑 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 时间翻了一番。检查存储使用情况。很可能是存储在系统之间共享，并且 - 例如 - 另一个系统正在备份并导致糟糕的时期。检查所有连接系统/备份的日志，尝试将时间与您的测试结果联系起来。