- ノード1つのアラームログ
木06月20日午前3時02分18秒2019
スレッド1は、（LGWRスイッチ）配列2092をログに記録するように前進
+ DATA /試験/ ONLINELOG / redo11_1.log：現在のログ番号11、配列番号2092、MEM＃0
の現在のログ番号11、配列番号2092、MEM＃ 1：+ DATA /試験/ ONLINELOG / redo11_2.log
木06月20日午前3時02分18秒2019
LNS：先LOG_ARCHIVE_DEST_2用スレッド1用に選択さスタンバイのREDOログファイルは、シーケンス2092
木06月20日午前3時02分20秒2019
アーカイブ・ログ・エントリ5703は、のために追加しましたスレッド1シーケンス2091 ID 0x9b8db1ed DEST 1：
木6月20日午前3時03分53秒2019
skgxpvfynet：MTYPE：61プロセス316751があるため、OS内のリソースの問題のために失敗しました。：OSはバッファのうち、最も可能性の高い走行（4 rvalに）持っている
ファイル/u01/app/oracle/diag/rdbms/test/test1/trace/test1_ora_316751.trc（インシデント= 560025）でのエラー：
ORA-00603：ORACLEサーバー・セッションは、致命的なエラーによって終了
ORA-27504：IPCエラー作成OSDコンテキスト
ORA-27300：OSのシステムに依存する操作：sendmsgのがステータスで失敗しました：105
ORA-27301：OSのエラーメッセージ：いいえバッファスペース利用可能
ORA-27302を：sskgxpsnd2：障害が発生した時
、入射詳細：/u01/app/oracle/diag/rdbms/test/test1/incident/incdir_560025/test1_ora_316751_i560025.trc
木06月20日3時03分54秒2019は
ディレクトリ内の診断データをダンプ= [cdmp_20190620030354] 、（例えば= 1、OSID = 316751）、要約= [入射= 560025]によって要求されました。
ORA-603の結果としてプロセス未知ospid（316751）を中止opiodr
木06月20日午前3時04分03秒2019
スイープ[INC] [560025]：終了
スイープ[INC2] [560025]：終了
木06月20日3時06分15秒2019
スレッド1は、シーケンス2093を記録するために前進（LGWRスイッチ）
現在のログ番号5、配列番号2093、MEM＃0：+ DATA /試験/ ONLINELOG / redo05_1.log
現在のログ＃5配列番号2093のMEM＃ 1：+ DATA /試験/ ONLINELOG / redo05_2.log
木06月20日3時06分16秒2019
--- --trcファイルTRCファイルには、サーバーは、カードのMTUの値に関連した問題で、予備的な外観でなければなりません
53.395：03：*** 2019年6月20日03
2019年6月20日3時03分***クライアントID :(）： 53.395
。***サービス名:(）2019年6月20日03：03：53.395
。***モジュール名:(）2019年6月20日03：03：53.395
。***アクション名:(）2019年6月20日03：03：53.395
SKGXP：[7f5ab0ef57c0.0] {0}：SKGXPVFYNET：ソケットセルフテストは、32768バイト（MTYPE 61れる）の正常な送信を確認できませんでした。
SKGXP：[7f5ab0ef57c0.1] {0}：ネットワークが要求されます。UDPプロトコルのこのサイズのサポートがソケット169.254.16.188にバインドされて送る。
SKGXP：[7f5ab0ef57c0.2] {0}：位相、100ループ、セット0しようと'送信' 32 354 MS（最後）の
構造体ksxpp * ksxppg_ [0xc11fde0 、0x7f5aadaf5588）= 0x7f5aadaf5580
0x00007F5AADAF6AB0へ0x00007F5AADAF5580からメモリのダンプ
---データベースの状態
のGVから選択INST_ID、INSTANCE_NAME、STARTUP_TIME $インスタンス。
-添加到CRTは、
'：MI：HH24 YYYYMMDD SS'セッションセットのNLS_DATE_FORMATを=変更R \ライン1000を設定し、GVの$インスタンスからINST_ID、INSTANCE_NAME、STARTUP_TIMEを選択し、\ rに\ rの設定時間を、
午前9時42分29秒SYS @ TEST1（TEST1）>セットライン1000年
9時43分30秒SYS @ TEST1（TEST1）>変更セッションセットNLS_DATE_FORMAT = 'YYYYMMDDのHH24：MI：SS'。
セッションが変更されました。
9時43分31秒SYSする@ TEST1（TEST1）>上の時刻を設定
午前9時43分31秒SYSする@ TEST1（TEST1）> INST_ID、INSTANCE_NAMEを選択し、STARTUP_TIMEのGV $インスタンスから。
INST_ID INSTANCE_NAME STARTUP_TIME
---------- ---------------- -----------------
1 TEST1 20190509 15 ：30：08
2 TEST2 20190507午後9時37分04秒
---节点2日志
木06月20日3時03分54秒2019
ディレクトリ内の診断データをダンプ= [cdmp_20190620030354]、要約= [入射= 560025]、（インスタンス= 1、OSID = 316751）によって要求されました。
木06月20日午前3時10分10秒2019
スレッド2は、シーケンス912（LGWRスイッチ）をログに記録する前進
現在ログ番号6、配列番号912、MEM＃0：+ DATA /試験/ ONLINELOG / redo06_1.log
現在のログ＃6、SEQ＃912、MEM＃ 1：+ DATA /試験/ ONLINELOG / redo06_2.log
---公式ドキュメントを参照してください。
2041723.1
原因
これは、ネットワークのバッファ予約のために利用できるスペースが少なくに起こります。
SOLUTION
高い物理メモリを持つサーバー1.、パラメータvm.min_free_kbytesは、総物理メモリの0.4％の順に設定する必要があります。これは、低バッファ空間条件の可能性を低減するネットワーク・バッファのために利用できるデフラグメモリページのより大きな範囲を維持するのに役立ちます。
***例えば、256ギガバイトのRAMを備えているサーバー上で、パラメータvm.min_free_kbytesは1073742に設定されなければならない***
値は、すべてのノード間で分割されるので、NUMA対応システム上で、vm.min_free_kbytesの値は、NUMAノードの数を乗算しなければなりません。
NUMAが有効上のシステム、vm.min_free_kbytesの値= N *総物理メモリの0.4％。ここで「n」のNUMAノードの数です。
2.また、MTU値は、以下のように変更しなければなりません
#ifconfig LO人16436
リブート上で変更を永続化するには、ファイル/ etc / sysconfig / network-scriptsに/のifcfg-loの中で次の行を追加します。
MTU = 16436
ファイルを保存し、変更をロードするためにネットワークサービスを再起動します
#serviceネットワークの再起動
注意：CRSノードでの変更を行う一方で、CRSがアップしている間、ネットワークが再起動された場合、それはCRSを掛けすることができます。だから、クラスタサービスは、前のネットワークの再起動を停止する必要があります。
---キジのブログ
http://ju.outofmemory.cn/entry/76102