セルフマネージド Db2 on Linux データベースを Amazon RDS for Db2 にリストアする

ソリューション概要

Db2 移行前提条件検証ツールは、移行準備状況を確認するため、さまざまな検証カテゴリにわたって包括的な移行前評価を実施します。不整合が検出された場合、ツールは修正のための具体的かつ実行可能な推奨事項を提示します。これらの詳細な情報により、データベース管理者や移行チームが潜在的な問題に体系的に対処できます。特定された問題は、Amazon RDS for Db2 へのリストアに使用される最終的なオンプレミス Db2 バックアップを作成する前に解決する必要があります。

このプロアクティブなアプローチにより、障害を減らし、Amazon RDS for Db2 へのスムーズな移行を実現します。セルフマネージド Db2 データベースを Linux から Amazon RDS for Db2 へ移行するステップバイステップのガイダンスについては、Amazon RDS for Db2 の Linux から Linux への移行 を参照してください。

以下の図は、オンプレミスのセルフマネージド Db2 データベース（Linux）から Amazon RDS for Db2 への正常なリストアを実現するための一般的なプロセスフローを示しています。

ツールの主な機能は以下のとおりです：

• クロスプラットフォームサポート：
  • Linux on x86、Linux on POWER に対応
  • 古い bash バージョン (訳注: bash 3.1 以降) との互換性あり
  • 標準 Unix ツール以外の外部依存関係なし
  • Linux 以外のプラットフォームやその他の移行オプションには Db2 Migration Tooling（Db2MT）の使用を検討
  • 移行の詳細については Migrate from self-managed Db2 to Amazon RDS for Db2 using AWS DMS および Amazon RDS for Db2 へのデータマイグレーション戦略 を参照
• 複数の操作モード：
  • インタラクティブモード – ユーザープロンプトによるガイド付き操作
  • 非インタラクティブモード – スクリプト向け自動実行
  • リモートモード – リモート Db2 データベースへの接続と検証
• 包括的なレポート：
  • カラーコード付きコンソール出力
  • タイムスタンプ付き詳細ログファイル
  • 各チェックの PASS/FAIL/WARNING ステータス
  • 失敗時の実行可能な推奨事項
• インベントリ分析：
  • 完全なデータベースオブジェクトインベントリ
  • 移行準備状況の健全性チェック
  • タイプ別オブジェクト数サマリー

ツールは以下のシナリオで使用できます：

• 移行前計画 – 潜在的な問題を早期に特定し、修正のための時間を確保するため
• 移行準備状況評価 – Amazon RDS for Db2 への移行プロセス開始前の最終検証のため
• Fix Pack(s) 適用後 – Db2 Fix Pack 適用後にデータベースを検証し、適切な更新完了を確認するため
• 最終 Db2 バックアップ前 – Amazon RDS for Db2 へのリストア前に準備完了を確認する（クリーンな出力はリストアの失敗を防ぐセーフガードとなる）ため。データベースバックアップコマンドの使用に関する一般的なガイダンスは後述します。

ツールの使い方

前提条件

開始前に、以下の前提条件と制限事項を確認してください：

ローカルモード

• Db2 インスタンスが起動・アクセス可能であること
• SYSADM 権限を持つ Db2 サーバー上でツールを実行すること
• Db2 環境が適切に source されていること（. ~/sqllib/db2profile）
• Db2 インスタンスユーザー（例：db2inst1）として実行すること

リモートモード

• Db2 クライアントがインストール・設定済みであること
• リモート Db2 サーバーへのネットワーク接続があること
• DBADM または SYSMAINT 権限を持つ有効な Db2 ユーザー認証情報があること
• データベースがカタログ済み、または db2dsdriver.cfg ファイルに DSN エントリが存在すること

インタラクティブフローでは、ツールは以下の手順を実行します：

1. Db2 バージョン情報を表示する
2. 利用可能なインスタンスを一覧表示する
3. 検証対象の現在のインスタンスを特定する
4. 現在のインスタンス内のローカルデータベースを検出する
5. Db2 サーバー上でスクリプトを実行できない場合はリモートデータベースを検証する
6. 検証対象データベースを選択する
7. 包括的な検証チェックを実行する
8. 詳細レポートを生成する

以下のコマンドはインタラクティブ実行のコードです。

ツールの直接実行

curl -sL https://bit.ly/precheckdb2migration |  bash

ダウンロードして実行

curl -sL https://bit.ly/precheckdb2migration -o db2_migration_prereq_check.sh
chmod +x db2_migration_prereq_check.sh
./db2_migration_prereq_check.sh

リモートモード – 直接実行

export DB2USER=myuser
export DB2PASSWORD=mypassword
export DBNAME=mydatabase
curl -sL https://bit.ly/precheckdb2migration |  bash -s -- --verbose

リモートモード – ダウンロードして実行

curl -sL https://bit.ly/precheckdb2migration -o  db2_migration_prereq_check.sh
chmod +x db2_migration_prereq_check.sh
export DB2USER=myuser
export DB2PASSWORD=mypassword
export DBNAME=mydatabase
# リモートデータベースに対して検証を実行
./db2_migration_prereq_check.sh --verbose

注意：リモート接続に使用する DBNAME 環境変数は、ローカルにカタログされたリモートデータベース名、または db2dsdriver.cfg ファイルで使用される DSN エントリ名である必要があります。

以下のコマンドは、Db2 サーバー上でローカル実行する非インタラクティブモードのコードです。

特定インスタンスの検証

DB2_INSTANCES=db2inst1 \
    ./db2_migration_prereq_check.sh

カスタムレポート出力先を指定

DB2_INSTANCES=db2inst1 \
REPORT_FILE_PATH=/opt/reports/db2_check.log \
./db2_migration_prereq_check.sh

注意：「db2_inventory」プレフィックスのレポートは、スクリプトを起動したディレクトリに生成されます。

デバッグ用の詳細出力

DB2_INSTANCES=db2inst1 \
./db2_migration_prereq_check.sh --verbose

複数インスタンスの実行では、各インスタンスで個別にツールを実行できます。以下のサンプルコードを参照してください：

#!/bin/bash
# 複数インスタンスの検証
INSTANCES=("db2inst1" "db2inst2" "db2inst3")
REPORT_DIR="/var/log/db2_migration_checks"
mkdir -p "$REPORT_DIR"

for instance in "${INSTANCES[@]}"; do
    echo "Validating instance: $instance"
    su - "$instance" -c "
        . ~/sqllib/db2profile
        export REPORT_FILE_PATH='$REPORT_DIR/${instance}_migration_check.log'
        /path/to/db2_migration_prereq_check.sh
    "
done

ツール出力の理解

ツールをローカルで実行するか Db2 クライアント経由で実行するかによって、動作が若干異なります。

ローカル実行

以下のコマンドを実行すると、スクリプト db2_migration_prereq_check.sh がダウンロードされ即座に実行されます。

curl -sL https://bit.ly/precheckdb2migration | bash -s -- --verbose

Db2 インスタンス上でローカル実行した場合、すべてのローカルデータベースを特定し、それらに対して検証を実施します。

出力には Db2 バージョン、検出されたローカルデータベース数、検証結果、データベースサイズ、インベントリ分析が表示されます。

リモート実行

リモート実行の場合、スクリプト実行前に DB2USER、DB2PASSWORD、DBNAME の3つの環境変数をエクスポートする必要があります。検証は一度に1つのデータベースに対してのみ実施されます。

検証チェックの内容

以下の表はさまざまなカテゴリのチェック内容を示しています。ツールはデータベースインベントリ分析も実施し、結果を db2_inventory_yyyymmdd_hhmmss.json としてローカルに保存します。

レポートの読み方と対応

以下の表は生成されるレポートをまとめたものです。

DATABASE READINESS ステータスを確認するには DATABASE SUMMARY セクションに移動してください：

==========================================
DATABASE SUMMARY: DB2DB
==========================================
Checks performed: 15
Passed: 15
Warnings: 0
Failed: 0
Informational: 48
==========================================
DATABASE READINESS: READY
Database DB2DB passed all checks
==========================================

移行準備レベルは以下のとおりです：

• READY FOR MIGRATION（移行準備完了）：
  • すべてのチェックが合格（PASS ステータス）
  • 重大な問題なし
  • データベースのバックアップおよび Amazon RDS for Db2 へのリストア準備完了
• REVIEW REQUIRED（要確認）：
  • 一部の警告あり
  • 推奨事項の手動確認が必要
  • 考慮事項はあるが移行は可能
• NOT READY FOR MIGRATION（移行不可）：
  • 重大な失敗あり
  • 移行前に失敗したチェックへの対処が必須
  • 移行を進めるべきではない

ベストプラクティス

以下のベストプラクティスを考慮してください：

• 早期かつ頻繁に実行する：
  • 移行計画フェーズ中に実行する
  • データベース変更後に再実行する
  • バックアップ作成直前に検証する
• 問題に体系的に対処する：
  • まず FAIL 項目を修正する（ブロッキング問題）
  • WARNING 項目を潜在的リスクとして確認する
  • INFO 項目を参考情報として文書化する
• 複数データベースの自動化：
  • 自動化には非インタラクティブモードを使用する
  • マルチインスタンス環境向けスクリプトを作成する
  • 定期的な検証実行をスケジュールする
• ドキュメントの維持：
  • 監査証跡として検証レポートを保管する
  • 実施した修正アクションを文書化する
  • 検証履歴を時系列で追跡する

高度な使用シナリオ

以下のコードは継続的インテグレーションのシナリオを示しています：

#!/bin/bash
# CI/CD パイプライン統合
DB_VALIDATION_EXIT_CODE=0

for instance in $(db2ilist); do
    su - "$instance" -c "
        . ~/sqllib/db2profile
        /path/to/db2_migration_prereq_check.sh
    " || DB_VALIDATION_EXIT_CODE=1
done

if [ $DB_VALIDATION_EXIT_CODE -ne 0 ]; then
    echo "db2 validation failed - blocking deployment"
    exit 1
fi

以下のコードは定期監視のシナリオを示しています：

#!/bin/bash
# 定期検証用 Cron ジョブ
# 0 2 * * 1 /path/to/weekly_db2_validation.sh

REPORT_DIR="/var/log/db2_weekly_checks"
mkdir -p "$REPORT_DIR"
DATE=$(date +%Y%m%d)

for instance in $(db2ilist); do
    su - "$instance" -c "
        . ~/sqllib/db2profile
        export REPORT_FILE_PATH='$REPORT_DIR/${instance}_${DATE}.log'
        /path/to/db2_migration_prereq_check.sh
    "
done

# サマリーメールを送信
mail -s "Weekly db2 Validation Report" admin@company.com < "$REPORT_DIR/summary_${DATE}.txt"

よくある問題のトラブルシューティング

以下の表はよくある問題とトラブルシューティングのヒントを示しています。

# db2 環境をソースする
. ~/sqllib/db2profile

# Db2 インストールを確認
which db2
echo $DB2INSTANCE

# インスタンスが起動しているか確認
db2ilist

# ユーザー権限を確認
whoami
id

# データベースディレクトリを確認して手動接続を試みる
db2 list db directory
db2 connect to <dbname>

# データベースをアクティベート
db2 activate db <dbname>
db2 list active databases

# Db2 インスタンスユーザーとして実行していることを確認
su - db2inst1
# 権限を確認
db2 "SELECT * FROM 
TABLE(SYSPROC.AUTH_LIST_AUTHORITIES_FOR_AUTHID('DB2INST1'))"

データベースバックアップコマンドの一般的なガイダンス

データベースバックアップコマンドを使用する際は、以下のベストプラクティスを考慮してください：

• Amazon RDS for Db2 は Amazon Simple Storage Service（Amazon S3）のストリーミング機能を使用して並列ストリームでデータベースをリストアします。S3 ストリーミングはマルチパートファイルのバックアップイメージで最も効果的です。例えば、db2 backup database <dbname> to /backup コマンドは単一イメージを生成しますが、パフォーマンス面で最適ではありません。代わりに db2 backup database to /backup, /backup, /backup, /backup, /backup のように複数のロケーションを指定してください。この例では、バックアップ操作が並列実行され、データベースイメージが .001、.002、.003、.004、.005 の5つのパートに分割されます。
• 小規模データベースでもマルチパートバックアップの使用を検討してください。Linux マシンの CPU とメモリ能力に基づいてロケーション数を決定します。不明な場合は20ロケーションの使用を推奨します。
• セルフマネージド Db2 から AWS リージョンのネットワークへの接続がある場合、Amazon S3 への直接バックアップを検討してください。データベースのマルチパートイメージを Amazon S3 にコピーするには、必要な権限を持つバケットをアカウントに作成し、そのバケットを使用して db2 ストレージアクセスエイリアス を作成します。
  ストレージエイリアス作成時の考慮事項：

• Db2 on EC2 を使用する場合、Amazon S3 バケットへのアクセスに適切な IAM ロールを付与し、ストレージエイリアス作成コマンドに USER、PASSWORD、TOKEN を指定しないでください。
  コマンド例

  db2 "CATALOG STORAGE ACCESS ALIAS <aliasName> VENDOR S3 SERVER https://s3.<region>.amazonaws.com" CONTAINER <container-name> DBUSER <masterUserName>

• セルフマネージド Db2 を使用する場合、AWS CLI 認証情報を取得してストレージエイリアスを作成できます。
• 長期認証情報を使用する場合：

  db2 "CATALOG STORAGE ACCESS ALIAS <aliasName> VENDOR S3 SERVER s3.<region>.amazonaws.com USER $AWS_ACCESS_KEY_ID PASSWORD $AWS_SECRET_ACCESS_KEY CONTAINER <container-name> DBUSER <masterUserName>"

• 短期認証情報を使用する場合：

  db2 "CATALOG STORAGE ACCESS ALIAS <aliasName> VENDOR S3 SERVER s3.<region>.amazonaws.com USER $AWS_ACCESS_KEY_ID PASSWORD $AWS_SECRET_ACCESS_KEY CONTAINER <container-name> DBUSER <masterUserName> TOKEN $AWS_SESSION_TOKEN"

• バックアップコマンドでストレージエイリアスを使用して、データベースバックアップイメージを Amazon S3 に直接書き込みます。例えば、作成したストレージエイリアスが db2S3 の場合、以下のコマンドを使用します：

  db2 backup database <dbname> to DB2REMOTE://db2S3, DB2REMOTE://db2S3, DB2REMOTE://db2S3, DB2REMOTE://db2S3, DB2REMOTE://db2S3

  このコマンドにより、データベースのマルチパートイメージが S3 バケット内で5つのパートに分割されます。

データベースリストアコマンドの一般的なガイダンス

データベースリストアコマンドを使用する際は、以下のベストプラクティスを考慮してください：

• データベースバックアップのマルチパートコピーが保存された S3 バケットへのアクセスに適切な AWS Identity and Access Management（IAM）ロールを持つ RDS for Db2 インスタンスの Amazon S3 統合 を有効にしていることを確認してください。
• ストアドプロシージャ rdsadmin.set_configuration を使用して RESTORE_DATABASE_NUM_BUFFERS、RESTORE_DATABASE_PARALLELISM、RESTORE_DATABASE_NUM_MULTI_PATHS などのパフォーマンスパラメータを設定してください。
• パラメータ USE_STREAMING_RESTORE を TRUE に設定して、Amazon S3 から Amazon RDS for Db2 への直接 S3 ストリーミングを有効にしてください。
• Amazon RDS for Db2 は rdsadmin.restore_database ストアドプロシージャを使用してマルチパートバックアップイメージをリストアするための Db2 ストレージエイリアスを自動的に作成します。
• rdsadmin.restore_database ストアドプロシージャで使用する s3_prefix 変数に注意してください。このプレフィックスは .001、.002 などの拡張子を除いたマルチパートバックアップイメージの共通部分です。
• オンラインバックアップイメージを使用する場合、Db2 アーカイブログファイルを Amazon S3 にコピーし続け、rdsadmin.rollforward_database ストアドプロシージャを実行してアーカイブログを適用する必要があります。すべてのログファイルを適用するまでこのプロセスを繰り返してください。各操作には異なるプレフィックスを使用してください。
• すべてのログファイルを適用後、rdsadmin.complete_rollforward ストアドプロシージャを実行して RDS for Db2 データベースを接続可能な状態にしてください。
• 手動手順の代わりにオンラインリストアの自動化には Db2MT ツール の使用を検討してください。

ツールの機能拡張

このツールのソースコードは以下の GitHub リポジトリ で公開されています。機能拡張のリクエストは Issue を登録 するか、変更提案は Pull Request として送信してください。

追加リソース

Amazon RDS for Db2 と移行戦略の詳細については、以下のリソースを参照してください：

• Amazon RDS for Db2 ユーザーガイド
• Amazon RDS for Db2 へのデータマイグレーション戦略
• AIX、Windows 上のセルフマネージド型 Db2 から Amazon RDS for Db2 へ IBM Q レプリケーションを使用してほぼゼロのダウンタイムで移行
• セルフマネージド Db2 から Amazon RDS for Db2 へのフルロードおよび継続的レプリケーションタスクのパフォーマンス最適化
• IBM Db2 for z/OS から Amazon RDS for Db2 へのテーブル移行

まとめ

Db2 移行前提条件検証ツールは、一般的な問題を移行スケジュールに影響を与える前に特定・対処することで、移行失敗を大幅に削減します。このツールを移行ワークフローに組み込むことで、以下を実現できます：

• 移行リスクの低減 – プロセスの早期に問題を特定
• 時間の節約 – リストア失敗やトラブルシューティングを回避
• 成功率の向上 – データベースが適切に準備されていることを確認
• ドキュメントの維持 – 詳細な検証記録を保持

Db2 のメンテナンスおよび移行プロセスの一部としてこのツールを定期的に使用することで、Amazon RDS for Db2 へのスムーズで成功した移行を実現できます。

このアプローチをご自身の環境で試しましたか？どのように機能したか、またはツールへの機能拡張要望があればぜひお知らせください。

著者について