Oracle Critical Patch Update Januar 2019 – der Statistik-Post

Publiziert am 16. Januar 2019 von Markus Flechtner

Vor einem Jahr habe ich angefangen, etwas Statistik zu den quartalsmäßigen Critical Patch Updates (CPU) von Oracle zu veröffentlichen. Der CPU Januar 2019, der gestern veröffentlicht wurde, ist dann natürlich Grund genug, diese Serie auch im Jahr 2019 fortzusetzen.

Weiterlesen →
Veröffentlicht unter Allgemein | Kommentare deaktiviert für Oracle Critical Patch Update Januar 2019 – der Statistik-Post

Datei-Eigentümer nach dem Patchen oder Re-Linken der Oracle RDBMS-Software

Publiziert am 26. Dezember 2018 von Markus Flechtner

Vor einiger Zeit habe ich beim Patchen von RDBMS-Software beim Kunden die Warnung „chmod: change permissions of’/u00/app/oracle/product/11.2.0.4/bin/extjobO‘: Operation not permitted“ bekommen. Ich habe daher mal ein bisschen recherchiert, was mit den Dateiberechtigungen und dem Eigentum beim Patchen oder Re-Linken von Oracle RDBMS-Software passiert.

English translation of this post on www.markusdba.net

Vor einiger Zeit habe ich beim Patchen von RDBMS-Software beim Kunden die Warnung „chmod: change permissions of’/u00/app/oracle/product/11.2.0.4/bin/extjobO‘: Operation not permitted“ bekommen. Ich habe daher mal ein bisschen recherchiert, was mit den Dateiberechtigungen und dem Eigentum beim Patchen oder Re-Linken von Oracle RDBMS-Software passiert.

Wie wir alle wissen, müssen die Berechtigungen einiger Oracle-Executables unter Linux/Unix nach der Installation geändert werden. Dies geschieht mit Hilfe von „root.sh“.

Nach einer Neuinstallation und dem Ausführen von root.sh (Oracle 18c – 18.3 unter Linux) sieht $ORACLE_HOME/bin so aus:

oracle@oramaster18:/u00/app/oracle/product/18.0.0.0/bin/ [rdbms18000] ls -l |grep root
-rwxr-xr-x. 1 oracle oinstall       945 Jun 20  2016 acfsroot
-rwxr-xr-x. 1 oracle oinstall      1000 Jun 20  2016 afdroot
-rwsr-x---. 1 root   oinstall   2580328 Oct  2 09:17 extjob
-rwsr-x---. 1 root   oinstall   2366584 Oct  2 09:17 jssu
-rwxr-xr-x. 1 oracle oinstall       940 Jun 20  2016 okaroot
-rwxr-xr-x. 1 oracle oinstall      1007 Jun 20  2016 olfsroot
-rwsr-x---. 1 root   oinstall     98210 Feb  7  2018 oradism
-rwx------. 1 oracle oinstall      2139 Sep 19  2017 rootPreRequired.sh

==> „root“ ist jetzt Eigentümer von extjob, jssu und oradism

Was passiert, wenn wir einen Patch einspielen?

Nach dem Einspielen des Patches 28655784 (Database RU 18.4) haben sich die Berechtigungen geändert:

oracle@oramaster18:/u00/app/oracle/product/18.0.0.0/bin/ [rdbms18000] ls -l |grep root
-rwxr-xr-x. 1 oracle oinstall       945 Jun 20  2016 acfsroot
-rwxr-xr-x. 1 oracle oinstall      1000 Jun 20  2016 afdroot
-rwsr-x---. 1 root   oinstall   2366584 Oct  2 09:17 jssu
-rwxr-xr-x. 1 oracle oinstall       940 Jun 20  2016 okaroot
-rwxr-xr-x. 1 oracle oinstall      1007 Jun 20  2016 olfsroot
-rwsr-x---. 1 root   oinstall     98210 Feb  7  2018 oradism
-rwx------. 1 oracle oinstall      2139 Sep 19  2017 rootPreRequired.sh
oracle@oramaster18:/u00/app/oracle/product/18.0.0.0/bin/ [rdbms18000] ls -l extjob
-rwxr-xr-x. 1 oracle oinstall 2580328 Nov 18 11:48 extjob

==> Genauer gesagt: nur bei „extjob“ hat sich etwas geändert. Die Datei gehört jetzt „oracle“ und nicht mehr „root“.

Da externe Jobs selten verwendet werden (mein persönlicher Eindruck) sind die meisten Benutzer von diesem Problem nicht betroffen. Aber um sicher zu sein, dass die Rechte korrekt sind, halte ich es für eine gute Idee, root.sh nach dem Einspielen eines Patches erneut auszuführen (dies ist ein nicht dokumentierter Schritt nach der Patch-Installation und wahrscheinlich auch nicht für alle Patches erforderlich).

oracle@oramaster18:/u00/app/oracle/product/18.0.0.0/bin/ [rdbms18000] cd ..
oracle@oramaster18:/u00/app/oracle/product/18.0.0.0/ [rdbms18000] su
Password:
root@oramaster18:/u00/app/oracle/product/18.0.0.0/ [rdbms18000] ./root.sh
Check /u00/app/oracle/product/18.0.0.0/install/root_oramaster18.markusdba.local_2018-11-18_11-51-41-270759279.log for the output of root script
root@oramaster18:/u00/app/oracle/product/18.0.0.0/ [rdbms18000] exit
exit
oracle@oramaster18:/u00/app/oracle/product/18.0.0.0/ [rdbms18000] cd bin
/u00/app/oracle/product/18.0.0.0/bin
oracle@oramaster18:/u00/app/oracle/product/18.0.0.0/bin/ [rdbms18000] ls -l |grep root
-rwxr-xr-x. 1 oracle oinstall       945 Jun 20  2016 acfsroot
-rwxr-xr-x. 1 oracle oinstall      1000 Jun 20  2016 afdroot
-rwsr-x---. 1 root   oinstall   2580328 Nov 18 11:48 extjob
-rwsr-x---. 1 root   oinstall   2366584 Oct  2 09:17 jssu
-rwxr-xr-x. 1 oracle oinstall       940 Jun 20  2016 okaroot
-rwxr-xr-x. 1 oracle oinstall      1007 Jun 20  2016 olfsroot
-rwsr-x---. 1 root   oinstall     98210 Feb  7  2018 oradism
-rwx------. 1 oracle oinstall      2139 Sep 19  2017 rootPreRequired.sh

Was passiert bei einem Relink der RDBMS-Software?

oracle@oramaster18:/u00/app/oracle/product/18.0.0.0/bin/ [rdbms18000] relink all
writing relink log to: /u00/app/oracle/homes/OraDB18Home1/install/relink_2018-11-18_11-52-23AM.log
oracle@oramaster18:/u00/app/oracle/product/18.0.0.0/bin/ [rdbms18000] ls -l |grep root
-rwxr-xr-x. 1 oracle oinstall 945 Jun 20 2016 acfsroot
-rwxr-xr-x. 1 oracle oinstall 1000 Jun 20 2016 afdroot
-rwxr-xr-x. 1 oracle oinstall 940 Jun 20 2016 okaroot
-rwxr-xr-x. 1 oracle oinstall 1007 Jun 20 2016 olfsroot
-rwsr-x---. 1 root oinstall 98210 Feb 7 2018 oradism
-rwx------. 1 oracle oinstall 2139 Sep 19 2017 rootPreRequired.sh
oracle@oramaster18:/u00/app/oracle/product/18.0.0.0/bin/ [rdbms18000] ls -l extjob
-rwxr-xr-x. 1 oracle oinstall 2580328 Nov 18 11:52 extjob

Es ist also sinnvoll, root.sh erneut auszuführen, damit diese Dateien den korrekten Eigentümer bekommen (dies ist in MOS-Note „Executing “relink all” resets permission of extjob, jssu, oradism, externaljob.ora (Doc ID 1555453.1).

oracle@oramaster18:/u00/app/oracle/product/18.0.0.0/bin/ [rdbms18000] su
Password:
root@oramaster18:/u00/app/oracle/product/18.0.0.0/bin/ [rdbms18000] cd ..
root@oramaster18:/u00/app/oracle/product/18.0.0.0/ [rdbms18000] ./root.sh
Check /u00/app/oracle/product/18.0.0.0/install/root_oramaster18.markusdba.local_2018-11-18_11-56-04-603314902.log for the output of root script
root@oramaster18:/u00/app/oracle/product/18.0.0.0/ [rdbms18000] exit
exit
oracle@oramaster18:/u00/app/oracle/product/18.0.0.0/bin/ [rdbms18000] ls -l extjob
-rwsr-x---. 1 root oinstall 2580328 Nov 18 11:52 extjob

Zusammenfassung:
Obwohl es nicht dokumentiert ist, halte ich es für eine gute Idee, root.sh nach dem Patchen auszuführen (oder zumindest den Eigentümer der betreffenden Dateien zu überprüfen). Beim Relinken der RDBMS-Software (z.B. nach einem Kernel-Update) ist die anschließende Ausführung von „root.sh“ ein Muss (IMHO).

MOS-Notes

  • What Are Root.sh And OrainstRoot.sh Scripts In A Standalone RDBMS Installation? (Doc ID 1493121.1)
  • Why are files under $ORACLE_HOME owned by root user? (Doc ID 461144.1)
  • Executing “relink all” resets permission of extjob, jssu, oradism, externaljob.ora (Doc ID 1555453.1)
  • Relinking Oracle Home FAQ ( Frequently Asked Questions) (Doc ID 1467060.1)
Veröffentlicht unter Allgemein | Kommentare deaktiviert für Datei-Eigentümer nach dem Patchen oder Re-Linken der Oracle RDBMS-Software

„Privilege Analysis“ jetzt „frei“ in der Enterprise Edition der Oracle Datenbank verfügbar

Publiziert am 25. November 2018 von Markus Flechtner

Vor wenigen Tagen hat Oracle die Lizenzbedingungen für „Privilege Analysis“ verändert. Diese Funktionalität, die mit Oracle 12c herauskam, setzte ursprünglich eine Lizenz für „Database Vault“ voraus. Diese Einschränkung wurde fallengelassen, so dass „Privilege Analysis“ jetzt allen Kunden der Enterprise Edition der Oracle Datenbank zur Verfügung steht.

Weiterlesen →

Veröffentlicht unter Oracle 18c | Kommentare deaktiviert für „Privilege Analysis“ jetzt „frei“ in der Enterprise Edition der Oracle Datenbank verfügbar

Oracle 18c Express Edition – eine zweite Datenbank anlegen

Publiziert am 23. November 2018 von Markus Flechtner

Nicht alles, was technisch möglich ist, ist auch erlaubt. Und so gilt natürlich für die Oracle Datenbank 18c Express Edition ganz klar die Einschränkung. „One instance per environment“, wobei Environment eine VM, eine physikalischer Server etc. sein. Aber vielleicht kann man ja doch zwei XE-Datenbanken auf einem Server betreiben. Probieren wir das doch mal aus.

Weiterlesen →

Veröffentlicht unter Allgemein, Oracle 18c | Kommentare deaktiviert für Oracle 18c Express Edition – eine zweite Datenbank anlegen

Oracle 12.2, 18c, 19c – was denn nun?

Publiziert am 6. November 2018 von Markus Flechtner

Kunden suchen New-Features Kurse zu Oracle-Datenbank-Version 18c; Datenbankadministratoren, die früher ohne mit der Wimper zu zucken ihre Produktionssysteme von Oracle 11.2.0.2 auf 11.2.0.4 gebracht haben, zögern: nehme ich besser Oracle 12.1, 12.2, 18c oder warte ich auf Oracle 19c? Der neue Release-Zyklus von Oracle hat durchaus für Verwirrung gesorgt. Bringen wir doch mal etwas Licht in dieses Versions(nummern)dunkel.

Weiterlesen →

Veröffentlicht unter Allgemein, O-NF12C-DBA | Verschlagwortet mit , , | Kommentare deaktiviert für Oracle 12.2, 18c, 19c – was denn nun?
Pages: 1 2 3 4 5 6 7 8 9 10 ... 22 23 24 Next