| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: dc_used_extents ,dc_free_extents and dc_histogram_defs
Well, you could have joined the beta program if you were THAT
interested, Mladen!
Ducks and runs. :)
Pete
"Controlling developers is like herding cats."
Kevin Loney, Oracle DBA Handbook
"Oh no, it's not. It's much harder than that!"
Bruce Pihlamae, long-term Oracle DBA
-----Original Message-----
Mladen Gogala
Sent: Tuesday, December 09, 2003 6:59 AM
To: Multiple recipients of list ORACLE-L
Larry Ellison has publicly stated that his goal is to produce a database
with
less then 100 tunable parameters. Allegedly, he came rather close with
10g.
As far as 10g is concerned, I'm rather disappointed with the marketing
hype
being created with oracle not making an early version available. I don't
plan
on migrating to 10g until I learn it well and if some oracle sales guy
tries to exert pressure on me to migrate, he will get a very stable sign
used by English archers after the battle at Agincourt to signify that
they
still have all the fingers needed to operate a longbow. I've had my fill
of
white papers and articles and now I want to see the software.
On 12/08/2003 02:24:33 PM, Rajesh.Rao_at_jpmchase.com wrote:
>
> .. And there used to be all these dc_ parameters that one could set,
> giving the dba control over the dictionary cache, which was not a part
of
> the shared pool. And then came Oracle V7, with the shared_pool_size,
> wresting that control.
>
> Regards
>
>
>
>
>
> Mladen Gogala
> <mladen_at_wangtr To: Multiple recipients
of list ORACLE-L <ORACLE-L_at_fatcity.com>
> ading.com> cc:
> Sent by: Subject: Re:
dc_used_extents ,dc_free_extents and dc_histogram_defs
> ml-errors_at_fatc
> ity.com
>
>
> 12/08/2003
> 01:29 PM
> Please respond
> to ORACLE-L
>
>
>
>
>
>
> Well, once upon a time, in a land far, far away, there was Oracle V6
with
> something called "TPO", which was essentially row locking + PL/SQL V1
(no
> stored procedures). My guess is that Cary Millsap, Anjo Kolk, Steve
> Feuerstein
> and Howard Rogers know a thing or two about the Jurassic period in
the
> database
> development. BTW, that was also when buffer hit ratio was invented.
The
> entries that you see are remnants from oracle v6, together with the
table
> called "V$ROWCACHE" and are both religiously maintained for the
> compatibility
> reasons, because Oracle Corp. doesn't want to disappoint all those who
are
> still running V6. Even compatibility with V5 is still maintained. In
Oracle
> 5.1.22,
> dictionary views weren't called "user_tables" and "user_objects", they
were
> called
> "tab" (user_tables) and cat (from "CATALOG", replaced with
"USER_OBJECTS").
> The term
> "CATALOG" was directory command on Apple IIe (6502, later Z80) with
100k
> floppies,
> computer immensly popular at the time, and I believe that is why the
first
> implementation of "user_objects" was called "catalog". Now, let's fast
> forward to the
> present time and Oracle 9.2.0.4. Do "Select * from tab" and "select *
from
> cat".
> You'll be surprised. For all those still running V5.1.22 with forms
2.0 and
> 2.3,
> the world is not over yet.
>
> On 12/08/2003 12:39:30 PM, Guang Mei wrote:
> > Hi:
> >
> > I am reading some statspack reports from our 8173 DB (on Sun
Solaris) and
> > found some of "Dictionary Cache Stats" are pretty high (much higher
than
> > 2%). I notice that "Pct Get Miss" for dc_used_extents
,dc_free_extents
> and
> > dc_histogram_defs are high (the second column data below). Is this
> > something I need to pay attention in terms of doing performance
> > optimization? If yes, what are the things (regarding "Dictionary
Cache")
> > that I should look in order to improve the performance?
> >
> > TIA.
> >
> > Guang
> >
> > ps, here are some "dc_" stats from my reports and a copy of actual
report
> > (partial):
> >
> > ----------
> > bash-2.03$ grep "dc_used_extents" sp_*
> > sp_681_682.lst:dc_used_extents 136 83.1 0
> > 136 3,840 100
> > sp_682_683.lst:dc_used_extents 124 81.5 0
> > 124 3,918 99
> > sp_683_684.lst:dc_used_extents 34 58.8 0
> > 34 3,924 100
> > sp_684_685.lst:dc_used_extents 0 0
> > 0 3,924 100
> > sp_685_686.lst:dc_used_extents 37 64.9 0
> > 37 3,935 99
> > sp_686_687.lst:dc_used_extents 12 100.0 0
> > 12 3,947 100
> > sp_687_688.lst:dc_used_extents 18 100.0 0
> > 18 3,965 100
> > sp_688_689.lst:dc_used_extents 26 100.0 0
> > 26 3,991 100
> > sp_689_690.lst:dc_used_extents 14 100.0 0
> > 14 4,005 100
> > sp_690_691.lst:dc_used_extents 16 100.0 0
> > 16 4,021 100
> > sp_691_692.lst:dc_used_extents 29 100.0 0
> > 29 4,050 100
> > sp_692_693.lst:dc_used_extents 1 100.0 0
> > 1 4,051 99
> > sp_693_694.lst:dc_used_extents 1,118 51.2 0
> > 1,118 4,077 100
> > sp_694_695.lst:dc_used_extents 1,294 99.8 0
> > 1,294 5,365 100
> > sp_695_696.lst:dc_used_extents 2,031 13.2 0
> > 2,031 3,870 72
> > sp_696_697.lst:dc_used_extents 1,195 98.5 0
> > 1,195 5,029 94
> > sp_697_698.lst:dc_used_extents 44 100.0 0
> > 44 5,073 94
> > sp_698_699.lst:dc_used_extents 0 0
> > 0 5,073 94
> > sp_699_700.lst:dc_used_extents 1,359 8.5 0
> > 1,359 568 33
> > bash-2.03$ grep "dc_free_extents" sp_*
> > sp_681_682.lst:dc_free_extents 395 34.4 166
0.0
> > 362 4,071 82
> > sp_682_683.lst:dc_free_extents 507 27.2 160
0.0
> > 342 4,100 82
> > sp_683_684.lst:dc_free_extents 75 32.0 20
0.0
> > 64 4,104 82
> > sp_684_685.lst:dc_free_extents 12 0.0 0
> > 0 4,104 82
> > sp_685_686.lst:dc_free_extents 95 35.8 24
0.0
> > 83 4,114 83
> > sp_686_687.lst:dc_free_extents 47 25.5 12
0.0
> > 36 4,114 83
> > sp_687_688.lst:dc_free_extents 64 23.4 18
0.0
> > 52 4,111 82
> > sp_688_689.lst:dc_free_extents 93 24.7 32
0.0
> > 78 4,108 82
> > sp_689_690.lst:dc_free_extents 54 25.9 14
0.0
> > 42 4,108 82
> > sp_690_691.lst:dc_free_extents 63 23.8 21
0.0
> > 48 4,107 82
> > sp_691_692.lst:dc_free_extents 109 25.7 42
0.0
> > 85 4,106 82
> > sp_692_693.lst:dc_free_extents 15 6.7 1
0.0
> > 3 4,106 82
> > sp_693_694.lst:dc_free_extents 1,624 24.0 596
0.0
> > 1,574 3,924 79
> > sp_694_695.lst:dc_free_extents 3,398 31.3 1,307
0.0
> > 3,288 3,696 74
> > sp_695_696.lst:dc_free_extents 2,043 86.3 268
0.0
> > 2,031 5,191 99
> > sp_696_697.lst:dc_free_extents 1,209 1.7 1,177
0.0
> > 1,197 4,034 77
> > sp_697_698.lst:dc_free_extents 55 0.0 44
0.0
> > 44 3,990 76
> > sp_698_699.lst:dc_free_extents 12 0.0 0
> > 0 3,990 79
> > sp_699_700.lst:dc_free_extents 1,384 90.4 115
0.0
> > 1,371 1,564 94
> > bash-2.03$ grep "dc_histogram_defs" sp_*
> > sp_681_682.lst:dc_histogram_defs 49 79.6 0
> > 25 128 21
> > sp_682_683.lst:dc_histogram_defs 47 29.8 0
> > 0 142 23
> > sp_683_684.lst:dc_histogram_defs 186 51.6 0
> > 119 238 39
> > sp_684_685.lst:dc_histogram_defs 1,756 91.3 0
> > 1,699 1,841 100
> > sp_685_686.lst:dc_histogram_defs 2,191 1.1 0
> > 59 1,865 100
> > sp_686_687.lst:dc_histogram_defs 144 0.0 0
> > 0 1,865 100
> > sp_687_688.lst:dc_histogram_defs 8,322 0.0 0
> > 18 1,865 100
> > sp_688_689.lst:dc_histogram_defs 5 0.0 0
> > 0 1,865 100
> > sp_689_690.lst:dc_histogram_defs 13 0.0 0
> > 0 1,865 100
> > sp_690_691.lst:dc_histogram_defs 36 0.0 0
> > 0 1,865 100
> > sp_691_692.lst:dc_histogram_defs 212 1.4 0
> > 70 1,868 100
> > sp_692_693.lst:dc_histogram_defs 559 0.0 0
> > 76 1,868 100
> > sp_693_694.lst:dc_histogram_defs 127,682 0.3 0
> > 37 1,821 96
> > sp_694_695.lst:dc_histogram_defs 197,927 0.1 0
> > 27 1,902 100
> > sp_695_696.lst:dc_histogram_defs 167,818 0.5 0
> > 44 1,826 95
> > sp_696_697.lst:dc_histogram_defs 137,702 0.0 0
> > 0 1,886 99
> > sp_697_698.lst:dc_histogram_defs 45,995 0.0 0
> > 0 1,886 99
> > sp_698_699.lst:dc_histogram_defs 141,411 0.0 0
> > 0 1,886 99
> > sp_699_700.lst:dc_histogram_defs 74,885 0.8 0
> > 22 362 99
> >
> > -----------
> >
> >
> > ->"Get Requests", "Pct Get Miss" and "Avg Slps/Miss" are statistics
for
> > willing-to-wait latch get requests
> > ->"NoWait Requests", "Pct NoWait Miss" are for no-wait latch get
requests
> > ->"Pct Misses" for both should be very close to 0.0
> >
> > Pct Avg
> > Pct
> > Get Get Slps
NoWait
> > NoWait
> > Latch Name Requests Miss /Miss
Requests
> > Miss
> > ----------------------------- -------------- ------ ------
Mladen Gogala
Oracle DBA
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: mladen_at_wangtrading.com 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: ListGuru_at_fatcity.com (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: Pete Sharman INET: peter.sharman_at_oracle.com 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: ListGuru_at_fatcity.com (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).Received on Mon Dec 08 2003 - 16:24:32 CST
 |
 |