Frits is basically correct, as confirmed by ATG below in response to my request for clarification: Am I wrong that the applications could not really know whether the physical storage is using HCC by the time it accesses the data? I wonder whether this is failing to understand the difference between “your support does not include Oracle evaluating and setting up HCC for your particular system implementation and if you screw that up backing it out is your problem” and “if you use HCC on any part of an EBS database your installation is unsupported” and the huge range of possibilities in between. Mark, Thanks for the email. You’re not wrong, an EBS instance would not know if HCC is in use. To clarify the recommendation: The Oracle E-Business Suite Performance Team does not currently recommend HCC for EBS. Our testing has shown degradation in performance with HCC and EBS (an OLTP system with high-volume tables). Thanks. ~ep Elke Phelps | Product Management | 303.661.2475 | <mailto:kenneth.baxter@xxxxxxxxxx> elke.phelps@xxxxxxxxxx Oracle E-Business Applications Technology Group ORACLE | 600 Oracle Parkway | Redwood Shores, CA 94065 <http://blogs.oracle.com/stevenchan> Oracle E-Business Suite Technology Blog Hardware and Software Engineered to Work Together From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of John Piwowar Sent: Wednesday, May 07, 2014 11:26 AM To: Frits Hoogland Cc: George.Leonard@xxxxxxxxx; ORACLE-L Subject: Re: EBS (12.1.3) / HCC and SSC Understood. There are also patches which perform mass data fixes/updates, though, and those could be more problematic in the "HCC doesn't like changes" context. The real reason for lack of support (or lack of documented support), however, could be more prosaic: number of EBS customers on Exa platforms. Given the range of customers they support, and the number of moving parts in EBS, the ATG team has to be selective in the database features that they test and certify. That list, as I understand it, can be heavily influenced by customer feedback. If enough customers ask for a statement of support for HCC in EBS, the ATG team might take a look; they tend to be very responsive to that sort of stuff. Please note that I don't have any inside info on the inner workings of the Oracle EBS ATG. This is just a summary of my impressions from years of reading Steven Chan's blog, and should not be misinterpreted as an official position on *anything.* ;) On Wed, May 7, 2014 at 7:53 AM, Frits Hoogland <frits.hoogland@xxxxxxxxx> wrote: Please mind the partitioning scheme and the table fields are not changed in any way with HCC, it's the way the data is stored which is only changed. So subsequent patches which alter table or partitioning properties can happily do so. It would have an effect on the compression (effectivity), but that's all. Indeed, I think HCC should be seen as 'yet another way to compress'. frits On May 7, 2014, at 4:46 PM, John Piwowar wrote: I think the sticking point is here: > So if you've got partitions with data that will not change anymore (HCC > compression doens't like changes), there is no reason not to compress it. It's not unusual for an EBS patch to alter the data or structure of a table or its dependent indexes. This is true even for some of the Very Important Tables in AR, Order Entry, etc., and particularly true during upgrades. So, just as you would need to be careful when implementing a custom partitioning scheme (supported, but with similar caveats), you might run into maintenance issues for tables to which HCC is applied. The ATG team has done extensive testing with the Advanced Compression (compress for OLTP, formerly "for all operations") feature, and has published a white paper on which objects were good targets for compression in both a test instance and Oracle's production GSI. Obviously Advanced Compression doesn't "squeeze the air out" as effectively as HCC, but it's an option. Here's a link to the Advanced Compression discussion, with ref to the whitepaper. It's from 2010, but some of the references are more up-to-date: https://blogs.oracle.com/stevenChan/entry/new_whitepaper_advanced_compression_11gr1_benchmar On Wed, May 7, 2014 at 6:01 AM, Frits Hoogland <frits.hoogland@xxxxxxxxx> wrote: Hi George. I am by no means an EBS specialist. I am aware a lot of database stuff needs to be done in an 'EBS way'. However. Essentially EBS is a client of the database (only oracle itself made it, instead of a 3rd party) HCC is a compression technique which requires no client SQL change to be used. So if you've got partitions with data that will not change anymore (HCC compression doens't like changes), there is no reason not to compress it. Said that, you should be aware of anything that will break when doing the mandatory recreation via direct path. (alter table move for example) Frits Hoogland http://fritshoogland.wordpress.com <http://fritshoogland.wordpress.com/> frits.hoogland@xxxxxxxxx Phone: +31 20 8946342 <tel:%2B31%2020%208946342> Mobile: +31 6 14180860 <tel:%2B31%206%2014180860> On 07 May 2014, at 07:41, George Leonard - Business Connexion <George.Leonard@xxxxxxxxx> wrote: <RSImage.jpeg> Hi all Ok, was a bit taken aback yesterday when an engineered informed me that HCC is not supported on EBS (12.1.3). I can't imagine that a Exa feature is not supported by now, nearly 6 years after V1. Is this really so, the client have data spanning 15+ years in their line items tables, we want to partition the table and HCC compress OLLDDDD data. It was a big part of the business case. Luckily the SSC will be a consolidation platform sot he value of HCC is still valid for the DW and other systems. But really, Oracle not supporting HCC on EBS on Engineered systems... Thats like something I would expect from SAP. Please help - URGENT. (If you have a note number that tells otherwise, and specifies how to partition EBS would appreciate it) (ME <> EBS expert). Yours Sincerely ________________________________________ George Leonard Oracle Engineered System Specialist Mobile: +27.82 655 2466 <tel:%2B27.82%20655%202466> eMail: george.leonard@xxxxxxxxx <mailto:george.leonard@xxxxxxxxxx> Web: <mailto:george.leonard@xxxxxxxxxx> http://www.bcx.com <image003.gif>