We're doing some more analysis of how much space we can save on our filesystems by implementing advanced compression. We initially looked at this in 11.1.0.7 but some bugs (that we couldn't easily patch for) prevented us from going any further. Now we've upgraded to 11.2.0.2 (we couldn't go any higher as the 3rd party vendor wouldn't certify it) we decided to revisit it.
We did some comparisons by importing the same export file of a copy from live into 2 different schemas/tablespaces - we then compare the resulting size of the objects.
Here is what we found:
| Storage | TABLE | INDEX* |
|---|---|---|
| Normal | 310GB | 115GB |
| Compress for all operations | 115GB | 99GB |
(* advanced compression does not apply to indexes - these were just compressed using old style 'compress')
So we can see there is a huge reduction in the storage required for the tables - the objects end up almost 1/3 of their original size. Indexes is not so amazing but is still OK.
This database has a huge number of tables and a huge mix of types of data so i think probably would accurately reflect the kind of figures you would see from a normal OLTP system.
Now we need to check there are no bugs and also how this impacts performance. In theory it should make a lot of things faster but we had bad experiences with advanced compression in a warehouse system where the overheard of the compression during data loads made very noticeable changes (in the wrong direction) to the batch performance.
Comments
Post a Comment