Nicht alles, was technisch möglich ist, ist auch erlaubt. Und so gilt natürlich für die Oracle Datenbank 18c Express Edition ganz klar die Einschränkung. „One instance per environment“, wobei Environment eine VM, eine physikalischer Server etc. sein. Aber vielleicht kann man ja doch zwei XE-Datenbanken auf einem Server betreiben. Probieren wir das doch mal aus.
Kunden suchen New-Features Kurse zu Oracle-Datenbank-Version 18c; Datenbankadministratoren, die früher ohne mit der Wimper zu zucken ihre Produktionssysteme von Oracle 11.2.0.2 auf 11.2.0.4 gebracht haben, zögern: nehme ich besser Oracle 12.1, 12.2, 18c oder warte ich auf Oracle 19c? Der neue Release-Zyklus von Oracle hat durchaus für Verwirrung gesorgt. Bringen wir doch mal etwas Licht in dieses Versions(nummern)dunkel.
Seit Januar 2018 veröffentliche in meinem Blog einige Statistiken und Grafiken zu den Critical Patch Updates von Oracle. Vor etwas mehr als einer Woche hat Oracle die Oktober-Patches veröffentlicht und so ist es wieder Zeit für ein Update.
Kritisch betrachtet sind diese Statistiken natürlich nutzlos. Die reinen Zahlen sagen nichts über die Kritikalität der Fehler aus; eine einzelne Sicherheitslücke, die einen Datenbank-Zugang remote ohne Password ermöglicht ist sicher deutlich schwerwiegender als eine Lücke, die nur unter bestimmten Bedingungen für wenige Betriebssysteme existiert und die z.B. durch eine Parameter-Änderung behoben werden kann.
Insofern gelten natürlich auch für die folgenden Grafiken und Statistiken die (nicht immer 100% ernst gemeinten) Grundsätze
„Traue keiner Statistik, die du nicht selbst gefälscht hast“
„Es gibt Lügen, Fälschungen und Statistik“
„Man kann mit Statistiken alles beweisen – und auch das genaue Gegenteil“
Wieviele Patches enthält das große „CPU-Paket“ insgesamt?
Mit 301 Fehlerbehebungen ist die Gesamtzahl der Patches pro Critical Patch Update (CPU) damit zum vierten Mal über der 300-er Grenze.
Der erste statistische „Trick“ ist es dann, die nicht Gesamtzahl der Patches zu betrachten, sondern die Zahl pro betroffenem Produkt:
Da liegt Oracle seit etwas mehr als einem Jahr bei etwa 3 Patches pro Produkt.
Sowohl quantitativ als auch qualitativ liegt die Datenbank im Vergleich mit den anderen Produkten im gleichen Bereich:
Anzahl DB-Patches vs. Mittel über alle Produkte
Der Oktober-CPU ist der letzte CPU des Jahres und so kann man vermelden, dass die Anzahl der Security-Patches für die Datenbank in den letzten Jahren gesunken ist:
Aber, das sind ja nur die reinen Zahlen. Wenn man die „Qualität“betrachtet (im Sinne von CVSS-Score), dann zeigt es sich, dass fast immer ein Bug mit einem Score von 9 oder höher dabei war:
Globale Entwarnung ist somit nicht angesagt, genauso wenig aber auch Aktionismus in der Form, einen CPU unmittelbar nach Freigabe auf Produktionssystemen einzuspielen. Die übliche Empfehlung ist, Release Updates zügig nach Erscheinen einzuspielen
bis 7/2014 wurden die Produkte in der Patchübersicht anders aufgeführt, daher sind frühere Auflistungen nicht mit den aktuellen Auflistungen vergleichbar
Beim Anlegen einer neuen Oracle 18c-Datenbank (Standard Edition 2) mit dem dbca („custom database“) sind mir viele Meldungen in der Datei alert.log aufgefallen:
Errors in file /u00/app/oracle/diag/rdbms/sn18/SN18/trace/SN18_j002_20332.trc:
ORA-12012: error on auto execute of job "SYS"."ORA$AT_SQ_SQL_SW_36"
ORA-38153: Software edition is incompatible with SQL plan management.
ORA-06512: at "SYS.DBMS_SPM_INTERNAL", line 4911
ORA-06512: at "SYS.DBMS_SPM", line 2696 ORA-06512: at line 34
Die Meldung taucht alle 10 Minuten in der alert.log-Datei auf.
Zu diesem Thema gibt es keine Informationen in „My Oracle Support“, aber die Fehlermeldung des ORA-38153 ist ziemlich eindeutig: SQL Plan Management wird von der Standard Edition 2 der Oracle-Datenbank nicht unterstützt.
oracle@kereru:~/ [SN18] oerr ora 38153
38153, 00000, "Software edition is incompatible with SQL plan management."
// *Cause: SQL plan management could be used only with Oracle Database Enterprise Edition.
// *Action: Ensure that Oracle is linked with the Enterprise Edition options.
SE2 and DBCS SE Summary: Only one SQL plan baseline per SQL statement is allowed and SQL plan evolution is disabled.
SE2 and DBCS SE Details: 1. SQL plan baselines can be created or captured using the following methods: – Auto capture (OPTIMIZER_CAPTURE_SQL_PLAN_BASELINE=TRUE) – Manual loading from the cursor cache (DBMS_SPM.LOAD_PLANS_FROM CURSOR_CACHE) – Migration from stored outlines (DBMS_SPM.MIGRATE_STORED_OUTLINE) – Import using DBMS_SPM.UNPACK_STGTAB_BASELINE
2. All capture and creation methods store only one SQL plan baseline per SQL statement. 3. SQL plan baselines can be exported and imported using DBMS_SPM.CREATE_STGTAB_BASELINE, DBMS_SPM.PACK_STGTAB_BASELINE, and DBMS_SPM.UNPACK_STGTAB_BASELINE. 4. Unused SQL plan baselines are not auto-purged. 5. Alternative SQL execution plans for SQL statements are not added to the SQL plan history. 6. SQL plan baselines can be altered and dropped (DBMS_SPM.ALTER_SQL_PLAN_BASELINE and DBMS_SPM.DROP_SQL_PLAN_BASELINE).
7. The following DBMS_SPM functions and procedures are not allowed: CONFIGURE, LOAD_PLANS_FROM_AWR, LOAD_PLANS_FROM_SQLSET, and all functions and procedures associated with SQL plan evolution.
Aber die Ursache der Fehlemeldung – in Bezug auf die Lizenzierung – „SQL Plan Management wird nicht unterstützt“ ist in diesem speziellen Fall richtig, da der Datenbankjob als „automatic SQL tuning advisor task“ gestartet wird – und der kann in der SE2 nicht lizenziert werden.
Meiner Meinung nach kann die Nachricht ignoriert werden. Es ist nur ein weiteres Indiz dafür, das Oracle für EE und SE2 die gleiche Software verwendet und keine 100% saubere Trennung zwischen beiden Editionen hat. Wie die Tatsache, dass dbca standardmäßig eine SE2-Datenbank erstellt, bei der der Parameter CONTROL_MANAGEMENT_PACK_ACCESS auf „DIAGNOSTIC+TUNING“ gesetzt ist, obwohl Diagnostic Pack und Tuning Pack nicht mit der SE2 lizenziert werden können. Und obwohl CONTROL_MANAGEMENT_PACK_ACCESS in meiner Datenbank auf NONE gesetzt ist, laufen alle AWR- und Tuning-Funktionen im Hintergrund. Und eine einfache Auswahl auf einer „DBA_HIST%‘-AWR-Ansicht kann eine SE2-Datenbank in eine teurere EE-Datenbank verwandeln.
Seit Januar 2018 veröffentliche in meinem Blog einige Statistiken und Grafiken zu den Critical Patch Updates von Oracle. Gestern hat Oracle die Juli-Patches veröffentlicht und so ist es Zeit für das Juli-Update
Veröffentlicht unterTrivadisContent|Verschlagwortet mitCPU, CVSS, Patches, Statistik|Kommentare deaktiviert für Oracle Critical Patch Updates – etwas Statistik – das Juli-Update
Wir verwenden Cookies, um Inhalte und Anzeigen zu personalisieren, Funktionen für soziale Medien anbieten zu können und die Zugriffe auf unsere Website zu analysieren. Außerdem geben wir Informationen zu Ihrer Nutzung unserer Website an unsere Partner für soziale Medien, Werbung und Analysen weiter. Mit der Nutzung der Webseite akzeptieren Sie die Nutzung von Cookies und die Datenschutzerklärung. Weitere Informationen
Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um Ihnen das bestmögliche Surferlebnis zu geben. Wenn Sie diese Website ohne Änderung Ihrer Cookie-Einstellungen zu verwenden fortzufahren oder wenn Sie auf "Akzeptieren" klicken, dann erklären Sie sich mit der Verwendung von Cookies und der beschriebenen Datenweitergabe an unsere Partner einverstanden.
Mit der Nutzung der Webseite akzeptieren Sie auch die Datenschutzerklärung.
Impressum * Datenschutzerklärung
