DBCA: Registrieren einer neuen Datenbank im OEM Cloud Control beim Anlegen einer Datenbank

Zu diesem Thema habe ich in meinem englischsprachigen Blog einen Beitrag veröffentlicht: siehe hier. (Die Übersetzung spare ich mir in diesem Fall 🙂 )

Veröffentlicht unter Allgemein | Hinterlasse einen Kommentar

Oracle Critical Patch Update April 2019 – Statistik-Update

Gesamtzahl der Patches pro CPU

Mittelwert Patches pro betroffenem Produkt

Anzahl Datenbank-Patches pro CPU

.. hier hat sich die Anzahl der DB-Patches (6) im Vergleich zu den letzten CPUs (3) verdoppelt

Die Datenbank im Vergleich zum „Durchschnittsprodukt“ – Anzahl Patches pro CPU

.. auch im Vergleich zum Mittelwert zeigt die Datenbank einen deutlichen Ausreißer nach oben

CVSS-Score der Datenbank-Patches (bzw. Bugs) – Maximum und Mittelwert

Gesamtübersicht

Quelle: https://www.oracle.com/technetwork/topics/security/alerts-086861.html

P.S.: Mit Erschrecken habe ich festgestellt, dass ich seit Januar nichts im Blog gepostet habe – ich hoffe, dass wird in den nächsten Wochen wieder anders 🙂

Veröffentlicht unter Allgemein | Hinterlasse einen Kommentar

Oracle Critical Patch Update Januar 2019 – der Statistik-Post

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

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

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) beschrieben).

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

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
Pages: 1 2 3 4 5 6 7 8 9 10 ... 23 24 25 Next