Hace unos días, publicábamos una entrada sobre los cambios que Oracle 18c introduce a nivel de identificación de versionado y aplicación de parches.

Como es habitual, cada vez que aparece una nueva versión de Oracle, acudimos a las New Features para buscar recopilar esas cosas que echábamos en falta y que por fin llegan.

Con la llegada de 12c, vimos que Flex ASM nos aporta lo que su nombre ya parece querer indicar, flexibilidad a la hora de gestionar el acceso a ASM por parte de las instancias en un RAC. Dejó de ser necesario que una instancia de base de datos tenga en su nodo local una instancia ASM arrancada para poder acceder al almacenamiento. Así, 12c empezó a permitir que una instancia de base de datos sobreviva a la caída de una instancia ASM (local o remota), manteniendo la actividad de sus sesiones de usuario, algo inviable en versiones anteriores. También pudimos ver que, gracias al empleo de ACFS como sistema de almacenamiento, esta protección es extensible a bases de datos en versión 11.2.0.4, como podemos ver en este artículo de Sergio Menoyo.

Oracle 18c anuncia mejoras en la alta disponibilidad RAC, introduciendo en la Grid Infrastructure la funcionalidad Zero Impact Patching. ¿Qué aporta ZIP? La posibilidad de aplicar parches sobre la capa de Grid Infrastructure (Clusterware + ASM) en modo rolling upgrade (con paradas individulaes de cada nodo en lugar de todo el clúster), pero manteniendo en ejecución las instancias de base de datos y sin interrupción en las sesiones de usuario mientras se aplica el parche.

Por lo de ahora no he encontrado mucha información técnica al respecto, ni siquiera en la guía de instalación / upgrade de GI 18.Podemos ver información en el blog oficial de Oracle, en esta presentación en el Open World de 2017, o en el White Paper de presentación de Oracle 18.De esta información sabemos que la actualización de la GI será out-of-place (nuevo GI_HOME completo aparte del existente, como ocurre con los Patch Sets desde 11gR2). El cambio implicará parar la capa GI antigua y arrancar la nueva, y en el proceso no se pararán las instancias de base de datos. Interesante, especialmente si esta funcionalidad se puede extender más allá de la aplicación de parches, por ejemplo, permitiendo un reinicio de la capa de clúster sin paradas de las instancias de BD en cualquier otro momento. Veremos con la liberación de la versión 18c on-premise (en el momento de escribir esta entrada solo están disponibles las versiones Cloud y Engineered Systems) y con los primeros RURs las capacidades y posibilidades del ZIP.