Schlagwort: Oracle

ORA-01861: literal does not match format string

· · 0 Kommentare

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'.


OPatch meldet Prerequisite check "CheckActiveFilesAndExecutables" failed

· · 0 Kommentare

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.


Plattenplatz beim Ausführen von OPatch

· · 0 Kommentare

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.


Oracle Archiver-Stuck beheben

· · 0 Kommentare

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.


Oracle Database recovery

· · 0 Kommentare

Stellt sich Oracle beim Datenbank-Recovery etwas umständlich an, so muß man etwas tiefer in die Trickkiste greifen:

Erfahrungsgemäß läuft ein

RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;

meist damit gegen die Wand, daß Oracle versucht, auf ein nicht existierendes, archiviertes Logfile zuzugreifen. Ergebnis sind in der Regel der Fehler

ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '<woauchimmer>system01.dbf'

was aber nicht unbedingt bedeutet, daß sich das Problem tatsächlich auf die eine Datei beschränkt.

Sollte dies der Fall sein, muß für ein erfolgreiches Recovery noch das aktuelle Redo-Log verwendet werden. Hierzu ist zuerst das aktuelle Log zu ermitteln

SELECT member FROM v$logfile , v$log WHERE v$log.status='CURRENT' AND v$logfile.group# = v$log.group#;

anschließend nochmals ein Recovery zu starten, hierbei allerdings weder 'AUTO' noch 'CANCEL' zu wählen sondern das soeben ermittelte Logfile anzugeben.

RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;

Hat alles geklappt, sollte ein

ALTER DATABASE OPEN RESETLOGS;

zum gewünschten Erfolg führen.