Hi Fidel and Stefan,
Thank you so much for your feedback.
In regards the number of columns in my case the table doesn't reach the 255 columns limitation actualy it has 225 columns and per the Oracle statistics there is no Row Chaining with this table.
I also find a bit strange to have the double of CPU time with the half of Logical I/Os. It's true that the statistics of the first execution (no buffer cache) are better with the table compressed because the number of Disk Reads were much lower but this only improves the first execution.
Oracle always says that the OLTP compression doesn't have any negative impact in read operations but If you can only improve the first run and the others were worse because of a higher CPU time ... I'd doubt this sentence. This means that OLTP compression can have a negative impact in performance with a lot of Logical I/Os.
I'm gonna check the links about "code optimization" and CPU Usage.
I'm also thinking of apply the Oracle SBP 11.2.0.3.9 - 201402V3. There are a couple of reported bug about compression there:
- 13641076 - HIGH AMOUNT OF BUFFER GETS FOR INSERT STATEMENT - REJECTION LIST DOES NOT FIRE
- 14762511 - UPDATE ON A OLTP COMPRESSED TABLE WITH MILLIONS OF BUFFERGETS TAKES LONG TIME
Here you have the Execution plan just in case it can give any new clue:
Execution Plan
| Id | Operation | Name | Rows | Bytes | Cost (%CPU) | Time |
|---|---|---|---|---|---|---|
| 0 | SELECT STATEMENT | 12438 (100) | ||||
| 1 | FILTER | |||||
| 2 | TABLE ACCESS BY INDEX ROWID | CE1GG00 | 424 | 273K | 12437 (1) | 00:02:21 |
| 3 | INDEX RANGE SCAN | CE1GG00~Z1 | 333K | 416 (1) | 00:00:05 |
Many thanks