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 patch | También conocido como one-off. Sirven para resolver problemas específicos, usualmente de forma reactiva. |
| Merge patch | Se 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 |
$ 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 UNINITIALIZED3
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 -verboseSituación final
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/OneOffsPor 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.
Una respuesta
Didáctico, me gusto. Gracias por compartirnos información!!!