- Online encrypting an unencrypted tablespace to TDE
- Restarting encrypting a tablespace within a database that crashed during the process
- Re-encrypted tablespaces with a stronger encryption key (AES128 --> AES256)
- What happens to a standby database when I use encryption and when I rekey.
Throughout this blog post I am will be using queries from my previous blog you can find here.
Environment
First my environment.
- Primary DB : ORCLCDB - DB 19.28
- Standby DB : ORCLSTBY - DB 19.28
- Both databases are using OMF to simplify naming files
- Encryption - Using Local wallet file
The parameters that affect encryption are using the default values.
Parmeter
Name Value Default?
------------------------------ -------------------- ----------
tablespace_encryption MANUAL_ENABLE TRUE
encrypt_new_tablespaces CLOUD_ONLY TRUE
Using these parameters, new tablespaces will not be encrypted unless the DDL explicitly mentions encrypting the tablespace.
NOTE: Since I am using 19c, the default encryption Algorithm used will be AES128. Set _tablespace_encryption_default_algorithm to 'AES256' to change the default.
Encrypting my tablespace
Above is the Encryption clause that you can add to "ALTER TABLESPACE" to manage encrypted tablespaces.
For this post, I will concentrate on ONLINE encryption.
New tablespace
I am going to create a new tablespace in my PDB and I want any new tablespaces to be encrypted.
- alter system set encrypt_new_tablespaces=always;
- Create tablespace encrypt_test;
Running my query against the database, I can see that it created a tablespace and by default that tablespace was created as AES128.
PDB Name Tablespace Name Enc. Enc. alg Master Key ID Key ID tablespace Encryt key (trunc)
---------- --------------- ----- ---------- ------------------------- ----------------------------------- ------------------------------
CDB$ROOT SYSAUX NO AZTq/iBVq0/Kv5Es4oNsgQI= 94EAFE2055AB4FCABF912CE2836C8102 603EC31649CDC3684FE68D3DB376F6
SYSTEM NO AZTq/iBVq0/Kv5Es4oNsgQI= 94EAFE2055AB4FCABF912CE2836C8102 603EC31649CDC3684FE68D3DB376F6
TEMP NO AZTq/iBVq0/Kv5Es4oNsgQI= 94EAFE2055AB4FCABF912CE2836C8102 603EC31649CDC3684FE68D3DB376F6
UNDOTBS1 NO AZTq/iBVq0/Kv5Es4oNsgQI= 94EAFE2055AB4FCABF912CE2836C8102 603EC31649CDC3684FE68D3DB376F6
USERS NO AQAAAAAAAAAAAAAAAAAAAAA= 00000000000000000000000000000000 000000000000000000000000000000
ENCRYPT_TEST YES AES128 AZTq/iBVq0/Kv5Es4oNsgQI= 94EAFE2055AB4FCABF912CE2836C8102 5635777F4E7A6ACA229FEA10369967
NOTE: I did not change the parameter in my standby database and the tablespace in my standby is also encrypted. The DDL sent to the standby from the primary ensured that the standby also encrypts the tablespace.
Existing tablespaces
Now I am going to take an existing tablespace and encrypt it online.
Prior to performing this operation (even though it is online), I am going to take a backup of the database.
To make this more realistic I am using a tablespace with 4 datafiles that are all around 10 GB per datafile.
Tablespace Name FILE_ID File Name Size
--------------- ---------- ------------------------------ ----------
ENCTEST 13 o1_mf_enctest_npz8393s_.dbf 14.454 GB
ENCTEST 14 o1_mf_enctest_npz8gvz0_.dbf 8.589 GB
ENCTEST 15 o1_mf_enctest_npz8oy0p_.dbf 10.831 GB
ENCTEST 16 o1_mf_enctest_npz8yr6p_.dbf 12.793 GB
I am going to encrypt this tablespace on the primary database.
SQL> alter tablespace ENCTEST ENCRYPTION ONLINE ENCRYPT;
My session will not come back until the tablespace is encrypted.
Observations
Alert log and encrypting standby database.
When looking at the alert log for the primary and the standby, I can see the changes occurring.
Primary Database Alert log
ORCLPDB1(3):alter tablespace ENCTEST ENCRYPTION ONLINE ENCRYPT
2026-01-20T10:44:14.923114-07:00
ORCLPDB1(3):About to encrypt tablespace ENCTEST (tsn 3/6)
2026-01-20T10:44:15.020101-07:00
ORCLPDB1(3):TDE converting datafile /home/db19c/oradata/ORCLCDB/ORCLCDB/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npz8393s_.dbf (13) to /home/db19c/oradata/ORCLCDB/ORCLCDB/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_%u_.dbf
2026-01-20T10:48:44.473301-07:00 --> Start Time for Encryption
ORCLPDB1(3):Blocks TDE converted for file /home/db19c/oradata/ORCLCDB/ORCLCDB/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzhqh0w_.dbf size 1894528
2026-01-20T10:48:44.564605-07:00
ORCLPDB1(3):TDE convert operation committed for file /home/db19c/oradata/ORCLCDB/ORCLCDB/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzhqh0w_.dbf
2026-01-20T10:48:46.584235-07:00
ORCLPDB1(3):About to zero out original file "/home/db19c/oradata/ORCLCDB/ORCLCDB/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npz8393s_.dbf"
2026-01-20T10:50:06.377754-07:00
ORCLPDB1(3):Successfully zero'ed out original file "/home/db19c/oradata/ORCLCDB/ORCLCDB/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npz8393s_.dbf"
2026-01-20T10:50:06.380150-07:00
ORCLPDB1(3):Successfully deleted original file "/home/db19c/oradata/ORCLCDB/ORCLCDB/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npz8393s_.dbf"
2026-01-20T10:50:06.388074-07:00
Standby Database Alert log
ORCLPDB1(3):TDE converting datafile /home/db19c/oradata/ORCLSTBY/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npz83b9x_.dbf (13) to /home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_%u_.dbf
2026-01-20T10:48:44.976604-07:00 ORCLPDB1(3):Blocks TDE converted for file /home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzhqj8h_.dbf size 1894528
2026-01-20T10:48:44.983884-07:00 --> Start Time for Encryption
ORCLPDB1(3):TDE convert operation committed for file /home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzhqj8h_.dbf
2026-01-20T10:48:46.994337-07:00
ORCLPDB1(3):About to zero out original file "/home/db19c/oradata/ORCLSTBY/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npz83b9x_.dbf"
2026-01-20T10:50:06.371051-07:00
ORCLPDB1(3):Successfully zero'ed out original file "/home/db19c/oradata/ORCLSTBY/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npz83b9x_.dbf"
2026-01-20T10:50:08.012125-07:00
ORCLPDB1(3):Successfully deleted original file "/home/db19c/oradata/ORCLSTBY/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npz83b9x_.dbf"
2026-01-20T10:50:08.088219-07:00
Notice that the conversion of the first datafile on the first node started at
2026-01-20T10:48:44.473301-07:00
And the standby database started converting the first datafile at
2026-01-20T10:48:44.976604-07:00
The difference is milliseconds due to latency.
Observation #1 - With a standby database, the standby database is also immediately encrypting through REDO, and it is encrypting at the same time as the primary.
This was the most interesting item I found when going through the alert log.
After creating a new encrypted copy of a datafile, the process "Zero'ed out" the old datafile prior to deletion.
This was something I had not thought of before.
When migrating to Encrypted datafiles, this ensures that the original datafile (unencrypted) is overwritten and cannot be "undeleted" and read.
ORCLPDB1(3):About to zero out original file "/home/db19c/oradata/ORCLSTBY/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npz83b9x_.dbf"
2026-01-20T10:50:06.371051-07:00
ORCLPDB1(3):Successfully zero'ed out original file "/home/db19c/oradata/ORCLSTBY/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npz83b9x_.dbf"
2026-01-20T10:50:08.012125-07:00
ORCLPDB1(3):Successfully deleted original file "/home/db19c/oradata/ORCLSTBY/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npz83b9x_.dbf"
2026-01-20T10:50:08.088219-07:00NOTE: This same process occurs when rekeying also.
26ai New feature : DB_RECOVERY_AUTO_REKEY
ON, which is the default for the standby, enables the standby to automatically perform an online tablespace rekey operation as part of the standby media recovery process. Be aware that this setting pauses media recovery. If the tablespace is large, then you could observe extended standby apply lag.OFF, which is the default for the primary, does not perform a tablespace rekey operation. This setting enables an extended standby database to avoid lag time during an online conversion, and is designed for large Oracle Data Guard tablespace deployments. This enables the standby recovery to only record the tablespace key information but not perform the rekey operation inline. In the V$ENCRYPTED_TABLESPACES dynamic view, after the STATUS column value for the corresponding tablespace becomes REKEYING or ENCRYPTING on the standby database, then you can use a standby SQL session to issue an ALTER TABLESPACE ENCRYPTION ONLINE FINISH REKEY|ENCRYPT command to perform the rekey in parallel of media recovery. Observation #2 - When encrypting/rekeying a tablespaces, the original datafiles are overwritten with zeros to ensure they no longer contain any usable data.
Backing up newly encrypted database
I am now going to perform a new Level 1 backup of the database, and look to see what is being backed up. Below is the output from Block changed tracking showing the blocks being backed up.
FILE# INCREMENTAL_LEVEL COMPLETION_TIME BLOCKS DATAFILE_BLOCKS PCT_CHANGED
---------- ----------------- ----------------- ---------- --------------- -----------
Level 0 backup of datafiles
13 1 01-20-26 10:30:00 1793783 1894528 94.68
14 1 01-20-26 10:27:31 1081471 1125744 96.07
15 1 01-20-26 10:28:43 1368079 1419632 96.37
16 1 01-20-26 10:29:32 1573511 1676800 93.84
Level 1 backup of datafiles prior to encryption
13 1 01-20-26 10:30:15 1 1894528 0
14 1 01-20-26 10:30:15 1 1125744 0
15 1 01-20-26 10:30:15 1 1419632 0
16 1 01-20-26 10:30:15 1 1676800 0
Level 1 backup of datafiles post encryption
13 1 01-20-26 11:12:14 1 1894528 0
14 1 01-20-26 11:12:16 1 1125744 0
15 1 01-20-26 11:12:15 1 1419632 0
16 1 01-20-26 11:12:14 1 1676800 0
What you can see is that as far as RMAN is concerned, since this database is idle, only the header block changed. RMAN did not backup the datafile blocks even though every block changed through the encryption process. Only the user contents of the blocks changed not the metadata about the block.
This is a critical observation.
- If you perform a weekly full/daily incremental backup, you will need a new Level 0 backup to ensure the datafiles are encrypted in your backup.
- If you utilize the 9i "incremental merge" process, your backup will not be encrypted. If you perform a "switch to copy", your datafiles will not be encrypted. After encrypting, you must restart this strategy with a new full backup.
NOTE: One of the features of the ZDLRA is that it is "encryption aware", and you will not need to perform a new Level 0 backup to ensure you restore encrypted datafiles.
Observation #3 - The database does not recognize the blocks as changed. The block header information, containing SCN information, and other metadata remains untouched.
Datafile/Tablespace information
Original Datafiles
Tablespace Name FILE_ID File Name Size
--------------- ---------- ------------------------------ ----------
ENCTEST 13 o1_mf_enctest_npz8393s_.dbf 14.454 GB
ENCTEST 14 o1_mf_enctest_npz8gvz0_.dbf 8.589 GB
ENCTEST 15 o1_mf_enctest_npz8oy0p_.dbf 10.831 GB
ENCTEST 16 o1_mf_enctest_npz8yr6p_.dbf 12.793 GB
New Datafiles
Tablespace Name FILE_ID File Name Size
--------------- ---------- ------------------------------ ----------
ENCTEST 13 o1_mf_enctest_npzhqh0w_.dbf 14.454 GB
ENCTEST 14 o1_mf_enctest_npzj2gdb_.dbf 8.589 GB
ENCTEST 15 o1_mf_enctest_npzj9f4k_.dbf 10.831 GB
ENCTEST 16 o1_mf_enctest_npzjl4dz_.dbf 12.793 GB
Tablespace encryption Status
PDB Name Tablespace Name Enc. Enc. alg Master Key ID Key ID tablespace Encryt key (trunc)
---------- --------------- ----- ---------- ------------------------- ----------------------------------- ------------------------------
ORCLPDB1 SYSAUX NO AawCP+ykIE/2v9kPpgqvHOk= AC023FECA4204FF6BFD90FA60AAF1CE9 0C836501DE2C28286F4DFF45EDB563
SYSTEM NO AawCP+ykIE/2v9kPpgqvHOk= AC023FECA4204FF6BFD90FA60AAF1CE9 0C836501DE2C28286F4DFF45EDB563
TEMP NO AawCP+ykIE/2v9kPpgqvHOk= AC023FECA4204FF6BFD90FA60AAF1CE9 0C836501DE2C28286F4DFF45EDB563
UNDOTBS1 NO AawCP+ykIE/2v9kPpgqvHOk= AC023FECA4204FF6BFD90FA60AAF1CE9 0C836501DE2C28286F4DFF45EDB563
USERS NO AQAAAAAAAAAAAAAAAAAAAAA= 00000000000000000000000000000000 000000000000000000000000000000
ENCTEST YES AES128 AawCP+ykIE/2v9kPpgqvHOk= AC023FECA4204FF6BFD90FA60AAF1CE9 604F0A3F91F73875D0BC9325FA87C3
Above, you can see that a newly encrypted datafile copy was created for each datafile member of the tablespace. The size, is exactly the same as the original datafile. You can also see that since I didn't specify a specific algorithm, the tablespace was encrypted as AES128 (the default).
Observation #4 - A new datafile copy is created for each member. You need to make sure that there is enough space for a second copy of largest datafile.
Re-encrypted tablespaces from AES128 to AES256
The next process I am going to go through is common as customers rekey existing tablespaces from AES128 to utilize the AES256 encryption algorithm.
In this example, I am not only going to re-encrypt the tablespaces, I am also going to crash the database in the middle of this process to see how to handle this possibility.
SQL> alter tablespace ENCTEST ENCRYPTION ONLINE USING 'AES256' rekey;
For this example, I monitored the alert log and watched it encrypt the datafiles, as soon as it finished encrypting the first datafile (File# 14), I performed a "Shutdown Abort" on the database.
Primary Alert log
ORCLPDB1(3):About to rekey tablespace ENCTEST (tsn 3/6)
2026-01-20T11:46:45.353069-07:00
ORCLPDB1(3):TDE converting datafile /home/db19c/oradata/ORCLCDB/ORCLCDB/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzhqh0w_.dbf (13) to /home/db19c/oradata/ ORCLCDB/ORCLCDB/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_%u_.dbf
2026-01-20T11:51:50.367605-07:00
ORCLPDB1(3):Blocks TDE converted for file /home/db19c/oradata/ORCLCDB/ORCLCDB/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzmdoc8_.dbf size 1894528
2026-01-20T11:51:50.415541-07:00
ORCLPDB1(3):TDE convert operation committed for file /home/db19c/oradata/ORCLCDB/ORCLCDB/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzmdoc8_.dbf
2026-01-20T11:51:52.481666-07:00
ORCLPDB1(3):About to zero out original file "/home/db19c/oradata/ORCLCDB/ORCLCDB/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzhqh0w_.dbf"
2026-01-20T11:52:25.125992-07:00
Shutting down ORACLE instance (abort) (OS id: 827465)
2026-01-20T11:52:25.158712-07:00
Shutdown is initiated by sqlplus@bgrenn-19-28 (TNS V1-V3).
License high water mark = 12
USER (ospid: 827465): terminating the instance
2026-01-20T11:52:26.213187-07:00
Instance terminated by USER, pid = 827465
2026-01-20T11:52:27.343819-07:00
Standby Alert log
ORCLPDB1(3):TDE converting datafile /home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzhqj8h_.dbf (13) to /home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_%u_.dbf
2026-01-20T11:51:51.143252-07:00
ORCLPDB1(3):Blocks TDE converted for file /home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzmdphy_.dbf size 1894528
2026-01-20T11:51:51.150126-07:00
ORCLPDB1(3):TDE convert operation committed for file /home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzmdphy_.dbf
2026-01-20T11:51:53.202013-07:00
ORCLPDB1(3):About to zero out original file "/home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzhqj8h_.dbf"
2026-01-20T18:52:25.254096+00:00
rfs (PID:823518): Possible network disconnect with primary database
2026-01-20T18:52:25.258563+00:00
rfs (PID:823518): while processing B-1209738101.T-1.S-412 BNUM:110516 BCNT:1
2026-01-20T18:52:25.259701+00:00
rfs (PID:823516): Possible network disconnect with primary database
rfs (PID:823518): Current process action IDLE, elapsed idle time 0
2026-01-20T18:52:25.266055+00:00
rfs (PID:823516): while processing B-1209738101.T-1.S-412 BNUM:0 BCNT:0
2026-01-20T18:52:25.267216+00:00
rfs (PID:823518): RFS client ASYNC ORL SINGLE (PID:823296)
2026-01-20T18:52:25.268790+00:00
rfs (PID:823516): Current process action IDLE, elapsed idle time 32
rfs (PID:823516): RFS client GAP MANAGER (PID:822694)
2026-01-20T11:53:04.841560-07:00
ORCLPDB1(3):Successfully zero'ed out original file "/home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzhqj8h_.dbf"
2026-01-20T11:53:06.478227-07:00
ORCLPDB1(3):Successfully deleted original file "/home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzhqj8h_.dbf"
2026-01-20T11:53:06.486711-07:00
ORCLPDB1(3):TDE converting datafile /home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzj2j4t_.dbf (14) to /home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_%u_.dbf
2026-01-20T11:54:47.101862-07:00
ORCLPDB1(3):Blocks TDE converted for file /home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzmrlhf_.dbf size 1125744
2026-01-20T11:54:47.108829-07:00
ORCLPDB1(3):TDE convert operation committed for file /home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzmrlhf_.dbf
2026-01-20T11:54:49.120370-07:00
ORCLPDB1(3):About to zero out original file "/home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzj2j4t_.dbf"
2026-01-20T11:55:28.313091-07:00
ORCLPDB1(3):Successfully zero'ed out original file "/home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzj2j4t_.dbf"
2026-01-20T11:55:37.980759-07:00
ORCLPDB1(3):Successfully deleted original file "/home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzj2j4t_.dbf"
2026-01-20T11:55:37.989404-07:00
ORCLPDB1(3):TDE converting datafile /home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_npzj9kff_.dbf (15) to /home/db19c/oradata/ORCLCDB/ORCLSTBY/3CE209FE44CDECAEE06394A5500AE99C/datafile/o1_mf_enctest_%u_.dbf
What is most interesting in the alert logs, is that the standby continued to rekey the datafiles for the tablespace. This occurred independently of the primary.
Observation #5 - The primary sends the ALTER DATABASE REKEY command in the redo, and the standby database performs the process independently. even once the primary crashed.
Startup Database after crash
After starting up the primary database I took a look at the encryption status of the tablespace in both the primary and standby.. In the primary it shows as "REKEYING", the standby successfully finished the operation and shows as normal AES256 encrypted
select ts#,
ENCRYPTIONALG,
ENCRYPTEDTS,
status,
con_id
from v$encrypted_tablespaces;
Primary Database (aborted)
TS# ENCRYPT ENC STATUS CON_ID
---------- ------- --- ---------- ----------
6 AES256 YES REKEYING 3
Standby Database (continued operation)
TS# ENCRYPT ENC STATUS CON_ID
---------- ------- --- ---------- ----------
6 AES256 YES NORMAL 3
Now I am going to look at the datafiles
-rw-r-----+ 1 oracle oracle 15519981568 Jan 20 11:52 o1_mf_enctest_npzhqh0w_.dbf
-rw-r-----+ 1 oracle oracle 9222103040 Jan 20 12:10 o1_mf_enctest_npzj2gdb_.dbf
-rw-r-----+ 1 oracle oracle 11629633536 Jan 20 12:10 o1_mf_enctest_npzj9f4k_.dbf
-rw-r-----+ 1 oracle oracle 13736353792 Jan 20 12:10 o1_mf_enctest_npzjl4dz_.dbf
-rw-r-----+ 1 oracle oracle 15519981568 Jan 20 12:10 o1_mf_enctest_npzmdoc8_.dbf
Since I aborted the database, while it was "zeroing out the datafile" there are two copies of the datafile.
At this point since it started the rekey operation, my only choice is to "FINISH" the operation. This is a manual step to restart the process.
alter tablespace ENCTEST ENCRYPTION FINISH rekey;
Observation #6 - Once you start an encryption operation, it must finish. There is no backing out.
Once the rekey operation finished, I again looked at the datafiles. I can see that the original datafile that was in process when I aborted the database is still there. If an online encryption operation is in process during a crash, you might have an orphan file from the process that has to be manually deleted.
-rw-r-----+ 1 oracle oracle 15519981568 Jan 20 11:52 o1_mf_enctest_npzhqh0w_.dbf
-rw-r-----+ 1 oracle oracle 15519981568 Jan 20 12:10 o1_mf_enctest_npzmdoc8_.dbf
-rw-r-----+ 1 oracle oracle 9222103040 Jan 20 12:27 o1_mf_enctest_npzopwfg_.dbf
-rw-r-----+ 1 oracle oracle 11629633536 Jan 20 12:30 o1_mf_enctest_npzovdhd_.dbf
-rw-r-----+ 1 oracle oracle 13736353792 Jan 20 12:34 o1_mf_enctest_npzp0zd5_.dbf
Observation #7 - After a crash, there may be cleanup necessary.
rm o1_mf_enctest_npzhqh0w_.dbf
