場合によっては、hugetlbfs がマウントされているすべてのディレクトリを確認する必要があります。そのため、
<オール>
コマンド mount | grep huge でマウントされたディレクトリを見つける .
特に /dev/hugepages を除くすべてのディレクトリをチェックします .
サイズが 2M のファイルをすべて削除します。 (2M は hugepage のサイズです)
ipcs -m を使用 共有メモリ セグメントを一覧表示するには、ipcrm を使用します。 残りの共有メモリ セグメントを削除します。
2019 年 6 月 24 日の編集:わかりました。上記の回答は、正しい限りではありますが、少し簡潔でした。特に、複数の DB インスタンスを持つホストがあり、そのうちの 1 つだけがクラッシュした場合、どのメモリ セグメントをクリーンアップする必要があるかをどのように判断できますか?
まぁ、これも出来ます。実行中のインスタンスごとに、/ as sysdba で接続します 、次に oradebug setmypid を実行します (すべての Oracle PID が SGA に接続するため、任意の pid で済みます)。次に oradebug ipc を実行します .それは（うまくいけば） IPC information written to the trace file を返します .そのため、udump (または diag_dest) ディレクトリに移動し、トレース ファイルを探します。インスタンスのすべての IPC 情報が含まれます。これには ShmId が含まれます .このインスタンスが使用している ShmId のファイルを調べます。 ipcs -m の出力を見てください。 .
実行中のすべてのインスタンスに対してこれを行うと、 ipcs -m によって出力されるメモリ セグメントはすべて ゼロ以外のメモリ割り当てを示し、 oradebug ipc で説明できない 実行中のインスタンスからの情報は、クラッシュしたインスタンスからの残りのメモリ セグメントである必要があります。 ipcrm を使用
複数のインスタンスが実行されているホストでこれを行う場合、これは少し面倒な場合があります。注意して進めてください。実行中のインスタンスの SGA を削除したくありません!
お役に立てば幸いです....