Tengo una base de datos Oracle 19.3 Multitenant a la que intento aplicar la actualización de la versión 19.7. El RU fue instalado por opatch muy bien. Pero el parche de datos incurrirá en el error ORA-1114. Recibo errores como el siguiente en uno de los registros:
SQL> modificar la base de datos conectable GOLD2020_06_18_123653 abrir instancias de lectura y escritura =todas;
modificar la base de datos conectable GOLD2020_06_18_123653 abrir instancias de lectura y escritura =todas
*
ERROR en la línea 1:
ORA-65107:Se encontró un error al procesar la tarea actual en la instancia:1
ORA-17500:error de ODM:argumento no válido
ORA-01114:error de E/S al escribir el bloque en el archivo 12346 (bloque n.º 1)
ORA-17500:error de ODM:argumento no válido
ORA-01114:error de E/S al escribir el bloque en el archivo 12345 (bloque n.º 1)
ORA-17500:error de ODM:argumento no válido
Antes de que pueda explicar cuál es el problema, permítanme analizar cómo usamos Multitenant en mi entorno. Una vez a la semana, tenemos un trabajo cron que crea una copia de nuestra base de datos de producción (utilizando instantáneas de hardware basadas en disco). Llamamos a esta copia de producción nuestra “imagen dorada”. Esta imagen dorada está conectada a nuestra base de datos como uno de nuestros PDB. El nombre PDB tiene el formato GOLDyyyy_mm_dd_hhmiss para que sepamos cuándo se creó ese PDB.
Todas nuestras bases de datos de desarrollo y prueba se crean a partir de este PDB de imagen dorada. Cuando necesito actualizar DEV1 o TEST, simplemente apagamos el PDB para DEV1 o TEST y lo soltamos. Luego creamos un clon instantáneo de la última imagen dorada. El PDB de la imagen dorada está en modo de SOLO LECTURA para facilitar la clonación de la instantánea.
Como escribí aquí, cuando se usa un PDB como fuente para un clon de instantánea, Oracle cambiará los permisos de archivo a 220. Esto es Oracle protegiéndonos de nosotros mismos. No se nos debería permitir modificar la fuente de un clon de instantánea para que Oracle haga que los archivos de datos sean de solo lectura. Quien sea en Oracle que haya decidido cambiar los permisos de los archivos fue una buena idea, no habló de ello con los desarrolladores del parche de datos.
Datapatch ve el PDB de SÓLO LECTURA y quiere abrirlo como LECTURA Y ESCRITURA, parchea el interior del PDB y luego vuelve a establecerlo en SÓLO LECTURA. Sin embargo, el parche de datos no puede abrir la PDB en modo de lectura y escritura porque los permisos del archivo no lo permiten. De ahí los errores que estoy recibiendo.
Oracle me hizo esto... forzaron los permisos de archivo de una manera y luego el parche de datos no puede hacer lo que ahora quieren que haga.
Todavía no he recibido noticias oficiales con mi solicitud de servicio, pero espero que esto se convierta en un error. En mi opinión, Datapatch debería omitir cualquier PDB que sea fuente de clones de instantáneas.
Mientras tanto, puedes usar la fuerza bruta para salir de esto. Intenté usar el parámetro -exclude_pdbs para el parche de datos, pero no funcionó. Aparentemente, hay un error conocido en el que ese parámetro no funciona si su lista de PDB tiene una coma. Así que tuve que ejecutar el parche de datos de la siguiente manera:\
./datapatch -verbose -pdbs cdb\$root
./datapatch -verbose -pdbs pdb\$seed
./parche de datos -verbose -pdbs dev1,dev2
Primero, ejecuté datapatch para parchear CDB$ROOT. Luego parché PDB$SEED. Luego parcheé mis PDB de desarrollo. Simplemente no parcheé mis PDB de imágenes doradas.
