Instance Parameter FILESYSTEMIO_OPTIONS

updated on

Mit diesem Parameter konfiguriert man Eigenschaften, mit welchen Technologien der Zugriff auf die Datenbankfiles erfolgt. Dabei gibt es viele Missverständnisse, die letztendlich zu suboptimaler Datenbank IO Performance führen.

Welche Einstellungen gibt es für den Parameter?

Die Konfigurationsmöglichkeiten sind seit Oracle 7 grundsätzlich gleich geblieben, siehe Oracle 23ai Dokumentation.

mögliche Werte

  • NONE: Async und Direct I/O deaktiviert
  • SETALL: Async und Direct I/O aktiviert
  • DIRECTIO: Async I/O deaktiviert, Direct I/O aktiviert
  • ASYNCH: Async I/O aktiviert, Direct I/O deaktiviert

Der Default Wert für FILESYSTEMIO_OPTIONS ist vom Betriebssystem abhängig:

  • AIX: ASYNCH, allerdings empfehlen sowohl IBM als auch viele Storage Hersteller, dass man SETALL nutzen soll.
  • Linux, Windows: NONE – und genau dieser Default ist eine Performancefalle!

Was bedeutet Async bzw. Direct I/O eigentlich?

Unter Async I/O versteht man, dass ein Prozess einen I/O Request in Richtung Storage sendet und dann mit seiner Tätigkeit weiter macht. Sobald der angeforderte Block von der Storage angekommen ist, wird der Prozess informiert und kann entsprechend weiter arbeiten. Dies ist speziell dann interessant, wenn ein Prozess mehrere Blöcke „gleichzeitig“ verarbeitet, zum Beispiels wenn der DBWR mehrere Blöcke auf die Disk schreiben möchte oder wenn ein Statement bei einem Full Table Scan viele Blöcke einlesen muss. Wenn Async I/O deaktiviert ist, spricht man von Sync I/O. In diesem Fall wartet der Prozess darauf, dass die I/O Operation abgeschlossen ist. Dadurch limitiert man die Anzahl der pro Zeiteinheit verarbeitbarer Blöcke. Die Performance hängt extrem von der Storage Latenz ab, weil man bei jeder I/O Operation eben die durchschnittliche I/O Latenz warten muss, bis man weiter verarbeiten kann.

Ist Direct I/O aktiviert, wird das Filesystem Cache des Betriebssystems umgangen. Dadurch, dass der I/O nicht über das Filesystem Cache abgewickelt wird, reduziert man den CPU Bedarf für den I/O Request. Da Oracle Datenbanken über ein sehr gutes Buffer Cache Mangement verfügen, ist dies in der Regel genau das erwünschte Verhalten. Es macht in der Praxis mehr Sinn, dass man der Datenbank Instanz mehr Hauptspeicher zur Verfügung stellt, weil die Datenbank einfach viel genauer weiss, welche Blöcke wirklich benötigt werden. Es gibt jedoch Ausnahmen davon. Bei einigen Oracle Verarbeitungen wird der Buffer Cache nicht genutzt – speziell bei Parallelverarbeitungen, die FTSs nutzen. Man erkennt dies bei Oracle an den I/O Statistiken „db file parallel read“ sowie „db file parallel write“. Im Fall von I/Os bei Sorts gibt es die I/O Statistiken „Direct path reads“ bzw „Direct path writes“.

Besonderheiten

  • Liegen die Files im ASM, ignoriert Oracle die Einstellung für diese Files und nutzt immer SETALL. Trotzdem sollte man den Parameter setzen: wenn man beispielsweise ein Datenbankbackup auf ein Filesystem schreibt, gilt die Einstellung für den Parameter für das Schreiben der Backupsets.
  • Liegen Datenbankfiles auf NFS, gibt es kein Filesystem Cache am Server, daher ist es wichtig, dass man hier immer Direct I/O nutzt. Außerdem sollte man zusätzlich Oracle dNFS konfigurieren (dNFS nutzt immer SETALL, trotzdem soll man es konfigurieren, wenn Oracle ein Fallback auf den OS NFS Stack machen muss).

Wie soll man FILESYSTEMIO_OPTIONS jetzt einstellen?

In 95% der Fälle ist die Einstellung FILESYSTEMIO_OPTIONS = SETALL bei entsprechend konfigurierten Buffer Cache das Optimale. Es gibt jedoch eine Ausnahme von dieser Regel. Sofern man deutlich mehr direct path I/Os im Vergleich zu „db file sequential read“ / „db file scattered reads“ in den Statistiken findet, kann man probieren den Buffer Cache zu Gunsten des Filesystem Caches zu verkleinern und FILESYSTEMIO_OPTIONS auf ASYNCH zu stellen. Alternativ kann den Oracle Optimizer dazu anhalten, dass Parallel Queries immer das Buffer Cache nutzen, indem man die Tabellen mit dem CACHE Attribut versieht. Dies kann aber dazu führen, dass die Buffer Cache Inhalte für andere – nicht parallelisierte – Statements nicht zur Verfügung stehen, wodurch diese langsamer werden.

Je nach Anwendung und abhängig von der Storage Latenz (je höher diese ist, um so mehr bringt Async I/O) kann man die Laufzeit von I/O intensiven Statements teilweise um Faktoren verkürzen.

Referenzen