SQL Server の Always On 可用性グループ（AG）運用中に、次のようなイベント（エラーログ）を見かけて不安になることがあります。😥
Always On Availability Groups transport has detected a missing log block...Log scan will be restarted to fix the issue. This is an informational message only. No user action is required.
結論から言うと、多くのケースでは「AGが自動で整合を取り直した」だけで、すぐに障害とは限りません。✅
ただし、頻発したり、同期遅延が増えるなら、原因の切り分けと恒久対策が重要です。🔍
✅ 参考：Always On（AG）やクラスタ障害を“自力で切り分けできる”ようになると、復旧が速くなり運用が一気にラクになります😊
✅ ここから先は、今回の「missing log block」系の調査・再発防止に役立つ資料と、検証環境づくりのおすすめをまとめました📚🛠️👉おすすめ本
この記事でわかること✨
- イベントの意味（何が起きたか）📩
- 代表的な原因（バグ/ネットワーク/I/O）🧩
- まず見るべき確認ポイント（AG健全性）🩺
- すぐできる対策と、再発防止（CU適用など）🛠️
- 「危険サイン」とエスカレーション判断🚨
イベント内容の日本語イメージ（まずは意味を把握）🧠
このメッセージは、ざっくり言うと👇
✅ AGの送受信（transport）が、セカンダリ適用用のログブロックが“連続していない/欠けたように見える”状態を検知
✅ そのため、SQL Server がログスキャンを再開（restart）して整合を取り直した
✅ 多くのケースでは情報メッセージで終わる（自動回復）
Microsoft のKBでも、**「低トランザクション環境でこの情報メッセージが出ることがある」**と説明されています。📌
「LSN of last applied log block」とは？🔢
- **LSN（Log Sequence Number）**は、トランザクションログの位置を示す番号です📍
LSN of last applied...は セカンダリが最後に適用できた位置 を示します🧾
よくある原因3パターン（現場で多い順）🧩
原因① 既知の不具合（低トランザクション時の発生）🐢
Microsoft KB4541309 では、「10秒に1トランザクション未満」など、トランザクションが少ない環境で発生しうるとされています。
この場合、実害がなくてもログに出ることがあります。😅
原因② SQL Serverの修正が入っていない（CU未適用）🧯
類似の「missing log block / Error 19432」系について、修正KBが複数あります。
例：KB4338746（修正系の案内）
また、SQL Server 2019 CUの修正一覧にも KB4541309 が掲載されています。
原因③ ネットワーク瞬断・遅延／ストレージI/O遅延🌐💽
- ネットワークが一瞬詰まる（遅延・ドロップ）📡
- セカンダリ側のディスクが遅くて redo が進まない💾
この場合は、他のHADR系ログや **待機（wait）**にも兆候が出やすいです。👀
まずやるべき確認（5分でできる安全確認）⏱️✅
AGダッシュボードで健全性を確認🖥️
SSMSで👇
Always On 高可用性 → 可用性グループ →（対象AG）→ ダッシュボード
見るポイント🔍
- Synchronization State：SYNCHRONIZED / SYNCHRONIZING か？✅
- Data Movement：SUSPENDED になっていないか？🚫
T-SQLで「遅延」と「停止」を数値で見る📊
以下は、セカンダリ（またはイベントが出たノード）での確認に便利です✨
（対象DB名 を置き換え）
SELECT
DB_NAME(drs.database_id) AS db_name,
drs.is_primary_replica,
drs.synchronization_state_desc,
drs.synchronization_health_desc,
drs.is_suspended,
drs.suspend_reason_desc,
drs.log_send_queue_size,
drs.redo_queue_size,
drs.redo_rate,
drs.log_send_rate,
drs.last_commit_time
FROM sys.dm_hadr_database_replica_states drs
WHERE drs.database_id = DB_ID(N'対象DB名');
この DMV は Microsoft Learn に公式説明があります。
結果の見方（ここだけ押さえればOK）🧭
is_suspended = 1👉 要対応（データ移動が止まっています）🚨log_send_queue_sizeが増え続ける 👉 送信詰まり📤redo_queue_sizeが増え続ける 👉 適用（redo）詰まり📥synchronization_health_descが NOT_HEALTHY 👉 要調査⚠️
SQL Serverエラーログで「同時刻の別メッセージ」を探す🧾
このイベント単体は軽いことが多いですが、同時刻に👇があると話が変わります😨
- 接続断（HADR/Endpoint/Network）系
- I/Oエラー系
- データ移動停止（SUSPEND）系
対策（症状別に最短ルートで）🛠️✨
単発で、AGが健全なら「基本は様子見」でOK👌
Microsoft KBが示す通り、情報メッセージとして自動回復するケースがあります。
この場合は、運用上は👇だけやっておくと安心です😊
- その時刻のネットワーク遅延/ドロップ確認📡
- セカンダリのディスクレイテンシ確認💽
- AG遅延（queue）が増えていないか確認📊
頻発するなら「CU適用検討」が最優先🧯⬆️
このメッセージは、低トランザクション環境で発生する既知事象として修正KBが存在します。
そのため、頻発するなら👇の流れが堅いです✅
手順📌
- SQL Serverのバージョンを確認
SELECT @@VERSION;
- 該当バージョンの 最新CU を検討（検証→適用）🧪
- 適用後、イベント頻度とAG遅延（queue）を観測📈
同期が戻らない／SUSPENDED になるなら「障害対応」へ🚨
次のどれかに当てはまるなら、情報メッセージ扱いは卒業です⚠️
is_suspended = 1が継続するredo_queue_size/log_send_queue_sizeが増え続ける- ダッシュボードで NOT_HEALTHY が続く
- 接続断/I/Oエラーが同時刻に出ている
この場合は👇を優先します🧯
- ネットワーク（瞬断・遅延）調査📡
- ストレージI/O（レイテンシ、キュー長）調査💽
- 必要なら再同期（環境方針に従って再初期化/再シード）🔁
再発防止の監視ポイント（運用がラクになる）😌📈
最低限見るべき指標3つ📌
log_send_queue_size（送信詰まり）📤redo_queue_size（適用詰まり）📥synchronization_health_desc（健康状態）💚
これらは sys.dm_hadr_database_replica_states で取得可能です。
アラートの出し方（例）🔔
- queue が 一定時間増え続けたら通知📨
is_suspended = 1を即通知🚨- NOT_HEALTHY を一定時間継続で通知⏳
FAQ（よくある質問）❓✨
Q1. 「No user action is required」なら何もしなくていい？🤔
A. 単発でAGが健全なら基本OKです👌
ただし、頻発や **同期遅延（queue増加）**があるなら、CU適用や基盤調査をおすすめします🛠️
Q2. “missing log block”ってログが壊れたってこと？😨
A. 多くは 内部処理上の検知→再スキャンで整合を取り直したという意味です✅
ただし、I/Oエラーや接続断が絡むと別問題になるため、同時刻ログの確認が大事です🧾
Q3. どの数値が増えると危険？📈⚠️
A. 代表は👇です🚨
log_send_queue_sizeが増え続ける（送れない）📤redo_queue_sizeが増え続ける（適用できない）📥
DMVで確認できます。
Q4. まず最初にやる「最短の確認」は？🏃💨
A. SSMSのAGダッシュボードで
- SYNCHRONIZED/SYNCHRONIZING か
- SUSPENDED になっていないか
を確認するのが最短です✅
Q5. 頻発する場合、恒久対策は？🧯
A. 最新CUの適用検討が最優先です⬆️
このメッセージに関する修正KBが案内されています。
まとめ（不安を「判断できる運用」へ）🌈✅
- このイベントは 自動回復の情報メッセージとして出ることがある📩
- 単発＋AG健全なら、基本は様子見でOK👌
- 頻発なら、既知修正の可能性があるため CU適用検討が強い🧯
- SUSPENDED/queue増加/NOT_HEALTHYなら、ネットワーク・I/O含めて障害対応へ🚨
この判断軸を持っておくと、アラートが出ても慌てずに「今は問題ない」「今は動くべき」が切り分けでき、運用がかなりラクになります😊✨
コメント