Since a MOVE (or a DROP or TRUNCATE) doesn't actually scrub the data; only marking the extents as "free". You would have to actually create one or more tables and populate them with dummy data in an attempt to overwrite those blocks --- you still cannot control which blocks your new table(s) do overwrite. OR drop the old tablespace and datafile -- then you have to create new OS or datafiles(s) in an attempt to overwrite the blocks (whether filesystem or raw) at the OS level ! On Mar 8, 2013 2:10 AM, "Kevin Lidh" <kevin.lidh@xxxxxxxxx> wrote: > I was researching TDE and set up a test in a small Oracle 11.2.0.3 database > on RHEL. I created a table with two rows of "sensitive" unencrypted > information. I opened up my datafile in a hex editor and found my data. I > then created an encrypted tablespace and "alter table move" the table to > the > new tablespace and when I open that datafile, I can't find my data. But > when I open the original datafile, I can still see sensitive information. > I > verified there were no extents remaining from that table. I understand how > it happened but I'm wondering if there's another way to either move the > data > out which clears it or if there's a way to clear it after the fact. I did > a > coalesce for fun and now my two sensitive pieces are right next to each > other in the unencrypted datafile. > > In our real world environment, the only method that comes to mind is to > move > all the remaining and unencrypted data to yet another tablespace and drop > the original but that wouldn't be practical for some of our databases. > > Any ideas are surely welcome. > > Kevin > > -- > //www.freelists.org/webpage/oracle-l > > > -- //www.freelists.org/webpage/oracle-l