Notizen zur In-Memory Option in Oracle 12c

Sie ist sicher das aufsehenerregendste Feature des gerade veröffentlichten Patch-Sets 12.1.0.2: die In-Memory Option. Wenn man das Marketing fragt, macht sie Zugriffe um den Faktor X schneller - wobei man für X so ziemlich jeden Wert einsetzen kann, der einem gerade einfällt: ein passendes Szenario dafür wird sich basteln lassen. Vor ein paar Tagen habe ich meinen Download des Patches durchgeführt, aber bis zur Installation bin ich noch nicht gekommen, daher bleiben meine Aussagen mal wieder auf der Ebene der Nacherzählung der Beobachtungen anderer Naturforscher:

• Jonathan Lewis: Analogy - liefert die von Maria Colgan formulierte Beschreibung der Grundidee der In-Memory Option in einem Satz: "In-memory columnar storage gives you bitmap indexes on OLTP systems without the usual disastrous locking side effects." Diese Zusammenfassung gefällt mir aus zwei Gründen: erstens ist sie griffig und zweitens passt sie zu einer entsprechenden Notiz die ich hier gelegentlich untergebracht hatte. Der Herr Lewis erläutert weiter:

  for each column stored you use a compression technique to pack the values for a large number of rows into a very small space, and for each stored row you can derive the rowid by arithmetic.  In highly concurrent OLTP systems there’s still room for some contention as the session journals are applied to the globally stored compressed columns (but then, private redo introduces some effects of that sort anyway); and the “indexes” have to be created dynamically as tables are initially accessed (but that’s a startup cost, it’s timing can be controlled, and it’s basically limited to a tablescan).

• Martin Klier: Oracle 12c InMemory – don’t stop thinking about performance - weist darauf hin, dass die In-Memory Option nicht automatisch der berühmte fast=true Parameter ist, sondern nur unter bestimmten Voraussetzungen eine bessere Performance mit sich bringt - und belegt diese Aussage mit einem Beispiel.
• Tim Hall: In-Memory Column Store in Oracle Database 12c Release 1 (12.1.0.2) - wenn es ein neues Oracle-Feature gibt, lässt Tim Halls einführendes Beispiel in der Regel nicht lange auf sich warten. Wenn ich mir die Option gelegentlich genauer anschaue, wird dieser Artikel wahrscheinlich der Ausgangspunkt sein. Unter anderem findet sich darin folgende Taxonomie:

  The documentation claims the IM column store is good for the following.

• Large scans that apply "=", "<", ">" and "IN" filters.
• Queries that return a small number of columns from a table with a large number of columns.
• Queries that join small tables to large tables.
• Queries that aggregate data.
It also states it is not designed for the following.
• Queries with complex predicates.
• Queries that return a large number of columns.
• Queries that return large numbers of rows.
• Queries with multiple large table joins.
• Maria Colgan: Oracle Database In-Memory & the Optimizer - die (ehemalige?) "Optimizer Lady" (und aktuelle "In-Memory Lady"?) erläutert, was der Optimizer von der In-Memory Option hält und wie er damit umgeht. Der erste wichtige Hinweis dabei ist, dass es sich immer noch um den alten kostenbasierten Optimizer handelt, der nur ein paar Ergänzungen für den Umgang mit den Herausforderungen der Optimierung mit In-Memory Strategien bekommen hat. Es gibt in diesem Zusammenhang ein paar neue Hints (angefangen mit: INMEMORY) und die Analyse der Entscheidungen des Optimizers erfolgt immer noch mit dem Event 10053. Die Einführung der Option erfordert keine Erfassung zusätzlicher Statistiken und keine Veränderungen an bestehenden Applikationen - in manchen Fällen kann es sinnvoll sein, bestimmte Indizes zu entfernen, die speziell zu Reporting-Zwecken erzeugt wurden, aber generell sind bestehende Indizes weiterhin wichtig; insbesondere, wenn sie zur Sicherstellung der referentiellen Integrität oder zum punktuellen OLTP-Zugriff benötigt werden. Wenn das alles stimmt, was Frau Colgan da schreibt - und ich habe grundsätzlich keinen Grund an ihren Worten zu zweifeln -, dann hat Oracle diese Integration ausgesprochen schmerzlos bewerkstelligen können. Im Oracle Database In-Memory Blog finden sich auch noch ein paar andere Artikel, die aber eher einführenden Charakter hatten.
• James Morle: Oracle’s In-Memory Database: The True Cost Of Licensing - erläutert einige technische Details der Memory-Nutzung und ihre Auswirkungen auf die Lizenzkosten (schlechtes Design führt zur Verschiebung von Operationen ins Memory, aber die sichtbare Konsequenz ist eine höhere CPU-Nutzung - statt bisher I/O und CPU - und wenn man zur Lösung der Probleme weitere CPUs ergänzt, steigen die Lizenzkosten; ohne dass die Probleme dadurch gelöst werden, denn eigentlich handelt es sich nicht um ein CPU-Problem).

An dieser Stelle beende ich meine Aufzählung, obwohl es noch zahlreiche weitere (und sicher ebenfalls lesenswerte) Artikel gibt - aber für den Moment genügt mir das Material. Der nächste Schritt ist die eigenständige Erkundung - ich frage mal beim Herrn Franklin nach, ob ich mir Terror und Erebus ausleihen kann...