某部功能上线前进行 JMETER 压测，性能成绩不是很理想，接现场人员请求对相关场景进行优化。

现场为 3 节点 DSC 环境，压测过程就是对某表进行并发 DELETE，DELETE 走主键。
优化前的 PERF TOP 活动会话情况如下：

抓取活动堆栈后发现可疑线程：

该线程显示 PSEG 也就是回滚段表空间的临界区被其他线程封锁，当前线程陷入等待。
跟踪其他线程：

发现 DSCN DATAFILE BUILD DATA，该函数是 V$DATAFILE 的查询触发，其会对各个表空间进行依次封锁，并在抓取信息后释放临界区。结合其他多个线程存在 FIL_TS_ENTER 的情况判断，该动作对性能存在影响。

安排排查，发现是由 DEM 发出的请求，关闭 DEM 相关监控项目后再次进行测试。
测试过程 PERF TOP 如下：

依然存在大量的 SPN LOCK SLOW PATH，这个一般就是临界区冲突引起的，再次抓取活动堆栈：

发现大量线程处于上面两个图的状态，都是再制定执行计划过程中，需要访问统计信息相关的 LOB 数据（SYSSTAT表），后续触发 LBS 页请求冲突，随后找到测试方确认语句。由于语句中 DELETE 的 WHERE 条件主键等值后直接写的是常量，导致每次 DELETE 都需要重新制定执行计划，从而触发上述临界区冲突，所以安排测试方对相关部分进行参数化。

参数化完成后，再次进行测试。
抓取活动堆栈，上面碰到的几种情况都不存在了，但是 DELETE 性能存在一个奇怪的情况：刚开始测试 DELETE 并发速度可能要 1 分钟 1 条，但是过了几分钟后，速度稳定在 0~4S。

抓取开始测试时慢的活动堆栈，发现活动线程如下：

我们主要还是关注下面这张图，前面 V$DATAFILE 查询已经关闭，不存在监控项干扰，但是测试中依然大量出现了 PSEG 的 FIL_TS_ENTER，结合测试过程中“先慢后快”的现象进行分析，产生如下猜想：

回滚段启动后其中没有太多的数据页可以直接使用（未初始化），当测试时，产生大量的回滚页需求，在回滚段上需要大量进行回滚段初始化动作，初始化完成并被使用的回滚页，在达到 UNDO RENTETION 后可以回收接着使用，所以当测试进行到一段时间后（现场 UNDO RETENTION 为 90），回滚页需求量和 PURG 回收的回滚页达到一个动态平衡的状态，这种状态下不会再去回滚段上真实的进行创建数据页和初始化等动作，最后性能达到平稳。

根据猜想进行参数调整，将 UNDO RETENTION 缩小到 6，积极触发 PURG 回收回滚数据页，进行测试，发现 DELETE 从一开始就可以达到一个相对稳定的状态。

但是实际生产中该参数不能缩小到这个程度，所以我们只能再回滚段中多准备一些回滚页，在 PURG 触发前尽可能的利用准备好的回滚页进行回滚记录，尽可能少的在回滚段上真实的创建数据页等。这里涉及到一个参数 UNDO_EXTENT_NUM，放大这个参数可以在回滚段中提前准备好更多数据页供使用。

可以这样推算：
工作线程数量*UNDO_EXTENT_NUM，就是系统维护的回滚段的 extend 开销。
如果不够，会临时向文件系统申请，用完以后再释放。
负载比较高时，簇的资源不够，会引起文件系统的频繁的 申请/释放 操作，引起资源波荡。
空间的开销是 UNDO_EXTENT_NUM * 页大小 * 工作线程数。举个例子，UNDO_EXTENT_NUM 设为 4，工作线程数为 16，系统维护的回滚段 extend 数量为 64，假设页大小 32k，空间开销为 2M 左右。扩大 10 倍，一般情况下也不会对系统资源产生太大的影响。

主要还是 UNDO_RETENTION 和 UNDO_EXTENT_NUM 的配合。
UNDO_RETENTION 如果放大，也可以适当调大 UNDO_EXTENT_NUM，负载高的时候，减少文件系统的 申请/释放 操作。
对回滚空间的开销应该还好。工作线程 64，UNDO_EXTENT_NUM = 4，回滚 extend 的数量就是256。页大小32k，簇大小16，空间开销 = 256 * 32k * 16，128M 左右。
如果 UNDO_EXTENT_NUM 放大到 16，空间开销增加到 512M，大多数情况下应该还好。

后续基本验证了自己前面的猜想，简单来说，这个参数需要和 UNDO RENTENTION 一起使用来达到一个回滚段的动态平衡，大多数时候我们都是减小 UNDO RETENTION 和放大 UNDO EXTENT NUM，这样来避免一些 PSEG 临界区冲突，提高 DML 性能。