RE: KEEP creep

From: Steve Adams <steve.adams_at_ixora.com.au>
Date: Fri, 11 Aug 2000 05:21:07 +1000
Message-Id: <10585.114292@fatcity.com>

Hi Alex,

I presume that's a typo. It is CR blocks, not CR locks. Sorry if the previous message was a bit cryptic. I was about to go to bed, and I knew that Mark would still be at work and would appreciate a quick answer. I also knew that he would understand. Anyway, CR means consistent read. A CR block is a temporary copy of the current mode block that has been rolled back for the purposes of read consistency. The parameter setting causes CR blocks to be placed at the LRU end of the cache where they will be immediately reused once unpinned.

Regards,
Steve Adams

http://www.ixora.com.au/
http://www.oreilly.com/catalog/orinternals/
http://www.christianity.net.au/

-----Original Message-----

From: Alex Hillman [mailto:alex_hillman_at_physia.com] Sent: Friday, 11 August 2000 3:19
To: Multiple recipients of list ORACLE-L Subject: RE: KEEP creep

Could you elaborate a little bit please - what is CR locks, when they happen and what consequences of using this parameter. Alex Hillman
-----Original Message-----

From: Steve Adams [mailto:steve.adams_at_ixora.com.au] Sent: Thursday, August 10, 2000 7:34 AM
To: Multiple recipients of list ORACLE-L Subject: RE: KEEP creep

Hi Mark,
There is no such timeout. What you are seeing is the effect of CR mode blocks.
You should be able to work around this by setting _db_aging_freeze_cr = TRUE.
Regards,
Steve Adams

http://www.ixora.com.au/
http://www.oreilly.com/catalog/orinternals/
http://www.christianity.net.au/

-----Original Message-----

Sent: Thursday, 10 August 2000 19:33
To: Multiple recipients of list ORACLE-L

I am trying to size objects for the KEEP pool on 8.1.6. An analyze shows 108,000 blocks for a table, yet it fills the KEEP buffer pool,
which is 120,000 blocks.
The extra 12,000 blocks are copies of buffers not found within a time limit
when searching the hash chains (or so I believe). There are no other objects in
the KEEP pool.
I have tried maximum and minimum numbers of db_block_lru_latches with little
effect. I have not modified the _db_block_hash_buckets. I would prefer if it searched the buffer cache for longer for the required
buffers (because I know the whole table is cached), even if this means that it
runs a little slower. As with OLTP systems, constant performance is better.
Anyone know what to change to extend the buffer cache search timeout? Regards
Mark

ERG Group -------------------------- The contents of this email and any attachments are confidential and may only be read by the intended recipient.

--

Author:
INET: mteehan_at_erggroup.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists


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

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).
--

Author: Steve Adams
INET: steve.adams_at_ixora.com.au

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists


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

To REMOVE yourself from this mailing list, send an E-Mail message