Der Oracle Database In-Memory Advisor ist da

Der In-Memory Advisor hilft bei der Evaluierung der In-Memory Option, speziell bei der Beantwortung der Frage, ob sich eine Performance-Verbesserung erzielen lässt.

Das Tool hilft auch bei der Konfiguration der In-Memory Option, indem es die optimale Größe des In-Memory Column Stores berechnet und die Datenbankobjekte auflistet, die von der In-Memory Option am meisten profitieren. Der Advisor kann bereits in einer Oracle DB 11g ausgeführt werden. Die Handhabung ist trivial, wie diese Präsentation zeigt.

15 Basisbefehle für Oracle DB 12c

  1. Welche Oracle Datenbanken sind auf meinem Server vorhanden?
    Wie heißen die Datenbanken? In welchem Oracle Home Verzeichnis laufen die Datenbanken?

    $ more /etc/oratab

    Die Ausgabe hat die Form ORACLE_SID:ORACLE_HOME:N|Y

  2. Verbindung zu einer Datenbankinstanz als SYSDBA aufbauen:
    $ . oraenv
    ORACLE_SID = [oracle] ? cdb1
    The Oracle base has been set to /u01/app/oracle
    $ sqlplus / as sysdba

    Mit der Utility oraenv werden die Umgebungsvariablen ORACLE_SID (hier cdb1) und ORACLE_HOME interaktiv gesetzt. Syntax: {Punkt}{Leerzeichen}oraenv

  3. Datenbank starten und öffnen (erforderlich, falls die Meldung „Connected to an idle instance“ erscheint)
    sql> startup
  4. Ist meine Datenbank eine Multitenant Container Datenbank (CDB) oder eine Non-CDB?
    sql> select name, cdb, con_id from v$database;
  5. Welche Container sind in meiner CDB definiert?
    Alle Container (Root Container und Pluggable Databases):

    sql> select name, con_id, open_mode from v$containers;  

    Nur Pluggable Databases (PDBs):

    sql> select name, con_id, open_mode from v$pdbs;  
    sql> show pdbs
  6. Mit welchem Container bin ich aktuell verbunden?
    sql> show con_name  
    sql> show con_id
  7. Redo Log Files der CDB
    sql> col member format a40
    sql> select group#, con_id, member from  v$logfile;  
  8. Control Files der CDB
    sql> col name format a60
    sql> select name, con_id from v$controlfile;
  9. Data Files der CDB
    sql> col name format a50
    sql> select file#, name, con_id from v$datafile order by con_id; 
  10. Tablespaces der CDB
    sql> col name format a8
    sql> select ts#, name, con_id from v$tablespace order by con_id; 

    Tablespaces und dazugehörige Data Files

    sql> col file_name format a50
    sql> col tablespace_name format a8
    sql> select ts.name tablespace_name, df.name file_name, df.con_id from v$datafile df, v$tablespace ts where df.ts#=ts.ts# and df.con_id=ts.con_id order by df.con_id;
  11. Alle User der CDB („common user“ und „local user“)
    sql> col username format a30
    sql> select username, common, con_id from cdb_users order by con_id;
  12. Eine PDB öffnen
    sql> alter pluggable database pdb1 open; 
    sql> alter pluggable database all open;
  13. Verbindung zu einer PDB als User SYSTEM aufbauen
    $ sqlplus system/pw@hostname:port/pdb

    z.B.

    $ sqlplus system/oracle@localhost:1521/pdb1

    Statt dem Easy Connect String „hostname:port/service“ kann ein Net Service Name angegeben werden, der vorher in tnsnames.ora definiert wurde.

  1. CDB herunterfahren
    sql> shutdown immediate
  2. Listener-Status und verfügbare DB-Services
    $ lsnrctl status

Oracle Database In-Memory Option

Oracle Database In-Memory ist in aller Munde. Erste-Hand-Informationen finden Sie im In-Memory Whitepaper, in der Oracle Dokumentation und im Product Management Blog. In diesem Beitrag werden einige häufig gestellte Fragen beantwortet.

1. Ist Oracle Database In-Memory eine neue Datenbank?
Nein. Die Oracle Database In-Memory Option ist eine Erweiterung der Oracle Datenbank (DB), verfügbar in der Enterprise Edition ab Version 12.1.0.2. Sie ist kompatibel mit allen Features der Oracle DB wie RAC, Data Guard, Advanced Security u.a.

2. Basiert die Oracle DB In-Memory Option auf TimesTen?
Nein. Oracle DB In-Memory ist eine komplett neue DB-Technologie. (TimesTen bleibt als eigenständige Datenbank sowie als Cache für die Oracle Datenbank – unter dem neuen Produktnamen „Oracle TimesTen Application-Tier Database Cache“ – weiterhin erhalten)

3. Wofür brauche ich die Oracle DB In-Memory Option?
Für Hochgeschwindigkeitsabfragen, um Auswertungen im analytischen oder im transaktionalen Umfeld zu beschleunigen.

4. Brauche ich neue Hardware für die Oracle DB In-Memory Option?
Nein. Die Oracle DB In-Memory Option kann auf jeder Hardwareplattform betrieben werden, auf der die Oracle DB 12.1.0.2 (und höher) zertifiziert ist.

5. Wie wird die Oracle DB In-Memory Option installiert?
Bei der Installation der Oracle DB 12.1.0.2 (und höher) wird die Oracle DB In-Memory Option automatisch installiert. Es ist keine zusätzliche Installation erforderlich.

6. Wie aktiviere ich die Oracle DB In-Memory Option für meine Datenbank?
Nach der Installation der Oracle Datenbank ist die In-Memory Option inaktiv. Das lässt sich an dem Datenbankparameter inmemory_size = 0 erkennen.

Die In-Memory Option benötigt einen dedizierten Hauptspeicherbereich (In-Memory Column Store), in dem die Daten im Spaltenformat abgelegt werden. Um die In-Memory Option zu aktivieren, müssen Sie 1. dem In-Memory Column Store Speicher zuweisen und 2. die Datenbank neustarten, wie in diesem Beispiel:

sql> alter system set inmemory_size = 10G scope=spfile;
sql> shutdown immediate;
sql> startup;

Der In-Memory Column Store wird im Oracle Hauptspeicher (System Global Area, SGA) erzeugt. Da die SGA auch für andere Zwecke benötigt wird, sollten Sie die Gesamtgröße der SGA überprüfen und ggf. anpassen. Initialisierungsparameter sga_target.

7. Wie verwende ich die In-Memory Option?
Die Handhabung der In-Memory Option ist sehr einfach. Sie müssen der Datenbank nur mitteilen, welche Datenbankobjekte in den In-Memory Column Store geladen werden sollen, wie in diesem Beispiel:

sql> alter table sales.customers inmemory;

Die In-Memory Option lässt sich für einzelne Tabellen, Partitionen, Tablespaces und Materialized Views einschalten. Der Oracle Optimizer kennt den In-Memory Column Store und nutzt ihn automatisch, jedes Mal wenn eine Datenbankabfrage davon profitiert.

8. Welche Tabellen befinden sich im In-Memory Column Store?
Die View v$im_segments gibt Auskunft über den Inhalt des In-Memory Column Stores:

sql> select v.owner, v.segment_name, v.populate_status from v$im_segments;

9. Muss die gesamte DB in den Hauptspeicher passen um Oracle DB In-Memory Option zu nutzen?
Nein. Mit der In-Memory Option bestimmen Sie selbst, welche Tabellen in den In-Memory Column Store geladen werden. Oracle vertritt die Ansicht, dass es nicht erforderlich ist, die gesamte Datenbank im teuren Hauptspeicher zu halten (meistens werden nur einige wenige Tabellen aktiv genutzt bzw. sind performancekritisch für Ihre Applikation).

Stattdessen implementiert Oracle ein mehrschichtiges Speichermodell, bei dem die Daten, in Abhängigkeit von der tatsächlichen Nutzung, auf unterschiedlichen Storage-Ebenen gespeichert werden. Die „heißen“ Daten (häufig im Zugriff) liegen im Hauptspeicher, die aktiven Daten (seltener abgefragt) liegen auf SSD, die “kalten“ (älteren) Daten liegen auf Festplatte. Eine SQL-Abfrage kann auf alle Daten transparent zugreifen.

10. Muss ich meinen Hauptspeicher verdoppeln um die Oracle DB In-Memory Option nutzen zu können?
Nein. Sie können dem In-Memory Column Store so viel oder so wenig Speicher zuweisen, wie Sie es möchten (die Mindestgröße beträgt 100 MB). Je größer der In-Memory Column Store, desto mehr Daten können darin vorgehalten werden. Um den verfügbaren Speicher maximal zu nutzen, können die Daten komprimiert werden.

11. Werden durch die In-Memory Option 4 Kopien meiner Daten erzeugt?
Nein. Die Behauptung, man bräuchte 4 Kopien der Daten, ist schlichtweg falsch. Die Oracle Datenbank speichert eine Kopie der Daten auf Festplatte (Zeilenformat). Eine kleine Untermenge der Daten – die aktivsten Zeilen, die häufig im Zugriff sind – werden zur Steigerung der Performance im Hauptspeicher im sog. Buffer Cache vorgehalten (Zeilenformat). Mit der In-Memory Option können einige DB-Objekte in den In-Memory Column Store geladen werden  (Spaltenformat). Die Daten, die im In-Memory Column-Store vorliegen, müssen nicht zwingend im Buffer Cache vorhanden sein und umgekehrt.

12. Kann eine Tabelle sowohl im Zeilen- als auch im Spaltenformat vorliegen?
Ja. Die gleiche Tabelle kann im Hauptspeicher sowohl im Buffer Cache (Zeilenformat) als auch im In-Memory Column Store (Spaltenformat) vorliegen. Die DB sorgt für die transaktionale Konsistenz der beiden Repräsentationen.

13. Wird der In-Memory Column Store auf Festplatte gespeichert?
Nein. Die Daten liegen auf Festplatte, wie bisher, im Zeilenformat vor. Die spaltenbasierte Repäsentation gibt es nur im Hauptspeicher.

14. Wann wird der Buffer Cache, wann der In-Memory Column Store verwendet?
Der Optimizer entscheidet automatisch, welcher Speicherbereich für die SQL-Ausführung genutzt wird. Liegen die Daten im Hauptspeicher sowohl im Zeilen- als auch im Spaltenformat vor, werden analytische Abfragen gegen den Column Store ausgeführt. Änderungsoperationen laufen gegen den Buffer Cache.

15. Muss meine Applikation agepasst werden, um die In-Memory Option nutzen zu können?
Nein. Die Oracle DB In-Memory Option wird auf DB-Ebene konfiguriert. Die Applikation muss nicht angepasst werden.

16. Für welche Applikationen eignet sich die Oracle DB In-Memory Option?
Die Oracle DB In-Memory Option erhöht die Performance von analytischen Abfragen.

Da die meisten Analysen in DWH-Umgebungen vorkommen, werden diese Umgebungen von der In-Memory Option am meisten profitieren.

Aber auch OLTP-Umgebungen (z.B. ERP-Applikationen) profitieren von der In-Memory Option, denn auch hier finden Auswertungen statt. Bis jetzt waren analytische Indizes erforderlich um transaktionale Daten performant abzufragen und zu durchsuchen. Der negative Nebeneffekt von analytischen Indizes ist, dass sie bei jeder Datenänderung aktualisiert werden müssen, was den OLTP-Betrieb insgesamt verlangsamt. Nun können analytische Indizes zugunsten der In-Memory Option entfernt werden.

17. Was passiert mit den Daten aus dem In-Memory Column Store nach einem unerwarteten Ausfall des DB-Servers?
Wenn Sie Ihre Datenbank als Single Instance betreiben (Non-RAC), muss der In-Memory Column Store nach einem Datenbankausfall neu befüllt werden. Je nach Datenmenge, kann dieser Vorgang unterschiedlich lange dauern. Aber: während der In-Memory Column Store befüllt wird, ist die Datenbank aktiv und kann genutzt werden. Analytische Abfragen werden ggf. länger dauern (weil manche Daten von der Festplatte geholt werden müssen) aber sie funktionieren. Im Gegensatz dazu, ist eine reine In-Memory Datenbank nicht zugänglich, bis die gesamte Datenbank im Hauptspeicher vorliegt.

Um Ausfallzeiten und Verzögerungen zu minimieren, können Sie Ihre Datenbanken als RAC betreiben. Im RAC hat jede Datenbankinstanz ihren eigenen In-Memory Column Store. Eine Tabelle kann in mehreren Column Stores als Kopie vorliegen. Bei Ausfall einer Datenbankinstanz wird der In-Memory Column Store einer anderen DB-Instanz genutzt.

18. Welche Komprimierungsmöglichkeiten gibt es?
Beim Laden in den In-Memory Column Store können die Daten komprimiert werden. Die 5 Komprimierungsalgorithmen (memcompress for dml, memcompress for query low | high, memcompress for capacity low | high) unterscheiden sich in der Komprimierungsrate und in der Abfrageperformance. Hier sind die Details.

19. Wird Exadata durch den Einsatz der Oracle DB In-Memory Option überflüssig?
Nein, Exadata und die In-Memory Option ergänzen sich sehr gut. Exadata ist die beste Pattform um eine Oracle DB mit In-Memory Option zu betreiben. Als Komplettsystem beinhaltet Exadata alle HW- und SW-Komponenten, die für einen ausfallsicheren Oracle Datenbankcluster erforderlich sind. Das System ist von Oracle vorkonfiguriert, gestetet und optimiert für maximale Performance.

Die Oracle Datenbank: ein Service der Oracle Public Cloud

Oracle Datenbanken werden typischerweise im eigenen Rechenzentrum betrieben oder bei einem externen Anbieter gehostet. Seit kurzem hat man die Möglichkeit die Oracle Datenbank auch als Service in der Oracle Public Cloud zu nutzen. Die Oracle Public Cloud -offiziell Oracle Cloud- ist im Internet auf cloud.oracle.com zu finden. Darin bietet Oracle, neben der Datenbank, eine Reihe weiterer Produkte verpackt als Services: von einer Java Plattform zur Entwicklung von Java EE Applikationen bis hin zu fertigen Unternehmensanwendungen im Bereich ERP oder CRM.

Der Oracle Database Cloud Service bietet Zugang zu einem Schema der Oracle Datenbank Enterprise Edition mit Werkzeugen für Upload, Download und Verwaltung der Daten. Außerdem bietet der Dienst eine Plattform zur Entwicklung von Webanwendungen auf Basis der Oracle Datenbank. Man beantragt den Datenbankservice über ein Selfservice Portal und kann die Datenbank von überall nutzen, wo ein Internetanschluss zur Verfügung steht. Es wird pro Monat oder Jahr, in Abhängigkeit von der Storagekapazität, abgerechnet. Die Nutzungspauschale beinhaltet alle anfallenden Kosten: die von Oracle bereitgestellte Exadata-Infrastrukur, die Softwarelizenzen, den Support sowie die Administration durch Oracle.

Ich habe den Oracle Database Cloud Service in einem Vortrag auf der diesjährigen DOAG Konferenz vorgestellt. Dabei ging es um die Architektur, die Werkzeuge und den Zugriff auf die Oracle Datenbank in der Oracle Public Cloud. Die Folien finden Sie hier.
 

 

Kurz und knapp: Ausfallsicherheit für Oracle Datenbanken

In diesem Video stellen wir Basistechnologien im Bereich Hochverfügbarkeit und Desasterschutz vor. Es geht um Clustering auf physikalischer Ebene mit Real Application Clusters (RAC) und den Betrieb von Standby Datenbanken mit Active Data Guard. Eine Einführung. Danke an Peter für die Produktion!

 

 

Oracle Hybrid Columnar Compression oder Advanced Compression?

In der Vergangenheit wurde häufiger angefragt, wo der Unterschied zwischen Advanced Compression und Hybrid Columnar Compression ist und ob es Sinn macht, beide Komprimierungstechniken der 11g Datenbank gleichzeitig einzusetzen. Advanced Compression (ACO) ist seit Version 11g eine kostenpflichtige Option zur Oracle Datenbank Enterprise Edition (EE). Hybrid Columnar Compression (HCC) hingegen, ist ein kostenloses EE-Feature, das ab Version 11.2.0.3 für alle Oracle Storage Systeme freigegeben wurde (Exadata Storage, ZFS Storage Appliance, Pillar Axiom).

Als erstes stellt sich die Frage, was komprimiert werden soll.

Sind es Tabellendaten, so hat man die Wahl zwischen 4 Verfahren: OLTP Table Compression (Bestandteil von ACO), Warehouse Compression (Bestandteil von HCC), Archive Compression (Bestandteil von HCC) und Basic Compression (Feature der Enterprise Edition).  In derselben Datenbank können die Verfahren koexistieren. Welche Komprimierungsmethode mehr Sinn macht, hängt von der Art des Zugriffs auf die Tabellendaten ab. OLTP Table Compression eignet sich für Tabellen, in denen die Daten häufig verändert werden. Tabellen, auf die überweigend lesend zugegriffen wird, sollten mit Basic Compression oder -noch speicherplatzeffizienter- mit Warehouse Compression komprimiert werden. Archive Compression ist das beste Komprimierungsverfahren für Tabellen, die für Compliance-Zwecke aufbewahrt und kaum verwendet werden. Sind die Tabellen Tabellen partitioniert, so können sie mit ACO und HCC gleichzeitig komprimiert werden. In meinem kürzlich erschienenen Artikel erfahren Sie mehr über die einzelnen Algorithmen und deren Einsatzgebiete.

Unstrukturierte und semistrukturierte Daten in der Oracle Datenbank (Bilder, Textdokumente, XML-Dateien u.ä.) lassen sich nur mit Advanced Compression komprimieren und nur wenn sie als SecureFiles LOBs gespeichert sind. Ab 11g R1 ist SecureFiles eine neue Storage Architektur für Large Objects.

Indizes können unabhängig von den dazugehörigen Tabellen komprimiert werden. Dazu benötigen Sie weder ACO noch HCC. Die Komprimierung von Indizes ist eine Funktionalität jeder Datenbankedition.

Möchte man Datensicherungen (Backups) mit Mitteln der Oracle Datenbank komprimieren, müssen die Backups mit Oracles Sicherungswerkzeug – dem Recovery Manager (RMAN) – durchgeführt werden. Weiterhin müssen die Backups als Backup Sets (und nicht als Image Copy) gespeichert werden. Bei der Erstellung der Backups hat man die Wahl zwischen 4 Komprimierungsalgorithmen BASIC, LOW, MEDIUM, HIGH. Hinter BASIC verbirgt sich die Default RMAN Compression. Sie ist in jeder Datenbankedition (Standard oder Enterprise Edition) ohne Zusatzkosten erlaubt. Die anderen 3 Algorithmen sind Bestandteil von Advanced Compression.

Mit Data Pump exportierte Daten können ebenfalls komprimiert werden. Metadaten kann man ohne Weiteres in jeder DB-Edition komprimieren. Möchte man Daten und Metadaten komprimieren oder nur die Daten, so ist Advanced Compression erforderlich.

Nicht zuletzt kann auch den Netzwerkverkehr zwischen Primary und Standby Datenbank (genauer die Redo Logs) in einer Data Guard Konfiguration komprimieren, um Bandbreite einzusparen. Dafür benötigt man auch Advanced Compression.

Fazit: Advanced Compression und Hybrid Columnar Compression lassen sich kombinieren, um das gesamte Komprimierungspotenzial der Oracle Datenbank auszuschöpfen.

Welche Oracle Datenbank Features nutzen Sie?

In einem anderen Blogeintrag ging es darum, wie man die Nutzung von Optionen und Packs – also der lizenzpflichtigen Add-ons zur Oracle Datenbank Enterprise Edition – aufdecken kann.

Darüber hinaus, stellt sich u.a. bei einem Downgrade der Enterprise Edition (EE) auf die Standard Edition (SE) die Frage, ob Funktionalität verwendet wird, die nur zur EE gehört.  Oracle LMS und divese Oracle Partner bieten Dienstleistungen an, um die Nutzung von Features zu auditieren und Ihnen Lizenz-Compliance zu bescheinigen. Ein solcher Service ist sinnvoll, denn die selbstständige Untersuchung ähnelt Detektivarbeit und hat keinen Anspruch auf Vollständigkeit und Verbindlichkeit. Warum, das werden wir hier beleuchten.

Der Startpunkt einer solchen Untersuchung ist die Data Dictionary View DBA_FEATURE_USAGE_STATISTICS. Sie gibt Auskunft über einen Teil der verwendeten Funktionalität.

sql> SELECT name, detected_usages, version, TO_CHAR(last_usage_date, 'dd-mm-yyyy hh12:mi:ss'), TO_CHAR(last_sample_date,'dd-mm-yyyy hh12:mi:ss') FROM dba_feature_usage_statistics WHERE detected_usages > 0  ORDER BY name;

Die Ausgabe ist eine Aufzählung von Funktionen, wie in der folgenden Tabelle:

NAME LAST_USAGE_DATE
Audit Options 23-04-2012 01:06:09
Automatic Maintenance – Optimizer Statistics Gathering 23-04-2012 01:06:09
Automatic Maintenance – Space Advisor 23-04-2012 01:06:09
Automatic SGA Tuning 23-04-2012 01:06:09
Automatic SQL Execution Memory 23-04-2012 01:06:09
Automatic Segment Space Management (system) 23-04-2012 01:06:09
Automatic Undo Management 23-04-2012 01:06:09
Character Set 23-04-2012 01:06:09
Deferred Segment Creation 23-04-2012 01:06:09
HeapCompression 23-04-2012 01:06:09
Locally Managed Tablespaces (system) 23-04-2012 01:06:09
Locally Managed Tablespaces (user) 23-04-2012 01:06:09
Oracle Java Virtual Machine (system) 23-04-2012 01:06:09
Oracle Utility Datapump (Import) 23-04-2012 01:06:09
Partitioning (system) 23-04-2012 01:06:09
Recovery Area 23-04-2012 01:06:09
SecureFiles (system) 23-04-2012 01:06:09
SecureFiles (user) 23-04-2012 01:06:09
Server Parameter File 23-04-2012 01:06:09
Virtual Private Database (VPD) 23-04-2012 01:06:09

Man sollte bei der Interpretation der Ausgabe Folgendes beachten:

  1.  Das Ergebnis ist potentiell veraltet. DBA_FEATURE_USAGE_STATISTICS wird einmal alle 7 Tage aktualisiert. Der dazugehörige Job wird von internen Datenbankprozessen angestoßen und kann nicht bei Bedarf (ohne weiteres) gestartet werden. Die Spalte last_sample_date zeigt, wann die letzte Statistikensammlung durchgeführt wurde, somit auch wie alt die Ergebnisse sind.
  2. Das Ergebnis ist nicht vollständig. Zur Abgrenzung zwischen den Editionen sollte man die Feature-Matrix aus der Oracle 11gR2 Dokumentation und dem Oracle Database 11gR2  Licensing Information Guide heranziehen, siehe dazu auch Blogeintrag. DBA_FEATURE_USAGE_STATISTICS berücksichtigt um die 150 Features. Das sind nicht alle EE-Features aus der Feature-Matrix. Ein einfaches Beispiel: Flashback Table wird von DBA_FEATURE_USAGE_STATISTICS nicht berücksichtigt.
  3. Das Ergebnis ist nicht immer relevant. DBA_FEATURE_USAGE_STATISTICS differenziert nicht immer, ob ein Feature von Datenbanknutzern oder intern, von Oracle, verwendet wird. z.B. Virtual Private Database ist in allen Datenbankeditionen aufgelistet, auch wenn es rein intern, für die Implementierung der XML Funktionalität in der Datenbank verwendet wird. Features, die von Standard Oracle Usern verwendet werden (z.B. XDB) fallen nicht unter der Lizenzpflicht. Eine solche Nutzung ist bei einigen Funktionen in Klammern angegeben (system). Wenn keine Kennzeichnung vorhanden und sollten Zweifel an der Nutzung einer Funktionalität bestehen,  sind weitere Untersuchungen notwendig. z.B. bei Virtual Private Database sollte man sich anzeigen lassen, welcher User die Policies angelegt hat und ob es ein Standard Oracle User ist oder nicht.
  4. Die Zuordnung eines Features aus DBA_FEATURE_USAGE_STATISTICS zu einer Edition ist nicht immer einfach. Die Feature-Namen in DBA_FEATURE_USAGE_STATISTICS und im Oracle Whitepaper sind leider nicht identisch.

Fazit: DBA_FEATURE_USAGE_STATISTICS ist ein hilfreiches Werkzeug bei der Ermittlung der eingesetzten Datenbankfeatures. Aus den o.g. Gründen sollte die Auskunft aus  DBA_FEATURE_USAGE_STATISTICS nicht als verbindlich angesehen werden. Weitere Untersuchungen und ergänzende Abfragen sind erforderlich.

Technische Abgrenzung zwischen der Oracle Datenbank Standard Edition und Enterprise Edition

Eine Frage, die mir immer wieder begegnet, ist ob sich  Oracles Datenbankeditionen Standard (SE) und Enterprise (EE) in der Basisfunktionalität, also abgesehen von den Enterprise Edition Erweiterungen (Management Packs und Datenbankoptionen), unterscheiden. Oder ob die Unterscheidung rein formell ist und der Lizenzierung dient, sprich die Funktionalität ist in beiden Editionen vorhanden. Dieser Frage soll in diesem Eintrag nachgegangen werden.

Ein Blick in den Database Installation Guide zeigt, dass man für eine Enterprise Edition Installation knapp 2% mehr Speicherplatz auf der Festplatte benötigt. Nicht nur die Oracle Homes sind unterschiedlich groß: das Data Dictionary einer Enterprise Edition Datenbank enthält Datenbankobjekte, die in der Standard Edition nicht vorhanden sind. Aus diesem Grund ist empfohlen, bei einem Downgrade von EE auf SE einen Export/Import vorzunehmen. Die SYS-Schemaobjekte werden nicht exportiert; somit wird man die EE-spezifischen Data Dictionary Objekte los (My Oracle Support > Support Note ID 139642.1). Die SE-Funktionalität hingegen ist in der EE gänzlich enthalten; deswegen ist der Konvertierungsprozess einer SE zu einer EE recht einfach (My Oracle Support > Support Note ID 117048.1).

Man kann sagen, dass die installierte Software für SE und EE fast identisch ist: es werden standardmäßig alle Features und Komponenten der EE installiert. So lässt sich prüfen, welche Komponenten installiert wurden:

sql> select comp_id, comp_name, status, schema from dba_registry order by comp_name;

Der DB-User in der Spalte schema ist der Eigentümer der  jeweiligen Datenbankkomponente und deren Objekte, z.B. MDSYS für Oracle Spatial. Die Abfrage liefert identische Ergebnisse in der SE und in der EE (Version 11gR2). Man sieht, dass EE  Optionen wie Spatial auch in der SE installiert werden.

Die EE-Funktionalität  steht in der SE jedoch nur bedingt zur Verfügung. Die kostenplichtigen Optionen der EE (wie Advanced Compression oder Partitioning) sind in der SE standardmäßig deaktiviert. So wird der Versuch eine Tabelle mit dem Zusatz compress for oltp anzulegen oder zu partitionieren scheitern, mit der Fehlermeldung ORA-00439: feature not enabled. Leider sind nicht alle EE-Funktionen gesperrt. Man kann in SE 11gR2 problemlos über flashback table to before drop gelöschte Tabellen aus dem Recyclebin wiederherstellen, obwohl dieses Feature der EE vorbehalten ist. Flashback Database ist wiederum gesperrt.

Es bleibt Aufgabe des Nutzers sicherzustellen, dass nur lizenzierte Features im Einsatz sind. Welche Features in welcher Datenbankedition erlaubt oder Teil der lizenzpflichtigen Optionen sind, beschreibt der Oracle Database 11gR2  Licensing Information Guide. Die Feature Matrix findet man auch auf My Oracle Support in der Support Note ID 1084132.1. Diese Dokumente sollten vor der Nutzung  einer Datenbankfunktionalität immer herangezogen werden.

Kann man Optionen der Oracle Datenbank Enterprise Edition deaktivieren?

Oracle Datenbankoptionen (wie Oracle Partitioning, Advanced Compression oder Real Application Testing) sind getrennt zu lizenzierende Produkte. Sie werden zusammen mit dem Oracle Datenbankserver installiert. In älteren Versionen der Oracle Datenbank konnte man einige Optionen von der Installation ausschließen. Seit Version 11gR2 werden jedoch alle Komponenten mit installiert (dies gilt auch für die Standard Edition).

Eine Option wird allein durch die Installation nicht zwingend lizenzpflichtig. Sie ist zu lizenzieren, wenn ihre Nutzung beabsichtigt ist.  In einem anderen Blog-Eintrag ist beschrieben worden, wie man feststellen kann, ob eine kostenpflichtige Funktionalität verwendet wurde. Die von Oracle Support angebotenen Skripte verfolgen die Nutzung der Produkte und nicht ihr Vorhandensein.

Um eine Nutzung kategorisch auszuschließen ist es möglich – nach der Installation der Oracle Datenbank 11gR2 – folgende 6 Optionen zu deaktivieren (siehe My Oracle Support > Support Note ID 1069015.1)

– Oracle Partitioning
– Oracle OLAP
– Oracle Label Security
– Oracle Data Mining
– Oracle Database Vault
– Oracle Real Application Testing

Wohlgemerkt man kann nicht alle Datenbankoptionen deaktivieren, die sich auf der Oracle Preisliste wiederfinden!

Unter Linux/UNIX kann man sich den Status der o.g. Komponenten (aktiv/nicht aktiv) mit folgendem Befehl anzeigen lassen:

[oracle@dbhost ~]$ ar -tv $ORACLE_HOME/rdbms/lib/libknlopt.a

Die Ausgabe ist nicht selbsterklärend. Man kann anhand der Module aus der Ausgabe und der Support Note ID 1069015.1 feststellen, ob eine Option aktiv ist oder nicht. Bei der Oracle Datenbank Standard Edition bekommt man – wie erwartet- folgendes Ergebnis:

...
rw-rw-r-- 94110/42424  22272 Sep 18 23:43 2011 xsnoolap.o --> OLAP Off
rw-rw-r-- 94110/42424   3968 Sep 18 23:45 2011 kzlnlbac.o --> Label Security Off
rw-rw-r-- 94110/42424   4112 Sep 18 23:46 2011 kzvndv.o --> Database Vault Off
...
rw-rw-r-- 94110/42424   3416 Sep 18 23:54 2011 kecnr.o --> Real Application Testing Off
rw-rw-r-- 94110/42424   3416 Sep 18 23:42 2011 dmndm.o --> Data Mining Off
rw-rw-r-- 94110/42424   3424 Sep 18 23:35 2011 ksnkkpo.o --> Partitioning Off

Nach der Installation der Oracle Datenbank Enterprise Edition ist die Ausgabe wie folgt:

...
rw-rw-r-- 94110/42424   3936 Sep  5 20:24 2010 kzlnlbac.o --> Label Security Off
rw-rw-r-- 94110/42424   4080 Sep  5 20:13 2010 kzvndv.o --> Database Vault Off
...
rw-rw-r-- 500/500   3424 Sep  5 20:14 2010 kecwr.o --> Real Application Testing On
rw-r--r-- 500/500   3432 Sep  5 20:08 2010 kkpoban.o  --> Partitioning On
rw-r--r-- 500/500   3424 Sep  5 20:20 2010 dmwdm.o --> Data Mining On
rw-r--r-- 500/500   4520 Sep  5 20:21 2010 xsyeolap.o --> OLAP On

Das Aktivieren/Deaktivieren einer Option kann sehr einfach mit dem Skript chopt durchgeführt werden (siehe My Oracle Support > Support Note ID 942406.1).  So deaktiviert man z.B. Partitioning:

[oracle@dbhost ~]$ $ORACLE_HOME/bin/chopt disable partitioning

chopt lässt es (leider) zu, auch in der Standard Edition Komponenten zu aktivieren. Ein Test bei Standard Edition 11.2.0.3 hat ergeben, dass trotz erfolgreicher Aktivierung von Oracle Partitioning,  das Anlegen einer partitinionierten Tabelle fehlschlägt. Der Fehler lautet:

ORA-00439: feature not enabled: Partitioning

Die Nutzung von Datenbankoptionen mit der Standard Edition ist ohnehin lizenztechnisch nicht erlaubt.

Welche Oracle Datenbankedition ist bei Ihnen im Einsatz?

Bei der Installation der Oracle Datenbanksoftware 11g gibt man die Edition (Enterprise Edition, Standard Edition oder Standard Edition One) an. Nachträgtlich hat man mehrere Möglichkeiten herauszufinden, welche Edition im Einsatz ist.

Eine Möglichkeit ist in die Global Inventory Logs  nachzuschauen (siehe My Oracle Support > Support Note ID 1341744.1). Den Pfad zur Global Inventory kann man je nach Plattform folgendermaßen finden:
– auf Linux und AIX in der Datei /etc/oraInst.loc (inventory_loc=<Pfad>)
– auf anderen UNIX Plattformen in der Datei /var/opt/oracle/oraInst.loc
– auf Windows als Wert des Registry Keys: HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\inst_loc
Die Installationslogs befinden sich im Unterverzeichnis logs der Global Inventory. Sie heißen auf allen Plattformen installActions<timestamp>.log. Meistens wird es mehrere Logdateien dieser Art geben; jede bezieht sich auf eine Installation oder ein Upgrade der Oracle Datenbanksoftware (eines Oracle Homes). Der Installationstyp ist im Abschnitt Global settings unter Database edition dokumentiert, z.B.:

--------------------------------------------------------------------------------
Global settings
--------------------------------------------------------------------------------
...
- Database edition : Standard Edition One (Install database software only)

Ein schneller Weg um herauszufinden ob man eine Enterprise Edition im Einsatz hat, ist sich einfach über SQL*Plus mit der Datenbank zu verbinden. Die SQL*Plus Ausgabe enthält im Regelfall einen Banner mit dem expliziten Hinweis auf die Enterprise Edition:

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

Bei Standard Edition und Standard Edition One sieht der SQL*Plus Banner gleich aus. Man kann leider auf diesem Weg zwischen den zwei Editionen nicht unterschieden:

Connected to:
Oracle Database 11g Release 11.2.0.3.0 - Production

Man kann sich die Information aus dem SQL*Plus Banner auch über folgende SQL-Abfrage ausgeben lassen:

select * from v$version;

Weitere Stellen, wo die Datenbankedition dokumentiert ist, listet die Die Support Note ID 735550.1 auf.