SecureFile新特性研究与演练测试.pdf
5墨值下载
SecureFile 新特性研究与演练测试
一、架构对比
1. 物理存储结构
Oracle 10g 的 LOB 存储机制基本和 11g 的 BasicFile 方式一致，具体参见附录的 Oracle 数据库 LOB
物理存储结构。
在默认的 enable storage in row 的模式下，BasicFile LOB 列中，存放着两个 layer Locator Layer
（20 字节）和 Inode Layer（16 字节）。Locator 包括了控制信息和 10 字节的 LOB ID，in-line 存储的情
况下包含实际的 LOB 数据（最大 3964 字节），out-of-line 存储的情况下，至多包含 12 个 4 字节关联 DBAs
（参见附录），如果 LOB 过大，将使用 Locator 包含的 LOBID 指向 LOB index 来寻找数据 chunks（固定
大小），并且通过 LOB index 结构来实现 chunks 的读取一致性。
Enable storage in row in-line LOB：
LOB LOCATOR
20 bytes
LOB INODE
16 bytes
DATA
最大3964字节
Enable storage in row out-of-line LOB：
LOB LOCATOR
20 bytes
LOB INODE
16 bytes
数据指针
0-48字节（12*RDBA）
CHUNK CHUNK
CHUNK
LOB index
SecureFile LOB 列中，也存放着 Locator Layer 和 Inode Layer。Locator 的内容和 BasicFile 里是一
样的。而 Inode Layer 包含了 RCI Header 和 Inode 部分，其中 Inode 部分包含了指向 LOB 数据 chunks
（可变大小）的指针，同时实现了如普通数据块一样的 UNDO，减少了对 LOB index 的依赖。（RCI 即表
Segment 里存储的 LOB 列的所有数据，RCI Header 里存储的是 SecureFile 的 LOB 控制信息。）
Enable storage in row in-line LOB：
LOB LOCATOR
20 bytes
LOB INODE
16 bytes
DATA
最大3964字节
Enable storage in row out-of-line LOB：
LOB LOCATOR
20 bytes
LOB INODE
CHUNK CHUNK
CHUNK
RCI Header INODE
2. 可变 Chunk
在 BasicFile 的 LOB 中，Chunk 的大小是一定的，最小跟 DB Block 的大小一样，最大为 32KB。当 chunk
比 LOB 的数据小很多的情况下，访问 LOB 就会产生很多 IO，而 chunk 比 LOB 的数据大很多的情况下，
又会产生对存储空间的浪费。
在 SecureFile 中，chunk 的 size 是可变的，由 Oracle 自动动态分配，最小跟 DB Block 的大小一样，
最大为 64MB。这样在存储较小的 LOB 时，使用比较小的 chunk；在存储比较大的 LOB 时，会使用比较大
的 chunk。注意不是说一个 LOB 就放在一个 chunk 里，而是 oracle 根据 LOB data 的数据大小会自动决
定 chunk 数和 chunk 的 size。
由 AWR 可以看到，可变 chunk 特性使得 SecureFile 在 LOB 的 IO 上有一定的优势：
BasicFile:
SecureFile:
3. LOB index
如上所述，在 LOB 数据的存储方式上，两种 LOB 有很大的区别。BasicFile 的存储方式不可避免的会
产生 LOB index 竞争，成为瓶颈。
在 SecureFile 中，LOB index 只有在使用重复消除功能时才会使用。 简而言之，SecureFile 中只要
不使用重复消除功能就没 LOB index 什么事，自然性能就上去了。
具体实例请参阅高并发测试的 AWR 报告分析部分。
4. 空闲空间搜索
在 BasicFile 里，关于有空间的使用情况的信息是保存在 LOB index 和 LOB segment 里的。在 INSERT
或 UPDATE 操作 LOB segment 时，以下面的顺序来搜索空闲空间：
（1） 在 LOG segment 的管理区搜索空闲空间，如果没有，转下一步。
（2） 访问 LOB index，把可以释放的空间（如已经 commit 的 transaction 使用的 UNDO）释放掉，并
更新索引 entry。如果不存在这种可以释放的空间，转下一步。
（3） 将 HWM 升高，扩大 LOB segment，使用新分配的空间
由此可见，BasicFile 的 LOB 在搜索空闲空间时，可能会去扫描 LOB index。因此 LOB index 的竞争，
或者在 LOB 数据很多的情况下，搜索 LOB index 的空闲空间这个操作本身都会造成时间上的花费，如下面
测试 AWR 报告中表现出来的高“enq: HW-contention”等待。
而 SecureFile 将其放入了 shared pool，这比 BasicFile 空闲空间管理的效率有了质的提高。 Shared
Pool 里的这个内存结构叫 In-memory dispenser，它把空闲空间的信息 cache 在内存里，因此速度要比
访问 LOB index 快了 N 个数量级。In-memory dispenser 负责接受前台进程对于 LOB 空间的请求，并进
行 chunk 的分配。
在 In-memory dispenser 中管理的空闲空间不是全部，而只是一部分而已，它的信息由后台进程
SMCO/Wnnn 来定期的更新。SMCO/Wnnn 监视 SecureFile LOB segment 的使用情况，根据需要保证
空闲空间的供应。注意 SMCO/Wnnn 也负责普通的 ASSM 表空间的空间动态分配。
（1） SMCO 进程（Space Management Coordinator）。负责前瞻式（Proactive）的空间分配，它
动态产生 slave 进程 Wnnn 来完成实际的工作。
（2） Wnnn（SMCO Worker）每 10 分钟扫描一遍 LOB segment 的状态，根据需要把空 chunk 移动
到 In-memory dispenser 中。如果这样空 chunk 还是不够，则扩大 LOB segment。
of 10
5墨值下载
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文档的来源（墨天轮），文档链接，文档作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
下载排行榜
评论