X-Received: by 10.66.242.70 with SMTP id wo6mr1172597pac.16.1421936519414; Thu, 22 Jan 2015 06:21:59 -0800 (PST) X-Received: by 10.50.110.101 with SMTP id hz5mr585987igb.6.1421936519310; Thu, 22 Jan 2015 06:21:59 -0800 (PST) Path: news.cambrium.nl!textnews.cambrium.nl!feeder3.cambriumusenet.nl!feed.tweaknews.nl!194.109.133.86.MISMATCH!newsfeed.xs4all.nl!newsfeed3a.news.xs4all.nl!xs4all!news.glorb.com!hl2no1098336igb.0!news-out.google.com!qk8ni13799igc.0!nntp.google.com!hl2no86480igb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.databases.oracle.server Date: Thu, 22 Jan 2015 06:21:58 -0800 (PST) In-Reply-To: <3a24ab2a-0937-4d27-9491-2a89909934b7@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=69.4.5.254; posting-account=KXUmygkAAABvBFmgDBe4RBLFwhTRAMZC NNTP-Posting-Host: 69.4.5.254 References: <3a24ab2a-0937-4d27-9491-2a89909934b7@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: basic compression From: ddf Injection-Date: Thu, 22 Jan 2015 14:21:59 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.cambrium.nl On Friday, January 16, 2015 at 12:01:10 PM UTC-7, Mark D Powell wrote: > On Thursday, January 15, 2015 at 3:58:56 PM UTC-5, geos wrote: > > initally a table was created with basic compression and loaded using=20 > > direct load insert. during table usage time there were performed some= =20 > > updates, some non-direct load inserts, deletions etc. so after a while = a=20 > > table is composed of compressed and uncompressed blocks living altogeth= er. > >=20 > > do you know if is it possible to tell whether a particular block is=20 > > stored in compressed or uncompressed form when using basic compression= =20 > > for a table? is this information available at the block level with the= =20 > > help of some oracle system functions that operate on blocks? > >=20 > > thank you > > geos >=20 > I do not have time to read Joel's reference at the moment so my apologies= if this is in the material but I suspect you can see this in the block dum= p of the table/index. That is I expect there is flag set that will show in= the dump but I do not have time to test this either but it should only tak= e you a few moments to find out. >=20 > HTH -- Mark D Powell -- A block dump will show compressed data by virtue of the row length; compres= sed data will show 'abnormally' short lengths (as compared to what the leng= th SHOULD be based on the column definitions plus overhead). Actually the = data isn't compressed, it's 'de-duplicated'. It's an interesting mechanism= , described by Jonathan in the provided link. Suffice it to say the repeat= ing values are 'cataloged' into a 'table' and each occurrence of a given to= ken is replaced by its 'identifier' as referenced by the token 'table'. Yo= u need to read Jonathan's post in its entirety; do not rely on my synopsis.= Jonathan also takes you through the entire process of generating and read= ing a binary block dump so be sure to read and understand that as well. David Fitzjarrell