Thanks for the question, Vicky .
Asked: June 13, 2023 - 7:25 pm UTC
Last updated: July 03, 2023 - 2:27 am UTC
Version: 19c
Viewed 1000+ times
You Asked
Hallo Everyone!
I am a student and currently writing a Project on Transparent Data Encryption in collaboration with a company which deployed some On-Premises Oracle Databases. I have read about how the logical structures in oracle are, how each block has a Data Block Overhead to store information about the Block and how row pieces in a data block have their header too to store information about the row piece itself. My question is:
When I encrypt a tablespace with Transparent Data Encryption, which part of the data block exactly gets encrypted? Are the header information also encrypted or it is only the column data parts of every row pieces of every data blocks relevant to that specific tablespace that gets encrypted?
If I assume that every part of a data block is encrypted, would not it be a problem to locate and manage data blocks? Or if at all, the whole data block gets encrypted, then my question would be: Should not the whole tablespace be read and cached to buffer to manage and access data blocks?
Greetings
Vicky
and Connor said...
TDE encrypts the data at rest, not when its in database memory, so the concern with metadata in the block (header or otherwise) is not an issue.
(Theoretical example here).
I need to scan a table and find a row where SURNAME = 'SMITH'. That (loosely) consists of (assuming nothing already in memory)
- read locally managed tablespace bitmap to find segment header block location for table
- read segment header block and extract extent info from it
- read batch of blocks from 1st extent
- for each block, read block header, find row locations in the block
- go through row, scan along until "SURNAME" column found, look for SMITH
In a TDE scenario, pretty much nothing changes ... except some decryption along the way ("extra" steps with an "*")
- read locally managed tablespace bitmap to find segment header block location for table
* - issue read request to segment header block. Get from disk, decrypt it, load into memory
- read segment header block and extract extent info from it
- read batch of blocks from 1st extent
* - decrypt each block as read from disk
- for each block, read block header, find row locations in the block
- go through row, scan along until "SURNAME" column found, look for SMITH
Thus by the time the "heavy lifting" (of getting the data from disk into memory) is done...the block is now decrypted and is utilised as per normal.
Hope that helps
Rating
(1 rating)
We're not taking comments currently, so please try again later if you want to add a comment.