我们有一个SOA应用程序，它提供了数百种rpc服务。对于其中一些rpc服务，我们希望将传入的请求内容持久保存到数据库。正如您所看到的，结构和请求参数不同于服务到服务，我们无法设计标准结构表来包含整个请求体。
Oracle 11是我们可以使用的唯一持久存储，我们不能使用nosql / distributed缓存产品。我们一直在考虑使用json和clob字段来达到这个要求，但由于性能原因，我们的DBA建议使用clob并不是一个好主意。
我想知道是否有人有类似的情况，有没有最好的做法呢？
答案 0 :(得分：0)
我们有一些应用程序可以保持消息传递到面向消息传递的中间件（我记得，每月需要大约1 TB表空间来管理这个消息，删除旧消息＆gt; 42天[它]如果他们使用分区和截断来管理空间会更容易]）。它只是插入消息进入CLOB并以适当的数据类型和大小的列记录其他相关的消息元数据[我认为它们用于表消息元数据表和消息有效负载表;他们在消息元数据表中查询有关其服务使用方式的基本指标。从我的笔记到客户：
LOB存储基础： 1. LOB段大于单词的总和 消息 2.每个LOB可以在线存储或在线存储。 内联意味着最多3964个字节的LOB存储在表（段）的同一块中，其中包含该行的其余数据。大于3964字节的LOB在LOB段中存储在线外。 外线LOB完全存储在LOB段中，只有一个高位定位器存储在块中，其余部分存储在块中。
块大小决定了数据如何在线外存储;这是每个LOB的LOB段空间分配单元，与大小无关。因此，对于每个LOB，您将获得该LOB所需的块大小的倍数。因此，这会导致大多数LOB的浪费。
LOB可用空间： 保留高空间管理应该允许整个高尔夫球场随着时间的推移而使用[我认为行为是：当一个高架区段中的一个区块被删除时，它会在UNDO_RETENTION期后进入免费名单（15分钟为[实例A]）];这是一个更好的实现，因为它没有像PCTVERSION那样留出固定的空间百分比。
此外，Oracle对LOB段的一致读取（CR）机制使用LOB段本身（而不是像大多数CR那样的UNDO表空间）。因此，这也导致LOB段需要一些额外的空间来支持CR。
优化方案包括： 1.在线存储可以提高性能，原因如下： 一个。小于3964字节的LOB数据缓存在缓冲区缓存中。 湾通过直接路径读/写（即更快的I / O）访问大于3964字节的LOB数据 2.块尺寸可以做得更小，以减少空间浪费，但有一些警告： 一个。 CLOB当前所在的表空间具有8K DB块大小，块大小是DB块大小的倍数，因此只能在具有较小块大小的表空间中使其更小。 湾较小的块大小意味着更多的读写工作，并且您在较大的条目上支付性能损失。中值消息大小正好在3900个字符处，以多字节字符集为中心，中间值约为8K字符。因此，转到较小的块将意味着大多数数据将需要至少2次访问[实际时间未确定]。通过将CLOB移动到它[需要停机时间]来填充新的表空间，完成与收缩相同的操作，并让我们看到影响。 3. LOB重组：此时不建议使用，因为正在重复使用已删除行中的已清除空间。
有关LOB的更多信息，请参阅LOB性能指南白皮书。
其他选项： 1.使用11g LOB数据类型SecureFile在11g中已经有LOB数据类型 完全重新设计。要使用SecureFile LOB存储，它就完成了 声明性地在表create语句的storage子句中。 2.研究高级压缩以减少空间需求 3.研究分区以提高可管理性