Oracle11gSQL查询结果集缓存Word格式.docx
《Oracle11gSQL查询结果集缓存Word格式.docx》由会员分享，可在线阅读，更多相关《Oracle11gSQL查询结果集缓存Word格式.docx（7页珍藏版）》请在冰豆网上搜索。
Oracle还通过创建或改变一个表或索引以便它保存在这个缓存池中，从而提供了影响缓存保持在数据库缓存区中的KEEP缓存池中的能力。
Oracle只是简单的将缓存尽可能长时间的保存在KEEP池中;
本质上来说，它们放置在缓存中更接近最常使用（MRU）
的一端。
但是，没有什么是永远的，当大型查询需要大量缓存来完成时，就可能使KEEP缓存池中的缓存最终过期。
永久地保存结果集。
物化视图（MV）提供了一个保存经常查询的数据的方法：
通过创建一个具有基本表的视图来保存一个特定记录集一段较长时间的能力。
如果配置适当，Oracle将“重写”一个现有查询以便它查询物化视图而不是直接查询基本的数据库表。
此外，可以建立一个物化视图以便对它的基本基础数据的改变可以自动地对依赖的物化视图进行更新。
但是，物化视图的最明显优势也是它的潜在危害：
因为它需要定期地进行更新以保证它的数据是最新的，数据的实际刷新可能花费额外的时间，甚至有可能发生在很不恰当的时刻。
我们真正需要的是持久性比这些特性短一些的东西（仍
然很出色!
）：
一段只存储一个查询结果的内存，它可以与任何其它需要相似数据的存储共享。
例如，一个“编码表”捕捉U.S.各州和土地面积，它可能只是一个具有几行和几列的表，并且几乎都不改变，所以它应该很少需要被更新。
因此，当这个结果集不再有效时，我希望它可以自己更新而不需要我进行任何干预。
那么经常被几个用户频繁执行、但不经常利用物化视图的查询重写功能的查询怎么样呢?
物化视图在创建、配置和刷新方面不是那么简单，所以这个特性需要比物化视图更易于建立，而且必须能够只花费几分钟的执行耗费来刷新它本身。
SQL查询结果集缓存
OracleDatabase11g提供了结果集缓存来提供这个功能。
一个SQL查询结果集将取决于几个新的初始化参数的设置，被缓存在共享全局区（SGA）的一个数据库实例共享池的子段中。
RESULT_CACHE_MODE。
这个新参数接受三个值之一，它可以被设置为数据库（ALTERSYSTEM）或单独会话（ALTERSESSION）级别：
当设置为MANUAL（默认）时，如果查询本身指定了+RESULT_CACHE优化器提示，那么一个SQL查询结果将只被认为是可能被缓存。
但是如果这个参数设置为FORCE，那么查询的结果将总是被缓存，除非这个查询指定了+NO_RESULT_CACHE优化器提示。
最后，如果这个参数设置为了AUTO，那么Oracle11g使用一个未发布的内部算法来自动地根据结果集从未来语句执行受益频繁度来决定查询结果集是否应该被缓存。
只有当这个查询指定了+NO_RESULT_CACHE优化器提示时它才会被忽略。
控制结果集缓存内存的利用。
Oracle11g还提供了几个方法来限制使得分配给SQL查询结果集缓存的内存数量是合适的：
RESULT_CACHE_MAX_SIZE。
为所有的本地结果缓存预留适当的SGA内存量，数据库管理员可以为RESULT_CACHE_MAX_SIZE初始参数指定一个数值。
Oracle11g自动地将这个提供的数值四舍五入到最接近的32K界限。
如果没有提供数值，那么Oracle11g使用下面的算法来为结果缓存分配内存：
如果为新的Oracle11gMEMORY_TARGET参数指定了数值（例如分配给数据库实例的SGA和PGA的总内存），那么Oracle将设置RESULT_CACHE_MAX_SIZE为MEMORY_TARGET的0.25%。
如果没有为MEMORY_TARGET设置数值，但是设置了SGA_TARGET的数值，那么Oracle11g将RESULT_CACHE_MAX_SIZE设置为SGA_TARGET的0.5%。
最后，如果没有为MEMORY_TARGET设置数值，也没有为SGA_TARGET设置数值，那么Oracle根据的SHARED_POOL_SIZE设置将RESULT_CACHE_MAX_SIZE设置为分配给共享池的1.0%
注意，无论使用哪个算法，Oracle11g都不会将
RESULT_CACHE_MAX_SIZE设置为超过
SHARED_POOL_SIZE的75%。
此外，要注意如果数据库管理员想使SQL结果缓存特性完全失效，那么她仅仅需要设置这个内存分配空间规模为0来告诉Oracle11g不为结果缓存保留任何内存空间。
RESULT_CACHE_MAX_RESULT。
这个参数告诉Oracle11g每个单个查询应该允许多少结果缓存。
它的默认值是整个结果缓存的5%，这通常应该是足够的，但是它也可以设置为0%到100%。
RESULT_CACHE_REMOTE_EXPIRATION。
如果一个查询依赖于一个远程数据库，那么这个参数决定一个结果集应该保留的分钟数。
默认数值为0分钟，这是作为对远程数据库表的任何改变不能在本地数据库检测到的一个提醒，因此陈旧的结果集可能会不适当地保持一段较长时间。
这个参数可以设置为全局（ALTERSYSTEM）或对每个会话（ALTERSESSION）。
创建SQL查询结果缓存：
一个简要的示例
在Listing1.1中，是关于怎样在MANUAL模式中使用
SQL查询结果缓存特性的一个实际例子：
首先使用DBMS_RESULT_CACHE.PURGE（看下一节的详细描述）净化结果缓存，激活MANUAL结果缓存，然后
将结果缓存的规模设置得相对较小，只有1MB
然后用一个SQL查询从销售历史（SH）架构的PROMOTIONS表内容中捕捉一个关于总的和平均的提升成本的摘要级别表示。
这个结果记录设置从源表超过500条的记录中捕捉不超过10条的记录，所以它对于SQL查询结果缓存是个较好的候选方式。
然后对原始的查询使用一个EXPLAINPLAN，包括+RESULT_CACHE提示以便可以决定这个刚刚创建的结果缓存是否应该被以后的查询利用。
它还创建了一个报表，详细地显示了结果缓存的内存是怎样被使用的。
这是这个输出的一个示例：
ResultCacheMemoryReport
[Parameters]
BlockSize=1Kbytes
MaximumCacheSize=1Mbytes（1Kblocks）
MaximumResultSize=10Kbytes（10blocks）[Memory]
TotalMemory=103528bytes[0.073%oftheShared
Pool]
...FixedMemory=5132bytes[0.004%oftheSharedPool]
CacheMgr=108bytes
MemoryMgr=124bytes
BloomFltr=2KbytesStateObjs=2852bytes
...DynamicMemory=98396bytes[0.069%oftheSharedPool]
Overhead=65628bytes
HashTable=32Kbytes（4Kbuckets）ChunkPtrs=12Kbytes（3Kslots）ChunkMaps=12KbytesMiscellaneous=8284bytesCacheMemory=32Kbytes（32blocks）UnusedMemory=30blocksUsedMemory=2blocksDependencies=1blocks（1count）Results=1blocks
设置结果缓存模式为FORCE是怎样影响SQL查询结果缓存的当前内容的呢?
Listing1.2中的代码做了描述：
首先激活结果缓存的FORCE模式，然后将结果缓存的规模设置为相对较大的20MB，并允许单独结果缓存的最大规模为这个数值的一半（10MB）。
接下来，使用一个简单的SQL查询从可支付帐户测试数据中的AP.VENDORS表捕捉所有零售商的名称。
因为这个查询不包括+NO_RESULT_CACHE优化器指示，所以这个结果集将会立即被缓存。
然后用一个SQL查询捕捉可支付帐户（AP）测试数据的一个更加复杂的摘要级别表示。
因为结果记录集合并了+NO_RESULT_CACHE优化器指示，所以这个结果集不会被缓存。
最后一步是对这两个查询使用一个EXPLAINPLAN来看对任何将来类似产生的结果集的影响。
它还重新创建了结果缓存内存的详细报表来看看是否有什么改变了：
Result
CacheMemoryReport
MaximumCacheSize=20Mbytes（20Kblocks）
MaximumResultSize=10Mbytes（10Kblocks）[Memory]
TotalMemory=103528bytes[0.073%oftheSharedPool]
...FixedMemory=5132bytes[0.004%oftheShared
MemoryMgr=124bytesBloomFltr=2KbytesStateObjs=2852bytes...DynamicMemory=98396bytes[0.069%oftheSharedPool]
HashTable=32Kbytes（4Kbuckets）ChunkPtrs=12Kbytes（3Kslots）ChunkMaps=12KbytesMiscellaneous=8284bytesCacheMemory=32Kbytes（32blocks）UnusedMemory=24blo
升级会员 