Vor einiger Zeit hatten wir ja schon einmal über die Freuden der Objektverwaltung im SYSAUX-Tablespace berichtet (s. HIER).
Heute aus aktuellem Anlass eine kleine Geschichte für all jene, die sich auch darüber wundern, warum Abfragen gegen Data Dictionary Views, hier insbesondere diejenigen, die den Job Scheduler betreffen, immer so lange dauern. Es könnte evtl. an diesem Umstand liegen:
WeiterlesenWer 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.
WeiterlesenSeit Oracle die das Java Java Development Kit vor einigen Jahren in eine kostenpflichtige Subscription verwandelt hat, gab es diverse kontroverse Diskussionen darüber. Im Gegensatz zum wahrscheinlich von Oracle erwarteten Effekt, dass jetzt alle Java-Nutzer Subscriptions abschließen (und bezahlen) würden, war offenbar eher das Gegenteil der Fall: viele User wendeten sich von Oracle Java ab und kostenlosen OpenSource-Alternativen zu. Doch nun gibt es neue Nachrichten:
WeiterlesenOracle hat vor einigen Tagen einen Merger-Patch für das RU 19.10 herausgebracht. Dieser soll bekannte Performance-Probleme bei der Verwendung von dpload.sql (im Zusammenhang mit datapatch) beheben. Ob dies tatsächlich der Fall ist, kann man leider unter Windows nicht herausfinden – denn obwohl der Patch Nr. 32551008 als „generic“, also für alle Plattformen, deklariert ist, funktioniert die Installation nicht unter Windows.
WeiterlesenDer SYSAUX-Tablespace wurde von Oracle in der Version 10g eingeführt. Hier werden diverse sog. „Auxiliary“ Objekte gespeichert, die Oracle-eigenen Schemata zuzuordnen sind. Die Menge der enthaltenen Objekte sowie der Platzbedarf hängen u.a. von der Anzahl der in der Datenbank installierten Komponenten ab. In der Regel sind diese unkritisch – es kann aber vorkommen, dass der Platzbedarf im SYSAUX-Tablespaces plötzlich stark ansteigt, ohne dass etwas neues installiert oder überhaupt irgendetwas getan wurde.
WeiterlesenAm 08. März wurde das neueste ODA-Software-Release 19.10 veröffentlicht. Warum ist dies ein Anlass zur Freude? Schließlich gibt es diese Patches für die Database Appliance, die kleine Schwester der Exadata, mehrmals pro Jahr.
Nun – in dieser sind einige Neuerungen enthalten, die die Verwendungs- und Konfigurationsmöglichkeiten mehr als sonst bei Patchen üblich verändern…
WeiterlesenIn 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, …
WeiterlesenIn der Oracle-Version 19 mit installierten DB-RUs 19.3, 19.4 oder dem DB-RUR 19.3.1 sind möglicherweise die Patch-Metadaten korrupt und / oder unvollständig.
Dies fällt beim Versuch auf, einen One-Off Patch zu installieren – hier erscheint dann die Fehlermeldung:
„Skip patch <bug#> from list of patches to apply: This patch is not needed.”
Dies wird im MOS Dokument Potential Impact to Database 19c One-off patches Due to Incorrect Patch Level Metadata (Doc ID 2575299.1) beschrieben.
Bei einem der o.g. Software-Ständen sollte laut dem MOS-Artikel ein Skript (chech_patch_level.sh) heruntergeladen und aus dem betreffenden ORACLE_HOME heraus ausgeführt werden, um festzustellen, ob das Problem in der aktuellen Umgebung existiert. Idealerweise ist der Output:
************************************************************
No action is required at this time
*************************************************************Ansonsten muss / müssen der / die im Output genannte Patch(es) zurückgerollt, erneut heruntergeladen und neu installiert werden.
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
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.