Oracleデータベースはdatagurdライブラリによるlog file sync待ち問題です。

読み解き:
最近のデータベースはよく会話の詰まりの警報が出ます。あとで自動的に消えます。昨日の夜に一回発生しました。そこで、急いで調べました。見ないと分かりません。びっくりしました。datagurdによるlog file syncが待っています。通常のlog file sync待ち時間は頻繁に日記を書くことによって引き起こされると知っていますが、今回はDG環境によって引き起こされるものです。
（一）問題の説明
データベース：Oracle 11.2.04、単独版、Datagurd環境があります。
オペレーティングシステム：centos 7.4
zabbixを通して監視されたセッションブロック情報は下図のようになります。ここではカスタムモニタです。以下のように説明します。
ユーザuseraは、そのsession idが2663であり、session serialが27727であり、このセッションはSQL文を実行していないが、ずっと待機中であり、待ち時間がないイベントはlog file syncであり、合計548 sを待っている。

（二）分析
アラーム期間の履歴会話情報を確認します。

select sample_time, session_id,session_serial#,session_type,user_id,sql_id,sql_plan_operation,event,
  blocking_session,blocking_session_serial#,PROGRAM,MACHINE 
from v$active_session_history a
where a.sample_time > to_date('2020-11-25 20:40:00','yyyy-mm-dd hh24:mi:ss')
and  a.sample_time < to_date('2020-11-25 20:59:00','yyyy-mm-dd hh24:mi:ss')
and  blocking_session is not null
order by a.sample_time;

セッション1333、2191、2663は、セッション1331によってブロックされ、待ち時間イベントは、log file syncであり、セッションは1311であることがわかる。

照会1331セッション情報は、ログ書き込みプロセスLGWRであり、1311セッションは他のセッションによってブロックされなくなり、1331セッションの待ち時間イベントはLGWR-LNS wait on chanelであると判定することができる。

select sample_time, session_id,session_serial#,session_type,user_id,sql_id,event,
  blocking_session_status,blocking_session,PROGRAM,MACHINE 
from v$active_session_history a
where a.sample_time > to_date('2020-11-25 20:40:00','yyyy-mm-dd hh24:mi:ss')
and  a.sample_time < to_date('2020-11-25 20:59:00','yyyy-mm-dd hh24:mi:ss')
and  a.session_id = 1331
order by a.sample_time;

このケースでは、2つのタイプの空き待ちイベントが発生しました。

log file sync

LGWR-LSNS wait on chanel（ブロック元）

何がlog file syncですか？ユーザーが一つのトランザクションを提出するとlog file syncを待っています。LGWRプロセスがSCNに対する伝播とやり直すログに対する書き込みが完了するまで。したがって、ログfile syncの待ち時間は、リフォームログI/O時間とSCN伝搬時間の2つの部分から構成されており、DataGardも使用されており、ログ転送時に同期＋確認（SYSNC+AFRIM）オプションが使用されている場合、LGWRはまた、ユーザがトランザクションを提出した後、リフォーム日誌情報をリモートライブラリノードに渡す必要がある。まとめてみると、ロゴfile syncの計算式は以下の通りです。
ユーザプロセスのlog file sync待ち時間=LGWRが、リフォームログI/O時間＋SCN伝搬時間＋LGWRが、リフォームログを準備した時間に転送します。
データベースの例では、log file syncの待ち時間は以下の通りである。

ステップ①、②の時に経験した時間は、log file syncが経験した時間です。a 1~a 4はLGWR転送してログを準備していく過程で、b 1~b 4はLGWRがSCNを伝播する過程で、c 1~c 2はLGWRがリフォームログをログファイルに書き込む過程です。
a 1~a 4はLGWRを代表して、リフォームログをDataGuard準備庫に送ります。過程は以下の通りです。
a 1：LGWRは、トランザクションに対応するリフォーム情報をローカルノードのLNS（network server）プロセスに送信する。
a 2：LNSプロセスは、ネットワークを介してリメイク情報を準備ライブラリに送信するRFSプロセスである。
a 3：RFSプロセスは、再構築ログ情報を準備ライブラリのバックアップ再作成ログファイル（Standby redo logs）に書き込み、メインライブラリのLNSプロセスにメッセージを返す。
a 4：メインライブラリのLNSプロセスは、LGWRプロセスのやり直し情報がすでに準備庫に書き込まれているバックアップのやり直しログファイルに通知します。
b 1〜b 4は、LGWR伝搬SCNを表し、SCNはデータベース内部のクロックであり、重複しない、単一の成長、SCNはデータベースに対してであり、実例に対してではなく、RACデータベースに対しては、複数のインスタンスがありますが、これらのインスタンスは同じSCNを使用しますが、各インスタンスごとにそれぞれのタスクを実行することができます。分散型データベース（例えば、DB Linkを使用している）についても、同期SCNの概念は同じである。同期SCNのプロセスは以下の通りである。
b 1：LGWRプロセスは、トランザクションを送信するSCNをローカルのLMSプロセスに送信する。
b 2：ローカルノードのLMSプロセスは、SCNを含むメッセージをすべてのリモートノードに送信するLMSプロセスを含む。
b 3：すべてのリモートノードのLMSプロセスは、SCNメッセージを受け取り、ローカルノードにフィードバックするLMSプロセスである。
b 4：ローカルノードのLMSプロセスは、LGWRに通知し、すべてのリモートノードは、トランザクションのSCNを受けている。
c 1~c 2はLGWRを代表してリフォームログを実行してI/Oを書きます。プロセスは以下の通りです
c 1:LGWRプロセスは、redo buffer cacheのログをオンラインredo logsに書き込みます。
c 2：書き終わったらLGWRが完了したという知らせを受けます。
ロゴfile syncの待ち時間を分析した後、その形成原因がほぼ分かります。しかし、新しい問題がまた来ました。log file syncは3つの原因で構成されています。私の環境の中で、LGWRがリメイクログを実行するのが遅いのか、それともSCNの伝播時間に異常があるのか、LGWRがリペアログを転送して予備庫に性能ボトルネックがありますか？
（1）LGWRがリフォームログI/Oを実行することによるlog file sync
LGWRがオンラインredo logsにログを書き込むことによるI/O問題は、log file parallel writeなどのイベントを伴って発生します。つまり、logfile syncとlogfile parallel writeが一緒に現れたら、オンラインでログファイルを保存する磁気ディスクI/Oが問題になります。ディスクI/O問題の主要解決策は以下の通りです。

redoログのI/O性能を最適化しました。できるだけ高速ディスクを使って、redo log fileをライヴ5のディスクに保存しないでください。

ログバッファを大きくする。

大量提出を使用して、提出回数を減らす。

（2）SCN伝搬によるlog file sync
SCN伝搬によるlog file sync待ちイベントはほとんど見られません。SCN伝搬によるlogfile syncの確率は小さいと思います。無視できます。

SQL> SELECT NAME FROM v$event_name a WHERE a.name LIKE '%SCN%' OR a.name LIKE '%LMS%';

NAME
----------------------------------------------------------------
retry contact SCN lock master
ges master to get established for SCN op

（3）LGWRからリペアログを準備庫に転送することによるlog file sync
特に注意したいのは、LOG_だけです。ARCHIVE_DEST_nパラメータに「SYNC，AFFIRM」属性が使用されている場合、log file sync待ちイベントはLGWR転送ログに関連します。他の属性が使用されている場合は考慮しないでください。
LNSプロセスData Gard環境では、メインライブラリを使用してログを準備ライブラリに転送するプロセスは、関連するすべての待ち時間イベントを参照してください。

SQL> SELECT NAME FROM v$event_name a WHERE a.name LIKE '%LNS%';

NAME
----------------------------------------------------------------
LNS wait on ATTACH
LNS wait on SENDREQ
LNS wait on DETACH
LNS wait on LGWR
LGWR wait on LNS
LNS ASYNC archive log
LNS ASYNC dest activation
LNS ASYNC end of log
LNS simulation latency wait
LGWR-LNS wait on channel

振り返ってみますと、再び私達の生産環境の問題は、log file syncがLGWR-LNS wait on chanelとともに現れて、データベースのパラメータ情報を確認して、データベースが最大の利用可能なモードで動作していることを発見しました。

SQL> select name,open_mode,database_role,protection_mode,protection_level from v$database;

NAME  OPEN_MODE   DATABASE_ROLE PROTECTION_MODE  PROTECTION_LEVEL 
--------- -------------------- ---------------- -------------------- --------------------
ORCL2  READ WRITE   PRIMARY   MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY


SQL> show parameter log
NAME       TYPE VALUE                        
----------------------------- ------- ---------------------------------------------------------------------------------------------------- 
log_archive_dest_2   string SERVICE=adg_orcl LGWR SYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)        
          DB_UNIQUE_NAME=adg_orcl

さらに「LGWR-LNS wait on chanel」等のイベントを分析します。
LGWR-LSNS wait on chanelとは、これはイベント監視LGWRまたはLNSプロセスがKSRチャネルでメッセージを受信するのにかかる時間を待つということです。
KSRチャネルの説明：https://docs.oracle.com/en/database/oracle/oracle-database/12.2/refrn/DBA_HIST_CHANNEL.WAITS.html荌GUID-628 C 58F-787-4 C 8 E-844 C-9 DFE 0612 BDD。
データベースの異常待ち時間は、メインライブラリのLNSプロセスが同時にDG環境にオンラインログ情報を転送することによって引き起こされ、ボトルネックが準備庫端にあると断定することができる。私たちのメインライブラリは高配合の物理サーバーだと思います。備庫は低配合のクラウドホスト（仮想マシン）です。このような問題が発生しても不思議ではありません。
（三）ソリューション
非同期方式でログ情報を転送し、ログ転送方式を非同期（async）に変更します。

SQL> alter system set log_archive_dest_2= SERVICE="adg_orcl" LGWR ASYNC VALID_FOR=(all_logfiles, primary_role) DB_UNIQUE_NAME="adg_orcl" scope=both;

--       
SQL> alter system set log_archive_dest_state_2= defer;
SQL> alter system set log_archive_dest_state_2= enable;

ここでは、Oracleデータベースのdatagurdライブラリによるlog file syncの待ち時間に関する記事を紹介します。Oracle datagurd備蓄庫に関する詳細について、logfile syncの内容を待っています。以前の文章を検索したり、次の関連記事を見たりしてください。これからもよろしくお願いします。