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

4. August 2018 Aus Von Markus Flechtner

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

Werbung (Amazon-Partner-Link)