Montag, Januar 26, 2015

Oracle Sample Schemas auf GitHub

Wieder nur eine kurze Notiz, aber eine mit einem aus meiner Sicht recht bedeutsamen Inhalt: wie man von Christopher Jones erfährt gibt es Oracles Beispiel-Schemata seit kurzem als Repository auf GitHub:
This repository contains a copy of the Oracle Database sample schemas that are installed with Oracle Database Enterprise Edition 12c. These schemas are used in Oracle documentation to show SQL language concepts. The schemas themselves are documented in Oracle Database Sample Schemas, 12c Release 1 (12.1)
The schemas are:
  • HR: Human Resources
  • OE: Order Entry
  • PM: Product Media
  • IX: Information Exchange
  • SH: Sales History
  • BI: Business Intelligence
Due to widespread dependence on these scripts in their current form, no pull requests for changes can be accepted.
Klingt vielleicht nicht besonders aufregend, vereinfacht den Aufbau nachvollziehbarer Beispiele aber ganz erheblich.

Mittwoch, Januar 21, 2015

Größe des Initial Extents für Partitionierte Tabellen

Dom Brooks weist in seinem Blog auf zwei Punkte hin, von denen mir (wie ihm) der erste komplett entgangen war:
  • die Default-Größe des Initial Extents für partitionierte Tabelle ist seit 11.2.0.2 auf 8MB erhöht worden, davor betrug sie 64KB. Das kann im Fall geringfügig gefüllter Partitionen zur Verschwendung von Speicherplatz führen, wobei solche Partitionen natürlich unter Umständen auch ein Anlass sein könnten, über die Partitionierungsstrategie nachzudenken.
  • der zweite Punkt war mir klar: da die Maximalanzahl der Partitionen in einer Tabelle 1024K -1 = 1048575 beträgt, kann man bei Interval Partitionierung bei Auswahl kleinerer Intervalle relativ leicht an die Begrenzungen stossen.
Beide Effekte werden anhand aussagekräftiger Beispiele erläutert.

Dienstag, Januar 20, 2015

NLS_LANG für Oracle unter Windows

Vor ein paar Jahren habe ich hier eine ausgesprochen knappe Notiz untergebracht, um mich daran zu erinnern, den Registry-Schlüssel NLS_LANG unter Windows auf GERMAN_GERMANY.WE8PC850 zu setzen, um eine korrekten Darstellung von Umlauten in sqlplus zu erhalten. Dass man den Sachverhalt auch umfassend analysieren kann, hat mir jetzt Franck Pachot gezeigt, der das unterschiedliche Verhalten von WE8MSWIN1252 und WE8PC850 detailliert beschreibt: dabei ist WE8MSWIN1252 die default-Einstellung in der Registry und für GUI-Tools durchaus geeignet. Sqlplus allerdings ist ein DOS commend line Tool und verwendet eine andere Codepage - nämlich 850. Für die korrekte Darstellung innerhalb von sqlplus ist daher WE8PC850 gut geeignet - aber leider werden Daten, die aus sqlplus via spool in eine Datei geschrieben werden, die man dann mit einer Windows-Applikation (sagen wir: notepad.exe) öffnet, ebenfalls mit Codepage 850 kodiert - und das führt dann unter Umständen in der Ausgabe zu Problemen. Im Artikel wird der Sachverhalt noch genauer erläutert, aber ich breche die Nacherzählung an dieser Stelle ab und verweise auf die Quelle.

P.S.: vermutlich wusste ich das alles mal, hatte es aber inzwischen komplett aus meinem Gedächtnis gelöscht.

Dienstag, Januar 13, 2015

Parallel Query, OR Expansion und überflüssige Buffer Sorts

In den letzten Tagen hat Randolf Geist zwei Artikel zum Auftreten von überflüssigen Buffer Sort Operationen bei der Ausführung paralleler Queries veröffentlicht:
  • Unnecessary BUFFER SORT Operations - Parallel Concatenation Transformation: zeigt, dass die Kombination von Paralleler Query und einer OR Expansion Transformation (OR verknüpfte Prädikate werden in zwei über UNION ALL verbundene Teil-Queries aufgeteilt, wobei unerwünschte Duplikate durch Verwendung der LNNVL-Funktion vermieden werden) zum Auftreten überflüssiger Buffer Sort Operationen führen kann, die die Vorteile der Parallelisierung als blocking operation massiv reduzieren (und die Ressourcennutzung erhöhen). Ähnliche Effekte können auch beim manuellen Rewrite solcher UNION ALL-Konstrukte auftreten.
  • "SELECT * FROM TABLE" Runs Out Of TEMP Space: zeigt einen Fall, in dem sich ähnliche Buffer Sort Steps bei einem einfachen parallel ausgeführten "SELECT * FROM table" ergeben, wobei es sich um ein Exadata System und eine partitionierte Tabelle handelt, die über HCC komprimiert ist. Dabei führt die Zwischenspeicherung der Ergebnisse zu extremen Laufzeiten, weil die ersten Datensätze erst geliefert werden, wenn die gesamte Tabelle in den Buffer geladen wurde - und potentiell kann es zu einem Abbruch der Ausführung kommen, wenn das Datenvolumen einer entpackten Partition größer ist als der TEMP space. Auch in diesem Fall ist eine Concatenation Transformation im Spiel, die auf eine andere Transformation folgt, nämlich auf eine "table expansion", die es erlaubt einige Partitionen (auf die ein selektiver Zugriff erfolgt) via Index zu lesen und andere (bei denen der Zugriff nicht selektiv ist) via Full Scan, indem dort die Index-Partionen unusable gemacht werden. Natürlich gibt es mehrere mögliche Workarounds (Verzicht auf Parallelisierung, Verzicht auf table expansion), aber offenbar ist die OR Expansion auch in dieser Situation ein potentielles Problem - obwohl sie im ersten Moment so harmlos wirkt...
Ich habe in der Überschrift und auch im Text mehrfach von OR Expansion gesprochen, obwohl die Transformation in den Artikeln als Concatenation Transformation angesprochen wird, gehe aber bis ich eines Besseren belehrt werde davon aus, dass es sich nur um zwei Namen für die gleiche Sache handelt.

Nachtrag 14.01.2015: die Antwort auf die Frage nach der Identität von OR Expansion und Concatenation Transformation bleibt erst mal offen: Randolf Geist bestätigte meine Einschätzung, dass es sich um die gleiche Transformation handelt, aber Stefan Koehler ist anderer Meinung - und auch der Herr Koehler hat in der Regel sehr gute Gründe für solche Aussagen.

Mittwoch, Januar 07, 2015

SQL Server Admin-Skripts

Wenn ich mich wieder mal als DBA für einen SQL Server ausgeben möchte, sollte ich mich an folgenden Rat von Brent Ozar erinnern:
If you’re a production database administrator responsible for backups, corruption checking, and index maintenance on SQL Server, try Ola Hallengren’s free database maintenance scripts. They’re better than yours (trust me), and they give you more flexibility than built-in maintenance plans.
Im Fall meiner SQL Server "Skriptsammlung" hat der Herr Ozar jedenfalls recht: die Hallgrenschen Skripte sind besser als meine.

Und gerade sehe ich, dass Erin Stellato zuletzt mehrere Artikel zur Durchführung von Health Checks im SQL Server veröffentlicht hat, die ich hier auch noch verlinke: