Oracle-L: Buffer Pool Testing

From: Jay Hostetter <jhostetter_at_decommunications.com>
Date: Tue, 31 Dec 2002 10:48:54 -0800
Message-ID: <F001.00524D22.20021231104854@fatcity.com>

I'm spending some time today experimenting with buffer pools in 8.1.7. I have two tables that I have assigned to the RECYCLE pool. I have been running various queries that perform full table scans, then checking the buffers to see what gets aged out. During my testing, it seems like the first blocks to get into the RECYCLE buffer pool will stay there. The following two tables are assigned to the RECYCLE pool. No other segments are assigned to it:

WORK_ORDER_STEP - 428 blocks of data
ALRA_TRANSACTION_HISTORY - 14152 blocks of data

The RECYCLE pool has 1000 blocks.

I startup the database, query the WORK_ORDER_STEP table (1 time), then run multiple queries against the ALRA_TRANSACTION_HISTORY table (6 times), I see the following in the buffers (the source for this query is at the end of my email):

BP_NAME              OBJ_OWNER       NAME                               BLOCKS MAX_TOUCH MIN_TOUCH AVG_TOUCH


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

RECYCLE              BIS             ALRA_TRANSACTION_HISTORY              569        14         0       .02
RECYCLE              WRKORD          WORK_ORDER_STEP                       431         1         0       .00

If I startup the database, query the ALRA_TRANSACTION_HISTORY table (1 time), then run multiple queries against the WORK_ORDER_STEP table (6 queries), I get these results:

First query - 1000 blocks are used as expected

BP_NAME              OBJ_OWNER       NAME                               BLOCKS MAX_TOUCH MIN_TOUCH AVG_TOUCH


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

RECYCLE              BIS             ALRA_TRANSACTION_HISTORY             1000         2         0       .00


After querying the second table multiple times, I expected more than just 9 blocks to be given up.  I expected more like 431 blocks.
BP_NAME              OBJ_OWNER       NAME                               BLOCKS MAX_TOUCH MIN_TOUCH AVG_TOUCH


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

RECYCLE              BIS             ALRA_TRANSACTION_HISTORY              991         2         0       .00
RECYCLE              WRKORD          WORK_ORDER_STEP                         9         4         0       .44

I expected the blocks (from the table that was queried first) to be aged out as I queried the second table (over and over). This does not occur. Am I hitting a bug or just misunderstanding the buffer management algorithms? ALRA_TRANSACTION_HISTORY blocks should be LRU as I hit the WORK_ORDER_STEP table over and over.

Thanks,
Jay

Here is the query that I use to check what is in the buffer pools: select bpd.bp_name,

       u.name   obj_owner,
       o.name, 
       count(*) BLOCKS,
       max(tch) max_touch,
       min(tch) min_touch,
       avg(tch) avg_touch 
 from x$kcbwds  wds, /* working data sets */
      x$kcbwbpd bpd, /* buffer pools */
      x$bh bh,       /* buffer headers */
      obj$ o,        /* objects */
      user$ u
where wds.set_id >= bpd.bp_lo_sid

  and wds.set_id <= bpd.bp_hi_sid
  and bpd.bp_size != 0
  and bh.indx between wds.start_buf# and wds.end_buf#   and o.dataobj# = bh.obj
  and bh.state !=0
  and o.owner# !=0 /* exclude sys */
  and o.owner# = u.user#
  group by bpd.bp_name, u.name, o.name
  order by bpd.bp_name, u.name, o.name
;

**DISCLAIMER
This e-mail message and any files transmitted with it are intended for the use of the individual or entity to which they are addressed and may contain information that is privileged, proprietary and confidential. If you are not the intended recipient, you may not use, copy or disclose to anyone the message or any information contained in the message. If you have received this communication in error, please notify the sender and delete this e-mail message. The contents do not represent the opinion of D&E except to the extent that it relates to their official business.

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Jay Hostetter
  INET: jhostetter_at_decommunications.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

Received on Tue Dec 31 2002 - 12:48:54 CST