Dienstag, September 20, 2016

Parallel Hint auf Statement Ebene

Christian Antognini erläutert in seinem Blog die unterschiedlichen Ausprägungsformen, der seit 11.2 verfügbaren Variante des parallel Hints auf Statement-Ebene, die neben den Hint auf Objekt-Ebene getreten ist, der es seit 11.1 erlaubt, den dem Objekt zugeordneten DOP (degree of parallelism) zu überschreiben. Für den parallel Hint auf Statement-Ebene gibt es dabei folgende Möglichkeiten:
  • parallel (default): erzwingt die Verwendung des allgemeinen (also von den beteiligten Objekten unabhängigen) default DOP (der sich errechnet als: CPU_COUNT * PARALLEL_THREADS_PER_CPU * Anzahl, der an der Ausführung beteiligten Instanzen).
  • parallel (manual): aktiviert den manuellen DOP, wenn für mindestens eines der beteiligten Objekte ein Parallelisierungsgrad angegeben ist (default oder ein Wert > 1). Dieser Wert ist abhängig von den Parallelisierungs-Definitionen der beteiligten Objekten.
  • parallel (auto): aktiviert den automatischen DOP (nicht aber parallel statement queuing und in-memory parallel execution). Die Entscheidung über den Einsatz der Parallelisierung liegt damit bei Optimizer.
  • parallel: entspricht weitgehend parallel(auto). Der einzige Unterschied ist anscheinend, dass der Parameter PARALLEL_MIN_TIME_THRESHOLD beim Einsatz von parallel ohne (auto) nicht berücksichtigt wird.
  • parallel (n): setzt die Parallelisierung auf den vorgegebenen Wert.
Der Artikel ergänzt diese Aussagen um praktische Beispiele, bei denen die unterschiedlichen Hints für ein Test-Szenario jeweils unterschiedliche Effekte hervorrufen.

Dienstag, September 13, 2016

Template Datenbanken in Postgres

Daniel Westermann erklärt im DBI Blog die Rolle der Template-Datenbanken in postgres, über die ich mir bisher nicht allzu viele Gedanken gemacht habe. Im Artikel erläutert er folgende Punkte:
  • in einem neu installierten postgres-Cluster existieren zunächst drei Datenbanken: postgres, template0 und template1.
  • die Datenbank postgres ist der default-Einstiegspunkt für viele Applikationen (etwa den pgadmin), kann aber - wie jede andere Datenbank - gelöscht werden, wenn keine Connections zur Datenbank existieren.
  • man kann sich anschließend aber problemlos mit der Datenbank template1 verbinden und in dieser über das Kommando "create database postgres;" die Standarddatenbank neu erzeugen.
  • Eine Datenbank, die über "create database" erzeugt wird, stellt eine exakte Kopie der Datenbank template1 dar. Werden in template1 neue Objekte erzeugt, so sind sie somit auch in den danach aus dem Template erzeugten DBs vorhanden.
  • es ist möglich, an Stelle von template1 eine andere Template-Datenbank zu verwenden. Dazu dient die Syntax "create database ... template ....;"
  • template0 erlaubt keine Connections (datallowconn=f in pg_database) und dient als unveränderliches Basis-Template.
  • Änderungen an den Attributen in pg_database erfolgen als Update: damit kann man beispielsweise das Attribut datistemplate anpassen, um eine Datenbank zum Template zu machen (wodurch sie übrigens unlöschbar wird). Ich finde es zwar immer wieder unheimlich, wenn an Dictionary-Tabellen Anpassungen durch DML ausgeführt werden, aber in postgres ist das offenbar so vorgesehen.
Erstaunlich ist für mich dabei vor allem, wie wenig ich bisher über die Rolle der Template-Datenbanken nachgedacht habe...

Montag, September 05, 2016

Dictionary Metadaten in der Multitenant Infrastruktur

Franck Pachot hat seit 2014 eine Reihe interessanter Artikel zu den internen Implementierungsdetails der Dictionary-Zugriffe im Multitenant-Kontext veröffentlicht. Ich spare mir eine detaillierte Zusammenfassung der umfangreichen Inhalte und beschränke mich auf die Verweise:
Die Wahrscheinlichkeit ist hoch, dass ich damit nicht alle Artikel zum Thema erfasst habe, aber mir ging es eher darum, das Thema überhaupt einmal zu notieren, da ich bisher in Sachen Multitenant noch solide Wissenslücken habe.

    Mittwoch, August 31, 2016

    Statistikerfassung für Tabellen mit mehr als 255 Spalten mit dbms_stats

    Nur eine kurze Notiz auf einen Artikel von Randolf Geist, der erklärt, dass Oracle 12c eine deutliche Verbesserung bei der Erfassung von Statistiken für Tabellen mit sehr vielen Spalten eingeführt hat: in älteren Releases mussten die Statistiken für solche Tabellen mit mehr als 255 Spalten, deren Datensätze intern auf mehrere row pieces verteilt werden müssen, in mehreren Leseoperationen ermittelt werden (multi pass). Diese Einschränkung ist mit 12c aufgehoben: auch für Tabellen mit mehreren row pieces pro Datensatz benötigt die Statistikerfassung jetzt nur noch einen einzigen Zugriff (single pass), was die Performance der Operation deutlich verbessern kann.

    Montag, August 29, 2016

    Umwandlung von LONG in CLOB mit SYS_DBURIGEN

    Meine Standardantwort auf die Frage, wie man die Inhalte von LONG-Spalten auslesen kann, war seit vielen Jahren: ich hab's vergessen, aber Adrian Billington hat alles notiert, was man über diesen unerfreulichen Datentyp wissen muss. Diese Antwort kann ich jetzt modifizieren: der handlichste Weg, um LONGs in etwas weniger Häßliches zu verwandeln, ist die Verwendung der builtin-Funktion SYS_DBURIGEN, der von Marc Bleron (aka odi_63) in seinem Blog beschrieben wird. Intern erzeugt Oracle in diesem Zusammenhang ein DBURI Objekt und beim Aufruf der Funktion SYS_DBURIGEN(...).GETCLOB() wird eine SQL-Query generiert, die die erforderlichen Informationen abruft. Die Details des Aufrufs werde ich mir auch diesmal nicht merken, aber mit etwas Glück zumindest den Ort, an dem ich danach suchen kann.