Included with every 3PAR array at no cost through the all-inclusive license, 3PAR Adaptive Data Reduction with compression offers the ability to compress Oracle data. Technical deep dive here with links to related white papers.
Enter 3PAR Adaptive Data Reduction with compression. This new HPE 3PAR StoreServ feature not only offers the ability to compress your Oracle data but it’s also included with every 3PAR array at no cost through the all-inclusive license.
3 Key Features of 3PAR Adaptive Data Reduction
The newest feature set with the 3PAR array is Adaptive Data Reduction (ADR). ADR has three major functional features for improving storage efficiency.
- Thin Provisioning and Thin Persistence—use of traditional HPE Thin Technologies
- Deduplication—use of HPE’s data deduplication engine through the Gen5 ASIC
- Compression—new feature that compresses data at the virtual volume level
The combination of these features generates an overall compaction ratio that reflects maximum space savings. Looking at these features in the context of Oracle Databases, most of the benefit comes from Thin Provisioning and compression. Typically, databases do not deduplicate very well, but there are some use cases where deduplication can provide benefits. These have to do with deduplication of 3PAR-based Thin Clones and RMAN images. But for the database itself, deduplication is not what provides the main value. Compression and Thin Provisioning, on the other hand, can add significant value to space savings, especially when customers have very large data footprints.
The great news is all of these features are part of the all-inclusive license as of 3PAR software revision 3.3.1. This translates to a potential savings that could be significant if you are considering buying compression licenses for Oracle Database.
3PAR Adaptive Data Reduction Architecture and Oracle Data flow
Figure 1 shows an overview diagram on how the Adaptive Data Reduction functions. The 3PAR array allows for Thin Provisioning of volumes. Part of the job of the ASIC is to detect zeroes and place unused space back into the free pool. This provides for Thin Persistence and keeps Oracle data no longer needed from being stranded in the Oracle ASM groups.
Once the data passes the ASIC, the remaining data from the 3PAR volume is run through a compression routine using the processors on the 3PAR node. The resulting data is packed using 3PAR’s Data Packing technology and written to the flash storage on the array. The combination of 3PAR’s Thin Technologies and Adaptive Data Reduction technologies creates an overall compaction ratio. Compression and deduplication each have its own ratio.
For more details on this see the white paper: Adaptive Data Reduction Technical White Paper
About Thin Provisioning and Thin Persistence
Oracle data files and growth of Thin Provisioned volumes in ASM
When using Thin Provisioning with the 3PAR and Oracle Database, it is important for the DBA to enable AUTOEXTEND on the data files in the ASM group. The reason for this is, if the data file size gets fully initialized, this defeats the value of thin provisioning because the volumes will be fully provisioned. Some Oracle DBAs may prefer this so they can manage the free space within the ASM group itself and not allow it to be managed at the storage array. While this approach may work well in some isolated circumstances, when the data availability needs to be shared between databases, ASM groups or even other applications, a best practice is to keep the free data on the storage array so it can be effectively shared.
Some DBAs may have a concern about having to allocate storage with AUTOEXTEND for performance reasons. Tests we have run in past experiments and did not show any noticeable performance degradation. It is possible in very few configurations with high performance utilization, this could be noticeable and a concern, but this would be more an exception, rather than the rule.
Using AUTOEXTEND with ASM and Thin Provisioning with the 3PAR can provide a very significant savings to the infrastructure and operations.
Oracle ASRU utility for freeing up unused data in ASM groups
Due to the nature of how Oracle ASM is designed, when data objects are deleted the usage for the data shows free and available, but this does not immediately reflect into Thin Persistence zero detect on the 3PAR array. This is because, even with the data being free in the ASM group from an Oracle view, it is not free from the VV itself. To completely free the data from the Thin Provisioned volumes in the ASM groups, an Oracle tool called ASM Storage Reclamation Utility (ASRU) can be used. This is a tool that acts at the ASM group level searching for unused data in the group. When it finds it, zeroes are written. When zeroes are written, the 3PAR ASIC detects them and returns those storage locations to the CPG as free data resulting in Thin Persistence.
For information on Oracle’s ASRU utility see this white paper: Oracle Automatic Storage Management and Thin Reclamation Paper. For version 1.2 of the ASRU tool use: ASRU Version 1.2 download.
Compression
Compression is very popular in this day of storage growth and needs to be efficient with the fast storage access of flash. HPE 3PAR compression was introduced with the 3.3.1 release of 3PAR software. Oracle databases are a good candidate for savings through compression.
Oracle offers their own compression at the database object level, including the popular option, Oracle Advanced Compression (OAC). This feature compresses tables and indexes at the database block level. Similar patterns from multiple rows of data can be identified in a block. The pattern is written in a symbol table, and then each row location containing that pattern points back to the one pattern.
Oddly enough, this form of compression looks quite a bit like deduplication. Using OAC is NOT free! In fact, it is licensed on a per-core or per-user basis. With a database using 64 CPU cores, the cost could be in the tens of thousands of dollars. The good news with compressing data on the 3PAR with 3.3.1 version OS is that there are no additional license fees for compression. The saved storage space can be reclaimed by group who manages the storage.
Compression acts on all blocks within a virtual volume being compressed by 3PAR. In the case of Oracle ASM groups, this is going to mainly be the tablespace data files, possibly the redo and archive logs. It’s typically recommended to keep redo and archive logs in separate ASM groups. Compressing the redo logs generally doesn’t provide much benefit. Compression ratios on Oracle data may vary but in general the benefit is at least 2:1.
Dig deeper on the topic with new whitepaper: HPE Best Practices for Oracle 12c1 on HPE 3PAR StoreServ Storage with Compression
HPE recently completed a project on how Oracle compression compares to 3PAR compression on database objects of the same type. The paper is separated into the following sections:
- Executive Summary
- Solution Overview and Components
- Best Practices for Configuration
- 3PAR versus Oracle Compression Results
- Analysis and Recommendations
Read this white paper now: HP Best Practices for Oracle 12c1 on HPE 3PAR StoreServ Storage with Compression
Figure 2 illustrates the final results in reference to the comparison between Oracle Advanced Compression and 3PAR Compression on the same template build of data objects in the databases. The white paper compares both OLTP and DSS with Oracle Advanced Compression to the same with 3PAR compression. In both cases the compression ratio for 3PAR compression was better than with Oracle compression. The MAJOR benefit of using 3PAR compression is the cost savings or absence of need to invest in Oracle licensing. Oracle Advanced Compression would result in a cost of $11,500.00 per core!
3PAR Compression Estimator
The 3PAR array has a feature to estimate the compression in a given virtual volume or set of virtual volumes. This tool is a function within the StoreServ Management Console (SSMC) where you simply choose the VV and the run the estimator against it. In the realm of Oracle ASM, there is no need to run the estimator on every VV in the ASM group. Just one VV per group needs to be checked. So even if the ASM group has 16 VVs, only one needs to be checked. This is because of the way the data is evenly striped across all VV’s in the ASM group. The compression ratio should be the same on all VVs if ASM external redundancy is used. On ASM Normal Redundancy, there may be some differences because of how ASM extends and failure groups are managed.
Figure 3 illustrates a screenshot of the estimation screens when compression estimator is run. This is a great method for determining the value of compression on a particular object set of Oracle data. It is also not specific to Oracle but will work with any SSD VV targeted for compression. The VV can’t be fully provisioned. It must be a Thin and/or Dedupe VV.
HPE 3PAR StoreServ with 3.3.1 OS provides a compression solution that can potentially save a large amount of money by optimizing storage capacity utilization. Using ADR and the compression features with Oracle Database can save potentially tens of thousands of dollars!
For more on reducing additional license costs with other features in your database environment: Reducing Costs in your Oracle Database Environment.
For more on HPE Storage solutions with Oracle, see the Oracle and HPE Storage solutions home on hpe.com.
Meet Ar
xxx
StorageExperts
Our team of Hewlett Packard Enterprise storage experts helps you to dive deep into relevant infrastructure topics.
