{"id":61200,"date":"2015-12-03T11:10:37","date_gmt":"2015-12-03T10:10:37","guid":{"rendered":"http:\/\/e3mag.com\/?p=61200"},"modified":"2019-07-18T09:21:46","modified_gmt":"2019-07-18T07:21:46","slug":"in-memory-ist-nicht-genug","status":"publish","type":"post","link":"https:\/\/e3mag.com\/de\/in-memory-ist-nicht-genug\/","title":{"rendered":"In-memory ist nicht genug"},"content":{"rendered":"

Selbst bei SAP hat man inzwischen eingesehen, dass die urspr\u00fcngliche, so genial einfach erscheinende Idee, s\u00e4mtliche Daten permanent im Memory zu halten, teils nicht durchf\u00fchrbar, teils nicht genug ist.<\/p>\n

Sie ist etwa dann nicht durchf\u00fchrbar, wenn eine Datenbank in gr\u00f6\u00dferem Umfang historische Daten enth\u00e4lt, deren Laden ins Memory zu einer Kostenexplosion beim ben\u00f6tigten Memory f\u00fchren w\u00fcrde.<\/p>

\"\"<\/a><\/div><\/div>\n

Daten permanent im Memory zu halten gen\u00fcgt au\u00dferdem nicht, weil jede Datenbank die Persistenz der in ihr abgelegten Daten gew\u00e4hrleisten muss.<\/p>\n

Es ist demnach notwendig, persistente Speichermedien zu nutzen, und sinnvoll, sich \u00fcber die m\u00f6glichst effiziente Nutzung dieses Speichers Gedanken zu machen. In der Oracle-Datenbank gibt es seit vielen Versionen schon zwei Technologien, die dieser effizienten Nutzung dienen:<\/p>\n

Partitionierung und Komprimierung. Und es gibt zwei Technologien, weil das Wort \u201eeffizient\u201c zwei verschiedene Bedeutungen haben kann.<\/p>\n

Was zusammengeh\u00f6rt: Partitionierung<\/h3>\n

\u201eEffiziente Nutzung des Speicherplatzes\u201c \u2013 das kann zun\u00e4chst einmal hei\u00dfen: Daten sollen so abgelegt werden, dass beim Zugriff auf noch nicht im Memory befindliche Informationen m\u00f6glichst wenige I\/O-Vorg\u00e4nge stattfinden m\u00fcssen.<\/p>\n

\u201eOptimierung der Datenspeicherung\u201c bedeutet dann, dass Daten nicht (wie es standardm\u00e4\u00dfig geschieht) in zuf\u00e4lliger Reihenfolge abgelegt werden, sondern unter Ber\u00fccksichtigung der Frage, welche Datengruppen sp\u00e4ter wieder gemeinsam ben\u00f6tigt werden.<\/p>\n

Eine Tabelle zu parti\u00adtionieren hei\u00dft, sie in solche Teilgruppen zu zerlegen. Eine Partition beinhaltet dann beispielsweise alle Daten, die in einem bestimmten Monat neu eingef\u00fcgt wurden oder einer bestimmten Filiale zugeordnet sind.<\/p>\n

F\u00fcr SAP-on-Oracle-Kunden ist die Partitionierung bei SAP BW standardm\u00e4\u00dfig eingeschaltet, sie profitieren also sofort davon. Freigegeben und unterst\u00fctzt ist Oracle Partitioning aber f\u00fcr alle SAP-NetWeaver-Applikationen. Es kann also auch in Nicht-BW-Systemen eingesetzt werden. F\u00fcr die Implementierung steht dann z. B. die SAP Partitioning Engine zur Verf\u00fcgung.<\/p>\n

Komprimierung<\/h3>\n

\u201eEffiziente Nutzung des Speicherplatzes\u201c kann aber auch hei\u00dfen: Daten sollen so abgelegt werden, dass sie m\u00f6glichst wenig Speicherplatz beanspruchen und dass das gigantische Wachstum der Datenbanken gebremst werden kann.<\/p>\n

\u00dcber mehrere Versionen der Datenbank-Software hinweg betrachtet, bedeutet das, dass die Effizienz der Datenspeicherung permanent gesteigert werden muss, sodass der gleiche Datenbestand von Version zu Version immer weniger Speicherplatz beansprucht.<\/p>\n

Und eine zus\u00e4tzliche Forderung hei\u00dft, dass all dies geschehen soll, ohne dass der Kunde daf\u00fcr den Preis einer Performance-Verschlechterung bezahlen muss.<\/p>\n

Bereits Oracle Database 11g setzte auf das Konzept, Werte, die mehrfach auftauchen, nicht mehrfach zu schreiben. Das gilt f\u00fcr Tabellen ebenso wie f\u00fcr Indizes. Die Komprimierungsrate, die dadurch erreicht werden kann, h\u00e4ngt von der Charakteristik der Daten und von der Anwendung ab.<\/p>\n

\u00dcblicherweise k\u00f6nnen Daten aus SAP BW (BI) st\u00e4rker komprimiert werden als Daten aus SAP ERP (ECC), und SAP CRM erlaubt sogar noch gr\u00f6\u00dfere Einsparungen. Im Schnitt ben\u00f6tigt eine mit Oracle Database 11g vollst\u00e4ndig komprimierte Datenbank im SAP-Umfeld 55 Prozent weniger Speicherplatz als die entsprechende unkomprimierte.<\/p>\n

Auf die Temperatur kommt es an<\/h3>\n

Eine h\u00e4ufig gestellte Frage lautet: Warum wird eigentlich die komprimierte Abspeicherung von Daten nicht zum Standard gemacht?<\/p>\n

Einen Teil der Antwort erh\u00e4lt man, wenn man auf diejenigen SAP-BW-Tabellen blickt, die f\u00fcr das Laden neuer Daten verwendet werden. Solche Tabellen w\u00fcrde man gerne komprimieren, aber das w\u00fcrde den Ladevorgang erheblich verz\u00f6gern.<\/p>\n

Hier setzt Oracle Database 12c an, und zwar durch die Einf\u00fchrung eines neuen Parameters. In Version 11g kann der Anwender im Hinblick auf jede Tabelle und jeden Index die Frage beantworten, ob dieses Objekt komprimiert werden soll.<\/p>\n

M\u00f6gliche Antworten sind \u201eJa\u201c oder \u201eNein\u201c. In Version 12c wird zus\u00e4tzlich die Frage gestellt, wann neue oder ge\u00e4nderte Daten komprimiert werden sollen. M\u00f6glich sind nun also Antworten der Art: \u201eJa, aber erst in einer Woche.\u201c<\/p>\n

Erst durch diesen neuen Parameter k\u00f6nnen die f\u00fcr das Laden von Daten ben\u00f6tigten Tabellen in die Komprimierung einbezogen werden: Geladen werden zun\u00e4chst unkomprimierte Daten (keine Verl\u00e4ngerung der Laufzeit), die erst nachtr\u00e4glich, d. h. zu einem geeigneten Zeitpunkt komprimiert werden (deferred compression).<\/p>\n

Diese L\u00f6sung wurde in Oracle Data\u00adbase 12c so generell gestaltet, dass sich mit ihr ein komplettes Information Lifecycle Management (ILM) implementieren l\u00e4sst. Es st\u00fctzt sich auf zwei neue Features:<\/p>\n