Oracle Database on EMC XtremIO A Compression Technology Case Study An Analysis of XtremIO Data Reduction Servicesand 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 SummaryEMC 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 http://www.oracle.com/us/corporate/pricing/technology-price-list-070617.pdf2 https://blogs.oracle.com/db/entry/master_note_for_oltp_compression 3 http://docs.oracle.com/cd/E11882_01/server.112/e25494/tables.htm#ADMIN13515 4 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 E-Business 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 5 http://www.oracle.com/us/solutions/benchmark/apps-benchmark/e-bus-r121-11gr1-advcompression-167254.pdf 6 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 oE5-2690v3 o320 Gigabytes RAM o2 x 8GFC (active) Fibre Channel paths to storage oOracle Linux 6.5 with Unbreakable Enterprise Kernel EMC XtremIO Dual X-Brick ArrayoXIOS firmware version 3.0.1 Oracle Software oGrid Infrastructure 12c Release 12.1.0.2 oOracle Database 12c Release 12.1.0.2 The SLOB7 Platform Performance Test KitoSLOB 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. 7 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 casecompression has not benefited query performance, but resulted in roughly a 50% performancehit (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. 9 https://web.archive.org/web/20150315183328/http://www.infoworld.com/article/2638616/database/oracle-database-11g-advanced-compression-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: oThe 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. oThe 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 IOPSFigure 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 efficienciesas 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 oThe 10% SQL UPDATE test enjoyed 14% fewer IOPS per SQL execution in the ACO case compared to the non-ACO case. Please bear in mind application throughput increased 16% in this case (Figure 4) oThe 25% SQL UPDATE test enjoyed 11% fewer IOPS per SQL execution in the ACO case compared to the non-ACO case. Please bear in mind application throughput increased 8% in this case (Figure 4) 228GB SGA Buffer Pool oThe 10% SQL UPDATE test enjoyed 29% fewer IOPS per SQL execution in the ACO case compared to the non-ACO case. Please bear in mind application throughput increased 43% in this case (Figure 4) oThe 25% SQL UPDATE test enjoyed 26% fewer IOPS per SQL execution in the ACO case compared to the non-ACO 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 UPDATEoThe 8GB SGA cache result showed ACO returned 6% less throughput on a CPU-normalized basis.oThe 128GB SGA cache result showed parity between ACO and non-ACO on a CPU-normalized basis.oThe 228GB SGA cache result showed ACO returned 5% more throughput on a CPU-normalized basis.25 Percent SQL UPDATE oThe 8GB SGA cache result showed ACO returned 12% less throughput on a CPU-normalized basis.oThe 128GB SGA cache result showed ACO returned 6% less throughput on a CPU-normalized basis.oThe 228GB SGA cache result showed ACO returned 5% more throughput on a CPU-normalized basis. Figure 7: Test Workload Throughput Normalized to DB CPU ConclusionIn 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 built-in 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