Neue Aufräum-Routine für inaktive Patches in opatch

Wer kennt es nicht – man installiert ein ORACLE_HOME und installiert den aktuellen RU, ggfs. auch OJVM-Patch. Als braver DBA aktualisiert man regelmäßig, und schwuppdiewupp hat man einige (Dutzend) GB im Verzeichnis $ORACLE_HOME/.patchstorage… Das kostet nicht nur viel Platz, sondern auch immer mehr Zeit z.B. bei der Ausführung von datapatch, weshalb Oracle auch inzwischen empfiehlt, Out-of-Place zu patchen. Aber dann wiederum muss man den Platz für das neue Home bereitstellen, ggfs. Skripte anpassen usw… und alles nur, weil teilweise steinalte Patches immer noch für den Fall eines Rollbacks im .patchstorage-Ordner „für gut verwahrt“ werden.

Weiterlesen

Upgrade-Problemchen in 19c unter Windows

In meiner nunmehr 20-jährigen Erfahrung mit Oracle ist es schon eine Tradition, dass man unter Windows, naja, sagen wir mal, ein bisschen das „Schmuddelkind“ ist oder sich zumindest so von Oracle behandelt fühlt. Das beginnt bei der Dokumentation (inzwischen werden hier zumindest die Variablen nicht mehr mit $ bezeichnet…), geht weiter bei (nicht vorhandenen) Skript-Beispielen und zieht sich bis zum Patch- und Upgrade-Management.

Leider scheint sich dies auch in den neueren Versionen fortzusetzen. Aktuell gibt es zwei Bugs sowohl beim Upgrade auf die Versionen 19.4.0.0 / 19.5.0.0 sowie 19.6.0.0, …

Weiterlesen

SCN-Stress für Database-Links ab dem 23. Juni 2019

Eher zufällig bin ich auf eine Ankündigung in MOS gestoßen, in der dem geneigten Benutzer nahegelegt wird, Datenbanken der Versionen 11.1.0.7, 11.2.0.3 und 12.1.0.1 AUF JEDEN FALL vor dem 23. Juni 2019 zu aktualisieren (siehe MOS Doc ID 2361478.1 )

Weiterlesen

Clone PDB from NON$CDB in Oracle 18

 

Es ist soweit – nach und nach nehmen die Migrationsprojekte auf Oracle 18 Fahrt auf.

Eine sehr cooles Feature in Oracle 18 ist, dass man in einer Multi- oder auch Single-Tenant-Umgebung eine neue PDB aus einer vorhandenen Non-CDB clonen kann.

Weiterlesen

Katalog-Datenbank für das RMAN-Repository muss ab 12.1.0.2 eine EE mit Partitioning sein

Bei einer Umgebung mit vielen Datenbanken hat es nach wie vor Vorteile, die RMAN-Backup-Informationen in einem Katalog-Schema innerhalb einer weiteren Datenbank zu speichern. Der RMAN-Katalog erfordert die höchste Version aller dort gesicherten Datenbanken – das bedeutet bei Upgrade oder Anlage einer neuen Datenbank in einer höheren Version dann jeweils auch ein Katalog-Upgrade. So weit, so bekannt.

Weiterlesen