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.
WeiterlesenSchlagwort-Archive: Upgrade
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, …
WeiterlesenOracle Datenbanken: Fast jede muss einen Upgrade bekommen
Schaut man sich die Versionen von aktuell genutzen produktiven Datenbanksystemen an, so trifft man sehr häufig 11.2 und 12.1 an.
WeiterlesenSCN-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 )
WeiterlesenClone 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.
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.