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
