All Things Oracle

Aprende a parchar como Dios manda (S1E1)

En esta vida no hay nada seguro, salvo la muerte, los impuestos y... el parchado.

Todos estamos de acuerdo en que el parchado es una actividad que se debe ejecutar de forma periódica, ya que presenta los siguientes beneficios:

  • Resolver bugs que afectan el desempeño y/o la calidad de los resultados
  • Resolver bugs que afectan la seguridad
  • Incluir mejoras / nuevas características

Por otro lado, debemos considerar que los parches se presentan en varias formas:

Release Updates (RU)Contiene cientos de parches que resuelven problemas conocidos. Se genera trimestralmente.
Monthly Recommended Patches (MRP)Contiene los parches para los bugs registrados en la nota 555.1. Se genera mensualmente para cada RU.
Interim patchTambién conocido como one-off. Sirven para resolver problemas específicos, usualmente de forma reactiva.
Merge patchSe genera para superar los conflictos entre one-offs y RU/MRPs.

Parchado in-place

Recibe este nombre la forma tradicional de aplicar parches, ya que implica trabajar exclusivamente sobre el Oracle Home (en adelante OH) que contiene los ejecutables en uso por la base de datos.

Veamos como se desarrolla un ciclo de parchado bajo esta modalidad.

Situación inicial

Contamos con un servidor llamado server1, en el cual se tiene instalado Oracle Database Server 19c, en un OH llamado DBHome1, que da soporte a una base de datos single instance.

Este OH tiene aplicados los siguientes parches:

34765931 database release update 19.18.0.0.0
34786990 ojvm release update 19.18.0.0.0
34777391 jdk bundle patch 19.0.0.0.230117
35573556 database mrp 19.18.0.0.230718
34972375 datapump bundle patch 19.18.0.0.0
in-place patching - original situation
$ opatch lspatches

29585399;OCW RELEASE UPDATE 19.3.0.0.0 (29585399)
31222103;STRESS RAC ATPD FAN EVENTS ARE NOT GETTING PROCESSED WITH 21C GI AND 19.4 DB
32727143;TRANSACTION-LEVEL CONTENT ISOLATION FOR TRANSACTION-DURATION GLOBAL TEMPORARY TABLES
33973908;DBWR NOT PICKING UP WRITES FOR SOME TIME
34340632;AQAH  SMART MONITORING & RESILIENCY IN QUEUE KGL MEMORY USAGE
34557500;CTWR CAUSED MULTIPLE INSTANCES IN HUNG STATE ON THE RAC STANDBY DATABASE
34632426;FADBRWT STRESS FA HITTING MULTIPLE INCIDENTS OF ORA-12850 IN ALERT LOG EVEN WITHOUT EXPLICITLY SETTING 12850 ERROR EVENT IN 19.17RU
34765931;DATABASE RELEASE UPDATE : 19.18.0.0.230117 (REL-JAN230131) (34765931)
34777391;JDK BUNDLE PATCH 19.0.0.0.230117
34783802;PARALLEL QUERY ON PARTITIONED TABLE RETURNS WRONG RESULT
34786990;OJVM RELEASE UPDATE: 19.18.0.0.230117 (34786990)
34793099;STRESS FA CDB CREATION FAILS ON 19.17 WITH THE ORA-00704  BOOTSTRAP PROCESS FAILURE WHILE OPENING PDB$SEED
34809715;SQL WITH CASE EXPRESSION MAY FAIL WITH ORA-00932 IN 19.17 AND ABOVE
34810252;SPIN OFF FOR BUG 34808861 [ORA-00600  INTERNAL ERROR CODE, ARGUMENTS  [KFDS_GETSEGREUSEENQ01] TERMINATED ALL DB INSTANCES
34832725;ORA-4031 KSU STATS_FREELIST AND KGLSESHTTABLE ERRORS IN 19C
34847038;ORA-16856 TRANSPORT LAG COULD NOT BE DETERMINED | TRANSPORT LAG  (UNKNOWN) | NO LAG | 19.16.0.0
34861493;RESYNC CATALOG FAILED IN ZDLRA CATALOG AFTER PROTECTED DATABASE PATCHED TO 19.17
34879016;ALL SESSIONS HANG DUE TO INST_RCV BUFFER IS NOT GETTING WRITE PERMISSION
34972375;DATAPUMP BUNDLE PATCH 19.18.0.0.0
34988484;ORA-600 [KTUGETTEMPRSP NO TSO] EVEN WITH PATCH 34615905 APPLIED
35156936;ORA-7445 [KFFBNEW()+351]  AFTER CONVERT TO ASM FLEX DISKGROUP
35160800;GG IE FAILS WITH ORA-14400 AT SYSTEM.LOGMNRC_USER AFTER ORACLE DB UPGRADE TO 19.18DBRU
35162446;NEED BEHAVIOR CHANGE TO BE SWITCHED OFF
35213579;MERGE ON DATABASE RU 19.18.0.0.0 OF 35037877 35046819
35246710;HIGH DIRECT PATH READ AFTER 19.18 DBRU PATCHING
35320424;MRP INTERMITTENT HANG ON TWO STANDBY DATABASES REGR_FIX
35386601;MERGE ON DATABASE RU 19.18.0.0.0 OF 34997479 35242133
35471762;KZTDE KZTSMTKI ENCRYPTION WALLET LOCATION MESSAGES FLOODING ALERT LOG POST 19.18
35556847;MERGE ON DATABASE RU 19.18.0.0.0 OF 35527937 35412607

1

2

Suspensión del servicio

Antes de poder parchar el OH, obligatoriamente se tiene que  bajar la base de datos asociada.

SQL> shutdown immediate;

Parchado del Oracle Home

Se procede a aplicar los siguientes parches:

36233263 database release update 19.23.0.0.0
36199232 ojvm release update 19.23.0.0.0
36195566 jdk bundle patch 19.0.0.0.240416
36701173 database mrp 19.23.0.0.240618
36420641 datapump bundle patch 19.23.0.0.0
$ opatch lspatches

29585399;OCW RELEASE UPDATE 19.3.0.0.0 (29585399)
34982944;COMPRESS ADVANCED VALUES NOT CHANGED AFTER EXCHANGE PARTITION WITH INDEXES REFERENCES TO BUG 33829857
35077128;AIM ORA-600 [15709] - KXFPQSRLS DUE TO CPURM AND DEAD SESSIONS
35149201;DBMS_XSTREAM_ADM.ADD_SUBSET_OUTBOUND_RULES FAILS LRG FILTERING
36065162;ORA-7445 [QKAUAL_GET_SELEXP] WITH PIPELINED FUNCTION IN UNION ALL IN 19.20
36079489;Fix for Bug 36079489
36103892;Fix for Bug 36103892
36158909;DB HUNG WATING FOR LOG FILE SWITCH (CHECKPOINT INCOMPLETE)
36195566;JDK BUNDLE PATCH 19.0.0.0.240416
36199232;OJVM RELEASE UPDATE: 19.23.0.0.240416 (36199232)
36233263;Database Release Update : 19.23.0.0.240416 (36233263)
36261036;SPIN OFF -RCA-DATABASE HAS CURSOR  PIN S WAIT ON X CONTENTION AND CAUSED OUTAGE
36285197;ORA-04021  TIMEOUT OCCURRED WHILE WAITING TO LOCK OBJECT
36319353;WRONG FIX CONTROL ADDED BY JIAKLI_BUG-29413205
36343856;Fix for Bug 36343856
36391004;REVERT NZWLT_COMPAT_V11 FLAG TO CREATE 3DES BASED WALLET
36391038;ADD OPTION TO CREATE 3DES WALLET IN 19C AFTER CHANGE IN DEFAULT ENCRYPTION ALGORITHM
36420641;DATAPUMP BUNDLE PATCH 19.23.0.0.0
36480774;RECOVERY SIDE REVIEW OPENING THE DATABASE IS VERY SLOW
36530005;TRACKING BUG TO FIX LOST CHANGES FOR BUG 32872839 DUE TO CI TRANSACTION OF BUG 32195815
36587533;RESULT CACHE  GLOBAL FLUSH SHOULD ALWAYS CLEAR BYPASS FLAG EVEN IF THE RESULT CACHE IS UNINITIALIZED

3

4

Parchado de la base de datos

Ahora se prosigue con la actualización del catálogo de la base de datos, usando el utilitario datapatch.

SQL> startup;

$ datapatch -verbose

Situación final

Se tiene el OH actualizado y la base de datos operando normalmente.

5

Desventajas del parchado in-place

1. Mucho tiempo sin servicio

Ya que para aplicar un parche en un Oracle Home se debe bajar la base de datos, todo el tiempo que tome aplicarlo afecta la disponibilidad de los servicios.

En primer lugar hay que ejecutar la verificación de conflictos, luego de ello ejecutar un rollback de los parches que generan conflictos, para recién poder proceder a aplicar el parche nuevo.

Si algo sale mal hay que invertir tiempo en hacer troubleshooting o en iniciar el procedimiento de rollback total del parchado, que puede requerir de la restauración de todo el Oracle Home desde un backup generado con anticipación.

opatch prereq CheckConflictAgainstOHWithDetail
opatch nrollback -id 34810252,35213579,34557500
opatch apply /stage/RU1923
opatch napply /stage/MRU
opatch napply /stage/OneOffs

Por si esto fuera poco, conforme pasa el tiempo y se van aplicando más y más parches sobre el Oracle Home, se registra un incremento en el tiempo que toma aplicar cada nuevo parche.

A continuación el tiempo que registré en mi ambiente de pruebas, en el que solamente apliqué los Release Updates/RU (sin Monthly Recommended Patches/MRP o one-offs adicionales); se muestra tanto el tiempo que toma la verificación de conflictos (prereq), como el tiempo de aplicación en sí (apply):

Es evidente que el tiempo se va incrementando casi exponencialmente con la aplicación de un nuevo RU.

En la vida real, en instalaciones en las que periódicamente se aplica no solo RUs sino también MRPs y one-offs, aplicar un nuevo parche puede  llegar a tomar horas! y así lo reconoce Oracle Support:

While performing patching on 19c homes , opatch apply and opatch rollback commands are getting slower if the number of oneoff or RU patches is higher.
It may take beyond 2 hours as well to perform a single RU apply command .

2. Mucho espacio consumido

Por cada parche aplicado, Oracle debe obtener un respaldo de todos los objetos modificados, lo que le permite ejecutar un rollback a futuro, de ser requerido.

A continuación el espacio consumido que registré en mi ambiente de pruebas, en el que solamente apliqué los Release Updates/RU (sin Monthly Recommended Patches/MRP o one-offs adicionales):

El espacio consumido es proporcional a la cantidad de parches que se van aplicando, pasando de los originales 7GB con 19.3 a casi 32GB con 19.23.

Conclusiones

Tomando como referencia la encuesta efectuada por Tim Hall vía Twitter, y sin ser una fuente oficial o confiable, se puede asumir que una buena parte del parchado que ejecutan los DBAs de Oracle es in-place.

Si bien es quizás la modalidad más usada por los DBAs, el parchado in-place es por lejos ineficiente, sujeto a errores, ocupa mucho espacio en disco, y lo que es peor: presenta los tiempos de indisponibilidad del servicio más altos.

En el siguiente Post veremos a detalle la solución a este problema: el parchado out-of-place, así que estén atentos!

¿Te pareció interesante este artículo?, ¿te quedaron algunas dudas?, ¿quieres sugerirme un tema a tratar?, pues déjame tus comentarios o ¡contáctame ahora mismo!

Una respuesta

Agregue un comentario

Su dirección de correo no se hará público. Los campos requeridos están marcados *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

Posts Relacionados

Aprenda a descargar los parches de Oracle, tanto manualmente como de forma automatizada, usando el utilitario getMOSPatch.
Link a articulo publicado en Toad World, sobre como aplicar un patch out-of-place a Grid Infrastructure, usando un Golden Image.
Link a articulo publicado en Toad World, sobre como aplicar un patch out-of-place a Grid Infrastructure, en modalidad rolling.

¿Necesitas Ayuda?

Completa estos datos y estaré en contacto a la brevedad.