This document discusses implementing Oracle Advanced Compression in an Oracle E-Business Suite environment to reduce storage footprint. It describes compressing the largest tables, which reduced the database size by over 500 GB. Some performance impacts were observed, such as a 7% increase in CPU usage and changed execution plans slowing some queries. Thorough testing is recommended before production use to understand specific impacts and ensure critical functionality is not affected. Advanced Compression can provide significant storage savings but also requires careful planning and testing due to potential performance trade-offs.

1. Session ID:
Prepared by:
Reducing Your E-Business Suite
Storage Footprint With Oracle
Advanced Compression
10222
@ AndrejsKarpovs
Andrejs Karpovs
Lead Oracle Applications DBA

2. About me
• Lead Oracle Apps DBA / Technical infrastructure
architect at Tieto [Latvia]
• Oracle Certified Master
• Oracle ACE
• Masters Degree in Computer Science
• Speaker: Collaborate, UKOUG, OUGH, Oracle
• RAC Attack Ninja
• Blog: adbaday.wordpress.com
2

3. Tieto
• Tieto is the largest Nordic IT services company
3

4. Coming from Latvia
4

5. Agenda
• Compression in Oracle
• Advanced Compression
• Advanced Compression with E-Business Suite
• Particular Customer Scenario
• Implementation
• Recommendations
• Conclusion and Results
5

6. Disclaimer
• Not a deep dive into Oracle Compression
algorithms
• Specifically based on implementation in EBS
environment
• Not a silver bullet for Advanced Compression
implementation
– Many things varies depending on individual
environment and requirements
– Therefore many answers could be “it depends…”
• There might be exceptions
• There are different business needs and requirements
• Presentation does not scope all the conditions
• The compression ratio achieved in a given environment
depends on the nature of the data being compressed;
specifically the cardinality of the data.

7. Compression Concepts
• Compression is “de-duplication”
– Eliminating duplicate values within a data block
• Repeating Data Patterns are stored in block header
as symbols
• Occurrences of such data in the block are replaced
with pointers to symbols
7

8. Types of Compression
• Basic Compression
– ALTER TABLE T1 COMPRESS BASIC;
– CREATE TABLE T1 COMPRESS BASIC;
– CREATE TABLESPACE COMPRESSED
DATAFILE ‘/u01/oradata/compressed01.dbf’
DEFAULT COMPRESS’;
• Compression for OLTP or Advanced Compression
– ALTER TABLE T1 COMPRESS FOR OLTP;
– DBMS_REDEFINITION;
– ALTER TABLE T1 MOVE COMPRESS FOR OLTP;
• Invalidates Indexes (use UPDATE INDEXES clause)
– Separate license required
• Hybrid Columnar compression (Exadata/ZFS)
– Not covered
8

9. Basic Compression
• CREATE TABLE T1 COMPRESS BASIC;
– Automatically sets PCT_FREE to 0
• The data is only compressed when the insert is a
direct path insert
– INSERT /*+ APPEND*/
– COMPRESS BASIC originally was “compress for
direct_load operations”
• Simply changing a table from uncompressed to
compressed does nothing to the data
– Alter table definition
– Move table to compress its contents
– Rebuild indexes
9

10. Advanced Compression (I)
• CREATE TABLE T1 COMPRESS FOR OLTP;
– Leaves PCT_FREE to the same 10
• Data is compressed also with normal inserts
– First is inserted uncompressed
• When the block gets full – compression is attempted
– Compression ratio is worse than direct path insert
though
• Data compressed on updates
– Same logic as for inserts
• Simply altering the table does not compress data
– Move is required
– Rebuild indexes
10

11. Advanced Compression (II)
11

12. Advanced Compression Additional
Options
• Data compress in tables and indexes
• RMAN backups
• Data Guard Redo compression
• Data Pump compression
• Oracle Secure File LOBs
– Deduplications
– FND_LOBS
12

13. Customer Environment
• Oracle Database 11.2.0.4 Single Instance on ASM
• Oracle EBS R12.1.3
• Database size ~2,5 TB
• Growing about 50 GB a month
• 20 test environments: DEV, TEST, QA + different
project purposes
– Resulting ~40 TB in storage
• Business requirement pertain data for 10 years
• ULA – Unlimited License Agreement
– Advanced compression was included
13

14. Challenges
• Rapid data growth
– Longer backup
– Longer cloning
• Higher costs for customer
• Harder to manage
• More intensive planning required
14

15. Identify and evaluate additional pre-
compression possibilities
15
• Verify/implement purging
– OM, AR, Accounting tables, FA, GL, ICX, Oracle
Workflow Runtime data, etc…
• Rebuild indexes
• Reorganize database
– Resize datafiles
• Drop unneeded schemas (PERFSTAT in our case)
• alter table move
• Monitor your segment growth over time

16. Prepare
• Study Advanced Compression bugs and
patches/fixes and apply them
– BUG:6846187 - UPDATE ON COMPRESSED TABLE
TAKES MORE THAN SEVERAL HOURS
– NOTE:8287680.8 - Bug 8287680 - Poor insert
performance into COMPRESS table
– NOTE:987049.1 - Performance Issue After Enabling
Compression
• Or upgrade to latest DB release + PSU (11.2.0.4)
• Study MOS notes for known issues
• Measure what space savings will be done with reorg
– Reorganize tables prior to compression to see the
exact compression gains
16

17. Strategy
• Review your largest candidate tables
– Some of the largest transaction tables in EBS have
over 255 columns or include Long columns and are
therefore not candidates for compression.
• Start by compressing your largest tables based on
the 80/20 rule, in that 20% of your tables likely
consume 80% of the space
• Identify tables that were not updated frequently
• Oracle Compression Advisor
– http://www.oracle.com/technetwork/database/options/
compression/index.html?ssSourceSiteId=otnes
17

18. Execution
• In our case, just some of the key facts
– Major segments
• PA_BUDGET_LINES ~60 GB
• FA_BALANCES_REPORTS_ITF ~40 GB
• PA_RESOURCE_ASSIGNMENTS ~25 GB
• GL_JE_LINES ~27 GB
• GL_BALANCES ~22 GB
• Custom tables ~100+ GB
• Indexes
– PA_BUDGET_LINES_N1 ~30 GB
– FA_BALANCES_REPORTS_ITF_N1 ~20 GB
– PA_RESOURCE_ASSIGNMENTS_U2 ~15 GB
– …
18

19. Placeholder for objects to be
compressed
19

20. Placeholder for objects to be
compressed
20

21. Placeholder for objects to be
compressed
21

22. TEST
• Try to avoid running any major project in parallel
22

23. Results (I)
• Before compression
– Size of candidates for compression ~400 GB
– After compression ~128 GB
– Compression Ratio ~68%
• Purge (ex., FND_LOG_MESSAGES, modules)
– ~60 GB
• Reorganize/Rebuild
– ~100 GB
• DB physical size decreased from ~2,5 TB to ~1,7
TB
23

24. Results (II)
24
UPDATE INDEXES
Check the default index parallelism before rebuilding and return the
value back or set to NOPARALLEL to avoid SQL performance regressions
• Crosscheck and make sure there are no UNUSABLE indexes left over

25. Results (III)
• Compression ratio is dependent on data nature
– More duplicates = better compression
• Compression on non-intense/read-only tables
• Typically a 2-4 times reduction can be expected
• Every environment is different
25

26. Timing
• Study the timings needed for compression
– Compress in cycles
– Compress in a weekend outage if allowed
• Each environment downtime is different
• Go table by table
– Biggest tables might require multiple hours time
• Go together with database reorganization if possible
• Use DBMS_REDEFINITION
– Online
• Use Parallel clause
– ALTER TABLE TEST COMPRESS FOR OLTP
PARALLEL 20;
26

27. Are we there yet?
• When they said, “Just enable Advanced
Compression and see what happens”
27
@DBAReactions

28. Benchmarking
• Identify your own testing strategy
– In my case it was combined with a migration project
• Measure CPU overhead
• Identify SLA requirements for particular jobs
• Load testing tools
• Batch processing simulation (CONCURRENT
REQUESTS)
• Involve functional team as much as possible in
testing
• Use AWR
– StatsPack
• Cloud Control
28

29. AWR
Before compression After compression
29

30. Side Effects (I)
• Performance impact – good or bad?
– Retrieving same data from fewer blocks
– Fewer physicalreads
• Less I/O
• Inserts and updates may trigger block compression
– Increase in CPU consumption
• Index compression
– Execution plan may change
• If the size become much lower, full index scan might be
chosen rather than range scan
• Additional overhead with db_block_checking = TRUE
– More CPU
– “Database corruption is exceptionally rare and Block Checking is not
recommended for EBS.”
30

31. Side Effects (II): Redo and Undo
• Amount of Undo and Redo will be greater than in
non-compressed table during update
– Whatever is written to undo, also is written to redo
• http://oraganism.wordpress.com/2013/01/20/advanc
ed-compression-visualising-insert-overhead/
31

32. Side Effects (III)
• Row chaining
– Migrated rows during intensive table UPDATE
• Partial loss of compression
• ITL contention
– Block density increased
• Concurrency
32

33. Recommendations (I)
• Index Compression
– Minimize execution plan changes
• Patches
– Review all available patches and make sure you are
not facing any bug
– List of Critical Patches Required For Oracle 11g Table
Compression (Doc ID 1061366.1)
• Avoid using High Transactional tables (ex.,
FND_CONCURRENT_REQUESTS)
• When loading many rows use direct path inserts
• Row migration
– Play with PCTFREE value for problematic tables
– Leaving enough room for updates; preventing
recompression and chaining
33

34. Recommendations (II)
• SQL Plan Regressions
– At first, gather statistics on the objects
• Consider using SQL Profiles or SQL Plan Baselines
• Remove db_block_checking if not necessary
• If the situation in critical, you can always
decompress
• Master Note for OLTP Compression (Doc ID
1223705.1)
34

35. Recommendations (III)
• LOBS
– Needs to be converted to SecureFile LOBS
– How to convert FND_LOBS from basicfile to
securefile LOBS
– Doc ID 1451379.1
• https://blogs.oracle.com/stevenChan/entry/using_se
curefiles_with_e-business_suite_databases
• Use deduplication
• Ulitise DBMS_REDIFINITION
35

36. Results
• CPU Usage
– 7% increase in CPU time
• DB sequential reads reduced 20%
• SQL Performance
– Some of the Execution plans changed reducing
performance
• Improved Self-Service flow response times
– More read intensive
36

37. Advanced Compression Considerations
• How much will we save in storage?
– Will it balance the product cost?
• How much will this impact our performance?
– Every environment will vary, how much will yours be
impacted
• How much will the implementation cost us?
• How much risk is there
– What things should we test
– How much should we test
37

38. Pros and Cons
Advantages
• Reduce storage
requirements
• Save costs
• May improve query
performance
• Reduction in I/O as
fewer blocks are
accessed for a given
set of rows
Disadvantages
• CPU overhead
• SQL Plan regressions
• Row Chaining
• ITL Contention
• Not suited for High
Transaction tables
38

39. Future Plans
• Test RMAN backup compression for EBS database
– Not really usable
39

40. RMAN backup advanced compression
40

41. Future plans (II)
• Index compression
• FND_LOBS
– Deduplication
• 12c compression new features?
41

42. Thank you!
Any questions?