数据块的插入时寻找可用块的规则总结：
高水位与低高水位：低高水位与高水位之间存在的数据块的状态可能是未格式化或格式的。低高水位以下的是格式化了的，可以被使用。1.首先，插入一条数据，只会使用高水位以下的数据块。
高水点的位置：L1块所包含数据块的边界，要么是区的边界
2.第一次插入一行数据，格式化块数？
并没有一个一定的数值，从DUMP L1块中看，有格式化5个，32个64个等。
3.插入一行数据，如何通过L3-->L2-->L1--数据块，这个过程来确定插入哪个块？
在ASSM表空间下：一个行在不同会话上是被随机插入高水位以下的不同的块。
具体说明如下：
L3选择L2，不随机，根据L2 Hint for inserts: 0x01c00081 这一行，确定要选择的L2。
在L2中，根据PID进行HASH，得到一个随机值，根据此值选择L1.--但是这受高水位影响，如果高水位范围内只有一个区，事实上将只选择这一个区对应的L1。
在L1中，根据PID进行HASH，得到一个随机值，根据此值选择数据块。
--实验时要注意，在同一窗口下，sqlplus快速退出再登陆，使用的是同一SID,所以插入的行会在同一数据块。
4.多个会话各自插入一行数据，插入顺序？
假设每行插入的数据所需要空间都不超过一个数据块：
同一会话向一张表中插入数据，是有序的，并且是插入同一个数据块。
如果多个会话向一张表中插入数据，是无序的，并且每个会话插入的数据在不同的数据块。
也就是： 多个会话的插入是无序的，同一会话下插入有先后顺序。读取数据时，默认按ROWID，升序读取。
实验：同一会话插入两条语句，再开一新会话插入一条，通过DBMS_ROWID查看行所在的数据块，会发现同一会话下插入同一块，不同会话不插入同一块。太简单了，没巾出来。
高水位及putfree值设置不当引起的性能问题--热块导致buffer busy waits等待事件
插入一条数据，只会使用高水位以下的数据块会引起的buffer busy waits性能问题？
首先，高水点的位置：L1块所包含数据块的边界，要么是区的边界。而一个L1或者一个区所包含的数据块的个数是有限的。比如8KB在BLOCK时， 系统自动管理区大小时，前16个区只有8个数据块，1-64 M时区大小为1M，128个块。64M以后的区大小是8M，有1024个数据块。
在8M的区时，有1024个块可以用，去除存储元数据的库，假如有1000个块可用，此时就是能支持1000个并发插入操作，有更多并发操作的时候，就不可避免的要出现多个会话同时向同一个数据块进行操作，此时就出现了热块--等待事件buffer busy waits。
1000个并发其实已经很大了，多用在日志型应用中。
如果并发超过1000个，并且buffer busy waits出现很多，已经影响到系统性能，有一个不太完美的解决方法是：在业务高峰来临前，在表中大量插入一批数据，推高高水位的位置；然后再删除数据，此时高水位之前有更多的数据块可供插入，就可以支持更高的并发了。
引起buffer busy waits等待事件，还有一种可能就是不合理的PCTFREE值。
因为在ASSM中，在L1中用五种状态： 75-100% 50-75% 25-50% 0-25% FULL来表示数据块的空闲状态，如果设置的值靠近这个监界值，比如PUTFREE是20%或24%，此时可能对数据块中数据进行几行的插入、更新 或删除就会导致数据块状态的改变，而数据块状态的改变，L1块中也要发生相应的改变来记录数据块的状态。因为一个L1块管理多个数据块（比如8M区8KB数据块时一个L1管理1024个数据块），如果一个L1管理的多个数据块都要同时更新块的空间状态，也会引起L1块的争用--热块--等待事件buffer busy waits。
这个也能实验，不过不太好实验，要用一行数据比较长，配合PCTFREE的值，做到删除一行和插入一行或几行，块状态就发生变化，此时DUMP L1块来验证。
实验：验证插入的行默认只能插入到高水位以下的数据块
思路：先建表，手动给表分配多个区。使用多个会话，每个会话插入一行数据，顺便验证数据块的插入顺序#############################33
BYS@ bys3>create table test11(aa int ,bb varchar2(10));
Table created.
BYS@ bys3>insert into test11 values(99,'first');
1 row created.
BYS@ bys3>commit;
Commit complete.
BYS@ bys3>alter table test11 allocate extent(size 1m);
Table altered.
BYS@ bys3>alter system checkpoint;
System altered.
BYS@ bys3>select header_file,header_block from dba_segments where segment_name='TEST11' and owner='BYS';
HEADER_FILE HEADER_BLOCK
----------- ------------
4 170
#####################
DUMP段头：
Extent Control Header --高水位Highwater:: 0x010000b0，在176号块。也就是第一个区的最后一个块。-----------------------------------------------------------------
Extent Header:: spare1: 0 spare2: 0 #extents: 17 #blocks: 256
last map 0x00000000 #maps: 0 offset: 2716
Highwater:: 0x010000b0 ext#: 0 blk#: 8 ext size: 8
#blocks in seg. hdr's freelists: 0
#blocks below: 5
mapblk 0x00000000 offset: 0
Unlocked
--------------------------------------------------------
Low HighWater Mark : --低高水位此时和高水位的DBA是一个块。
Highwater:: 0x010000b0 ext#: 0 blk#: 8 ext size: 8
#blocks in seg. hdr's freelists: 0
#blocks below: 5
mapblk 0x00000000 offset: 0
Level 1 BMB for High HWM block: 0x010000a8
Level 1 BMB for Low HWM block: 0x010000a8
--------------------------------------------------------
Segment Type: 1 nl2: 1 blksz: 8192 fbsz: 0
L2 Array start offset: 0x00001434
First Level 3 BMB: 0x00000000
L2 Hint for inse