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,
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.
February 19, 2019 - 5:48 am UTC
good input