Oracle Datenbank 12c Release 2: Parallel NFS und Performance

Oracle hat die direkte NFS-Implementierung (dNFS) mit Oracle 11g Release 1 eingeführt. Das bedeutet, dass die Datenbankprozesse eigene NFS-Verbindungen erzeugen und nicht auf das NFS des Betriebssystems angewiesen sind. Zu diesem Zeitpunkt wurde lediglich NFS v3 unterstützt. Die Unterstützung für NFS v4.0 und NFS v4.1 (ohne pNFS) ist mit Oracle 12c Release 1 hinzugekommen. Die Unterstützung von Parallel NFS folgt nun mit Oracle 12c Release 2.
Was bedeutet direct NFS genau und welche Vorteile bietet es?
Wenn man von NFS spricht, versteht man darunter ein Protokoll, mit dem man Verzeichnisse von anderen Systemen lokal anbinden kann. Dazu braucht man einerseits NFS Server, um ein Verzeichnis freigeben zu können, und andererseits NFS Clients, um ein freigegebenes Verzeichnis lokal einzubinden. Möchte jetzt ein Prozess auf dieses NFS Share zugreifen, wird der Zugriff an den NFS Client übergeben, der sich um die Kommunikation mit dem NFS Server kümmert. Dieser Zwischenschritt (Kommunikation mit dem NFS Client und dessen Verarbeitung) bedeutet in weiterer Folge, dass die Daten mindestens einmal im Memory kopiert werden müssen, es zu einem oder mehreren Context Switches (wechseln von einem Prozess zu einem anderen) kommt und natürlich CPU-Zeit konsumiert wird.
Die NFS Clients wurden für den Zugriff auf Dateien, aber nicht für zufällige Zugriffe, die eine Datenbank benötigt, optimiert.
Bei Oracle direct NFS verbindet (mountet) sich jeder Oracle-Prozess mit jenen NFS Shares, auf die dieser zugreifen muss, selbst. Dadurch wird der lokale NFS Client umgangen – er wird nicht mehr benötigt, muss aber als eine Art "Fallback" trotzdem existieren und konfiguriert sein. Der wesentliche Vorteil ist, dass jeder Oracle-Prozess eine eigene "I/O Queue" hat, sprich, sich um seine eigenen I/Os kümmert. Im Fall von NFS Clients werden alle Zugriffe über eine (oder wenige) I/O Queues verwaltet – was dazu führt, dass ein I/O nicht sofort an den NFS Server geschickt wird, sondern zuerst lokal im NFS Client warten muss, bis er verarbeitet werden kann.
Wir haben schon bei vielen Kunden POCs unter dem Titel "Oracle dNFS versus OS NFS" gemacht und typischerweise eine Durchsatzsteigerung von 50 – 100 Prozent nachweisen können, wobei gleichzeitig die CPU-Belastung deutlich reduziert wurde [1].
Was ist der Unterschied zwischen NFS v3, NFS v4.0, NFS v4.1 und pNFS?
Der wesentliche Unterschied zwischen NFS v3 und den anderen Versionen liegt in der Architektur. Während NFS v3 sehr simpel gestrickt ist – es existiert schon seit 1995 – fehlen viele Funktionalitäten, die man sich von einem Filesystem eigentlich wünscht. Dies sind beispielsweise:
- Unterstützung eines einheitlichen Namensbereiches (Namespace)
- Unterstützung für Migration und Replikation
- Zusammenfassung mehrere Operationen zu einem Aufruf (Compound Operations)
- Echtes Sperren von Files (File Locking) – NFS v3 nutzt dazu den Network Lock Manager, ab NFS v4 ist das ein integraler Bestandteil von NFS.
Die Version NFS v4.1 erweitert das Protokoll um die Unterstützung von Storage Clustern und enthält auch schon die parallel NFS-Funktionalität.
Im Internet findet man sehr viele Benchmarks "NFS v3 versus v4", bei denen (fast) alle feststellen, dass NFS v4 langsamer ist als NFS v3. Die meisten dieser Benchmarks testen allerdings mit EINEM Client- gegen EINEN NFS-Server. In diesem Fall wird NFS v4 meistens schlechter abschneiden, da im Protokoll mehr Funktionalität enthalten ist. Wir haben keine Benchmark-Ergebnisse gefunden, die Funktionalitäten wie pNFS, Migration und Replikation genutzt hätten.
pNFS-Architektur
Bei pNFS wird zwischen den Metadaten – wo liegen welche Shares und wie kann man diese (über mehrere Wege) erreichen? – sowie den Daten-Servern (wo die Shares/Daten liegen) unterschieden. Alle Daten-Server bieten potentiell die gleichen Daten an. Der Metadaten-Server behandelt alle nicht-Daten-(I/O)-Anfragen wie: LOOKUP, GET/SETATTR, ACCESS, REMOVE, RENAME, etc. Die Daten-Server sind ausschließlich für READ und WRITE I/O zuständig.
Je nach Implementierung durch den NFS Storage-Hersteller können die Metadaten auch von mehreren Servern angeboten werden – hier ein Beispiel von der NetApp-Implementierung. NFS v4 sieht vor, dass alle Daten in einem gemeinsamen Namespace abgebildet sind. Physisch liegen die Daten aber in Volumes auf einem der Storages. In diesem Beispiel greift der pNFS Client 1 auf /vol1 über die Storage Node D zu (mount). Das gilt aber nur für die Metadaten. Der Zugriff auf die Daten erfolgt dann über jenen Server, auf dem diese Daten physisch liegen – in dem Beispiel auf der Storage Node B.
Werden die Daten innerhalb der Storages verschoben, beispielsweise das Volume vol1 von Storage Node B auf Storage Node A, so würde der Client im ersten Augenblick immer noch via Storage Node B zugreifen, die dann Ihrerseits die Daten über den Cluster Interconnect auf die Storage Node A zugreifen müsste, um die Daten zu liefern – das ist klarerweise ein Overhead und dauert länger. Daher sieht pNFS vor, dass Client 1 informiert wird, dass die Daten nun über eine andere IP-Adresse zu beziehen sind. Client 1 greift dann direkt auf die Storage Node A zu [2].
Versuchsaufbau Oracle 12cR2 mit dNFS mit und ohne pNFS
- Oracle VM Server mit einer VM mit Oracle 12cR2
- NetApp FAS 3170 Cluster bestehend aus zwei Storage Heads mit jeweils 51 Stück 300GB Harddisks
- Einem VServer und zwei LIFs (IP-Adressen – eine pro Storage Head)
- Jumbo Frames (MTU=9000) konfiguriert
Dieser Aufbau (ältere Hardware, virtualisiert, ...) ermöglicht keine Aussage über die absoluten Performancewerte aktueller Intel-Server und NetApp-Storages – diese sind deutlich schneller! Wir haben schon vor über 5 Jahren POCs mit über 140.000 IOPS und über 1.000 MBPS gemacht. Die Hardware ist aber ausreichend um Performanceunterschiede der verschiedenen NFS-Versionen festzustellen.
NetApp-Storage-Konfiguration
Die beiden FAS3170 bilden einen Cluster aus zwei Knoten (fas3170a, fas3170b). Auf den Storageknoten gibt es 10GBit LAN Interfaces, auf denen jeweils ein LIF (virtuelles Interface) des vServers vsdb122b konfiguriert ist.

Die Datenbank liegt im Volume data1, das für die Tests zwischen den beiden Storageknoten hin und her verschoben wird.
Oracle 12c2 VM-Konfiguration
Die Oracle 12c Release 2-Datenbank läuft auf einem Oracle VM Server mit Dual Intel Xeon X5450 (3GHz) und in Summe 8 Cores. Die Storageanbindung erfolgt über 10GBit-Netzwerkkarten mit der IP-Adresse 10.146.2.61. Die VM selbst läuft unter OEL 7.3 und darf 4 Cores nutzen. Die 8GB-kleine Datenbank wird mittels NFS auf /u01/app/oracle/oradata/DB122B/data1/ gemountet. Damit ist diese klein genug, um in den Cache der FAS3170 Storageknoten zu passen.
select name from v$datafile; NAME ------------------------------------------------------------ /u01/app/oracle/oradata/DB122B/data1/system01.dbf /u01/app/oracle/oradata/DB122B/data1/sysaux01.dbf /u01/app/oracle/oradata/DB122B/data1/undotbs01.dbf /u01/app/oracle/oradata/DB122B/data1/pdbseed/system01.dbf /u01/app/oracle/oradata/DB122B/data1/pdbseed/sysaux01.dbf /u01/app/oracle/oradata/DB122B/data1/users01.dbf /u01/app/oracle/oradata/DB122B/data1/pdbseed/undotbs01.dbf
Die Oracle-Datenbank wurde zur Nutzung von dNFS konfiguriert [3]. Die erfolgreiche Konfiguration von dNFS kann man beispielsweise in v$dnfs_servers verifizieren:
select SVRNAME, DIRNAME from V$DNFS_SERVERS; SVRNAME DIRNAME NFSVERSION ---------------- ---------------------------------------- ---------------- vsdb122b-lif1 /vol/db122b_ctrl1/db122b_ctrl1_qt NFSv3.0 vsdb122b-lif1 /vol/db122b_data1/db122b_data1_qt NFSv3.0 vsdb122b-lif1 /vol/db122b_log1/db122b_log1_qt NFSv3.0 vsdb122b-lif2 /vol/db122b_ctrl2/db122b_ctrl2_qt NFSv3.0 vsdb122b-lif2 /vol/db122b_data2/db122b_data2_qt NFSv3.0 vsdb122b-lif2 /vol/db122b_log2/db122b_log2_qt NFSv3.0
Neben dieser View gibt es noch weitere Views mit Informationen zu dNFS:
- V$DNFS_CHANNELS – welche NFS-Verbindungen die Datenbank nutzt
- V$DNFS_FILES– welche Files auf dNFS liegen
- V$DNFS_STATS– Performance-Statistiken pro File
Diese Views werden im Rahmen der Performancetests für die Performanceanalyse herangezogen. Da es mehrere Wege zu den Daten gibt, braucht man eine oranfstab-Konfiguration. Diese ist auch nötig um pNFS einzuschalten. Dazu muss man den Parameter nfs_version auf pNFS einstellen – Beispiele für die oranfstab folgen bei den verschiedenen Performancetests (Referenzen zur Konfiguration von pNFS [4]).
Oracle 12c Release 2 und NFS: Performancetest – Überblick
Als Performancetest nutzen wir Oracle I/O Calibrate [5], wobei wir für die Anzahl von Disks 100 einsetzen (zweimal 50) sowie eine maximale Latenz von 20. Mir sind die verschiedenen Gründe, die gegen diesen Test sprechen durchaus bewusst (keine SQL-Verarbeitung, kein Schreiben, ...). Da es uns bei den Tests aber nur darum geht, den Performanceeinfluss mit und ohne pNFS zu ermitteln, reicht uns ein Test, der lediglich lesend auf die Oracle-Datenbankfiles zugreift. Für die CPU-Bewertung werden nur die RANDOM I/O-Teile des IO Calibrate herangezogen, wobei der IO Calibrate immer zweimal hintereinander gelaufen ist, da beim ersten Lauf der Cache potentiell nicht befüllt war.
Die Datenbankgröße ist mit ca. 8 GB so gewählt, dass die Datenbank komplett ins Memory der jeweiligen Storage Node passt. Das wurde deswegen so gewählt, weil es um den Performanceunterschied bzw. Performanceoverhead geht – der sich im Microsekundenbereich bewegt – und nicht um die disk io performance, die im ms-Bereich liegt.
Zusätzlich ermitteln wir die CPU-Auslastung sowohl auf dem Datenbank-Server als auch auf den NetApp Storage-Knoten. Leider stehen die NetApp Storages nicht exklusiv für unsere Tests zur Verfügung, die CPU-Auslastung schwankt ohne Tests zwischen 3 und 10 Prozent und zwischen 500 und 2000 Netzwerkpaketen. Da unsere Tests eine deutlich höhere Last generieren, sollte trotzdem eine Aussage möglich sein.
Vor jedem Test wir die Oracle-Datenbankinstanz restartet um einerseits die möglicherweise geänderten Einstellungen in der oranfstab zu übernehmen und andererseits ein Cleanup der v$dnfs%-Views zu erreichen.
Performancetest #1: NFSv3, Zugriff auf DATA1 auf FAS3170a via LIF auf FAS3170a
In der oranfstab wurde nfs_version nicht spezifiziert, wodurch die Datenbankinstanz den Default von NFSv3 verwendet hat.
SVRNAME DIRNAME NFSVERSION ---------------- ---------------------------------------- ---------------- vsdb122b-lif1 /vol/db122b_ctrl1/db122b_ctrl1_qt NFSv3.0 vsdb122b-lif1 /vol/db122b_data1/db122b_data1_qt NFSv3.0 vsdb122b-lif1 /vol/db122b_log1/db122b_log1_qt NFSv3.0 vsdb122b-lif2 /vol/db122b_ctrl2/db122b_ctrl2_qt NFSv3.0 vsdb122b-lif2 /vol/db122b_data2/db122b_data2_qt NFSv3.0 vsdb122b-lif2 /vol/db122b_log2/db122b_log2_qt NFSv3.0
Während des Tests wurden folgende CPU-Auslastungen festgestellt:
- Die CPU-Belastung am Datenbank-Server lag um die 90 Prozent, wobei NMON schon 10 Prozent Steal angezeigt hat – die VM hat zu wenig CPU-Ressourcen
- FAS3170a
Die CPU-Auslastung schwankt zwischen 30 und kurzfristig bis zu 55 Prozent. Wenn man die typische Basisbelastung abzieht, sollte die CPU-Belastung durch den Benchmark zwischen 30 und 45 Prozent liegen. - FAS3170b
Keine CPU-Belastung feststellbar. - Oracle File - IO-Statistik (v$iostat_file)
Hier liefert Oracle Informationen zu den I/O Requests von IO Calibrate. Da uns speziell die random I/O Latenz interessiert, betrachten wir nur die "small read IOs".FILE_NO AVG_SMALL_READ_US AVG_SMALL_SYNC_READ_US ------- ----------------- ---------------------- 1 355.507436 355.538691 3 355.995664 356.228999 4 356.920581 356.920581 5 356.409876 356.398215 6 355.770811 355.783105 7 .75 .75 8 356.28306 356.296397
Die Leselatenz beträgt quer über alle Datenbankfiles ca. 355us (also 0.355ms). - Ergebnis des IO Calibrate: I/O Ops/Sec = 27.066
Performancetest #2: NFSv3, Zugriff auf DATA1 auf FAS3170b via LIF auf FAS3170a
Das Volume DATA1 wird von den Disks von FAS3170a auf die Disks von FAS3170b verschoben. Der Zugriff erfolgt weiterhin über die IP von FAS3170a. Das Verschieben geht online und hat keine Auswirkungen auf die NFS Mounts.
Während des Tests wurde Folgendes festgestellt:
- Die CPU-Belastung am Datenbank-Server war gleich mit dem ersten Test.
- FAS3170a – nur IP-Adressen, keine Daten
Die CPU-Auslastung schwankt zwischen 20 und knapp 40 Prozent – nur dafür, dass die IO Requests über den Cluster Interconnect hin und wieder zurückgegeben werden. - FAS3170b – nur Daten
Hier haben wir eine Last, die zuvor auf FAS3170a zu sehen war. Die CPU-Last schwankt zwischen 20 bis zu 50 Prozent, wobei Werte unter 30 und über 40 Prozent eher als Ausreißer zu sehen sind. - V$IOSTAT_FILE
Betrachtet man die I/O Zeiten für Small Reads aus v$iostat_file und errechnet daraus die durchschnittlichen small reads I/O Zeiten bekommt man folgendes Ergebnis: Der I/O über den "falschen" Storageknoten dauert ca. 35us länger – das ist nicht viel – die CPU-Auslastung der Storageknoten ist aber dramatisch höher! - Ergebnis des IO Calibrates: I/O Ops/sec = 26.416
Greift man über eine Netzwerkkarte auf einem Storageknoten auf Daten zu, die auf dem anderen Storageknoten liegen, so erzeugt auf beiden Storageknoten annähernd die gleiche CPU-Belastung, d. h. man verdoppelt den CPU-Bedarf auf den Storages durch diese Zugriffe über die falsche IP-Adresse. Das Ergebnis des I/O Calibrate ist praktisch identisch – von der Datenbank aus merkt man keinen Unterschied. Die zusätzliche Latenz durch die Beschäftigung von zwei Storage Heads liegt im Bereich von deutlich unter 0.04ms. Die interne Messgenauigkeit beim I/O Calibrate liegt bei ganzen ms, da ist die Auswertung über v$iostat_file (mit Microsekunden) deutlich sinnvoller.
Performancetest #3: nur NFSv4, Zugriff auf DATA1 auf FAS3170a via LIF auf FAS3170a
Im dritten Test steigen wir von NFSv3 auf NFSv4 um – allerdings noch immer ohne pNFS-Funktionalität. In der oranfstab wird jetzt die nfs_version auf nfsv4 für alle Mounts eingestellt (s. Abb.4). Das wird auch in v$dnfs_servers korrekt wiedergegeben (s. Abb.5).
Während des Tests wurden Folgendes festgestellt:
- Die CPU-Belastung am Datenbank-Server ist mit den ersten beiden Tests vergleichbar, tendenziell aber etwas niedriger.
- NFSv4 Metadaten
Auf den Storages sieht man Unterschiede im Vergleich mit NFSv3 – die Metadaten werden offensichtlich von beiden Storageknoten abgefragt. - FAS3170a – nur IP-Adressen & Daten
Allgemein ist der CPU-Bedarf auf der Storage bei der Verwendung von NFSv4 merklich höher, das liegt an der deutlich höheren Komplexität des Protokolls auf Grund der zusätzlichen Funktionalitäten. Bei unseren schon etwas älteren Storages steigt die CPU-Belastung von zuvor zwischen 30 und 45 Prozent (NFSv3) auf 50 bis knapp über 70 Prozent – somit um ca. 20 Prozent. - FAS3170b – nur Metadaten
Während bei NFSv3 beim Zugriff über den richtigen Storageknoten der andere Storageknoten überhaupt nichts zu tun hatte, sieht man hier eine – zwar geringe – aber messbare Auslastung. Da diese stark schwankt (beim Start vom IO Calibrate lag diese einige Zeit lang bei knapp 10 Prozent) und mit der Zeit geringer wurde, dürfte es sich aber nur um einige Prozent handeln, die das Abfragen der Metadaten auf den zweiten Storageknoten an Last erzeugt. - V$IOSTAT_FILE
Betrachtet man die I/O Zeiten in v$iostat_file, so sieht man, dass diese ebenfalls merklich höher sind als bei der Verwendung von NFSv3. Diese liegen im Bereich von 430us somit um 75us (0.075ms) höher als bei NFSv3. - Ergebnis des IO Calibrates – I/O Ops/sec = 23.536
Auch die Ergebnisse vom I/O Calibrate sind – bei den für uns relevanten IOPS – deutlich schlechter. Es wird auch eine höhere Latenz angegeben, die wir auf die anfänglichen Metadatenzugriffe zurückführen, da die Werte in v$iostat_file durchschnittlich immer noch unter 0.45ms liegen.
Performancetest #4: NFSv4, Zugriff auf DATA1 auf FAS3170b via LIF auf FAS3170a
Die oranfstab bleibt wie beim vorigen Test. Es werden lediglich die Daten wieder auf die Disken der FAS3170b migriert.
Erkenntnisse aus dem Test
- Bei der CPU-Last und beim Netzwerkdurchsatz am Datenbank Server ist klar zu sehen, dass im Vergleich zu den bisherigen Performancetests etwas nicht stimmt. Die CPU-Auslastung ist deutlich niedriger – was ja positiv wäre, wäre nicht gleichzeitig der I/O-Durchsatz massiv schlechter. Das wird sich natürlich in den I/O Calibrate-Werten deutlich wiederspiegeln.
- FAS3170a – nur die IP
Die CPU-Belastung auf dem Knoten, der die Kommunikation mit dem Datenbankserver übernimmt, ist zwar geringer als beim dem vorigen Test, allerdings werden ja alle I/O-Operationen an den anderen Storageknoten weitergereicht. Die Belastung pendelt zwischen 40 und knapp über 50 Prozent mit Peaks auf über 60 Prozent. - FAS3170b – hier befinden sich die Daten
Die CPUs sind alle mehr oder weniger gleichmäßig mit 25 bis 40 Prozent ausgelastet. - V$IOSTAT_FILE
Wie zu erwarten, dauern die I/Os länger – mit durchschnittlich knapp 500us (0.5ms) bedeutet dieser Umweg ca. 70us längere I/O Zeiten. Das wirkt sich natürlich auf die Ergebnisse von I/O Calibrate aus. - IO Calibrate-Ergebnis
I/O Ops/sec = 20780 – ein deutlicher Rückgang von ca. 10 Prozent.
Wenn man an dieser Stelle einen Vergleich zwischen NFSv3 und NFSv4 macht (was bei vielen Benchmarks leider gemacht wird), würde das Ergebnis wie folgt aussehen (s. Abb.6).
- NFSv4 ist langsamer als NFSv3 – weniger IOPS, höhere I/O Zeiten
- Der Zugriff über den "falschen" Storagekopf führt zwar ebenfalls zu geringeren IOPS-Zahlen und höheren I/O Zeiten, aber das Entscheidende ist die massiv höhere CPU-Belastung auf den Storageknoten – dieses Problem sollte pNFS beheben.

Performancetest #5: pNFS, Zugriff auf DATA1 auf FAS3170a via LIF auf FAS3170a
In der oranfstab wurde auf pNFS umgestellt. v$dnfs_servers zeigt uns diese Einstellung (s. Abb.7).
Erkenntnisse aus dem Test:
- Auffällig an der CPU-Belastung des Datenbank-Servers ist, dass diese niedriger ausfällt als angenommen (unter 70 Prozent – etwas niedriger, als beim Test davor), aber dabei gleichzeitig der Netzwerkdurchsatz mit dem bei NFSv3 vergleichbar ist!
- FAS3170a – hier liegt IP und Daten
Auf dem Storageknoten liegt die durchschnittliche Belastung im Bereich von 60 - 80 Prozent mit Peaks auf 90 Prozent. Damit wird der Storageknoten zum Engpass. - FAS3170b – nur Metadaten
Wie zu erwarten, ist die Last auf dem nicht involvierten Knoten wieder recht gering – es gibt hin und wieder kleine Peaks, die von Metadaten-Abfragen herrühren dürften. - V$IOSTAT_FILE
Die Werte sind überraschend niedrig – mit unter 20us (0.02ms) stellt sich die Frage: können die Werte stimmen oder misst Oracle mit pNFS nicht korrekt? Die Anzahl der IOs werden korrekt wiedergegeben, lediglich die I/O Zeiten sind fraglich! Somit ist das Ergebnis vom I/O Calibrate wichtig, finden wir hier auch sehr gute Daten? - IO Calibrate Ergebnis – I/O Ops/sec = 25547
Und die Antwort ist: Ja, absolut! Diese sind zwar immer noch etwas schlechter als bei NFSv3, aber deutlich besser als bei NFSv4.
Performancetest #6: pNFS, Zugriff auf DATA1 auf FAS3170b via ???
Jetzt wird es spannend: Hält pNFS, was es verspricht? Die Daten auf der Storage wurden bei laufender Datenbank auf FAS3170b verschoben. Wenn pNFS hält, was es verspricht, sollte der Zugriff transparent via FAS3170b erfolgen (zumindest nach kurzer Zeit).
Das Ergebnis ist ernüchternd: es funktioniert nicht, beide Storageknoten stehen wieder massiv unter Last. Kann es an den Einstellungen in oranfstab liegen?
Versuch #1) donotroute auskommentieren
Versuch #2) mehrere Pfade definieren/erlauben
Jeder Versuch zeigt, dass pNFS immer über den gemounteten Pfad zugreift. Entweder gibt es eine spezielle Konfiguration für die oranfstab, die wir nicht gefunden haben – die Dokumentation schweigt sich dazu aus – oder es funktioniert einfach noch nicht. Wir haben dazu zwei Service-Requests bei Oracle geöffnet.
Die Erkenntnisse während der Tests
- Die CPU-Auslastung am Datenbank-Server ist wieder deutlich höher – vergleichbar mit den Tests mit NFSv3.
- FAS3170a
Die CPU-Belastung ist vergleichbar mit dem vorigen Test. - FAS3170b
Auch hier liegt die Last im Bereich des NFSv4-Tests, wenn über den falschen Storageknoten zugegriffen wird. - V$IOSTAT_FILE
Wie zu erwarten, liefert uns V$IOSTAT_FILE auch hier keine korrekten Werte. - Ergebnis des IO Calibrates – I/O Ops/sec = 24.321
Die Werte vom IO Calibrate liegen knapp 10 Prozent unter denen der Tests mit NFSv3.
Zusammenfassung: Oracle pNFS und Performance
Aktuell funktioniert das Nutzen des optimalen Zugriffspfades mit Oracle pNFS noch nicht und auch die Oracle-internen Performance Views liefern im Zusammenhang mit pNFS noch falsche Daten. Interessant ist, dass mit pNFS die Performance im Vergleich mit NFSv3 nur um einige Prozent geringer ausfällt, dafür aber die CPU am Datenbank-Server merklich weniger belastet wird.

Auf der Storageseite ist pNFS offensichtlich merklich aufwändiger und noch nicht so gut optimiert wie es NFSv3 ist – das wird aber in den nächsten Jahren sicher noch optimiert werden. Vielleicht liegt es aktuell auch daran, dass Oracle den "redirect" auf den anderen Storage Knoten ignoriert.
Oracle 12c Release 2: Soll man schon jetzt auf pNFS umsteigen?
Ein klares Ja für Test-/Dev-Systeme und ein klares Nein für produktive Datenbanken. Wie wir schon in den letzten Jahrzehnten gelernt haben, sollte man ein neues Feature bei Oracle frühestens mit dem nächsten Release produktiv nutzen (um die Produktion nicht durch die sicher noch vorhandenen Bugs zu gefährden), aber schon jetzt mit dem Sammeln von Erfahrungen beginnen.
Die gefundenen Probleme wurden bei Oracle gemeldet – wir hoffen auf eine baldige Behebung.
- Oracle dNFS- und RMAN-Performance
Erfolgreiche Umstellung von SAN auf DNFS bei den SALK
Oracle Direct NFS Performance - Parallel Network File System Configuration and Best Practices for Clustered Data Ontap 8.2 and Later
- Oracle dNFS richtig konfigurieren
- Oracle 12cR2 Database Installation Guide: Creating an oranfstab File for Direct NFS Client
- Performancetest mit Oracle I/O Calibrate