The problem persists in 9.2 and 10.1 beta.
Probably worth the OP raising a TAR so
that Oracle Corp. can bug it and fix it.
--
Regards
Jonathan Lewis
http://www.jlcomp.demon.co.uk
The educated person is not the person
who can answer the questions, but the
person who can question the answers -- T. Schick Jr
One-day tutorials:
http://www.jlcomp.demon.co.uk/tutorial.html
____Belgium__November (EOUG event - "Troubleshooting")
____UK_______December (UKOUG conference - "CBO")
Three-day seminar:
see http://www.jlcomp.demon.co.uk/seminar.html
____UK___November
The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html
"Wolfgang Breitling" <john.doe_at_aol.com> wrote in message
news:Xns9423CED40E3FAbreitliwcentrexcccom_at_198.161.157.145...
>
> I did some tests and found
>
> a) dbms_stats.delete_index_stats and analyze index delete statistics
do
> exactly the same thing as far as removing the statistics from
> xxx_indexes. The update statement to sys.ind$, including the values,
are
> identical from both commands
>
> b) dbms_stats.delete_xxx_stats does not invalidate the index
statistics
> present in the library cache, while analyze ... delete statistics
does.
> I tested it with delete_index_stats, delete_table_stats and
> delete_schema_stats. Although I have not tested it for
> delete_database_stats, I see no reason to believe that matters would
be
> different there. The deleted table statistics become effective
> immediately but the index statistics linger. A select from
xxx_indexes
> shows the updated values, i.e. nulls for the statistics values, but
the
> CBO is using what is cached in the library cache. When you follow
the
> dbms_stats.delete_xxx_stats with a flush shared_pool then the CBO
uses
> its statistics defaults for the index instead of the old memorized
> statistics.
>
Received on Sun Nov 02 2003 - 11:20:28 CST
