Alt, aber bezahlt: Oracle Disk Manager auf VxFS

Neues aus den Rubriken „Old Feature“ und „unbekannt oder unterbewertet„: Der Oracle Disk Manager (ODM)!

Nicht immer hat man als DBA in einem Unternehmen die Wahl, welche Speichersysteme man für die Datenbank einsetzt, und seien sie auch noch so effizient: Es gibt oft altertümliche Standards, gerne auch als „Best Practice“ bezeichnet (um sie über jeden Zweifel, jedes Gegenargument und jegliche Innovation erhaben zu machen), an die man sich halten muss. Ein solcher Standard ist die zwingende Nutzung von Dateisystemen anstelle von ASM und/oder Raw Volumes.

Worin aber sollen denn die Nachteile von Dateisystemen liegen? Sie sind doch so schön bequem handhabbar?

Double Buffering

Der erste, große Nachteil bei der Verwendung von Dateisystemen für Datenbankinhalte liegt in der doppelten Pufferung der Daten, nämlich

  • einerseits im DB Buffer Cache und
  • andererseits im Cache des Dateisystems.

Wenn in Oracle ein Datenblock gelesen wird, wird zunächst geprüft, ob er im Buffer Cache vorliegt. Falls ja, wird er von dort gelesen. Falls nicht, dann wird der Block aus der passenden Datei gelesen. Liegt die Datei nun in einem gepufferten Dateisystem, wird wiederum nachgesehen, ob die angeforderten Daten im Cache des Dateisystems liegen und andernfalls ein Zugriff auf die Festplatte ausgelöst. Diese Aneinanderreihung von Puffern nennt man auch „Double Buffering“ (es könnte auch noch ein „Triple Buffering“ werden, da viele Speichersysteme wiederum über ihren eigenen Cache verfügen).

Dieser zusätzliche Aufruf des Betriebssystems an das Dateisystem kostet Zeit und CPU-Leistung. Zeit, die schon einmal vom Oracle-Kernel aufgebracht wurde und unnötig ist. Es ist daher sinnvoll, ein Double Buffering zu vermeiden, um die CPU anderen Aufgaben zur Verfügung zu stellen.

Außerdem wird durch die doppelte Datenhaltung im Cache des Dateisystems RAM verschwendet und fragmentiert, das besser dem DB Buffer Cache zugewiesen werden sollte.

Direct I/O

Als Heilmittel gegen Double Buffering bieten viele Dateisysteme (u.a. VxFS, Solaris UFS, HP OnlineJFS) die Option „Direct I/O“ an, die einen direkten Zugriff auf Datenblöcke ohne zwischengeschalteten Cache ermöglicht. Oracle verwendet diese Zugriffsmethode, wenn der Parameter filesystemio_options=directio gesetzt ist.

Dummerweise ist dann im Dateisytem der Cache i.d.R. ganz abgeschaltet. Wenn nun also „klassische“ Dateioperationen (copy, zip/unzip, etc.) durchgeführt werden, werden diese deutlich verlangsamt. In der Praxis hatte ich bei tar sowie gunzip schon mal eine Verdopplung der Laufzeiten festgestellt.

Edit vom 16.10.2012:

Concurrent I/O

POSIX-konforme Dateisysteme sorgen zur Wahrung der Datenintegrität dafür, daß keine zwei Prozesse gleichzeitig in dieselbe Datei schreiben. Nun ist aber das Oracle RDBMS in der Lage, problemlos die Zugriffe auf eine Datei zu differenzieren, so daß mehrere Schreibzugriffe auf verschiedene Datenblöcke derselben Datei gleichzeitig möglich sind.

Dateisysteme, die konkurrierende Zugriffe nicht erlauben (Option „cio“ bei VxFS), sorgen also für zusätzliche Wartezeiten beim Schreiben in Datafiles.

Asynchronous I/O

Viele Dateisysteme verwenden synchrone Zugriffe, d.h. vereinfacht, daß bei Schreibzugriffen auf eine Datei diese Datei so lange gegen weitere Schreibzugriffe gesperrt ist, bis der erste Schreibzugriff beendet wird (Oft auch „Blocking I/O“ genannt).

Einige Betriebs-/Dateisystem-Kombinationen verwenden synchrone Zugriffe, das bedeutet vereinfacht, daß I/O-Operationen zuerst abgeschlossen sein müssen, bevor die nächste Operation gestartet werden darf  (oft auch „Blocking I/O“ genannt). Eine derartige, „zwangsweise“ Serialisierung stellt für I/O-intensive-Umgebungen einen engen Flaschenhals dar.

(Ende Edit)

Ab Oracle 10.1 kann asynchronous I/O ohne Patches verwendet werden. Bis einschließlich 9.2.0.6 ist ein Patch notwendig, siehe Oracle Note 428355.1. Asynch I/O wird mit folgenden Parametern in der init.ora aktiviert:

  • disk_asynch_io=TRUE
  • filesystemio_options=ASYNCH # oder SETALL f. Asynch + Direct I/O

Damit Oracle asynchronen I/O durchführen kann, muss dies vom Kernel des Betriebssystems („kaio“) bzw. vom Dateisystem unterstützt werden. Hier eine kleine Aufstellung, ohne Gewähr und ohne Anspruch auf Vollständigkeit:

OS Asynch I/O verfügbar?
Solaris KAIO verfügbar für Raw Devices und Quick I/O files.
Keine besondere Konfiguration erforderlich.
HP-UX KAIO verfügbar für Raw Devices und Quick I/O files.
AIX KAIO verfügbar für Raw Devices und virtuelle oder Hashed Shared Disks.Konfiguration erforderlich.
Tru64 Unix KAIO verfügbar für Raw Devices.
No special configuration is required.
Irix KAIO verfügbar für Raw Devices.
Keine besondere Konfiguration erforderlich.
Reliant Unix KAIO verfügbar für Raw Devices.
Konfiguration erforderlich.
Linux Verfügbar ab Kernel 2.6. Siehe Oracle Note 225751.1
Windows Verfügbar unter Microsoft Windows x64, Windows NT and Windows 2000 (s. Oracle und Microsoft)

Außer bei Linux ist asynchroner I/O in Verbindung mit Dateisystemen also nicht so leicht zu haben. Das gilt insbesondere für HP-UX. Allerdings taucht in der Tabelle der Begriff „Quick I/O Files“ auf, und dieser führt uns direkt zu dem Nachfolger dieses Features, dem

Oracle Disk Manager

Oracle ermöglicht seit der Version 9i in Verbindung mit dem weit verbreiteten Veritas File System (VxFS) sowohl einen asynchronen als auch den ungepufferten Zugriff auf Dateien im Dateisystem mit Hilfe des ODM. Der ODM  wird als Shared Library zum DB-Kernel mitgeliefert. Er setzt voraus, daß die (lizenzpflichtige) Option „Quick I/O“ (qio) im Filesystem aktiviert ist. Asynch und Direct I/O finden dann automatisch statt, unabhängig von den Einstellungen der DB-Parameter.

Das Dateisystem VxFS muss dann folgendermaßen gemountet sein:

mount -F vxfs -o qio <device_name> <mount_point>

Dann muss die beim Dateisystem mitgelieferte Shared Library anstelle der von Oracle gelieferten eingesetzt werden, z.B. unter Solaris:

mv ${ORACLE_HOME}/lib/libodm11.so ${ORACLE_HOME}/lib/libodm11.so.bak
ln -s /opt/VRTSodm/lib/sparcv9/libodm.so ${ORACLE_HOME}/lib/libodm11.so
Die Datenbank kann nun hochgefahren werden und wird den ODM automatisch benutzen. Dies können wir im Alert Log auslesen, z.B. ab Oracle 11g:
adrci> show alert -p "message_text like '%ODM%'"

2012-10-04 13:05:05.060000 +02:00
Oracle instance running with ODM: Veritas 5.1 ODM Library, Version 2.0
Im laufenden Betrieb wird dann das virtuelle Gerät „/dev/odm“ angelegt, das einige, informative Dateien enthält. Damit kann geprüft werden, ob ODM aktiv ist:
# cat /dev/odm/stats
Auch im Data Dictionary kann geprüft werden, ob ODM für den Dateizugriff verwendet wird. In der Spalte „Access Method“ steht dann „ODM_LIB“ anstelle von üblicherweise „OS_LIB“:
SELECT f.name, i.asynch_io, i.access_method
  FROM v$datafile f, v$iostat_file i
 WHERE f.file# = i.file_no
   AND filetype_name IN( 'Data File', 'Temp File' );
NAME                                      ASYNCH_IO FILETYPE_ ACCESS_METHOD
----------------------------------------- --------- --------- -------------
/oradata/ORCL/datafile/system_01.dbf      ASYNC_ON  Data File ODM_LIB
/oradata/ORCL/datafile/system_01.dbf      ASYNC_ON  Temp File ODM_LIB
/oradata/ORCL/datafile/sysaux_01.dbf      ASYNC_ON  Data File ODM_LIB
/oradata/ORCL/datafile/sysaux_01.dbf      ASYNC_ON  Temp File ODM_LIB
/oradata/ORCL/datafile/undotbs02_05.dbf   ASYNC_ON  Data File ODM_LIB
/oradata/ORCL/datafile/undotbs02_05.dbf   ASYNC_ON  Temp File ODM_LIB
/oradata/ORCL/datafile/users_01.dbf       ASYNC_ON  Data File ODM_LIB
/oradata/ORCL/datafile/tools_01.dbf       ASYNC_ON  Data File ODM_LIB

Probleme ab Oracle 11.2.0.3

Oracle 11.2.0.3 führt eine Änderung in der API ein, die die Zugriffe auf den ODM durchführt. Dies führt bei Datenbanken im Archive Log Mode (also wohl den meisten, produktiven Datenbanken) zu Abbrüchen bereits beim Hochfahren:

ORA-00600: internal error code, arguments: [ksfd_odmcrt8], [ODM ERROR V-41-4-1-105-22 Invalid argument], ...

Ein aktuelles Patchlevel von VRTSodm behebt das Problem. Siehe Symantec Tech Note 173597 und Oracle Doc ID 1380169.1.

Fazit

Wenn man die Verwendung von Dateisystemen für DBFiles nicht vermeiden kann und VxFS mit lizensierter „Storage Foundation for Oracle“ zur Verfügung steht, dann kann man mit dem „Oracle Disk Manager“ annähernd die Performance von Raw Volumes erreichen, ohne die administrativen Vorteile von Dateisystemen aufgeben zu müssen.

Die tatsächliche Performance für eine spezifische Anwendung sollte allerdings in eigenen Tests gegenüber anderen, möglichen Konfigurationen verifiziert werden!

Weblinks

2 Gedanken zu „Alt, aber bezahlt: Oracle Disk Manager auf VxFS

  1. Randolf Geist

    Hallo Uwe,

    ich glaube, dass Deine Beschreibung von „Asynchronous I/O“ mehrere Sachen durcheinander wirft – Asynchrones I/O beschreibt m.E. erst mal die Fähigkeit, dass I/O nicht synchron vom Oracle Kernel verwendet wird, d.h. der jeweilige Thread wartet, bis der Funktionsaufruf beendet ist, sondern mehrere I/Os von einem Thread zur gleichen Zeit „non-blocking“ abgesetzt werden können, und die Daten dann bei Verfügbarkeit verarbeitet werden, was mehrere Vorteile liefert, da der Oracle Kernel-Code nicht blockiert ist, und der OS-Kernel bzw. die darunterliegende Treiberschicht die erhöhte Anzahl von I/Os besser optimieren kann (batches / queueing / reordering etc.), aber auch vom O/S eben entsprechend unterstützt werden muss, da es wesentlich komplexer bezüglich der Implementierung ist.

    Es gibt zusätzlich grundsätzlich bei Posix-konformen Dateisystemen das Problem, dass nur ein Prozess gleichzeitig in die Datei schreiben darf, was, wie Du beschreibst, bei Oracle ja unnötig ist, da Oracle selbst die Schreibaktivitäten koordiniert und konkurrierende Zugriffe verhindert. Wenn ein Filesystem erlaubt, diese für Oracle künstliche Limitierung zu umgehen, wird manchmal auch von „Concurrent I/O“ gesprochen.

    Insofern ist m.E. Asynchronous I/O nicht gleichzusetzen mit Concurrent I/O, die angesprochenen Lösungen versuchen aber meistens, alle drei Sachen anzugehen: Direct I/O, Asynchronous I/O und Concurrent I/O.

    Das macht dann auch verständlich, warum Oracle ASM eingeführt hat, da es eben genau diese drei Grundprobleme bei der Verwendung von Dateisystemen umgeht, und natürlich noch einige andere Funktionalitäten liefert.

    Herzliche Grüße,
    Randolf

    Gefällt mir

    Antwort
    1. Uwe M. Küchler Autor

      Hallo Randolf,
      vielen Dank für Deine Ergänzungen zu Async/Direct/Concurrent I/O!

      Ehrlich gesagt, hatte ich auch schon auf eine Reaktion aus der Community gewartet, da mir bereits beim Schreiben des Artikels klar wurde, daß die Abschnitte über Async und Direct I/O eigentlich den Rahmen dieses Themas sprengen. Mein Versuch der Vereinfachung dieser Abschnitte musste da wohl fast zwangsläufig zu einer zu starken Vereinfachung führen… Ich werde den Absatz nochmal anpassen, um das „Blocking“ und die damit einhergehende Serialisierung der Zugriffe stärker hervorzuheben.

      Dasselbe gilt für „Concurrent I/O“, das ja gerade unter VxFS eine mögliche Option ist. Das hatte ich ebenfalls zur Vereinfachung nicht explizit erwähnt (es sollte ja primär um den ODM gehen). Ja, es ist nicht gleichzusetzen mit Async I/O — das wird gleich korrigiert.

      Beste Grüße,
      Uwe

      Gefällt mir

      Antwort

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s