Re: GLOBAL_STATS

Holger Baer <holger.baer_at_science-computing.de> wrote in message news:<cklh1l$rfp$1_at_news.BelWue.DE>...
> Martin Preiss wrote:
> > Holger Baer <holger.baer_at_science-computing.de> wrote in message news:<ckj5pl$mp$1_at_news.BelWue.DE>...
> >
> >
> > Hi Holger,
> >
> > thank you for your comment.
> >
> > it seems that my conclusions were indeed a little bit fragile ...
> >
> > The monitoring was set to yes (i think that's default in 10g), the
> > tables had been changed, and there were no statistics - while the
> > system had statistics for other CTAS-tables that had been created
> > about the same time. The only other difference i could see in
> > DBA_TABLES was the different entry for GLOBAL_STATS. So i assumed that
> > the missing statistics and the GLOBAL_STATS=NO-entry were linked
> > together, and that there were no statistics because of the
> > GLOBAL_STATS-Setting - which is wrong as i see now: today i have
> > statistics on most of the tables and the GLOBAL_STATS have changed to
> > yes. I guess the GATHER_STATS_JOB did his job in the maintenance
> > window. So everything is fine now.
> >
> > But i still don't know what's the meaning of GLOBAL_STATS=NO for a
> > non-partitioned table. The database reference seems to say that it's
> > only of interest for partitioned tables. Or do i misread the
> > documentation?
> >
> > Kind regards
> >
> > Martin Preiss
>
> Oh, right I forgot to mention - the automatic statistics gathering
> is somewhen during the night by default. Maybe in the first run
> not everything got analyzed because the maintainance window was
> exceeded. I haven't got round to learn all the details regarding
> this automatic analytics thing (how to configure the maintainance
> window for a start. Shouldn't be that hard, though).
>
> And my first reaction to the global_stats=no would be: why bother
> if you don't have a problem? Not very professional ;-), so I did some
> digging in catalog.sql: If I'm able to count right, then the global_stats
> field in the end is nothing more than
>
> select decode (bitand(flags, 512), 0 'NO', 'YES') from tab$
>
> So I'd say (until someone with more insight into this things than me corrects me)
> this flags field, or at least part of it gets set only after statistics
> have been gathered, so the initial value before the first analyze is
> indetermined.
>
> Cheers,
>
> Holger

Hi Holger,

sounds convincing.

Thank you

Martin Preiss Received on Fri Oct 15 2004 - 02:56:08 CDT