問題判別の手引き
この節では、DB2 サーバーを使用するユーザーがしばしば直面する問題を処理する方法について説明しています。
以下のトピックが扱われます。
このトピックに関する付加的な問題判別情報については、
以下の資料を参照してください。
重要: この節では、DB2 カスタマー・サポートから利用可能な情報の簡単なサンプルを示します。
DB2 に関する完全な最新情報については、DB2 Product and Service Technical Library (URL は http://www-4.ibm.com/software/data/db2/library/) を参照してください。
(この情報は英語のみですのでご注意ください。)
バージョン 7 への移行にあたって問題が生じる場合には、以下のことを確認してください。
- [ ]
- 概説およびインストール 資料にある指示に従ったか。
- [ ]
- 前のバージョンからの非互換性のリストを確認したか。
(管理の手引き: 計画 を参照。)
- [ ]
- データベースに矛盾がないか。
データベースが一致していて、データベースを移行できるかどうかを確かめるには、
db2ckmig コマンドを使用してください。
(詳細については、概説およびインストール を参照してください。)
以下の状態に該当するデータベースについて報告されるすべてのエラーを訂正しなければなりません。
- バックアップ保留中: データベースのバックアップを実行します。
- ロールフォーワード保留中: ROLLFORWARD DATABASE コマンドを実行または再開することによって必須となるデータベースを回復します。
- データベース不整合: データベースを再始動して、整合性を保持します。
さらに、このツールは、SYSCAT、SYSSTAT、または SYSFUN をスキーマ名として使用するオブジェクトを含むデータベースを識別します。
これらのオブジェクトは、除去し、異なるスキーマ名を使用して再作成しなければなりません。
- [ ]
- マシン上に十分なディスク・スペースがあるか。
(必要なディスク・スペースの量は、データベースによって異なります。)
- [ ]
- 1 次および 2 次ログ・ファイルの数 (データベース構成の logprimary および
およびログ・ファイルのサイズ (データベース構成の logfilsiz) に適切な値を使用しているか。
詳細については、サーバー障害を参照してください。
- 症状
- 修正パックのインストール後か、オペレーティング・システムのレベルの変更後に、
エラー・メッセージ SQL1042C を受け取りました。
- 推定原因
- 修正パックやオペレーティング・システムのレベル変更が、
DB2 インスタンス (データベース管理プログラム) に識別される必要があります。
- 処置
- DB2 の修正パックのインストール後かオペレーティング・システムのレベルの変更時に、
db2iupt を実行してください。
- 症状
- DB2 サーバーが要求に対して応答していないか、
または予期しない応答を返しました。
- 処置
- 以下のことを確認してください。
- [ ]
- サーバー上の db2diag.log ファイルを検査して、原因を診断する。
詳細については、db2diag.log の解釈を参照してください。
- [ ]
- DB2COMM が、クライアントの接続に必要なプロトコルに設定されているか。
(そうでない場合、通常はメッセージ SQL5043N を受け取ります。)
db2diag.log ファイルを調べ、
正常に開始されなかった通信プロトコルとその理由を確かめてください。
詳細については、db2diag.log ファイルを使用してサーバー通信問題を診断するを参照してください。
- [ ]
- 十分なログ・スペースがあるか。
(そうでない場合、通常は SQL0964C メッセージを受け取ります。)
ログ・スペースを増やすには、以下のようにします。
- 1 次または 2 次ログ・ファイル (データベース構成の logprimary および logsecond) の数を増やします。
-
ログ・ファイルのサイズ (データベース構成の logfilsiz) を大きくします。
変更を開始するには、データベースからすべてのアプリケーションを切断し、
データベースが活動化されている場合は非活動化します。
ログを含むファイル・システムまたはディスク・スペースが、
すべてのログを保持できるほどの大きさであるかを確認しなければなりません。
ログ・ファイルに必要なスペースの量 (バイト数) は次の範囲です。
(logprimary * (logfilsiz + 2) * 4096) + 8192
から
((logprimary + logsecond) * (logfilsiz + 2) * 4096) + 8192
- [ ]
- 索引が有効であるか。
db2diag.log ファイルは、索引が再作成される必要があるかどうかを示します。
索引を不整合としてマーク付けするには、db2dart /MI を使用します。
db2dart /MI の詳細については、
各種問題判別ツールを参照してください。
データベースが始動されるまで索引の再作成を遅らせるには、
管理の手引き: パフォーマンス に説明されているように、INDEXREC 構成パラメーターを使用してください。
- [ ]
- データに矛盾がないか。
以下のデータ矛盾に関する症状があるか探してください。
- db2diag.log ファイル内に DIA3700C エラー「A bad page was encountered」がある。
- 特定のデータへのアクセス時にサーバーが停止する。
この場合、このデータ・リソースが損傷を受けている可能性があります。
- サーバーが繰り返し失敗する。
db2dart を実行して、
データが整合しているか検査してください。
データが一致していない場合には、DB2 カスタマー・サポートと連絡をとってください。
- [ ]
- 適切な修正パックをインストールして、
DB2 の最新のバージョンを使用しているか。
Web サイトにアクセスして、生じている問題と、
その問題を修正する修正パックについて調べてください。
詳細については、DB2 製品の更新を参照してください。
DB2 ユニバーサル・データベース エンタープライズ拡張エディションの特定のオペレーティング・システムをサポートする版について、
データベース管理プログラムが開始しないも参照してください。
Windows 95 または Windows 98 環境で db2start コマンドを正常実行するには、
以下のいずれかを行う必要があります。
- Windows のログオン・ウィンドウか Microsoft ネットワーキングのログオン・ウィンドウを使用してログオンする。
- db2logon コマンドを発行する (db2logon コマンドについては、
1 の注を参照してください)。
また、ログオン時や db2logon コマンドの発行時に指定するユーザー ID は、
DB2 の要件を満たしていなければなりません (2 の注を参照してください)。
db2start コマンドを開始する際には、まずユーザーがログオンしているかどうか調べてください。
ユーザーがログオンしている場合、db2start コマンドはそのユーザーの ID を使用します。
ユーザーがログオンしていない場合は、db2start コマンドにより、
db2logon コマンドが実行されているかどうかが調べられます。
実行されている場合、db2start コマンドは db2logon コマンドに指定されているユーザー ID を使用します。
db2start コマンドにより有効なユーザー ID が検出されないと、
このコマンドは終了します。
Windows 95 および Windows 98 に DB2 ユニバーサル・データベース バージョン 6 をインストールする際には、
デフォルトではインストール・ソフトウェアにより「スタートアップ」フォルダーへのショートカットが追加され、
システムのブート時に db2start コマンドが実行されます (詳しくは、1 の注を参照してください)。
システムのユーザーがログオンしておらず、db2logon コマンドも発行していない場合は、db2start コマンドは終了します。
読者またはユーザーが通常は Windows やネットワークにログオンしない場合は、
バッチ・ファイルから以下のようにコマンドを実行して、
db2start コマンドを発行する前に db2logon コマンドを発行する必要がないようにすることができます。
- db2start.exe コマンドの後に db2logon コマンドを発行するバッチ・ファイルを作成します。
たとえば、以下のようにします。
@echo off
db2logon db2local /p:password
db2start
cls
exit
- バッチ・ファイルに db2start.bat という名前を付け、
DB2 をインストールしたドライブおよびパスの下の /bin ディレクトリーに格納します。
この場所にバッチ・ファイルを格納すると、
オペレーティング・システムでは確実にバッチ・ファイルに対するパスを検出できます。
DB2 をインストールしたドライブとパスは、DB2 レジストリー変数 DB2PATH に格納されます。
DB2 をインストールしたドライブとパスを検索するには、以下のコマンドを発行してください。
db2set -g db2path
db2set コマンドによって値 c:\sqllib が戻されると想定します。
この場合、以下の場所にバッチ・ファイルを格納します。
c:\sqllib\bin\db2start.bat
- システムのブート時に DB2 を開始するには、
「スタートアップ」フォルダー内のショートカットからバッチ・ファイルを実行する必要があります。
以下の 2 つのオプションがあります。
- DB2 インストール・プログラムによって作成されたショートカットに変更を加えて、
db2start.exe の代わりにバッチ・ファイルが実行されるようにする。
前述の例では、ショートカットにより db2start.bat バッチ・ファイルが実行されるようになります。
DB2 インストール・プログラムにより作成されるショートカットは DB2 - DB2.lnk という名前になり、
ほとんどのシステムでは c:\WINDOWS\Start Menu\Programs\Start\DB2 - DB2.lnk に格納されます。
- バッチ・ファイルを実行するための独自のショートカットを追加して、
DB2 インストール・プログラムによって追加されたショートカットを削除する。
DB2 ショートカットを削除するには、以下のコマンドを使用します。
del "C:\WINDOWS\Start Menu\Programs\Startup\DB2 - DB2.lnk"
独自のショートカットを使用することにした場合は、
ショートカットのプログラム終了時にウィンドウを閉じる 属性を設定する必要があります。
この属性を設定しないと、db2start コマンドが正常に完了した場合でも、
タスクバー内に DOS コマンド・プロンプトが残ります。
db2start プロセス中に DOS ウィンドウがオープンしないようにするには、
実行時の大きさを最小化の状態に設定して、このショートカット (およびこのショートカットを実行する DOS ウィンドウ) を作成できます。
注: | システムのブート時に DB2 を開始する代わりに、
DB2 を使用するアプリケーションの実行直前に DB2 を開始することができます。
詳細については、5 の注を参照してください。
|
バッチ・ファイルを使用して、
db2logon コマンドを発行してから db2start コマンドを実行する場合に、
ユーザーが時折ログオンするのであれば、db2start コマンドは引き続き実行されます。
異なるのは、DB2 がログオン・ユーザーのユーザー ID を使用する点だけです。
詳細については、1 の注を参照してください。
注:
- db2logon コマンドは、ユーザー・ログオンをシミュレートします。
db2logon コマンドの形式は以下のとおりです。
db2logon userid /p:password
DB2 の命名要件を満たすユーザー ID をこのコマンドに指定しなければなりません (詳しくは、
2 の注を参照してください)。
ユーザー ID とパスワードを指定せずにこのコマンドを発行すると、
ユーザー ID とパスワードの入力を求めるウィンドウがオープンします。
ユーザー ID だけしかパラメーターに指定しなかった場合は、パスワードは要求されません。
ただし後述のように、特定の条件下ではパスワードは必須です。
db2logon コマンドによって設定したユーザー ID とパスワードは、
ユーザーが Windows のログオン・ウィンドウか Microsoft ネットワーキングのログオン・ウィンドウを使用してログオンしなかった場合に限り使用されます。
ユーザーがログオンしている場合に db2logon コマンドが発行されていると、
すべての DB2 アクションに db2logon コマンドのユーザー ID が使用されますが、
db2logon コマンドに指定されているパスワードは無視されます。
ユーザーが Windows のログオン・ウィンドウか Microsoft ネットワーキングのログオン・ウィンドウを使用してログオンしていない場合は、
db2logon コマンドに指定したユーザー ID とパスワードが以下のように使用されます。
- バージョン 6 では、
ログオンに使用されるユーザー ID や db2logon コマンドに指定されるユーザー ID は、
以下の DB2 要件に準拠していなければなりません。
- 長さは最大 8 文字 (バイト) でなければならない。
- USERS、ADMINS、GUESTS、PUBLIC、LOCAL、
または SQL 解説書 にリストされている SQL 予約語は使用できない。
- 先頭を SQL、SYS、または IBM にすることはできない。
- 以下の文字を使用できる。
- A 〜 Z (Windows 95 および Windows 98 では大文字小文字の区別があるユーザー ID がサポートされている)
- 0 〜 9
- @、#、または $
- 「スタートアップ」フォルダー内に db2start ショートカットが作成されないようにするには、
対話式のカスタム・インストールを行うか、
または応答ファイルのインストール時に DB2.AUTOSTART=NO オプションを指定します。
この種のオプションを使用すると、「スタートアップ」フォルダー内に db2start ショートカットは作成されないので、
db2start.bat ファイルを実行するための独自のショートカットを追加しなければなりません。
- Windows 98 の場合、
オプションを使用して、Windows 98 の開始時に常にログオンされるユーザー ID を指定できます。
指定すると、Windows のログオン・ウィンドウは表示されません。
このオプションを使用すると、ユーザー ID が DB2 の要件を満たしていれば、
ユーザーはログオンし、db2start コマンドは正常に実行されます (詳細については、
2 の注を参照してください)。
このオプションを使用しないと、ログオン・ウィンドウが常に表示されます。
ユーザーがログオンせずにこのウィンドウをキャンセルすると、前述のように、
db2logon コマンドが事前に発行されているかバッチ・ファイルから呼び出されなければ、
db2start コマンドは失敗します。
- システム・ブート時に DB2 を開始しなくても、アプリケーションによって DB2 を開始できます。
DB2 を使用するアプリケーションの初期設定の一部として、
db2start.bat ファイルを実行できます。
この方式を使用すると、DB2 を使用するアプリケーションが開始される時にだけ DB2 が開始されます。
ユーザーがアプリケーションを終了する際には、
db2stop コマンドを発行して DB2 を停止できます。
システム・ブート時に DB2 を開始しない場合は、
このような方法で業務に使用するアプリケーションにより DB2 を開始できます。
実行用にダウンロードされるスクリプトに、
ローカル・インスタンスかローカル・データベースに対して実行されるコマンドが含まれている場合に、
DB2 シンクロナイザー・アプリケーションを使用するかまたはご使用のアプリケーションから同期 API を呼び出すには、
DB2 を開始しなければなりません。
この種のコマンドは、データベース・スクリプト、インスタンス・スクリプト、
またはオペレーティング・システム (OS) スクリプトに組み込むことができます。
インスタンスまたはデータベースを使用するコマンド行プロセッサー・コマンドまたは DB2 API が OS スクリプトに含まれていなければ、
それは DB2 を開始しなくても実行できます。
同期化処理時にスクリプトから実行されるコマンドをあらかじめ知ることは難しいので、
通常は DB2 を開始してから同期を開始する必要があります。
ご使用のアプリケーションから db2sync コマンドまたは同期 API を呼び出す場合は、
そのアプリケーションの初期設定時に DB2 を開始します。
ユーザーが DB2 (Windows 版) フォルダー内の DB2 シンクロナイザーのショートカットを使用して同期を開始する場合は、
DB2 シンクロナイザーのショートカットに変更を加えて、
db2sync.bat ファイルを実行するようにしなければなりません。
バッチ・ファイルに以下のコマンドを組み込んで、
同期が始まる前に DB2 が確実に実行されるようにする必要があります。
@echo off
db2start.bat
db2sync.exe
db2stop.exe
cls
exit
この例では、前述のように、
db2start.bat ファイルにより db2logon コマンドと db2start コマンドが呼び出されると想定されています。
アプリケーションの開始時に DB2 を開始することにした場合は、DB2 のインストール時に、
「スタートアップ」フォルダーに DB2 を開始するショートカットは追加されないことを確認してください。
詳細については、3 の注を参照してください。
- 症状
- REXX または ODBC ドライバ・マネージャーなど、
動的に DB2 DLL をロードするアプリケーションを使用しようとすると、
エラー・メッセージ SQL1032N を受け取ります。
- 推定原因
- REGISTER コマンドによって設定された実行モードが無効です。
エラー・メッセージが戻された理由は、
アプリケーションを実行するのに必要な共用メモリーに、
そのアプリケーションが接続できなかったからです。
- 処置
- 実際には、以下の 2 つの問題があります。
- DB2 グローバル・カ−ネル オブジェクトにアクセスする際の、Windows 2000 Terminal Server の問題。
IBM DB2 Service and Support に連絡して、対処方法をご相談ください。
Microsoft 社によるフィックスがあります。
- Windows 2000 Terminal Server の Remote Administration を使用するローカル・アプリケーションがエラーになる時の問題。
Windows NT での作業の際には、REGISTER コマンドにより、
すべての必須のバイナリー・ファイルを GLOBAL 実行モードとしてマークしなければなりません。
REXX バイナリー・ファイルを SYSTEM GLOBAL として実行するよう登録する方法を以下に示します。
- REXX アプリケーションが実行されていないことを確認します。
- タスク・マネージャー・ウィンドウを開始して REXX プロセスをすべて除去します。
たとえば、rxapi.exe が実行中でないことを確認します。
- \winnt\system32 ディレクトリーに進みます。
- rxapi.exe、rexx.dll、
および rexxapi.dll の 3 つの REXX ファイルを SYSTEM GLOBAL として登録します。
たとえば、以下のようにします。
register /SYSTEM rxapi.exe
- 症状
- SQL1403N エラー・メッセージは、
DB2 を実行している Windows NT プライマリー・ドメイン上のユーザー名またはグループの許可を得ようとしたときに受け取ります。
- 推定原因
- Windows NT プライマリー・ドメインでの許可制限。
- 処置
- インスタンスのサービスを開始しているのが、
マスター・ドメイン上のユーザーではないローカル管理者であること、
そしてそのローカル管理者がローカル・マシンのオペレーティング・システム権限を持っていることを確認してください。
- 症状
- データベース・サーバーのインストールまたは管理に問題があります。
- 処置
- 以下のことを確認してください。
- [ ]
- 管理者権限を持つ有効なユーザー名およびパスワードを使用しているか。
- OS/2 Warp Connect およびそれ以降のバージョンの OS/2 の場合: デフォルト DB2 管理者ユーザー名およびパスワードは、
オペレーティング・システムのインストール時に指定したパスワードと同じです。
- OS/2 Warp Connect より前のバージョンの OS/2 の場合: デフォルト管理者ユーザー名とパスワードは、
マシン上にインストールされた各国語、
および UPM が特定のユーザー名を指定してインストールされたかどうかによって異なります。
ほとんどの場合、デフォルトは英語圏では USERID および PASSWORD です。
詳細については、ご使用のプラットフォームの概説およびインストール を参照してください。
- Windows NT の場合: グループ内でのユーザーのメンバーシップによって、
実行を許可されているアクションが制御されます。
DB2 (Windows NT 版) の場合、
インストールおよびいくつかの管理タスクを実行するには、
「管理者 (Administrators)」または「ドメイン管理者 (Domain Admins.)」グループに属していなければなりません。
ユーザー・マネージャー・ツールを使用して、
ユーザー名およびグループ・メンバーシップを表示することによって、
自分が属しているグループを判別することができます。
このツールを呼び出すには、
「スタート」を選択してから、
「プログラム」 -->
「管理ツール」 -->
「ユーザー マネージャ」の順で選択してください。
DB2 をインストールするには、
ローカル・マシンに対する管理者権限を持っていなければなりません。
管理者グループに加入するには、
そのグループの既存のメンバーによって追加されなければなりません。
- UNIX ベースの環境: SYSADM グループ環境に属していなければなりません。
グループ名の長さは、8 文字以下でなければなりません。
-
DB2 (Solaris 版) の場合: DB2 インスタンス所有者と同じグループに属していないユーザーによって DB2 インスタンスが開始されると、
ほとんどのコマンドに対して SQL1042C メッセージを受け取ります。
この状態では、実行している db2sysc プロセスは、
ユーザーのグループ名を継承しますが、
/proc ディレクトリーにあるファイルをオープンできる正式な読み取り許可はありません。
インスタンス所有者としてインスタンスを開始しなければなりません。
ファイルを読み取ろうとしている db2sysc プロセスの ID またはグループは、
DB2 インスタンスの ID またはグループと同じでなければなりません。
- [ ]
- AIX 以外の UNIX ベースの環境の場合、
カーネル構成パラメーターを自分で更新および再作成しなければならない。
(これを行わないと、インスタンスを作成またはコマンド行プロセッサーを使用しようとしたときに、
大抵 SQL1016N または SQL1018N メッセージが表示されます。)
詳細については、ご使用のプラットフォーム用の概説およびインストール を参照してください。
正しいバックアップおよび回復戦略、
およびこの戦略を実現するプランを持つことは重要です。
このプランでは、以下の質問が考慮されている必要があります。
- そのデータはどれほど重要か?
- データが利用できない場合、どのくらいの期間であればユーザーに影響を与えずに済むか?
- データベースの復元にどれほどの時間とリソースを費やせるか?
- データ読み取り専用か、または更新されているか?
- データは別のソースから容易に再作成できるか?
- システムをバックアップしたり回復するために、
どのくらいのリソースを割り当てられるか?
バックアップ・プランは、
データベース内のデータを使用可能にできることの重要度によって大きく影響されます。
業務内容がデータに大きく依存している場合には、
ダウン時間を最小化するバックアップおよび回復プランを作成し、
損失を許容できる程度で抑え、
データが使用可能になるようにしなければなりません。
バックアップおよび回復に関するヘルプについてはデータ移動ユーティリティー 手引きおよび解説書 を参照し、
コントロール・センターから DB2 バックアップ・データベース・ウィザードを使用してください。
- 症状
- SQL0902C メッセージは、データのバックアップ時に受け取ります。
- 推定原因
- データベースに体系的な整合性がありません。
- 処置
- db2dart コマンドを使用して、
データベースの体系的な整合性を検査します。
このコマンドについては、各種問題判別ツールを参照してください。
通常、ログの最後へロールフォワードして復元を実行し、
問題を訂正することができます。
問題が解決しない場合には、DB2 カスタマー・サポートと連絡をとってください。
- 症状
- エラー・メッセージ SQL4908N は ROLLFORWARD TABLESPACE の実行時に受け取ります。
- 推定原因
- 表スペースのロールフォワードを初めて試行している場合、
ロールフォワードするように指定した 1 つまたは複数の表スペースが、
指定したノードで ROLLFORWARD PENDING 状態になっていないときに、
このメッセージを受け取ることがあります。
すでに進行中の表スペースのロールフォワードを続けている場合、
ロールフォワードするように指定した 1 つまたは複数の表スペースが、
指定したノードで 「roll forward in progress」 状態になっていないときに、
このメッセージを受け取ることがあります。
- 処置
-
- 指定したノードで LIST TABLESPACES SHOW DETAIL コマンドを使用して、
ロールフォワードの用意ができていない表スペースを見つけます。
- ROLLFORWARD コマンドの QUERY STATUS オプションを使用して、
表スペースのロールフォワードの状況を判別します。
- タスクに応じて以下を行います。
- 表スペース・ロールフォワードを新しく開始する場合、
それらの表スペースを復元して、ROLLFORWARD PENDING 状態にします。
- 表スペースのロールフォワードを続けるときに、
関係する 1 つまたは複数の表スペースをすでに復元しており、それらが ROLLFORWARD PENDING 状態になっている場合は、
進行中の表スペースのロールフォワードを取り消さなければなりません。
- 表スペースを RESTORE PENDING 状態にします。
- 表スペースを復元します。
- 元の ROLLFORWARD コマンドをもう一度実行依頼します。
- 症状
- SQL2419N エラー・メッセージは、ディスクへのオンライン・バックアップ時に受け取ります。
- 推定原因
- ディスクには空きがありますが、
バックアップ・ファイルがオペレーティング・システムのファイル・サイズ制限を超えています。
- 処置
- 複数のターゲット・ディレクトリーを指定することにより、
バックアップを実行できます。
オペレーティング・システムのファイル・サイズ制限 (2 GB) を超えないようにファイルを分割して、
複数のバックアップ・ディレクトリーに入れます。
- 症状
- Tivoli Storage Manager (TSM) を使用したバックアップ時に、
DB2 クライアントからの NetBIOS 接続が切断されました。
- 推定原因
- TSM の初期化の過程で、
呼び出し側アプリケーションの NetBIOS リソースをリセットする NCB.RESET が出されました。
DB2 (OS/2 版) および DB2 (Windows NT 版) の場合、
呼び出し側アプリケーションとは DB2 そのもののことです。
そのため、NetBIOS を介して行われているデータベースへの接続がすべて除去されます。
- 処置
- NetBIOS を通信プロトコルとして使用している場合、
この障害は避けられません。
TSM を使用してデータベースへのバックアップを行う場合は、TCP/IP などの別のプロトコルを使用してください。
- 症状
- データを復元できません。
- 処置
- 以下のことを確認してください。
- [ ]
- データを復元するのに十分なディスク・スペースがある。
リダイレクトされた復元を使用して、
復元する表スペースのためのコンテナーのリストを修正し指定し直してください。
管理の手引き: インプリメンテーション を参照してください。
- [ ]
- バックアップ・イメージおよびログの正しいパスを指定する。
(それらが移動されてしまっているということもあり得ます。)
- [ ]
- オンライン・バックアップを取ってある場合、
データベースを復元およびロールフォワードするには、
バックアップの始めから終わりまでのすべてのログが必要である。
(ROLLFORWARD QUERY STATUS コマンドからの出力によって指定された最小限の時点まで、
ロールフォワードを継続しなければなりません。
そうでないと、データベースがアクセス不能になってしまいます。)
- 症状
- AIX では、API を使用したデータベースの復元時に、
戻りコード 22 が戻され、SQL0902C エラー・メッセージを受け取ります。
- 推定原因
- アプリケーションが異常終了すると、
メッセージ待ち行列は既存のデータベース・ファイルに接続されたままになります。
- 処置
- db2stop を使用してデータベースを停止します。
db2terminate を使用して、すべてのバックエンド・プロセスを除去します。
DB2 プロセス間通信 (IPC) リソースをクリーンアップします。
db2start を使用してデータベースを開始します。
そして、RESTORE を再試行します。
問題が解決しない場合は、DB2 サポートに連絡してください。
- 症状
- Windows NT マシンで RESTORE コマンドを出すときに、ロールフォワードが必要でないことを指定すると、
表スペースは ROLLFORWARD PENDING 状態のままになります。
- 推定原因
- ハード・ディスク・キャッシュが制限 (192 MB) に達している DB2 と Windows NT がリソースの競合を起こしています。
このハード・ディスク・キャッシュは、DB2 がたくさんのファイルをオープンまたはクローズしたり、
大きいファイルをオープンまたはクローズしたりするときには必ず使用されます。
- 処置
- DB2 製品が最新の修正パックに更新されており、
DB2NTNOCACHE レジストリー変数が 1 に設定されていることを確認します。
DB2NTNOCACHE の設定は、db2set -all コマンドを使用して検査することができます。
- 症状
- SQL1277N エラー・メッセージは、
新しいデータベースにリダイレクトされた復元を行っているときに受け取ります。
- 推定原因
- リダイレクトされた復元で使用する 1 つまたは複数のコンテナーがすでに使用されている可能性があります。
追加情報については、db2diag.log を調べてください。
- 処置
- 使用中のコンテナーを除去するか解放し、
コントロール・センターを使用してリダイレクトされた復元を実行してください。
SMS コンテナーを除去してください。
DMS コンテナーを解放してください。
(SMS も解放できます。)
コマンド行プロセッサーを使用する場合、
SET TABLESPACE CONTAINERS API を使用してから、
CONTINUE パラメーターを指定して RESTORE コマンドを再実行してください。
SET TABLESPACE CONTAINERS API の詳細については、
コマンド行で db2 ? set tablespace と入力してください。
- 症状
- SQL1024N エラー・メッセージは、リダイレクトされた復元を行っているときに受け取ります。
- 推定原因
- リダイレクトされた復元には以下の 3 つのステップがあります。
- 復元のリダイレクト
- 表スペース・コンテナーの設定
- 復元の続行
最初のステップの後で、データベースに対する暗黙接続が確立されます。
この接続はセッション ID と関連付けられます。
残りの 2 つのステップ用のシェル・スクリプトを使用する場合は、新しいセッションが開始されます。
データベースに対する暗黙接続がなくなるので、2 番目のステップが失敗します。
- 処置
- シェル・スクリプトを使用する際には、1 つのスクリプトで 3 つのステップとも実行することを確認してください。
- 症状
- SQL0298N エラー・メッセージは、
リダイレクトされた復元の実行時に表スペース・コンテナーを設定する際に受け取ります。
- 推定原因
- 顧客がリダイレクトされた復元を使用して SMS 表スペース中の DMS 表スペースを復元しようとすると、
SQL0298N エラー・メッセージを受け取ります。
- 処置
- これは有効な処置ではありません。
表スペースのタイプを変更することはできません。
- 症状
- Windows NT または Windows 2000 で BACKUP または RESTORE が失敗しました。
- 推定原因
- バックアップ・イメージ・ファイルが 128GB より大きいと、
NTFS ファイル・キャッシュにはスペースが足りなくなります。
- 処置
- BACKUP または RESTORE 時に使用する論理ドライブの数を少なくしてください。
- 症状
- LOAD 操作中に SQL3508N エラー・メッセージを受け取りました。
- 推定原因
-
- REMOTE FILE パラメーターを明示的に指定しないで LOAD コマンドを出してから LOAD RESTART 操作を試行したため、
ユーティリティーがデフォルトのリモート・ファイルを上書きしました。
- 指定したパスが異なっているとしても、
指定したファイル名が似ています。
たとえば、MESSAGES C:\table.MSG と REMOTE FILE D:\table などです。
- 処置
-
- データベースまたは表スペースを復元します。
- MESSAGES と REMOTE FILE パラメーターには、
それぞれ別のファイル名を指定します。
たとえば、MESSAGES C:\table.MSG と REMOTE FILE D:\table.RMT のようにします。
RMT という拡張子を使用すれば、問題は解決します。
- 症状
- データがデータベース・サーバーにロードされません。
- 処置
- 以下のことを確認してください。
- [ ]
- LOAD コマンドに RESTART または REPLACE パラメーターを使用した。
(そうでない場合、通常は SQL3805N メッセージを受け取ります。)
LOAD コマンドの詳細については、データ移動ユーティリティー 手引きおよび解説書 を参照してください。
- [ ]
-
SMS 表スペース内のデータベース・オブジェクトのサイズがオペレーティング・システムの制限に達していない。
たとえば、OS/2 および Windows NT では、2 GB までのファイル・サイズ制限があります。
(DB2 ユニバーサル・データベース エンタープライズ拡張エディションでのデータのロードの詳細については、
LOAD の問題、およびデータの分割とロードの問題を参照してください。)
- 症状
- データのインポートに問題があります。
- 処置
-
- [ ]
-
利用可能な十分なログ・スペースがあることを確認します。
(サーバー障害を参照。)
- [ ]
- COMMITCOUNT n オプションを使用して、
n 個のレコードがインポートされるたびにデータをコミットします。
このオプションは、
障害が生じた場合にコミット済みデータが失われないよう保護します。
また、長いトランザクションを 1 つ実行するのではなく、
小さいトランザクションを多く実行することができるようにして、
インポート操作のためのログ要件を削減します。
- 症状
- Windows 2000 使用時のロー・デバイス参照が稼働していないように見えます。
- 推定原因
- Windows 2000 の新しい Dynamic Disk モードでは、
区画が多過ぎる場合にロー・デバイスを使用すると障害が起こります。
Windows 2000 の Logical Disk Manager は、
Windows 2000 とは違う方式でロー・デバイスの定義を処理します。
- 処置
- Basic Disk モードに関連した方式を使用して、
1 つの区画で使用されている長いタイプの区画名を使用してロー・デバイスを定義してください。
- 症状
- ディスクへの入出力に関係するさまざまな DB2 タスクとユーティリティーのパフォーマンス上の問題。
- 推定原因
- Windows 2000 では、SectorsPerTrack と TracksPerCylinder のデフォルト値が変更されました。
たとえば、SectorsPerTrack は 32 から 63 に増えました。
この問題は、多数のディスクがあり、RAID 制御プログラムがトラック配置の転送の最適化を行うと起こります。
- 処置
- この問題を訂正する方法は複数あります。
最も簡単な方法は以下のとおりです。
- 専用の classpnp.sys ドライバーを使用して、Windows NT の動作に復帰する。
- この専用ドライバーを使用して、Windows 2000 の下にディスクと区画を作成する。
- 専用ドライバーを Windows 2000 に付属のドライバーに置き換え、マシンをリブートする。
注: | Windows NT を使用して区画を作成してから Windows 2000 にアップグレードする (または Windows 2000 との二重ブートを使用する) と、
ディスク配置の問題は起きません。
|
- 症状
- コマンド、ユーティリティー、またはコマンド行プロセッサーを使用できません。
- 処置
- 以下のことを確認してください。
- [ ]
- 修正パックまたはより新しい実行可能モジュールをインストールした後で、
ユーティリティーとアプリケーションをデータベースにバインドした。
(SQL0818N または SQL0805N メッセージは、再バインドする必要があることを示しています。)
SQL アプリケーションをプリコンパイルする場合、
コンパイル可能ファイル (任意指定でバインド・ファイル) が作成されます。
これら 2 つのファイルのタイム・スタンプは、新しくなります。
プリコンパイル操作のデフォルト動作はパッケージの自動作成になっているので、
何もバインドする必要がありません。
ただし、バインド・ファイルを作成してもパッケージを作成しない場合は、
データベースに新しいバインド・ファイルをバインドしなければなりません。
バインドについては、概説およびインストール を参照してください。
- [ ]
-
正しい構文を使用した (特に UNIX ベースのシステムで)。
以下のいずれかを行うことをお勧めします。
- コマンド行プロセッサー要求は、必ず二重引用符 (" ") で囲むようにする。
- アスタリスク (*)、大括弧、
または疑問符 (?) などの特殊文字の前には円記号 (\) 文字を置き、
コマンド行プロセッサーがそれらを正しく解釈するようにする。
例
次のステートメントの場合、
db2 SELECT * FROM SYSCAT.TABLES
次のどちらかを使用します。
db2 "SELECT * FROM SYSCAT.TABLES"
または
db2 SELECT \* FROM SYSCAT.TABLES
データベース管理プログラムには並行性制御の機能が備わっており、
ロックによって無制限にアクセスされないようにします。
DB2 ロックには基本原則があり、
ロックを制御するための処置をとる必要はほとんどありません。
どのようにロックが作用するかについては、管理の手引き を参照してください。
以下の方式を使用して、アプリケーションがデッドロックを作成しているか、
またはロックを保留しているかどうかを調べてください。
- デッドロック は、
同じデータベースに接続した 2 つまたはそれ以上のアプリケーションがいつまでもリソースを待機しているときに生じます。
他方のアプリケーションが処理の継続を必要とするリソースをお互いに保留にしているために、
待ち状態は決して解決されません。
データベース上のデッドロックに対してイベント・モニターを使用して、
デッドロックが発生してからの各デッドロックのログを保持してください。
デッドロックが避けられない場合も時折生じます。
ご使用のアプリケーションで SQLCODE -911 を処理して、
この状況に対する計画を立てる必要があります。
こうすると、デッドロックを検出して何らかの対策を計画できますが、
デッドロックを避けることはできません。
- アプリケーションがロックを待機しているかどうかを判別するには、
スナップショット・モニターを使用して、lock_wait_time の値が高いかどうか調べてください。
値が高い場合、
あるアプリケーションが保持しているロックを、
別のアプリケーションが待機していることを示す場合があります。
これは、アプリケーションがトランザクションを適宜コミットしていない可能性があることを示しています。
どのロックが待ち状態の原因となっているか、
およびどのアプリケーションがロックを保留にしているかを調べるには、LOCK モニター・スイッチを ON にしてからアプリケーション・スナップショットを取得してください。
詳細については、
データベース・システム・モニターおよびシステム・モニター 手引きおよび解説書 を参照してください。
- 症状
- SQL0911N メッセージを受け取ります。
- 推定原因
- デッドロックおよびタイムアウトがあります。
- 処置
- SQLCA の理由コードを確認し、
デッドロックまたはタイムアウトが問題の原因となっているかどうかを判別します (SQLCA 構造の解釈を参照)。
デッドロックの場合、
ご使用のアプリケーションが -911 戻りコードを処理できるようにコード化されているか確認してください。
ロック・リストのサイズを増やしてロック調整を回避してください。
このロック調整が原因となってデッドロックが生じることもよくあります。
デッドロック・イベント・モニターを使用しても、
タイムアウトは取り込めないので注意してください。
- 症状
- DB2 データベースにアクセスしているアプリケーションの処理が遅いか、またはハングしています。
- 推定原因
- ロック競合またはロック調整があります。
- 処置
- コントロール・センターまたは LIST APPLICATIONS FOR DATABASE database-alias SHOW DETAIL コマンドを使用して、アプリケーションがロックを待っているか、
およびアプリケーションが待っているロックを保持しているのが何かを検出します。
次に、データベース・モニターを使用して、ロック調整が起こっているかどうかを判別します。
自動調整が起こっている場合には、以下のことを確認してください。
- [ ]
- アプリケーションのコミット頻度が適切である。
ロックのためのモニター・スナップショットを取得し、
どのアプリケーションが他のアプリケーションにロックを待機させているかを判別します。
また、db2.lock_waits パフォーマンス変数をモニターします。
- [ ]
- データベース構成パラメーター maxlocks および locklist (許可されているロックの数を決めるパラメーター) の値が適切である。
- [ ]
- locktimeout データベース構成パラメーターが適切に設定されている。
このパラメーターがオンに設定されている場合、ロック競合による停止を避けるのに役立ち、
ロック競合が問題の原因であるかどうかが分かります。
- [ ]
- dlchktime データベース構成パラメーターが適切に設定されている。
このパラメーターは、
データベース管理プログラムがデータベースに接続されたすべてのアプリケーションの間でデッドロックを検査する頻度を定義します。
頻度が高い値に設定される場合、CPU 時間は節約されますが、
デッドロックが迅速には検出されないことがあります。
- [ ]
- 他のユーザーが、アプリケーションを作成およびバインドしていない。
アプリケーションの作成およびバインドのプロシージャーでは、
システム・カタログ表に対してロックが獲得されていることが必要です。
このプロシージャーは、オフピーク時に行ってください。
- [ ]
- ロック待機またはデッドロックの原因が、次のキーロックにはない。
次のキーロック は、
すべての INSERT および DELETE ステートメントでの次のキー、
および SELECT ステートメントの結果セットより上にあり 2 番目に高いキー値を自動的にロックすることによって、
カーソル固定 (CS) 分離レベルを保証します。
これは ANSI および SQL 92 標準 CS を保証するために必要であり、DB2 のデフォルトです。
アプリケーションのスナップショット情報を調べてください。
次のキーロックに問題がありそうな場合、DB2_RR_TO_RS オプションをオンに設定することによって、
分離レベルを「読み取り固定 (RS)」に変更することができます。
DB2_RR_TO_RS オプションはユーザー表上のすべての 次のキーロックを停止します (カタログ表には影響しません)。
DB2 が CS を保証できなくなったため、CS にバインドされているパッケージは自動的に RS に格下げされます。
ANSI および SQL92 標準 CS が必要な場合には、このオプションを使用しないでください。
ロック、構成パラメーター、および Explain 情報については、管理の手引き: パフォーマンス を参照してください。
データベース・パフォーマンスは複雑なテーマであるため、
本書では詳しく取り上げることはしません。
まず始めに、以下のことに留意してください。
[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]