Oracle Database on EMC XtremIO

A Compression Technology Case Study

An Analysis of XtremIO Data Reduction Services

and Oracle Advanced Compression Option

EXECUTIVE SUMMARY ................................................................................................................................................................................................... 3

COMPRESSION ANALYSIS XTREMIO WITH AND WITHOUT ADVANCED COMPRESSION OPTION .................................................... 4
Test Data Used To Study Space Savings .............................................................................................................................................................................................. 4

CASE STUDY OVERVIEW ................................................................................................................................................................................................ 5

Characterization of Compression Efficacy ........................................................................................................................................................................................... 5
Test Platform Description ..........................................................................................................................................................................................................................5
Analyzing Space Savings ..................................................................................................................................................................................................................... 5
Space Savings Summary ...................................................................................................................................................................................................................... 6

COMPRESSION PERFORMANCE CHARACTERIZATION........................................................................................................................................ 6

Advanced Compression: Beyond Storage Space Savings ..................................................................................................................................................................... 6
Performance Test Overview................................................................................................................................................................................................................ 7
Database Schema and Storage Configuration ...........................................................................................................................................................................................7
Case Study Performance Testing ......................................................................................................................................................................................................... 7
Active Data Set and SGA Buffer Pool Sizes.................................................................................................................................................................................................7
Performance Measurements .............................................................................................................................................................................................................. 8
Application Throughput .............................................................................................................................................................................................................................8
I/O Throughput ..........................................................................................................................................................................................................................................9
Total IOPS ...................................................................................................................................................................................................................................................9
Total IOPS Per SQL Execution ...................................................................................................................................................................................................................10
Application Performance Per Database Host CPU Utilization .................................................................................................................................................................11

CONCLUSION ................................................................................................................................................................................................................... 12
APPENDIX A ..................................................................................................................................................................................................................... 13
APPENDIX B ..................................................................................................................................................................................................................... 14
NOTES: ............................................................................................................................................................................................................................... 14

Executive Summary

EMC XtremIO storage array offers powerful data reduction features. In addition to thin provisioning, XtremIO applies both
deduplication and compression algorithms to blocks of data when they are ingested into the array. These features are
always on and intrinsic to the array. There is no added licensing, no tuning nor configuration involved when it comes to
XtremIO data reduction.
Oracle Database also supports compression. The most common form of Oracle Database compression is the Advanced
Compression Optioncommonly referred to as ACO. With Oracle Database most options are separately licensed
features and ACO is one such option. As of the publication date of this Lab Report, ACO is licensed at $11,000 per
processor core on the database host1.
Compressing Oracle Database blocks with ACO can offer benefits beyond simple storage savings. Blocks compressed with
ACO remain compressed as they pass through the database host. In short, blocks compressed with ACO will hold more
rows of data per block. This can be either a blessing or a curse. Allowing Oracle to store more rows per block has the
positive benefit of caching more application data in main memory (i.e., the Oracle SGA buffer pool). On the other hand,
compacting more data into each block often results in increased block-contention. Oracle offers tuning advice to address
this contention in My Oracle Support note 1223705.12. However, the tuning recommendations for reducing block
contention with ACO also lower the compression ratios.
Oracle also warns users to expect higher CPU overhead with ACO as per the following statement in the Oracle Database
product documentation3:
Compression technology uses CPU. Ensure that you have enough available CPU to handle the additional load.

Application vendors, such as SAP, also produce literature to further assist database administrators in making sensible
choices about how and when to employ Advanced Compression Option. The importance of understanding the possible
performance impact of ACO are made quite clear in such publications as SAP Note 14363524 which states the following
about SAP performance with ACO:

Overall system throughput is not negatively impacted and may improve.

Should you experience very long runtimes (i.e. 5-10 times slower) for certain operations (like mass inserts in BW
PSA or ODS tables/partitions) then you should set the event 10447 level 50 in the spfile/init.ora. This will reduce
the overhead for insertion into compressed tables/partitions.
The SAP note offers further words of caution regarding transaction logging (a.k.a., redo) in the following quote:

Amount of redo data generated can be up to 30% higher

Oracle Database Administrators, with prior ACO experience, are largely aware of the trade-offs where ACO is concerned.
Database Administrators who have customarily used ACO in their Oracle Database deployments may wish to continue to
use ACO after adopting EMC XtremIO. For this reason Database Administrators are interested in learning how XtremIO
compression and Advanced Compression Option interact.
This Lab Report offers an analysis of space savings with and without ACO on XtremIO. In addition, a performance
characterization of an OLTP workload manipulating the same application data in ACO and non-ACO tablespaces will be
covered.

1
2

http://www.oracle.com/us/corporate/pricing/technology-price-list-070617.pdf
https://blogs.oracle.com/db/entry/master_note_for_oltp_compression

http://docs.oracle.com/cd/E11882_01/server.112/e25494/tables.htm#ADMIN13515

http://sapsearch.net/1436352-oracle-database-11g-advanced-compression-for-sap-systems/

Compression Analysis XtremIO With and Without Advanced Compression

Option
The impact of compression technology depends on the data being compressed. This is true for both XtremIO array compression and
Oracle Database with Advanced Compression Option. In the case of ACO, extremely redundant data can compress quite deeply. On
the contrary, some application data compresses moderatelyor not at allwith ACO.
To put this in perspective Oracle published a paper entitled Oracle E-Business Suite Release 12.1 with Oracle Database 11g
Advanced Compression5 which offers an analysis of a proper E-Business Suite schema and data. The paper states that the overall
data reduction was 68% (roughly 3:1). The paper also offers detailed compression ratio information for 231 tables of the Oracle EBusiness Suite 12.1.1 VISION schema. The per-table breakdown of ACO compression ratios achieved with the E-Business Suite
tables was as follows:

36 tables with a compression ratio > 5:1

27 tables with a compression ratio between 4:1 and 5:1
90 tables with a compression ratio between 2:1 and 4:1
40 tables with a compression ratio < 2:1
38 tables with a compression ratio of 1:1 (due to having 255 or more columnsa limit for Advanced Compression Option)

The Oracle whitepaper helps one to understand the variables involved in ACO compression efficacy. However, the general
conclusion is that both space savings and performance impact of ACO depends greatly on application data.
The variables involved with ACO compression performance and space efficiency played an important factor in choosing a
schema and dataset for the testing conducted for this Lab Report.

Test Data Used To Study Space Savings

The goal of this case study was to avoid testing with data that results in unrealistically high or low ACO compression
ratios. Based on the information gleaned from the Oracle E-Business Suite whitepaper5, EMC engineers decided to test
with data that compresses on the low-end of the publicized ACO compression capabilities. The primary factor in choosing
this approach is the fact that of the 231 tables discussed in the E-Business Suite paper, 78 enjoyed either no compression
or compression below 2:1. In other words, 34% of the tables in the E-Business Suite schema, discussed in the above-cited
Oracle whitepaper, compressed at less than 2:1 with ACO. To that end, EMC Engineers decided to settle on data and a
loading methodology that would limit the ACO compression rate to less than 50% (2:1).
In order to provide a meaningful case study with a workload and dataset that is easy to understand, EMC engineers chose
to focus on a slightly modified TPC-H Lineitem table. Figure 1 shows how the Lineitem create table DDL was altered to
prepend a column of type NUMBER(15) to the standard 16 columns seen in the TPC-H specification6.

Figure 1: Customized TPC-H Lineitem Table

http://www.oracle.com/us/solutions/benchmark/apps-benchmark/e-bus-r121-11gr1-advcompression-167254.pdf

http://www.tpc.org/tpc_documents_current_versions/pdf/tpch2.17.1.pdf

Case Study Overview

The remainder of this Lab Report will provide analysis of a case study that focused on two compression related aspects:

Characterization of Compression Efficacy

Compression Performance Characterization

Characterization of Compression Efficacy

Test Platform Description
The test platform used for the case study in this Lab Report consisted of the following:

2-Socket Intel Xeon based server

o E5-2690v3
o 320 Gigabytes RAM
o 2 x 8GFC (active) Fibre Channel paths to storage
o Oracle Linux 6.5 with Unbreakable Enterprise Kernel

EMC XtremIO Dual X-Brick Array

o XIOS firmware version 3.0.1
Oracle Software
o Grid Infrastructure 12c Release 12.1.0.2
o Oracle Database 12c Release 12.1.0.2
The SLOB7 Platform Performance Test Kit
o SLOB version 2.2.1.3

Analyzing Space Savings

The first phase of testing, conducted by EMC engineers, consisted of loading text records generated by the TPC-H data
generatorDBGENinto a baseline table stored in an Oracle Database 12c tablespace. The tablespace was stored in an
ASM disk group consisting of EMC XtremIO volumes. ASM external redundancy was used because XtremIO has data
protection known as XDP8 implemented in the array firmware.
After creating a tablespace for the test data, EMC engineers loaded 80,000,000,000 (80 billion) rows of test data into the
modified TPC-H Lineitem table (a.k.a., the baseline table). The modified TPC-H Lineitem row size averaged approximately
128 bytes so the table was 9.42 terabytes.
The randomness of the DBGEN data mandated sorting the data in order to increase the compression ratios. This is not
problem with any of the compression technologies being discussed but instead merely reflects the fact that highly random
data is difficult to compress. The test data was sorted at load time on the SHIPDATE column (c12Figure 1) in order to
achieve reasonable compression ratios.
After analyzing the logical and physical storage attributes of the baseline table, EMC engineers dropped the tablespace
containing the baseline table and recreated an identical tablespace but stipulated the ACO attribute COMPRESS FOR OLTP.
The modified TPC-H Lineitem was created in the newly created ACO tablespace and then populated with the same 80
billion rows of data.
As Figure 2 shows the data reduction characteristics of the test data were as follows:

Oracle dictionary views (i.e., USER_EXTENTS) reported the baseline table consumed 9.42TB of space in the
tablespace. This is logical space utilization.

EMC XtremIO Dashboard showed the 9.42TB baseline table in XtremIO required 6.7TBa reduction ratio of roughly
1.4:1. This is array-level physical space utilization.

Oracle dictionary views (i.e., USER_EXTENTS) reported that the same 80 billion row table (the baseline table)
created with ACO (COMPRESS FOR OLTP) reduced the tablespace requirement down to 5.89TBa compression ratio
of roughly 1.6:1. This is logical space utilization.

SLOB is the vastly popular, freely available Oracle Database centric platform performance testing kit. For more information visit xtremio.com/slob ,
kevinclosson.net/slob or use Google to search for user-contributed content.
8
For detail regarding EMC XtremIO XDP please refer to: http://www.emc.com/collateral/white-paper/h13036-wp-xtremio-data-protection.pdf

EMC XtremIO Dashboard revealed that storing the 5.89TB ACO table in XtremIO resulted in no appreciable physical
space savings.

Figure 2: Logical and Array-Level Space Usage Comparison. ACO versus Non-ACO

Space Savings Summary

The testing conducted by EMC Engineers gives a good example of how even data that is difficult to compress can be
reduced at the persistent storage level with XtremIO inline data reduction services. In this particular case a 29% reduction
in physical space requirements was observed when the data was stored in XtremIO. The testing also showed Advanced
Compression Option can further reduce the physical footprint by an additional 12% (6.7TB to 5.89TB). However,
combining ACO compression and XtremIO data reduction resulted in no additional space savings in this particular case.

Compression Performance Characterization

Advanced Compression: Beyond Storage Space Savings

Compression is first and foremost a storage savings technology. However, in the case of application compressionsuch
as Advanced Compression Optiondata remains compressed as it flows through the system. For this reason ACO can
deliver improved performance when, for example, the database server is able to cache more data in main memory,
resulting in less physical I/O. That said, the benefit of reduced physical I/O must outweigh the CPU costs associated with
ACO in order to enjoy a net benefit.
There is a very large body of ACO performance-related information available from many sources online. This Lab Report
has already discussed some of the authoritative literature published by Oracle and SAP. Other articles leave readers with
many questions unanswered. One specific Infoworld article9 would leave readers with the belief that ACO imposes as
much as 50% performance penalty based on the following quote:

Comparing the Read Uncompressed and Read Compressed results, you can see that in this case
compression has not benefited query performance, but resulted in roughly a 50% performance
hit (a drop from 30 TPS to 16 TPS).
Testing the performance ramifications of ACO can be difficult, however, the goal for this Lab Report was to test norms as
opposed to extremes.

https://web.archive.org/web/20150315183328/http://www.infoworld.com/article/2638616/database/oracle-database-11g-advancedcompression-testbed--methodology--and-results.html

Performance Test Overview

In preparation for this Lab Report, EMC engineers aimed to craft a repeatable, understandable workload based on the very
popular and readily available SLOB7 platform performance testing toolkit. However, EMC engineers sometimes modify the
SLOB toolkit to function with altered schemas because the default schema and data are simply not suitable for testing
compression. To address this issue EMC Engineers altered the SLOB toolkit to function on the same modified TPC-H
Lineitem table discussed in the compression efficacy section of this Lab Report. For details on the SLOB modifications
implemented by EMC Engineers for this case study please refer to Appendix A.
In order to characterize more than a simple ACO versus non-ACO storage space-savings comparison, several dimensions
were tested. Since ACO can improve application performance through increased SGA10 buffer cache efficacy, the testing
needed to vary the percentage of the active data, set cached in the SGA, from a very small percent to a much larger
percent.

Database Schema and Storage Configuration

To prepare for testing the following tasks were performed:

Two tablespaces (2 terabytes each) were created in the database stored in the XtremIO array. One of the
tablespaces was created with the COMPRESS FOR OLTP attribute in order to test ACO compression.

Both of the tablespaces were loaded with 256 test schemas based on the modified TPC-H Lineitem table definition
described in Appendix A. Each of the 256 schemas were loaded with 31 million rows of data. This multi-schema
testing approach is characteristic SLOB.

The array-level space requirements of this test data exhibited the same data reductions as seen above in Figure 2.
The array-level storage attributes of the test data were as follows:
o The 256 non-ACO tables consumed roughly 946 gigabytes of logical space in the tablespace
(USER_EXTENTS). However, due to XtremIO data reduction services only 673 gigabytes of space was
consumed in the array. In addition, an index was created on each table (custid column) and stored in the
same tablespace.
o The 256 tables created with ACO consumed roughly 597 gigabytes of logical space (in aggregate) in the
tablespace created with the COMPRESS FOR OLTP attribute and stored in the XtremIO array. No additional
space savings was observed at the physical level in the XtremIO array. In addition, an index was created on
each table (custid column) and stored in the same tablespace.

The space reduction delivered by ACO mirrored that show in Figure 2. To that end, the ACO tests
enjoyed an effective SGA capacity roughly 60% larger than the non-ACO tests. To put it another way,
with ACO each Oracle database block contained approximately 60% more rowson averagethan in
the non-ACO case.

Case Study Performance Testing

Active Data Set and SGA Buffer Pool Sizes

To properly characterize the potential benefit of improved database block buffering with Advanced Compression Option,
EMC Engineers tested with three different SGA buffer pool sizes: 8 gigabytes, 128 gigabytes and 228 gigabytes. At each
SGA buffer pool size the SLOB workload was tested with SQL UPDATE percentage set at three different levels of modify
intensity: zero percent, ten percent and twenty-five percent. In SLOB testing all SQL is either SELECT or UPDATE with only
the percentage of UPDATE varying.
Figure 3 helps visualize the percentage of the workload active data set that fit in the Oracle SGA buffer pool in the ACO and
non-ACO case.

10

For details on the concept of Oracle SGA please refer to https://docs.oracle.com/database/121/CNCPT/memory.htm#CNCPT7777

Figure 3: Oracle SGA Caching of the Active Data Set

Please refer to Appendix B for details regarding important database instance statistics per SQL execution for this test
workload.

Performance Measurements

Performance characterization of the test workload with and without Advanced Compression Options will be broken down
into two categories:

Application throughput

Application throughput per CPU consumption

Application Throughput

The key application throughput indicator, for this suite of tests, was SQL executions per second reported by Oracle
Automatic Workload Repository report. Since ACO data fits more densely within Oracle data blocks, I/O intensive
applications should enjoy improved throughput as a result of reduced physical I/O.
Figure 4 shows the varying benefit ACO delivered to the test workload. In summary, the testing revealed:

8GB SGA Buffer Pool. With a SGA buffer pool of only 8 gigabytes there was no difference in throughput as measured
by SQL executions per second when comparing ACO to non-ACO. At 8 gigabytes the SGA buffer pool was sized
below critical minimum for the active data set size regardless of compression.

128GB SGA Buffer Pool. After the SGA buffer pool was increased to 128 gigabytes the increased cache efficacy
could be detected in the ACO test results. When testing 0% SQL UPDATE (100% random single-block reads) the
ACO test produced 16% more throughput than the non-ACO test. Likewise at 10% SQL UPDATE there was also a
16% improvement with ACO. On the contrary, the 25% SQL UPDATE test showed only 8% improvement with ACO
over non-ACO.

228GB SGA Buffer Pool. When the workload was tested with an SGA buffer pool sized at 228 gigabytes, the 0% SQL
UPDATE performance was 47% better than the non-ACO test. At 10% SQL UPDATE the ACO result was 43% better
than the non-ACO result. Here again, however, the 25% SQL UPDATE result showed much less benefit than the 0%
and 10% SQL UPDATE result. At 25% SQL UPDATE the ACO result was 12% better than the non-ACO result.

Figure 4: Test Workload Application Throughput. SQL Executions Per Second

I/O Throughput

As mentioned in the Test Platform Description section, these tests were conducted on a server with 2 active 8Gb Fibre
Channel paths to storage. As such, the test configuration was limited to a maximum of roughly 200,000 random 8KB read
transfers per second. As explained above, the testing varied the SQL UPDATE ratio from 0% to 10% and then 25%. To that
end, the Fibre Channel bandwidth is ultimately the limiting factor for random reads. In fact, random reads are the primary
limiting factor for this, and most OLTP-style workloads, since Oracle Database transactions cant modify blocks of data
without first reading them into the SGA buffer pool. Unless the active data set resides entirely in the SGA buffer pool,
Oracle modify-SQL is a read (from the database), modify (in memory) and a wait for change vectors to be written to the
transaction log (a.k.a., redo log). However, since Fibre Channel is a duplex protocol the 10% and 25% SQL UPDATE tests
do have the opportunity to drive more IOPS as the blend shifts from read-only to a combination of reads and writes.
Predicting the I/O profile of a modify-intensive workload at varying levels of SGA buffer cache hit-ratios is a very difficult
task. With higher modify-SQL ratios there is more redo logging overheadand, indeed, redo logging is not improved by
buffer cache hit ratio. To that end, the same workload executing with a larger buffer cache will essentially be able to
replace I/O, that would otherwise be random read, with sequential writes to the redo log. In essence, a hole is created by
eliminating some random reads (datafile) and then partially filled back in with sequential writes (redo log). In the end,
however, a modify-intensive workload is always throttled by redo logging regardless of buffer cache hit rate. This is the
most essential factor in whether or not Advanced Compression Option will benefit a given workload since ACO has no
direct improvement on redo logging. In fact, the opposite is often true.
With ACO, redo logging overhead is often increasedand the increase can be significant. The above-cited SAP note
suggests the increase in redo generation can be as high as 30%. As Figure 10 (Appendix B) shows the test workload used
by EMC Engineers for this Lab Report sustained increased redo generation in the 50% range for the 25% SQL UPDATE test
case.
The simple fact about ACO is that performance benefitor degradationis entirely application dependent.
While Figure 4 summarizes application throughput with the test workload but what about total IOPS?

Total IOPS
Figure 5 shows the total IOPS for all tests. As expected, IOPS for the 0% SQL UPDATE tests were limited to the bandwidth
afforded by the two active Fibre Channel paths to storage. However, as the SGA buffer cache size was increased,
application throughput increased (Figure 4). This is easily explained by the fact that the active data set, in all cases, is
much larger than the SGA buffer cache so physical I/O was expected to saturate the storage networking bandwidth for the
0% SQL UPDATE tests.
Figure 5 also shows that combining high data-modification rates with increased buffer cache efficacy can result in
unexpected changes to the I/O profile. While that is not a problem, per se, it does help prove the point that efficiencies
as well as overheadsresulting from ACO tend manifest themselves in unexpected ways. As shown in Figure 3, the

percentage of the active data set cacheable in the SGA buffer pool was 38% in the 25% SQL UPDATE test with ACO. This
level of cache coverage makes room for more modified SGA buffers to remain in the cache. The result of this cache
dynamic is seen in Figure 5 which shows that in the 228GB SGA buffer pool configuration the 25% SQL UPDATE test
enjoyed a 17% reduction in total I/O when comparing ACO to non-ACO. Most of this reduction in total I/O can be
accounted for with the data in Figure 10 (Appendix B), which shows that in this particular comparison of ACO to non-ACO
there was a 14% decrease in physical writes per SQL execution. Having said all that, the 17% reduction in total IOPS
didnt result in 17% improved application performance as can be seen in Figure 4. Figure 4 shows that the 17% decrease
in total IOPS resulted in an application throughput increase of only 11.6% (2520 to 2814 SQL executions/second).

Figure 5: Test Workload Total IOPS

Total IOPS Per SQL Execution

While it is important to observe total IOPS at the system level, there is no way to map such statistics to application
performance. For this we normalize IOPS to SQL executions per second. After all, ACO cannot improve application
performance unless the workload enjoys a higher SGA buffer pool hit ratio due to the fact that ACO stores more rows of
data per block.
Figure 6 shows total physical IOPS per SQL execution. Since the 8GB test results represent testing at grossly undersized
SGA buffer pool capacity, the most interesting data points are from the 10% and 25% SQL UPDATE results with the 128
and 228 gigabyte SQL buffer pool. In summary Figure 6 shows :

128GB SGA Buffer Pool

o The 10% SQL UPDATE test enjoyed 14% fewer IOPS per SQL execution in the ACO case compared to the nonACO case. Please bear in mind application throughput increased 16% in this case (Figure 4)
o The 25% SQL UPDATE test enjoyed 11% fewer IOPS per SQL execution in the ACO case compared to the nonACO case. Please bear in mind application throughput increased 8% in this case (Figure 4)

228GB SGA Buffer Pool

o The 10% SQL UPDATE test enjoyed 29% fewer IOPS per SQL execution in the ACO case compared to the nonACO case. Please bear in mind application throughput increased 43% in this case (Figure 4)
o The 25% SQL UPDATE test enjoyed 26% fewer IOPS per SQL execution in the ACO case compared to the nonACO case. Please bear in mind application throughput increased 12% in this case (Figure 4)

Figure 6: Test Workload Total IOPS Per SQL Execution

Thus far this Lab Report has shown how Advanced Compression Option generally improves application throughput by
reducing physical IOPS per SQL execution. This would be considered application performance improvement in absolute
terms. However, as mentioned very early in this Lab Report, Oracle documentation speaks of increased CPU overhead
when using ACO. Since Oracle software is licensed by the database host processor core count one must also ascertain
how ACO impacts performance in a manner normalized to CPU utilization.

Application Performance Per Database Host CPU Utilization

As mentioned earlier in the Lab Report, EMC Engineers rely heavily on Oracle performance statistics reported in Automatic
Workload Repository reports. In all performance testing it is imperative to pay particular attention to the DB CPU statistics
tracked and reported by Oracle database. After all, CPU is the ultimate governing factor in application performance and
there is always a fixed limit on CPU bandwidth available. Moreover, Oracle licenses software based on the count of
physical cores on the database host. As cited about, Oracle documentation states ACO imposes CPU overhead and that
one must ensure there is enough CPU to handle this added overhead. To that end, EMC Engineers were keen to scrutinize
the performance testing results normalized to CPU utilization.
Figure 7 shows application performance impact of ACO normalized to the host CPU utilization as reported by Automatic
Workload Repository results. As Figure 7 shows, 100% SELECT (read-only) workloads experience a significant boost. This
is no surprise because with more SGA cache footprint (see Figure 3) the SQL statements are enjoying more buffer cache
hits. RAM is faster than any block storage.
Looking beyond the read-only tests one can clearly see that CPU overhead is a critical factor in assessing suitability of ACO
for a specific workload. In summary, Figure 7 shows:

10 Percent SQL UPDATE

o The 8GB SGA cache result showed ACO returned 6% less throughput on a CPU-normalized basis.
o The 128GB SGA cache result showed parity between ACO and non-ACO on a CPU-normalized basis.
o The 228GB SGA cache result showed ACO returned 5% more throughput on a CPU-normalized basis.

25 Percent SQL UPDATE

o The 8GB SGA cache result showed ACO returned 12% less throughput on a CPU-normalized basis.
o The 128GB SGA cache result showed ACO returned 6% less throughput on a CPU-normalized basis.
o The 228GB SGA cache result showed ACO returned 5% more throughput on a CPU-normalized basis.

Figure 7: Test Workload Throughput Normalized to DB CPU

Conclusion
In this Lab Report EMC Engineers have used an in-depth case study to help Oracle Database Administrators further
understand the relationship between XtremIO data reduction services in combination with Oracle Advanced Compression
Option. The case study demonstrated that difficult to compress data reduces 1.4:1 with built-in XtremIO compression. In
addition ACO was able to further reduce the storage requirement by 12% resulting in a storage-level data reduction ratio of
1.6:1thus establishing favorable coexistence of the two compression technologies.
In addition to space savings analysis, the case study showed important performance characterizations of a SQL-driven
IOPS centric workload with and without Advanced Compression Option. Generally speaking read-only workloads showed
significant improvement with ACO since more application data fits in Oracles primary memory cache (the SGA). Further,
read-only tests with or without ACO were able to take full advantage of the bandwidth provided by the storage networking.
When it comes to workloads that are not read-only, however, the results are mixed. When testing the combination of a low
degree of SQL modification and a large SGA (caching roughly 25% of the active data set) the results showed that ACO
improved performance by 43%. However, when a smaller portion of the active data set was cached, and/or the degree of
SQL modification intensity was increased, the performance benefit of ACO was limited to 16%.
Finally, the case study showed that when application throughput was normalized to the CPU cycles required to processes
the workload, modify-intensive workload results with ACO ranged from degrading the performance by 6% to improving the
performance by 12%.
Compression is first, and foremost, a space savings technology. This whitepaper shows that XtremIO is a predictable builtin technology that has no host processing ramifications yet renders space savings even for data that is difficult to
compress. The Oracle Advanced Compression Option has the ability to improve Oracles SGA buffer cache hit ratio but
that improvement comes at a cost in terms of CPU overhead. This fact is evident in both Oracle documentation and
testingsuch as the case study in this whitepaper. Customers will do well to test before they decide whether or not to
layer additional compression on top of XtremIO data reduction services which include not only compression but
deduplication.

Appendix A

EMC Engineers use a modified SLOB kit to test the performance characteristics of workloads involving data compression with
Advanced Compression Option. The modifications to the SLOB kit are twofold:

Changed the primary SLOB target table from the default to a modified TPC-H Lineitem table
Change the UPDATE SQL in procedure.sql to operate on the modified TPC-H Lineitem table

Figure 8 shows the DDL used to create a TPC-H Lineitem table that functions with the SLOB kit. Those familiar with SLOB will notice
the lead column is custid as it is in the standard SLOB kit. As an aside, the SLOB runtime will function with any table that has a
numerical custid column with unique values. Those familiar with TPC-H will recognize the TPC-H compliant Lineitem table
(commented out).

Figure 8: Table Definition. Customized TPC-H Lineitem Table

The other modification to the SLOB kit is in the SLOB/misc/procedure.sql file. Figure 9 shows how the SQL UPDATE statement used
by SLOB was altered to modify the seventh ordinal column. As per Figure 8, C7 maps to l_discount in the original TPC-H
specification. This modification simply adds 20 percent to the value previously stored in the row for each row matching the
selection criteria.

Figure 9: Modified SQL for Customized SLOB Workload

Appendix B

The following table shows Oracle Database key performance indicators normalized to the DB CPU statistic reported in Automatic
Workload Repository reports for the SLOB workload used in this Lab Report.

Figure 10: Key Performance Metrics For Test Workload

Notes:

Performance test results are highly dependent on workload, specific application requirements, and system design and
implementation. Relative system performance will vary as a result of these and other factors. Therefore, the lab test
workloads should not be used as a substitute for a specific customer application testing when critical capacity planning or
product evaluation decisions are considered.
All performance data contained in this report was obtained in a rigorously controlled environment. Results obtained in other
operating environments may vary significantly.
EMC Corporation does not warrant or represent that a user can or will achieve a similar performance