Re: buffer cache structure in SGA

From: Jonathan Lewis <jonathan_at_jlcomp.demon.co.uk>
Date: Tue, 3 Apr 2018 07:29:44 +0000
Message-ID: <LOXP123MB09825102DF91C825DF4DA8BEA5A50_at_LOXP123MB0982.GBRP123.PROD.OUTLOOK.COM>


It's probably worth including the point that the linked list is still there - the effect of the touch count is that a buffer is not moved to the head of the list every time it is touched (which is why the latch activity became a threat), but it only moved when it reaches the tail of the list, and then only if it has been touched on the way down.

(Obviously lots more detail I've omitted - but it's in the book)

Regards
Jonathan Lewis



From: oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org> on behalf of Mladen Gogala <gogala.mladen_at_gmail.com> Sent: 03 April 2018 08:07
To: oracle-l_at_freelists.org
Subject: Re: buffer cache structure in SGA

Well, not quite the same. In Oracle 8i, buffers were managed by a linked list. The oldest buffers were at the tail of list, the most recently touched buffers were at the head of the list. Since Oracle 9.2 buffers are managed by the "touch count". Basically, when Oracle would need to free buffer in Oracle 8i, it would take certain number of buffers from the end of the linked list, save them and allocate them to processes that needed them. The problem was that to manipulate the linked list, Oracle would need to acquire the latch. And latches can be expensive. So, with touch counts, the organization was different, the need for latches was much smaller.

In Oracle 11.2, the whole system of pins and latches was completely reorganized, which resulted in Oracle 11.2.0.1 being practically unusable. Situation has improved greatly in 11.2.0.4. Now, there are some additional changes in 12c, to prevent connections to different PDB's from stealing buffers from each other. If you check db_cache_size parameter in Oracle 12.2, you will see that it's modifiable within PDB:

--
http://www.freelists.org/webpage/oracle-l
Received on Tue Apr 03 2018 - 09:29:44 CEST

Original text of this message