Freitag, Januar 30, 2015

Einzelne Query aus dem Shared Pool löschen

Eigentlich war ich mir ziemlich sicher, dass ich hier irgendwo einen Link auf Kerry Osbornes Erläuterungen zum Löschen einer einzelnen Query aus dem Shared Pool untergebracht hätte - aber anscheinend ist das nicht der Fall. Daher hole ich zunächst dieses Versäumnis nach:
Auf die Suche nach diesen Links habe ich mich gemacht, weil Franck Pachot gerade einen Artikel zum gleichen Thema veröffentlicht hat, der mit einem Bind Peeking Problem einsetzt. Grundsätzlich ist die Möglichkeit der Löschung einer einzelnen Query aus dem Cache natürlich immer dann interessant, wenn man nicht den kompletten Shared Pool löschen will, sondern nur ein punktuelles Hard Parse hervorrufen möchte.

Dienstag, Januar 27, 2015

In-Memory Performance

Gerade habe ich noch mal überprüft, dass es Fälle gibt, in denen ich Artikel aus dem Oracle Scratchpad von Jonathan Lewis hier nicht verlinke. Das geschieht aber selten und gewöhnlich nur aus Gründen der Trägheit. Allerdings ist in der Tat nicht jeder Artikel von gleicher Bedeutung, manchmal sind die Themen auch relativ abgelegen und betreffen seltene Ausnahmefälle. Der aktuelle Artikel In-memory DB jedoch befasst sich mit einer recht grundsätzlichen Frage: wieso ist eine (column-store) In-Memory Datenbank effektiver als eine traditionelle (row-store) Datenbank, deren Daten sich komplett im Buffer Cache befinden?

Die Antwort erläutert zunächst das Verfahren beim traditionellen Tablescan einer komplett im Cache verfügbaren Tabelle: dabei muss für jeden einzelnen Block eine recht komplizierte Schrittfolge durchgeführt werden:
Oracle has to acquire the “cache buffers chains” latch, pin the block, drop the latch, and scan the block testing each row, then acquire the latch, unpin the block, and drop the latch.  Scanning the block requires a walk through the row directory and, for each row pointer, jumping to the correct location in the block for the row, stepping along the row one column at a time to get to the correct row, and then checking the column  value.
Im Fall des In-Memory Scans ist das Vorgehen ein grundsätzlich anderes:
  1. Für jede einzelne Spalte wird eine eigene In-Memory-Repräsentation erstellt, so dass das relevante Datenvolumen, auf das zugegriffen werden muss, unter Umständen massiv reduziert werden kann.
  2. Diese In-Memory-Repräsentation kann das im Speicher vorzuhaltende Datenvolumen durch Komprimierung/Deduplizierung noch einmal deutlich reduzieren. Diese Komprimierung ist ein grundsätzlicher Vorteil der column stores.
  3. Die In-Memory-Repräsentation wird in einzelne Chunks unterteilt, zu denen jeweils die low und high value Angaben bekannt sind, was es ermöglichen kann, komplette Chunks zu überspringen.
  4. Durch SIMD-Operationen (Single Instruction,  Multiple Data) kann der Zugriff im einzelnen Chunk weiter optimiert werden.
Für den Zugriff auf wenige Spalten ist das In-Memory-Verfahren in der Regel sehr effektiv - aber wenn sehr viele Spalten benötigt werden, kann dieser Vorteil gegenüber dem row-store verschwinden. Dabei gilt:
  • Using the In-memory Database, you can identify the rows you want very quickly but it’s relatively slow to reconstruct them.
  • Using a fully cached traditional row-store, it’s relatively slow to identify the rows you want, but once you’ve found them you spend no time reconstructing them.
Über diese grundsätzliche Analyse hinaus liefert der Artikel auch noch eine größere Anzahl von Links auf weitere Untersuchungen zum In-Memory-Thema - unter anderem auf Maria Colgans Artikelserie, aber auch auf andere relevante Beiträge.

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.