DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=RJl55g+lQY0lEkVig89T+j3lNk0hEZvsOVtBpt0tTcKy1VMxHdXpuxs/D497Y6TJNwkllTcM6zDhh+RvocV3o/QIL8fW4gScQzhQuE0eQCXthwdItId+rxfxvFkYqiIxFHn/2TV+r6cXvbLL+nn5If+bbbt4B08kOEixDN36GYo=
Message-ID: <d6f0def50602021606i3fefcad9y2d5b6f0b97efd42c@mail.gmail.com>
Date: Fri, 3 Feb 2006 00:06:55 +0000
From: Jurijs Velikanovs <j.velikanovs@gmail.com>
Subject: Re: Index compression on Oracle 9.2
Cc: oracle-l@freelists.org
In-Reply-To: <7ED53A68952D3B4C9540B4EFA5C76E360165826D@CWYMSX04.Corp.Acxiom.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
References: <7ED53A68952D3B4C9540B4EFA5C76E360165826D@CWYMSX04.Corp.Acxiom.net>
Sender: oracle-l-bounce@freelists.org
Errors-To: oracle-l-bounce@freelists.org
Precedence: normal
Reply-To: j.velikanovs@gmail.com

I agree with you.
In that case I would like emphasize the fact what many Oracle users
think that compressed tables are the same (or almost the same) feature
as compressed indexes.
I would say compressed table feature can be useful in 0.002% cases, at
the same time compressed indexes would be good in 5% of cases.
Any oracle feature (almost any) is made to improve thinks, not all can
be useful often.

The same as with a LONIGGING tablespace option; In theory  a great
option on practise :(
However a direct path write useful more often then compressed tables.

Jurijs

On 2/2/06, Herring Dave - dherri <Dave.Herring@acxiom.com> wrote:
> > By my opinion the feature is absolutely grate (whilst table
> > compression is rubbish).
>
> Could you elaborate on the "rubbish" comment above?  The reason I ask is
> that I've seen a pretty good compression percentage in the past at the
> table level.  We had a bunch of tables as part of an initial build that
> we wanted around, but needed them to cough up some of the space (I think
> they were consuming 300 - 400GB of space).  I rebuilt them using CTAS,
> ordering by the columns with cardinality < 50, up to 5 of them, in order
> by lowest cardinality to higher.  Doing this the compression dropped the
> table sizes to around 60% of their original size.  Table compression is
> pretty effective, in my experience, for this use.
>
> Dave
> -------------------------------------
> Dave Herring, DBA
> Acxiom Corporation
> 3333 Finley
> Downers Grove, IL 60515
> wk: 630.944.4762
> <mailto:dherri@acxiom.com>
> -------------------------------------
> *************************************************************************
> 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 resend this
> communication to the sender and delete the original message or any copy
> of it from your computer system.
>
> Thank you.
> *************************************************************************
>


--
Jurijs
+44 7738 013090 (GMT)
============================================
http://otn.oracle.com/ocm/jvelikanovs.html
--
http://www.freelists.org/webpage/oracle-l