Bill Hodak Principal Product Manager

Bill Hodak Principal Product Manager
Oracle Advanced Compression: Reduce Storage, Reduce Costs, Increase Performance Bill Hodak Principal Product Manager

The following is intended to outline our general product direction
The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.

Agenda Data Growth Challenges Advanced Compression Feature Overview
Relational Data Compression Unstructured Data Compression Backup Data Compression Network Transport Data Compression Questions and Answers

Challenges Explosion in Data Volumes
Government Regulations (Sarbanes-Oxley, etc) User Generated Content (Web 2.0) Application Consolidation IT Managers Must Support Larger Volumes of Data with Limited Technology Budgets Need to optimize storage consumption Also maintain acceptable application performance Intelligent and Efficient Compression Technology can Help Address These Challenges The volume of data being generated and retained by businesses has seen an exponential growth in the last few years. On an average, it is not uncommon to see data growing by 2-3 times every couple of years thanks to a variety of factors such as government regulations that mandate storing historical data for a certain number of years, massive amount of user generated content through web 2.0 applications and increasing adoption of multimedia content – enabled in turn by growing penetration of broadband technologies. Consequently, terabytes sized database – that were a novelty in the past – have become so commonplace these days. A key challenge before enterprises today is how to manage this enormous volume of data in a cost effective manner as they still have a limited IT budget. On a more technical level, there is also an associated challenge of ensuring the application performance does not degrade unacceptably while accessing this enormously large volume of data. This brings compression technology at forefront. We have known and used compression technology in some form of other so it should not need much explanation. The most prominent benefit of compression of course is the reduced storage consumption. However, the compression technology needs to be highly efficient and intelligent before it can be used with enterprise application in view of their demanding performance and scalability requirements.

Oracle Advanced Compression Option
OLTP Table Compression SecureFiles Deduplication SecureFiles Compression Data Pump Data Compression RMAN Fast Backup Compression Data Guard Redo Transport Compression Relational Data Compression Unstructured Data Compression Backup Data Compression Network Data Compression Reduces resource requirements and costs Storage System Network Bandwidth Memory Usage

Table Compression Introduced in Oracle Database 9i Release 2
Compression during bulk load operations (Direct Load, CTAS) Data modified using conventional DML not compressed Optimized compression algorithm for relational data Improved performance for queries accessing large amounts of data Fewer I/Os Buffer Cache efficiency Data is compressed at the database block level Compression enabled at either the table or partition level Completely transparent to applications Being self-contained is good b/c in order to read a compressed block we don’t have to access ‘other blocks’ that contain the symbol table or compression dictionary. For example, IBM has a table-wide symbol table. So every time you read a block that is compressed – you also have to read the blocks holding the symbol table – meaning extra I/O. We don’t have to do that!!

OLTP Table Compression
Oracle Database 11g extends table compression for OLTP data Support for conventional DML Operations (INSERT, UPDATE) New algorithm significantly reduces write overhead Batched compression minimizes impact for OLTP transactions No impact on reads Reads may actually see improved performance due to fewer I/Os and enhanced memory efficiency Lets first talk about compression of regular relational data. We were the early pioneer in terms of compression technology for databases when we introduced table compression for bulk load operations in Oracle9i. Using this feature, customers can compress data at the time of doing bulk load using operations such as DIRECTLOAD, CTAS, etc. However, until now, compression was not available for regular data manipulation operations such as INSERT and UPDATE. In Oracle database 11g, we have extended the compression technology to support these operations as well. Consequently, compression in Oracle Database 11g can be used for all kinds of workload – be it OLTP or DW. It is important to mention here is that table compression enhancements introduced Oracle database 11g are not just incremental changes. Rather enormous amount of work has gone into making sure that the new compression technology has negligible impact on updates since any noticeable write time penalty due to compression won’t be acceptable in OLTP environment. As a result compression technology in Oracle database 11g is very efficient which could reduce the space consumption up to 2 to 3 times. And while you do that, not only your write performance does not degrade, your read performance or queries actually improves. This is because unlike desktop based compression techniques where you have to wait for data to uncompressed, our technology reads the compressed data directly and does not require any uncompression. This make sure that our query performance does not degrade because of compression. Now, the question is how does the query performance improve. It does so because we need to fetch less data to answer a query due to compression. Another advantage of fetching less data to satisfy a query is that we can now use the memory used to buffer the data read from disk more efficient thereby maximizing the memory utilization efficiency. Finally, just to make sure that I do not miss any thing obvious, our compression technology is completely application transparent. That mean that you can use this technology with any home grown or packaged application such as SAP, Siebel , EBS, etc.

OLTP Table Compression Process
Initially Uncompressed Block Compressed Block Partially Compressed Block Empty Block Legend Header Data Free Space Uncompressed Data Compressed Data

Block-Level Batch Compression
Patent pending algorithm minimizes performance overhead and maximizes compression Individual INSERTs and UPDATEs do not cause recompression Compression cost is amortized over several DML operations Block-level (Local) compression keeps up with frequent data changes in OLTP environments Competitors use static, fixed size dictionary table thereby compromising compression benefits

Initially Uncompressed Block Employee Table Smith John 3 Doe Jane 4 2 1 LAST_NAME FIRST_NAME ID Header 1•John•Doe 2•Jane• Doe 3•John•Smith 4• Jane • Doe Free Space Start with a table ‘Employee’ that has compression enabled and we can see a block containing this data. In the beginning the block is not compressed because it is NOT full Then we issue an insert statement which triggers the block to compress… We create the Symbol Table (or dictionary) in the block header for data that has duplicate values (i.e. ‘John’,’Doe’,and ‘Jane’) Then we replace the data in the block with the relevant symbol INSERT INTO EMPLOYEE VALUES (5, ‘Jack’, ‘Smith’); COMMIT;

Employee Table Block 1•• 2•• 3•• 4 •  •  5•Jack• Free Space Compressed Block Doe Jane 4 Smith John 3 Jack 5 2 1 LAST_NAME FIRST_NAME ID Header John=|Doe=|Jane=|Smith= 1•John•Doe 2•Jane• Doe 3•John•Smith 4• Jane • Doe Free Space Start with a table ‘Employee’ that has compression enabled and we can see a block containing this data. In the beginning the block is not compressed because it is NOT full Then we issue an insert statement which triggers the block to compress… We create the Symbol Table (or dictionary) in the block header for data that has duplicate values (i.e. ‘John’,’Doe’,and ‘Jane’) Then we replace the data in the block with the relevant symbol Local Symbol Table

Table Compression Syntax
OLTP Table Compression Syntax: CREATE TABLE emp ( emp_id NUMBER , first_name VARCHAR2(128) , last_name VARCHAR2(128) ) COMPRESS FOR OLTP; Direct Load Compression Syntax (default): ) COMPRESS [BASIC]; Lets first talk about compression of regular relational data. We were the early pioneer in terms of compression technology for databases when we introduced table compression for bulk load operations in Oracle9i. Using this feature, customers can compress data at the time of doing bulk load using operations such as DIRECTLOAD, CTAS, etc. However, until now, compression was not available for regular data manipulation operations such as INSERT, UPDATE and DELETES. In Oracle database 11g, we have extended the compression technology to support these operations as well. Consequently, compression in Oracle Database 11g can be used for all kinds of workload – be it OLTP or DW. It is important to mention here is that table compression enhancements introduced Oracle database 11g are not just incremental changes. Rather enormous amount of work has gone into making sure that the new compression technology has negligible impact on updates since any noticeable write time penalty due to compression won’t be acceptable in OLTP environment. As a result compression technology in Oracle database 11g is very efficient which could reduce the space consumption up to 2 to 3 times. And while you do that, not only your write performance does not degrade, your read performance or queries actually improves. This is because unlike desktop based compression techniques where you have to wait for data to uncompressed, our technology reads the compressed data directly and does not require any uncompression. This make sure that our query performance does not degrade because of compression. Now, the question is how does the query performance improve. It does so because we need to fetch less data to answer a query due to compression. Another advantage of fetching less data to satisfy a query is that we can now use the memory used to buffer the data read from disk more efficient thereby maximizing the memory utilization efficiency. Finally, just to make sure that I do not miss any thing obvious, our compression technology is completely application transparent. That mean that you can use this technology with any home grown or packaged application such as SAP, Siebel , EBS, etc.

Table Compression Advisor Estimate Potential Storage Savings
Available in 11g Release 2 Available on OTN * Supports Oracle Database 9i Release 2 through 11g Release 1 Shows projected compression ratio for uncompressed tables Reports actual compression ratio for compressed tables (11g Only) Lets first talk about compression of regular relational data. We were the early pioneer in terms of compression technology for databases when we introduced table compression for bulk load operations in Oracle9i. Using this feature, customers can compress data at the time of doing bulk load using operations such as DIRECTLOAD, CTAS, etc. However, until now, compression was not available for regular data manipulation operations such as INSERT, UPDATE and DELETES. In Oracle database 11g, we have extended the compression technology to support these operations as well. Consequently, compression in Oracle Database 11g can be used for all kinds of workload – be it OLTP or DW. It is important to mention here is that table compression enhancements introduced Oracle database 11g are not just incremental changes. Rather enormous amount of work has gone into making sure that the new compression technology has negligible impact on updates since any noticeable write time penalty due to compression won’t be acceptable in OLTP environment. As a result compression technology in Oracle database 11g is very efficient which could reduce the space consumption up to 2 to 3 times. And while you do that, not only your write performance does not degrade, your read performance or queries actually improves. This is because unlike desktop based compression techniques where you have to wait for data to uncompressed, our technology reads the compressed data directly and does not require any uncompression. This make sure that our query performance does not degrade because of compression. Now, the question is how does the query performance improve. It does so because we need to fetch less data to answer a query due to compression. Another advantage of fetching less data to satisfy a query is that we can now use the memory used to buffer the data read from disk more efficient thereby maximizing the memory utilization efficiency. Finally, just to make sure that I do not miss any thing obvious, our compression technology is completely application transparent. That mean that you can use this technology with any home grown or packaged application such as SAP, Siebel , EBS, etc. *

Monitoring Table Compression
View: DBA_TABLES, columns: COMPRESSION ( ENABLED / DISABLED ) COMPRESS_FOR ( FOR ALL OPERATIONS / DIRECT LOAD ONLY ) Lets first talk about compression of regular relational data. We were the early pioneer in terms of compression technology for databases when we introduced table compression for bulk load operations in Oracle9i. Using this feature, customers can compress data at the time of doing bulk load using operations such as DIRECTLOAD, CTAS, etc. However, until now, compression was not available for regular data manipulation operations such as INSERT, UPDATE and DELETES. In Oracle database 11g, we have extended the compression technology to support these operations as well. Consequently, compression in Oracle Database 11g can be used for all kinds of workload – be it OLTP or DW. It is important to mention here is that table compression enhancements introduced Oracle database 11g are not just incremental changes. Rather enormous amount of work has gone into making sure that the new compression technology has negligible impact on updates since any noticeable write time penalty due to compression won’t be acceptable in OLTP environment. As a result compression technology in Oracle database 11g is very efficient which could reduce the space consumption up to 2 to 3 times. And while you do that, not only your write performance does not degrade, your read performance or queries actually improves. This is because unlike desktop based compression techniques where you have to wait for data to uncompressed, our technology reads the compressed data directly and does not require any uncompression. This make sure that our query performance does not degrade because of compression. Now, the question is how does the query performance improve. It does so because we need to fetch less data to answer a query due to compression. Another advantage of fetching less data to satisfy a query is that we can now use the memory used to buffer the data read from disk more efficient thereby maximizing the memory utilization efficiency. Finally, just to make sure that I do not miss any thing obvious, our compression technology is completely application transparent. That mean that you can use this technology with any home grown or packaged application such as SAP, Siebel , EBS, etc.

<Insert Picture Here>
Table Compression Results

Oracle’s Internal E-Business Suite DB
Overall database storage savings: 3x Table compression x Index compression x LOB compression x 95 TB of Total Storage Savings! Primary, standby, test, dev, and backup Payroll, Order-2-Cash, AP/AR batch flows, Self-Service flows run without regression, Queries involving full table scans show speedup 4-node Sun E25K RAC, 11gR1 17

Oracle’s Internal Beehive Email DB
Average Compression Ratio: 2x Oracle Database 11g Release 1 Exadata Storage Servers Storage savings add up with standby, mirroring, flash recovery area Phase I in production for 28K employees 195 TB of storage savings with SecureFiles Compression Phase II, Dec 2009 Migrate all 90K employees on this server 581TB estimated storage savings with SecureFiles Compression Performance improved by caching more data due to compression - reducing I/O latencies 18

SAP R/3, BW, Leading Global Company
Compression on SAP databases at leading global company Oracle Database 11g Release 2 SAP R/3 DB 4.67TB Uncompressed 1.93 TB Compressed 2.4x compression ratio SAP BW DB 1.38 TB Uncompressed .53 TB Compressed 2.6x compression ratio Leverage 11g compression for Tables, Indexes and LOB data 19

Real Networks Rhapsody Digital Music Subscription Service
Compression results using 11g Release 1 Average Compression Ratio: x Highest compression ratio: 8x Total Savings: 3.5TB 20

CERN Oracle Database 11g Release 2 Average Compression Ratio: 2x
Highest Compression Ratio 6x Scientific application supporting particle research 21

Introduction to SecureFiles
Next-generation high performance LOB Superset of LOB interfaces allows easy migration from LOBs Transparent deduplication, compression, and encryption Leverage the security, reliability, and scalability of database Enables consolidation of file data with associated relational data Single security model Single view of data Single management of data Scalable to any level using SMP scale-up or grid scale-out

SecureFiles Deduplication
Secure Hash Enables storage of a single physical image for duplicate data Significantly reduces space consumption Dramatically improves writes and copy operations No adverse impact on read operations May actually improve read performance for cache data Duplicate detection happens within a table, partition or sub-partition Specially useful for content management, applications and data archival applications Create a table with a SECUREFILE LOB column and LOB deduplication enabled on only one partition. Only LOBs that belong to partition p1 are deduplicated. CREATE TABLE t1 ( REGION VARCHAR2(20), a BLOB) LOB(a) STORE AS SECUREFILE ( CACHE ) PARTITION BY LIST (REGION) ( PARTITION p1 VALUES ('x', 'y') DEDUPLICATE ), PARTITION p2 VALUES (DEFAULT) ); Create a table with a SECUREFILE LOB column and disable deduplication. LOBs will be created with deduplication disabled. CREATE TABLE t1 ( a CLOB) KEEP_DUPLICATES

SecureFiles Compression
Significant storage savings for unstructured data Three levels of compression (LOW/[MEDIUM]/ HIGH ) provide desired ratios 2-3x compression for typical files (combination of doc, pdf, xml) Compression Level LOW (NEW in 11.2) Compression algorithm optimized for high performance 3x less CPU utilization than default SecureFiles Compression Maintains 80% compression of default SecureFiles Compression Allows for random reads and writes to Compressed SecureFile data Can be specified at a partition level Automatically detects if SecureFile data is compressible Independent of table or index compression Compression algorithm : ZLIB (support for more algorithms upcoming) Compression Overhead: 3- 5% Random reads/writes: utl_compress PL/SQL package which provide for compression/decompression functionality – does NOT provide for random access for read/write. With SecureFiles, only the required set of data blocks are uncompressed for providing random read/write access. More over, this is completely transparent to user applications. SecureFiles automatically maintains the mapping between uncompressed and compressed offsets. If the compression level is changed from MEDIUM to HIGH, there is no need to change the user application as the mapping is automatically updated to reflect the new algorithm. Create a table with a SECUREFILE LOB column and LOB compression enabled on only one partition. Only LOBs that belong to partition p1 are compressed. CREATE TABLE t1 ( REGION VARCHAR2(20), a BLOB) LOB(a) STORE AS SECUREFILE ( CACHE ) PARTITION BY LIST (REGION) ( PARTITION p1 VALUES ('x', 'y') COMPRESS ), PARTITION p2 VALUES (DEFAULT) ); Create a table with a SECUREFILE LOB column and LOB compression disabled. CREATE TABLE t1 ( a CLOB) NOCOMPRESS

SecureFiles Compression Syntax
CREATE TABLE t1 (a CLOB) LOB(a) STORE AS SECUREFILE ( COMPRESS CACHE ); Deduplication Syntax DEDUPLICATE Compression algorithm : ZLIB (support for more algorithms upcoming) Compression Overhead: 3- 5% Random reads/writes: utl_compress PL/SQL package which provide for compression/decompression functionality – does NOT provide for random access for read/write. With SecureFiles, only the required set of data blocks are uncompressed for providing random read/write access. More over, this is completely transparent to user applications. SecureFiles automatically maintains the mapping between uncompressed and compressed offsets. If the compression level is changed from MEDIUM to HIGH, there is no need to change the user application as the mapping is automatically updated to reflect the new algorithm.

Data Pump Compression Metadata compression available since Oracle Database 10g Oracle Database 11g extends compression to table data during exports No need to decompress before import COMPRESSION={ALL | DATA_ONLY | [METADATA_ONLY] | NONE} Single step compression of both data and metadata Compressed data directly hits disk resulting in reduced disk space requirements Internal tests reduced dump file size up to 75% Application transparent Complete Data Pump functionality available on compressed files

Advanced Compression New in Oracle Database 11g Release 2
RMAN Backup Compression Compression Level LOW (New in 11.2) Fastest compression algorithm Best suited when backup is constrained by CPU Compression Level MEDIUM (New in 11.1) Balance between CPU usage and compression ratio Formerly Fast RMAN Backup Compression 11.1 syntax supported in 11.2 Compression LEVEL HIGH (New in 11.2) Best compression ratio and highest CPU utilization Best suited when backup is constrained by network or I/O LOW - corresponds to LZO (11gR2) MEDIUM - corresponds to ZLIB (11gR1) DEFAULT - corresponds to BZIP2 (10g style compression) HIGH - corresponds to GZIP (11gR2) Since the performance of the various compression levels depends on the nature of the data in the database, network configuration, system resources and the type of computer system and its capabilities, Oracle cannot document universally applicable performance statistics. The decision as to which level is best must factor in on how balanced your system is regarding bandwidth into the CPU as well as the actual speed of the CPU. It is highly recommended that you run tests with the different compression levels on the data in your environment. Choosing a compression level based on your environment, network traffic characteristics (workload) and dataset is the only way to ensure that the backup set compression level can satisfy your organization's performance requirements and any applicable service level agreements.

Backup Compression Syntax
Data Pump Syntax PROMPT> expdp hr DIRECTORY=dpump_dir1 DUMPFILE=hr_comp.dmp COMPRESSION=ALL FAST RMAN Backup Compression Configuration RMAN> configure compression algorithm 'MEDIUM'; RMAN Backup Compression Syntax RMAN> BACKUP AS COMPRESSED BACKUPSET DATABASE PLUS ARCHIVELOG; In 10gR2: Configuring Compressed Backupsets as Default for Tape or Disk You can configure RMAN to use compressed backupsets by default on a particular device type, by using the CONFIGURE DEVICE TYPE command with the BACKUP TYPE TO COMPRESSED BACKUPSET option, as shown in the following examples. RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET; RMAN> CONFIGURE DEVICE TYPE sbt BACKUP TYPE TO COMPRESSED BACKUPSET; To disable compression, use the CONFIGURE DEVICE TYPE command with arguments specifying your other desired settings, but omitting the COMPRESSED keyword, as in the following examples: RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO BACKUPSET; RMAN> CONFIGURE DEVICE TYPE sbt BACKUP TYPE TO BACKUPSET;

RMAN Compression Results

RMAN Compression Overview
Data from Oracle’s implementation of Oracle Applications 3.5 GB Database Oracle Enterprise Linux Oracle Database 11g Release 1 Test 1: Slow I/O (16 MB/s) 11g RMAN without Compression 10g RMAN with Compression 11g RMAN with MEDIUM Compression Test 2: Fast I/O (200 MB/s)

Backup Compression Results
Backup Size Comparison Compression reduced backup size by 6x GB 1 Backup to local disk which has write speed of 16 MB/s (very slow disk) Backup Type DB size (allocated) Backup size Compression ratio Time Speed No compression 3351 MB 3085 MB 1.08:1 228s 14.7 MB/s BZIP2 compression 519 MB 6.46:1 201s 16.7 MB/s ZLIB compression 521 MB 6.43:1 81s 41.5 MB/s Here, we run compression to very slow output disk – which gives speed of only 16 MB/s. Since this setup was not optimized for I/O throughput, compression can actually improve backup speed because output disk was slow. To explain a little; the speed of the output disk was in range of 16 MB/s (measured by dd). Because of that, non-compressed backup have speed of 14.7 MB/s. However, our new compression cuts amount of data needed to write by 6 times – and it can do that at speed of 40 MB/s. So RMAN backup with compression ends up being actually faster than non-compressed backup. So we can say something like this: “If you backup to slow disks or to NFS/tape over slow network, then compression can significantly reduce backup speed if data is highly compressible”. 2 Backup to /dev/null (super fast disk) 18s 186.0 MB/s Here, we run compression to super fast output disk. It showed that ZLIB compression is really two times faster than BZIP2. Of course backup to /dev/null has throughput which very near to speed of underlying disk subsystem which is about 200 MB/s.

Backup Speed Comparison
Backup Compression Backup Speed Comparison Slow I/O (Tape) 11g Compression is almost 2.5x faster than 10g Compression Time (Seconds) 1 Backup to local disk which has write speed of 16 MB/s (very slow disk) Backup Type DB size (allocated) Backup size Compression ratio Time Speed No compression 3351 MB 3085 MB 1.08:1 228s 14.7 MB/s BZIP2 compression 519 MB 6.46:1 201s 16.7 MB/s ZLIB compression 521 MB 6.43:1 81s 41.5 MB/s Here, we run compression to very slow output disk – which gives speed of only 16 MB/s. Since this setup was not optimized for I/O throughput, compression can actually improve backup speed because output disk was slow. To explain a little; the speed of the output disk was in range of 16 MB/s (measured by dd). Because of that, non-compressed backup have speed of 14.7 MB/s. However, our new compression cuts amount of data needed to write by 6 times – and it can do that at speed of 40 MB/s. So RMAN backup with compression ends up being actually faster than non-compressed backup. So we can say something like this: “If you backup to slow disks or to NFS/tape over slow network, then compression can significantly reduce backup speed if data is highly compressible”. 2 Backup to /dev/null (super fast disk) 18s 186.0 MB/s Here, we run compression to super fast output disk. It showed that ZLIB compression is really two times faster than BZIP2. Of course backup to /dev/null has throughput which very near to speed of underlying disk subsystem which is about 200 MB/s.

Backup Speed Comparison
Backup Compression Backup Speed Comparison Fast I/O (Disk) 11g Compression is almost 2.5x faster than 10g Compression Time (Seconds) 1 Backup to local disk which has write speed of 16 MB/s (very slow disk) Backup Type DB size (allocated) Backup size Compression ratio Time Speed No compression 3351 MB 3085 MB 1.08:1 228s 14.7 MB/s BZIP2 compression 519 MB 6.46:1 201s 16.7 MB/s ZLIB compression 521 MB 6.43:1 81s 41.5 MB/s Here, we run compression to very slow output disk – which gives speed of only 16 MB/s. Since this setup was not optimized for I/O throughput, compression can actually improve backup speed because output disk was slow. To explain a little; the speed of the output disk was in range of 16 MB/s (measured by dd). Because of that, non-compressed backup have speed of 14.7 MB/s. However, our new compression cuts amount of data needed to write by 6 times – and it can do that at speed of 40 MB/s. So RMAN backup with compression ends up being actually faster than non-compressed backup. So we can say something like this: “If you backup to slow disks or to NFS/tape over slow network, then compression can significantly reduce backup speed if data is highly compressible”. 2 Backup to /dev/null (super fast disk) 18s 186.0 MB/s Here, we run compression to super fast output disk. It showed that ZLIB compression is really two times faster than BZIP2. Of course backup to /dev/null has throughput which very near to speed of underlying disk subsystem which is about 200 MB/s.

Network Compression Data Guard Redo Transport Services
Compress network traffic between primary and standby databases Lower bandwidth networks (<100Mbps) 15-35% less time required to transmit 1 GB of data Bandwidth consumption reduced up to 35% High bandwidth networks (>100 Mbps) Compression will not reduce transmission time But will reduce bandwidth consumption up to 35% Syntax: LOG_ARCHIVE_DEST_3='SERVICE=denver SYNC COMPRESSION=ENABLE|[DISABLE]' Ref. MetaLink “Redo Transport Compression in a Data Guard Environment” Note – sufficient cpu cycles must be available in order for compression to achieve the above benefits. Network latency will not impact throughput or transmission time for Oracle Database 11g environments. Given that compression ratios vary from one application to the next, Oracle recommends that customers test with compression enabled to validate the benefit of utilizing compression before introducing it to the production environment.

Redo Transport Compression
2X Compression ! 5X Compression ! More efficient bandwidth utilization, up to 5x compression ratio Compression did not impact throughput or response time OLTP workload JPetStore application Batch Workload Direct load insert Validation performed by CTC in collaboration with Oracle Japan Grid Center

Summary Comprehensive data compression capabilities for all types of data Structured, Unstructured, Backup, Network Reduces storage consumption by 2 to 4 times Improves read performance Enhances memory, buffer cache utilization Complete application transparency Benefits diverse application workloads So, to sum it up, as we have seen Advanced Compression Option in Oracle Database 11g contains a compelling set of compression technologies to help customers deal with data volume explosion in a cost effective manner without compromising application performance. Our compression technologies not only reduce disk space requirements, they improve application performance, enhance memory and network efficiency and can be used with any application out of the box. We are very excited about this technology and truly hope that this offering will help customers manage their large volume of data in the most cost effective manner.

Open World Sessions Oracle’s Hybrid Columnar Compression: The Next-Generation Compression Technology [ S ] Tuesday 13:00 | Moscone South | Room 102 Oracle Advanced Compression in Oracle Database 11g Release 2: Value/Performance [S ] Thursday 09:00 | Moscone South | Room 102 Oracle Advanced Compression: Stories from the Most Trusted Source – Customers! [ S ] Thursday 12:00 | Moscone South | Room 104 The Oracle Advanced Compression Experience – Hands on Lab [S311813] Thursday 15:00 | Marriott Hotel | Golden Gate B2 So, to sum it up, as we have seen Advanced Compression Option in Oracle Database 11g contains a compelling set of compression technologies to help customers deal with data volume explosion in a cost effective manner without compromising application performance. Our compression technologies not only reduce disk space requirements, they improve application performance, enhance memory and network efficiency and can be used with any application out of the box. We are very excited about this technology and truly hope that this offering will help customers manage their large volume of data in the most cost effective manner.

For More Information search.oracle.com Or advanced compression
OTN:

Real World Table Compression Tests
Data from Oracle’s implementation of Oracle Applications Compressed the 10 Largest Tables Two copies of each table: Compressed and Uncompressed Oracle Enterprise Linux Oracle Database 11g Release 1 Test Queries Full Table Scan Index Range Scan DML Operations (Insert, Update, Delete)

Table Compression Test Results
Storage Utilization More than 70% Storage Savings MB

Table Scan Performance Compression is 2.5x Faster Time (seconds)

Index Range Scan Performance No Performance Impact on Index Scans Time (seconds)

DML Performance Time (seconds) Compression has less than 3% overhead Note: DML Workload comprises equal number of INSERT, UPDATE and DELETE statements. Performance overhead may be higher for INSERT only or UPDATE only workload

Competitive Analysis

Competitive Analysis – DB2
- More compression overhead - Transactional compression - Minimal compression overhead - Batched compression - None Unstructured data compression and de-duplication (SecureFiles) Some decompression overhead Zero decompression overhead Table/partition level compression dictionary Block level compression - New data may not be compressed / offline rebuild symbol table - Max 4K values per table - Adaptive / dynamic compression - Unlimited compression values IBM DB2 Oracle

Competitive Analysis – DB2
Even without compression, Oracle needs less disk space than DB2: Oracle uses variable length representation for numbers – DB2 uses fixed length DB2 has more overhead for VARCHAR data SAP BW data needs 30-50% less disk space if stored in Oracle

Competitive Analysis – Teradata
None Unstructured data compression and de-duplication (SecureFiles) - More compression overhead - Transactional compression - Minimal compression overhead - Batched compression Backup compression Limited data type support All data types supported - Admin must define compression values - Max 255 compression values - Dynamic compression values - Unlimited values Field level compression Block level compression Teradata Oracle

Competitive Analysis – Hardware Based Compression
Oracle Hardware Compression Database specific compression algorithm Generic compression algorithm -deficient for databases Fine grained compression – compress at tablespace, table or partition level No fine grained compression -compress at file level Improved read performance in several cases – no decompression overhead Poor read performance – significant decompression overhead Improved memory efficiency - data stays compressed in memory No memory benefits - data needs to be decompressed Batched algorithm for minimal compression overhead Data updates are very expensive Benefits automatically cascade to all environments Benefits limited to specific hardware environment

Compression: Oracle vs Competition Top 10 Tables in an ERP Application
Competitive Analysis 1000 2000 3000 4000 5000 6000 Size, MB Oracle No Compress Competition No Oracle Competition Compression: Oracle vs Competition Top 10 Tables in an ERP Application DB2 NoCompress consumes over 100% more space than Oracle NoCompress DB2 Compress consumes over 90% more space than Oracle Compress Oracle NoCompress = 2344 MB DB2 NoCompress = 5077 MB Oracle Compress = 550 MB DB2 Compress = 1060 MB

Bill Hodak Principal Product Manager

Similar presentations

Presentation on theme: "Bill Hodak Principal Product Manager"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Bill Hodak Principal Product Manager

Similar presentations

Presentation on theme: "Bill Hodak Principal Product Manager"— Presentation transcript:

Similar presentations

About project

Feedback