What is the alternative to track down memory issues? Sure, one could use DMA (Direct Memory Access), but I for one am not there yet. If there is a better way to diagnose and resolve memory issues, I am all ears (or rather, eyes *grin*). -----Original Message----- From: Mladen Gogala [mailto:gogala@xxxxxxxxxxxxx] Sent: Tuesday, June 27, 2006 8:08 AM To: duncan.lawie@xxxxxxxxxxxxxxxxx Cc: Schultz, Charles; Hallas, John, Tech Dev; oracle-l@xxxxxxxxxxxxx Subject: Re: X$ksmsp (OSEE 10.2.0.2 on Solaris 8) On 06/27/2006 08:12:07 AM, Lawie, Duncan wrote: > Charles, > > I agree that a row in x$ksmsp should equal a single memory chunk - but is it possible that there is a chunk with an outrageous value? I don't recall that particular case, but I have seen x$ksmsp sum to values significantly larger than the size of the SGA. > > In addition, I have also had significant performance issues on a production system when selecting on this table in a very busy system which is severely fragmented. > > Cheers, > Duncan. > Guys, selecting from tables like that usually means to acquire a latch for each row. If the table points to the real chunks of SGA, those chunks must be protected from changing during select. Every one of them. That means latch. I don't see any pressing need to use the table, especially not if the table is undocumented. I must say that Oracle10gR2 is marvelously instrumented and equipped with the documented performance tables. It misses just one thing: "run my stuff faster" parameter, which will probably be available in the next release as an undocumented parameter, will be tweaked by the bravest among us, causing, of course, ORA-0600 and ORA-7445 errors. Parameter will eventually become useful in the Oracle21R3. -- Mladen Gogala http://www.mgogala.com -- //www.freelists.org/webpage/oracle-l