オブジェクト破損時の対応：その３(原因調査のアプローチ)(KROWN:135926)

[概要]
本文書は、ブロック破損が発生した際の原因調査のアプローチについて説明しま
す。

破損ブロックの確認、復旧および原因調査について、それぞれ以下の文書を参照
して下さい。

  Document 1746539.1(KROWN:135804) オブジェクト破損時の対応：その１(破損ブロックの確認)
  Document 1746576.1(KROWN:135925) オブジェクト破損時の対応：その２(破損ブロックの復旧)
  Document 1746577.1(KROWN:135926) オブジェクト破損時の対応：その３(原因調査のアプローチ)


[対象リリース]
すべてのリリース


[対象プラットフォーム]
すべてのプラットフォーム


[詳細]

原因調査のアプローチ
====================

  既にブロック破損が発生してしまっている状況では、破損している状況の確認
  はできますが、何故破損したのかといった破損経緯を追うことは非常に難しく、
  破損した状況からの調査は非常に困難です。




  1) 以下を確認します。
  
     - エラーが発生するまでどのような作業を行っているか
     - データベースを停止せずに OS を shutdown していないか
     - OS で何かエラーを検知していないか
         messages,syslog,errpt,イベントビューアなどを確認します。
  
  
  2) ブロックが更新された SCN を含むアーカイブログを特定します。
  
     復旧を行う際に取得したブロックダンプより問題のブロックに格納されてい
     る SCN を調べます。
  
      -----------
      buffer tsn: 0 rdba: 0x00400062 (1/98)
      scn: 0x0000.000fee5a seq: 0x01 flg: 0x06 tail: 0xee5a0601
      ^^^^^^^^^^^^^^^^^^^^ <--- ★
      frmt: 0x02 chkval: 0x5b40 type: 0x06=trans data 
      Hex dump of block: st=0, typ_found=1
      -----------
  
      上記 SCN より該当の SCN を含むアーカイブログを確認します。
      SCN を16進数から10進数に変換して以下の SQL を実行します。

     SQL> select SEQUENCE#,NAME,FIRST_CHANGE#,FIRST_TIME,NEXT_CHANGE#,NEXT_TIME,
       2  RESETLOGS_CHANGE# from v$archived_log where FIRST_CHANGE# < <SCN#> and  
       3  <SCN#> < NEXT_CHANGE# order by RESETLOGS_CHANGE#,SEQUENCE#;
  
  
  3) 2) で確認した更新を含むアーカイブログの REDO ダンプを取得します。
     * アーカイブログファイルも保管します。
  
     例)
     SQL> alter system dump logfile '<archive_logfile_path>'  
       2  SCN MIN '<SCN#>-3000' SCN MAX '<SCN#>+3000';
  
     * RAC 環境では、該当する全スレッドのREDOをダンプします。
  

  
  
  4) 2) で確認したアーカイブログが生成された時間帯の更新処理を確認し、
     再現ケースを特定します。

     - アプリのログ等から該当の時間帯の更新処理を確認
     - ログマイナーにより該当の時間帯の更新処理を確認
     - 処理内容から再現ケースの特定

  5) OS, HW 側からの調査

     ブロックに更新が行われた時間帯に、OS, HW 側で問題が発生していなかっ
     たかを確認します。