Table of Contents
On the second night of our TDE implementation project on Oracle 19c, what we thought would take less than 12 hours stretched to almost 30. Even worse, we had a partial service outage.
If you want to avoid the same headaches and enjoy a story with plenty of twists and an unexpected ending, keep reading. You won’t regret it.
The Calm Before the Storm
You know how it goes: you run ALTER TABLESPACE … ENCRYPTION ONLINE ENCRYPT, and the magic begins. Oracle picks up a datafile and starts encrypting it; once it’s done, it moves on to the next one, and so on until they’re all done. At the same time, the redo stream sends the instruction to the physical standby, which follows the same steps as the primary.
The result is that both the primary and standby are encrypted, and there’s no service interruption.
The week before, I had already completed two databases, and now there were three more left. We started at 5 pm, expecting to finish by 6 am. My last check at 1 am showed everything was fine—until it suddenly wasn’t.
Houston, We Have a Problem
At 2:30 am, I checked again. The primary databases were still encrypting without issues, but the physical standbys were not. The alert.log files were showing write errors.
alert_db1s_1.log
2026-09-15T02:14:59.664807-05:00
TDE converting datafile +DAT02/DB1S/datafile/t_sales.361.1182719849 (133) to +DAT02
2026-09-15T02:19:25.321055-05:00
Blocks TDE converted for file +DAT02/DB1S/DATAFILE/t_sales.357.1243995299 size 4193280
2026-09-15T02:19:25.325023-05:00
TDE convert operation committed for file +DAT02/DB1S/DATAFILE/t_sales.357.1243995299
2026-09-15T02:19:27.338984-05:00
About to zero out original file "+DAT02/DB1S/datafile/t_sales.361.1182719849"
2026-09-15T02:20:08.592404-05:00
Successfully zero'ed out original file "+DAT02/DB1S/datafile/t_sales.361.1182719849"
2026-09-15T02:20:08.917999-05:00
Successfully deleted original file "+DAT02/DB1S/datafile/t_sales.361.1182719849"
2026-09-15T02:20:08.928661-05:00
TDE converting datafile +DAT02/DB1S/datafile/t_sales.366.1182720275 (138) to +DAT02
2026-09-15T02:22:08.662060-05:00
WARNING: Write Failed. group:3 disk:7 AU:564818 offset:0 size:8192
path:/dev/oracleasm/emc_dc2_leg_dat02_002
incarnation:0x54be4f4f synchronous result:'I/O error' ioreason:16147 why:63
subsys:System krq:0x7f1d9adf4460 bufp:0x7f1d9aa85000 osderr1:0x69b5 osderr2:0x0
IO elapsed time: 0 usec Time waited on I/O: 0 usec
2026-09-15T02:22:08.663540-05:00
Errors in file /u01/app/oracle/diag/rdbms/db1s/db1s_1/trace/db1s_1_pr00_153839.trc:
ORA-15080: synchronous I/O operation failed to write block 1767808 of disk 7 in disk group DAT02
ORA-27061: waiting for async I/Os failed
Linux-x86_64 Error: 5: Input/output error
Additional information: 4294967295
Additional information: 8192
WARNING: failed to write mirror side 1 of virtual extent 13811 logical extent 0 of file 361 in group 3 on disk 7 allocation unit 564818
WARNING: group 3 file 361 block 1767681 write failed, OSD error 27061.
WARNING: Write Failed. group:3 disk:7 AU:22 offset:32768 size:16384
path:/dev/oracleasm/emc_dc2_leg_dat02_002
incarnation:0x54be4f4f asynchronous result:'I/O error' ioreason:2067 why:8
subsys:System krq:0x7f1d9a198520 bufp:0x7f1d9adcc000 osderr1:0x69b5 osderr2:0x0
IO elapsed time: 0 usec Time waited on I/O: 0 usec
2026-09-15T02:22:08.668618-05:00
Errors in file /u01/app/oracle/diag/rdbms/db1s/db1s_1/trace/db1s_1_pr00_153839.trc:
ORA-15080: synchronous I/O operation failed to write block 42 of disk 7 in disk group DAT02
ORA-27061: waiting for async I/Os failed
Linux-x86_64 Error: 5: Input/output error
Additional information: 4294967295
Additional information: 16384
ORA-01114: IO error writing block to file +DAT02/DB1S/DATAFILE/t_sales.361.1243995609 (block # 1767681)
ORA-15081: failed to submit an I/O operation to a disk
WARNING: failed to write mirror side 1 of virtual extent 5 logical extent 0 of file 257 in group 3 on disk 7 allocation unit 22
WARNING: group 3 file 257 block 42 write failed, OSD error 27061.
2026-09-15T02:22:08.669719-05:00
Errors in file /u01/app/oracle/diag/rdbms/db1s/db1s_1/trace/db1s_1_pr00_153839.trc:
ORA-00206: error in writing (block 42, # blocks 1) of control file
ORA-00202: control file: '+DAT02/DB1S/controlfile/current.257.1182711551'
ORA-15081: failed to submit an I/O operation to a disk
ORA-15081: failed to submit an I/O operation to a disk
ORA-01114: IO error writing block to file +DAT02/DB1S/DATAFILE/t_sales.361.1243995609 (block # 1767681)
ORA-15081: failed to submit an I/O operation to a disk
Clean up of TDE convert operation for fno 138 aborted
PR00 (PID:153839): MRP0: Background Media Recovery terminated with error 221
2026-09-15T02:22:08.670612-05:00
Errors in file /u01/app/oracle/diag/rdbms/db1s/db1s_1/trace/db1s_1_pr00_153839.trc:
ORA-00221: error on write to control file
ORA-00206: error in writing (block 42, # blocks 1) of control file
ORA-00202: control file: '+DAT02/DB1S/controlfile/current.257.1182711551'
ORA-15081: failed to submit an I/O operation to a disk
ORA-15081: failed to submit an I/O operation to a disk
ORA-01114: IO error writing block to file +DAT02/DB1S/DATAFILE/t_sales.361.1243995609 (block # 1767681)
ORA-15081: failed to submit an I/O operation to a disk
2026-09-15T02:22:08.672648-05:00
.... (PID:16928): Managed Standby Recovery not using Real Time Apply
2026-09-15T02:22:08.677045-05:00
NOTE: Suppressing further IO Write errors on group:3 disk:7
WARNING: Write Failed. group:3 disk:7 AU:22 offset:32768 size:16384
path:/dev/oracleasm/emc_dc2_leg_dat02_002
incarnation:0x54be4f4f asynchronous result:'I/O error' ioreason:2067 why:8
subsys:System krq:0x7f1d9a198520 bufp:0x7f1d9adcc000 osderr1:0x69b5 osderr2:0x0
IO elapsed time: 0 usec Time waited on I/O: 0 usec
2026-09-15T02:22:08.679009-05:00
Errors in file /u01/app/oracle/diag/rdbms/db1s/db1s_1/trace/db1s_1_pr00_153839.trc:
ORA-15080: synchronous I/O operation failed to write block 42 of disk 7 in disk group DAT02
ORA-27061: waiting for async I/Os failed
Linux-x86_64 Error: 5: Input/output error
Additional information: 4294967295
Additional information: 16384
ORA-00221: error on write to control file
ORA-00206: error in writing (block 42, # blocks 1) of control file
ORA-00202: control file: '+DAT02/DB1S/controlfile/current.257.1182711551'
ORA-15081: failed to submit an I/O operation to a disk
That’s not all. One of them also reported that its associated disk group, DAT06, had been dismounted.
alert_db3s_2.log
Errors in file /u01/app/oracle/diag/rdbms/db3s/db3s_2/trace/db3s_2_clmn_17937.trc:
ORA-00221: error on write to control file
ORA-00206: error in writing (block 2175, # blocks 1) of control file
ORA-00202: control file: '+DAT06/DB3S/controlfile/current.292.1182826595'
ORA-15081: failed to submit an I/O operation to a disk
ORA-15081: failed to submit an I/O operation to a disk
2026-09-15T02:25:17.905775-05:00
Starting background process AMB1
2026-09-15T02:25:17.937752-05:00
AMB1 started with pid=109, OS id=173010
2026-09-15T02:25:18.368064-05:00
NOTE: AMB1 (index:1) registering with ASM instance as Flex client 0xffffffffffffffff (reg:4264647947) (startid:1230983097) (new connection)
NOTE: AMB1 (index:1) (173010) connected to ASM instance +ASM1, osid: 196330 (Flex mode; client id 0xeca2896b4ccb4159)
NOTE: AMB1 (173010) rebuilding ASM server state for all pending groups
NOTE: AMB1 (173010) rebuilding ASM server state for group 6 (DAT06)
NOTE: AMB1 (173010) rebuilt 1 (of 1) groups
WARNING: AMB1 (173010) did not rebuild some files (284 allocated)
ERROR: AMB1 (173010) failed to rebuild ASM server state for disk group 6
2026-09-15T02:25:18.578959-05:00
Errors in file /u01/app/oracle/diag/rdbms/db3s/db3s_2/trace/db3s_2_amb1_173010.trc:
ORA-15064: communication failure with ASM instance
ORA-15130: diskgroup "DAT06" is being dismounted
2026-09-15T02:25:18.580611-05:00
Errors in file /u01/app/oracle/diag/rdbms/db3s/db3s_2/trace/db3s_2_amb1_173010.trc:
ORA-15064: communication failure with ASM instance
ORA-15130: diskgroup "DAT06" is being dismounted
2026-09-15T02:25:19.897261-05:00
Some recovered datafiles maybe left media fuzzy
Media recovery may continue but open resetlogs may fail
WARNING: Write Failed. group:6 disk:6 AU:3651 offset:245760 size:16384
path:/dev/oracleasm/emc_dc2_leg_dat06_001
incarnation:0x54be389c asynchronous result:'I/O error' ioreason:2067 why:8
subsys:System krq:0x7f0103026c70 bufp:0x7f00fdd02000 osderr1:0x69b5 osderr2:0x0
IO elapsed time: 0 usec Time waited on I/O: 0 usec
2026-09-15T02:25:19.946476-05:00
Errors in file /u01/app/oracle/diag/rdbms/db3s/db3s_2/trace/db3s_2_cl01_21236.trc:
ORA-15080: synchronous I/O operation failed to write block 2175 of disk 6 in disk group DAT06
ORA-27061: waiting for async I/Os failed
Linux-x86_64 Error: 5: Input/output error
Additional information: 4294967295
Additional information: 16384
WARNING: failed to write mirror side 1 of virtual extent 39 logical extent 0 of file 292 in group 6 on disk 6 allocation unit 3651
WARNING: group 6 file 292 block 2175 write failed, OSD error 27061.
2026-09-15T02:25:19.956442-05:00We confirm this in the ASM alert.log.
alert_+ASM2.log
2026-09-15T01:57:45.151655-05:00
NOTE: cleaning up empty system-created directory '+CRS/acmedc2/OCRBACKUP/backup01.ocr.264.1243965457'
NOTE: cleaning up empty system-created directory '+CRS/acmedc2/OCRBACKUP/backup00.ocr.268.1243979861'
NOTE: cleaning up empty system-created directory '+CRS/acmedc2/OCRBACKUP/13126281.259.1243994263'
2026-09-15T02:25:13.998358-05:00
ASM Health Checker found 1 new failures
2026-09-15T02:25:15.819799-05:00
WARNING: Write Failed. group:6 disk:6 AU:1 offset:1044480 size:4096
path:/dev/oracleasm/emc_dc2_leg_dat06_001
incarnation:0x67dadfbb asynchronous result:'I/O error' ioreason:13825 why:54
subsys:System krq:0x7fbd5f050008 bufp:0x7fbd5f00b000 osderr1:0x69b5 osderr2:0x0
IO elapsed time: 0 usec Time waited on I/O: 0 usec
WARNING: Hbeat write to PST disk 6.1742397371 in group 6 failed. [2]
2026-09-15T02:25:15.857043-05:00
NOTE: initiating PST update: grp 6 (DAT06), dsk = 6/0x67dadfbb, mask = 0x6a, op = clear mandatory
2026-09-15T02:25:15.857722-05:00
GMON updating disk modes for group 6 at 3398 for pid 34, osid 172985
2026-09-15T02:25:15.858251-05:00
ERROR: no read quorum in group: required 1, found 0 disks
2026-09-15T02:25:15.887990-05:00
ERROR: no read quorum in group: required 1, found 0 disks
2026-09-15T02:25:15.888171-05:00
ERROR: Could not read PST for grp 6. Force dismounting the disk group.
2026-09-15T02:25:15.888358-05:00
NOTE: cache dismounting (not clean) group 6/0x408A2FB3 (DAT06)
2026-09-15T02:25:15.890419-05:00
NOTE: messaging CKPT to quiesce pins Unix process pid: 172987, image: oracle@DBSRV1.acme.com (B001)
2026-09-15T02:25:15.894545-05:00
NOTE: halting all I/Os to diskgroup 6 (DAT06)
2026-09-15T02:25:15.900472-05:00
NOTE: LGWR doing non-clean dismount of group 6 (DAT06) thread 1
NOTE: LGWR sync ABA=175.8843 last written ABA 175.8843
2026-09-15T02:25:15.902495-05:00
NOTE: initiating dirty detach from lock domain 6
2026-09-15T02:25:15.905928-05:00
WARNING: Offline of disk 6 (DAT06_001) in group 6 and mode 0x7f failed on ASM inst 2
2026-09-15T02:25:15.906636-05:00
Errors in file /u01/app/oracle/diag/asm/+asm/+ASM2/trace/+ASM2_b000_172985.trc:
ORA-15040: diskgroup is incomplete
2026-09-15T02:25:15.920302-05:00
kjbdomdet send to inst 1
detach from dom 6, sending detach message to inst 1A search for OSD error 27061 suggests we might be out of disk space — which seems odd, because ASMCMD still shows plenty of free capacity; however, it does confirm that disk group DAT06 is no longer available.
$ asmcmd lsdg
State Type Block AU Total_MB Free_MB Usable_file_MB Name
MOUNTED NORMAL 4096 4194304 6120 5052 1506 CRS/
MOUNTED EXTERN 4096 1048576 23068584 1300960 1300960 DAT01/
MOUNTED EXTERN 4096 1048576 7339976 1231677 1231677 DAT02/ << << <<
MOUNTED EXTERN 4096 1048576 6291408 1236900 1236900 DAT03/ << << <<
MOUNTED EXTERN 4096 1048576 25165728 3969930 3969930 DAT04/
MOUNTED EXTERN 4096 1048576 2040 9 9 DATW/
MOUNTED EXTERN 4096 1048576 8388544 6822595 6822595 FRA01/
At this point, it’s clear I’m not dealing with an Oracle Server or Oracle TDE issue — this goes deeper, into another layer — and with nothing left for me to do on my end, I have no choice but to loop in the project lead, who in turn brings in the storage specialist.
After a tense few minutes of waiting, the specialist confirms our initial suspicion: the storage array is completely out of free space — not a single byte left!
Space: The Final Frontier?
Every modern storage array includes data reduction capabilities, usually through some combination of compression, deduplication, and thin provisioning — and that was exactly our situation: the 18 TiB that Oracle reports as logically consumed by these three databases were, in reality, only taking up around 5 TiB of physical space.
Now, though, encrypting the datafiles essentially kills any chance of compression or deduplication. The result: physical space usage kept climbing until there was nothing left and every attempt to write new data failed outright.
Fortunately, the primary databases were already encrypted, so the main services kept running —but because of the space shortage, the physical standbys became unusable, and some tasks got interrupted along the way: backups, queries, and reports. Nothing fatal, but restoring full service ASAP was critical.
I Decrypt, Therefore I Am
Since there’s no space, and getting more could take a long time, the simplest and fastest fix is to rebuild the physical standbys without encryption. So I searched My Oracle Support for unencrypted standby, and it surfaced this document:
| KB874637 | Steps to Create a Standby Database Unencrypted from an Primary database Having Encrypted Tablespace |
It states that, as a first step, you should take an RMAN backup and then restore it using AS DECRYPTED. It also notes that you need to be careful to set the tablespace_encryption=DECRYPT_ONLY parameter.
Getting that backup would take more time and space, and since we’re short on both, I decided to try it straight from the primary using DUPLICATE instead.
I spin up my test environment (VMs on VirtualBox), cross my fingers, and run this from RMAN:
RMAN>
run {
DUPLICATE TARGET DATABASE
FOR STANDBY
FROM ACTIVE DATABASE
DORECOVER
AS DECRYPTED
NOFILENAMECHECK;
}A few minutes later, the duplication finishes. I had my physical standby, and much to my relief, I confirmed its datafiles aren’t encrypted.
SQL>
SELECT ts.name as tablespace_name,
et.encryptedts,
et.encryptionalg
FROM v$tablespace ts,
v$encrypted_tablespaces et
WHERE ts.ts# = et.ts# (+)
ORDER BY 2 NULLS LAST, 1;
TABLESPACE_NAME ENCRYPTED ENCRYPTIONALG
------------------------------ --------- ---------------------
ENCRYPTED_TBS1
ENCRYPTED_TBS2
ENCRYPTED_TBS3
SYSAUX
SYSTEM
TEMP
UNDOTBS1
USERS$
dbv file= '+DATA/ORCL2/DATAFILE/encrypted_tbs1.404.1244574577' USERID=sys/Oracle1
DBVERIFY: Release 19.0.0.0.0 - Production on Tue Sep 15 05:00:01 2026
Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.
DBVERIFY - Verification starting : FILE = +DATA/ORCL2/DATAFILE/encrypted_tbs1.404.1244574577
DBVERIFY - Verification complete
Total Pages Examined : 12800
Total Pages Processed (Data) : 35
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 43
Total Pages Failing (Index): 0
Total Pages Processed (Other): 12685
Total Pages Processed (Seg) : 0
Total Pages Failing (Seg) : 0
Total Pages Empty : 37
Total Pages Marked Corrupt : 0
Total Pages Influx : 0
Total Pages Encrypted : 0 << << << << << << <<
Highest block SCN : 815547 (0.815547)Encouraged by these results, we mounted the failed disk group and deleted all the files for the three affected databases.
$ . grid.env
Oracle Home: /u01/app/grid/19.0.0/grid_1
Oracle SID: +ASM2
asmcmd mount +dat06
asmcmd rm -rf +dat02/db1s
asmcmd rm -rf +dat03/db2s
asmcmd rm -rf +dat06/db3sI tried duplicating one of the databases as a test, but after 10 minutes, nothing seemed to be happening.
..
.
using target database control file instead of recovery catalog
allocated channel: tgt1
channel tgt1: SID=1309 instance=db1s_1 device type=DISK
allocated channel: tgt2
channel tgt2: SID=523 instance=db1s_2 device type=DISK
allocated channel: aux1
channel aux1: SID=253 device type=DISK
allocated channel: aux2
channel aux2: SID=376 device type=DISK
Starting Duplicate Db at 2026-09-15 07:23:19
current log archivedWhen I checked V$SESSION, I saw waits on the control file sequential read event. This reminded me of a similar case I had written about before in another article. So I ran the same query to check:
SQL>
SELECT type, records_total, records_used
FROM v$controlfile_record_section
WHERE type='ARCHIVED LOG';
TYPE RECORDS_TOTAL RECORDS_USED
-------------------- ------------- ------------
ARCHIVED LOG 116508 81426Sure enough, it was the same issue. An unusually high number of rows (81,426) in the archived redo log history caused RMAN to spend a lot of time processing the control file during duplication. We quickly aborted the cloning and applied the workaround right away:
SQL>
exec dbms_backup_restore.resetcFileSection(11);
RMAN>
catalog start with '+FRA01/db3s/archivelog';I started the DUPLICATE again, and this time it does move — for a couple of minutes, anyway — because it then dies again, and, much to our surprise, it’s a space issue all over again!
..
.
channel aux2: starting datafile backup set restore
channel aux2: specifying datafile(s) to restore from backup set
channel aux2: restoring datafile 00006 to +DAT06
channel aux1: restore complete, elapsed time: 00:00:16
channel aux1: starting datafile backup set restore
channel aux1: specifying datafile(s) to restore from backup set
channel aux1: restoring datafile 00007 to +DAT06
dbms_backup_restore.restoreCancel() failed
released channel: tgt1
released channel: tgt2
released channel: aux1
released channel: aux2
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 09/15/2026 07:58:16
RMAN-05501: aborting duplication of target database
RMAN-03015: error occurred in stored script Memory Script
ORA-19660: some files in the backup set could not be verified
ORA-19661: datafile 7 could not be verified due to corrupt blocks
ORA-19849: error while reading backup piece
ORA-19502: write error on file "+DAT06/DB3S/DATAFILE/tbs_sales.489.1244015893", block number 168320 (block size=8192)
ORA-15081: failed to submit an I/O operation to a disk
ORA-15081: failed to submit an I/O operation to a disk
RMAN>
Recovery Manager complete.Out of Sight, Not Out of Mind
The storage specialist confirms that the LUNs assigned to the three disk groups still show the original consumption; in other words, the storage array has no idea that space has been freed up at the ASM level, so when RMAN tries to write the datafiles, the storage array is told to provide more space — space that’s already gone.
Turns out the LUNs assigned to ASM were set up with thin provisioning, and after digging through the Oracle 19c documentation, we find that the only way for space freed via ASMCMD to actually register back at the storage layer is for the disk group to have the thin_provisioned=TRUE attribute set. It also notes this only works if you’re using ASM Filter Driver (ASMFD) — which isn’t our case, since we’re running the good old reliable multipath + udev combo.
So what now? Should we start experimenting, bring down the entire clusterware stack, and configure ASMFD on the fly? No, we’re bold but not reckless. It’s better to play it safe and keep the damage contained, so we chose to free up the space the brute-force way, directly from the OS (RHEL 7).
#
blkdiscard -v /dev/mapper/emc_dc2_leg_dat02_001p1
blkdiscard -v /dev/mapper/emc_dc2_leg_dat02_002p1
..
.
blkdiscard -v /dev/mapper/emc_dc2_leg_dat03_001p1
blkdiscard -v /dev/mapper/emc_dc2_leg_dat03_002p1
..
.
blkdiscard -v /dev/mapper/emc_dc2_leg_dat06_001p1
blkdiscard -v /dev/mapper/emc_dc2_leg_dat06_002p1
..
.
blkdiscard -v /dev/mapper/emc_dc2_leg_dat06_008p1We thought it would be quick, but it actually took a little over two hours to process all 21 disks, each 1 TiB in size.
The wait was worth it. The storage specialist confirmed the disks were now showing 0% usage, so we quickly started another DUPLICATE attempt, which finally made progress.
After two and a half hours, RMAN finished. But to our surprise and frustration, the datafiles were still encrypted.
SQL>
SELECT ts.name as tablespace_name,
et.encryptedts,
et.encryptionalg
FROM v$tablespace ts,
v$encrypted_tablespaces et
WHERE ts.ts# = et.ts# (+)
ORDER BY 2 NULLS LAST, 1;
TABLESPACE_NAME ENCRYPTED ENCRYPTIONALG
------------------------------ --------- ---------------------
TBS_SALES YES AES256
TBS_HR YES AES256
TBS_GL YES AES256
USERS YES AES256
SYSAUX
SYSTEM
TEMP
UNDOTBS1
UNDOTBS2$ dbv file='+DAT06/DB3S/DATAFILE/tbs_sales.341.1244059789' userid=sys/TK6_7p8i
DBVERIFY: Release 19.0.0.0.0 - Production on Tue Sep 15 15:03:04 2026
Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.
DBVERIFY - Verification starting : FILE = +DAT06/DB3S/DATAFILE/tbs_sales.341.1244059789
DBVERIFY - Verification complete
Total Pages Examined : 4194302
Total Pages Processed (Data) : 0
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 0
Total Pages Failing (Index): 0
Total Pages Processed (Other): 11825
Total Pages Processed (Seg) : 0
Total Pages Failing (Seg) : 0
Total Pages Empty : 3523119
Total Pages Marked Corrupt : 0
Total Pages Influx : 0
Total Pages Encrypted : 659358 << << << << << << <<
Highest block SCN : 3270805281 (0.3270805281)Schrödinger's DUPLICATE
There’s an important nuance here: the 19c documentation does explicitly cover AS DECRYPTED, but it also contains an apparent contradiction on that same page that needs to be explained properly.
In the requirements section for AS ENCRYPTED / AS DECRYPTED, Oracle states that both clauses are supported options of DUPLICATE when COMPATIBLE >= 18.0.0.
But then, in the description of AS DECRYPTED, you find:
AS DECRYPTED ... data blocks in the duplicate database being unencrypted.
immediately followed by:
This clause is not supported for ... creating a standby database
That was something I hadn’t noticed myself, and since AI can sometimes hallucinate, I went through the documentation carefully. It turned out to be true: Oracle says DUPLICATE … AS DECRYPTED isn’t supported for creating a standby, and the same restriction appears in the Oracle 26ai documentation. But then, how did it work on my VMs running Oracle 19c?
I went back to My Oracle Support and searched for duplicate as decrypted, and this time it surfaced this document:
| KB172271 | Is It Possible To Take RMAN Backup As Decrypted When Using TDE With Tablespace Encryption? |
It explains that for this to work, you need the patch for bug 33672295. Looking into the bug details, I found it affects versions 19.19 through 19.27 and is fixed in 19.28 and later. That explained it: my client had Oracle 19.24, which didn’t have the patch, while my VM tests used Oracle 19.31, which did.
To be completely sure, I installed a new Oracle Home on my VMs with 19.24 without the patch for bug 33672295, and another with 19.24 that had the patch. The results confirmed it: without the patch, the standby stays encrypted. With the patch, even though the Oracle 19c documentation says this isn’t supported, you can create an unencrypted standby. Would the same be true for Oracle 26ai?
I set up new VMs, this time with Oracle 23.26.3. I repeated the whole test cycle and was able to create the physical standby unencrypted as well, using DUPLICATE AS DECRYPTED straight from the primary. Based on these results, I concluded that it may not be officially supported, but in practice, it works.
dbv file= '+DATA/ORCL2/5C0752B66DB14BFBE0638400A8C0CACF/DATAFILE/encrypted.431.1242167225' USERID=sys/Oracle1
DBVERIFY: Release 23.0.0.0.0 - Production on Mon Sep 15 15:44:31 2026
Copyright (c) 1982, 2026, Oracle and/or its affiliates. All rights reserved.
DBVERIFY - Verification starting : FILE = +DATA/ORCL2/5C0752B66DB14BFBE0638400A8C0CACF/DATAFILE/encrypted.404.1242167225
DBVERIFY - Verification complete
Total Pages Examined : 12800
Total Pages Processed (Data) : 35
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 43
Total Pages Failing (Index): 0
Total Pages Processed (Other): 12685
Total Pages Processed (Seg) : 0
Total Pages Failing (Seg) : 0
Total Pages Empty : 37
Total Pages Marked Corrupt : 0
Total Pages Influx : 0
Total Pages Encrypted : 0 << << << << << << <<
Highest block SCN : 815547 (0.815547)
Given all this, one question remains: it works, but is it safe to use in production?
A Bug Is a Bug Is a bug
There was no way I was letting this one go, so — since I’d reached out to Rodrigo Jorge, PM for Database Patching and Upgrade, before over some findings related to AutoUpgrade — I gave him a quick rundown of what I’d found and my interest in figuring out whether DUPLICATE AS DECRYPTED was, or wasn’t, currently a supported combination for creating a standby.
Diligent as always, Rodrigo loops in Ludovico Caldara, PM for Oracle Data Guard. Ludovico confirms — after checking with development — that yes, using it to create a standby is indeed possible, and that for 19c, it’s been supported since RU 19.28. That said, thanks to my question, they’ve realized the documentation still doesn’t reflect this, so he’s filing bug 40077685 – Restore and duplicate as decrypted work for tbsp-level tde keys. He also warns us that getting the documentation fixed and published will take some time.
And with that, the mystery was finally solved. What first looked like an unsupported DUPLICATE combination turned out to be a documentation bug that nobody had noticed yet.
Lessons Learned
- Encryption turns data into ciphertext, deliberately wiping out any recognizable or redundant patterns. This directly hurts your data’s compression and deduplication ratios and can increase physical space usage on storage systems that rely on data reduction—even when the logical size hasn’t changed at all. This also applies to your RMAN backups, so always factor in the impact and recalculate your physical space requirements.
- When space is freed up in an Oracle ASM disk group, the storage array doesn’t automatically detect that those blocks are now reclaimable. To do that, configure the ASM Filter Driver (or ASMLib v3) and set the thin_provisioned=TRUE attribute. Otherwise, you’ll need to reclaim it manually with OS-level commands like blkdiscard, as we had to do here.
- Whether it’s because of space constraints on thin-provisioned LUNs or Oracle TDE licensing considerations, you can have an encrypted primary database while its standby stays unencrypted. Just make sure the tablespace_encryption=DECRYPT_ONLY parameter is set.
- If you need to rebuild an unencrypted standby from an encrypted primary, using DUPLICATE … FROM ACTIVE DATABASE … AS DECRYPTED is fully supported. Just keep in mind that if you’re on Oracle 19c, you need to have the patch for bug 33672295 applied (already included in 19.28+).
Final Thoughts
What started as a routine task, with the only complication being that it had to run overnight, ended up being one of the most complex and demanding experiences I’ve had all year.
It was 30 straight hours of work: investigating and fixing every problem as it came up, running test after test on VMs, and always checking what the next step should be before moving forward. If you don’t already have an automated environment set up with Ansible, VirtualBox, and Vagrant, I strongly recommend you start building one. It will save you a lot of time, which is exactly what you need most during a crisis.
There were also meeting after meeting to report progress, explain the steps taken, discuss next steps, share both the good and bad results, estimate when everything would be resolved, and then later explain why that estimate didn’t hold and provide a new one.
Bottom line: dealing with incidents is never easy. But when the chaos finally settles, and everything is under control, what remains is the satisfaction and the certainty that we chose the right profession. And with that, at 11 pm, it was finally time to sleep…
