Re: (long and boring) SQL AREA and LIBARARY CACHE size?
An expert is the one who fully understands all of the important relationships between different parts of a system, I have a long way to go for getting there. But my sources are Oracle docs, Ixora, Internet, few training materials and of course Oracle server itself with awesome tracing and debugging abilities. Tanel. - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Monday, September 29, 2003 9:09 PM No expert? Hardly! Tanel, just how the heck do you KNOW all this stuff? --- Tanel Poder [EMAIL PROTECTED] wrote: Hi! As I understand, when shared pool heap is allocated, half of it's memory is actually hidden at first. Oracle just allocates one big permanent type chunk for that. The rest of memory is put on shared pool freelist. Initially this is just one big free chunk as well, but starts shrinking as space requests are done from it. One space request might result in multiple allocated chunks, if there's not enough free space in one memory extent for example. When a new chunk is allocated, the allocator will specify size and type of chunk it wants: - permanent type is permanent, unpinnable and unfreeable chunk. Permanent chunks exist until the whole heap is deallocated. - freeable type chunks can explicitly be freed by allocator (there's also special type of freeable chunks, called freeable with a mark, which can be freed implicitly, depending on memory usage in heap) - recreatable type chunks are pinned (in use) right after allocation and they can't be freed until they are explicitly unpinned. So, when allocating a recreatable type chunk, first freelists are searched for suitably sized free chunks. A heap freelist actually consists of 255 different lists, one for each size range of free chunks (smallest size range starts from 16 bytes, largest is about 64k+). This allows the freelist to be scanned faster. When no exactly matching free chunk is found, the next largest will be taken and is split. The leftover free chunk is placed to appropriate range in freelist. Memory allocations deallocations in shared pool are protected by shared pool latch (by shared pool child latch starting from 9i - you can separate shared pool to several heaps for better concurrency in 9i). AFAIK, Oracle is also able to coalesce adjacent free chunks when they're freed. When a recreatable chunk is allocated, it is marked as pinned - meaning currently in use. Thus noone can free it until it is explicitly unpinned by it's allocator (for example, several chunks might be pinned in shared pool during SQL parse and execution, but get unpinned right after the statement has finished). Here comes the LRU list into play. When a recreatable chunk is unpinned first time, it is put into MRU end of *transient* LRU list, since Oracle doesn't know whether it's needed ever again. When it is pinned next time, then of course it's taken off from LRU list at first, but the chunk itself is marked recurrent and is put in *recurrent* LRU list when unpinned again. (Note that I'm not sure how this LRU list internal structure looks like, whether there are really two LRU lists for each heap or is there a single one with two ends). Now, when a new space request is done, first freelists are scanned, but if there is no sufficient space there, transient LRU list is scanned and if big enough unpinned recreatable chunk is found, it is freed and returned to free list. Ok, but what happens if no suitable chunk is found from neither freelists nor LRU list? Oracle will then release hidden free space, which is allocated as permanent chunk during startup and is not in any freelists. The reason behind that might be that it is good to have less available memory during database startup, dictionary cache population and various applications initialization operations - that way more transient recreatable chunks can be reused and LRU lists don't get that long and there's less fragmentation in shared pool before real work starts. Long LRU and freelists are one reason for shared pool latch contention, that's why one should consider reducing of shared pool in case of this latch problem instead of usual more memory is better approach (as mentioned above, in 9i it's possible to split shared pool into several heaps to improve concurrency). And if even hidden memory is used up, then we get ORA-4031. Ok, this was a tiny part of heap management in Oracle, there is actually much more, such reserved list for shared pool reserved area and what happens free chunk split leftovers which are smaller than 16 bytes etc. Since I'm not expert on SGA, please correct if I'm wrong. Tanel. - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Friday, September 26, 2003 3:17
Re: (long and boring) SQL AREA and LIBARARY CACHE size?
No expert? Hardly! Tanel, just how the heck do you KNOW all this stuff? --- Tanel Poder [EMAIL PROTECTED] wrote: Hi! As I understand, when shared pool heap is allocated, half of it's memory is actually hidden at first. Oracle just allocates one big permanent type chunk for that. The rest of memory is put on shared pool freelist. Initially this is just one big free chunk as well, but starts shrinking as space requests are done from it. One space request might result in multiple allocated chunks, if there's not enough free space in one memory extent for example. When a new chunk is allocated, the allocator will specify size and type of chunk it wants: - permanent type is permanent, unpinnable and unfreeable chunk. Permanent chunks exist until the whole heap is deallocated. - freeable type chunks can explicitly be freed by allocator (there's also special type of freeable chunks, called freeable with a mark, which can be freed implicitly, depending on memory usage in heap) - recreatable type chunks are pinned (in use) right after allocation and they can't be freed until they are explicitly unpinned. So, when allocating a recreatable type chunk, first freelists are searched for suitably sized free chunks. A heap freelist actually consists of 255 different lists, one for each size range of free chunks (smallest size range starts from 16 bytes, largest is about 64k+). This allows the freelist to be scanned faster. When no exactly matching free chunk is found, the next largest will be taken and is split. The leftover free chunk is placed to appropriate range in freelist. Memory allocations deallocations in shared pool are protected by shared pool latch (by shared pool child latch starting from 9i - you can separate shared pool to several heaps for better concurrency in 9i). AFAIK, Oracle is also able to coalesce adjacent free chunks when they're freed. When a recreatable chunk is allocated, it is marked as pinned - meaning currently in use. Thus noone can free it until it is explicitly unpinned by it's allocator (for example, several chunks might be pinned in shared pool during SQL parse and execution, but get unpinned right after the statement has finished). Here comes the LRU list into play. When a recreatable chunk is unpinned first time, it is put into MRU end of *transient* LRU list, since Oracle doesn't know whether it's needed ever again. When it is pinned next time, then of course it's taken off from LRU list at first, but the chunk itself is marked recurrent and is put in *recurrent* LRU list when unpinned again. (Note that I'm not sure how this LRU list internal structure looks like, whether there are really two LRU lists for each heap or is there a single one with two ends). Now, when a new space request is done, first freelists are scanned, but if there is no sufficient space there, transient LRU list is scanned and if big enough unpinned recreatable chunk is found, it is freed and returned to free list. Ok, but what happens if no suitable chunk is found from neither freelists nor LRU list? Oracle will then release hidden free space, which is allocated as permanent chunk during startup and is not in any freelists. The reason behind that might be that it is good to have less available memory during database startup, dictionary cache population and various applications initialization operations - that way more transient recreatable chunks can be reused and LRU lists don't get that long and there's less fragmentation in shared pool before real work starts. Long LRU and freelists are one reason for shared pool latch contention, that's why one should consider reducing of shared pool in case of this latch problem instead of usual more memory is better approach (as mentioned above, in 9i it's possible to split shared pool into several heaps to improve concurrency). And if even hidden memory is used up, then we get ORA-4031. Ok, this was a tiny part of heap management in Oracle, there is actually much more, such reserved list for shared pool reserved area and what happens free chunk split leftovers which are smaller than 16 bytes etc. Since I'm not expert on SGA, please correct if I'm wrong. Tanel. - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Friday, September 26, 2003 3:17 PM ...long long way to go . b4 i reach x$ tables. Tanel, can u brief me about transient chunks recurrent chunks that u were discussing with Steve ? Jp. 26-09-2003 19:54:48, Tanel Poder [EMAIL PROTECTED] wrote: I'd suggest, when possible, not to use any x$ views, but stich with plain old documented ways. That way you'll probably avoid a lot of confusion, especially when database versions might change.. Tanel. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Prem Khanna J
Re: (long and boring) SQL AREA and LIBARARY CACHE size?
Hi! As I understand, when shared pool heap is allocated, half of it's memory is actually hidden at first. Oracle just allocates one big permanent type chunk for that. The rest of memory is put on shared pool freelist. Initially this is just one big free chunk as well, but starts shrinking as space requests are done from it. One space request might result in multiple allocated chunks, if there's not enough free space in one memory extent for example. When a new chunk is allocated, the allocator will specify size and type of chunk it wants: - permanent type is permanent, unpinnable and unfreeable chunk. Permanent chunks exist until the whole heap is deallocated. - freeable type chunks can explicitly be freed by allocator (there's also special type of freeable chunks, called freeable with a mark, which can be freed implicitly, depending on memory usage in heap) - recreatable type chunks are pinned (in use) right after allocation and they can't be freed until they are explicitly unpinned. So, when allocating a recreatable type chunk, first freelists are searched for suitably sized free chunks. A heap freelist actually consists of 255 different lists, one for each size range of free chunks (smallest size range starts from 16 bytes, largest is about 64k+). This allows the freelist to be scanned faster. When no exactly matching free chunk is found, the next largest will be taken and is split. The leftover free chunk is placed to appropriate range in freelist. Memory allocations deallocations in shared pool are protected by shared pool latch (by shared pool child latch starting from 9i - you can separate shared pool to several heaps for better concurrency in 9i). AFAIK, Oracle is also able to coalesce adjacent free chunks when they're freed. When a recreatable chunk is allocated, it is marked as pinned - meaning currently in use. Thus noone can free it until it is explicitly unpinned by it's allocator (for example, several chunks might be pinned in shared pool during SQL parse and execution, but get unpinned right after the statement has finished). Here comes the LRU list into play. When a recreatable chunk is unpinned first time, it is put into MRU end of *transient* LRU list, since Oracle doesn't know whether it's needed ever again. When it is pinned next time, then of course it's taken off from LRU list at first, but the chunk itself is marked recurrent and is put in *recurrent* LRU list when unpinned again. (Note that I'm not sure how this LRU list internal structure looks like, whether there are really two LRU lists for each heap or is there a single one with two ends). Now, when a new space request is done, first freelists are scanned, but if there is no sufficient space there, transient LRU list is scanned and if big enough unpinned recreatable chunk is found, it is freed and returned to free list. Ok, but what happens if no suitable chunk is found from neither freelists nor LRU list? Oracle will then release hidden free space, which is allocated as permanent chunk during startup and is not in any freelists. The reason behind that might be that it is good to have less available memory during database startup, dictionary cache population and various applications initialization operations - that way more transient recreatable chunks can be reused and LRU lists don't get that long and there's less fragmentation in shared pool before real work starts. Long LRU and freelists are one reason for shared pool latch contention, that's why one should consider reducing of shared pool in case of this latch problem instead of usual more memory is better approach (as mentioned above, in 9i it's possible to split shared pool into several heaps to improve concurrency). And if even hidden memory is used up, then we get ORA-4031. Ok, this was a tiny part of heap management in Oracle, there is actually much more, such reserved list for shared pool reserved area and what happens free chunk split leftovers which are smaller than 16 bytes etc. Since I'm not expert on SGA, please correct if I'm wrong. Tanel. - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Friday, September 26, 2003 3:17 PM ...long long way to go . b4 i reach x$ tables. Tanel, can u brief me about transient chunks recurrent chunks that u were discussing with Steve ? Jp. 26-09-2003 19:54:48, Tanel Poder [EMAIL PROTECTED] wrote: I'd suggest, when possible, not to use any x$ views, but stich with plain old documented ways. That way you'll probably avoid a lot of confusion, especially when database versions might change.. Tanel. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Prem Khanna J INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from
Re: SQL AREA and LIBARARY CACHE size?
Now that I think about it, it might very well be so :)
DBA_ views vs. base tables would be a different story (uet$ fet$ case with
LMT for example...)
Tanel.
- Original Message -
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Sent: Friday, September 26, 2003 2:14 PM
Was it not Dave Ensor that once concluded that x$ tables actually change
less than v$ tables?
Tanel Poder wrote:
I'd suggest, when possible, not to use any x$ views, but stich with plain
old documented ways. That way you'll probably avoid a lot of confusion,
especially when database versions might change..
Tanel.
- Original Message -
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Sent: Friday, September 26, 2003 1:19 PM
Hi Prem,
I Think you are also doing the same mistake that I have done yesterday,
that was causing so much confusion.
I had earlier calculated the library cache and sql area size from
X$ksmsp.
Please check the size of these component in x$ksmss.
WHat is difference in both x$ view is little bit confusing.
ORACLE try to calcluate SGASTAT from V$SGASTAT based on below mentioned
query:
===
select inst_id,
'',
ksmssnam,
ksmsslen
from x$ksmfs
where ksmsslen1
union all
select inst_id,
'shared pool',
ksmssnam,
sum(ksmsslen)
from x$ksmss
where ksmsslen1
group by inst_id, 'shared pool', ksmssnam
union all
select inst_id,
'large pool',
ksmssnam,
sum(ksmsslen)
from x$ksmls
where ksmsslen1
group by inst_id, 'large pool', ksmssnam
union all
select inst_id,
'java pool',
ksmssnam,
ksmsslen
from x$ksmjs
where ksmsslen1
=
You can see the library cache and sql area size from :
select inst_id,
'shared pool',
ksmssnam,
sum(ksmsslen)
from x$ksmss
where ksmsslen1
group by inst_id, 'shared pool', ksmssnam
===
However at same time when when you you calculate these component from
the
x$ksmsp using below mentioned SQL:
get different result:
SQL l
select
ksmchcom contents,
sum(ksmchsiz) total
from
sys.x$ksmsp
where
inst_id = userenv('Instance')
group by ksmchcom
With Regards,
Manoj Kumar Jha
C-56 , Phase-2
NOIDA -201305, UP(INDIA)
Tata Consultancy Services
Ph No: (+91-120) 4461001 ext : 1037 (Off.)
Mobile No : 9810090974
--
--
A transcendentalist engaged in auspicious activities does not meet with
destruction either in this world or in the spiritual world; one who does
good,
is never overcome by evil.
--
--
Prem Khanna J
[EMAIL PROTECTED]To: Multiple recipients of
list ORACLE-L [EMAIL PROTECTED]
.co.jp cc:
Sent by: Subject: Re: RE: SQL AREA
and LIBARARY CACHE size?
[EMAIL PROTECTED]
city.com
09/26/03
01:39 PM
Please
respond to
ORACLE-L
Hi Manoj,
this is the statistics i got from one of my instance.
sql area 225 MB
library cache 112 MB
I was also confused as u were [ i didn't notice this so far ].
but reading the replies of Tanel Steve once again:
tanel
But what Steve meant (please correct me if I'm wrong), is that
operations
on
sql areas are managed by library cache structures (library cache latch,
KGL
manager, lib cache hash table, etc), so sql area is dependent on library
cache, despite the fact they both have memory allocated directly from
shared pool.
/tanel
from this (and as per the docs) i understand that sql area is a subset
of
library cache.
perhaps,what subset means is:
in terms of the control library cache has over sql area and not in
terms
of memory allocated.
is my understanding correct, Tanel ?
steve
My best guess at the moment is that when new recreatable chunks are
first
unpinned,
they go onto the transient list, and then when they have been reused,
they
go back
onto the recurrent list.
/steve
..and reading this post by Steve,i feel there is something more(a lot)
that
we need to
know/understand to discuss about this.
Can Steve/Tanel/List explain me what is transient chunk recurrent
chunk
?
Regards,
Jp.
P.S.Thanx Naveen.
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Prem Khanna J
INET: [EMAIL PROTECTED]
Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing
RE: SQL AREA and LIBARARY CACHE size?
v$sgastat? -Original Message- From: Prem Khanna J [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2003 12:25 PM To: Multiple recipients of list ORACLE-L Subject: Re: SQL AREA and LIBARARY CACHE size? Hi Manoj, quoteIn my system size of library cache is approx 48 mb and sql area 417 mb/quote can i know where/how did u get the statistics from ? Jp. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Prem Khanna J INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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). DISCLAIMER: This message (including attachment if any) is confidential and may be privileged. Before opening attachments please check them for viruses and defects. MindTree Consulting Private Limited (MindTree) will not be responsible for any viruses or defects or any forwarded attachments emanating either from within MindTree or outside. If you have received this message by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change and MindTree shall not be liable for any improper, untimely or incomplete transmission. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Naveen Nahata INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
Re: RE: SQL AREA and LIBARARY CACHE size?
Hi Manoj, this is the statistics i got from one of my instance. sql area225 MB library cache 112 MB I was also confused as u were [ i didn't notice this so far ]. but reading the replies of Tanel Steve once again: tanel But what Steve meant (please correct me if I'm wrong), is that operations on sql areas are managed by library cache structures (library cache latch, KGL manager, lib cache hash table, etc), so sql area is dependent on library cache, despite the fact they both have memory allocated directly from shared pool. /tanel from this (and as per the docs) i understand that sql area is a subset of library cache. perhaps,what subset means is: in terms of the control library cache has over sql area and not in terms of memory allocated. is my understanding correct, Tanel ? steve My best guess at the moment is that when new recreatable chunks are first unpinned, they go onto the transient list, and then when they have been reused, they go back onto the recurrent list. /steve ..and reading this post by Steve,i feel there is something more(a lot) that we need to know/understand to discuss about this. Can Steve/Tanel/List explain me what is transient chunk recurrent chunk ? Regards, Jp. P.S.Thanx Naveen. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Prem Khanna J INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
Re: RE: SQL AREA and LIBARARY CACHE size?
Hi Prem,
I Think you are also doing the same mistake that I have done yesterday,
that was causing so much confusion.
I had earlier calculated the library cache and sql area size from X$ksmsp.
Please check the size of these component in x$ksmss.
WHat is difference in both x$ view is little bit confusing.
ORACLE try to calcluate SGASTAT from V$SGASTAT based on below mentioned
query:
===
select inst_id,
'',
ksmssnam,
ksmsslen
from x$ksmfs
where ksmsslen1
union all
select inst_id,
'shared pool',
ksmssnam,
sum(ksmsslen)
from x$ksmss
where ksmsslen1
group by inst_id, 'shared pool', ksmssnam
union all
select inst_id,
'large pool',
ksmssnam,
sum(ksmsslen)
from x$ksmls
where ksmsslen1
group by inst_id, 'large pool', ksmssnam
union all
select inst_id,
'java pool',
ksmssnam,
ksmsslen
from x$ksmjs
where ksmsslen1
=
You can see the library cache and sql area size from :
select inst_id,
'shared pool',
ksmssnam,
sum(ksmsslen)
from x$ksmss
where ksmsslen1
group by inst_id, 'shared pool', ksmssnam
===
However at same time when when you you calculate these component from the
x$ksmsp using below mentioned SQL:
get different result:
SQL l
select
ksmchcom contents,
sum(ksmchsiz) total
from
sys.x$ksmsp
where
inst_id = userenv('Instance')
group by ksmchcom
With Regards,
Manoj Kumar Jha
C-56 , Phase-2
NOIDA -201305, UP(INDIA)
Tata Consultancy Services
Ph No: (+91-120) 4461001 ext : 1037 (Off.)
Mobile No : 9810090974
A transcendentalist engaged in auspicious activities does not meet with
destruction either in this world or in the spiritual world; one who does
good,
is never overcome by evil.
Prem Khanna J
[EMAIL PROTECTED]To: Multiple recipients of list
ORACLE-L [EMAIL PROTECTED]
.co.jp cc:
Sent by: Subject: Re: RE: SQL AREA and LIBARARY
CACHE size?
[EMAIL PROTECTED]
city.com
09/26/03
01:39 PM
Please
respond to
ORACLE-L
Hi Manoj,
this is the statistics i got from one of my instance.
sql area 225 MB
library cache 112 MB
I was also confused as u were [ i didn't notice this so far ].
but reading the replies of Tanel Steve once again:
tanel
But what Steve meant (please correct me if I'm wrong), is that operations
on
sql areas are managed by library cache structures (library cache latch, KGL
manager, lib cache hash table, etc), so sql area is dependent on library
cache, despite the fact they both have memory allocated directly from
shared pool.
/tanel
from this (and as per the docs) i understand that sql area is a subset of
library cache.
perhaps,what subset means is:
in terms of the control library cache has over sql area and not in terms
of memory allocated.
is my understanding correct, Tanel ?
steve
My best guess at the moment is that when new recreatable chunks are first
unpinned,
they go onto the transient list, and then when they have been reused, they
go back
onto the recurrent list.
/steve
..and reading this post by Steve,i feel there is something more(a lot
Re: RE: SQL AREA and LIBARARY CACHE size?
Hi Manoj, to be frank : need to know more basic stuff before i peep into X$ tables. let me get good at fundamentals (a lot to be read explored) first. later i can join u to explore about X$ stuff ;) meanwhile,i'm waiting for someone to explain me about transient chunk recurrent chunk. Jp. 26-09-2003 19:19:25, ManojKr Jha [EMAIL PROTECTED] wrote: Hi Prem, I Think you are also doing the same mistake that I have done yesterday, that was causing so much confusion. I had earlier calculated the library cache and sql area size from X$ksmsp. Please check the size of these component in x$ksmss. WHat is difference in both x$ view is little bit confusing. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Prem Khanna J INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
Re: RE: SQL AREA and LIBARARY CACHE size?
I'd suggest, when possible, not to use any x$ views, but stich with plain
old documented ways. That way you'll probably avoid a lot of confusion,
especially when database versions might change..
Tanel.
- Original Message -
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Sent: Friday, September 26, 2003 1:19 PM
Hi Prem,
I Think you are also doing the same mistake that I have done yesterday,
that was causing so much confusion.
I had earlier calculated the library cache and sql area size from X$ksmsp.
Please check the size of these component in x$ksmss.
WHat is difference in both x$ view is little bit confusing.
ORACLE try to calcluate SGASTAT from V$SGASTAT based on below mentioned
query:
===
select inst_id,
'',
ksmssnam,
ksmsslen
from x$ksmfs
where ksmsslen1
union all
select inst_id,
'shared pool',
ksmssnam,
sum(ksmsslen)
from x$ksmss
where ksmsslen1
group by inst_id, 'shared pool', ksmssnam
union all
select inst_id,
'large pool',
ksmssnam,
sum(ksmsslen)
from x$ksmls
where ksmsslen1
group by inst_id, 'large pool', ksmssnam
union all
select inst_id,
'java pool',
ksmssnam,
ksmsslen
from x$ksmjs
where ksmsslen1
=
You can see the library cache and sql area size from :
select inst_id,
'shared pool',
ksmssnam,
sum(ksmsslen)
from x$ksmss
where ksmsslen1
group by inst_id, 'shared pool', ksmssnam
===
However at same time when when you you calculate these component from the
x$ksmsp using below mentioned SQL:
get different result:
SQL l
select
ksmchcom contents,
sum(ksmchsiz) total
from
sys.x$ksmsp
where
inst_id = userenv('Instance')
group by ksmchcom
With Regards,
Manoj Kumar Jha
C-56 , Phase-2
NOIDA -201305, UP(INDIA)
Tata Consultancy Services
Ph No: (+91-120) 4461001 ext : 1037 (Off.)
Mobile No : 9810090974
--
--
A transcendentalist engaged in auspicious activities does not meet with
destruction either in this world or in the spiritual world; one who does
good,
is never overcome by evil.
--
--
Prem Khanna J
[EMAIL PROTECTED]To: Multiple recipients of
list ORACLE-L [EMAIL PROTECTED]
.co.jp cc:
Sent by: Subject: Re: RE: SQL AREA
and LIBARARY CACHE size?
[EMAIL PROTECTED]
city.com
09/26/03
01:39 PM
Please
respond to
ORACLE-L
Hi Manoj,
this is the statistics i got from one of my instance.
sql area 225 MB
library cache 112 MB
I was also confused as u were [ i didn't notice this so far ].
but reading the replies of Tanel Steve once again:
tanel
But what Steve meant (please correct me if I'm wrong), is that operations
on
sql areas are managed by library cache structures (library cache latch,
KGL
manager, lib cache hash table, etc), so sql area is dependent on library
cache, despite the fact they both have memory allocated directly from
shared pool.
/tanel
from this (and as per the docs) i understand that sql area is a subset of
library cache.
perhaps,what subset means is:
in terms of the control library cache has over sql area and not in terms
of memory allocated.
is my understanding correct, Tanel ?
steve
My best guess at the moment is that when new recreatable chunks are first
unpinned,
they go onto the transient list, and then when they have been reused, they
go back
onto the recurrent list.
/steve
..and reading this post by Steve,i feel there is something more(a lot)
that
we need to
know/understand to discuss about this.
Can Steve/Tanel/List explain me what is transient chunk recurrent chunk
?
Regards,
Jp.
P.S.Thanx Naveen.
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Prem Khanna J
INET: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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).
DISCLAIMER: The information contained in this message is intended only
Re: SQL AREA and LIBARARY CACHE size?
Was it not Dave Ensor that once concluded that x$ tables actually change
less than v$ tables?
Tanel Poder wrote:
I'd suggest, when possible, not to use any x$ views, but stich with plain
old documented ways. That way you'll probably avoid a lot of confusion,
especially when database versions might change..
Tanel.
- Original Message -
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Sent: Friday, September 26, 2003 1:19 PM
Hi Prem,
I Think you are also doing the same mistake that I have done yesterday,
that was causing so much confusion.
I had earlier calculated the library cache and sql area size from X$ksmsp.
Please check the size of these component in x$ksmss.
WHat is difference in both x$ view is little bit confusing.
ORACLE try to calcluate SGASTAT from V$SGASTAT based on below mentioned
query:
===
select inst_id,
'',
ksmssnam,
ksmsslen
from x$ksmfs
where ksmsslen1
union all
select inst_id,
'shared pool',
ksmssnam,
sum(ksmsslen)
from x$ksmss
where ksmsslen1
group by inst_id, 'shared pool', ksmssnam
union all
select inst_id,
'large pool',
ksmssnam,
sum(ksmsslen)
from x$ksmls
where ksmsslen1
group by inst_id, 'large pool', ksmssnam
union all
select inst_id,
'java pool',
ksmssnam,
ksmsslen
from x$ksmjs
where ksmsslen1
=
You can see the library cache and sql area size from :
select inst_id,
'shared pool',
ksmssnam,
sum(ksmsslen)
from x$ksmss
where ksmsslen1
group by inst_id, 'shared pool', ksmssnam
===
However at same time when when you you calculate these component from the
x$ksmsp using below mentioned SQL:
get different result:
SQL l
select
ksmchcom contents,
sum(ksmchsiz) total
from
sys.x$ksmsp
where
inst_id = userenv('Instance')
group by ksmchcom
With Regards,
Manoj Kumar Jha
C-56 , Phase-2
NOIDA -201305, UP(INDIA)
Tata Consultancy Services
Ph No: (+91-120) 4461001 ext : 1037 (Off.)
Mobile No : 9810090974
--
--
A transcendentalist engaged in auspicious activities does not meet with
destruction either in this world or in the spiritual world; one who does
good,
is never overcome by evil.
--
--
Prem Khanna J
[EMAIL PROTECTED]To: Multiple recipients of
list ORACLE-L [EMAIL PROTECTED]
.co.jp cc:
Sent by: Subject: Re: RE: SQL AREA
and LIBARARY CACHE size?
[EMAIL PROTECTED]
city.com
09/26/03
01:39 PM
Please
respond to
ORACLE-L
Hi Manoj,
this is the statistics i got from one of my instance.
sql area 225 MB
library cache 112 MB
I was also confused as u were [ i didn't notice this so far ].
but reading the replies of Tanel Steve once again:
tanel
But what Steve meant (please correct me if I'm wrong), is that operations
on
sql areas are managed by library cache structures (library cache latch,
KGL
manager, lib cache hash table, etc), so sql area is dependent on library
cache, despite the fact they both have memory allocated directly from
shared pool.
/tanel
from this (and as per the docs) i understand that sql area is a subset of
library cache.
perhaps,what subset means is:
in terms of the control library cache has over sql area and not in terms
of memory allocated.
is my understanding correct, Tanel ?
steve
My best guess at the moment is that when new recreatable chunks are first
unpinned,
they go onto the transient list, and then when they have been reused, they
go back
onto the recurrent list.
/steve
..and reading this post by Steve,i feel there is something more(a lot)
that
we need to
know/understand to discuss about this.
Can Steve/Tanel/List explain me what is transient chunk recurrent chunk
?
Regards,
Jp.
P.S.Thanx Naveen.
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Prem Khanna J
INET: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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).
DISCLAIMER: The information contained in this message is intended only and
solely for the addressed
Re: RE: SQL AREA and LIBARARY CACHE size?
...long long way to go . b4 i reach x$ tables. Tanel, can u brief me about transient chunks recurrent chunks that u were discussing with Steve ? Jp. 26-09-2003 19:54:48, Tanel Poder [EMAIL PROTECTED] wrote: I'd suggest, when possible, not to use any x$ views, but stich with plain old documented ways. That way you'll probably avoid a lot of confusion, especially when database versions might change.. Tanel. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Prem Khanna J INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
SQL AREA and LIBARARY CACHE size?
Hi, Any body have any idea about how to control the size of library cache and sql area in shared_pool? With Regards, Manoj Kumar Jha A transcendentalist engaged in auspicious activities does not meet with destruction either in this world or in the spiritual world; one who does good, is never overcome by evil. DISCLAIMER: The information contained in this message is intended only and solely for the addressed individual or entity indicated in this message and for the exclusive use of the said addressed individual or entity indicated in this message (or responsible for delivery of the message to such person) and may contain legally privileged and confidential information belonging to Tata Consultancy Services. It must not be printed, read, copied, disclosed, forwarded, distributed or used (in whatsoever manner) by any person other than the addressee. Unauthorized use, disclosure or copying is strictly prohibited and may constitute unlawful act and can possibly attract legal action, civil and/or criminal. The contents of this message need not necessarily reflect or endorse the views of Tata Consultancy Services on any subject matter. Any action taken or omitted to be taken based on this message is entirely at your risk and neither the originator of this message nor Tata Consultancy Services takes any responsibility or liability towards the same. Opinions, conclusions and any other information contained in this message that do not relate to the official business of Tata Consultancy Services shall be understood as neither given nor endorsed by Tata Consultancy Services or any affiliate of Tata Consultancy Services. If you have received this message in error, you should destroy this message and may please notify the sender by e-mail. Thank you. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: ManojKr Jha INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
Re: SQL AREA and LIBARARY CACHE size?
There is no control on these parameter. Oracle manage it by itself. Only one parameter: shared_pool_size. - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Thursday, September 25, 2003 3:09 PM Hi, Any body have any idea about how to control the size of library cache and sql area in shared_pool? With Regards, Manoj Kumar Jha A transcendentalist engaged in auspicious activities does not meet with destruction either in this world or in the spiritual world; one who does good, is never overcome by evil. DISCLAIMER: The information contained in this message is intended only and solely for the addressed individual or entity indicated in this message and for the exclusive use of the said addressed individual or entity indicated in this message (or responsible for delivery of the message to such person) and may contain legally privileged and confidential information belonging to Tata Consultancy Services. It must not be printed, read, copied, disclosed, forwarded, distributed or used (in whatsoever manner) by any person other than the addressee. Unauthorized use, disclosure or copying is strictly prohibited and may constitute unlawful act and can possibly attract legal action, civil and/or criminal. The contents of this message need not necessarily reflect or endorse the views of Tata Consultancy Services on any subject matter. Any action taken or omitted to be taken based on this message is entirely at your risk and neither the originator of this message nor Tata Consultancy Services takes any responsibility or liability towards the same. Opinions, conclusions and any other information contained in this message that do not relate to the official business of Tata Consultancy Services shall be understood as neither given nor endorsed by Tata Consultancy Services or any affiliate of Tata Consultancy Services. If you have received this message in error, you should destroy this message and may please notify the sender by e-mail. Thank you. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: ManojKr Jha INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: zhu chao INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
Re: SQL AREA and LIBARARY CACHE size?
You cannot control the sizes of sql area and library cache individually Regards On Thu, 25 Sep 2003 ManojKr Jha wrote : Hi, Any body have any idea about how to control the size of library cache and sql area in shared_pool? With Regards, Manoj Kumar Jha A transcendentalist engaged in auspicious activities does not meet with destruction either in this world or in the spiritual world; one who does good, is never overcome by evil. DISCLAIMER: The information contained in this message is intended only and solely for the addressed individual or entity indicated in this message and for the exclusive use of the said addressed individual or entity indicated in this message (or responsible for delivery of the message to such person) and may contain legally privileged and confidential information belonging to Tata Consultancy Services. It must not be printed, read, copied, disclosed, forwarded, distributed or used (in whatsoever manner) by any person other than the addressee. Unauthorized use, disclosure or copying is strictly prohibited and may constitute unlawful act and can possibly attract legal action, civil and/or criminal. The contents of this message need not necessarily reflect or endorse the views of Tata Consultancy Services on any subject matter. Any action taken or omitted to be taken based on this message is entirely at your risk and neither the originator of this message nor Tata Consultancy Services takes any responsibility or liability towards the same. Opinions, conclusions and any other information contained in this message that do not relate to the official business of Tata Consultancy Services shall be understood as neither given nor endorsed by Tata Consultancy Services or any affiliate of Tata Consultancy Services. If you have received this message in error, you should destroy this message and may please notify the sender by e-mail. Thank you. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: ManojKr Jha INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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). ___ Art meets Anesthesia; Shefali Weds Dr. Raman. Rediff Matchmaker strikes another interesting match !! Visit http://matchmaker.rediff.com?1 -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: bhabani s pradhan INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
Re: SQL AREA and LIBARARY CACHE size?
How the ORACLE distribute and mange the size of variouse component in shared_pool? There should be some criteria on which it disribute its toatl available memory to these component. Steve Adams/Jonathan, do you have any about these? Also are there any way to control the number and type of chunks in different buckets. If these can be manage I hope that lots of seriouse problem related to shared pool fragmentation and other issues can be easilly avoided? With Regards, Manoj Kumar Jha --- A transcendentalist engaged in auspicious activities does not meet with destruction either in this world or in the spiritual world; one who does good, is never overcome by evil. --- bhabani s pradhan [EMAIL PROTECTED]To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] fmail.com cc: Sent by: Subject: Re: SQL AREA and LIBARARY CACHE size? [EMAIL PROTECTED] om 09/25/03 01:04 PM Please respond to ORACLE-L You cannot control the sizes of sql area and library cache individually Regards On Thu, 25 Sep 2003 ManojKr Jha wrote : Hi, Any body have any idea about how to control the size of library cache and sql area in shared_pool? With Regards, Manoj Kumar Jha A transcendentalist engaged in auspicious activities does not meet with destruction either in this world or in the spiritual world; one who does good, is never overcome by evil. DISCLAIMER: The information contained in this message is intended only and solely for the addressed individual or entity indicated in this message and for the exclusive use of the said addressed individual or entity indicated in this message (or responsible for delivery of the message to such person) and may contain legally privileged and confidential information belonging to Tata Consultancy Services. It must not be printed, read, copied, disclosed, forwarded, distributed or used (in whatsoever manner) by any person other than the addressee. Unauthorized use, disclosure or copying is strictly prohibited and may constitute unlawful act and can possibly attract legal action, civil and/or criminal. The contents of this message need not necessarily reflect or endorse the views of Tata Consultancy Services on any subject matter. Any action taken or omitted to be taken based on this message is entirely at your risk and neither the originator of this message nor Tata Consultancy Services takes any responsibility or liability towards the same. Opinions, conclusions and any other information contained in this message that do not relate to the official business of Tata Consultancy Services shall be understood as neither given nor endorsed by Tata Consultancy Services or any affiliate of Tata Consultancy Services. If you have received this message in error, you should destroy this message and may please notify the sender by e-mail. Thank you. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: ManojKr Jha INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services
RE: SQL AREA and LIBARARY CACHE size?
Hi Manoj, Although the stats are confused, the SQL area is in fact a subset of the library cache. Cursors are cached in the library cache as namespace 0. You can exercise limited control over the memory usage by marking objects for keeping with DBMS_SHARED_POOL.KEEP. Otherwise, the retention of chunks and thus the relative size of these and other shared pool areas depends entirely how recently objects have been used, because they all share the same LRU mechanisms (although there is an additional subordinate LRU mechanism for the dictionary cache). @ Regards, @ Steve Adams @ http://www.ixora.com.au/ - For DBAs @ http://www.christianity.net.au/ - For all -Original Message- ManojKr Jha Sent: Thursday, 25 September 2003 6:35 PM To: Multiple recipients of list ORACLE-L How the ORACLE distribute and mange the size of variouse component in shared_pool? There should be some criteria on which it disribute its toatl available memory to these component. Steve Adams/Jonathan, do you have any about these? Also are there any way to control the number and type of chunks in different buckets. If these can be manage I hope that lots of seriouse problem related to shared pool fragmentation and other issues can be easilly avoided? With Regards, Manoj Kumar Jha --- A transcendentalist engaged in auspicious activities does not meet with destruction either in this world or in the spiritual world; one who does good, is never overcome by evil. --- bhabani s pradhan [EMAIL PROTECTED]To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] fmail.com cc: Sent by: Subject: Re: SQL AREA and LIBARARY CACHE size? [EMAIL PROTECTED] om 09/25/03 01:04 PM Please respond to ORACLE-L You cannot control the sizes of sql area and library cache individually Regards On Thu, 25 Sep 2003 ManojKr Jha wrote : Hi, Any body have any idea about how to control the size of library cache and sql area in shared_pool? With Regards, Manoj Kumar Jha A transcendentalist engaged in auspicious activities does not meet with destruction either in this world or in the spiritual world; one who does good, is never overcome by evil. DISCLAIMER: The information contained in this message is intended only and solely for the addressed individual or entity indicated in this message and for the exclusive use of the said addressed individual or entity indicated in this message (or responsible for delivery of the message to such person) and may contain legally privileged and confidential information belonging to Tata Consultancy Services. It must not be printed, read, copied, disclosed, forwarded, distributed or used (in whatsoever manner) by any person other than the addressee. Unauthorized use, disclosure or copying is strictly prohibited and may constitute unlawful act and can possibly attract legal action, civil and/or criminal. The contents of this message need not necessarily reflect or endorse the views of Tata Consultancy Services on any subject matter. Any action taken or omitted to be taken based on this message is entirely at your risk and neither the originator of this message nor Tata Consultancy Services takes any responsibility or liability towards the same. Opinions, conclusions and any other information contained in this message that do not relate to the official business of Tata Consultancy Services shall be understood as neither given nor endorsed by Tata Consultancy Services or any affiliate of Tata Consultancy Services. If you have received this message in error, you should destroy this message and may please notify the sender by e-mail. Thank you. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: ManojKr Jha INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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
RE: SQL AREA and LIBARARY CACHE size?
Hi Steve, Sorry for it, but I want to correct one thing that is , it is Libarray cache which is subset of SQL area which intern subset of shared pool. With Regards, Manoj Kumar Jha A transcendentalist engaged in auspicious activities does not meet with destruction either in this world or in the spiritual world; one who does good, is never overcome by evil. Steve Adams [EMAIL PROTECTED]To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] ra.com.au cc: Sent by:Subject: RE: SQL AREA and LIBARARY CACHE size? [EMAIL PROTECTED] y.com 09/25/03 03:24 PM Please respond to ORACLE-L Hi Manoj, Although the stats are confused, the SQL area is in fact a subset of the library cache. Cursors are cached in the library cache as namespace 0. You can exercise limited control over the memory usage by marking objects for keeping with DBMS_SHARED_POOL.KEEP. Otherwise, the retention of chunks and thus the relative size of these and other shared pool areas depends entirely how recently objects have been used, because they all share the same LRU mechanisms (although there is an additional subordinate LRU mechanism for the dictionary cache). @ Regards, @ Steve Adams @ http://www.ixora.com.au/ - For DBAs @ http://www.christianity.net.au/ - For all -Original Message- ManojKr Jha Sent: Thursday, 25 September 2003 6:35 PM To: Multiple recipients of list ORACLE-L How the ORACLE distribute and mange the size of variouse component in shared_pool? There should be some criteria on which it disribute its toatl available memory to these component. Steve Adams/Jonathan, do you have any about these? Also are there any way to control the number and type of chunks in different buckets. If these can be manage I hope that lots of seriouse problem related to shared pool fragmentation and other issues can be easilly avoided? With Regards, Manoj Kumar Jha --- A transcendentalist engaged in auspicious activities does not meet with destruction either in this world or in the spiritual world; one who does good, is never overcome by evil. --- bhabani s pradhan [EMAIL PROTECTED]To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] fmail.com cc: Sent by: Subject: Re: SQL AREA and LIBARARY CACHE size? [EMAIL PROTECTED] om 09/25/03 01:04 PM Please respond to ORACLE-L You cannot control the sizes of sql area and library cache individually Regards On Thu, 25 Sep 2003 ManojKr Jha wrote : Hi, Any body have any idea about how to control the size of library cache and sql area in shared_pool? With Regards, Manoj Kumar Jha A transcendentalist engaged in auspicious activities
Re: SQL AREA and LIBARARY CACHE size?
As I understand SQL area is a subset of library cache which is a subset of shared pool. Taking advantage the opportunity that Steve is here, I'd like to ask how does Oracle distinguish between recurrent and transient chunks? Is this hardcoded, that certain types of chunks go to transient end of LRU list and others go to rcr end or is this based on some kind of touch count as well, like in buffer cache LRU list? Tanel. - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Thursday, September 25, 2003 2:04 PM Hi Steve, Sorry for it, but I want to correct one thing that is , it is Libarray cache which is subset of SQL area which intern subset of shared pool. With Regards, Manoj Kumar Jha -- -- A transcendentalist engaged in auspicious activities does not meet with destruction either in this world or in the spiritual world; one who does good, is never overcome by evil. -- -- Steve Adams [EMAIL PROTECTED]To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] ra.com.au cc: Sent by:Subject: RE: SQL AREA and LIBARARY CACHE size? [EMAIL PROTECTED] y.com 09/25/03 03:24 PM Please respond to ORACLE-L Hi Manoj, Although the stats are confused, the SQL area is in fact a subset of the library cache. Cursors are cached in the library cache as namespace 0. You can exercise limited control over the memory usage by marking objects for keeping with DBMS_SHARED_POOL.KEEP. Otherwise, the retention of chunks and thus the relative size of these and other shared pool areas depends entirely how recently objects have been used, because they all share the same LRU mechanisms (although there is an additional subordinate LRU mechanism for the dictionary cache). @ Regards, @ Steve Adams @ http://www.ixora.com.au/ - For DBAs @ http://www.christianity.net.au/ - For all -Original Message- ManojKr Jha Sent: Thursday, 25 September 2003 6:35 PM To: Multiple recipients of list ORACLE-L How the ORACLE distribute and mange the size of variouse component in shared_pool? There should be some criteria on which it disribute its toatl available memory to these component. Steve Adams/Jonathan, do you have any about these? Also are there any way to control the number and type of chunks in different buckets. If these can be manage I hope that lots of seriouse problem related to shared pool fragmentation and other issues can be easilly avoided? With Regards, Manoj Kumar Jha -- -- --- A transcendentalist engaged in auspicious activities does not meet with destruction either in this world or in the spiritual world; one who does good, is never overcome by evil. -- -- --- bhabani s pradhan [EMAIL PROTECTED]To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] fmail.com cc: Sent by: Subject: Re: SQL AREA and LIBARARY CACHE size? [EMAIL PROTECTED] om 09/25/03 01:04 PM Please respond to ORACLE-L You cannot control the sizes of sql area and library cache individually Regards On Thu, 25 Sep 2003 ManojKr Jha wrote : Hi, Any body have any idea about how to control the size of library cache and sql area in shared_pool? With Regards, Manoj Kumar Jha -- -- A transcendentalist engaged in auspicious activities does not meet with destruction either in this world or in the spiritual world; one who does good, is never overcome by evil. -- -- DISCLAIMER: The information contained in this message is intended only and solely for the addressed individual or entity indicated in this message and for the exclusive use of the said addressed individual or entity indicated in this message (or responsible for delivery of the message to such person) and may contain legally privileged and confidential information belonging to Tata Consultancy Services
Re: SQL AREA and LIBARARY CACHE size?
Prem Khanna, Yes I know that Steve is master of unix/oracle internals, that why I want to clarify my doubt. I had doubt that why I asked you fine people. Yes as far doc. and references are concerned, all clearly say that sql area is subset of library cache. but my doubt is due to size of these two components in shared pool. it is Library cache which may be subset of SQL area which intern subset of shared pool. If it is not then subset will be larger than set. Which is not possible. Please confirm with your database that what are size of LIBRARY CACHE and SQL AREA? In my system size of library cache is approx 48 mb and sql area 417 mb. With Regards, Manoj Kumar Jha A transcendentalist engaged in auspicious activities does not meet with destruction either in this world or in the spiritual world; one who does good, is never overcome by evil. Prem Khanna J [EMAIL PROTECTED]To: [EMAIL PROTECTED] .co.jp cc: Subject: Re: SQL AREA and LIBARARY CACHE size? 09/25/03 05:12 PM Please respond to jprem Manoj,hope u aware that u are talking to Steve Adams. author of oracle 8i internals and considered to be one of the top experts of oracle internals. just for your information. Regards, Jp. - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Hi Steve, Sorry for it, but I want to correct one thing that is , it is Libarray cache which is subset of SQL area which intern subset of shared pool. With Regards, Manoj Kumar Jha DISCLAIMER: The information contained in this message is intended only and solely for the addressed individual or entity indicated in this message and for the exclusive use of the said addressed individual or entity indicated in this message (or responsible for delivery of the message to such person) and may contain legally privileged and confidential information belonging to Tata Consultancy Services. It must not be printed, read, copied, disclosed, forwarded, distributed or used (in whatsoever manner) by any person other than the addressee. Unauthorized use, disclosure or copying is strictly prohibited and may constitute unlawful act and can possibly attract legal action, civil and/or criminal. The contents of this message need not necessarily reflect or endorse the views of Tata Consultancy Services on any subject matter. Any action taken or omitted to be taken based on this message is entirely at your risk and neither the originator of this message nor Tata Consultancy Services takes any responsibility or liability towards the same. Opinions, conclusions and any other information contained in this message that do not relate to the official business of Tata Consultancy Services shall be understood as neither given nor endorsed by Tata Consultancy Services or any affiliate of Tata Consultancy Services. If you have received this message in error, you should destroy this message and may please notify the sender by e-mail. Thank you. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: ManojKr Jha INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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
RE: SQL AREA and LIBARARY CACHE size?
Yes. Just increase the SHARED_POOL_SIZE parameter and you've increased both library cache and SQL area. Not just that, you've also increased the row cache as well. -- Mladen Gogala Oracle DBA -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ManojKr Jha Sent: Thursday, September 25, 2003 3:10 AM To: Multiple recipients of list ORACLE-L Subject: SQL AREA and LIBARARY CACHE size? Hi, Any body have any idea about how to control the size of library cache and sql area in shared_pool? With Regards, Manoj Kumar Jha -- -- A transcendentalist engaged in auspicious activities does not meet with destruction either in this world or in the spiritual world; one who does good, is never overcome by evil. -- -- DISCLAIMER: The information contained in this message is intended only and solely for the addressed individual or entity indicated in this message and for the exclusive use of the said addressed individual or entity indicated in this message (or responsible for delivery of the message to such person) and may contain legally privileged and confidential information belonging to Tata Consultancy Services. It must not be printed, read, copied, disclosed, forwarded, distributed or used (in whatsoever manner) by any person other than the addressee. Unauthorized use, disclosure or copying is strictly prohibited and may constitute unlawful act and can possibly attract legal action, civil and/or criminal. The contents of this message need not necessarily reflect or endorse the views of Tata Consultancy Services on any subject matter. Any action taken or omitted to be taken based on this message is entirely at your risk and neither the originator of this message nor Tata Consultancy Services takes any responsibility or liability towards the same. Opinions, conclusions and any other information contained in this message that do not relate to the official business of Tata Consultancy Services shall be understood as neither given nor endorsed by Tata Consultancy Services or any affiliate of Tata Consultancy Services. If you have received this message in error, you should destroy this message and may please notify the sender by e-mail. Thank you. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: ManojKr Jha INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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). Note: This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Wang Trading LLC and any of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Mladen Gogala INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
RE: SQL AREA and LIBARARY CACHE size?
From 9.2 doc: Shared Pool The shared pool portion of the SGA contains three major areas: library cache, dictionary cache, buffers for parallel execution messages, and control structures. The total size of the shared pool is determined by the initialization parameter SHARED_POOL_SIZE. The default value of this parameter is 8MB on 32-bit platforms and 64MB on 64-bit platforms. Increasing the value of this parameter increases the amount of memory reserved for the shared pool. Library Cache The library cache includes the shared SQL areas, private SQL areas (in the case of a multiple transaction server), PL/SQL procedures and packages, and control structures such as locks and library cache handles. Shared SQL areas are accessible to all users, so the library cache is contained in the shared pool within the SGA. Regards, Waleed -Original Message- Sent: Thursday, September 25, 2003 7:05 AM To: Multiple recipients of list ORACLE-L Hi Steve, Sorry for it, but I want to correct one thing that is , it is Libarray cache which is subset of SQL area which intern subset of shared pool. With Regards, Manoj Kumar Jha A transcendentalist engaged in auspicious activities does not meet with destruction either in this world or in the spiritual world; one who does good, is never overcome by evil. Steve Adams [EMAIL PROTECTED]To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] ra.com.au cc: Sent by:Subject: RE: SQL AREA and LIBARARY CACHE size? [EMAIL PROTECTED] y.com 09/25/03 03:24 PM Please respond to ORACLE-L Hi Manoj, Although the stats are confused, the SQL area is in fact a subset of the library cache. Cursors are cached in the library cache as namespace 0. You can exercise limited control over the memory usage by marking objects for keeping with DBMS_SHARED_POOL.KEEP. Otherwise, the retention of chunks and thus the relative size of these and other shared pool areas depends entirely how recently objects have been used, because they all share the same LRU mechanisms (although there is an additional subordinate LRU mechanism for the dictionary cache). @ Regards, @ Steve Adams @ http://www.ixora.com.au/ - For DBAs @ http://www.christianity.net.au/ - For all -Original Message- ManojKr Jha Sent: Thursday, 25 September 2003 6:35 PM To: Multiple recipients of list ORACLE-L How the ORACLE distribute and mange the size of variouse component in shared_pool? There should be some criteria on which it disribute its toatl available memory to these component. Steve Adams/Jonathan, do you have any about these? Also are there any way to control the number and type of chunks in different buckets. If these can be manage I hope that lots of seriouse problem related to shared pool fragmentation and other issues can be easilly avoided? With Regards, Manoj Kumar Jha --- A transcendentalist engaged in auspicious activities does not meet with destruction either in this world or in the spiritual world; one who does good, is never overcome by evil. --- bhabani s pradhan [EMAIL PROTECTED]To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] fmail.com cc: Sent by: Subject: Re: SQL AREA and LIBARARY CACHE size? [EMAIL PROTECTED] om 09/25/03 01:04 PM Please respond to ORACLE-L You cannot control the sizes of sql area and library cache individually Regards On Thu, 25 Sep 2003 ManojKr Jha wrote : Hi, Any body have any idea about how to control the size of library cache and sql area in shared_pool? With Regards, Manoj Kumar Jha A transcendentalist engaged in auspicious activities does not meet with destruction either in this world or in the spiritual world; one who does good, is never overcome by evil. DISCLAIMER: The information contained in this message is intended only
Re: SQL AREA and LIBARARY CACHE size?
Well, if you look it from memory allocation point of view, then during startup, a heap in size of shared_pool_size is allocated for shared pool and all memory allocations for library cache, sql area, pl/sql mpcode, KGL library cache manager structures, etc, are made from the same shared pool heap (providing that only one heap is configured). So different memory chunks are mixed up in the shared_pool, there is no such mechanism, which divides shared pool to sql part and library cache object part or similar. Only exceptions I can think of are shared pool reserved area and also I remember something about heap manager hiding half of shared pool for startup duration. v$sgastat just shows you the sums of chunk sizes for different types of objects. But what Steve meant (please correct me if I'm wrong), is that operations on sql areas are managed by library cache structures (library cache latch, KGL manager, lib cache hash table, etc), so sql area is dependent on library cache, despite the fact they both have memory allocated directly from shared pool. Tanel. - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Thursday, September 25, 2003 4:04 PM Prem Khanna, Yes I know that Steve is master of unix/oracle internals, that why I want to clarify my doubt. I had doubt that why I asked you fine people. Yes as far doc. and references are concerned, all clearly say that sql area is subset of library cache. but my doubt is due to size of these two components in shared pool. it is Library cache which may be subset of SQL area which intern subset of shared pool. If it is not then subset will be larger than set. Which is not possible. Please confirm with your database that what are size of LIBRARY CACHE and SQL AREA? In my system size of library cache is approx 48 mb and sql area 417 mb. With Regards, Manoj Kumar Jha -- -- A transcendentalist engaged in auspicious activities does not meet with destruction either in this world or in the spiritual world; one who does good, is never overcome by evil. -- -- Prem Khanna J [EMAIL PROTECTED]To: [EMAIL PROTECTED] .co.jp cc: Subject: Re: SQL AREA and LIBARARY CACHE size? 09/25/03 05:12 PM Please respond to jprem Manoj,hope u aware that u are talking to Steve Adams. author of oracle 8i internals and considered to be one of the top experts of oracle internals. just for your information. Regards, Jp. - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Hi Steve, Sorry for it, but I want to correct one thing that is , it is Libarray cache which is subset of SQL area which intern subset of shared pool. With Regards, Manoj Kumar Jha DISCLAIMER: The information contained in this message is intended only and solely for the addressed individual or entity indicated in this message and for the exclusive use of the said addressed individual or entity indicated in this message (or responsible for delivery of the message to such person) and may contain legally privileged and confidential information belonging to Tata Consultancy Services. It must not be printed, read, copied, disclosed, forwarded, distributed or used (in whatsoever manner) by any person other than the addressee. Unauthorized use, disclosure or copying is strictly prohibited and may constitute unlawful act and can possibly attract legal action, civil and/or criminal. The contents of this message need not necessarily reflect or endorse the views of Tata Consultancy Services on any subject matter. Any action taken or omitted to be taken based on this message is entirely at your risk and neither the originator of this message nor Tata Consultancy Services takes any responsibility or liability towards the same. Opinions, conclusions and any other information contained in this message that do not relate to the official business of Tata Consultancy Services shall be understood as neither given nor endorsed by Tata Consultancy Services or any affiliate of Tata Consultancy Services. If you have received this message in error, you should destroy this message and may please notify the sender by e-mail. Thank you. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: ManojKr Jha INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services
RE: SQL AREA and LIBARARY CACHE size?
Hi Tanel, There was a note in the bug database back in 7.1 days that suggested that it was hard coded based on the chunk type, and so that's what I wrote in my book. However, I fear that that might have been wrong. At least it is in recent versions. It is not hard to set up a test in which you can see chunks moving from the transient to recurrent list. My best guess at the moment is that when new recreatable chunks are first unpinned, they go onto the transient list, and then when they have been reused, they go back onto the recurrent list. @ Regards, @ Steve Adams @ http://www.ixora.com.au/ - For DBAs @ http://www.christianity.net.au/ - For all -Original Message- Tanel Poder Sent: Thursday, 25 September 2003 9:45 PM To: Multiple recipients of list ORACLE-L As I understand SQL area is a subset of library cache which is a subset of shared pool. Taking advantage the opportunity that Steve is here, I'd like to ask how does Oracle distinguish between recurrent and transient chunks? Is this hardcoded, that certain types of chunks go to transient end of LRU list and others go to rcr end or is this based on some kind of touch count as well, like in buffer cache LRU list? Tanel. - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Thursday, September 25, 2003 2:04 PM Hi Steve, Sorry for it, but I want to correct one thing that is , it is Libarray cache which is subset of SQL area which intern subset of shared pool. With Regards, Manoj Kumar Jha -- -- A transcendentalist engaged in auspicious activities does not meet with destruction either in this world or in the spiritual world; one who does good, is never overcome by evil. -- -- Steve Adams [EMAIL PROTECTED]To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] ra.com.au cc: Sent by:Subject: RE: SQL AREA and LIBARARY CACHE size? [EMAIL PROTECTED] y.com 09/25/03 03:24 PM Please respond to ORACLE-L Hi Manoj, Although the stats are confused, the SQL area is in fact a subset of the library cache. Cursors are cached in the library cache as namespace 0. You can exercise limited control over the memory usage by marking objects for keeping with DBMS_SHARED_POOL.KEEP. Otherwise, the retention of chunks and thus the relative size of these and other shared pool areas depends entirely how recently objects have been used, because they all share the same LRU mechanisms (although there is an additional subordinate LRU mechanism for the dictionary cache). @ Regards, @ Steve Adams @ http://www.ixora.com.au/ - For DBAs @ http://www.christianity.net.au/ - For all -Original Message- ManojKr Jha Sent: Thursday, 25 September 2003 6:35 PM To: Multiple recipients of list ORACLE-L How the ORACLE distribute and mange the size of variouse component in shared_pool? There should be some criteria on which it disribute its toatl available memory to these component. Steve Adams/Jonathan, do you have any about these? Also are there any way to control the number and type of chunks in different buckets. If these can be manage I hope that lots of seriouse problem related to shared pool fragmentation and other issues can be easilly avoided? With Regards, Manoj Kumar Jha -- -- --- A transcendentalist engaged in auspicious activities does not meet with destruction either in this world or in the spiritual world; one who does good, is never overcome by evil. -- -- --- bhabani s pradhan [EMAIL PROTECTED]To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] fmail.com cc: Sent by: Subject: Re: SQL AREA and LIBARARY CACHE size? [EMAIL PROTECTED] om 09/25/03 01:04 PM Please respond to ORACLE-L You cannot control the sizes of sql area and library cache individually Regards On Thu, 25 Sep 2003 ManojKr Jha wrote : Hi, Any body have any idea about how to control the size of library cache and sql area in shared_pool? With Regards, Manoj Kumar Jha [snip] -- Please see
Re: SQL AREA and LIBARARY CACHE size?
Hi Manoj, quoteIn my system size of library cache is approx 48 mb and sql area 417 mb/quote can i know where/how did u get the statistics from ? Jp. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Prem Khanna J INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
