En breve Oracle publicará una nueva release para los productos Database y Grid Infrastructure. Como hace ya algún tiempo viene anunciando, se producirán cambios importantes realacionados con la liberación de nuevas versiones y con las políticas y métodos de actualización de la base de datos.

Así, lo que debería haber sido la versión 12.2.0.2 con la llegada del nuevo Patch Set, pasará a denominarse Oracle 18. Tras esto, Oracle entregará una nueva release cada año, por lo que tendremos un Oracle 19 que previsiblemente será la última actualización de la tecnología 12c.

Las nuevas versiones anuales dejarán de ser Patch Sets, desapareciendo así estos míticos parches Oracle, que son sustituidos por las RUs (Release Updates). También desaparecen los Patch Set Updates (PSUs), pero se mantiene la política de actualización trimestral con la liberación de RURs (Release Update Revisions).

Estos cambios introducen una nueva nomenclatura de versiones, que contendrá tres campos: año, actualización y revisión. Cada trimestre, tendremos disponible un cambio de versión con nuevas incorporaciones funcionales, a diferencia de lo que ocurría ahora, que era necesario esperar a un nuevo Patch Set para disponer de nuevas funcionalidades. Cada trimestre (Quarter) podremos aplicar los nuevos cambios funcionales sobre la GI y la base de datos (versiones 18.1, 18.2, 18.3), o podremos aplicar sólo las mejoras de seguridad y resolución de parches sobre una RU específica sin ser necesario evolucionar funcionalmente (18.2.1, 18.2.2, 18.2.3), y mantener una política más conservadora en el parcheo.

Objetivos del cambio

Los objetivos que Oracle indica para este cambio son muy interesantes:

  • Reducción de tiempos en la disponibilidad de nuevas funcionalidades.
  • Mejora de calidad software al reducir el número de cambios introducidos en cada evolución (cultura Agile/DevOps? 🙂 )
  • Evitar en la medida de lo posible la aplicación de parches individuales (one-off), lo que se alinea completamente con la política Arumel de parcheado (que no siempre es posible) para simplificar el mantenimiento de una instalación.
  • Mantener la posibilidad de actualizaciones de seguridad y errores sin precisar cambios evolutivos (nuevas funcionalidades). Esto es algo similar al que actualmente aplican los PSUs.

Mapa de versiones

Podemos ver de manera más sencilla el ciclo de vida y el calendario de publicación de versiones previsto. Podemos encontrar información completa en la nota MOS Release Update Introduction and FAQ (Doc ID 2285040.1).

La versión 18.1.0 tendrá su primera RU en el segundo trimestre. En el tercero, además de ser publicada una nueva RU, se publicará simultáneamente la RUR1 para 18.2.0. En el último trimestre, aparecerá la RU 18.4.0 y la última actualización (RUR) para la RU 18.2 (18.2.2), que no tendrá más actualizaciones de seguridad ni bugs, siendo precisa la actualización de RU para seguir disponiendo de nuevos parches (Oracle indica explícitamente que el soporte sigue garantizado aunque no se apliquen los parches).

Por otro lado, tanto las RUs como las RURs que se publican en un trimestre, contendrán el mismo nivel de parches. De este modo, dentro de una misma versión, los niveles de RU y RUR que sumen la misma cifra indican un mismo nivel de parcheado. Por ejemplo, 18.5.0, 18.4.1 y 18.3.2 tendrán un mismo nivel de parches de seguridad aplicados.

 

Primeras impresiones

Tras revisar el nuevo planteamiento evolutivo / correctivo de Oracle, tengo las siguientes impresiones:

  • Menores cambios más simples de aplicar a costa de un menor ciclo de vida de una RU (6 meses de actualizaciones). A partir de los 6 meses, no se entregarán nuevos RUR para esta versión, por lo que cada RU tendrá inicialmente un máximo de dos actualizaciones.
  • Pese a este menor ciclo de vida, Oracle indica que no será obligatorio el parcheo para poder solicitar parches para nuevos bugs. Sólo será recomendado. Con esta premisa podemos ver que el soporte se mantiene, durante el ciclo de vida de la versión sin introducir estrés adicional para la actualización.
  • Una RUR nunca incluirá nuevas funcionalidades (similar a lo que ocurría con los PSUs).
  • Hay independencia entre RUs y RURs, por lo que para la aplicación de un RUR no será preciso aplicar previamente el RU. Deberá ser por lo tanto posible pasar de 18.2.1 a 18.3.2 aplicando un solo parche.
  • Pese al que parece deducirse de la información inicial, no será posible cualquier movimiento entre RU y RUR. Existirá un criterio de “cummulative”, que básicamente parece que será que el parche sea posterior, no se podrá pasar de 18.2.2 a 18.3.0 ya que esta última es una versión anterior.
  • La actualización de OJVM seguirá siendo uno de las pesadillas de la aplicación de parches de base de datos. Oracle está trabajando en la mejora del procedimiento, pero por lo de ahora no está garantizada la integración en la aplicación de un RU / RURs.
  • Este nuevo criterio de parcheado no aplicará en plataformas Windows (se mantienen los Bundle Patches).
  • No aplica este cambio para las versiones 12.2.0.1 y 11.2.0.4 que se seguirán actualizando con PSUs.
  • Las versiones 18 y 19 cubrirán el ciclo de vida previsto para la versión 12c.
%d bloggers like this: