目次


DB2問題判別 習熟シリーズ

第5回 データベース・エンジンの問題判別

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: DB2問題判別 習熟シリーズ

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:DB2問題判別 習熟シリーズ

このシリーズの続きに乞うご期待。

セクション1: この回について

対象読者と前提事項

DB2製品の機能をよく理解していること、およびDB2コマンドやSQLステートメントを難なく実行できることを前提とします。これには、バックアップとリストア、クラッシュ・リカバリーとロールフォワード・リカバリー、オブジェクトの作成、データ・アクセスなども含まれます。

目的

データベースの問題を解決することは、データベース管理者の重要な仕事の1つです。DB2 UDBによって提供される診断情報の分析方法を理解することは、問題判別の第1歩となります。

この回は、DB2 UDBエンジンに関する問題の理解および解決のための、エントリー・レベルの問題判別ガイドです。

表記規則

ツールやユーティリティーの名前は、初出時には太字で表記されています。

すべてのコマンド、ステートメント、およびそれらの出力は、モノスペース・フォントで表記されています。

ここで使用する例はほとんどがWindows®ベースですが、UNIX®環境でも問題なく機能します(そうでない場合は説明があります)。

この回のいくつかの例では、ユーティリティーで使用できるオプションが紹介されています。これらのオプションはリリース間で変更される可能性もありますが、基本的な部分については変わることはありません。

著者について

Aman Lallaは、1997年からIBMに勤務しています。最初の2年間は、DB2カスタマー・サイトを担当しました。現在は、DB2 UDBダウン・システム部門のチーム・リーダーを務めています。このチームの主な任務には、ダウン・システムのDB2 UDBエンジンの問題判別作業が含まれます。

Aman Lallaの連絡先については、http://www.ibm.com/contact/employees/usのIBM Global Directoryをご覧ください。彼の電子メール・アドレスを調べることができます。

セクション2: DB2DIAG.LOGの分析

db2diag.logの抜粋

概要

db2diag.logの分析は、問題判別の第1歩です。

db2diag.logの場所は、データベース・マネージャー構成パラメーターDIAGPATHによって決まります。db2diag.logファイルでは、最も最近発生したイベントがファイルの末尾にあります。

分析

以下は、DIAGLEVEL 3のdb2diag.logの抜粋です。問題判別を目的としていて、「問題が再現可能」な場合は、DIAGLEVEL 4を使用することをお勧めします。db2diag.logの主な構成要素は、以下のとおりです。

(1) 2002-05-17-17.30.32.140000   (2) Instance:DB2MPP  (3) Node:000
(4) PID:2204(db2bp.exe)   (5) TID:2224   (6) Appid:*LOCAL.DB2MPP.020517213032
(7) database_utilities  (8) sqlubckp   (9) Probe:26

DiagData
(10)  2cfc ffff                                    

2002-05-17-20.17.20.793000   Instance:DB2MPP   Node:000
PID:596(db2syscs.exe)   TID:2176   Appid:
base_sys_utilities  sqleMergeSqlca   Probe:20   Database:SAMPLE

Received sqlcode 1496 for request 8000001e from node number 1

(11) Data Title:SQLCA PID:596 TID:2176 Node:000
 sqlcaid : SQLCA     sqlcabc: 136   sqlcode: 1496   sqlerrml: 0
 sqlerrmc:
 sqlerrp : SQLESRSU
 sqlerrd : (1) 0x00000000      (2) 0x00000000      (3) 0x00000000
           (4) 0x00000000      (5) 0x00000000      (6) 0x00000001
 sqlwarn : (1)      (2)      (3)      (4)        (5)       (6)
           (7)      (8)      (9)      (10)       (11)
 sqlstate:
  1. ログに作成されたエントリーの日付とタイム・スタンプ。
  2. インスタンスの名前。この例ではDB2MPPです。
  3. ノード(パーティション)番号。単一パーティション構成では常に0になります。
  4. アプリケーション(エージェント)のプロセスID。
  5. アプリケーション(エージェント)のスレッドID。Windowsプラットフォームでのみ使用されます。
  6. アプリケーションID。LIST APPLICATIONSコマンドの出力に相当します。各アプリケーションには固有のアプリケーションIDがあります。
  7. コンポーネント名。この例の場合、このエントリーがデータベース・ユーティリティー・コンポーネントによって作成されたことがコンポーネント名からわかります。
  8. エラーまたは情報を報告しているコンポーネント内の関数の名前。
  9. 関数内のプローブ・ポイント。エラーまたは情報を返した関数のソース・コード内の場所に相当します。
  10. 診断情報。この例のdb2diag.logはWindowsプラットフォームのものであるため、ダンプされた情報はバイト反転しています。このエラーを10進数のSQLコードに変換するには、2cfc ffffをffff fc2cにバイト反転し、16進数から10進数に変換します。これにより、SQLCODEを取得できます。 ただし、この数値は、常に有効なSQLCODEに変換できるとは限りません。変換できなかった場合は、DB2サポートに連絡してください。
  11. SQLCODEを含むSQLCA構造のダンプ。

db2diag.logの分析例

概要

この例では、バックアップしようとするとエラーになるという苦情をユーザーから受けたと仮定します。ユーザーはエラー・メッセージを知りません。

分析

問題判別のステップは次のようになります。

  • db2diag.log (セクション1の抜粋を参照)を開いてファイルの末尾に移動します。最も新しいエントリーはファイルの末尾にあります。この例の場合、最後のエントリーは2002-05-17-20.17.20.793000にあります。
  • プロセスID (PID)を書き留めます。この例の場合、PIDは596です。このPIDをdb2diag.logで辿ると、報告されているエラーや警告の原因となるような問題が、これより前にこのプロセスで発生していないかどうかを調べることができます。
  • この例では、PID 596は、sqlcode 1496を持つSQLCA (11)をダンプしています。コマンドdb2 ? sql1496を実行して詳細を調べます。
    SQL1496W Deactivate database is successful, but the database was not 
    activated.
    
    Explanation:  Database was not explicitly started on one or more nodes 
    when deactivate database was executed.
    
    User Response:  Refer to the diagnostic log to see which node returns 
    this warning.

このメッセージ・コード(SQL1496W)から、返されたSQLCODEは実際には警告であり、エラーではないことがわかります。また、このメッセージからは、現在のバックアップの問題については何の情報も得られません。この時点で、PID 596によって作成されたdb2diag.logエントリーは無視できます。

  • 次のステップでは、db2diag.logを遡って、別のPIDのエントリーを見てみます。この例では、2002-05-17-17.30.32.140000 -にPID 2204のエントリーがあります。
  • Diag Data (10)に2cfc ffffがダンプされています。このdb2diag.logはWindowsプラットフォームのものであり、バイト反転しているため、実際の形式はffff fc2cです。ffff fc2cを10進数に変換すると、- 980になります。このエラーの詳細を調べるには、コマンドdb2 ? sql0980を実行します。
    SQL0980C A disk error occurred.  Subsequent SQL statements 
    cannot be processed.
    
    Explanation:  A disk error occurred that prevented successful 
    execution of the current and subsequent SQL statements.  The 
    application program is not permitted to issue additional SQL 
    statements.  For example, a recovery routine associated with 
    the application program cannot issue additional SQL statements.  
    The database is marked as needing recovery and all applications 
    using the database are prevented from accessing the database.

    これは重大なエラーのようです。このエラーを返した関数の名前(8)を確認し(sqlubckp)、それを『API Reference』で調べてみると、これがバックアップ関数であることがわかります。コンポーネント名(7)からは、データベース・ユーティリティーがエラーになっていることを確認できます。

以上の分析から、バックアップが失敗した原因はディスク・エラーにあると結論づけるのに十分な情報が得られました。この後は、DB2 UDBの外部で、ディスクの問題の原因を究明することになります。

まとめ

上の方法は、DB2 UDBエンジンのあらゆる種類の問題に応用できます。以上で、db2diag.logの分析を終わりにします。

エンジン・コンポーネント

db2diag.logを分析する際に、エラーや警告を報告しているコンポーネントの名前がわかると便利です。DB2 UDBの関数の名前はすべて"sql"で始まり、その後にコンポーネント名の短縮形が続きます。以下は、最もよく使用されるエンジン・コンポーネントのリストです。

sql、squh -

  • DB2バックアップとリストア

Sqb -

  • DB2バッファー・プール・サービス - バッファー・プール、データ・ストレージ管理、表スペース、コンテナー、入出力、プリフェッチ、ページ・クリーニング、および場合によってはデータ破損(チェックサム・エラーや不正なページ・ヘッダーなど)を担当します。

Clp -

  • DB2コマンド行プロセッサー

Sqng -

  • CodeGen CodeGenコンポーネントはSQLコンパイラーの一部であり、ステートメントのコンパイルの最終段階に当たります。CodeGenは、ステートメントのコンパイラー内部表現(QGM (Query Graph Model)グラフ)と最適化プログラムの「プラン」を入力として受け取り、後にランタイム・コンポーネントによって実行される「セクション」を生成します。
  • Sqv - データ・サービス -
    1. データ・サービスは、データ型の比較と変換のルーチンを担当します(NLS変換を除く)。このコンポーネントには、以下の処理を行うルーチンが含まれています。 char型、漢字タイプ、数値型の間の変換
    2. 10進数、浮動小数点数、整数の演算
    3. 日付、時刻、タイム・スタンプの演算と変換
    4. 任意のデータ型の比較(DB2でサポートされている比較に限る)。これらの比較ルーチンは、索引マネージャー、ソート・サービス、ランタイム、およびその他のコンポーネントによって使用されます。

Dlfm -

  • DB2 UDBにデータ・リンク・ファイル・マネージャーの機能を提供します。これによりDB2は、データベースの外部に格納されているファイルを管理することができます。

sqd、sqdx、sqdl、dart -

  • DB2データ管理サービス:
    • 表、レコード、ロング・フィールド、およびLOB (large-object)列。
    • リカバリー(ロールフォワード、ロールバック/取り消し)。
    • 表とレコードのロッキング。

sqp、sqdz -

  • DB2データ保護サービス、ロギング。

Sqx -

  • DB2索引マネージャー

squ、sqi、sqs、squs -

  • DB2ロード、インポート、エクスポート、ソート

sqno、sqnx、Runstats (複数のコンポーネントにわたる) -

  • DB2照会オプティマイザー、Explain、Runstats

sqo、sqt、sqz -

  • DB2エンジン・オペレーティング・システム・サービス

sqe、sqkd、sqkf -

  • DB2プロセス・モデル</yy>
  • BSU
  • BDS
  • FCM EEEインフラストラクチャー
  • DB2 Connect/ゲートウェイ接続プーリング
  • DB2 Connect XA
  • コンセントレーター
  • db2start / db2stop
  • Create database / Drop database at node
  • Activate database / Deactivate database
  • Add node / Drop node
  • 割り込み処理
  • ノード障害とリカバリー
  • DB2エンジン・オペレーティング・システム・サービス

セクション3: データベース・クラッシュ

概要

データベース管理者は、データベース・クラッシュとアプリケーション・クラッシュの違いを理解し、両者を区別する必要があります。問題記述では、多くの場合、ユーザー・アプリケーションのクラッシュが示唆されています。実際にアプリケーション・クラッシュによってデータベースがクラッシュしたのか、それともその逆かを特定するのは、データベース管理者の役目です。

分析: データベース・インスタンスがクラッシュしたかどうかの判別

データベース・インスタンスがクラッシュしたかどうかを判別するには、さまざまなプローブ・ポイントでdb2diag.logを調べる必要があります。セクション1で述べたように、db2diag.logの場所は、データベース・マネージャー構成パラメーターDIAGPATHによって決まります。以下は、このファイルの抜粋です。これは、DB2がクラッシュしたときに生成されたものです。

2002-05-13-18.17.10.131162   Instance:db2inst1   Node:000            
PID:53003(db2agent (GCXSDSN) 0) Appid:*LOCAL.db2inst1.020513181115 
oper_system_services  sqloEDUCodeTrapHandler   Probe:20              
Database:UUSERDB                                                     
.                                                                    
Signal number received                                               
0000 000b                                     ....

この例では、関数sqloEDUCodeTrapHandlerが16進数のシグナル0000 000b (DB2がクラッシュしたときにのみ生成されるシグナル)を返しています。これを10進数に変換すると11になります。したがって、db2シグナル・ハンドラーがシグナル#11をキャッチしたことになります。

UNIXプラットフォームでは、signal.hというヘッダー・ファイルが、通常は/usr/include/sysにあります。これにより、シグナル#11がセグメンテーション違反(SIGSEGV)であることがわかります。

以下は、ヘッダー・ファイルsignal.hの抜粋です。

 …
#define SIGBUS    10    /* (*) bus error (specification exception) */
#define SIGSEGV   11    /* (*) segmentation violation */
#define SIGSYS    12    /* (*) bad argument to system call */

ここで初めて、データベースがセグメンテーション違反によって実際にクラッシュし、データベース・シグナル・ハンドラーがそのシグナルをキャッチしたことがわかります。次に、クラッシュしたプロセスのプロセスID (PID)を特定します。db2diag.logファイルに戻り、"abnormally terminated process (異常終了したプロセス)"を見つけます。

2002-05-13-18.17.10.199694   Instance:db2inst1   Node:000  
 PID:11322(db2tcpcm 0)   Appid:none                         
 oper_system_services  sqloEDUSIGCHLDHandler   Probe:20     
 .                                                          
 PID of abnormally terminated child process:                
 0000 cf0b

プローブ20の関数sqloEDUSIGCHLDHandlerが、16進数のPID、0000 cf0bをダンプしています。これを10進数に変換すると53003になります。

シグナル#11のdb2シグナル・ハンドラーは、トラップ・ファイルをダンプします。このファイルの名前には、命名規則に基づいてPIDが使用されています。この例の場合は、t53003.000というファイルが../sqllib/db2dumpディレクトリーに生成されます。AIXなど一部のプラットフォームでは、COREファイルも生成されます。

このトラップ・ファイルには、クラッシュしたプロセスのスタック上にあったすべての関数のスタック・トレースバックが含まれています。トラップ・ファイルの一番上から始めて、シグナル#11が発生したポイントを探します。

以下は、トラップ・ファイルt53003.000のヘッダーです。

DB2 (db2inst1.000) : db2agent (GCXSDSN) 0 (0x1)                    
2002-05-13-18.17.03.884465                                         
signal #11 encountered, stack traceback follows:                   
siginfo_t (length=128)                                             
...                                                                
PC location: __0FKMemTreeDelPP6ISMemNodeP6HSMemSeg + 0x150         
.                                                                  
/home01/db2inst1/sqllib/adm/db2sysc: sqlo_trce + 0x310             
/home01/db2inst1/sqllib/adm/db2sysc: sqloEDUCodeTrapHandler + 0x34 
 
__0FNMemReleaseSegP6HSMemSeg + 0x44                                
  sqlofmblkEx + 0x390

この例では、MemTreeDelという関数でトラップしたことがわかります。クラッシュのより詳しい情報は、AIXのエラー報告書(errpt)やSun Solarisのメッセージ・ファイルなど、オペレーティング・システムのエラー・ログで見つけることができます。

結論

一般に、シグナル#11はDB2の障害を示します。したがって、すべての関連情報をDB2サポート・チームに提供する必要があります。

セクション4: ロッキングのトラブルシューティング

概要

DB2 UDBはマルチユーザー・データベースであるため、データベース・エンジンにロッキングのメカニズムが備わっています。これにより、リソース競合の回避や、データ保全性の確保が実現されます。ロッキングを理解することは、データベース管理者にとっても、アプリケーション開発者にとっても重要です。データベース管理者は、スナップショットや、場合によってはモニターまでを分析して、ロッキングの問題を引き起こしているアプリケーションを特定できなければなりません。アプリケーション開発者は、アプリケーション・ロックの影響を最小限に抑えるようにアプリケーションを設計します。

ロッキングの問題のデータ収集

ロッキングの問題では、アプリケーションがハングするという症状がよく見られます。ハングは通常、データベース・エンジン内では"Lock Wait"として現れます。アプリケーションが"Lock Wait"の状態にあることを確認するには、データベース管理者がロック・スナップショットとアプリケーション・スナップショットを取得する必要があります。

ロッキング状態が発生していると思われる場合は、以下のステップを実行します。

ステップ1: ロック・スナップショットを取得します。

 db2 get snapshot for locks on sample

ステップ2: アプリケーション・スナップショットを取得します。

db2 get snapshot for applications on sample

ステップ3: データベースに接続しているアプリケーションのリストを取得します。

 db2 list applications all

ロック・スナップショットの分析

  • 取得したロック・スナップショットを開き、"Lock-wait"のアプリケーション状態を探します。複数のアプリケーションがこの状態になっている場合もあります。

    アプリケーション・ハンドル1のロック・スナップショットの抜粋

    Application handle                    = 1
    Application ID                             = *LOCAL.amanl.021106192019
    ………
    Authorization ID                           = AMANL
    Application status                    = Lock-wait
    Status change time                         = 11-06-2002 14:20:28.739223
            ……….
            Locks held                                 = 3
    Total wait time (ms)                       = 59003

    アプリケーション・ハンドルを書き留めておきます。この例の場合は1です。

  • アプリケーション・ハンドル1が待っているロックを保持しているアプリケーションのIDを特定します。
    …………………….
    Subsection waiting for lock              = 0
    ID of agent holding lock            = 0
    Application ID holding lock              = *LOCAL.amanl.021106191959
    ……………………

    これで、ハンドル1のアプリケーションがハンドル0のアプリケーションを待っていることがわかりました。

  • アプリケーション・ハンドル0の状態を調べます。
    ………………
    Snapshot timestamp                    = 11-06-2002 15:06:35.977515
    ……………….
    Application handle                         = 0
    Application ID                             = *LOCAL.amanl.021106191959
    Sequence number                            = 0001
    Application name                           = db2bp
    Authorization ID                           = AMANL
    Application status                    = UOW Waiting
    Status change time                         = 11-06-2002 14:20:02.057647

    このアプリケーションは、"UOW Waiting"状態にあります。これは、アプリケーションがなにか別の処理を実行しているか、開いているUOW (作業単位)があることを意味します。アプリケーションがアイドル状態の場合(未処理の作業がもうない場合)は、状態が"Idle"になります。アイドル状態のアプリケーションがデータベース・ロックを保持することはありません。

    このほか、"status change time"と"snapshot timestamp"を比較します。これにより、上の例の場合は、このアプリケーションが40分以上にわたって"UOW Waiting"状態にあることがわかります。

    ………………………….
    Lock object type                         = Row
    Lock mode                                = Exclusive Lock (X)
    Lock mode requested                      = Next Key Share (NS)
    ……………………………..

    ロック・スナップショットからは、アプリケーション・ハンドル1がNext Key Share (NS)ロックを要求しているが、アプリケーション・ハンドル0がExclusive Lock (X)を持っているため、アプリケーション・ハンドル1はアプリケーション・ハンドル0を待っている、ということがわかります。アプリケーション・スナップショットを分析すると、アプリケーション・ハンドル0に関するより詳しい情報が得られます。

    (X)ロックは(NS)ロックと互換性がないため、Lock-Wait状態になります。ロックの互換性については、『DB2 UDB Administration Guide』を参照してください。

    アプリケーション・ハンドル0のアプリケーション・スナップショットの抜粋
    ……………..
    Elapsed time of last completed uow (sec.ms)= 0.000000
    UOW start timestamp                   = 11-06-2002 14:20:01.972039
    UOW stop timestamp                    =
    UOW completion status                 =
    Open remote cursors                        = 0
    ……………..
    ……………..
    Rows inserted                              = 0
    Rows fetched                               = 0
    Blocking cursor                            = NO
    Dynamic SQL statement text:
    insert into staff values (99,'aman',20,'Sales',5,10000,75.60)
    Agent process/thread ID                  = 355954

    このアプリケーション・スナップショットから、このUOWは開始されているがまだ完了されていないことが確認できます。したがって、このUOWはまだ開いていることになります。もしもデータベースがこの時点でクラッシュすると、このトランザクションはまだディスクに書き込まれていないため、失われることになります。

    また、このスナップショットからは、このアプリケーション・ハンドルが動的SQLステートメント(この場合は表STAFFへの挿入)を実行していることもわかります。

    ………………………..
    Number of SQL requests since last commit   = 1
    Commit statements                     = 0
    Rollback statements                        = 0
    ………………………..
    Locks held by application             = 3
    Lock waits since connect                   = 0
    Time application waited on locks (ms)      = 0
    …………………………..

    アプリケーション・ハンドル0はまだコミットを行っておらず、3つのロックを保持しています。これらのロックの詳細は、ロック・スナップショットで見ることができます。

    …………………………..
    …………………………..
     List Of Locks
     Lock Object Name            = 39
     Node number lock is held at = 0
     Object Type                 = Row
     Tablespace Name             = USERSPACE1
     Table Schema                = AMANL
     Table Name                  = STAFF
     Mode                       = X
     Status                     = Granted
     Lock Escalation             = NO
    …………………………….
    …………………………….

    アプリケーション・ハンドル0が保持している3つのロックの中に、許可されているXロックがあります。

    以上の分析から、このロッキング状態は、排他的アクセスを必要とする表へのINSERTを実行しているアプリケーションが、必要なロックをすべて許可されたがまだコミットを行っていないことが原因である、と結論づけることができます。より弱いロックを持つアプリケーションは、このUOWがコミットされるまで待たなければなりません(これはカーソル固定(CS)分離レベルのデフォルトの動作です)。アプリケーション・ハンドル0は、より頻繁にコミットを行う必要があります。

セクション5: リカバリーのトラブルシューティング

概要

万一の場合にデータベースをリカバリーするためには、データベースを頻繁にバックアップしておくことが欠かせません。リカバリーのオプションや上位の処理を理解することによって、リカバリーにまつわる一般的な不安を和らげることができます。データベースのリカバリーは、データベース管理者が行うきわめて重大な作業の1つです。

主要なバックアップ/リストア・プロセス

db2agent
すべての子プロセスのコーディネーター。アプリケーションとの通信をすべて処理します。

db2bm
db2バッファー・マニピュレーター。プリフェッチャーを使って入出力要求を処理します。バックアップ/リストア・バッファーへのデータの書き込み、およびそこからのデータの読み取りを行い、データをdb2medプロセスに渡します。

db2med
db2メディア・コントローラー。バックアップ先との入出力を処理します。データはバックアップ/リストア・バッファーから書き込まれ、そこに読み込まれます。バッファーはdb2bmに戻されます。

db2ckbkpによるバックアップ・イメージのチェック

現在DB2 UDBには、db2ckbkpというユーティリティーが用意されています。このユーティリティーを使用すると、バックアップ・イメージを検証できます。オプションの詳細を調べるには、引き数を何も指定せずにdb2ckbkpを実行します。以下は、db2ckbkpユーティリティーを使用できるシナリオの例です。

SQL1013N  The database alias name or database name "ITB20" could not be 
found.                               

2002-10-12-10.28.52.710000   Instance:DB2   Node:000          
PID:-2296-439445(DB2SYSC.EXE)   TID:-439445                   
Appid:*LOCAL.DB2.021012172526                                 
database_utilities  sqludMRWarn   Probe:40   Database:ITB20   
.                                                             
16f6 ffff 433a 5c44 4232 4261 636b 7570       .oyyC:\DB2Backup
5c49 5442 3230 2e30 5c44 4232 5c4e 4f44       \ITB20.0\DB2\NOD
4530 3030 305c 4341 544e 3030 3030 5c32       E0000\CATN0000\2
3030 3230 3931 335c 3039 3237 3339 2e30       0020913\092739.0
3031 00                                      01.

上のエラーは、バックアップ・イメージが見つからないことを示しています。この場合、指定した場所にイメージはあるのに破損している、という可能性があります。バックアップ・イメージに問題がないかどうかを確認するには、-aオプションを指定してdb2ckbkpを実行して、できるだけ多くの情報をダンプします。

バックアップ・イメージに何も問題がなければ、次のメッセージが返されます。

Image Verification Complete - successful.

ヒストリー・ファイルの基本的な分析

すべてのDB2 UDBデータベースには、管理操作を記録するヒストリー・ファイルがあります。各データベースと共にリカバリー・ヒストリー・ファイルが作成され、自動的に更新されます。データベースの移行の際には、ヒストリー・ファイルも一緒に移行されます。ヒストリー・ファイルにアクセスするには、次のコマンドを実行します。

db2 list history all for <dbname>

データベース・ヒストリー・ファイルは、リカバリーのシナリオにおいてきわめて重要です。ヒストリー・ファイルは、どのバックアップ・イメージからでも独立してリストアできます。現在のデータベースが使用できなくなったときに、関連付けられているリカバリー・ヒストリー・ファイルが破損していたり削除されていたりした場合は、RESTOREコマンドのオプションを使用すると、リカバリー・ヒストリー・ファイルだけをリストアすることができます。その後、リカバリー・ヒストリー・ファイルを調べることにより、データベースをリストアするのにどのバックアップを使用すればよいのかがわかります。たとえば、ここで使用しているサンプル・データベースのヒストリー・ファイルをリストアするには、次のコマンドを使用します。

db2 restore database sample history file

リカバリー・ヒストリー・ファイルからは、バックアップ・イメージを使ってデータベースや表スペースをリカバリーするのに十分な情報を得ることができます。

ヒストリー・ファイルの抜粋

Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log  Backup ID
 -- --- ------------------ ---- --- ------------ ------------ --------------
  B  D  20021107151552001   N    D  S0000002.LOG S0000003.LOG
 ----------------------------------------------------------------------------
  Contains 2 tablespace(s):

  00001 SYSCATSPACE
  00002 USERSPACE1
 ----------------------------------------------------------------------------
    Comment: DB2 BACKUP SAMPLE ONLINE
 Start Time: 20021107151552
   End Time: 20021107151613
 ----------------------------------------------------------------------------
  00007 Location: c:\backups\SAMPLE.0\DB2MPP\NODE0000\CATN0000\20021107

ヒストリー・ファイル内の重要な情報には、次のようなものがあります。

Op: 実行された操作です。上の例では"B"です。これは、バックアップを表します。Opで使用される値のリストについては、『UDB Administration Guide』を参照してください。

Obj: バックアップの細かさです。"D"はデータベース・バックアップ、"T"は表スペース・バックアップを表します。

Earliest Log: オンライン・バックアップの場合、ロールフォワード操作に必要な最初のログです。

Current Log: バックアップが完了したときに書き込まれた最後のログです。オンライン・バックアップの場合、バックアップが完了するのに必要な最小限のログです。

ポイント・イン・タイム・リカバリー ヒストリー・ファイルのEarliest LogとCurrent Logは、バックアップが実行されたときに使用されたログの範囲であり、バックアップの一部と見なされます。これらのログがないとバックアップは完了できず、データベースはロールフォワード・ペンディング状態のままになります。

Earliest LogとCurrent Logの間のログ範囲にあるポイント・イン・タイムへのロールフォワードを実行しようとすると、db2diag.logは次のようなメッセージをダンプします。

 2002-11-18-04.18.25.860819   Instance:ispbdw01   Node:008        
PID:334510(db2agntp (DBPBDW) 8)   Appid:*N0.ispbdw01.021118091637
recovery_manager  sqlpCheckStopTime   Probe:55   Database:DBPBDW 
.                                                                
Invalid stop time: 3dd7 2250 0000 0000 3dd7 d45f 0000 0000

セクション6: LOADユーティリティーのトラブルシューティング

概要

LOADは、ファイルやパイプからデータベースにデータをバルクロードするためのユーティリティーです。LOADには、最大で3つのフェーズがあります。ロード・フェーズでデータをロードし、作成フェーズで索引を作成し(ある場合)、削除フェーズで重複を削除します(固有索引がある場合)。

LOADのプロセス

以下は、主要なロード・プロセスです(Xは多数のうちの1つを識別する番号)。

db2agent
db2lmr ロード・メディア・リーダー。このプロセスは入力を読み取ります。
db2lbmX ロード・バッファー・マニピュレーター。ロードされたデータをデータベースに書き込みます。
db2lfrmX ロード・フォーマッター。入力データを内部形式にフォーマットします。
db2lrid リッダー。ディスクに書き込むデータを整理します。索引のソートを実行します。
db2lmwX ロード・メディア・ライター。ロード・コピーを書き込みます。

LOADの失敗

LOADが失敗して表スペースにアクセスできなくなった場合、以下のような対処が可能です。

  • LOADを再開する
  • LOADを終了する
  • 最新のバックアップからのリストアを行い、LOADが失敗する前のポイント・イン・タイムにロールフォワードする
  • 表スペースをドロップして再作成する

ロードが失敗した場合は、db2diag.logで次のようなメッセージがよく見られます。

2002-10-23-15.46.55.454018   Instance:db2inst1   Node:000               
PID:2038(db2agent (DWCORP))   Appid:*LOCAL.db2inst1.021023174208        
database_utilities  call_sqluvload   Probe:40   Database:DWCORP         
.                                                                       
Load Error: Load failed for table DW      .DW_PROD_MED in tablespace 7.

コンポーネント名と関数名が、Loadユーティリティーに問題があることを示しています。さらに、次のコマンドを実行すると、ロードする表がある表スペースの状態を調べることができます。

   db2 list tablespaces show detail

典型的な出力は次のようになります。

Tablespace ID                        = 15                    
Name                                 = TS_BOYDC2             
Type                                 = System managed space  
Contents                             = Any data              
State                                = 0x0004                
        Detailed explanation:                                      
        Quiesced: EXCLUSIVE                                      
...                                      
Number of quiescers                  = 1 
Quiescer 1:
Tablespace ID                    = 15 
Object ID                        = 43

DB2に用意されているdb2tbstツールを使用すると、この表スペース状態を調べることができます。

上の例の場合は、次のコマンドを実行します。

 db2tbst 0x0004

結果は次のようになります。

 State = Quiesced Exclusive

この状態では、表スペースにアクセスすることはできません。表スペースをこの状態から解放するには、次のコマンドを実行します。

 db2 quiesce tablespaces for table FDE_OPCF.ACTION reset

FDE_OPCF.ACTIONは、ロードする表の名前です。

Version 7までのバージョンのLOADは、ロードを開始するときに表に対してQUIESCE EXCLUSIVEを実行し、コミットするときにQUIESCE RESETを実行します。また、ロード・フェーズや作成フェーズでは表スペース状態LOAD PENDINGを使用し、削除フェーズではDELETE PENDINGを使用します。これらの状態は、ロードが割り込まれたり失敗したりした後も持続します。これらを解放するには、LOAD RESTART、LOAD TERMINATE、LOAD REPLACEのいずれかを実行する以外にありません。

LOADの一時ファイル

インスタンス・ディレクトリーには、"load/DB2XXXXX.PID/DB2YYYYY.PID"というサブディレクトリーがあります(XXXXXとYYYYYは、ロードに含まれる表のプール(表スペース)とオブジェクトのID)。このサブディレクトリーは、ロードの実行中だけ存在し、ロードが終了すると削除されます。ユーザーは、このディレクトリーには一切手を触れないように警告されます。ユーザーがこのディレクトリーに変更を加えたりすると、リカバリーが困難になります。

通常このディレクトリーには、ロケーション・ファイル、最小リカバリー・ファイル、メッセージ・ファイル、およびロード制御ファイルが含まれています。ロケーション・ファイルと最小リカバリー・ファイルは、常にこのディレクトリーにある必要があります。db2 loadコマンドのTEMPFILES PATHパラメーターにユーザーがデフォルト以外のパスを指定した場合は、このディレクトリーにその他のファイルが含まれることもあります。

load.loc
ロケーション・ファイルには、制御ファイルとメッセージ・ファイルが通常置かれているディレクトリーが含まれています。このディレクトリーは、loadコマンドのTEMPFILES PATHパラメーターによって制御されます。デフォルトの場所は、ロケーション・ファイルと同じディレクトリーです。このファイルはASCIIファイルです。

load.min
最小リカバリー・ファイルは、万が一制御ファイルがなくなった場合に、LOAD REPLACEのために使用されます。たとえば、ユーザーがTEMPFILES PATHで別のディレクトリーを指定して、その後そのディレクトリーを削除したとします。このシナリオでも、まだLOAD REPLACEは可能です。最小リカバリー・ファイルはバイナリー・ファイルです。内部ツールsqluckctを使用すると、ASCIIファイルに変換できます。

load.CT1、load.CT2
これらはロード制御ファイルです。これらのファイルがないと、ユーザーはLOAD TERMINATEやLOAD RESTARTを実行できません。これらのファイルは、どの時点においても少なくとも1つのバージョンは正しくなるように、シャドー・プロトコルを使用しています。ロード制御ファイルはバイナリー・ファイルです。sqluckctを使用すると、ASCIIファイルに変換できます。

load.msg
ロードの最後に表示されるロード・メッセージ・ファイルのバイナリー形式です。load queryコマンドでASCIIファイルに変換できます。

db2 load query filename

filenameは、メッセージ・ファイルの名前です(.msg拡張子は除く)。

表をオンラインに戻す方法

ロードが失敗した後に、表スペースがLOAD PENDING状態やDELETE PENDING状態のままになってしまうことがあります。通常、失敗したロードをロールバックするには、LOAD TERMINATEを使用します。この場合、元のloadコマンドは、代わりにTERMINATEを使って再実行されます。また、LOAD RESTARTを使ってロードを再開することもできます。この場合は、元のloadコマンドがRESTARTコマンドで置き換えられます。たとえば、次のロードが割り込みを受けたとします。

 db2 load from File1 of del insert into T1

ロードに含まれる表スペースは、ロード・フェーズまたは作成フェーズの間に割り込みが入った場合はload pending状態のままになり、削除フェーズの間に割り込みが入った場合はdelete pendingのままになります。この場合、以下のどのコマンドでも実行できます。

 db2 load from File1 of del terminate into T1

LOAD TERMINATEは、失敗したロードをロールバックしようとします。LOAD TERMINATEではファイル名は無視されます。

 db2 load from File1 of del restart into T1

LOAD RESTARTは、ロードを再開しようとします。

 db2 load from File1 of del replace into T1

LOAD REPLACEは、T1のすべてのデータをFile1のデータに置き換えます。注: 上のどのタイプのロードでも、正常に終了した場合、表スペースはLOAD PENDING (またはDELETE PENDING)から解放されます。一般に、LOAD TERMINATEでは、索引に要再作成のマークが付けられ、データがLOAD INSERT前のサイズに切り捨てられます。LOAD REPLACEに失敗した場合にも、LOAD TERMINATEやLOAD RESTARTを実行できます。ただし、その場合は、LOAD TERMINATEでは表が切り捨てられます。LOAD TERMINATEは、LOAD REPLACEが実行される前に存在していたデータを回復することはできません。

上のいずれかの方法で、表をオンラインに戻すのに失敗する場合は、たいていは静止の問題か、そうでなければ制御ファイルに問題があります。以下のような、有用な情報を含むメッセージが返される場合もあります。

SQL3508N  Error in accessing a file or path of type 
"RESTART/TERMINATE INFO" during load or load query.  
Reason code: "1".  Path: "".

結論

以上の説明で、LOADユーティリティーに関連するほとんどの問題を解決できます。これで、LOADユーティリティーについての説明を終わりにします。

セクション7: サマリー

この回で学んだこと

ここでは、DB2 UDBエンジンに関連する一般的な問題の診断方法について説明しました。

db2diag.log、ヒストリー・ファイル、およびLOADのメッセージ・ファイルに記録されるエントリーについての理解も深まったはずです。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Information Management
ArticleID=322699
ArticleTitle=DB2問題判別 習熟シリーズ: 第5回 データベース・エンジンの問題判別
publish-date=11162005