RE: X$ksmsp (OSEE on Solaris 8)

  • From: "Schultz, Charles" <sac@xxxxxxxxxxxxx>
  • To: "Mladen Gogala" <gogala@xxxxxxxxxxxxx>, <duncan.lawie@xxxxxxxxxxxxxxxxx>
  • Date: Tue, 27 Jun 2006 09:30:11 -0500

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


Other related posts: