Skip to Main Content

Breadcrumb

Question and Answer

Connor McDonald

Thanks for the question, Andrea.

Asked: February 13, 2019 - 3:32 pm UTC

Last updated: February 19, 2019 - 5:54 am UTC

Version: 11.2

Viewed 1000+ times

You Asked

Good Afternoon Tom,

I'm going to develop a little SQL Tool for maintenance of compress tables and indexes for our DWH Schema, our clients have Oracle EE (11.2 and 12.2), my "big" doubt is use or not use parallel execution because i see that using parallel execution increase the number of extents (as Oracle doc says); in your opinion which is the best way?
this is my SQL output:


alter table owner.table_name enable row movement
/
alter table owner.table_name move tablespace tablespace_name compress for oltp
(noparallel or parallel n?)
/
alter table owner.table_name deallocate unused
/
alter table owner.table_name disable row movement
/
alter index owner.index_name rebuild tablespace tablespace_name compress
(noparallel or parallel n?)
/
alter index owner.index_name shrink space compact
/
alter index owner.index_name deallocate unused
/


then usually i get gather_schema_stats with ad hoc preferences.

Thanks in advance for your attention,
and sorry for my english.

Andrea.


and Connor said...

Firstly, be aware that "compress for oltp" is not included in the Enterprise Edition license - it is an extra cost option (part of advanced compression).

So, I'm going to assume basic compression here. For me, I want to keep things as simple as possible so ideally, I'll compress *on load*, rather than have to come back later and compress data I've already loaded.

If I can't do that, I'd be starting as simple as possible, ie

11.2: alter table T move compress
12.2: alter table T move compress online

and then using a simple routine to handle any/all of my indexes, eg

https://asktom.oracle.com/pls/asktom/asktom.search?tag=rebuilding-all-the-unusable-index

I'd start simple and then if duration/contention/etc become an issue, only then look at options in terms of parallel operations etc.

Rating

  (2 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

packing too tight

Racer I., February 18, 2019 - 7:02 am UTC

Hi,

Two little points from our experience :
- Yes, parallel creates gaps due to the parallel parts being stitched together. But this only really gets noticeable if the segments are small, compression very high and parallel degree high. For big tables this will only be an issue if they are also partitioned (say daily) into many small segments. We went for noparallel, because we had no time constraints. If time is an issue parallelize by objects, i.e. compress multiple objects at the same time using DBMS_SCHEDULE or such.
- We ran into an obscure bug *) with DEALLOCATE UNUSED on FOR ARCHIVE HIGH compression. In production we got ORA-08103 when accessing the segments afterwards. In our testenv we only got an ORA-0600 (ktspfmtrng_al-2) but reproducible. So we had to stop using that.

*) https://support.oracle.com/epmos/faces/DocumentDisplay?id=27459948.8&displayIndex=1
possibly fixed in 19.1

regards,
Connor McDonald
February 19, 2019 - 5:54 am UTC

Nice input

for index compression in 12c

Rajeshwaran, Jeyabal, February 18, 2019 - 10:39 am UTC

Perhaps for 12c, you can think of advanced index compression rather than prefixed index compression.

Rather than compressing all the leaf blocks with the same prefixed columns, advanced index compression will look into each and every leaf block and see if it's a potential candidate for compression and so see how best it can be compressed. For those index leaf block that have no duplicate entries, do nothing, for those with some repeated columns just compress them and for those leaf blocks with lots of repeated columns and values to compress all of them as efficiently as possible.
Connor McDonald
February 19, 2019 - 5:48 am UTC

good input

More to Explore

Administration

Need more information on Administration? Check out the Administrators guide for the Oracle Database