X$ksmsp (OSEE 10.2.0.2 on Solaris 8) 2006-06-28 - By eagle fan
hi Gogala:
Do you have some meterials or test for this? I mean "selecting from tables
like that usually means to acquire a latch for
each row. "
Does querying each x$ table need to hold latch?
Thanks
On 6/27/06, Mladen Gogala <gogala@(protected)> wrote:
>
>
> 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 (See ORA-0600.ora-code.com) and ORA-7445 (See ORA-7445.ora-code.com) errors. Parameter will
> eventually
> become useful in the Oracle21R3.
>
>
> --
> Mladen Gogala
> http://www.mgogala.com
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>
--
Eagle Fan
Oracle DBA
hi Gogala:<br><br>Do you have some meterials or test for this? I mean "
;selecting from tables like that usually means to acquire a latch for<br>each
row. "<br><br>Does querying each x$ table need to hold latch? <br>
<br>Thanks<br><br><div><span class="gmail_quote">On 6/27/06, <b class="gmail
_sendername">Mladen Gogala</b> <<a href="mailto:gogala@(protected)">gogala
@(protected)</a>> wrote:</span><blockquote class="gmail_quote" style=
"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding
-left: 1ex;">
<br>On 06/27/2006 08:12:07 AM, Lawie, Duncan wrote:<br>> Charles,<br>><br
>> 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.
<br>><br>> 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.<br>><br>> Cheers,<br>> Duncan.<br>
><br><br><br>Guys, selecting from tables like that usually means to acquire
a latch for<br>each row. If the table points to the real chunks of SGA, those
chunks must<br>be protected from changing during select. Every one of them.
That means latch.
<br><br>I don't see any pressing need to use the table, especially not if the
table<br>is undocumented. I must say that Oracle10gR2 is marvelously
instrumented and<br>equipped with the documented performance tables. It misses
just one thing:
<br>"run my stuff faster" parameter, which will probably be available
in the next<br>release as an undocumented parameter, will be tweaked by the
bravest among us,<br>causing, of course, ORA-0600 (See ORA-0600.ora-code.com) and ORA-7445 (See ORA-7445.ora-code.com)
errors. Parameter will eventually
<br>become useful in the Oracle21R3.<br><br><br>--<br>Mladen Gogala<br><a href=
"http://www.mgogala.com">http://www.mgogala.com</a><br><br>--<br><a href="http:/
/www.freelists.org/webpage/oracle-l">http://www.freelists.org/webpage/oracle-l
</a><br><br><br></blockquote></div><br><br clear="all"><br>-- <br>Eagle Fan<br>
<br>Oracle DBA
|
|
