Skip to Main Content

Breadcrumb

PEM für Oracle Datenbanken

Nutzung von PEM für Oracle Datenbanken

Seit einiger Zeit gibt es PEM - Persistent Memory für Server. Es handelt sich dabei um persistentes Server Memory, zumeist auf Intel Optane Basis, dessen Inhalt sowohl einen Reboot als auch eine längere Zeit ohne Strom ohne Datenverlust überlebt. Oracle nutzt PEM seit der Exadata X8 in den Storage Cells für Caching. Andere Hersteller wie HPE, Dell,... bieten dies für normale Server an. Damit man dieses Memory nutzen kann, gibt es mehrere Möglichkeiten, die wir her kurz vorstellen möchten.

Mögliche Nutzung von PEM in Servern für Oracle Datenbanken

  • Bei Datenbanken mit vielen Sorts auf Disk kann man ab Oracle 12c mit LOCAL TEMP TABLESPACES diese im PEM ablegen.
  • Für Datenbanken mit vielen Commits kann man die Online Logfiles ins PEM legen. Vorsicht: wenn der Server defekt wird, kann es zu Verlust der Online Logfiles führen!
  • Prinzipiell können ganze Datenbanken im Server Memory betrieben werden - Aber Vorsicht: Wenn es zu einem Serverdefekt kommt, kann die Datenbank verloren sein. Backups und Archivelog Files gehören definitiv auf ein anderes Medium.

Falsch konfiguriertes PEM kann zu Datenbank-Korruptionen führen!

Laut Oracle Doc ID 2608116.1 können Filesysteme und Devices auf PEM zu Datenbank-Korruptionen führen - Zitat:

File systems and raw devices based on Persistent Memory such as Intel Optane DC Persistent Memory or equivalent NV-RAM (Non-Volatile Random Access Memory) technology that is installed directly into the servers that run the database do not provide the needed integrity for storing Oracle database data.
Persistent Memory technology can also be built into storage products such as disk arrays, network file servers, and other storage shared across servers. Persistent Memory in such shared storage devices is not covered as part of this notice, and it is currently unknown whether these storage devices have similar integrity issues.
The only storage technology that uses persistent memory that is currently known to handle all the integrity needs of the Oracle Database is Oracle's Exadata X8M or later versions of Exadata.
This document does not apply to the use of Persistent Memory as large volatile memory - sometimes called Memory Mode. It only applies to using Persistent Memory to store the data file and log files that hold Oracle database data.

Laut Oracle gibt es aktuell (Feb 2020) dafür keine Lösung (und man soll doch einfach eine Exadata X8 kaufen....)

Oracle stellt mit der Datenbank Version 20c eine offizielle Unterstützung für PEM DB in Aussicht - siehe auch: Datenbank Admin Guide der Release 20c.

 

Oracle überlegt diese Funktionalität auf Oracle 19c zurück zu portieren (Stand 18. Feb 2020) - es gibt jedoch keine Info, wann das kommen soll. Ältere Oracle Datenbank Releases werden definitiv keinen Support dafür erhalten.

Was sagen andere Hersteller zu diesem Problem? Gibt es vielleicht eine andere Lösung?

Zumindest HPE hat sich dieses Problems angenommen, die Ursache genau analysiert und ein Support Bulletin mit einer Lösung verfasst.

Die Korruptionen dürften dadurch entstehen, dass Daten in den PEM Bereichen nicht aligned abgespeichert sind. Dadurch kann es passieren, dass verschiedene Prozesse beim "gleichzeitigen" Zugriff auf die Bereiche sich gegenseitig ins Gehege kommen. Die Lösung ist, dass man das PEM mit 4096 Bytes Sektoren und aligned konfiguriert.

Zum Verwalten von PEMs gibt es in Linux das Utility ndctl, das ab Red Hat 7 bzw OEL7 mitgeliefert wird.

Beispiel für Online Logfiles im PEM

Grundsätzlich eignet sich diese Einstellung für die komplette Datenbank. Der Zugriff erfolgt aber etwas langsamer als nötig - aber immer noch um Faktoren schneller als auf jede anderen Storage Lösung.

ndctl create-namespace -r region0 -m sector -l 4096

Beispiel für Datenbank Files im PEM

Erlaubt einen schnelleren Zugriff auf die Datenbank Files, kann jedoch bei Stromausfällen, Server- oder Datenbankabstürzen die Datenbank korrumpieren. Die dabei potentiell entstehenden korrupten Blöcke kann man mittels Media Recovery beheben.

ndctl create-namespace -r region0 -m fsdax -l 4096

Unabhängig davon empfiehlt HPE die Nutzung von Data Guard, wobei die Standby Datenbank nicht im PEM liegen sollte.

Weiterführende Informationen