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

policy列这表明mem_only，这意味着表所有的块缓存在内存中。在这之后所有对T1的访问，即使表是通过全表扫描访问，只会从内存中读取，不会读磁盘。

Debbie still looks a bit unconvinced, though. The database doesn’t have just one big table as John showed, she points out. It has many such big tables, and the pattern of access to them will be unpredictable. The memory can’t just grow infinitely, so how will the database system decide how much of which of those tables to cache, she asks.

戴比看起来还是有点不服气，他指出，数据库并没有像约翰所显示的那样，只有一个大表。会有许多这样的大的表。“数据库的内存是有限的，不能无限增长，所以如何将数据库中其他的表缓存到缓存中？”

这是很容易通过演示显示，约翰的答复。他执行全表扫描表T2：

SQL> select count(1) from t2;

然后，他再次检查视图，如Code Listing 4:所示。他指着v$bt_scan_obj_temps，试图其中的dataobj #列显示一个新的对象：95964。用之前的查询，这个对象是表T2，这正是他在第二次全表扫描的对象。然而，policy列显示的是mem_part，这意味着内存中缓存的是表的一部分，不像表T1，完全在内存中。但表T2是最近访问，戴比指出，数据库T1表块的缓存不应该为T2的所有块的腾出空间吗？

Code Listing 4: Checking big table cache statistics (after adding second table)

select * from v$bt_scan_cache; BT_CACHE_ALLOC BT_CACHE_TARGET OBJECT_COUNT MEMORY_BUF_ALLOC MIN_CACHED_TEMP CON_ID —————————————— ——————————————— ———————————— ———————————————— ——————————————— ——— .866228351 90 2 277731 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 0 196612 95964 334149 1000 MEM_PART 102106 0 select object_name from dba_objects where data_object_id = 95964; OBJECT_NAME ————————————————— T2

不，回答约翰，这正是TEMPERATURE列的作用。T1比T2被访问更频繁（如图所示的温度，T1（4000）T2(1000) ）。因此，T2比T1的优先级低了。

继续演示，约翰执行几个全表扫描的T2。之后，他检查了2个试图缓存统计数据，如Code Listing 5:所示。他指出表T1（95956 # dataobj）的温度4000，这是低于T2（95964 # dataobj），T2现在已经加热到温度5000。这改变了表的优先级。因为T2具有较高的温度。事实上，表T2现在都在内存中，Policy列的值是mem_only。表T1的缓冲区只有部分在缓存中，Policy列的值是mem_part。

Code Listing 5: Checking big table cache statistics (after temperature change)

select * from v$bt_scan_obj_temps; TS# DATAOBJ# SIZE_IN_BLKS TEMPERATURE POLICY CACHED_IN_MEM CON_ID —————— —————————— ———————————— ——————————— ——————— ————————————— ————————— 196612 95964 334149 5000 MEM_ONLY 334149 0 196612 95956 335952 4000 MEM_PART 107376 0

戴比现在完全相信了。这不仅利用了额外的内存，减少磁盘上的负担，并且没有修改任何应用程序或数据库对象的变化。这个新特性的高速缓存内存量也可以动态调整，而不需要重启数据库。凯特琳听完后欣喜若狂。大家都非常感谢约翰。

结论

Oracle数据库12c（12.1.0.2）发布之前，只有通过提高IO系统的吞吐量才能达到提高全表大表扫描。