Tabla de Contenidos
Era la segunda fecha de un proyecto de implementación de TDE en Oracle 19c, y lo que se esperaba que tomara menos de 12 horas terminó tardando casi 30 y, lo que es peor, con una interrupción parcial del servicio.
Si te quieres ahorrar el dolor de cabeza y, de paso, entretenerte con una historia llena de giros de guion y un final inesperado, continúa leyendo; no te arrepentirás.
La calma antes de la tormenta
Ya sabes, ejecutas alter tablespace … encryption online encrypt y comienza la magia: Oracle toma un datafile y empieza a encriptarlo; cuando termina, pasa al siguiente y así hasta acabar con todos. Mientras tanto, en el redo viaja la indicación al physical standby para que se repita la misma secuencia que en el primario.
Resultado final: primario y standby encriptados, sin interrupción alguna del servicio.
Ya había trabajado con 2 bases de datos la semana anterior, y esta vez tocaban 3 más. Empezamos a las 5 pm y teníamos estimado terminar a las 6 am del día siguiente. Mi último chequeo fue a la 1 am y todo funcionaba… hasta que dejó de hacerlo.
Houston, tenemos un problema
A las 2:30 am verifico que las bases de datos primarias siguen encriptando, pero los physical standby no; los archivos alert.log registran errores de grabación.
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
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:00
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 1Una búsqueda por OSD error 27061 indica que posiblemente se ha agotado el espacio en disco, lo cual resulta raro, ya que según ASMCMD aún hay mucha capacidad libre; sin embargo, sí confirma que el disk group DAT06 ya no está disponible.
$ 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/
En este momento, es evidente que no estoy ante un problema a nivel de Oracle Server u Oracle TDE, sino que involucra otra capa y, sin más que hacer por mi parte, es inevitable informar al jefe del proyecto, quien, a su vez, convoca al especialista en storage.
Tras unos minutos de tensa espera, el especialista nos confirma que nuestra sospecha inicial es la correcta: ya no queda espacio libre en el storage server, ¡ni un solo byte!
El espacio: ¿La frontera final?
Todo storage moderno incluye la capacidad de reducción de datos, usualmente mediante una combinación de compresión, deduplicación y thin provisioning, y este era nuestro caso: los 18 TiB que Oracle registra como espacio lógicamente consumido por estas 3 bases de datos en realidad ocupaban físicamente unos 5 TiB. Ahora bien, al encriptar los datafiles se anula prácticamente toda posibilidad de compresión y deduplicación. El resultado: cada vez se consume más espacio físico, hasta que finalmente no queda nada y todo intento de añadir datos aborta.
Afortunadamente, las bases de datos primarias ya están encriptadas y no hubo interrupción alguna de los servicios principales, aunque, debido a la falta de espacio, los physical standby quedaron inservibles y algunas tareas se interrumpieron: backups, consultas y reportes; nada que sea fatal, pero es imperioso restaurar el 100% del servicio lo antes posible.
Desencripto, luego existo
Como no hay espacio y conseguir más puede tomar mucho tiempo, la solución más simple e inmediata es reconstruir los physical standby sin encriptación, por lo que busco unencrypted standby en My Oracle Support y me presenta el documento:
| KB874637 | Steps to Create a Standby Database Unencrypted from an Primary database Having Encrypted Tablespace |
En él se indica que, como primer paso, debemos obtener un backup con RMAN y luego restaurarlo usando AS DECRYPTED. También se señala que hay que tener cuidado en fijar el parámetro tablespace_encryption=DECRYPT_ONLY.
Obtener este respaldo va a requerir tiempo y espacio adicionales y, como no tenemos ni lo uno ni lo otro, me decido a probarlo directamente con DUPLICATE a partir de la base de datos primaria.
Armo mi ambiente de pruebas (VMs con VirtualBox), cruzo los dedos y ejecuto desde RMAN:
RMAN>
run {
DUPLICATE TARGET DATABASE
FOR STANDBY
FROM ACTIVE DATABASE
DORECOVER
AS DECRYPTED
NOFILENAMECHECK;
}Pocos minutos después, la duplicación ha terminado; ya tengo el physical standby y, para mi beneplácito, compruebo que sus datafiles no están encriptados.
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)Con estos resultados alentadores, montamos el disk group fallido y limpiamos todos los archivos de las 3 bases de datos afectadas.
$ . 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/db3sProcedo a duplicar una de las bases de datos, a modo de prueba, pero pasan 10 minutos y no veo que avance:
..
.
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 archivedConsultando en V$SESSION encuentro que hay esperas por el evento control file sequential read, lo cual me lleva a sospechar de un caso similar sobre el cual había escrito un artículo anteriormente (y que te recomiendo leer). Con base en ello ejecuto la consulta del caso:
SQL>
SELECT type, records_total, records_used
FROM v$controlfile_record_section
WHERE type='ARCHIVED LOG';
TYPE RECORDS_TOTAL RECORDS_USED
-------------------- ------------- ------------
ARCHIVED LOG 116508 81426Y efectivamente se trata del mismo problema: hay una cantidad exagerada de filas (81,426) correspondientes al historial de archived redo logs; esto ocasiona que RMAN deba invertir mucho tiempo en procesar el controlfile durante la duplicación, así que rápidamente abortamos la clonación e inmediatamente aplicamos el workaround:
SQL>
exec dbms_backup_restore.resetcfilesection(11);
RMAN>
catalog start with '+FRA01/db3s/archivelog';Vuelvo a lanzar el DUPLICATE y ahora sí avanza, al menos durante un par de minutos, porque luego vuelve a caer y, para sorpresa nuestra, ¡nuevamente por falta de espacio!
..
.
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.Ojos que no ven, corazón que sí siente
El especialista en storage nos confirma que los LUNs asignados a los 3 disk groups aún figuran con el consumo inicial; en otras palabras, el storage no se ha enterado de que el espacio ha sido liberado a nivel de ASM y, por tanto, cuando RMAN intenta copiar los datafiles, el storage recibe la indicación de ofrecer más espacio, pero este ya está agotado.
Resulta que los LUNs asignados a ASM están configurados con thin provisioning, y luego de revisar la documentación de Oracle 19c, encontramos que la única forma de que el espacio liberado con ASMCMD se refleje en el storage es que el disk group tenga configurado el atributo thin_provisioned=TRUE. Se indica, además, que esto funcionará si y solo si se usa ASM Filter Driver (ASMFD), lo cual no es nuestro caso pues estamos usando la vieja y confiable combinación multipath con udev.
¿Qué hacer? ¿Nos ponemos a experimentar y bajamos todos los servicios del clusterware y configuramos ASMFD? Pues no, somos osados pero no locos; es mejor ir a lo seguro y mantener el daño bajo control, por lo que optamos por liberar el espacio con fuerza bruta desde el sistema operativo (RHEL7).
#
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_008p1Esperábamos que fuese algo rápido, pero tomó poco más de 2 horas procesar los 21 discos de 1 TiB cada uno.
El resultado final vale la espera: el especialista en storage nos confirma que los discos figuran con 0% de uso y, con ello, nos apuramos a ejecutar un nuevo intento de clonación con DUPLICATE, que ahora sí avanza.
Luego de 2 horas y 30 minutos, RMAN concluye, pero, para nuestra sorpresa y frustración, los datafiles están encriptados.
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)El DUPLICATE de Schrödinger
Hay una precisión importante: la documentación 19c sí incluye explícitamente AS DECRYPTED, pero también contiene una contradicción aparente dentro de la misma página que hay que explicar correctamente.
En la sección de requisitos para AS ENCRYPTED / AS DECRYPTED, Oracle dice que ambas cláusulas son opciones soportadas de DUPLICATE cuando COMPATIBLE >= 18.0.0.
Pero luego, en la descripción de AS DECRYPTED, aparece:
AS DECRYPTED ... data blocks in the duplicate database being unencrypted.
y acto seguido:
This clause is not supported for ... creating a standby database
Eso es algo de lo que no me había percatado y, como a veces la IA alucina, reviso minuciosamente la documentación y es verdad: Oracle indica que DUPLICATE … AS DECRYPTED no está soportado si lo que se desea es crear un standby; lo mismo figura en la documentación de Oracle 26ai. Pero entonces: ¿cómo es que sí lo logré en mis VMs con Oracle 19c?
Ingreso nuevamente a My Oracle Support y busco duplicate as decrypted, y esta vez me ofrece el documento:
| KB172271 | Is It Possible To Take RMAN Backup As Decrypted When Using TDE With Tablespace Encryption? |
En él se señala que, para que funcione correctamente, se necesita aplicar el parche para el bug 33672295, y al buscar el detalle del mismo encuentro que se ha reportado como afectando a las versiones 19.19 a 19.27, y que ya está resuelto desde 19.28. Ahora todo tiene sentido: mi cliente tenía instalado Oracle 19.24, que no incluye el parche, y mis pruebas en VMs usaron Oracle 19.31, que ya incluye el parche del bug.
Para estar 100% seguro, instalo en mis VMs un nuevo Oracle Home con 19.24 sin el parche 33672295 y otro Oracle Home con 19.24 que sí lo tiene, y los resultados lo confirman: sin el parche el standby se mantiene encriptado, pero con el parche, y aun cuando la documentación de Oracle 19c indica que no está soportado, sí es posible crear un standby sin encriptar, sin embargo ¿ocurrirá lo mismo con Oracle 26ai?
Creo nuevas VMs, ahora con Oracle 23.26.3. Repito mi ciclo de pruebas y también logro crear el physical standby sin encriptar, usando DUPLICATE AS DECRYPTED directamente desde el primario. Con estos resultados llego a la siguiente conclusión: puede que oficialmente no esté soportado, pero en la práctica sí funciona.
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)
Siendo así, aún queda la duda: funciona, pero ¿será seguro usarlo en producción?
Un bug es un bug es un bug
Obviamente no me iba a quedar con la duda, así que aprovechando que anteriormente había recurrido a Rodrigo Jorge, PM – Database Patching and Upgrade, por algunos hallazgos con el uso de AutoUpgrade, le comenté brevemente lo que había encontrado y mi interés en determinar si actualmente DUPLICATE AS DECRYPTED era o no una combinación soportada para crear un standby.
Siendo lo diligente que es, Rodrigo incluye en la conversación a Ludovico Caldara, PM – Oracle Data Guard. Ludovico nos confirma que, luego de consultarlo con desarrollo, sí es posible usarlo para crear un standby y que, en 19c, lo es desde el RU 19.28. Eso sí, gracias a mi consulta se han percatado de que la documentación todavía no refleja este cambio, así que está registrando el bug 40077685 – Restore and duplicate as decrypted work for tbsp-level tde keys. Nos advierte, además, que las correcciones a la documentación tomarán algo de tiempo en publicarse.
Y con esto, por fin, el misterio está resuelto: lo que inicialmente parecía una combinación no soportada de DUPLICATE resultó ser un bug de documentación que aún no habían notado.
Lecciones aprendidas
- La encriptación transforma los datos en texto cifrado, eliminando intencionalmente patrones reconocibles y redundantes. Esto impacta directamente en la capacidad de compresión y deduplicación de los datos y, por tanto, puede aumentar el consumo de espacio físico en sistemas de almacenamiento que utilizan algoritmos de reducción de datos, aunque el tamaño lógico no haya variado. Este incremento también se aplicará a los respaldos con RMAN, así que evalúa siempre su impacto y calcula los nuevos requisitos de espacio físico.
- Cuando se libera espacio en un disk group de Oracle ASM, el storage no detecta automáticamente que esos bloques pueden recuperarse. Para que esto ocurra, se necesita configurar el uso del ASM Filter Driver (o ASMLib v3) y establecer el atributo thin_provisioned=TRUE. De lo contrario, será necesario liberarlo manualmente mediante comandos del sistema operativo como blkdiscard, tal como hicimos en nuestro caso.
- Ya sea por problemas de espacio en un entorno con LUNs configurados con thin provisioning, o por temas de licenciamiento de Oracle TDE, es posible tener una base de datos primaria encriptada mientras que su standby no lo está. Solo asegúrate de que esté fijado el parámetro tablespace_encryption=DECRYPT_ONLY.
- Si necesitas reconstruir un standby no encriptado a partir del primario encriptado, está perfectamente soportado usar DUPLICATE … FROM ACTIVE DATABASE … AS DECRYPTED. Ten en cuenta que si usas Oracle 19c, debes asegurarte de tener aplicado el parche 33672295 (ya incluido en 19.28+).
Reflexiones finales
Lo que comenzó como una tarea rutinaria, cuya única complicación aparente era tener que ejecutarse de madrugada, terminó siendo una de las experiencias más complejas y demandantes en lo que va del año.
Fueron 30 horas de trabajo ininterrumpido, investigando y resolviendo cada problema que se iba presentando, haciendo prueba tras prueba en VMs y validando constantemente cuál debía ser el siguiente paso antes de continuar. En este punto, si todavía no tienes un entorno automatizado con Ansible, VirtualBox y Vagrant, te recomiendo que empieces a trabajar en ello. Te ahorrará muchísimo tiempo, que es precisamente el recurso que más escasea cuando estás en medio de una crisis.
También hubo reunión tras reunión para informar del avance, explicar las medidas tomadas, discutir las medidas por tomar, comunicar los buenos y malos resultados obtenidos, estimar cuándo estaría todo resuelto y, posteriormente, explicar por qué ese estimado no se había cumplido y proporcionar uno nuevo.
En fin, nunca es fácil lidiar con incidentes, pero cuando por fin acaba este caos, todo está bajo control y los problemas están resueltos, quedan la satisfacción y la certeza de que escogimos la profesión correcta. Y, siendo las 11 pm, por fin: a dormir…
