Re: x$ constructs and memory
Thanks Raj, I knew about dbms_system.ksdwrt to write to trace files or the alert log or both but not these two. I have see from google that kcfrms allows the resetting of IO counters in v$session_event and v$filestat. And KSDFLS is part of the suite of functions to write to the alert log or trace file and flushes any pending output. http://www.oracleadvice.com/Tips/db ms_system_v2.htm gives a good description of the functions in DBMS_SYSTEM. Thanks Raj, kind regards Pete In article [EMAIL PROTECTED], Jamadagni, Rajendra [EMAIL PROTECTED] writes dbms_system.KCFRMS|KSDFLS (not sure about this one). Raj -- Pete Finnigan email:[EMAIL PROTECTED] Web site: http://www.petefinnigan.com - Oracle security audit specialists Book:Oracle security step-by-step Guide - see http://store.sans.org for details. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Pete Finnigan 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: x$ constructs and memory
Thanks very much Gopal, I have just replied to Raj's post on the same subject. kind regards Pete In article [EMAIL PROTECTED], K Gopalakrishnan [EMAIL PROTECTED] writes Pete: Sorry for the delay. I was traveling back to Bangalore from San Francisco when you sent the message. There is a procedure in the DBMS_SYSTEM package called KCFRMS which resets certain timing information from the X$KCFIO (which is exposed as V$FILESTAT). And also there is an event which can be used to flush the buffer cache and that will reset the part of the X$BH stats (very similar to ALTER SYSTEM FLUSH BUFFER CACHE in 10g and above!!). Regards, Gopal -- Pete Finnigan email:[EMAIL PROTECTED] Web site: http://www.petefinnigan.com - Oracle security audit specialists Book:Oracle security step-by-step Guide - see http://store.sans.org for details. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Pete Finnigan 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: x$ constructs and memory
Pete: Sorry for the delay. I was traveling back to Bangalore from San Francisco when you sent the message. There is a procedure in the DBMS_SYSTEM package called KCFRMS which resets certain timing information from the X$KCFIO (which is exposed as V$FILESTAT). And also there is an event which can be used to flush the buffer cache and that will reset the part of the X$BH stats (very similar to ALTER SYSTEM FLUSH BUFFER CACHE in 10g and above!!). Regards, Gopal - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Saturday, October 04, 2003 3:24 AM Hi Gopal, I have followed this thread with interest and i was waiting for you to elaborate on the following statement, specifically what undocumented procedures ? kind regards Pete code and you can not create/update/delete them. However there are some undocumented procudures , thru which you can reset certain tables. Regards, Gopal -- Pete Finnigan email:[EMAIL PROTECTED] Web site: http://www.petefinnigan.com - Oracle security audit specialists Book:Oracle security step-by-step Guide - see http://store.sans.org for details. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Pete Finnigan 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: K Gopalakrishnan 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: x$ constructs and memory
Hi Gopal, I have followed this thread with interest and i was waiting for you to elaborate on the following statement, specifically what undocumented procedures ? kind regards Pete code and you can not create/update/delete them. However there are some undocumented procudures , thru which you can reset certain tables. Regards, Gopal -- Pete Finnigan email:[EMAIL PROTECTED] Web site: http://www.petefinnigan.com - Oracle security audit specialists Book:Oracle security step-by-step Guide - see http://store.sans.org for details. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Pete Finnigan 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: x$ constructs and memory
Title: RE: x$ constructs and memory dbms_system.KCFRMS|KSDFLS (not sure about this one). Raj Rajendra dot Jamadagni at nospamespn dot com All Views expressed in this email are strictly personal. QOTD: Any clod can have facts, having an opinion is an art ! -Original Message- From: Pete Finnigan [mailto:[EMAIL PROTECTED]] Sent: Friday, October 03, 2003 5:54 PM To: Multiple recipients of list ORACLE-L Subject: Re: x$ constructs and memory Hi Gopal, I have followed this thread with interest and i was waiting for you to elaborate on the following statement, specifically what undocumented procedures ? kind regards Pete This e-mail message is confidential, intended only for the named recipient(s) above and may contain information that is privileged, attorney work product or exempt from disclosure under applicable law. If you have received this message in error, or are not the named recipient(s), please immediately notify corporate MIS at (860) 766-2000 and delete this e-mail message from your computer, Thank you.*2
Re: x$ constructs and memory
No, X$ tables exist even before a database is created - they are mostly instance related structures, not database or data dictionary ones. Do a startup nomount and select from x$ksuse or even dual for example and you see. You just can't select from these x$ tables which want to read physical database structures when database doesn't exist or isn't mounted/open. The translation of SGA memory structures to a returnable row set is pure C code, I think. Or if you can point me to these certain catalog scripts, I'd be glad to read them :O) But yes, about the fixed area I wasn't entirely correct at first. The Oracle term fixed_sga is really fixed, that it's size shouln't change if you don't relink of patch your executables. x$version contents are probably in fixed_sga. The other stuff, like enqueues goes to variable SGA (shared pool), but still many memory structures are not dynamic - they're allocated during startup and will remain the same during the lifetime of an instance. Tanel. - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Monday, September 29, 2003 9:24 PM With all due respect, I don't believe that it is a fixed area. You can create X$ tables by running certain catalog scripts. I believe that the description of X$ tables is located logically close to the description of the data dictionary, which would mean shared pool, not the fixed one. Now, can we get back to bears? -- Mladen Gogala Oracle DBA -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tanel Poder Sent: Monday, September 29, 2003 1:45 PM To: Multiple recipients of list ORACLE-L Subject: Re: x$ constructs and memory What I have not checked so far is how an ALTER SYSTEM increasing a parameter affects the SGA. In practice it's a realloc() (functionally speaking). It would seem reasonable to me to have a shared memory segment to hold all parameters which can by dynamically changed. I wouldn't touch it if parameters are decreased, but I would have to realloc it in case of a massive increase. Hmm, I guess that I would allow some spare memory initially, performance penalty would otherwise be severe. Which all makes the 10g dynamic rearrangement quite sensible ... Hi! I think the behaviour depends on which parameter you are changing. If you're changing shared_pool_size to higher size, then just additional extents of memory are allocated and heap header is updated. If you set sort_area_size higher, nothing particular happens, except some maximum is increased in UGA I believe and during next sort you can go up to that limit. Some parameters like enqueue_resources can't be changed in the fly, because they are fixed, they stay in fixed area of SGA, fixed area isn't managed as heap as I understand, it does not have any free or LRU lists, because it's physical structure remains unchanged during the lifetime of an instance. Tanel. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Tanel Poder 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
RE: x$ constructs and memory
Hi Steve and welcome back, Thanks for that detailed answer BUT... A practical question from the original post remains: What happens when these x$constructs begin to consume large amounts of memory? From your explanation I'm assuming that, beyond monitoring the SGA and PGA, memory consumption of individual X$ in-memory data structures is generally not something we need to worry about. How can we determine how much memory they actually consume? Are there any related tunable parameters of which we should be aware? Thanks, Steve Orr -Original Message- Sent: Monday, September 29, 2003 5:25 PM To: Multiple recipients of list ORACLE-L Hi Daniel and list, There are two types of X$ row sources. X$ tables export in-memory data structures that are inherently tabular, and X$ interfaces that call functions to return data is non-tabular, or not memory resident. For example, the array of structs in the SGA representing processes is exported as the X$ table X$KSUPR. Not all of the struct members are exported as columns, but all of the rows are exported. There is a freelist, implemented as a header that points to the first free slot in the array, and a member of each struct to point to the next free slot. The 'process allocation' latch protects this freelist. The most obvious example of an X$ interface to return non-tabular data is X$KSMSP, which returns one row for each chunk of memory in the shared pool. (There are similar X$ interfaces for other memory heaps). As you may know, heaps are implemented as a heap descriptor and linked list of extents, and within each extent there is a linked list of chunks. So what is done is that when the X$ interface is queried these linked lists are navigated (under the protection of the relevant latch if necessary) an a array is built in the CGA (part of the PGA) from which rows are then returned by the row source. An example of an X$ interface that returns data that is not memory resident is X$KCCLE, which returns one row for each log file member entry in the controlfile. In fact, all the X$KCC* interfaces read data directly from the controlfile. Similarly, the X$KTFB* interfaces return LMT extent information - from the bitmap blocks (for free extents) and from the segment header and extent map blocks (for used extents). Some X$ tables have become X$ interfaces in recent versions, for example X$KTCXB and X$KSQRS. These correspond to the transactions and enqueue resources arrays respectively. The reason is that they are no longer fixed arrays. Instead they are segmented arrays that can be dynamically extended by adding discontiguous chunks of shared pool memory to the array. The freelists and latching for these arrays in unchanged however. All you will notice is that the ADDR column of the X$ output now returns addresses which map into your PGA rather than the SGA. In fact, that is in general a good way to work out whether you are looking at an X$ table or an X$ interface. @ Regards, @ Steve Adams @ http://www.ixora.com.au/ - For DBAs @ http://www.christianity.net.au/ - For all -Original Message- Daniel Fink Sent: Tuesday, 30 September 2003 1:10 AM To: Multiple recipients of list ORACLE-L I was sitting on a mountain here in Colorado, pondering Oracle optimization and an interesting scenario crossed my feeble mind. As I began to ponder this (I asked the resident marmot, but he must be a SQL*Server expert...), I came up with several questions. Where in memory (sga or other) do the x$ constructs reside? Some of them are 'populated' by reading file-based structures (control file, datafile headers, undo segments). Does this information reside in memory or is it loaded each time the x$ construct is accessed? What happens when these x$constructs begin to consume large amounts of memory? Is there an upper bound? Daniel Fink -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Steve Adams 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: Orr, Steve 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
RE: x$ constructs and memory
I don't generally get too involved in the x$ stuff, just because it normally helps me very little in my DBA work. Nonetheless, I have been following this one somewhat, and if my understanding is correct, x$ tables are not actually responsible for consuming memory, they are merely a mechanism for displaying various structures internal to the kernel, many of which happen to be transient. Jared Orr, Steve [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 09/30/2003 07:49 AM Please respond to ORACLE-L To:Multiple recipients of list ORACLE-L [EMAIL PROTECTED] cc: Subject:RE: x$ constructs and memory Hi Steve and welcome back, Thanks for that detailed answer BUT... A practical question from the original post remains: What happens when these x$constructs begin to consume large amounts of memory? From your explanation I'm assuming that, beyond monitoring the SGA and PGA, memory consumption of individual X$ in-memory data structures is generally not something we need to worry about. How can we determine how much memory they actually consume? Are there any related tunable parameters of which we should be aware? Thanks, Steve Orr -Original Message- Sent: Monday, September 29, 2003 5:25 PM To: Multiple recipients of list ORACLE-L Hi Daniel and list, There are two types of X$ row sources. X$ tables export in-memory data structures that are inherently tabular, and X$ interfaces that call functions to return data is non-tabular, or not memory resident. For example, the array of structs in the SGA representing processes is exported as the X$ table X$KSUPR. Not all of the struct members are exported as columns, but all of the rows are exported. There is a freelist, implemented as a header that points to the first free slot in the array, and a member of each struct to point to the next free slot. The 'process allocation' latch protects this freelist. The most obvious example of an X$ interface to return non-tabular data is X$KSMSP, which returns one row for each chunk of memory in the shared pool. (There are similar X$ interfaces for other memory heaps). As you may know, heaps are implemented as a heap descriptor and linked list of extents, and within each extent there is a linked list of chunks. So what is done is that when the X$ interface is queried these linked lists are navigated (under the protection of the relevant latch if necessary) an a array is built in the CGA (part of the PGA) from which rows are then returned by the row source. An example of an X$ interface that returns data that is not memory resident is X$KCCLE, which returns one row for each log file member entry in the controlfile. In fact, all the X$KCC* interfaces read data directly from the controlfile. Similarly, the X$KTFB* interfaces return LMT extent information - from the bitmap blocks (for free extents) and from the segment header and extent map blocks (for used extents). Some X$ tables have become X$ interfaces in recent versions, for example X$KTCXB and X$KSQRS. These correspond to the transactions and enqueue resources arrays respectively. The reason is that they are no longer fixed arrays. Instead they are segmented arrays that can be dynamically extended by adding discontiguous chunks of shared pool memory to the array. The freelists and latching for these arrays in unchanged however. All you will notice is that the ADDR column of the X$ output now returns addresses which map into your PGA rather than the SGA. In fact, that is in general a good way to work out whether you are looking at an X$ table or an X$ interface. @ Regards, @ Steve Adams @ http://www.ixora.com.au/ - For DBAs @ http://www.christianity.net.au/ - For all -Original Message- Daniel Fink Sent: Tuesday, 30 September 2003 1:10 AM To: Multiple recipients of list ORACLE-L I was sitting on a mountain here in Colorado, pondering Oracle optimization and an interesting scenario crossed my feeble mind. As I began to ponder this (I asked the resident marmot, but he must be a SQL*Server expert...), I came up with several questions. Where in memory (sga or other) do the x$ constructs reside? Some of them are 'populated' by reading file-based structures (control file, datafile headers, undo segments). Does this information reside in memory or is it loaded each time the x$ construct is accessed? What happens when these x$constructs begin to consume large amounts of memory? Is there an upper bound? Daniel Fink -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Steve Adams 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
Re: x$ constructs and memory
Mladen: I am not sure where I am failing to understand you ;). First of all X$ objects are NOT tables, so there is no question of blocks or memory or dictionary cache. They are some C structures and their point in time (I am not finding a better word) values are exposed as table formats. That is what my understanding. I don't see any relation between them and dictionary cache.. AM I missing something? Regards, Gopal - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Wednesday, October 01, 2003 2:24 AM Description of the X$ does reside in the dictionary cache, but those tables are entry points into the code. So, besides their description, they don't consume memory, i.e. their blocks aren't cached. On Tue, 2003-09-30 at 15:29, [EMAIL PROTECTED] wrote: I don't generally get too involved in the x$ stuff, just because it normally helps me very little in my DBA work. Nonetheless, I have been following this one somewhat, and if my understanding is correct, x$ tables are not actually responsible for consuming memory, they are merely a mechanism for displaying various structures internal to the kernel, many of which happen to be transient. Jared Orr, Steve [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 09/30/2003 07:49 AM Please respond to ORACLE-L To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] cc: Subject: RE: x$ constructs and memory Hi Steve and welcome back, Thanks for that detailed answer BUT... A practical question from the original post remains: What happens when these x$constructs begin to consume large amounts of memory? From your explanation I'm assuming that, beyond monitoring the SGA and PGA, memory consumption of individual X$ in-memory data structures is generally not something we need to worry about. How can we determine how much memory they actually consume? Are there any related tunable parameters of which we should be aware? Thanks, Steve Orr -Original Message- Sent: Monday, September 29, 2003 5:25 PM To: Multiple recipients of list ORACLE-L Hi Daniel and list, There are two types of X$ row sources. X$ tables export in-memory data structures that are inherently tabular, and X$ interfaces that call functions to return data is non-tabular, or not memory resident. For example, the array of structs in the SGA representing processes is exported as the X$ table X$KSUPR. Not all of the struct members are exported as columns, but all of the rows are exported. There is a freelist, implemented as a header that points to the first free slot in the array, and a member of each struct to point to the next free slot. The 'process allocation' latch protects this freelist. The most obvious example of an X$ interface to return non-tabular data is X$KSMSP, which returns one row for each chunk of memory in the shared pool. (There are similar X$ interfaces for other memory heaps). As you may know, heaps are implemented as a heap descriptor and linked list of extents, and within each extent there is a linked list of chunks. So what is done is that when the X$ interface is queried these linked lists are navigated (under the protection of the relevant latch if necessary) an a array is built in the CGA (part of the PGA) from which rows are then returned by the row source. An example of an X$ interface that returns data that is not memory resident is X$KCCLE, which returns one row for each log file member entry in the controlfile. In fact, all the X$KCC* interfaces read data directly from the controlfile. Similarly, the X$KTFB* interfaces return LMT extent information - from the bitmap blocks (for free extents) and from the segment header and extent map blocks (for used extents). Some X$ tables have become X$ interfaces in recent versions, for example X$KTCXB and X$KSQRS. These correspond to the transactions and enqueue resources arrays respectively. The reason is that they are no longer fixed arrays. Instead they are segmented arrays that can be dynamically extended by adding discontiguous chunks of shared pool memory to the array. The freelists and latching for these arrays in unchanged however. All you will notice is that the ADDR column of the X$ output now returns addresses which map into your PGA rather than the SGA. In fact, that is in general a good way to work out whether you are looking at an X$ table or an X$ interface. @ Regards, @ Steve Adams @ http://www.ixora.com.au/ - For DBAs @ http://www.christianity.net.au/ - For all -Original Message- Daniel Fink Sent: Tuesday, 30 September 2003 1:10 AM To: Multiple recipients of list ORACLE-L I was sitting on a mountain here in Colorado, pondering Oracle optimization and an interesting scenario crossed my feeble
RE: x$ constructs and memory
Hi Steve, The X$ interfaces do not use memory persistently, and the memory usage of the X$ tables is fixed and necessary to an instance. Thus memory growth is not possible. Memory growth is possible for the segmented arrays, which some of the X$ interfaces expose. However, it is very unusual, because the defaults are rather generous. If you query V$RESOURCE_LIMIT, you will normally see that the MAX_UTILIZATION falls way short of the INITIAL_ALLOCATION. Even if there is significant growth, it is unlikely to chew up more than a few M of shared pool memory, because the structures involved are each very small. (You do however need to worry about similar growth in the instance lock database in a RAC environment). To answer another question raised later in this thread ... the metadata for X$ objects is present in the library cache during a query and may be cached afterwards, but there is no corresponding metadata in the dictionary cache. @ Regards, @ Steve Adams @ http://www.ixora.com.au/ - For DBAs @ http://www.christianity.net.au/ - For all -Original Message- Steve Sent: Wednesday, 1 October 2003 12:49 AM To: Multiple recipients of list ORACLE-L Hi Steve and welcome back, Thanks for that detailed answer BUT... A practical question from the original post remains: What happens when these x$constructs begin to consume large amounts of memory? From your explanation I'm assuming that, beyond monitoring the SGA and PGA, memory consumption of individual X$ in-memory data structures is generally not something we need to worry about. How can we determine how much memory they actually consume? Are there any related tunable parameters of which we should be aware? Thanks, Steve Orr -Original Message- Sent: Monday, September 29, 2003 5:25 PM To: Multiple recipients of list ORACLE-L Hi Daniel and list, There are two types of X$ row sources. X$ tables export in-memory data structures that are inherently tabular, and X$ interfaces that call functions to return data is non-tabular, or not memory resident. For example, the array of structs in the SGA representing processes is exported as the X$ table X$KSUPR. Not all of the struct members are exported as columns, but all of the rows are exported. There is a freelist, implemented as a header that points to the first free slot in the array, and a member of each struct to point to the next free slot. The 'process allocation' latch protects this freelist. The most obvious example of an X$ interface to return non-tabular data is X$KSMSP, which returns one row for each chunk of memory in the shared pool. (There are similar X$ interfaces for other memory heaps). As you may know, heaps are implemented as a heap descriptor and linked list of extents, and within each extent there is a linked list of chunks. So what is done is that when the X$ interface is queried these linked lists are navigated (under the protection of the relevant latch if necessary) an a array is built in the CGA (part of the PGA) from which rows are then returned by the row source. An example of an X$ interface that returns data that is not memory resident is X$KCCLE, which returns one row for each log file member entry in the controlfile. In fact, all the X$KCC* interfaces read data directly from the controlfile. Similarly, the X$KTFB* interfaces return LMT extent information - from the bitmap blocks (for free extents) and from the segment header and extent map blocks (for used extents). Some X$ tables have become X$ interfaces in recent versions, for example X$KTCXB and X$KSQRS. These correspond to the transactions and enqueue resources arrays respectively. The reason is that they are no longer fixed arrays. Instead they are segmented arrays that can be dynamically extended by adding discontiguous chunks of shared pool memory to the array. The freelists and latching for these arrays in unchanged however. All you will notice is that the ADDR column of the X$ output now returns addresses which map into your PGA rather than the SGA. In fact, that is in general a good way to work out whether you are looking at an X$ table or an X$ interface. @ Regards, @ Steve Adams @ http://www.ixora.com.au/ - For DBAs @ http://www.christianity.net.au/ - For all -Original Message- Daniel Fink Sent: Tuesday, 30 September 2003 1:10 AM To: Multiple recipients of list ORACLE-L I was sitting on a mountain here in Colorado, pondering Oracle optimization and an interesting scenario crossed my feeble mind. As I began to ponder this (I asked the resident marmot, but he must be a SQL*Server expert...), I came up with several questions. Where in memory (sga or other) do the x$ constructs reside? Some of them are 'populated' by reading file-based structures (control file, datafile headers, undo segments). Does this information reside in memory or is it loaded each time the x$ construct is accessed? What happens when these x$constructs begin to consume large
Re: x$ constructs and memory
Hi! Yep, I also think that x$ tables have nothing to do with row cache, instead their behaviour is hardcoded to Oracle executable. I did a simple test just in case (but I'm not sure whether it was sufficient), by parsing a select from x$kturd 10 times didn't see any big increases in v$rowcache stats. Tanel. - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Wednesday, October 01, 2003 12:14 AM Mladen: I am not sure where I am failing to understand you ;). First of all X$ objects are NOT tables, so there is no question of blocks or memory or dictionary cache. They are some C structures and their point in time (I am not finding a better word) values are exposed as table formats. That is what my understanding. I don't see any relation between them and dictionary cache.. AM I missing something? Regards, Gopal - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Wednesday, October 01, 2003 2:24 AM Description of the X$ does reside in the dictionary cache, but those tables are entry points into the code. So, besides their description, they don't consume memory, i.e. their blocks aren't cached. On Tue, 2003-09-30 at 15:29, [EMAIL PROTECTED] wrote: I don't generally get too involved in the x$ stuff, just because it normally helps me very little in my DBA work. Nonetheless, I have been following this one somewhat, and if my understanding is correct, x$ tables are not actually responsible for consuming memory, they are merely a mechanism for displaying various structures internal to the kernel, many of which happen to be transient. Jared Orr, Steve [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 09/30/2003 07:49 AM Please respond to ORACLE-L To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] cc: Subject: RE: x$ constructs and memory Hi Steve and welcome back, Thanks for that detailed answer BUT... A practical question from the original post remains: What happens when these x$constructs begin to consume large amounts of memory? From your explanation I'm assuming that, beyond monitoring the SGA and PGA, memory consumption of individual X$ in-memory data structures is generally not something we need to worry about. How can we determine how much memory they actually consume? Are there any related tunable parameters of which we should be aware? Thanks, Steve Orr -Original Message- Sent: Monday, September 29, 2003 5:25 PM To: Multiple recipients of list ORACLE-L Hi Daniel and list, There are two types of X$ row sources. X$ tables export in-memory data structures that are inherently tabular, and X$ interfaces that call functions to return data is non-tabular, or not memory resident. For example, the array of structs in the SGA representing processes is exported as the X$ table X$KSUPR. Not all of the struct members are exported as columns, but all of the rows are exported. There is a freelist, implemented as a header that points to the first free slot in the array, and a member of each struct to point to the next free slot. The 'process allocation' latch protects this freelist. The most obvious example of an X$ interface to return non-tabular data is X$KSMSP, which returns one row for each chunk of memory in the shared pool. (There are similar X$ interfaces for other memory heaps). As you may know, heaps are implemented as a heap descriptor and linked list of extents, and within each extent there is a linked list of chunks. So what is done is that when the X$ interface is queried these linked lists are navigated (under the protection of the relevant latch if necessary) an a array is built in the CGA (part of the PGA) from which rows are then returned by the row source. An example of an X$ interface that returns data that is not memory resident is X$KCCLE, which returns one row for each log file member entry in the controlfile. In fact, all the X$KCC* interfaces read data directly from the controlfile. Similarly, the X$KTFB* interfaces return LMT extent information - from the bitmap blocks (for free extents) and from the segment header and extent map blocks (for used extents). Some X$ tables have become X$ interfaces in recent versions, for example X$KTCXB and X$KSQRS. These correspond to the transactions and enqueue resources arrays respectively. The reason is that they are no longer fixed arrays. Instead they are segmented arrays that can be dynamically extended by adding discontiguous chunks of shared pool memory to the array. The freelists and latching for these arrays in unchanged however. All you will notice is that the ADDR column of the X$ output now
x$ constructs and memory
I was sitting on a mountain here in Colorado, pondering Oracle optimization and an interesting scenario crossed my feeble mind. As I began to ponder this (I asked the resident marmot, but he must be a SQL*Server expert...), I came up with several questions. Where in memory (sga or other) do the x$ constructs reside? Some of them are 'populated' by reading file-based structures (control file, datafile headers, undo segments). Does this information reside in memory or is it loaded each time the x$ construct is accessed? What happens when these x$constructs begin to consume large amounts of memory? Is there an upper bound? Daniel Fink begin:vcard n:Fink;Daniel x-mozilla-html:FALSE org:Sun Microsystems, Inc. adr:;; version:2.1 title:Lead, Database Services x-mozilla-cpt:;9168 fn:Daniel W. Fink end:vcard
RE: x$ constructs and memory
Dan - I think you are in grave danger of forgetting the point of sitting on the top of mountains Either that or your Colorado mountains have nothing on our variety from the NW Highlands of Scotland... (grin!) peter edinburgh -Original Message- From: Daniel Fink [mailto:[EMAIL PROTECTED] Sent: Monday, September 29, 2003 4:10 PM To: Multiple recipients of list ORACLE-L Subject: x$ constructs and memory I was sitting on a mountain here in Colorado, pondering Oracle optimization and an interesting scenario crossed my feeble mind. As I began to ponder this (I asked the resident marmot, but he must be a SQL*Server expert...), I came up with several questions. Where in memory (sga or other) do the x$ constructs reside? Some of them are 'populated' by reading file-based structures (control file, datafile headers, undo segments). Does this information reside in memory or is it loaded each time the x$ construct is accessed? What happens when these x$constructs begin to consume large amounts of memory? Is there an upper bound? Daniel Fink * This e-mail message, and any files transmitted with it, are confidential and intended solely for the use of the addressee. If this message was not addressed to you, you have received it in error and any copying, distribution or other use of any part of it is strictly prohibited. Any views or opinions presented are solely those of the sender and do not necessarily represent those of the British Geological Survey. The security of e-mail communication cannot be guaranteed and the BGS accepts no liability for claims arising as a result of the use of this medium to transmit messages from or to the BGS. .http://www.bgs.ac.uk * -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Robson, Peter 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: x$ constructs and memory
As I understand it, the X$ information is largely a window onto the control structures in shared memory rather than a summary, aggregation or abstraction. I may be wrong here but that's the way I've always understood it to work. So the structures 'occupy' the same space as the data they're supposed to reflect. If I'm wrong I'd be interested to know the true story. Cheers, Mike HAtely -Original Message- Sent: 29 September 2003 15:10 To: Multiple recipients of list ORACLE-L I was sitting on a mountain here in Colorado, pondering Oracle optimization and an interesting scenario crossed my feeble mind. As I began to ponder this (I asked the resident marmot, but he must be a SQL*Server expert...), I came up with several questions. Where in memory (sga or other) do the x$ constructs reside? Some of them are 'populated' by reading file-based structures (control file, datafile headers, undo segments). Does this information reside in memory or is it loaded each time the x$ construct is accessed? What happens when these x$constructs begin to consume large amounts of memory? Is there an upper bound? Daniel Fink E mail Disclaimer You agree that you have read and understood this disclaimer and you agree to be bound by its terms. The information contained in this e-mail and any files transmitted with it (if any) are confidential and intended for the addressee only. If you have received this e-mail in error please notify the originator. This e-mail and any attachments have been scanned for certain viruses prior to sending but CE Electric UK Funding Company nor any of its associated companies from whom this e-mail originates shall be liable for any losses as a result of any viruses being passed on. No warranty of any kind is given in respect of any information contained in this e-mail and you should be aware that that it might be incomplete, out of date or incorrect. It is therefore essential that you verify all such information with us before placing any reliance upon it. CE Electric UK Funding Company Lloyds Court 78 Grey Street Newcastle upon Tyne NE1 6AF Registered in England and Wales: Number 3476201 -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Hately, Mike (LogicaCMG) 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: x$ constructs and memory
Title: Message You should have asked a grizzly bear. They're much wiser then marmots and they don'trun away that easily. Also, when you see a grizzly bear 100ft away from you and realizethat you only have a camera with you, then you begin to understand that there are biggerworries in this world then the location of database structures.What a grizzly would tell you is that, according to my sources, those tables are storedin the "misc" area of shared pool, which can easily be seen when selected * from V$SGASTAT.Here is what a grizzly would have in mind:POOL NAME BYTES--- -- --shared pool 1M buffer 2098176shared pool KGLS heap 4102928shared pool PX subheap 76920shared pool parameters 32796shared pool free memory 101833708shared pool PL/SQL DIANA 1028660shared pool FileOpenBlock 3476816shared pool PL/SQL MPCODE 547852shared pool library cache 30858108shared pool miscellaneous 11656764shared pool pl/sql source 2708--Mladen GogalaOracle DBA -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Daniel Fink Sent: Monday, September 29, 2003 11:10 AM To: Multiple recipients of list ORACLE-L Subject: x$ constructs and memory I was sitting on a mountain here in Colorado, pondering Oracle optimization and an interesting scenario crossed my feeble mind. As I began to ponder this (I asked the resident marmot, but he must be a SQL*Server expert...), I came up with several questions. Where in memory (sga or other) do the x$ constructs reside? Some of them are 'populated' by reading file-based structures (control file, datafile headers, undo segments). Does this information reside in memory or is it loaded each time the x$ construct is accessed? What happens when these x$constructs begin to consume large amounts of memory? Is there an upper bound? Daniel Fink 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 LLCand 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.
RE: x$ constructs and memory
I was sitting on a mountain here in Colorado, pondering Oracle... You are one twisted individual! :-) Here's some SQL for ya: ALTER brain RECOVER STANDBY consciousness CONTINUE UNTIL CANCEL; -Original Message- Sent: Monday, September 29, 2003 9:10 AM To: Multiple recipients of list ORACLE-L I was sitting on a mountain here in Colorado, pondering Oracle optimization and an interesting scenario crossed my feeble mind. As I began to ponder this (I asked the resident marmot, but he must be a SQL*Server expert...), I came up with several questions. Where in memory (sga or other) do the x$ constructs reside? Some of them are 'populated' by reading file-based structures (control file, datafile headers, undo segments). Does this information reside in memory or is it loaded each time the x$ construct is accessed? What happens when these x$constructs begin to consume large amounts of memory? Is there an upper bound? Daniel Fink -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Orr, Steve 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: x$ constructs and memory
I was sitting on a mountain here in Colorado, pondering Oracle optimization and an interesting scenario crossed my feeble mind. As I began to ponder this (I asked the resident marmot, but he must be a SQL*Server expert...), I came up with several questions. Where in memory (sga or other) do the x$ constructs reside? Some of them are 'populated' by reading file-based structures (control file, datafile headers, undo segments). Does this information reside in memory or is it loaded each time the x$ construct is accessed? What happens when these x$constructs begin to consume large amounts of memory? Is there an upper bound? Daniel Fink Dan, Concerning question 1, I think that most X$ information resides in the SGA, however some X$ tables obviously map the PGA (those on which GV$SQL_BIND_DATA is based are an obvious example - you can only see what refers to your own session, for what I have seen; other examples with cursor-related fixed views). I don't believe that any of them is ever reloaded - they contain data which is really useful to Oracle. For the last point, if you run a count(*) on them you will notice a stunning resemblance to some of your init.ora parameters ... It's less obvious with the V$ views because the V$ views chop any null (not in the SQL acceptance) row off, but the X$ are unrepentant memory arrays, with 0s or similar at unused positions. What I have not checked so far is how an ALTER SYSTEM increasing a parameter affects the SGA. In practice it's a realloc() (functionally speaking). It would seem reasonable to me to have a shared memory segment to hold all parameters which can by dynamically changed. I wouldn't touch it if parameters are decreased, but I would have to realloc it in case of a massive increase. Hmm, I guess that I would allow some spare memory initially, performance penalty would otherwise be severe. Which all makes the 10g dynamic rearrangement quite sensible ... Regards, Stephane Faroult Oriole -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Stephane Faroult 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: x$ constructs and memory
Hi! X$ fixed tables are just interfaces to Oracle database and instance memory structures. In my understanding, there are no separate memory structures built only for serving x$ tables, x$ tables just help humans to read existing instance memory and physical structures more easily. Selecting from x$ table doesn't mean only reading and formatting some memory locations, they can have rules associated with them, for example x$ktfbue and x$ktfbfe (LMT used extents and free extents) require selecting from ts$ for example and of course reading relevant bitmap blocks into buffer cache as well. A lot of memory structures x$ tables reflect are located in SGA fixed area, for example x$ktuxe which a transaction entry table is located there and controlled by init parameter transactions or x$ksqeq which should be depenent on enqueue_resources parameter. There's a table called x$ksmmem which is a map for whole SGA, each line mapping a word from SGA memoy. X$ tables aren't restricted to SGA or physical structures only, they can reflect PGA structs for example as well. Tanel. - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Monday, September 29, 2003 6:10 PM I was sitting on a mountain here in Colorado, pondering Oracle optimization and an interesting scenario crossed my feeble mind. As I began to ponder this (I asked the resident marmot, but he must be a SQL*Server expert...), I came up with several questions. Where in memory (sga or other) do the x$ constructs reside? Some of them are 'populated' by reading file-based structures (control file, datafile headers, undo segments). Does this information reside in memory or is it loaded each time the x$ construct is accessed? What happens when these x$constructs begin to consume large amounts of memory? Is there an upper bound? Daniel Fink -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Tanel Poder 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: x$ constructs and memory
What happens when these x$constructs begin to consume large amounts of memory? Is there an upper bound? Dan, can you think of a scenario where X$ constructs could consume enough memory that DBA marmots like us should meditate on them? OT: Are there many grizzlies in CO? There are plenty here in MT and I always take my pepper spray with me whenever if go to the mountain top to comtemplate things Oracle and otherwise. Got within 100 yards of one and I saw him but he didn't see me. Steve Orr Bozeman, Montana -Original Message- Sent: Monday, September 29, 2003 9:45 AM To: Multiple recipients of list ORACLE-L You should have asked a grizzly bear. They're much wiser then marmots and they don't run away that easily. Also, when you see a grizzly bear 100ft away from you and realize that you only have a camera with you, then you begin to understand that there are bigger worries in this world then the location of database structures. What a grizzly would tell you is that, according to my sources, those tables are stored in the misc area of shared pool, which can easily be seen when selected * from V$SGASTAT. Here is what a grizzly would have in mind: POOLNAMEBYTES --- -- -- shared pool 1M buffer 2098176 shared pool KGLS heap 4102928 shared pool PX subheap 76920 shared pool parameters 32796 shared pool free memory 101833708 shared pool PL/SQL DIANA 1028660 shared pool FileOpenBlock 3476816 shared pool PL/SQL MPCODE 547852 shared pool library cache30858108 shared pool miscellaneous11656764 shared pool pl/sql source2708 -- Mladen Gogala Oracle DBA -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Fink Sent: Monday, September 29, 2003 11:10 AM To: Multiple recipients of list ORACLE-L Subject: x$ constructs and memory I was sitting on a mountain here in Colorado, pondering Oracle optimization and an interesting scenario crossed my feeble mind. As I began to ponder this (I asked the resident marmot, but he must be a SQL*Server expert...), I came up with several questions. Where in memory (sga or other) do the x$ constructs reside? Some of them are 'populated' by reading file-based structures (control file, datafile headers, undo segments). Does this information reside in memory or is it loaded each time the x$ construct is accessed? What happens when these x$constructs -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Orr, Steve 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: x$ constructs and memory
Pepper spray? I would feel much safer with a good Springfield rifle by my side. I'm not sure that a can of pepper spray can stop a 700 lbs animal, charging at 30 MPH, armed with 2 teeth and 5 claws. On short distances, a bear can outrun a deer. -- Mladen Gogala Oracle DBA -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Orr, Steve Sent: Monday, September 29, 2003 12:45 PM To: Multiple recipients of list ORACLE-L Subject: RE: x$ constructs and memory What happens when these x$constructs begin to consume large amounts of memory? Is there an upper bound? Dan, can you think of a scenario where X$ constructs could consume enough memory that DBA marmots like us should meditate on them? OT: Are there many grizzlies in CO? There are plenty here in MT and I always take my pepper spray with me whenever if go to the mountain top to comtemplate things Oracle and otherwise. Got within 100 yards of one and I saw him but he didn't see me. Steve Orr Bozeman, Montana -Original Message- Sent: Monday, September 29, 2003 9:45 AM To: Multiple recipients of list ORACLE-L You should have asked a grizzly bear. They're much wiser then marmots and they don't run away that easily. Also, when you see a grizzly bear 100ft away from you and realize that you only have a camera with you, then you begin to understand that there are bigger worries in this world then the location of database structures. What a grizzly would tell you is that, according to my sources, those tables are stored in the misc area of shared pool, which can easily be seen when selected * from V$SGASTAT. Here is what a grizzly would have in mind: POOLNAMEBYTES --- -- -- shared pool 1M buffer 2098176 shared pool KGLS heap 4102928 shared pool PX subheap 76920 shared pool parameters 32796 shared pool free memory 101833708 shared pool PL/SQL DIANA 1028660 shared pool FileOpenBlock 3476816 shared pool PL/SQL MPCODE 547852 shared pool library cache30858108 shared pool miscellaneous11656764 shared pool pl/sql source2708 -- Mladen Gogala Oracle DBA -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Fink Sent: Monday, September 29, 2003 11:10 AM To: Multiple recipients of list ORACLE-L Subject: x$ constructs and memory I was sitting on a mountain here in Colorado, pondering Oracle optimization and an interesting scenario crossed my feeble mind. As I began to ponder this (I asked the resident marmot, but he must be a SQL*Server expert...), I came up with several questions. Where in memory (sga or other) do the x$ constructs reside? Some of them are 'populated' by reading file-based structures (control file, datafile headers, undo segments). Does this information reside in memory or is it loaded each time the x$ construct is accessed? What happens when these x$constructs -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Orr, Steve 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
Re: x$ constructs and memory
A lot of memory structures x$ tables reflect are located in SGA fixed area, for example x$ktuxe which a transaction entry table is located there and controlled by init parameter transactions Sorry, I was talking about x$ktcxb here, this is the transaction object table in SGA fixed area. x$ktuxe is a window to physical transaction tables in rollback segment headers. Tanel. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Tanel Poder 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: x$ constructs and memory
What I have not checked so far is how an ALTER SYSTEM increasing a parameter affects the SGA. In practice it's a realloc() (functionally speaking). It would seem reasonable to me to have a shared memory segment to hold all parameters which can by dynamically changed. I wouldn't touch it if parameters are decreased, but I would have to realloc it in case of a massive increase. Hmm, I guess that I would allow some spare memory initially, performance penalty would otherwise be severe. Which all makes the 10g dynamic rearrangement quite sensible ... Hi! I think the behaviour depends on which parameter you are changing. If you're changing shared_pool_size to higher size, then just additional extents of memory are allocated and heap header is updated. If you set sort_area_size higher, nothing particular happens, except some maximum is increased in UGA I believe and during next sort you can go up to that limit. Some parameters like enqueue_resources can't be changed in the fly, because they are fixed, they stay in fixed area of SGA, fixed area isn't managed as heap as I understand, it does not have any free or LRU lists, because it's physical structure remains unchanged during the lifetime of an instance. Tanel. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Tanel Poder 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: x$ constructs and memory
With all due respect, I don't believe that it is a fixed area. You can create X$ tables by running certain catalog scripts. I believe that the description of X$ tables is located logically close to the description of the data dictionary, which would mean shared pool, not the fixed one. Now, can we get back to bears? -- Mladen Gogala Oracle DBA -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tanel Poder Sent: Monday, September 29, 2003 1:45 PM To: Multiple recipients of list ORACLE-L Subject: Re: x$ constructs and memory What I have not checked so far is how an ALTER SYSTEM increasing a parameter affects the SGA. In practice it's a realloc() (functionally speaking). It would seem reasonable to me to have a shared memory segment to hold all parameters which can by dynamically changed. I wouldn't touch it if parameters are decreased, but I would have to realloc it in case of a massive increase. Hmm, I guess that I would allow some spare memory initially, performance penalty would otherwise be severe. Which all makes the 10g dynamic rearrangement quite sensible ... Hi! I think the behaviour depends on which parameter you are changing. If you're changing shared_pool_size to higher size, then just additional extents of memory are allocated and heap header is updated. If you set sort_area_size higher, nothing particular happens, except some maximum is increased in UGA I believe and during next sort you can go up to that limit. Some parameters like enqueue_resources can't be changed in the fly, because they are fixed, they stay in fixed area of SGA, fixed area isn't managed as heap as I understand, it does not have any free or LRU lists, because it's physical structure remains unchanged during the lifetime of an instance. Tanel. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Tanel Poder 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: x$ constructs and memory
Mladen: I hope you are not kidding.. X$ table (!) definitions are defined in the source code and you can not create/update/delete them. However there are some undocumented procudures , thru which you can reset certain tables. Regards, Gopal - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Monday, September 29, 2003 11:54 PM With all due respect, I don't believe that it is a fixed area. You can create X$ tables by running certain catalog scripts. I believe that the description of X$ tables is located logically close to the description of the data dictionary, which would mean shared pool, not the fixed one. Now, can we get back to bears? -- Mladen Gogala Oracle DBA -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tanel Poder Sent: Monday, September 29, 2003 1:45 PM To: Multiple recipients of list ORACLE-L Subject: Re: x$ constructs and memory What I have not checked so far is how an ALTER SYSTEM increasing a parameter affects the SGA. In practice it's a realloc() (functionally speaking). It would seem reasonable to me to have a shared memory segment to hold all parameters which can by dynamically changed. I wouldn't touch it if parameters are decreased, but I would have to realloc it in case of a massive increase. Hmm, I guess that I would allow some spare memory initially, performance penalty would otherwise be severe. Which all makes the 10g dynamic rearrangement quite sensible ... Hi! I think the behaviour depends on which parameter you are changing. If you're changing shared_pool_size to higher size, then just additional extents of memory are allocated and heap header is updated. If you set sort_area_size higher, nothing particular happens, except some maximum is increased in UGA I believe and during next sort you can go up to that limit. Some parameters like enqueue_resources can't be changed in the fly, because they are fixed, they stay in fixed area of SGA, fixed area isn't managed as heap as I understand, it does not have any free or LRU lists, because it's physical structure remains unchanged during the lifetime of an instance. Tanel. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Tanel Poder 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: K Gopalakrishnan 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
Re: RE: x$ constructs and memory
i think there are memory structurse that oracle isnt telling us about. wouldnt surprise me if the x$ tables are stored in some place that is not documented. From: Mladen Gogala [EMAIL PROTECTED] Date: 2003/09/29 Mon PM 02:24:46 EDT To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Subject: RE: x$ constructs and memory With all due respect, I don't believe that it is a fixed area. You can create X$ tables by running certain catalog scripts. I believe that the description of X$ tables is located logically close to the description of the data dictionary, which would mean shared pool, not the fixed one. Now, can we get back to bears? -- Mladen Gogala Oracle DBA -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tanel Poder Sent: Monday, September 29, 2003 1:45 PM To: Multiple recipients of list ORACLE-L Subject: Re: x$ constructs and memory What I have not checked so far is how an ALTER SYSTEM increasing a parameter affects the SGA. In practice it's a realloc() (functionally speaking). It would seem reasonable to me to have a shared memory segment to hold all parameters which can by dynamically changed. I wouldn't touch it if parameters are decreased, but I would have to realloc it in case of a massive increase. Hmm, I guess that I would allow some spare memory initially, performance penalty would otherwise be severe. Which all makes the 10g dynamic rearrangement quite sensible ... Hi! I think the behaviour depends on which parameter you are changing. If you're changing shared_pool_size to higher size, then just additional extents of memory are allocated and heap header is updated. If you set sort_area_size higher, nothing particular happens, except some maximum is increased in UGA I believe and during next sort you can go up to that limit. Some parameters like enqueue_resources can't be changed in the fly, because they are fixed, they stay in fixed area of SGA, fixed area isn't managed as heap as I understand, it does not have any free or LRU lists, because it's physical structure remains unchanged during the lifetime of an instance. Tanel. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Tanel Poder 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: [EMAIL PROTECTED] 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
RE: x$ constructs and memory
You are right. This is what has confused my script, as taken from SQL.BSQ: create table kottbx$ of kottbx /* additional type table */ oid '00010042' / -- Mladen Gogala Oracle DBA -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of K Gopalakrishnan Sent: Monday, September 29, 2003 3:30 PM To: Multiple recipients of list ORACLE-L Subject: Re: x$ constructs and memory Mladen: I hope you are not kidding.. X$ table (!) definitions are defined in the source code and you can not create/update/delete them. However there are some undocumented procudures , thru which you can reset certain tables. Regards, Gopal - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Monday, September 29, 2003 11:54 PM With all due respect, I don't believe that it is a fixed area. You can create X$ tables by running certain catalog scripts. I believe that the description of X$ tables is located logically close to the description of the data dictionary, which would mean shared pool, not the fixed one. Now, can we get back to bears? -- Mladen Gogala Oracle DBA -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tanel Poder Sent: Monday, September 29, 2003 1:45 PM To: Multiple recipients of list ORACLE-L Subject: Re: x$ constructs and memory What I have not checked so far is how an ALTER SYSTEM increasing a parameter affects the SGA. In practice it's a realloc() (functionally speaking). It would seem reasonable to me to have a shared memory segment to hold all parameters which can by dynamically changed. I wouldn't touch it if parameters are decreased, but I would have to realloc it in case of a massive increase. Hmm, I guess that I would allow some spare memory initially, performance penalty would otherwise be severe. Which all makes the 10g dynamic rearrangement quite sensible ... Hi! I think the behaviour depends on which parameter you are changing. If you're changing shared_pool_size to higher size, then just additional extents of memory are allocated and heap header is updated. If you set sort_area_size higher, nothing particular happens, except some maximum is increased in UGA I believe and during next sort you can go up to that limit. Some parameters like enqueue_resources can't be changed in the fly, because they are fixed, they stay in fixed area of SGA, fixed area isn't managed as heap as I understand, it does not have any free or LRU lists, because it's physical structure remains unchanged during the lifetime of an instance. Tanel. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Tanel Poder 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
RE: x$ constructs and memory
Hi Daniel and list, There are two types of X$ row sources. X$ tables export in-memory data structures that are inherently tabular, and X$ interfaces that call functions to return data is non-tabular, or not memory resident. For example, the array of structs in the SGA representing processes is exported as the X$ table X$KSUPR. Not all of the struct members are exported as columns, but all of the rows are exported. There is a freelist, implemented as a header that points to the first free slot in the array, and a member of each struct to point to the next free slot. The 'process allocation' latch protects this freelist. The most obvious example of an X$ interface to return non-tabular data is X$KSMSP, which returns one row for each chunk of memory in the shared pool. (There are similar X$ interfaces for other memory heaps). As you may know, heaps are implemented as a heap descriptor and linked list of extents, and within each extent there is a linked list of chunks. So what is done is that when the X$ interface is queried these linked lists are navigated (under the protection of the relevant latch if necessary) an a array is built in the CGA (part of the PGA) from which rows are then returned by the row source. An example of an X$ interface that returns data that is not memory resident is X$KCCLE, which returns one row for each log file member entry in the controlfile. In fact, all the X$KCC* interfaces read data directly from the controlfile. Similarly, the X$KTFB* interfaces return LMT extent information - from the bitmap blocks (for free extents) and from the segment header and extent map blocks (for used extents). Some X$ tables have become X$ interfaces in recent versions, for example X$KTCXB and X$KSQRS. These correspond to the transactions and enqueue resources arrays respectively. The reason is that they are no longer fixed arrays. Instead they are segmented arrays that can be dynamically extended by adding discontiguous chunks of shared pool memory to the array. The freelists and latching for these arrays in unchanged however. All you will notice is that the ADDR column of the X$ output now returns addresses which map into your PGA rather than the SGA. In fact, that is in general a good way to work out whether you are looking at an X$ table or an X$ interface. @ Regards, @ Steve Adams @ http://www.ixora.com.au/ - For DBAs @ http://www.christianity.net.au/ - For all -Original Message- Daniel Fink Sent: Tuesday, 30 September 2003 1:10 AM To: Multiple recipients of list ORACLE-L I was sitting on a mountain here in Colorado, pondering Oracle optimization and an interesting scenario crossed my feeble mind. As I began to ponder this (I asked the resident marmot, but he must be a SQL*Server expert...), I came up with several questions. Where in memory (sga or other) do the x$ constructs reside? Some of them are 'populated' by reading file-based structures (control file, datafile headers, undo segments). Does this information reside in memory or is it loaded each time the x$ construct is accessed? What happens when these x$constructs begin to consume large amounts of memory? Is there an upper bound? Daniel Fink -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Steve Adams 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: x$ constructs and memory
Hi Steve, Thank you for your explanation, but I got few additional questions ig you got a chance to answer: (There are similar X$ interfaces for other memory heaps). As you may know, heaps are implemented as a heap descriptor and linked list of extents, and within each extent there is a linked list of chunks. So what is done is that Is there a linked list for *all* chunks in a heap as well, regardless of their type, or is there only a list for each type of chunks, free and recreatable ones? Am I correct that permanent chunks don't have to be in any list because they're never deallocated and they should stay in same place anyway? Some X$ tables have become X$ interfaces in recent versions, for example X$KTCXB and X$KSQRS. These correspond to the transactions and enqueue resources arrays respectively. The reason is that they are no longer fixed arrays. Instead they are segmented arrays that can be dynamically extended by adding discontiguous chunks of shared pool memory to the array. The freelists and latching for these arrays in unchanged however. All you will notice is that the ADDR column of the X$ output now returns addresses which map into your PGA rather than the SGA. In fact, that is in general a good way to work out whether you are looking at an X$ table or an X$ interface. I've noticed that some tables such x$ktcxb and x$kturd return the same ADDR value for all it's rows. I've always thought, that it means a subroutine or function is returning the results instead of a direct read from array, as you described. But x$ksqrs does return different ADDRs for each row (9.2.0.4 on W2K). Am I on wrong tracks here? Thank you! Tanel. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Tanel Poder 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: x$ constructs and memory
Hi Tanel, Answers inline ... As you may know, heaps are implemented as a heap descriptor and linked list of extents, and within each extent there is a linked list of chunks. Is there a linked list for *all* chunks in a heap as well, regardless of their type, or is there only a list for each type of chunks, free and recreatable ones? Am I correct that permanent chunks don't have to be in any list because they're never deallocated and they should stay in same place anyway? There is an invariant chunk header that identifies the chunk class and implements the linked list of all chunks in an extent. Then there is a class specific header that in the case of permanent, free and recreatable chunks has a pointer for another linked list. I'm not sure why the permanent linked list is needed (other than to make heapdumps efficient). The free and recreatable chunks obviously need theirs for the freelists and LRU lists. Some X$ tables have become X$ interfaces in recent versions, for example X$KTCXB and X$KSQRS. [snip] All you will notice is that the ADDR column of the X$ output now returns addresses which map into your PGA rather than the SGA. In fact, that is in general a good way to work out whether you are looking at an X$ table or an X$ interface. I've noticed that some tables such x$ktcxb and x$kturd return the same ADDR value for all it's rows. I've always thought, that it means a subroutine or function is returning the results instead of a direct read from array, as you described. But x$ksqrs does return different ADDRs for each row (9.2.0.4 on W2K). Am I on wrong tracks here? The implementation of these row sources varies somewhat. Some of them, like X$KSMSP, need to buffer their results in the CGA because the structure might change before the next fetch; others like these ones you've mentioned do not need to, but some of them do so anyway. @ Regards, @ Steve Adams @ http://www.ixora.com.au/ - For DBAs @ http://www.christianity.net.au/ - For all -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Steve Adams 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).
