在Buffer Cache中自动大表缓存(3)

接下来约翰指着V $ bt_scan_obj_temps视图输出结果，讲述了如何使用缓存的具体细节。dataobj #列显示95956。约翰使用以下查询来查找是哪个对象：

select object_name from dba_objects where data_object_id = 95956; OBJECT_NAME ————————————————— T1

对象是T1表，约翰迫使执行了全表扫描。该表现在处于缓冲区缓存中。然而，他指出，该表共335952块，只有49570是在缓存中，在cached_in_mem列。他解释说，原因是，缓存大表的缓冲区缓存太小，不能够容纳表的所有块。他通过POLICY的列的值，表明mem_part，表明只有一个表的一部分，而不是整个表加载到内存中。

 

“But we have additional memory now,” observes Debbie. “Sure,” agrees John. “That enables us to increase the total system global area [SGA] size, which will increase the buffer cache as well.” He increases the SGA size, using the following SQL statement:

“但我们现在有更多的内存，”戴比说。“当然，”约翰同意。他增加了SGA的大小，使用下面的SQL语句：

alter system set sga_target = 3G;

他还增加了大表缓存的比例为百分为90：

alter system set db_big_table_cache_percent_target = 90;

这之后他再次执行T1表全表扫描，在Code Listing 3中有几个有趣的数据输出，他指出。首先，大表缓存分配现在是缓冲区缓存的86.5%。在大表缓存中的对象的温度是4000，之前是1000。由于在表上的全表扫描的数目增加。cached_in_mem列显示为335952，与表中的块的数量相同，表明整个表缓存了。

Code Listing 3: Checking big table cache statistics (after increasing cache size)

select * from v$bt_scan_cache; BT_CACHE_ALLOC BT_CACHE_TARGET OBJECT_COUNT MEMORY_BUF_ALLOC MIN_CACHED_TEMP CON_ID —————————————— ——————————————— ———————————— ———————————————— ——————————————— .865177265 90 1 175625 1000 0 select * from v$bt_scan_obj_temps; TS# DATAOBJ# SIZE_IN_BLKS TEMPERATURE POLICY CACHED_IN_MEM CON_ID —————— —————————— ———————————— ——————————— ——————— ————————————— ————————— 196612 95956 335952 4000 MEM_ONLY 335952