El último día del mes de febrero, Mike nos comparte un post, sobre un tema que es poco conocido, pero puede tener un impacto grande, tanto a nivel de estructuras de la base de datos, como en espacio local de almacenamiento en el servidor.
En esta profesión de DBA, a quienes tienen la costumbre de aplicar todos los RU (Release Update) a una base de datos de forma consecutiva, aún cuando no sea necesario hacerlo.
Si yo he instalado la versión base de 19c 19.3.0.0, no necesito instalar ningún RU intermedio para actualizar mi base de datos a 19.25.0.0, pero si es necesario actualizar la herramienta de OPatch, ya que esta si cambia en prerequisitos específicos para cada cierto grupo de RU.
En la práctica, personalmente he visto algunas diferencias importantes en 19.10 y 19.11, que de alguna manera, me lleva como práctica propia a actualizar primero de 19.3 a 19.10 y luego de ahí a 19.18 que es el otro RU que noto diferencias significativs y posteriormente a cualquier RU reciente.
Por ejemplo, he visto cambios importantes en el rendimiento a favor, a la hora de instalar 19.10. Lueg en 19.18 se incluye algunas validaciones adicionales que tienen que ver con el número máximo de PDBs a nivel de contenedor para la versión SE2 y E.E.
A la hora de hacer un parcheo en la versión 19.18 a 19.19 a una base de datos 19c desplegada como IaaS, en una instancia de Oracle Linux en el OCI, se me hizo imposible crear más de 3 PDBs en un contenedor con Oracle Database Enterprise Edition. A pesar que subí un par de casos con el área de PM's del producto, no tuve respuesta al inconveniente sufrido. Después de reinstalar un ambiente nuevo y pasar directamente a 19.15 desde 19.3 no tuve inconvenientes como los descritos anteriormente.
El tema aquí de fondo, es que cada vez que aplicamos un RU, en el proceso previo de aplicación, la herramienta OPatch, hace un backup de aquellos archivos de la versión actualmente instalada, para poder realizar un "rollback" a nivel de la aplicación del parche.
Adicionalmente al OPatch a través del comando "DATAPATCH", guarda en la base de datos, la colección completa de scripts SQL y PL/SQL en un archivo ZIP para poder realizar "ROLLBACK" en el tablespace SYSTEM. Esto como lo afirma Mike provoca inevitablemente que el tablespace SYSTEM crezca con cada aplicación de RU.
Aquí el punto es que no es necesario mantener la copia de los scripts anteriores de cada RU, porque cada aplicación, contiene la información necesaria para disolver los cambios anteriores. Por decirlo de alguna manera, es un respaldo acumulativo.
Si aplico en orden cada RU que fue siendo liberado para una versión base en el software de la base de datos, vamos a ir aumentando acumulativamente el espacio ocupado.
Y esta acumulación no sólo se da a nivel de la metadata del CDB$ROOT o sea en el container database, sino también, se hace en cada metadata para cada pluggable database que tengamos en el contenedor.
Mike nos indica que han logrado crear un parche para poder hacer esta limpieza. El número del parche es el
Actualmente el parche sólo esta disponible en One-off patches para las versiones 19.25.0, 19.26.0 y 23.7.0.
Una vez aplicado este parche agrega un nuevo parámetro al comando DATAPATCH de la herramienta OPatch:
- ./datapatch -purge_old_metadata
Se espera, que para la liberación del RU del mes de Julio de este 2025, -RU 19.28- ya sea incluido como parte de la herramienta OPatch, on en el mismo RU.
Ya he realizado el proceso de aplicación de la limpieza y la verdad que fue bastante rápido, comparado con el tiempo que tardaba aplicando el proceso anterior.
Existen varias publicaciones sobre este mismo tema en el blog de Mike:
Para el evento del LAOUC 2025, he subido una propuesta con el nombre de: Tablespace SYSTEM en Peligro: La Trampa
del Crecimiento de Datapatch en donde estaré explicando a profundida el procedimiento y mostrando el impacto a nivel de almacenamiento, en el servidor de la base de datos y en el tablespace SYSTEM del contenedor y de cada pluggable database.
En caso de no se admitido para el evento, estaría compartiendo a través de un video con ustedes todo el proceso en un par de meses.
