Re: Index Compression

On Wed, 16 Nov 2005 bdbafh_at_gmail.com wrote:

> For starters, what version/patchset are you working against? (e.g.
> 9.2.0.7, 10.1.0.4)

Several, 8.1.7.4 primarily.

> Have you considered the following:
> - column re-ordering to maximize compression
> - effect of column re-ordering upon the clustering factor for the
> re-ordered index

Siebel. Canned app. Touch the schema in any significant way and your support evaporates.

> - using a "compute statistics" clause when rebuilding the index
> (inline).

Siebel is violently anti-CBO and advocates extensive "analyze... DELETE statistics."

> If you are rebuilding indexes you might want to consider going the
> route of setting the workarea_policy to manual, upping the dbfmbrc and
> hiking the sort_area_size to a largisfh value to reduce the amount of
> time spent on such activities. This practice was recently trashed by
> some posters here ... as it will likely be again.
> For some undexplained reason, hiking the dbfmbrc to 128 for an 8 KB
> block size with a sort area size of 128 MB gets the
> adreniline/testosterone going for me - probably the same reason that I
> prefer to run power tools that are wired for 220V instead of 110V.

I'm not familiar with these parameters; will review. Bouncing for init.ora changes can be very problematic.

   / Charles J. Fisher   | A bad design with a good presentation is doomed  /
  /  cfisher_at_rhadmin.org | eventually. A good design with a bad            /
 /   http://rhadmin.org  | presentation is doomed immediately.            /
--------------------------------------------------------------------------