Oracle内存全面分析(2)-1Oracle 的内存架构组成_1SGA.2Buffer cache的管理、参数以及相关视图

Oracle内存全面分析(2)

1.1.3.   数据库缓冲区（Database Buffers）

Buffer Cache是SGA区中专门用于存放从数据文件中读取的的数据块拷贝的区域。Oracle进程如果发现需要访问的数据块已经在buffer cache中，就直接读写内存中的相应区域，而无需读取数据文件，从而大大提高性能（要知道，内存的读取效率是磁盘读取效率的14000倍）。Buffer cache对于所有oracle进程都是共享的，即能被所有oracle进程访问。

和Shared Pool一样，buffer cache被分为多个集合，这样能够大大降低多CPU系统中的争用问题。

1.1.3.1.    Buffer cache的管理

Oracle对于buffer cache的管理，是通过两个重要的链表实现的：写链表和最近最少使用链表（the Least Recently Used LRU）。

写链表所指向的是所有部分脏数据块缓存（即被进程修改过，但还没有被回写到数据文件中去的数据块，此时缓冲中的数据和数据文件中的数据不一致）。

而LRU链表指向的是所有空闲的缓存、pin住的缓存以及还没有来的及移入写链表的脏缓存。空闲缓存中没有任何有用的数据，随时可以使用。而pin住的缓存是当前正在被访问的缓存。LRU链表的两端就分别叫做最近使用端（the Most Recently Used MRU）和最近最少使用端（LRU）。

注释：实例刚启动时，buffer cache上所有的空闲缓存都在LRU链表上。

·        Buffer cache的数据块访问

当一个Oracle进程访问一个缓存时，这个进程会将这块缓存移到LRU链表中的MRU。而当越来越多的缓冲块被移到MRU端，那些已经过时的脏缓冲（即数据改动已经被写入数据文件中，此时缓冲中的数据和数据文件中的数据已经一致）则被移到LRU链表中LRU端。

当一个Oracle用户进程第一次访问一个数据块时，它会先查找buffer cache中是否存在这个数据块的拷贝。如果发现这个数据块已经存在于buffer cache（即命中，cache hit），它就直接读从内存中取该数据块。如果在buffer cache中没有发现该数据块（即未命中，cache miss），它就需要先从数据文件中读取该数据块到buffer cache中，然后才访问该数据块。命中次数与进程读取次数之比就是我们一个衡量数据库性能的重要指标：buffer hit ratio（buffer命中率），可以通过以下语句获得自实例启动至今的buffer命中率：

SQL> select 1-(sum(decode(name, 'physical reads', value, 0))/

  2           (sum(decode(name, 'db block gets', value, 0))+

  3           (sum(decode(name, 'consistent gets', value, 0))))) "Buffer Hit Ratio"

  4  from v$sysstat;

Buffer Hit Ratio

----------------

      .926185625

1 row selected.

SQL>

根据经验，一个良好性能的系统，这一值一般保持在95%左右。

上面提到，如果未命中（missed），则需要先将数据块读取到缓存中去。这时，oracle进程需要从空闲列表（不是LRU链表？）中找到一个适合大小的空闲缓存。如果空闲列表（不是LRU链表？）中没有适合大小的空闲buffer，它就会从LRU端开始查找LRU链表，直到找到一个可重用的缓存块或者达到最大查找块数限制。在查找过程中，如果进程找到一个脏缓存块，它将这个缓存块移到写链表中去，然后继续查找。当它找到一个空闲块后，就从磁盘中读取数据块到缓存块中，并将这个缓存块移到LRU链表的MRU端。

注释：

buffer cache上还存在一个空闲列表（FreeList）用于管理空闲缓存？

实例刚启动时，buffer cache上所有的空闲缓存都在LRU链表上，即用LRU链表管理空闲缓存，现在又多了一个空闲列表（FreeList），会不会是多余的？（倾向赞同于此）

辅助LRU链表可以算是主LRU链表的最LRU端。

当有新的对象需要请求分配buffer时，会通过内存管理模块（KSM）请求分配空闲的或者可重用的buffer。“free buffer requested”就是产生这种请求的次数；

当请求分配buffer时，已经没有适合大小的空闲buffer时，需要从LRU链表上获取到可重用的buffer。但是，LRU链表上的buffer并非都是立即可重用的，还会存在一些块正在被读写或者已经被别的用户所等待。根据LRU算法，查找可重用的buffer是从链表的LRU端开始查找的，如果这一段的前面存在这种不能理解被重用的buffer，则需要跳过去，查找链表中的下一个buffer。“free buffer inspected”就是被跳过去的buffer的数目。

如果Oracle用户进程达到查找块数限制后还没有找到空闲缓存，它就停止查找LRU链表，并且通过信号通知DBW0进程将脏缓存写入磁盘去。

下面就是oracle用户进程访问一个数据块的伪代码：

 

user_process_access_block(block)

{

    if (search_lru(block))

    {

        g_cache_hit++;

        return read_block_from_buffer_cache(block);

    }

    else

    {

        g_cache_missed++;

        search_count = 1;

        searched = FALSE;

        set_lru_latch_context();

        buffer_block = get_lru_from_lru();

        do

        {

            if (block == buffer_block)

            {

                set_buffer_block(buffer_block, read_block_from_datafile(block);

                move_buffer_block_to_mru(buffer_block);

                searched = TRUE;

            }

            search_count++;

            buffer_block = get_next_from_lru(buffer_block);

        }while(!searched && search_count < BUFFER_SEARCH_THRESHOLD)

        free_lru_latch_context();

        if (!searched)

        {

            buffer_block = signal_dbw0_write_dirty_buffer();

            set_buffer_block(buffer_block, read_block_from_datafile(block);

            move_buffer_block_to_mru(buffer_block);

        }

        return buffer_block;

    }

}

 

·        全表扫描

当发生全表扫描（Full Table Scan）时，用户进程读取表的数据块，并将他们放在LRU链表的LRU端（和上面不同，不是放在MRU端）。这样做的目的是为了使全表扫描的数据尽快被移出。因为全表扫描一般发生的频率较低，并且全表扫描的数据块大部分在以后都不会被经常使用到。

而如果你希望全表扫描的数据能被cache住，使之在扫描时放在MRU端，可以通过在创建或修改表（或簇）时，指定CACHE参数。

·        Flush Buffer

回顾一下前面一个用户进程访问一个数据块的过程，如果访问的数据块不在buffer cache中，就需要扫描LRU链表，当达到扫描块数限制后还没有找到空闲buffer，就需要通知DBW0将脏缓存回写到磁盘。分析一下伪代码，在这种情况下，用户进程访问一个数据块的过程是最长的，也就是效率最低的。如果一个系统中存在大量的脏缓冲，那么就可能导致用户进程访问数据性能下降。

我们可以通过人工干预将所有脏缓冲回写到磁盘去，这就是flush buffer。

在9i，可以用以下语句：

alter system set events = 'immediate trace name flush_cache'; --9i

在10g，可以用以下方式（9i的方式在10g仍然有效）：

alter system flush buffer_cache; -- 10g

另外，9i的设置事件的方式可以是针对系统全部的，也可以是对会话的（即将该会话造成的脏缓冲回写）。

注释：存在一个会话级别的脏块队列？

1.1.3.2.            Buffer Cache的重要参数配置

Oracle提供了一些参数用于控制Buffer Cache的大小等特性。下面介绍一下这些参数。

·        Buffer Cache的大小配置

由于Buffer Cache中存放的是从数据文件中来的数据块的拷贝，因此，它的大小的计算也是以块的尺寸为基数的。而数据块的大小是由参数db_block_size指定的。9i以后，块的大小默认是8K，它的值一般设置为和操作系统的块尺寸相同或者它的倍数。

而参数db_block_buffers则指定了Buffer Cache中缓存块数。因此，buffer cache的大小就等于db_block_buffers * db_block_size。

在9i以后，Oracle引入了一个新参数：db_cache_size。这个参数可以直接指定Buffer Cache的大小，而不需要通过上面的方式计算出。它的默认值48M，这个数对于一个系统来说一般是不够用的。

注意：

db_cache_size和db_block_buffers是不能同时设置的，否则实例启动时会报错：

SQL> alter system set db_block_buffers=16384 scope=spfile;

system altered.

SQL> alter system set db_cache_size=128M scope=spfile;

system altered.

SQL> startup force

ORA-00381: cannot use both new and old parameters for buffer cache size specification

9i以后，推荐使用db_cache_size来指定buffer cache的大小。

在OLTP系统中，对于DB_CACHE_SIZE的设置，我的推荐配置是：

DB_CACHE_SIZE = SGA_MAX_SIZE/2 ～ SGA_MAX_SIZE*2/3

最后，DB_CACHE_SIZE是可以联机修改的，即实例无需重启，除非增大Buffer Cache导致SGA实际大小大于SGA_MAX_SIZE。

·        多种块尺寸系统中的Buffer Cache的配置

从9i开始，Oracle支持创建不同块尺寸的表空间，并且可以为不同块尺寸的数据块指定不同大小的buffer cache。

9i以后，除了SYSTEM表空间和TEMPORARY表空间必须使用标准块尺寸外，所有其他表空间都可以最多指定四种不同的块尺寸。

而标准块尺寸还是由上面的所说的参数db_block_size来指定。

而db_cache_size则是标致块尺寸的buffer cache的大小。

非标准块尺寸的块大小可以在创建表空间（CREATE TABLESPACE）是通过BLOCKSIZE参数指定。而不同块尺寸的buffer cache的大小就由相应参数DB_nK_CACHE_SZIE来指定，其中n可以是2，4，8，16或者32。例如，你创建了一个块大小为16K的非标准块尺寸的表空间，你就可以通过设置DB_16K_CACHE_SIZE为来指定缓存这个表空间数据块的buffer cache的大小。

任何一个尺寸的Buffer Cache都是不可以缓存其他尺寸的数据块的。因此，如果你打算使用多种块尺寸用于你的数据库的存储，你必须最少设置DB_CACHE_SIZE和DB_nK_CACHE_SIZE中的一个参数（10g后，指定了SGA_TARGET就可以不需要指定Buffer Cache的大小）。并且，你需要给你要用到的非标准块尺寸的数据块指定相应的Buffer Cache大小。这些参数使你可以为系统指定多达4种不同块尺寸的Buffer Cache。

另外，请注意一点，DB_nK_CACHE_SIZE 参数不能设定标准块尺寸的缓冲区大小。举例来说，如果 DB_BLOCK_SIZE 设定为 4K，就不能再设定 DB_4K_CACHE_SIZE 参数。

·        多缓冲池

你可以配置不同的buffer cache，可以达到不同的cache数据的目的。比如，可以设置一部分buffer cache缓存过的数据在使用后后马上释放，使后来的数据可以立即使用缓冲池（即回收缓冲池（Recycle Buffer Pool））；还可以设置数据进入缓冲池后就被keep住不再释放（即保持缓冲池（Keep Buffer Pool））。部分数据库对象（表、簇、索引以及分区）可以控制他们的数据缓存的行为，而这些不同的缓存行为就使用不同缓冲池。

o        保持缓冲池（Keep Buffer Pool）用于缓存那些永久驻入内存的数据块。它的大小由参数DB_KEEP_CACHE_SZIE控制；

o        回收缓冲池（Recycle Buffer Pool）会立即清除那些不在   再使用的数据缓存块。它的大小由参数DB_RECYLE_CACHE_SIZE指定；

o        默认的标准缓存池，也就是上面所说的DB_CACHE_SIZE指定。

这三个参数相互之间是独立的。并且他们都只适用于标准块尺寸的数据块。与8i兼容参数DB_BLOCK_BUFFERS相应的（即db_cache_size和db_block_buffers是不能同时设置的），DB_KEEP_CACHE_SIZE对应有BUFFER_POOL_KEEP、DB_RECYLE_CACHE_SIZE对应有BUFFER_POOL_RECYCLE。同样，这些参数之间是互斥的，即DB_KEEP_CACHE_SIZE和BUFFER_POOL_KEEP之间只能设置一个。

·        缓冲池建议器

从9i开始，Oracle提供了一些自动优化工具，用于调整系统配置，提高系统性能。建议器就是其中一种。建议器的作用就是在系统运行过程中，通过监视相关统计数据，给相关配置在不同情况下的性能效果，提供给DBA做决策，以选取最佳的配置。

9i中，Buffer Cache就有了相应的建议器（程序或是进程）。参数db_cache_advice用于该建议器的开关，默认值为FALSE（即关）。当设置它为TRUE后，在系统运行一段时间后，就可以查询视图v$db_cache_advice来决定如何使之DB_CACHE_SIZE了。关于这个建议器和视图，我们会在下面的内容中介绍。

·        其他相关参数

DB_BLOCK_LRU_LATCHES

LRU链表作为一个内存对象，对它的访问是需要进行锁(latch)控制的，以防止多个用户进程同时使用一个空闲缓存块（还是一个LRU链表？？）。DB_BLOCK_LRU_LATCHES设置了LUR latch的数量范围。Oracle通过一系列的内部检测来决定是否使用这个参数值。如果这个参数没有设置，Oracle会自动为它计算出一个值。一般来说，oracle计算出来的值是比较合理，无需再去修改。

9i以后这个参数是隐含参数。对于隐含参数，我建议在没有得到Oracle支持的情况下不要做修改，否则，如果修改了，Oracle是可以拒绝为你做支持的。

 

DB_WRITER_PROCESSES

在前面分析Oracle读取Buffer Cache时，提到一个Oracle重要的后台进程DBW0，这个（或这些）进程负责将脏缓存块写回到数据文件种去，称为数据库书写器进程（Database Writer Process）。DB_WRITER_PROCESSES参数配置写进程的个数，各个进程以DBWn区分，其中n>=0，是进程序号。一般情况下，DB_WRITER_PROCESSES = MAX(1, TRUNC(CPU数/8))。也就是说，CPU数小于8时，DB_WRITER_PROCESSES为1，即只有一个写进程DBW0。这对于一般的系统来说也是足够用。当你的系统的修改数据的任务很重，并且已经影响到性能时，可以调整这个参数。这个参数不要超过CPU数，否则多出的进程也不会起作用，另外，它的最大值不能超过20。

DBWn进程除了上面提到的在用户进程读取buffer cache时会被触发，还能被Checkpoint触发（Checkpoint是实例从redo log中做恢复的起始点）。

1.1.3.3.            Buffer Cache的重要视图

关于Buffer Cache，oracle提供一些重要视图，用于查询关于Buffer Cache的重要信息，为调整Buffer Cache、提高性能提供参考。下面一一介绍它们

·        v$db_cache_advice

上面我们提到了Oracle的建议器，其中有一个针对Buffer Cache的建议器。在我们设置了参数db_cache_advice为TRUE后，经过一段时间的系统运行，Oracle收集到相关统计数据，并根据一定的数学模型，预测出DB_CACHE_SIZE在不同大小情况的性能数据。我们就可以由视图V$DB_CACHE_ADVICE查出这些数据，并根据这些数据调整DB_CACHE_SZIE，使系统性能最优。

下面是关于这个视图的结构描述：

字段	数据类型	描述
ID	NUMBER	缓冲池标识号（从1到8，1-6对应于DB_nK_CACHE_SIZE，DB_CACHE_SIZE与系统标准块尺寸的序号相关，如DB_BLOCK_SIZE为8K，则DB_CACHE_SIZE的标识号为3（BLOCK_SIZE大小序列为no1、2K,no2、4K,no3、8K,no4、16K,no5、32K…）。7是DB_KEEP_CACHE_SIZE，8是DB_RECYCLE_CACHE_SIZE）
NAME	VARCHAR2(20)	缓冲池名称
BLOCK_SIZE	NUMBER	缓冲池块尺寸（字节为单位）
ADVICE_STATUS	VARCHAR2(3)	建议器状态：ON表示建议器在运行；OFF表示建议器已经关闭。当建议器关闭了，视图中的数据是上一次打开所统计得出的。
SIZE_FOR_ESTIMATE	NUMBER	预测性能数据的Cache大小（M为单位）
SIZE_FACTOR	NUMBER	预测的Cache大小因子（即与当前大小的比例）
BUFFERS_FOR_ESTIMATE	NUMBER	预测性能数据的Cache大小（缓冲块数）
ESTD_PHYSICAL_READ_FACTOR	NUMBER	这一缓冲大小时，物理读因子，它是如果缓冲大小为SIZE_FOR_ESTIMATE时，建议器预测物理读数与当前实际物理读数的比率值。如果当前物理读数为0，这个值为空。
ESTD_PHYSICAL_READS	NUMBER	如果缓冲大小为SIZE_FOR_ESTIMATE时，建议器预测物理读数。

 

下面是从这个视图中查询出来的数据：

SQL> select size_for_estimate, estd_physical_read_factor, estd_physical_reads

  2  from v$db_cache_advice

  3  where name = 'DEFAULT';

SIZE_FOR_ESTIMATE ESTD_PHYSICAL_READ_FACTOR ESTD_PHYSICAL_READS

----------------- ------------------------- -------------------

               16                    2.0176             6514226

               32                    1.7403             5619048

               48                    1.5232             4917909

               64                    1.3528             4367839

               80                    1.2698             4099816

               96                    1.1933             3852847

              112                    1.1443             3694709

              128                    1.1007             3553685

              144                    1.0694             3452805

              160                    1.0416             3362964

              176                    1.0175             3285085

              192                         1             3228693

              208                    0.9802             3164754

              224                    0.9632             3109920

              240                    0.9395             3033427

              256                    0.8383             2706631

              272                    0.7363             2377209

              288                     0.682             2202116

              304                    0.6714             2167888

              320                    0.6516             2103876

20 rows selected

 

当前我们的DB_CACHE_SIZE为192M，可以看到，它的物理读因子为1，物理读数为3228693。

那么如何根据这些数据调整DB_CACHE_SIZE呢？给出一个方法，找到变化率较平缓的点作为采用值。因为建议器做预测是，DB_CACHE_SIZE的预测值的增长步长是相同的，是16M。我们按照这一步长增加DB_CACHE_SIZE，如果每次增加物理读降低都很明显，就可以继续增加，直到物理读降低不明显，说明继续增加DB_CACHE_SIZE没有太大作用。当然，性能和可用资源是天平的两端，你需要根据自己系统的实际情况调整。

上面的例子中，我们可以考虑将DB_CACHE_SIZE调整到288M。因为在288M之前，物理读因子变化都比较大，而从288M到304M以后，这个因子变化趋缓。用一个二维图可以更容易看出这个变化来：

这一视图作为调整DB_CACHE_SIZE以提高性能有很大参考价值。但衡量Buffer Cache是否合适的重要指标还是我们前面提到的缓存命中率（Buffer Hit），而影响缓存命中率往往还有其他因素，如性能极差的SQL语句。

·        V$BUFFER_POOL

这一视图显示了当前实例中所有buffer cache类型的缓冲池的信息。它的结构如下：

字段	数据类型	描述
ID	NUMBER	缓冲池ID，和上面视图描述相同。
NAME	VARCHAR2(20)	缓冲池名称
BLOCK_SIZE	NUMBER	缓冲池块尺寸（字节为单位）
RESIZE_STATE	VARCHAR2(10)	缓冲池当前(重置尺寸的)状态。 STATIC：没有被正在调整大小 ALLOCATING：（内存管理模块（KSM））正在分配内存空间给缓冲池（不能被用户取消） ACTIVATING：正在创建新的缓存块（不能被用户取消）【即服务器进程用新的缓存块来填充从磁盘读取的block的内容】 SHRINKING：正在删除缓存块（能被用户取消。如何取消?）
CURRENT_SIZE	NUMBER	缓冲池大小（M为单位）
BUFFERS	NUMBER	当前缓存块数
TARGET_SIZE	NUMBER	如果正在调整缓冲池大小（即状态不为STATIC），这记录了调整后的大小（M为单位）。如果状态为STATIC，这个值和当前大小值相同。
TARGET_BUFFERS	NUMBER	如果正在调整缓冲池大小（即状态不为STATIC），这记录了调整后的缓存块数。否则，这个值和当前缓存块数相同。
PREV_SIZE	NUMBER	前一次调整的缓冲池大小。如果从来没有调整过，则为0。
PREV_BUFFERS	NUMBER	前一次调整的缓存块数。如果从来没有调整过，则为0。
LO_BNUM	NUMBER	9i后已经废弃字段
HI_BNUM	NUMBER	9i后已经废弃字段
LO_SETID	NUMBER	9i后已经废弃字段
HI_SETID	NUMBER	9i后已经废弃字段
SET_COUNT	NUMBER	9i后已经废弃字段

注释：

当有新的对象需要请求分配buffer时，会通过内存管理模块（KSM）请求分配空闲的或者可重用的buffer。

当某种buffer cache的空间不足且此时有新的对象需要请求分配buffer时，内存管理模块（KSM）就会分配新的内存空间给该缓冲池。

分配的空间单位为graule还是实际需要大小，有一个参数控制，具体忘了是叫啥？？core Oracle

从该视图可知，buffer cache的大小是会动态调整的，变大或变小。

·        v$buffer_pool_statistics

V$BUFFER_POOL_STATISTICS视图记录了所有缓冲池的统计数据。它的结构如下：

字段	数据类型	描述
ID	NUMBER	缓冲池ID，和上面视图描述相同。
NAME	VARCHAR2(20)	缓冲池名称
SET_MSIZE	NUMBER	缓冲池中缓存块的最大数
CNUM_REPL	NUMBER	在置换列表（即主LRU链表）中的缓存块数
CNUM_WRITE	NUMBER	在写列表中的缓存块数
CNUM_SET	NUMBER	当前的缓存块数
BUF_GOT	NUMBER	读取过的缓存块数
SUM_WRITE	NUMBER	被写过的缓存块数
SUM_SCAN	NUMBER	被扫描过的缓存块数
FREE_BUFFER_WAIT//等待事件	NUMBER	等待空闲块统计数
WRITE_COMPLETE_WAIT	NUMBER	等待完成写统计数
BUFFER_BUSY_WAIT	NUMBER	缓存块正忙（正在被使用）等待统计数
FREE_BUFFER_INSPECTED	NUMBER	确认了的空闲缓存块数（即可用的）
DIRTY_BUFFERS_INSPECTED	NUMBER	确认了的脏缓存块数
DB_BLOCK_CHANGE	NUMBER	被修改过的数据块数
DB_BLOCK_GETS	NUMBER	读取过的数据块数
CONSISTENT_GETS	NUMBER	一致性读统计数
PHYSICAL_READS	NUMBER	物理读统计数
PHYSICAL_WRITES	NUMBER	物理写统计数

查看当前的Buffer Cache命中率：

SQL> select 1-(physical_reads)/(consistent_gets+db_block_gets)

  2  from v$buffer_pool_statistics;

1-(PHYSICAL_READS)/(CONSISTENT

------------------------------

             0.967658520581074

SQL>

·        v$bh

这一视图在深入定位缓冲区问题时很有用。它记录了缓冲区中所有数据块对象。粒度非常细。这个视图最初的目的是用于OPS（Oracle Parallel Server Oracle平行服务器，9i后称为RAC）的，是用于保证RAC中各个节点的数据一致性的。但是，我们可以通过它来查询Buffer Cache的使用情况，找出大量消耗（占用）了Buffer Cache（里的buffer的个数）的数据库对象。下面的语句就可以完成这一工作：

SQL> column c0 heading 'Owner'                     format a15

SQL> column c1 heading 'Object|Name'               format a30

SQL> column c2 heading 'Number|of|Buffers' //该数据库对象使用了的buffer的个数        format 999,999

SQL> column c3 heading 'Percentage|ofData|Buffer' //该数据库对象使用了的buffer的个数与buffer cache里总
buffer的个数的百分比    format 999,999,999

SQL> select

  2     owner                        c0,

  3     object_name                  c1,

  4     count(1)                     c2,

  5     (count(1)/(select count(*) from v$bh)) *100  c3

  6  from

  7     dba_objects o,

  8     v$bh        bh

  9  where

 10     o.object_id  = bh.objd

 11  and

 12     o.owner not in ('SYS','SYSTEM')

 13  group by

 14     owner,

 15     object_name

 16  order by

 17     count(1) desc

 18  ;

C0              C1                                     C2         C3

--------------- ------------------------------ ---------- ----------

PLSQLDEV        STANDARD_CITY                  17290      72.5860621

DBOWNER         MSG_LOG                        2          0.00839630

DBOWNER         COUNTRY_PK                     1          0.00419815

DBOWNER         PARAMETER                      1          0.00419815

DBOWNER         PARAMETER_PK                   1          0.00419815

DBOWNER         MSG_LOG_IDX1                   1          0.00419815

6 rows selected

SQL>

 

更重要的是，这个视图记录的粒度非常细，一条记录对应了一个数据块。这对于我们做内存问题分析或分析Oracle行为时很有帮助。

下面是这个视图的结构：

字段	数据类型	说明
FILE#	NUMBER	缓存块对应的数据块所在的数据文件号。可以通过视图DBA_DATA_FILES或V$DBFILES查询
BLOCK#	NUMBER	缓存块对应的数据块编号
CLASS#	NUMBER	分类编号
STATUS	VARCHAR2(1)	缓存块的状态 FREE：空闲，没有被使用 XCUR：排斥（正在被使用） SCUR：可被共享 CR：一致性读 READ：正在从磁盘读入 MREC：处于从存储介质恢复状态 IREC：处于实例恢复状态
XNC	NUMBER	缓存块上由于和其他实例争用导致的PCM（Parallel Cache Management并行缓存管理）x to null锁的数量。这一字段已经被废弃。
LOCK_ELEMENT_ADDR	RAW(4 | 8)	缓存块上PCM锁的地址。如果多个缓存块的PCM锁地址相同，说明他们被同一锁锁住。
LOCK_ELEMENT_NAME	NUMBER	缓存块上PCM锁的地址。如果多个缓存块的PCM锁地址相同，说明他们被同一锁锁住。
LOCK_ELEMENT_CLASS	NUMBER	缓存块上PCM锁的地址。如果多个缓存块的PCM锁地址相同，说明他们被同一锁锁住。
FORCED_READS	NUMBER	由于其他实例的PCM锁锁住了该缓存块，导致当前实例尝试重新请求读该缓冲块的次数。
FORCED_WRITES	NUMBER	由于其他实例的PCM锁锁住了该缓存块，导致当前实例尝试重新请求写该缓冲块的次数。
DIRTY	VARCHAR2(1)	脏标志：Y – 块被修改过，是脏块；N – 不是脏块
TEMP	VARCHAR2(1)	是否为临时块：Y – 是；N – 否。
PING	VARCHAR2(1)	是否被ping住：Y – 是；N – 否。
STALE	VARCHAR2(1)	是否是陈旧块：Y – 是；N – 否。
DIRECT	VARCHAR2(1)	是否为直接读写块：Y – 是；N – 否。
NEW	VARCHAR2(1)	字段被废弃，始终为N
OBJD	NUMBER	数据块所属对象的对象标号，可以查询dba_objects
TS#	NUMBER	数据块所在的表空间号，可以查询v$tablespaces