Db2 サーバーのアップグレード前タスク

Db2 サーバーをアップグレードする前に、Db2 サーバーのアップグレードに関する重要事項 (推奨事項、制約事項、ディスク・スペース要件など) を確認して、アップグレードに影響を与える可能性のある変更点や制約事項を識別してください。 正常にアップグレードするには、あらゆる問題に対応するための準備をアップグレード前にしておく必要があります。

プロシージャー

Db2 サーバーのアップグレードの準備をするには、以下のタスクを行います。

  1. 索引スペースのフリー・ページがオブジェクト索引につき少なくとも必ず 1 つあるようにして、潜在的な索引の再作成のオーバーヘッドを除去します。
    アップグレード時に索引ルート・ページに十分なフリー・スペースがない場合は、索引は 1 ページずつ増大する必要があります。 フリー・ページが索引オブジェクトに見つからない場合は、表スペースに対してページの要求が行われます。 表スペースがいっぱいである場合は、索引オブジェクト全体が無効としてマークされ、アップグレード後に基礎表が初めてアクセスされたときに再作成されます。
  2. Db2 データベースを含む分散トランザクションを使用する場合は、 LIST INDOUBT TRANSACTIONS コマンドを使用して未確定トランザクションのリストを取得し、未確定トランザクションを対話式に解決することにより、アップグレードするデータベースに未確定トランザクションが含まれていないことを確認してください。
  3. サーバー時間がリセットも変更もされていないこと、および複数パーティション・データベース環境のメンバーと関連付けられている時間が同期していることを確認してください。 サーバー時間が確認されていない場合、アップグレードが SQL0440N エラー・メッセージを返す可能性があります。
  4. データベースが Db2 アップグレードの準備ができていることを確認して、実際のアップグレードの前に問題を識別します。 アップグレードを始める前に、そのような問題を解決しておく必要があります。

    データベースのアップグレードの準備ができていることの確認を参照してください。

  5. Db2 Query Patroller からワークロード・マネージャーへのアップグレード。
    Query Patroller は廃止されました。 アップグレードのための Query Patroller から Db2 ワークロード・マネージャーへのマイグレーション のステップを実行してください。
  6. アップグレードのリカバリー計画に基づいて、アップグレード後の新しいシステムにデータベースをアップグレードしたり、アップグレード前の元のシステムにデータベースをリストアしたりするために、既存のバックアップ・イメージを検証するか、データベースの新しいバックアップを作成します。

    アップグレード前またはアップグレード後のデータベースのバックアップを参照してください。

  7. 現在の構成を記録してアップグレード後の構成と比較できるように、構成および診断情報のバックアップを取ります。 さらに、この情報を使って、アップグレード前と同じ構成の新しいインスタンスやデータベースを作成することも可能です。

    Db2 サーバー構成および診断情報のバックアップを参照してください。

  8. スタンバイ再初期設定を必要としないアップグレードをサポートする HADR 環境の場合 (単一パーティション ESE Db2 バージョン 10.5 フィックスパック 7 以降のデータベース、または Db2 pureScale V10.5 フィックスパック 9 以降のデータベース) 高可用性災害時リカバリー・モニターの使用、 1 次側のログ・シッピング機能とスタンバイ側のログ・リプレイ機能の両方が正しく動作していることを確認します。 スタンバイの再初期化を必要とせずに新しい HADR アップグレード手順を使用するために、 db2ckupgrade コマンドと UPGRADE DATABASE コマンドは、1 次のログ配送位置がスタンバイのログ適用位置と等しいことを検証します。 検証できない場合や等しくない場合は、アップグレード前に HADR を停止して、アップグレード後に再初期化する必要があります。
  9. すべての Db2 ログ・ファイルをアーカイブします。キャプチャー・プログラムまたは Q キャプチャー・プログラムでログ・ファイルが必要な場合は SQL レプリケーションまたは Q レプリケーション用、データベース・アップグレードによるリカバリー用、またはスタンバイ・データベースを作成するためにログ・ファイルが必要な場合は高可用性災害時リカバリー (HADR) レプリケーション用です。
  10. ディスク・スペース要件を調べて、アップグレード用のディスク・フリー・スペース、SYSTEM TEMPORARY 表スペース、 およびログ・スペースが十分であるかどうか確認し、必要に応じて表スペースとログ・ファイル・サイズを拡大します。
    データベース・オブジェクトの数によっては、アップグレードを実行するためにさらに多くのログ・スペースが必要かもしれません。

    Db2 サーバーのアップグレードのためのディスク・スペース要件 および アップグレード前の表スペースとログ・ファイルのサイズの増加を参照してください。

  11. オプション: リカバリー可能データベースの場合、アップグレードのリカバリー計画にアップグレードによる可能なロールフォワードが含まれている場合は、 logindexbuild データベース構成パラメーターをオンにすることを検討してください。 データベースのアップグレードでは、通常、カタログ表の索引が再作成されます。 この操作はログに記録されません。 つまり、アップグレード後に障害が発生し、データベースのアップグレードにおけるリカバリーが必要になった場合は、その時点より後のロールフォワードでそれらの索引に不良のマークが付けられ、ロールフォワード完了後に初めてアクセスされたときに、索引の再作成に時間がかかってしまうことになります。 これが問題になる環境では、logindexbuild をオンにしてアップグレード中の索引再作成をログに記録することを検討してください。 これには、追加のログ・スペースが必要になるというトレードオフがあります。 スタンバイ・データベースの読み取りが有効になっている HADR スタンバイ・データベースの場合、スタンバイ・データベースのアップグレードが完了した後に読み取り専用接続を許可するために、1 次データベースの logindexbuild をオンにすることを強くお勧めします。
  12. Windows のみ: カスタマイズしたコード・ページ変換表を Db2 サポート・サービスから取得した場合は、 DB2OLD\conv ディレクトリー内のすべてのファイルをバックアップする必要があります。ここで、 DB2OLD は既存のDb2 バージョン 11.1 コピーの場所です。

    標準のコード・ページ変換表をバックアップする必要はありません。 Db2 バージョン 11.1 より前のコピーをアップグレードすると、これらの表が削除されます。これは、標準コード・ページ表が Db2 バージョン 11.1 ライブラリーに含まれているためです。

  13. Linux® のみ: ロー・デバイスをブロック・デバイスに変更します。

    ブロック・デバイスへのロー・デバイスの変更 (Linux)を参照してください。

  14. アップグレードの実行中に生じる可能性がある問題をトラブルシューティングするための情報を収集します。

    アップグレード前の診断情報の収集を参照してください。

  15. オプション: テスト環境で Db2 サーバーをアップグレードして、アップグレードの問題を識別し、 Db2 サーバーをアップグレードする前に、アプリケーション、スクリプト、ツール、およびルーチンが期待どおりに機能することを検証します。 実稼働環境。

    テスト環境での Db2 サーバーのアップグレードを参照してください。

  16. GET DBM CFG コマンドを使用して、「診断エラー・キャプチャー・レベル」を確認します。 診断エラー・キャプチャー・レベル ( diaglevel パラメーターで設定) が 2 以下の場合、 アップグレード前に診断エラー・キャプチャー・レベルを 3 以上に設定します。
  17. 次のいずれかのアクションを実行します。
  18. アップグレードのために Db2 サーバーをオフラインにします。

    アップグレードまたは Db2 pureScale 環境への変換のための Db2 サーバーのオフライン化を参照してください。

  19. 既存のマテリアライズ照会表のデータをリフレッシュします。
    システム・ビューに依存するすべてのマテリアライズ照会表は、データベースのアップグレード中にドロップされます。 アップグレード後に、REFRESH TABLE ステートメントを使用して、既存のマテリアライズ照会表のデータをリフレッシュする必要があります。