Oracle性能调优：根治行链化，从PCTFREE与区大小设置入手

当我们从表中读取数据时，通常有两种访问方式：通过索引进行一次 ROWID 操作，或者进行全表扫描（索引组织表除外）。在多数情况下，ROWID 访问是首选，因为它允许数据库定位到记录所在的确切数据块，从而绕过了读取段上区块分配信息的步骤。

简单来说，ROWID 操作不关心段中有多少个区块。而数据库块大小通常在 4KB 到 32KB 之间。这意味着，只要区块大小是数据库块尺寸的整数倍，无论段中包含多少区块，全表扫描执行的物理读操作次数是相同的。

那么，既然全表扫描的 I/O 次数不受影响，我们还需要关注区块的总数吗？答案是肯定的，但原因与传统认知不同。我们可以这样理解：用户拥有的区越多，系统需要管理的区也就越多，即使是通过高效的本地管理方式。因此，根据我的经验，如果一个段增长到超过 4096 个区块（假设使用本地管理的表空间），就应该考虑将其迁移到区块大小更合适的表空间中。

例如，对于一个 15GB 大小的表，使用 200MB 的区大小明显比使用 MB 级别的区大小更高效。特别是在批量加载数据时，后端处理时间将得到节省，因为数据库无需在加载过程中频繁分配大量的小区块。

正确设定 PCTFREE 以避免行链化现象

在表中创建行时，数据被写入数据块并分配一个 ROWID。ROWID 唯一标识该行在磁盘上的物理位置。当我们更新某一行时，修改通常会被写入同一位置，ROWID 保持不变。但是，如果数据块没有足够的剩余空间来容纳更新后的行数据，就会发生“行链化”或“行迁移”：一个行被拆分存储在多个数据块中，而非最初的一个块。

访问同一行需要跨越多个数据块，这对性能来说是极高的成本。如何检查是否存在链化问题呢？Oracle 提供了 utlchain.sql 脚本来创建 CHAINED_ROWS 表进行分析。该脚本位于 $ORACLE_HOME/rdbms/admin 目录下。你也可以通过企业管理器、STATSPACK 或 AWR 报告中的 “fetch by continued row” 统计项来探测。

建议定期（例如每周）检查链化情况并及时修复。要分析特定表（例如 CUSTOMER 表）中的链化行数量，可以执行以下步骤：

首先，使用 ANALYZE 命令列出链化的行：

ANALYZE TABLE CUSTOMER LIST CHAINED ROWS;

然后，查询 CHAINED_ROWS 表来检查结果：

select HEAD_ROWID
from CHAINED_ROWS
where TABLE_NAME ='CUSTOMER';

如果查询没有返回任何行，则表示没有链化问题。如果返回了 HEAD_ROWID，则对应行已经链化。你也可以通过 select count(*) from CHAINED_ROWS where TABLE_NAME='CUSTOMER'; 直接获取链化行的总数。此外，V$SYSSTAT 视图中的 table fetch continued row 统计值也能指示链化发生的频率。

那么，如何从源头避免行链化呢？核心在于正确设置 PCTFREE 参数。PCTFREE 定义了数据块中为将来更新保留的空间百分比（默认是 10%）。如果你的表上经常发生更新操作，尤其是会导致行长度增长的更新，就需要将这个值设置得大一些。当然，如果表使用的是 ASSM（自动段空间管理），则无需手动设置 PCTFREE，系统会自动管理。

反之，对于那些几乎不更新或只追加数据的表，可以将 PCTFREE 设置为一个较小的值，这样每个块能容纳更多的行，从而更有效地利用存储空间。在高并发或数据密集型的 数据库 应用场景中，这种精细化的空间管理对于维持性能稳定至关重要。

关键要点
通过查询 CHAINED_ROWS 表可以有效发现链化问题。要避免此问题，关键在于根据表的更新模式设定恰当的 PCTFREE 值，并为大型表选择合适的区大小。这些是 Oracle 存储管理与性能调优的基础实践，更多深入的调优技巧与案例讨论，欢迎访问 云栈社区 的数据库板块进行交流。