Lee,
Definitely sounds like bug 766095. It isn't listed in
the patchset readme file for 8.0.5.2.1 so it doesn't
appear to be fixed in 8.0.5, although there might be a
patchset exception for your platform (check with
support).
The workaround is to estimate statistics using a
percentage which brings the total amount of data
analyzed under 4GB to avoid the overflow issue which
results in the incorrect value, keeping in mind that
the value produced by estimating may not be 100%
accurate either.
HTH,
Lee,
Definitely sounds like bug 766095. It isn't listed in
the patchset readme file for 8.0.5.2.1 so it doesn't
appear to be fixed in 8.0.5, although there might be a
patchset exception for your platform (check with
support).
The workaround is to estimate statistics using a
percentage which brings the total amount of data
analyzed under 4GB to avoid the overflow issue which
results in the incorrect value, keeping in mind that
the value produced by estimating may not be 100%
accurate either.
HTH,
- Anita
- Robertson Lee - lerobe <lerobe_at_acxiom.co.uk>
wrote:
> OK here goes and thanks for the response
>
> Definitely one table and "from the top" :-)
>
> DB Block size = 8192
> Avg. Row Size = 6
> Num Rows = 57351031
> Pct free = 0
> Pct Used = 40
> Table definition (column names removed) =
>
> Type
> -------- ----
> NOT NULL NUMBER(9)
> NOT NULL NUMBER(9)
> NOT NULL NUMBER(9)
> NOT NULL NUMBER(9)
> NUMBER(9)
> CHAR(2)
> CHAR(3)
> CHAR(4)
> VARCHAR2(100)
> VARCHAR2(60)
> VARCHAR2(50)
> VARCHAR2(60)
> VARCHAR2(7)
> NUMBER(6)
> NUMBER(6)
> NUMBER(9)
> DATE
> VARCHAR2(50)
>
> A - ha I think the penny drops - how on earth could
> this be right - average
> row length of 6 with a table definition like this.
> Is this the problem. The
> average row length must be wrong, yet the table was
> definitely analyzed with
> compute statistics.!!!!
>
>
> Lee Robertson
>
>
> The information contained in this communication is
> confidential, is intended only for the use of the
> recipient
> named above, and may be legally privileged. If the
> reader
> of this message is not the intended recipient, you
> are
> hereby notified that any dissemination, distribution
> or
> copying of this communication is strictly
> prohibited.
> If you have received this communication in error,
> please
> re-send this communication to the sender and delete
> the
> original message or any copy of it from your
> computer
> system.
> --
> Please see the official ORACLE-L FAQ:
> http://www.orafaq.com
> --
> Author: Robertson Lee - lerobe
> INET: lerobe_at_acxiom.co.uk
>
> Fat City Network Services -- (858) 538-5051 FAX:
> (858) 538-5051
> San Diego, California -- Public Internet
> access / Mailing Lists
>
> 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).
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: A. Bardeen
INET: abardeen1_at_yahoo.com
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
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 Tue May 15 2001 - 10:01:56 CDT
