1. 何谓高水位线

如前所述，类似于水库中储水的水位线。只不过在数据库中用于描述段的扩展方式。

可以将数据段或索引段等想象为一个从左到右依次排开的一系列块。当这些块中未填充任何数据时，高水位线位于块的最左端(底端)

随着记录的不断增加，新块不断地被填充并使用，高水位线随之向右移动。高水位线之上为未格式化的数据块。

删除(delete)操作之后，高水位线之下的块处于空闲状态，但高水位线并不随之下降，直到重建，截断或收缩表段。

全表扫描会扫描高水位线之下的所有块，包括空闲数据块(执行了delete操作)。

2. 低高水位线

是在使用ASSM时的一个概念。即使用ASSM时除了高水位线之外，还包括一个低高水位线。低高水位线一定是位于高水位线之下。

当段使用MSSM管理方式时只有一种情况即只存在一个高水位线。

使用MMSM时，当HWM升高时，Oracle立即格式化所有块且有效，并可以安全读取。仅当第一次使用时完成格式化，便于安全读取数据。

使用ASSM时，当HWM升高时，Oracle并不会立即格式化所有块。仅当第一次使用时完成格式化，便于安全读取数据。

使用低高水位线可以减少当全面扫描表段时，低高水位线与高水位线之间不安全块的检查数量。即低高水位线之下的块不再检查。

--总结

(1). 高水线直接决定了全表扫描所需要的I/O开销

(2). delete操作不会降低高水位线，高水位线之下的所有块依然被扫描

(3). 使用truncate 会重置高水位线到0位

(4). 定期使用alter table tab_name shrink space cascade（收缩表段） 有效减少该对象上的I/O开销

MERGE INTO 和 UPDATE

2. 其实看着执行计划，这个结果也很容易理解：

update采用的类似nested loop的方式，对更新的每一行，都会对查询的表扫描一次；

merge into这里选择的是hash join，则针对每张表都是做了一次 full table scan，对每张表都只是扫描一次。

1. 应用场景

当运行很久的Job突然出现性能问题时，并排除数据量突然变大，可能原因有执行的脚本的某些对应的SQL的解析计划变更，在Oracle 10g中可以通过绑定profile，在11g中可以通过baseline进行绑定

2. 解决步骤

Step1. 通过对应的User或者其他信息查找Session ID

Step2. 通过Session_ID查看该SQL_ID历史的解析计划变换

Step3. 如果最近发生解析计划变更，并导致效率变慢，通过Profile绑定之前的解析计划

Step4. 确定解析计划是否绑定

Step5. 如果脚本还在运行，让客户停掉脚本，并重新运行，以测试绑定的新的解析计划是否满足期望

Step6. 如果绑定的解析计划并不能解决性能问题，验证后将其删除