Me encontraba en plena configuración de unos Clusters Oracle 19c para un proyecto de upgrade de Oracle Database Server 11.2 a 19c, cuando al reiniciar uno de los computadores (node2) me percato que los servicios no estaban disponibles, sin razón aparente, ya que este Cluster en particular venía operando normalmente por varias semanas.
El problema
Como parte de los trabajos para copiar usuarios y grupos de Linux desde los Clusters 11.2 hacia estos nuevos Clusters 19c, por accidente se ejecutó una tarea que empezó a modificar el propietario y grupo de los archivos del filesystem /u01, en el que residen todos los binarios de Oracle Grid y Oracle Database Server.
Si bien el proceso fue cancelado casi de inmediato, el daño ya estaba hecho: los contenidos del Oracle Home de Grid 19c, así como los contenidos del Oracle Home de Oracle Database Server 19c y 11.2 estaban alterados y con ello el software Oracle quedó inoperativo.
[oracle@node2 ~]$ ls -la /u01/app/
total 4
drwxr-xr-x. 5 root oinstall 52 Aug 24 12:46 .
drwxr-xr-x. 3 root oinstall 17 Aug 24 12:35 ..
drwxr-xr-x. 3 haldaemon haldaemon 20 Aug 24 12:35 grid
drwxr-xr-x. 13 oracle oinstall 4096 Aug 25 20:07 oracle
drwxrwx---. 5 oracle oinstall 92 Sep 28 11:25 oraInventory
[oracle@node2 ~]$ ls -la /u01/app/oracle
total 8
drwxr-xr-x. 13 oracle oinstall 4096 Aug 25 20:07 .
drwxr-xr-x. 5 root oinstall 52 Aug 24 12:46 ..
drwxr-xr-x. 3 haldaemon haldaemon 18 Aug 24 16:50 11.2.0
drwxr-xr-x. 3 haldaemon haldaemon 18 Aug 24 12:35 19.0.0
drwxr-xr-x. 5 oracle oinstall 45 Aug 24 19:14 admin
drwxr-x---. 3 oracle oinstall 21 Aug 24 18:34 audit
drwxrwxr-x. 6 oracle oinstall 60 Aug 24 18:12 cfgtoollogs
[oracle@node2 ~]$ crsctl check crs
CRS-4638: Oracle High Availability Services is online
CRS-4535: Cannot communicate with Cluster Ready Services
CRS-4530: Communications failure contacting Cluster Synchronization Services daemon
CRS-4534: Cannot communicate with Event ManagerPrimer intento
Buscando en My Oracle Support se encuentra este documento:
| 1931142.1 | How to check and fix file permissions on Grid Infrastructure environment |
[root@node2 ~]# crsctl stop crs -f
CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on 'node2'
CRS-2673: Attempting to stop 'ora.drivers.acfs' on 'node2'
CRS-2677: Stop of 'ora.drivers.acfs' on 'node2' succeeded
CRS-2793: Shutdown of Oracle High Availability Services-managed resources on 'node2' has completed
CRS-4133: Oracle High Availability Services has been stopped.
[root@node2 ~]# chown -R oracle:oinstall /u01/app
[root@node2 ~]# cd $ORACLE_HOME/crs/install/
[root@node2 install]# ./rootcrs.sh -init
Smartmatch is deprecated at /u01/app/grid/19.0.0/grid_1/crs/install/crsupgrade.pm line 6512.
Using configuration parameter file: /u01/app/grid/19.0.0/grid_1/crs/install/crsconfig_params
The log of current session can be found at:
/u01/app/oracle/crsdata/node2/crsconfig/crsinit_node2_2024-09-26_03-45-33PM.logProcedemos a validar el estado del Oracle Home de Grid:
[oracle@node2 ~]$ cluvfy comp software -n node2 -verbose
This software is "184" days old. It is a best practice to update the CRS home by downloading and applying the latest release update. Refer to MOS note 756671.1 for more details.
Performing following verification checks ...
Software home: /u01/app/grid/19.0.0/grid_1 ...
Node Name Status Comment
------------ ------------------------ ------------------------
node2 failed 1256 files verified
Software home: /u01/app/grid/19.0.0/grid_1 ...FAILED (PRVG-2031, PRVG-11960, PRVH-0147)
Verification of software was unsuccessful on all the specified nodes.
Failures were encountered during execution of CVU verification request "software".
Software home: /u01/app/grid/19.0.0/grid_1 ...FAILED
node2: PRVG-2031 : Owner of file
"/u01/app/grid/19.0.0/grid_1/lib/liboramysql19.so" did not match the
expected value on node "node2". [Expected = "root(0)" ; Found =
"oracle(54321)"]
node2: PRVG-2031 : Owner of file "/u01/app/grid/19.0.0/grid_1/bin/expdp" did
not match the expected value on node "node2". [Expected = "root(0)" ;
Found = "oracle(54321)"]
node2: PRVG-2031 : Owner of file "/u01/app/grid/19.0.0/grid_1/bin/sqlldr" did
not match the expected value on node "node2". [Expected = "root(0)" ;
Found = "oracle(54321)"]
. . .
node2: PRVG-2031 : Owner of file "/u01/app/grid/19.0.0/grid_1/bin/okdstry" did
not match the expected value on node "node2". [Expected = "root(0)" ;
Found = "oracle(54321)"]
node2: PRVG-2031 : Owner of file "/u01/app/grid/19.0.0/grid_1/bin/okinit" did
not match the expected value on node "node2". [Expected = "root(0)" ;
Found = "oracle(54321)"]
node2: PRVG-2031 : Owner of file "/u01/app/grid/19.0.0/grid_1/bin/oklist" did
not match the expected value on node "node2". [Expected = "root(0)" ;
Found = "oracle(54321)"]
node2: PRVG-2031 : Owner of file
"/u01/app/grid/19.0.0/grid_1/bin/oradaemonagent" did not match the
expected value on node "node2". [Expected = "root(0)" ; Found =
"oracle(54321)"]La misma nota indica que si la ejecución de rootcrs.sh -init es insuficiente, se debe recurrir a un cambio manual apoyándose con la información contenida en los archivo crsconfig_fileperms y crsconfig_dirs, pero eso resulta largo y sujeto a errores.
Afortunadamente en My Oracle Support existe este documento:
| 1515018.1 | Script to capture and restore file permission in a directory (for eg. ORACLE_HOME) |
En la nota se indica que el primer paso es descargar un programa en Perl, llamado permission.pl.
Este programa requiere como único parámetro el directorio que deseamos procesar, y como resultado generará un archivo con los comandos de Linux para reconstruir el propietario, grupo y permisos de todos y cada uno de los archivos de ese directorio!
Parece ser la solución definitiva, ¿pero será cierto? Veamos.
Segundo intento
[root@node1 ~]# ./permission.pl /u01/app
Following log files are generated
logfile : permission-Thu-Sep-26-16-58-50-2024
Command file : restore-perm-Thu-Sep-26-16-58-50-2024.cmd
Linecount : 147029Culminó en menos de 10 segundos y el archivo «.cmd» efectivamente contiene los comandos prometidos.
[root@node1 ~]# more restore-perm-Thu-Sep-26-16-58-50-2024.cmd
chown root:oinstall "/u01/app"
chmod 755 "/u01/app"
chown root:oinstall "/u01/app/grid"
chmod 755 "/u01/app/grid"
chown root:oinstall "/u01/app/grid/19.0.0"
chmod 755 "/u01/app/grid/19.0.0"
chown root:oinstall "/u01/app/grid/19.0.0/grid_1"
chmod 755 "/u01/app/grid/19.0.0/grid_1"
chown oracle:oinstall "/u01/app/grid/19.0.0/grid_1/env.ora"
chmod 644 "/u01/app/grid/19.0.0/grid_1/env.ora"
chown root:oinstall "/u01/app/grid/19.0.0/grid_1/root.sh"
chmod 755 "/u01/app/grid/19.0.0/grid_1/root.sh"
chown oracle:oinstall "/u01/app/grid/19.0.0/grid_1/welcome.html"
chmod 640 "/u01/app/grid/19.0.0/grid_1/welcome.html"
chown oracle:oinstall "/u01/app/grid/19.0.0/grid_1/gridSetup.sh"
chmod 750 "/u01/app/grid/19.0.0/grid_1/gridSetup.sh"
chown oracle:oinstall "/u01/app/grid/19.0.0/grid_1/runcluvfy.sh"
chmod 750 "/u01/app/grid/19.0.0/grid_1/runcluvfy.sh"
chown oracle:oinstall "/u01/app/grid/19.0.0/grid_1/gridSetup.rsp"
chmod 644 "/u01/app/grid/19.0.0/grid_1/gridSetup.rsp"Copiamos el archivo al computador afectado, pero debemos tomar en cuenta que el nombre del computador y el nombre de la instancia ASM son distintos, por los que debemos adecuarlos en el script antes de ejecutarlo.
[root@node1 ~]# sed -i 's/ASM1/ASM2/g' restore-perm-Thu-Sep-26-16-58-50-2024.cmd
[root@node1 ~]# sed -i 's/asm1/asm2/g' restore-perm-Thu-Sep-26-16-58-50-2024.cmd
[root@node1 ~]# sed -i 's/node1/node2/g' restore-perm-Thu-Sep-26-16-58-50-2024.cmd
[root@node1 ~]# sh restore-perm-Thu-Sep-26-16-58-50-2024.cmd
chown: cannot access ‘/u01/app/grid/19.0.0/grid_1/gpnp/gpnp_bcp__2024_8_24_175252’: No such file or directory
chmod: cannot access ‘/u01/app/grid/19.0.0/grid_1/gpnp/gpnp_bcp__2024_8_24_175252’: No such file or directory
chown: cannot access ‘/u01/app/grid/19.0.0/grid_1/gpnp/gpnp_bcp__2024_8_24_175252/stg__node2’: No such file or directory
chmod: cannot access ‘/u01/app/grid/19.0.0/grid_1/gpnp/gpnp_bcp__2024_8_24_175252/stg__node2’: No such file or directory
. . .
chmod: cannot access ‘/u01/app/grid/19.0.0/grid_1/cfgtoollogs/oui/GridSetupActions2024-08-24_05-56-29PM/time2024-08-24_05-56-29PM.log’: No such file or directory
chown: cannot access ‘/u01/app/grid/19.0.0/grid_1/crf/admin/run/crfmond/snode2.pid’: No such file or directory
chmod: cannot access ‘/u01/app/grid/19.0.0/grid_1/crf/admin/run/crfmond/snode2.pid’: No such file or directoryLuego de algunos minutos, finalmente culmina. Si bien se muestran varios mensajes de error, pueden ser ignorados por cuanto se tratan de archivos de logs y traces, que no afectan la operación del software Oracle.
Procedemos a validar nuevamente el estado del Oracle Home de Grid:
[oracle@node2 ~]$ cluvfy comp software -n node2 -verbose
This software is "184" days old. It is a best practice to update the CRS home by downloading and applying the latest release update. Refer to MOS note 756671.1 for more details.
Performing following verification checks ...
Software home: /u01/app/grid/19.0.0/grid_1 ...
Node Name Status Comment
------------ ------------------------ ------------------------
node2 passed 1256 files verified
Software home: /u01/app/grid/19.0.0/grid_1 ...PASSED
Verification of software was successful.
CVU operation performed: software
Date: Sep 26, 2024 17:15:11 PM
CVU version: 19.23.0.0.0 (032824x8664)
Clusterware version: 19.0.0.0.0
CVU home: /u01/app/grid/19.0.0/grid_1
Grid home: /u01/app/grid/19.0.0/grid_1
User: oracle
Operating system: Linux5.4.17-2136.330.7.1.el7uek.x86_64
Excelente! Todo parece estar en orden, pero la prueba de fuego es ver si inicia el Clusterware y si levantan las bases de datos dbrac (Oracle Database 11.2) y orcl (Oracle Database 19c).
[root@node2 ~]# crsctl start crs
CRS-4123: Oracle High Availability Services has been started.
[root@node2 ~]# crsctl check crs
CRS-4638: Oracle High Availability Services is online
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online
[root@node2 ~]# olsnodes -s
node1 Active
node2 Active
node3 Active
[root@node2 ~]# ps -ef | grep pmon
oracle 16125 1 0 17:24 ? 00:00:00 asm_pmon_+ASM2
oracle 16380 1 0 17:24 ? 00:00:00 ora_pmon_dbrac1_2
oracle 16503 1 0 17:24 ? 00:00:00 ora_pmon_orcl1_2Confirmado: todo opera normalmente y podemos dar el caso por cerrado y continuar con la agenda de tareas del día.
Sí que nos dimos un susto, pero afortunadamente se encontró una solución que nos evitó tener que reinstalar el software, que dicho sea de paso no es algo tan complicado si estás acostumbrado a usar Golden Images.
¿Que no sabes qué son? Pues, ¡qué esperas para aprender sobre el tema! Tengo toda una serie de artículos que puedes empezar a leer ahora mismo.