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.

Advertisements

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.