Skip to main content
Enterprise applications
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Filesystemio_options

Beitragende kaminis85
PDFs

Der Oracle-Initialisierungsparameter filesystemio_options Steuert die Verwendung von asynchronem und direktem I/O.

Das Verhalten und die Empfehlungen für filesystemio_options auf ASA r2 sind identisch mit denen auf AFF/ FAS -Systemen, da der Parameter Oracle-spezifisch ist und nicht von der Speicherplattform abhängt. ASA r2 verwendet ONTAP wie AFF/ FAS, daher gelten die gleichen Best Practices.

Entgegen der allgemeinen Auffassung schließen sich asynchroner und direkter I/O nicht gegenseitig aus. NetApp hat festgestellt, dass dieser Parameter in Kundenumgebungen häufig falsch konfiguriert ist und dass diese Fehlkonfiguration direkt für viele Performance-Probleme verantwortlich ist.

Asynchroner I/O bedeutet, dass Oracle-I/O-Vorgänge parallelisiert werden können. Bevor asynchroner I/O auf verschiedenen Betriebssystemen verfügbar war, konfigurierten Anwender zahlreiche dbwriter-Prozesse und änderten die Serverprozesskonfiguration. Bei asynchronem I/O führt das Betriebssystem selbst I/O im Auftrag der Datenbanksoftware hocheffizient und parallel aus. Dieser Prozess gefährdet keine Daten, und kritische Vorgänge wie die Oracle-Wiederherstellungsprotokollierung werden weiterhin synchron ausgeführt.

Direkter I/O umgeht den Puffercache des Betriebssystems. I/O auf einem UNIX-System durchläuft normalerweise den Puffercache des Betriebssystems. Dies ist nützlich für Applikationen, die keinen internen Cache verwalten, aber Oracle hat einen eigenen Puffer-Cache innerhalb des SGA. In fast allen Fällen ist es besser, direkten I/O zu ermöglichen und dem SGA Server-RAM zuzuweisen, anstatt sich auf den Puffercache des Betriebssystems zu verlassen. Oracle SGA nutzt den Speicher effizienter. Wenn I/O den Puffer des Betriebssystems durchläuft, finden weitere Verarbeitungsschritte statt, wodurch die Latenzen erhöht werden. Die erhöhten Latenzen sind besonders bei umfangreichen I/O-Schreibvorgängen spürbar, bei denen eine niedrige Latenz eine wichtige Anforderung ist.

Die Optionen für filesystemio_options Sind:

  • Async. Oracle sendet I/O-Anfragen zur Verarbeitung an das Betriebssystem. Mit diesem Prozess kann Oracle andere Aufgaben ausführen, anstatt auf den I/O-Abschluss zu warten. Dadurch wird die I/O-Parallelisierung erhöht.

  • Directio. Oracle führt I/O direkt auf physische Dateien aus, anstatt I/O über den Host-BS-Cache zu leiten.

  • None. Oracle verwendet synchrone und gepufferte I/O. In dieser Konfiguration ist die Wahl zwischen Shared-Server- und dedizierten Server-Prozessen und der Anzahl der dbwriters wichtiger.

  • setall. Oracle verwendet sowohl asynchrone als auch direkte I/O. In fast allen Fällen, die Verwendung von setall Ist optimal.

Hinweis In ASM-Umgebungen verwendet Oracle automatisch Direct I/O und Asynchronous I/O für ASM-verwaltete Datenträger, so filesystemio_options hat keine Auswirkung auf ASM-Disk-Gruppen. Für Nicht-ASM-Bereitstellungen (z. B. Dateisysteme auf SAN-LUNs) gilt Folgendes: `filesystemio_options = setall`Die Dies ermöglicht sowohl asynchrone als auch direkte Ein-/Ausgabe für optimale Leistung.

Bei einigen älteren Betriebssystemen gab es Probleme mit asynchroner Ein-/Ausgabe, was zu veralteten Empfehlungen führte, diese zu vermeiden. Die asynchrone Ein-/Ausgabe ist jedoch stabil und wird von allen gängigen Betriebssystemen vollständig unterstützt. Es gibt keinen Grund, es zu deaktivieren, es sei denn, es wird ein spezifischer Fehler im Betriebssystem identifiziert.

Wenn in einer Datenbank gepufferte I/O verwendet wurden, könnte ein Wechsel zu direkten I/O auch eine Änderung der SGA-Größe rechtfertigen. Durch die Deaktivierung gepufferter I/O-Vorgänge werden die Performance-Vorteile eliminiert, die der Host-BS-Cache für die Datenbank bietet. Durch das Hinzufügen von RAM zum SGA wird dieses Problem behoben. Das Nettoergebnis sollte eine Verbesserung der I/O-Performance sein.

Obwohl es fast immer besser ist, RAM für Oracle SGA zu verwenden statt für das Zwischenspeichern von BS-Puffern, ist es unter Umständen nicht möglich, den besten Wert zu ermitteln. Es könnte beispielsweise besser sein, gepufferten I/O mit sehr kleinen SGA-Größen auf einem Datenbankserver mit vielen intermittierend aktiven Oracle-Instanzen zu verwenden. Diese Anordnung ermöglicht die flexible Nutzung des verbleibenden freien RAM auf dem Betriebssystem durch alle ausgeführten Datenbankinstanzen. Dies ist eine äußerst ungewöhnliche Situation, die jedoch an einigen Kundenstandorten beobachtet wurde.

Tipp * NetApp empfiehlt* Einstellung filesystemio_options Zu `setall`Beachten Sie jedoch, dass der Verlust des Host-Puffer-Caches unter bestimmten Umständen eine Vergrößerung der Oracle SGA erforderlich machen kann. ASA r2-Systeme sind für SAN-Workloads mit niedriger Latenz optimiert, daher passt die Verwendung von setall perfekt zum Design von ASA für leistungsstarke Oracle-Bereitstellungen.