„Privilege Analysis“ jetzt „frei“ in der Enterprise Edition der Oracle Datenbank verfügbar

Vor wenigen Tagen hat Oracle die Lizenzbedingungen für „Privilege Analysis“ verändert. Diese Funktionalität, die mit Oracle 12c herauskam, setzte ursprünglich eine Lizenz für „Database Vault“ voraus. Diese Einschränkung wurde fallengelassen, so dass „Privilege Analysis“ jetzt allen Kunden der Enterprise Edition der Oracle Datenbank zur Verfügung steht.

Weiterlesen

Veröffentlicht unter Oracle 18c | Kommentare deaktiviert für „Privilege Analysis“ jetzt „frei“ in der Enterprise Edition der Oracle Datenbank verfügbar

Oracle 18c Express Edition – eine zweite Datenbank anlegen

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.

Weiterlesen

Veröffentlicht unter Allgemein, Oracle 18c | Kommentare deaktiviert für Oracle 18c Express Edition – eine zweite Datenbank anlegen

Oracle 12.2, 18c, 19c – was denn nun?

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.

Weiterlesen

Veröffentlicht unter Allgemein, O-NF12C-DBA | Verschlagwortet mit , , | Kommentare deaktiviert für Oracle 12.2, 18c, 19c – was denn nun?

Oracle Critical Patch Updates – etwas Statistik – das Oktober-Update

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

 

Gesamtübersicht Oracle Critical Patch Updates (seit 2010)

Quelle: https://www.oracle.com/technetwork/topics/security/alerts-086861.html

Jahr #Security Patches Veränderung zum Vorquartal #Produkte #Patches/ #Produkte Security Patches für DB DB – max CVSS score DB – avg CVSS score
2010.01 24 bis 7/2014 wurden die Produkte in der Patchübersicht anders aufgeführt, daher sind frühere Auflistungen nicht mit den aktuellen Auflistungen vergleichbar 9
2010.04 47 96% 7
2010.07 59 26% 6
2010.10 86 46% 7
2011.01 66 -23% 5
2011.04 73 11% 6
2011.07 78 7% 13
2011.10 57 -27% 5
2012.01 78 37% 2
2012.04 88 13% 6
2012.07 87 -1% 4
2012.10 109 25% 5
2013.01 86 -21% 1
2013.04 128 49% 4
2013.07 89 -30% 6
2013.10 127 43% 2
2014.01 144 13% 5 5,0 4,1
2014.04 104 -28% 2 8,5 7,6
2014.07 113 9% 5 9,0 6,1
2014.10 154 36% 45 3,4 31 9,0 5,2
2015.01 169 10% 50 3,4 8 9,0 6,5
2015.04 96 -43% 43 2,2 4 9,0 6,0
2015.07 193 101% 63 3,1 10 9,0 5,1
2015.10 153 -21% 56 2,7 7 10,0 7,7
2016.01 248 62% 51 4,9 7 9,0 5,3
2016.04 136 -45% 49 2,8 5 9,0 5,7
2016.07 276 103% 84 3,3 9 9,0 6,3
2016.10 253 -8% 76 3,3 9 9,1 5,4
2017.01 270 7% 45 6,0 2 9,0 6,2
2017.04 300 11% 121 2,5 2 7,2 6,3
2017.07 308 3% 97 3,2 4 9,9 6,4
2017.10 252 -18% 88 2,9 6 8,8 7,0
2018.01 233 -8% 97 2,4 5 9,1 6,7
2018.04 254 9% 115 2,2 1 8,5 8,5
2018.07 334 31% 121 2,8 3 9,8 7,8
2018.10 301 -10% 101 3,0 3 9,8 6,8
Mittelwert 154,8 3,2 6,0 8,8 6,3

 

Links:

Veröffentlicht unter Allgemein, Oracle 18c | Verschlagwortet mit , , , , , | Kommentare deaktiviert für Oracle Critical Patch Updates – etwas Statistik – das Oktober-Update

Oracle Database 18c, Standard Edition 2 & ORA-38153

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.

Diese allgemeine Aussage ist jedoch nicht 100% wahr; einige grundlegende SQL Plan Management ist mit SE2 lizenziert. Die Lizenzinformationen (https://docs.oracle.com/en/database/oracle/oracle-database/18/dblic/Licensing-Information.html#GUID-0F9EB85D-4610-4EDF-89C2-4916A0E7AC87) sagen zu „SQL Plan Management“ in der Oracle Datenbank 18c:

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.

 

English translation of this post

Veröffentlicht unter Oracle 18c | Kommentare deaktiviert für Oracle Database 18c, Standard Edition 2 & ORA-38153
Pages: 1 2 3 4 5 6 7 8 9 10 ... 22 23 24 Next