Während bei Debian cron-apt für die automatische Aktualisierung der Systeme sorgt, ist unter Oracle Linux yum-cron das passende Gegenstück.

Um (unabhängig von automatischen oder manuellen Aktualisierungen) die Menge der zu übertragenden Daten zu reduzieren, kann optional das Paket “deltarpm”

# yum install deltarpm

installiert werden.

Delta RPM packages contain the difference between an old and a new version of an RPM package. … The delta RPM packages are even smaller in size than patch RPMs, which is an advantage when transferring update packages over the Internet. The drawback is that update operations with delta RPMs involved consume considerably more CPU cycles than plain or patch RPMs. [Quelle]

Anschließend wird das Paket “yum-cron” installiert:

# yum install yum-cron

Nach Installation liegt die zugehörige Konfigurationsdatei “yum-cron.conf” im Verzeichnis “/etc/yum” und kann dort bearbeitet werden.

Hier kann z.B. über den Parameter

update_cmd = security

die Art der abzuhandelnden Aktualisierungen oder über den Parameter

apply_updates = yes

nicht nur das Herunterladen, sondern auch das automatische Einspielen aktiviert sowie verschiedene Benachrichtigungsoptionen konfiguriert werden.

Als letzter Schritt muß noch noch der Dienst aktiviert und gestartet werden:

# systemctl start yum-cron
# systemctl enable yum-cron

Als jemand, der überwiegend MySQL bzw. MariaDB als Datenbank verwendet, stolpere ich mehr oder minder regelmäßig über die Aufgabe, Oracle ein Datum mitzuteilen.

Als Workaround hilft ein

ALTER SESSION SET NLS_DATE_FORMAT='YYYY-MM-DD';

am Beginn der Session, dann funktionieren auch Angaben wie ‘2021-09-30’.

Beim Versuch eine Oracle-Datenbank zu patchen, hat OPatch den Prerequisite check mit der Fehlermeldung “CheckActiveFilesAndExecutables” abgebrochen:

Prerequisite check "CheckActiveFilesAndExecutables" failed.
The details are:
Following active files are not used by opatch process :
E:\pfad_zu_oracle\18.0.0\jdk\jre\bin\vcruntime140.dll

Der einfachste Weg, herauszufinden, welcher Prozess die Dateien aktuell benutzt ist “tasklist”:

E:\>tasklist -m vcruntime140.dll
Image Name                     PID Modules
========================= ======== ============================================
VGAuthService.exe             2232 VCRUNTIME140.dll

Leider bietet Windows keine Möglichkeit, einen Dienst anhand des Namens der ausführbaren Datei zu identifizieren. In den meisten Fällen kann aber aus dem Namen auf den Dienst geschlossen werden, hier von “VGAuthService.exe” auf den Dienst “VGAuthService”.

Nach dem Anhalten des Diensts

E:\>net stop VGAuthService
The VMware Alias Manager and Ticket Service service was stopped successfully.
E:\>tasklist -m vcruntime140.dll
INFO: No tasks are running which match the specified criteria.

lässt sich OPatch ohne weitere Probleme ausführen.

Wer Ursachenforschung betreiben möchte, sollte sich den Pfad des betroffenen Systems genauer ansehen. Mit großer Wahrscheinlichkeit hat sich Oracle am Anfang des Pfads verewigt, so daß DLLs aus dem Oracle-Verzeichnis statt der ursprünglich bei der Installation mitgelieferten DLLs verwendet werden.

Während des Einspielens von Critical Patch Updates benötigt OPatch zum Sichern der zu aktualisierenden Module reichlich Festplattenplatz, so daß es passieren kann, daß während des Einspielvorgangs nicht mehr genügend Plattenplatz zur Verfügung steht.

Mit dem Howto ID 550522.1 “How To Avoid Disk Full Issues Because OPatch Backups Take Big Amount Of Disk Space.” gibt Oracle gezielte Hinweise, wie im Falle des Falles zu verfahren ist und weist auch auf die “util”-Funktion von OPatch hin.

$ opatch util cleanup

räumt auf und löscht alle Daten des “$ORACLE_HOME/.patch_storage”-Verzeichnisses, die nicht für einen Rollback von Interim-Patches notwendig sind.

Wenn Oracle der Platz zum Speichern der Redo-Logs ausgeht, kommt es zu einem sog. Archiver Stuck.

Reicht auch das Löschen des vom Admin meist in weiser Voraussicht angelegten Dummy-Files nicht, so kann der Speicherort für die Logs kurzfristig umgebogen werden:

ALTER SYSTEM ARCHIVE LOG STOP;
ALTER SYSTEM SET LOG_ARCHIVE_DEST='woauchimmer';
ALTER SYSTEM ARCHIVE LOG START;

Anschließend können die alten Logs in Ruhe in Sicherheit gebracht und Platz geschaffen werden, bevor mit obiger Befehlsfolge der Speicherort wieder auf das ursprüngliche Ziel zurückgestellt wird.

Wer genauere Infos zum aktuellen Status seiner Archive-Logs erhalten will, kann sich diese mit dem Befehl

ARCHIVE LOG LIST

beschaffen. Eine ausführliche Abhandlung zum Thema “Managing Archived Redo Logs” gibt’s im Oracle Database Administrator’s Guide.