Skip to Main Content
  • Questions

  • Compression and TDE and NNE using ODA

Breadcrumb

Question and Answer

Connor McDonald

Thanks for the question, fynix.

Asked: November 18, 2015 - 2:07 pm UTC

Last updated: November 23, 2015 - 1:05 pm UTC

Version: 11.2.0.4

Viewed 1000+ times

You Asked

We just purchased a brand spanking new ODA X-5 with stupendous amount of storage 128TB raw storage or 42TB triple mirrored. For our environment the storage is a godsend, we have been running really tight on storage so our backups are tape only. I am looking to implement some key oracle features such as TDE,NNE (native network encryption) and advanced compression for OLTP. Even though we have more than enough storage for now I am looking into the future and want to ensure we don't run out of space for the next few years. I would like to implement the compression at the tablespace level rather than individual tables, so everything is automatically compressed without any extra work from users. Are there any downsides to implementing compresssion at the tablespace level? Most of the instructions I see online mention table compression but not tablespace. Also, can all three features be used together? We will be running a production RAC with 12CPUs per node and two smaller RAC databases that will see very little usage (just me and two or so developers). We have about 5000 users overall but the major users will be data entry and applications that pull in data from external sources (lets say about 150-300 users). What pitfalls should I be looking out for? I have read there will be CPU overhead but I think these new gen Intel chips (Intel(R) Xeon(R) CPU E5-2699 v3) can handle the workload. Our current hardware is a three node 8CPU (Intel(R) Xeon(R) CPU E7220 @ 2.93GHz) per node RAC with about 4 databases (PROD and some other smaller DBs) and average CPU load is about 50-65% and we do not have TDE,NNE or compression enabled.

and Connor said...

I'm obviously not going to try dissuade you from purchasing an advanced compression license, and an advanced security license in addition to database licenses :-)

For me, I'd probably not set compression at tablespace levely, only because I like the granular control at the table level. For example, whilst there's probably negligible overhead for compression (say) a small reference table thats primarily read-only, I also question the need to do so. After all, such tables typically have very few duplicate keys. (Of course, you could adopt a tablespace policy that separate such tables out.

I'm a fan of TDE at the tablespace level, because you're paying the encyrption/decryption penalty less often (because once that data is in the buffer cache, its pretty much as per normal). TDE at the column level means more challenges in terms of data sizes and indexing considerations.

A good read here on the topic: http://www.oracle.com/technetwork/database/security/twp-transparent-data-encryption-bes-130696.pdf

I cant really comment on network encyrption (in terms of the CPU performance cost) - but there's nothing to stop you benchmarking that on existing hardware to see what the delta is.

Hope this helps.

Rating

  (3 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

fynix, November 19, 2015 - 1:17 pm UTC

I am confused when you say paying for extra licensing, I thought compression was included at no extra cost and advanced security is now free with the Enterprise database license.
Connor McDonald
November 19, 2015 - 10:54 pm UTC

You want to have a careful read of:

http://www.oracle.com/us/corporate/pricing/databaselicensing-070584.pdf
http://www.oracle.com/us/corporate/pricing/sig-070616.pdf
http://www.oracle.com/us/corporate/pricing/technology-price-list-070617.pdf

and probably have a chat to your local Oracle office.

*Some* elements of security and compression are included in an EE license. But not all.

fynix, November 19, 2015 - 1:20 pm UTC

My reasoning for compression is that it is supposed to reduce storage requirements by at least 2x and also speed up OLTP since more data can be fit in each block and the data does not need to be decompressed in memory.
Connor McDonald
November 20, 2015 - 1:21 am UTC

I didnt say *dont* use compression. I said perhaps a *blanket* use of compression might be overkill.

fynix, November 23, 2015 - 12:49 pm UTC

Yeah, you are right blanket compression is probably not a good idea but I was thinking since the machine is pretty powerful and it would require little input from users, since I do not really have control over the application. The licensing issue kind of puts a damper on things though but apparently we do have the advanced encryption license. The compression issue I have to figure out somehow because unfortunately the way Oracle configures its ODA only allows for 43% 57% or 86% 14% split of the available storage and neither falls within my exact storage requirements.
Connor McDonald
November 23, 2015 - 1:05 pm UTC

One thing I strongly encourage for anyone getting new gear ... is dedicate some time *before* a manager demands it gets commissioned, to test it in all sorts of interesting ways. Not just compression, but failover, stress test etc etc etc....

Once the thing is in live usage, you'll wish you had done more :-)
more

Connor and Chris don't just spend all day on AskTOM. You can also catch regular content via Connor's blog and Chris's blog. Or if video is more your thing, check out Connor's channel and Chris's channel from their Youtube channels. And of course, keep up to date with AskTOM via the official twitter account.