En breve Oracle publicará unha nova release para os produtos Database e Grid Infrastructure. Como hai xa algún tempo que ven anunciando, produciranse cambios importantes realacionados coa liberación de novas versións e coas políticas e métodos de actualización da base de datos.

Así, o que debera ser a versión 12.2.0.2 coa chegada do novo Patch Set, pasará a denominarse Oracle 18. Tras isto, Oracle entregará unha nova release cada ano, polo que teremos un Oracle 19 que previsiblemente será a última actualización da tecnoloxía 12c.

As novas versións anuais deixarán de ser Patch Sets, desaparecendo con elo estes míticos parches Oracle, que son substituídos polas RUs (Release Updates). Tamén desaparecen os Patch Set Updates (PSUs), pero mantense a política de actualización trimestral coa liberación de RURs (Release Update Revisions).

Estes cambios introducen unha nova nomenclatura de versións, que conterá tres campos: ano, actualización e revisión. Cada trimestre, teremos dispoñible un cambio de versión con novas incorporacións funcionais, a diferencia do que acontecía agora, na que estas modificacións eran introducidas polos Patch Sets. Así, cada trimestre (Quarter) poderemos aplicar os novos cambios funcionais sobre a GI e a base de datos (versións 18.1, 18.2, 18.3), ou poderemos aplicar só as melloras de seguridade e resolución de parches sobre unha RU específica sen ser preciso evolucionar funcionalmente (18.2.1, 18.2.2, 18.2.3).

Obxectivos do cambio

Os obxectivos que Oracle indica para este cambio son moi interesantes:

  • Redución de tempos na dispoñibilidade de novas funcionalidades.
  • Mellora de calidade software ó reducir o número de cambios introducidos en cada evolución (cultura Agile/DevOps? 🙂 )
  • Evitar na medida do posible a aplicación de parches individuais (one-off), o que se aliñea completamente coa política Arumel de parcheado (que non sempre é posible) para simplificar o mantemento dunha instalación.
  • Manter a posibilidade de actualizacións de seguridade e erros sen precisar cambios evolutivos (novas funcionalidades). Isto é algo similar ó que actualmente aplican os PSUs.

Mapa de versións

Podemos ver de xeito máis sinxelo o ciclo de vida e o calendario de publicación de versións. Podemos atopar información completa na nota MOS Release Update Introduction and FAQ (Doc ID 2285040.1). A versión 18.1.0 terá a súa primeira RU no segundo trimestre. No terceiro, ademais de ser publicada unha nova RU, publicarase simultaneamente a RUR1 para 18.2.0. No último trimestre, aparecerá a RU 18.4.0 e a última actualización (RUR) para a RU 18.2 (18.2.2), que non terá máis actualizacións de seguridade nin bugs, sendo precisa a actualización de RU para seguir dispoñendo de novos parches (Oracle indica de xeito claro que o soporte segue garantido aínda que non se apliquen os parches).

Por outro lado, tanto as RUs como as RURs que se publican nun trimestre, conterán o mesmo nivel de parcheo. Deste xeito, dentro dunha mesma versión, os niveis de RU e RUR que sumen a mesma cifra indican un mesmo nivel de parcheado. Por exemplo, 18.5.0, 18.4.1 e 18.3.2 terán un mesmo nivel de parches de seguridade aplicados.

 

Primeiras impresións

Tras revisar o novo plantexamento evolutivo / correctivo de Oracle, obteño as seguintes impresións:

  • Menores cambios máis simples de aplicar a costa dun menor ciclo de vida dunha RU (6 meses de actualizacións). A partires dos 6 meses, non se entregarán novos RUR para esta versión, polo que cada RU terá inicialmente un máximo de dúas actualizacións.
  • Pese a este menor ciclo de vida, Oracle indica que non será de obrigatorio o parcheo para poder solicitar parches para novos bugs. Só será recomendado. Con esta premisa podemos ver que o soporte mantense, incluíndo a apertura de incidencias para novos parches, durante o ciclo de vida da versión sen introducir estrés adicional para a actualización.
  • Unha RUR nunca incluirá novas funcionalidades (similar a o que acontecía cos PSUs).
  • Hai independencia entre RUs e RURs, polo que para a aplicación dun RUR non será preciso aplicar previamente o RU. Deberá ser polo tanto posible pasar de 18.2.1 a 18.3.2 aplicando un só parche.
  • Pese ó que parece deducirse da información inicial, non será posible calquera movemento entre RU e RUR. Existirá un criterio de “cummulative”, que basicamente parece que será que o parche sexa posterior, non se poderá pasar de 18.2.2 a 18.3.0 xa que esta última é unha versión anterior.
  • A actualización de OJVM seguirá a ser un dos pesadelos da aplicación de parches de base de datos. Oracle está a traballar na mellora do procedemento, pero polo de agora non está garantida a integración na aplicación dun RU / RURs.
  • Este novo criterio de parcheado non aplicará en plataformas Windows.
  • As versións 11.2.0.4 e 12.2.0.1 manterán o actual sistema de actualización por PSUs.
  • As versións 18 e 19 cubrirán o ciclo de vida previsto para a versión 12c.