Yoshihito Tech Blog

2023/02/23

Oracle Reconfigurationの長時間化

前提

本事象が発生した環境は以下です。

Oracle 19c
Oracle RAC構成(DataGuard構成)

Reconfigurationとは

RAC構成の場合、インスタンス障害が発生すると、
各インスタンスの整合性を確保するためにreconfigurationという動作を内部的に実行します。
reconfiguration中は全ての処理が待ち状態となり、実質DBへの全断が発生してしまいます。

背景

金融系のシステム開発案件にて、障害試験を実施中にORA-01013が発生。
ORA-01013はタイムアウト発生に関するエラーで、reconfigurationによる待機が約150秒ほど発生していました。
アプリケーションのタイムアウト値を10秒に設定していたため、10秒以内に抑える必要がありました。
業務影響がかなり大きいため、緊急度/重要度がMAXでした。

解決方法

oracleサポートからの回答も頼りに、実施した解決策は2つあります。

隠しパラメータ _lm_ticketsを5000に変更
インターコネクトで使用しているMTUを9000に変更

隠しパラメータ _lm_ticketsを5000に変更

LMSという、キャッシュフュージョンに関するバックグラウンドプロセスが使用するパラメータ。
デフォルト設定は1000です。
トレースファイルから、このlm_ticketsが足りていないというメッセージが出ているとのことで、5000に値を変更しました。

インターコネクトで使用しているMTUを9000に変更

インスタンス間で同期を取るために使用してるネットワーク線の帯域が小さい値(1500)だったことが原因だったので、9000に変更しました。

今回の事象はこちらが大きな原因だったと思いますが、、、
アラートログやトレースファイルから、UDPのパケットロスが発生していることが確認できていました。
ただしネットワーク機器(L3スイッチ)からのエラーは確認できていなかったと記憶しています。
MTUの値が小さすぎると、UDPパケットはMTUサイズに合うよう細かくパケットを分割して再送する動きをします。
このUDPパケット送付にかなりの時間がかかっていたようです。
ちなみに、Oracleの推奨値は9000のようでした。(それなら構築の段階で反映しておいてほしかった・・・)

まとめ

reconfigurationが長時間化してしまう場合は、
(1)Oracle隠しパラメータである_lm_ticketsの値を見直してみる
(2)インターコネクトで使用しているMTUサイズを大きくしてみる
を試してみると解消されるかもしれません。

振り返ってみると当たり前だな、と思えるのですが、当時はかなり難航していました。
とても苦い思い出です。
いろんなブログを漁っても情報があまり出てこなかったので、もし同じような事象に困っている人がいたら参考にしてみてください。