Probleme nach dem Löschen von DIAGNOSTIC_DEST
Um am Datenbankserver die Filesysteme aufzuräumen, wird sehr oft einfach die DIAGNOSTIC_DEST mit einem
$ rm -rf {ADR_BASE}/diag
gelöscht. Bis zur Version 11.2 stellt das auch kein Problem dar. Die Verzeichnisstruktur wird mit dem Neustart von Oracle einfach wieder angelegt.
Mit dem Upgrade der auf 12c hat sich das aber für CRS, ASM und RAC geändert.
Es wird zwar die Verzeichnisstruktur wieder angelegt, dennoch kommt es zu unterschiedlichen Fehlermeldungen, und der Cluster Stack startet nicht.
In diesem Fall bleibt der Startprozess bei ora.chad hängen und das Kommando crsctl meldet sich mit einer Fehlermeldung (hier sogar mit einem brauchbaren Hinweis zur Ursache):
[oracle@srvdb12cr201 ~]$ crsctl stat res -t
Oracle Clusterware infrastructure error in CRSCTL (OS PID 15361): CLSD/ADR initialization failed with return value -1
1: clskec:has:CLSU:910 4 args[clsdAdrInit_CLSK_err][mod=clsdadr.c][loc=(:CLSD00281:)][msg=clsdAdrInit: Additional diagnostic data returned by the ADR component for dbgc_init_all failure:
DIA-49802: missing read, write, or execute permission on specified ADR home directory [/oracle/gridBASE/diag/crs/srvdb12cr201]
DIA-49801: actual permissions [rwxr-xr-x], expected minimum permissions [rwxrwxrwx] for effective user [oracle]
DIA-48188: user missing read, write, or exec permission on specified directory
Linux-x86_64 Error: 13: Permission denied
Additional information: 2
Additional information: 511
Additional information: 16877
([all diagnostic data retrieved from ADR])]
2: clskec:has:CLSU:910 4 args[clsdAdrInit_CLSK_err][mod=clsdadr.c][loc=(:CLSD00050:)][msg=clsdAdrInit: call to dbgc_init_all failed. facility:[CRS] product:[CRS] line number:[1422] return code: [ORA-49802] Oracle Base: [/oracle/gridBASE] Product Type: [CRS] Host Name: [srvdb12cr201] Instance ID: [crs_oracle] User Name: [oracle]]
--------------------------------------------------------------------------------
Name Target State Server State details
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.ASMNET1LSNR_ASM.lsnr
ONLINE ONLINE srvdb12cr201 STABLE
ONLINE ONLINE srvdb12cr202 STABLE
ora.CRS1DG.dg
ONLINE ONLINE srvdb12cr201 STABLE
ONLINE ONLINE srvdb12cr202 STABLE
ora.DATA_DB12CR2.dg
ONLINE ONLINE srvdb12cr201 STABLE
OFFLINE OFFLINE srvdb12cr202 STABLE
ora.LISTENER.lsnr
ONLINE ONLINE srvdb12cr201 STABLE
ONLINE ONLINE srvdb12cr202 STABLE
ora.chad
ONLINE OFFLINE srvdb12cr201 STARTING
ONLINE OFFLINE srvdb12cr202 STARTING
ora.net1.network
ONLINE ONLINE srvdb12cr201 STABLE
ONLINE ONLINE srvdb12cr202 STABLE
ora.ons
ONLINE ONLINE srvdb12cr201 STABLE
ONLINE ONLINE srvdb12cr202 STABLE
ora.proxy_advm
OFFLINE OFFLINE srvdb12cr201 STABLE
OFFLINE OFFLINE srvdb12cr202 STABLE
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.LISTENER_SCAN1.lsnr
1 ONLINE ONLINE srvdb12cr202 STABLE
ora.LISTENER_SCAN2.lsnr
1 ONLINE ONLINE srvdb12cr201 STABLE
ora.LISTENER_SCAN3.lsnr
1 ONLINE ONLINE srvdb12cr201 STABLE
ora.MGMTLSNR
1 ONLINE ONLINE srvdb12cr201 192.168.0.7 10.7.7
.20,STABLE
ora.asm
1 ONLINE ONLINE srvdb12cr201 Started,STABLE
2 ONLINE ONLINE srvdb12cr202 Started,STABLE
3 OFFLINE OFFLINE STABLE
ora.cvu
1 ONLINE ONLINE srvdb12cr201 STABLE
ora.mgmtdb
1 ONLINE ONLINE srvdb12cr201 Open,STABLE
ora.qosmserver
1 ONLINE ONLINE srvdb12cr201 STABLE
ora.scan1.vip
1 ONLINE ONLINE srvdb12cr202 STABLE
ora.scan2.vip
1 ONLINE ONLINE srvdb12cr201 STABLE
ora.scan3.vip
1 ONLINE ONLINE srvdb12cr201 STABLE
ora.srvdb12cr201.vip
1 ONLINE ONLINE srvdb12cr201 STABLE
ora.srvdb12cr202.vip
1 ONLINE ONLINE srvdb12cr202 STABLE
--------------------------------------------------------------------------------
Ursache
Beim Starten des GI Stacks werden viele der Verzeichnise der $ORACLE_BASE/diag mit dem OS Owner root:system angelegt und können deshalb mit den Prozessen, die als Grid Owner laufen, nicht mehr beschrieben werden. Das ganze firmiert unter dem Bug 20371168, beschrieben in Oracle Note Problems When Removing DIAGNOSTIC_DEST in 12c (Doc ID 1994539.1).
Workaround
Die Lösung dafür ist einfach die Ownership und Berechtigungen entsprechend manuell zu korrigieren.
$ chown -R grid:oinstall $ORACLE_BASE/diag
$ chmod -R 775 $ORACLE_BASE
Wird die GI mit dem User oracle und der Gruppe dba installiert, ist das natürlich entsprechend anzupassen:
$ chown -R oracle:dba $ORACLE_BASE/diag
$ chmod -R 775 $ORACLE_BASE