Thank you Mladen. I checked the historical size of tablespaces(from
dba_hist_tbspc_space_usage) and summed them up for this DEV database. And
it comes as prior to TSE the database size was ~633GB and post TSE it's now
~636GB, so it's showing some increase but not showing a 2-3 times kind of
increase at least.
But one thing I wanted to check , as this encryption technique is widely
used one, is such degradation in performance expected (as because it's
degrading from 50% to 100% for some queries)?
OR
Are we testing/validating performance here in the wrong way?
Regards
Lok
On Mon, Jun 28, 2021 at 9:33 AM Mladen Gogala <gogala.mladen@xxxxxxxxx>
wrote:
IO has changed because encrypted data is much larger than the original.
Encrypted data can be 4 times or more larger than the original. That is
what happens when you apply ciphers like RSA RC4. There are many
decryption techniques that are being stymied by this: pattern
recognition, same character repeat and many others. Since the keys are
enormous, you would need 100 years or so to break them. Public key
encryption is based on huge numbers that need to be factored into their
prime components. The most efficient factorization algorithm is the
Sieve of Erathosten, named after mathematician form the ancient Greece.
So, unless some mathematical wunderkind comes up with something much
faster, your data is safe and secure. That hasn't happened for the last
2500 years or so. The price you pay is much enlarged data size and a lot
of CPU cycles to decrypt stuff. Personally, I use ROT13 and, to be safe,
I encrypt everything - twice.
On 6/27/21 10:18 PM, Lok P wrote:
No other change happened. It was only tablespace encryption which has--
been done on top of existing data.
I am also struggling to understand why the increase in IO is noted in
SQL monitor.
Mladen Gogala
Database Consultant
Tel: (347) 321-1217
https://dbwhisperer.wordpress.com
--
//www.freelists.org/webpage/oracle-l
