Understanding the Oracle Database Technical Architecture in Detail

<<Back to DB Administration Main Page

Understanding the Oracle Database Technical Architecture in Detail

Since the architecture of oracle database is complicated and difficult to understand for a beginner. I will divide the article in multiple posts. I will try my best to explain you, how oracle database functions.
You can leave me your questions/suggestion in the comment box below.
A high level architecture of non multitenant oracle  database is explained here
Database Buffer Cache in Details:

• The database buffer cache, also called the buffer cache, is the memory area in the System Global Area (SGA) that stores copies of data blocks read from data files.
• A buffer is a database block-sized chunk of memory.
• The default size of a database block is 8K and can not be changed once the database is created.
• Supported non default block sizes are 2k, 4k, 16k and 32k.
• Each buffer has an address called a Database Buffer Address (DBA)
•  Buffers in database buffer cache is maintained by a touch based LRU algorithm

The goals of the buffer cache is

• To optimize physical I/O and to keep frequently accessed blocks in the buffer cache and write infrequently accessed blocks to disk.
• Provides fast access to frequently access data blocks.
• Provides mechanism for RAC Cache Fusion

Buffer States
Each buffer in the database buffer cache has a state
Unused: The buffer is available for use because it has never been used or is currently unused
Clean: This buffer was used earlier and now contains a read-consistent version of a block as of a point in time. The block contains data but is "clean" so it does not need to be check pointed. The database can pin the block and reuse it
Dirty: The buffer contain modified data that has not yet been written to disk. The database must flush the buffer content on the disk before overwriting this buffer.
You can check the status a particular buffer using v$bh and x$bh views
List the free and Clean buffers
SQL> select * from v$bh where status in ('free','cr') and rownum<10
SQL>select TS#,FILE#, BLOCK#,CLASS#,STATUS,FLASH_CACHE,CELL_FLASH_CACHE from v$bh where status in ('free','cr') and rownum<10
       TS#      FILE#     BLOCK#     CLASS# STATUS     FLASH_CACHE     CELL_FLASH_CACH
---------- ---------- ---------- ---------- ---------- --------------- ---------------
         1          9       9500          1 cr         DEFAULT         DEFAULT
         1          9      17718          1 cr        DEFAULT         DEFAULT
         1          9       9068          1 cr         DEFAULT         DEFAULT
         1          9       9911          1 cr         DEFAULT         DEFAULT
         1          9       9534          1 cr         DEFAULT         DEFAULT
         1          3      29807          1 cr         DEFAULT         DEFAULT
         1          3      21534          1 cr         DEFAULT         DEFAULT
         1          9      17697          1 cr         DEFAULT         DEFAULT
         0          8      34199          1 cr         DEFAULT         DEFAULT
9 rows selected.
Find the buffer detail for a particular block#
SQL> select * from x$bh where dbablk='xxxxx'
SQL> select ADDR,HLADDR,BLSIZ,NXT_HASH,PRV_HASH,NXT_REPL,PRV_REPL,LRU_FLAG,TS#,FILE#,DBARFIL,DBABLK,CLASS,STATE from x$bh where dbablk='9500';
ADDR             HLADDR                BLSIZ NXT_HASH         PRV_HASH         NXT_REPL         PRV_REPL           LRU_FLAG        TS#      FILE#    DBARFIL     DBABLK      CLASS      STATE
---------------- ---------------- ---------- ---------------- ---------------- ---------------- ---------------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
00007FD900FA3980 0000000063CBFB88       8192 0000000075F6E0A8 0000000063CC10C0 000000006EFBF5A8 000000006CFD2DD8          8          1          9          4       9500          1          1
00007FD900FA3800 0000000063CBFB88       8192 0000000063CC10C0 000000006FF7C748 000000007CFF95C8 000000007AFD2298          8          1          9          4       9500          1          3
List the Dirty Buffers
SQL> select * from v$bh where dirty='Y' and rownum<10
Buffer Modes
When a client requests data, Oracle Database retrieves buffers from the database buffer cache in either current mode or consistent mode.
Current mode: The retrieval of the version of a data block as it exists right now in the buffer cache
Only one version of a block exists in current mode at any one time.
Consistent mode : Is a retrieval of a read-consistent version of a block. It may uses undo data to construct CR copy of a buffer.

• Consistent images can’t be further modified.
• Multiple consistent versions of the one dirty buffer may exist.

Buffer Pool: A buffer pool is collection of buffers
Multiple sub-buffers pools can be configured in database buffer cache as shown in the pic above. You can configure the individual buffer pools using corresponding parameter

• Default Buffer Cache <=DB_CACHE_SIZE
• Keep cache <=DB_KEEP_CACHE_SIZE
• Recycle cache <=DB_RECYCLE_CACHE_SIZE
• Nk(non-default) buffer caches  <=DB_nK_CACHE_SIZE (where nK = 2,4,8,16,32K)
• Flash buffer cache (in case Smart Flash cache is configured) <=DB_FLASH_CACHE_SIZE

Buffer Cache uses default block size as the minimum unit of IO and is configured at the time of database creation itself. The value can be verified from  DB_BLOCK_SIZE parameter.

How Oracle Allocates Buffers
Oracle allocates memory to each buffer pools in the form or Granules.
You can find the size of granule using below query
SQL> select bytes from v$sgainfo where name = 'Granule Size';
     BYTES
----------
  16777216
Below Query demonstrates you the Granule allocation to the buffer
SQL> select ge.grantype, ct.component, ge.granprev, ge.grannum, ge.grannext from x$ksmge ge, x$kmgsct ct where ct.grantype = ge.grantype order by ge.grantype;
  GRANTYPE COMPONENT                        GRANPREV    GRANNUM   GRANNEXT
---------- ------------------------------ ---------- ---------- ----------
         1 shared pool                             0          1          2
         1 shared pool                            58         59         48
.........................................................................
.........................................................................
         2 large pool                             34         35          0
         2 large pool                              0         34         35
.........................................................................
.........................................................................
         3 java pool                               0         36          0
.........................................................................
.........................................................................
         8 DEFAULT buffer cache                   32         33         40
         8 DEFAULT buffer cache                   31         32         33
         8 DEFAULT buffer cache                    0         11         12
         8 DEFAULT buffer cache                   29         30         31
         8 DEFAULT buffer cache                   30         31         32
         8 DEFAULT buffer cache                   11         12         13
.........................................................................
.........................................................................
        16 Shared IO Pool                          0         52         53
        16 Shared IO Pool                         53         51          0
        16 Shared IO Pool                         52         53         51
.........................................................................
.........................................................................

Each buffer cache granule consists mainly of three parts – the granule header, an array of buffer headers and an array of buffers that are used for holding copies of the data blocks

Buffer Cache Implementation
Buffer Cache is maintained in the form of a Hash table comprising of Hash Buckets
Hash buckets are structures that maintain the list of data buffer headers , grouped by relative Data Block Address(DBA) and tablespace number
Hash buckets are linked with Hash Chains
Hash value of the buffers is calculated from the data block address and the block class to it belongs
Number of hash buckets ( buffer chains ) are internally controlled by _db_block_hash_buckets hidden parameter which is automatically calculated from size of Database buffer cache.
Can be queried from X$BH table

Buffer replacement

• Buffer Cache is a circular cache. To keep the unused buffers replaced with the used buffers LRU algorithm is followed.
• LRU chain has a mid-point dividing it into HOT and COLD end. Default division point is 50% and controlled by hidden _db_percent_hot_default parameter.
• A buffer is either inserted into the mid point of the chain or MRU end (ie hot end)
• A hidden parameter _small_table_threshold defines threshold for a buffer where should it be inserted
• If buffer count is larger than _small_table_threshold buffers will be linked to the Mid point LRU end else it will be in the MRU end.
• Movement of buffer from HOT end to COLD end and vice versa and eventually eviction from Cache is controlled by touch count

Touch Count

The database measures the frequency of access of buffers on the LRU list using a touch count. When a buffer is pinned, the database determines when its touch count was last incremented. If the count was incremented over three seconds ago, then the count is incremented; otherwise, the count stays the same. If a buffer is on the cold end of the LRU, but its touch count is high, then the buffer moves to the hot end. If the touch count is low, then the buffer ages out of the cache.

You can find the touch count of a given buffer from X$BH.TCH column
SQL> select max (TCH),min(TCH),ADDR,HLADDR,BLSIZ,NXT_HASH,PRV_HASH,NXT_REPL,PRV_REPL,LRU_FLAG,DBARFIL,DBABLK,CLASS,STATE from  X$BH where rownum < 10 group by ADDR,HLADDR,BLSIZ,NXT_HASH,PRV_HASH,NXT_REPL,PRV_REPL,LRU_FLAG,DBARFIL,DBABLK,CLASS,STATE

Buffer Lookup in The Buffer Cache
When a client process requests a buffer, the server process searches the buffer cache for the buffer.

• The hash value is calculated using DBA (data block address and file#)
• Required Hash Buckets are located for the calculated hash value
• Using Cache Buffer Chain(CBC) Latch, Hash Chains within the Hash Buckets are scanned
• If the DBA is found (Its a cash hit) the result is returned to the user directly from buffer cache
• If the DBA is not found ( Its a cache miss). "The search of buffer hash chain to locate a block in the cache is controlled by _db_block_max_scan_pct hidden parameter (default value for which is 40%)". The Server process identifies a free cache using Cache Buffer LRU Chain Latch
• Server process then Load the block from the disk in the free buffer
• The result is then returned to client by Performing a logical read of the buffer that was read into memory 

Database Buffer Cache and Full Table Scans
By default, when buffers must be read from disk, the database inserts the buffers into the middle of the LRU list. In this way, hot blocks can remain in the cache so that they do not need to be read from disk again. In case of  full table scan, if the table is large, it  could clean out the buffer cache, preventing the database from maintaining a cache of frequently accessed blocks. To prevent this problem for large tables, the database typically uses a direct path read,  which loads blocks directly into the PGA and bypasses the SGA altogether,

Dirty Buffer Write to The Disk
The database writer (DBW) process periodically writes cold, dirty buffers to disk. DBW writes buffers in the following circumstances

•  A server process cannot find clean buffers for reading new blocks into the database buffer cache.
•  At DB checkpoint
•  Tablespaces taken to read only or offline
• At Redo Log switch
• Every 3 seconds

The server  processes signal DBW to write the dirty buffer to the disk.
The database uses the LRU to determine which dirty buffers to write
The database moves the dirty buffer from the LRU to a write queue (also known as write list).
DBW writes buffers from write queue to disk, using multiblock writes if possible.

How Buffer Cache Works: Understanding with an Example

So far we learned, How database buffer cache is organized in the memory, How touch count keeps the most frequently used blocks in the buffer, How Sub buffers can be configured in buffer cache etc.
Now I will walk you through all these stuffs with an example.
For demonstration purpose I have created a table "TEST" and populated it with some data
SQL>create table test (id number, name varchar (20));
begin
for i in 1..10 loop
insert into test values (i,'TEST' ||i);
end loop;
commit;
end;
/
lets quickly find the important information for the table TEST which we need throughout this exercise
Find the file#,block# and DBA
SQL> select
 rownum,
  dbms_rowid.rowid_relative_fno(rowid) rfile#,
  dbms_rowid.rowid_block_number(rowid) block#,
  DBMS_ROWID.ROWID_OBJECT(ROWID) as OBJECT_ID
from TEST;
    ROWNUM     RFILE#     BLOCK#  OBJECT_ID
---------- ---------- ---------- ----------
         1         17        135      77960
         2         17        135      77960
         3         17        135      77960
         4         17        135      77960
         5         17        135      77960
         6         17        135      77960
         7         17        135      77960
         8         17        135      77960
         9         17        135      77960
        10         17        135      77960
10 rows selected.
SQL> select OWNER,SEGMENT_NAME,HEADER_FILE,HEADER_BLOCK,BYTES,BLOCKS,EXTENTS,BUFFER_POOL  from cdb_segments where OWNER='TEST' and SEGMENT_NAME='TEST';
OWNER      SEGMENT_NA HEADER_FILE HEADER_BLOCK      BYTES     BLOCKS    EXTENTS BUFFER_POOL
---------- ---------- ----------- ------------ ---------- ---------- ---------- ---------------
TEST       TEST                17          130      65536          8          1 DEFAULT

All the rows of my table TEST table is stored in a single block Block#135 of datafile# 17. Only one extent (8 database blocks) is allocated and  HEADER_BLOCK is 130
Lets quickly find out the DBA (Database block address) for Block#135 in file#17
SQL> select dbms_utility.make_data_block_address(17,135) from dual;
DBMS_UTILITY.MAKE_DATA_BLOCK_ADDRESS(17,135)
--------------------------------------------
                                    71303303

Gather the stats for the table to make the information available for optimizer
SQL> exec DBMS_STATS.GATHER_TABLE_STATS('TEST', 'TEST');
Note: I am working in my Lab Environment that's why its safe for me to restart the database
Restart the database.

Now let us see if the block for TEST table is buffered.
Query 1 

SQL> select HLADDR, decode(STATE,0,'free',1,'xcur',2,'scur',3,'cr', 4,'read',5,'mrec',6,'irec',7,'write',8,'pi', 9,
                       'memory',10,'mwrite',11,'donated', 12,'protected',  13,'securefile', 14,'siop',15,'recckpt', 16,
                       'flashfree',  17, 'flashcur', 18, 'flashna') as STATE, PRV_HASH, NXT_HASH,
                       BA, DBARFIL, DBABLK
            from X$BH where OBJ = 77960 and DBABLK = 135;       
no rows selected
HLADDR = Address of the latch, that protects the hash bucket
STATE = State of the block like xcur (current version), cr (consistent version, which contains an older version of the block and is available for consistent reads)
PRV_HASH = Address of the previously attached buffer header in the double linked list
NXT_HASH = Address of the following attached buffer header in the double linked list
BA = Address of data block buffer
DBARFIL => Relative data file number
DBABLK=> Database block number
Query2
select file#, block#,
decode(class#,
    1,'data block',
    2,'sort block',
    3,'save undo block',
    4,'segment header',
    5,'save undo header',
    6,'free list',
    7,'extent map',
    8,'1st level bmb',
    9,'2nd level bmb',
    10,'3rd level bmb',
    11,'bitmap block',
    12,'bitmap index block',
    13,'file header block',
    14,'unused',
    15,'system undo header',
    16,'system undo block',
    17,'undo header',
    18,'undo block')
        class_type,
    status
from v$bh
where objd = 77960
order by 1,2,3
/
no rows selected
file#=> Datafile number
block#=> block number
class#=> Block Type
Note: The object is not in buffer cache
Let us read the content of the table
SQL> set time on;
SQL> set timing on;
SQL>select * from test;
11:14:26 SQL> select * from test;
        ID NAME
---------- --------------------
         1 TEST1
         2 TEST2
         3 TEST3
         4 TEST4
         5 TEST5
         6 TEST6
         7 TEST7
         8 TEST8
         9 TEST9
        10 TEST10
10 rows selected.
Elapsed: 00:00:00.02
Let's run query1 and query2 again.
Query1 Output
HLADDR           STATE      PRV_HASH         NXT_HASH         BA                  DBARFIL     DBABLK
---------------- ---------- ---------------- ---------------- ---------------- ---------- ----------
0000000063D334F0 xcur       0000000063D350F0 0000000063D350F0 000000007D104000         17        135
Query2 Output
     FILE#     BLOCK# CLASS_TYPE         STATUS
---------- ---------- ------------------ ----------
        17        130 segment header     xcur
        17        131 data block         xcur
        17        132 data block         xcur
        17        133 data block         xcur
        17        134 data block         xcur
        17        135 data block       xcur
6 rows selected.

As we can see the database block is now cached in buffer cache and from the output of query1 you can see, how the buffers are organized in memory
Lets us run the select statement again.
11:20:07 SQL> select * from test;
        ID NAME
---------- --------------------
         1 TEST1
         2 TEST2
         3 TEST3
         4 TEST4
         5 TEST5
         6 TEST6
         7 TEST7
         8 TEST8
         9 TEST9
        10 TEST10
10 rows selected.
Elapsed: 00:00:00.00
And as you can see the query executed in 0 seconds much faster than previous execution because the database found the block in buffer cache itself.
Lets examine the latch from query1 output.
SQL> select NAME from V$LATCH_CHILDREN where ADDR = '0000000063D334F0';
NAME
----------------------------------------------------------------
cache buffers chains
As you can see its "cache buffers chains" latch which is protecting the hash buckets
SQL> select count(*) from V$LATCH_CHILDREN where NAME = 'cache buffers chains';
  COUNT(*)
----------
      4096
The total number of these latches are 4096  
From the below query you can verify the Hash bbuckets and hash latches configuration in your database
SQL> select
  ksppinm,
  ksppstvl,
  ksppdesc
from
  x$ksppi a,
  x$ksppsv b
where
  a.indx=b.indx and
  substr(ksppinm,1,1) = '_'
 and a.ksppinm in ('_db_block_hash_buckets','_db_block_hash_latches');
 KSPPINM                        KSPPSTVL   KSPPDESC
------------------------------ ---------- --------------------------------------------------
_db_block_hash_buckets         131072     Number of database block hash buckets
_db_block_hash_latches         4096       Number of database block hash latches
In my environment I got 131072 hash buckets and 4096 hash latches. If we divide _db_block_hash_buckets/_db_block_hash_latches its 32
which means each hash_latches are protecting exactly 32 hash_buckets.
Note: oracle automatically calculates these values based on the buffer pool size. This demonstration is just for your understanding and education purpose.
Let's test the buffer cache behavior for DML.
Remember the output of query1 and query2
HLADDR           STATE      PRV_HASH         NXT_HASH         BA                  DBARFIL     DBABLK
---------------- ---------- ---------------- ---------------- ---------------- ---------- ----------
0000000063D334F0 xcur       0000000063D350F0 0000000063D350F0 000000007D104000         17        135

     FILE#     BLOCK# CLASS_TYPE         STATUS
---------- ---------- ------------------ ----------
        17        130 segment header     xcur
        17        131 data block         xcur
        17        132 data block         xcur
        17        133 data block         xcur
        17        134 data block         xcur       
        17        135 data block         xcur
6 rows selected.
SQL> update test set  id=11 where id=1;
1 row updated.
HLADDR           STATE      PRV_HASH         NXT_HASH         BA                  DBARFIL     DBABLK
---------------- ---------- ---------------- ---------------- ---------------- ---------- ----------
0000000063D334F0 xcur       0000000063D350F0 000000007DF59630 00000000791FC000         17        1350000000063D334F0 cr         0000000079F64490 0000000063D350F0 000000007D104000         17        135

    FILE#     BLOCK# CLASS_TYPE         STATUS
---------- ---------- ------------------ ----------
        17        130 segment header     xcur
        17        131 data block         xcur
        17        132 data block         xcur
        17        133 data block         xcur
        17        134 data block         xcur
        17        135 data block         xcur
        17        135 data block         cr

SQL> update test set  id=12  where id=2;
1 row updated.

HLADDR           STATE      PRV_HASH         NXT_HASH         BA                  DBARFIL     DBABLK
---------------- ---------- ---------------- ---------------- ---------------- ---------- ----------
0000000063D334F0 xcur       0000000063D350F0 0000000079F64490 00000000791FA000         17        1350000000063D334F0 cr         0000000079F64328 000000007DF59630 00000000791FC000         17        135
0000000063D334F0 cr         0000000079F64490 0000000063D350F0 000000007D104000         17        135

    FILE#     BLOCK# CLASS_TYPE         STATUS
---------- ---------- ------------------ ----------
        17        130 segment header     xcur
        17        131 data block         xcur
        17        132 data block         xcur
        17        133 data block         xcur
        17        134 data block         xcur
        17        135 data block         cr       
        17        135 data block         xcur       
        17        135 data block         cr

SQL>  update test set  id=13  where id=3;
1 row updated.
SQL>  update test set  id=14  where id=4;
1 row updated.
SQL>  update test set  id=15 where id=5;
1 row updated.

HLADDR           STATE      PRV_HASH         NXT_HASH         BA                  DBARFIL     DBABLK
---------------- ---------- ---------------- ---------------- ---------------- ---------- ----------
0000000063D334F0 xcur       0000000063D350F0 0000000079F63C20 000000007D104000         17        1350000000063D334F0 cr         000000007DF59630 0000000079F63D88 00000000791F0000         17        135
0000000063D334F0 cr         0000000079F63C20 0000000079F63EF0 00000000791F2000         17        135
0000000063D334F0 cr         0000000079F63D88 0000000079F64328 00000000791F4000         17        135
0000000063D334F0 cr         0000000079F63EF0 0000000079F64490 00000000791FA000         17        135
0000000063D334F0 cr         0000000079F64328 0000000063D350F0 00000000791FC000         17        135
6 rows selected.

     FILE#     BLOCK# CLASS_TYPE         STATUS
---------- ---------- ------------------ ----------
        17        130 segment header     xcur
        17        131 data block         xcur
        17        132 data block         xcur
        17        133 data block         xcur
        17        134 data block         xcur
        17        135 data block         cr
        17        135 data block         cr
        17        135 data block         cr
        17        135 data block         cr       
        17        135 data block         xcur       
        17        135 data block         cr

Notice, every time you perform an update on the database block oracle just copies the buffer and performs the update in new buffer keeping the old buffer in cr (consistent read) state.
The limit of creating  the CR buffer is controlled by _db_block_max_cr_dba parameter. The value for which in my environment is 6 and oracle stopped creating the CR copy as soon as I crossed this limit.
The CR copies of the buffer is used to serve the select statement. When a select statement is issued for an object for which an update is performed, oracle compares the select statement scn with the current buffer scn for that block, if the scn matches oracle returns the block, if block SCN is higher than the query scn then oracle traverse the hash chain to find an appropriate CR copy of the block and returns it, if one found, else oracle simply clones the block with status=xcur and applies the undo, makes a CR copy and returns it to the user.
To find out how the buffers headers are organized in a Chain and confirm all the copies of a block belongs to the same chain, lets create level 4 dump of the buffer cache 

SQL> oradebug setmypid
SQL> oradebug dump buffers 4;
Lets examine the created trace file for block#77960
CHAIN: 27534 LOC: 0x63d350f0 HEAD: [0x79f64490,0x79f63ef0]
    BH (0x79f643e0) file#: 17 rdba: 0x04400087 (17/135) class: 1 ba: 0x791fc000
      set: 5 pool: 3 bsz: 8192 bsi: 0 sflg: 0 pwc: 0,0
      dbwrid: 0 obj: 77960 objn: 77960 tsn: [3/4] afn: 17 hint: f
      hash: [0x7df59630,0x63d350f0] lru: [0x79f64090,0x79f63af0]
      lru-flags: debug_dump
      ckptq: [NULL] fileq: [NULL]
      objq: [0x7df597f8,0x8710c590] objaq: [0x7df59808,0x8710c580]
      st: XCURRENT md: NULL fpin: 'kdswh01: kdstgr' fscn: 0x9d04e8 tch: 5
      flags: block_written_once
      LRBA: [0x0.0.0] LSCN: [0x0] HSCN: [0x9d2d2c] HSUB: [7]
      Printing buffer operation history (latest change first):
      cnt: 12
      01. sid:09 L192:kcbbic2:bic:FBD         02. sid:09 L191:kcbbic2:bic:FBW
      03. sid:09 L602:bic1_int:bis:FWC        04. sid:09 L822:bic1_int:ent:rtn
      05. sid:09 L832:oswmqbg1:clr:WRT        06. sid:09 L930:kubc:sw:mq
      07. sid:09 L913:bxsv:sw:objq            08. sid:09 L608:bxsv:bis:FBW
      09. sid:09 L464:chg1_mn:bic:FMS         10. sid:09 L778:chg1_mn:bis:FMS
      11. sid:09 L353:gcur:set:MEXCL          12. sid:09 L464:chg1_mn:bic:FMS
      13. sid:09 L778:chg1_mn:bis:FMS         14. sid:09 L353:gcur:set:MEXCL
      15. sid:09 L464:chg1_mn:bic:FMS         16. sid:09 L778:chg1_mn:bis:FMS
    BH (0x7df59580) file#: 17 rdba: 0x04400087 (17/135) class: 1 ba: 0x7d104000
      set: 5 pool: 3 bsz: 8192 bsi: 0 sflg: 0 pwc: 0,0
      dbwrid: 0 obj: 77960 objn: 77960 tsn: [3/4] afn: 17 hint: f
      hash: [0x79f63c20,0x79f64490] lru: [0x78fb3ed8,0x79f63c58]
      lru-flags: debug_dump hot_buffer
      ckptq: [NULL] fileq: [NULL]
      objq: [NULL] objaq: [NULL]
      st: CR md: NULL fpin: 'kdswh01: kdstgr' fscn: 0x0 tch: 0 lfb: 252
      cr: [scn: 0x9d235f],[xid: 0xfffe.ffff.0],[uba: 0x0.0.0],[cls: 0x9d235f],[sfl: 0x1],[lc: 0x9d229f]
      flags: block_written_once
      Printing buffer operation history (latest change first):
      cnt: 10
      01. sid:09 L940:z_sw_cur:sw:cq          02. sid:09 L070:zswcu:ent:ob
      03. sid:09 L082:zcr:ret:TRU             04. sid:09 L192:kcbbic2:bic:FBD
      05. sid:09 L191:kcbbic2:bic:FBW         06. sid:09 L602:bic1_int:bis:FWC
      07. sid:09 L822:bic1_int:ent:rtn        08. sid:09 L832:oswmqbg1:clr:WRT
      09. sid:09 L930:kubc:sw:mq              10. sid:09 L913:bxsv:sw:objq
      11. sid:09 L608:bxsv:bis:FBW            12. sid:09 L607:bxsv:bis:FFW
      13. sid:09 L464:chg1_mn:bic:FMS         14. sid:09 L778:chg1_mn:bis:FMS
      15. sid:09 L116:swcur:set:EXCL          16. sid:09 L369:zswcu:set:MEXCL
    BH (0x79f63b70) file#: 17 rdba: 0x04400087 (17/135) class: 1 ba: 0x791f0000
      set: 5 pool: 3 bsz: 8192 bsi: 0 sflg: 0 pwc: 0,0
      dbwrid: 0 obj: 77960 objn: 77960 tsn: [3/4] afn: 17 hint: f
      hash: [0x79f63d88,0x7df59630] lru: [0x7df59668,0x79f63dc0]
      lru-flags: debug_dump hot_buffer
      ckptq: [NULL] fileq: [NULL]
      objq: [NULL] objaq: [NULL]
      st: CR md: NULL fpin: 'kdswh01: kdstgr' fscn: 0x0 tch: 0 lfb: 252
      cr: [scn: 0x9d229f],[xid: 0xfffe.ffff.0],[uba: 0x0.0.0],[cls: 0x9d229f],[sfl: 0x1],[lc: 0x9d228a]
      flags:
      Printing buffer operation history (latest change first):
      cnt: 6
      01. sid:09 L940:z_sw_cur:sw:cq          02. sid:09 L070:zswcu:ent:ob
      03. sid:09 L082:zcr:ret:TRU             04. sid:09 L464:chg1_mn:bic:FMS
      05. sid:09 L778:chg1_mn:bis:FMS         06. sid:09 L116:swcur:set:EXCL
      07. sid:09 L369:zswcu:set:MEXCL         08. sid:09 L071:zswcu:ent:nb
      09. sid:09 L122:zgb:set:st              10. sid:09 L810:zgb:bic:FEN
      11. sid:09 L896:z_mkfr:ulnk:objq        12. sid:09 L083:zgb:ent:fn
      13. sid:13 L144:zibmlt:mk:EXCL          14. sid:13 L710:zibmlt:bis:FBP
      15. sid:13 L085:zgm:ent:fn              16. sid:13 L122:zgb:set:st
    BH (0x79f63cd8) file#: 17 rdba: 0x04400087 (17/135) class: 1 ba: 0x791f2000
      set: 5 pool: 3 bsz: 8192 bsi: 0 sflg: 0 pwc: 0,0
      dbwrid: 0 obj: 77960 objn: 77960 tsn: [3/4] afn: 17 hint: f
      hash: [0x79f63ef0,0x79f63c20] lru: [0x79f63c58,0x79f63f28]
      lru-flags: debug_dump hot_buffer
      ckptq: [NULL] fileq: [NULL]
      objq: [NULL] objaq: [NULL]
      st: CR md: NULL fpin: 'kdswh01: kdstgr' fscn: 0x0 tch: 0 lfb: 252
      cr: [scn: 0x9d228a],[xid: 0xfffe.ffff.0],[uba: 0x0.0.0],[cls: 0x9d228a],[sfl: 0x1],[lc: 0x9d227d]
      flags:
      Printing buffer operation history (latest change first):
      cnt: 6
      01. sid:09 L940:z_sw_cur:sw:cq          02. sid:09 L070:zswcu:ent:ob
      03. sid:09 L082:zcr:ret:TRU             04. sid:09 L464:chg1_mn:bic:FMS
      05. sid:09 L778:chg1_mn:bis:FMS         06. sid:09 L116:swcur:set:EXCL
      07. sid:09 L369:zswcu:set:MEXCL         08. sid:09 L071:zswcu:ent:nb
      09. sid:09 L122:zgb:set:st              10. sid:09 L810:zgb:bic:FEN
      11. sid:09 L896:z_mkfr:ulnk:objq        12. sid:09 L083:zgb:ent:fn
      13. sid:13 L144:zibmlt:mk:EXCL          14. sid:13 L710:zibmlt:bis:FBP
      15. sid:13 L085:zgm:ent:fn              16. sid:13 L122:zgb:set:st
    BH (0x79f63e40) file#: 17 rdba: 0x04400087 (17/135) class: 1 ba: 0x791f4000
      set: 5 pool: 3 bsz: 8192 bsi: 0 sflg: 0 pwc: 0,0
      dbwrid: 0 obj: 77960 objn: 77960 tsn: [3/4] afn: 17 hint: f
      hash: [0x63d350f0,0x79f63d88] lru: [0x79f63dc0,0x7afa83d0]
      lru-flags: debug_dump hot_buffer
      ckptq: [NULL] fileq: [NULL]
      objq: [NULL] objaq: [NULL]
      st: CR md: NULL fpin: 'kdswh01: kdstgr' fscn: 0x0 tch: 0 lfb: 252
      cr: [scn: 0x9d227d],[xid: 0xfffe.ffff.0],[uba: 0x0.0.0],[cls: 0x9d227d],[sfl: 0x1],[lc: 0x9d226b]
      flags:
      Printing buffer operation history (latest change first):
      cnt: 6
      01. sid:09 L940:z_sw_cur:sw:cq          02. sid:09 L070:zswcu:ent:ob
      03. sid:09 L082:zcr:ret:TRU             04. sid:09 L464:chg1_mn:bic:FMS
      05. sid:09 L778:chg1_mn:bis:FMS         06. sid:09 L116:swcur:set:EXCL
      07. sid:09 L369:zswcu:set:MEXCL         08. sid:09 L071:zswcu:ent:nb
      09. sid:09 L122:zgb:set:st              10. sid:09 L810:zgb:bic:FEN
      11. sid:09 L896:z_mkfr:ulnk:objq        12. sid:09 L083:zgb:ent:fn
      13. sid:13 L144:zibmlt:mk:EXCL          14. sid:13 L710:zibmlt:bis:FBP
      15. sid:13 L085:zgm:ent:fn              16. sid:13 L122:zgb:set:st

......................................................

......................................................

Related Views

View Name	Description
V$SGA	Displays summary information about the system global area (SGA).
V$SGAINFO	Displays size information about the SGA, including the sizes of different SGA components, the granule size, and free memory.
V$SGASTAT	Displays detailed information about how memory is allocated within the shared pool, large pool, Java pool, and Streams pool.
V$PGASTAT	Displays PGA memory usage statistics as well as statistics about the automatic PGA memory manager when it is enabled (that is, when PGA_AGGREGATE_TARGET is set). Cumulative values in V$PGASTAT are accumulated since instance startup.
V$MEMORY_DYNAMIC_COMPONENTS	Displays information on the current size of all automatically tuned and static memory components, with the last operation (for example, grow or shrink) that occurred on each.
V$SGA_DYNAMIC_COMPONENTS	Displays the current sizes of all SGA components, and the last operation for each component.
V$SGA_DYNAMIC_FREE_MEMORY	Displays information about the amount of SGA memory available for future dynamic SGA resize operations.
V$MEMORY_CURRENT_RESIZE_OPS	Displays information about resize operations that are currently in progress. A resize operation is an enlargement or reduction of the SGA, the instance PGA, or a dynamic SGA component.
V$SGA_CURRENT_RESIZE_OPS	Displays information about dynamic SGA component resize operations that are currently in progress.
V$MEMORY_RESIZE_OPS	Displays information about the last 800 completed memory component resize operations, including automatic grow and shrink operations for SGA_TARGET and PGA_AGGREGATE_TARGET.
V$SGA_RESIZE_OPS	Displays information about the last 800 completed SGA component resize operations.
V$MEMORY_TARGET_ADVICE	Displays information that helps you tune MEMORY_TARGET if you enabled automatic memory management.
V$SGA_TARGET_ADVICE	Displays information that helps you tune SGA_TARGET.
V$PGA_TARGET_ADVICE	Displays information that helps you tune PGA_AGGREGATE_TARGET.
V$LATCH	shows aggregate latch statistics for both parent and child latches, grouped by latch name
V$LATCH_CHILDREN	contains statistics about child latches
V$LATCH_PARENT	displays statistics about parent latches
V$LATCHNAME	This view contains information about decoded latch names for the latches shown in V$LATCH
V$LATCHHOLDER	displays information about the current latch holders
V$LATCH_MISSES	This view contains statistics about missed attempts to acquire a latch
V$DLM_LATCH	displays statistics about DLM latch performance.