Dies ist ein altes Problem für mich, das ich vor einiger Zeit gelöst habe, aber ich dachte, ich schreibe es endlich auf. Als ich in meiner neuen Firma anfing, stürzte die Produktionsdatenbank etwa einmal im Monat mit ORA-4031-Speicherfehlern ab. Der aktuelle DBA stellte fest, dass das Problem das Fehlen von Bind-Variablen im Anwendungscode war, was normalerweise die wahrscheinlichste Ursache ist. Das Fehlen von Bind-Variablen war ein Problem, aber wie ich bald herausfand, hatte das Problem überhaupt nichts mit SQL-Anweisungen zu tun. Vielmehr war das Problem auf einen Fehler mit Direct NFS zurückzuführen. Anscheinend hatte Direct NFS ein Speicherleck. Das Speicherleck wirkte sich auf den Shared Pool aus und bei ausreichender Zeit war der freie Speicher im Shared Pool nicht mehr vorhanden, ORA-4031-Fehler wurden ausgegeben und die Datenbank stürzte ab.
Ich habe mit dem Oracle-Support zusammengearbeitet, um zu bestätigen, dass dies ein Fehler ist. Dieses Problem wurde als Bug 10237987 gemeldet und betrifft die Versionen 11.1.0 und 11.2.0. Ich bin auf diesen Fehler auf einem RAC-Cluster mit 3 Knoten gestoßen, auf dem Oracle Enterprise Linux ausgeführt wird. Ich konnte nie eine Antwort erhalten, wenn dieser Fehler auf anderen Betriebssystemplattformen oder für Nicht-RAC-Umgebungen aufgetreten ist. Der Fehler führt dazu, dass die KGNFS-Pools im Shared Pool im Laufe der Zeit erheblich anwachsen.
Ich bedauere, dass ich diesen Fehler nie mit dem Oracle-Support zu Ende bringen konnte. Der Support wollte, dass ich eine Ablaufverfolgung erfasse, als die Datenbank aufgrund von ORA-4031-Fehlern mit den KGNFS-Pools abstürzte. Was sie nicht erkannten, war, dass die KGNFS-Pools zu Platzmangel in allen anderen Pools im Shared Pool führten. Die KGNFS-Pools verdrängten die anderen Pools, und oft wurde der ORA-4031-Fehler erreicht, wenn Platz in den anderen Pools angefordert wurde. Und das einzige Mal, dass die Ablaufverfolgungsdateien generiert wurden, bestand darin, auf den Absturz der Instanz(en) zu warten. Ich konnte nicht herumsitzen und darauf warten, dass unsere Instanzen mitten am Tag abstürzen, nur um eine Trace-Datei für den Oracle-Support zu erfassen, zumal die Trace-Datei möglicherweise nicht einmal aus den KGNFS-Pools stammt!
Am Ende bestand unsere Problemumgehung darin, die Verwendung von Direct NFS in unserer Konfiguration einzustellen. Unsere Tests zeigten keine Leistungsunterschiede mit oder ohne Direct NFS. Seit wir Direct NFS nicht mehr verwenden, haben wir keinen der ORA-4031-Fehler mehr gesehen. Wie ich sehe, ist der Fehler immer noch auf Metalink da draußen, aber noch keine Lösung.
