Amazon Relational Database Service（以下、RDS）や Amazon Aurora（以下、Aurora）のリザーブドインスタンス（RI）は、オンデマンド料金と比較して大幅なコスト削減が可能です。しかし、RDS の RI には Amazon EC2 の RI とは異なり開始日時を指定した予約購入の機能がなく、購入 API を実行した時点で即座に課金が開始されます。そのため、大量の RI を短時間で正確に購入するには手動オペレーションでは負荷が高く、お客様にとって購入のハードルが高い状況となっています。 なお、第 7 世代以降のインスタンスで利用可能になった Database Savings Plans では予約購入が可能ですが、旧世代のインスタンスを利用されている場合は引き続き RI での購入が必要です。 本記事では、公共機関における RI 購入の制約を例に、RDS / Aurora の RI を効率的に一括購入するサンプルスクリプトをご紹介します。公共機関以外のお客様でも、大量の RI を正確に購入したいケースで参考にしていただけます。 背景 公共機関ではデータ保管場所や予算執行の都合により購入方法が限定されることが一般的です。例えば、次のような制約があります。 日本リージョン（東京・大阪）のみ 前払いなし（No Upfront）のみ利用可能 購入タイミングは 4/1 09:00:00〜09:59:59（JST） ※会計年度を1時間でもまたがないようにする場合 この制約のもとでは、限られた時間内に正確な購入を完了する必要があり、事後に間違いに気づいても購入を止めることが出来ません。そして、多数のアカウントが同じ時間帯に一斉に RI を購入する必要があることを考えると、手動オペレーションでは品質・工数の両面で課題があります。 この課題に対応するため、AWS CloudShell 上で動作する RDS RI 一括購入のサンプルスクリプトを用意しました。AWS CloudShell はブラウザからアクセスできるシェル環境で、AWS CLI や jq（JSON 処理ツール）などの主要ツールがプリインストールされているため、実行環境の準備を別途行う必要がありません。AWS マネジメントコンソールにログインできれば、すぐにスクリプトを実行できます。 前提条件 AWS CloudShell 環境（AWS CLI、jq がプリインストール済みのため、追加のセットアップは不要） IAM ロールに以下の権限が付与されていること rds:DescribeReservedDBInstancesOfferings rds:PurchaseReservedDBInstancesOffering rds:DescribeDBInstances sts:GetCallerIdentity 1アカウントあたり同一リージョンで保有可能なRIはデフォルト40件まで（ 参考 ）。超過する場合は事前にサービスクォータの引き上げを申請してください （参考）AWS CloudShell VPC environment を利用する場合 CloudShell VPC environment ではシェルが指定した VPC のサブネット内で動作するため、スクリプトが呼び出す AWS API（RDS、STS）へのネットワーク到達性を確保する必要があります。具体的には、以下のいずれかを構成してください。 AWS PrivateLink（VPC エンドポイント）による RDS API および STS API へのアクセス NAT Gateway を経由したインターネットアクセス（ご利用環境のシステム要件やセキュリティポリシーを確認のうえ実施してください） ネットワーク構成が不十分な場合、API 呼び出しがタイムアウトしスクリプトが正常に動作しません。 ※ 本記事執筆時点では、デジタル庁が提供するガバメントクラウド環境で AWS CloudShell を利用するには CloudShell VPC environment の構成が必要です。 （参考）CloudShellを使わずローカル端末から実行する場合 AWS CloudShell を使用せず、お手元のローカル端末から実行することも可能です。その場合、以下の点にご注意ください。 シェルスクリプト実行環境が必要です。Linux や macOS ではデフォルトシェルである bash や zsh が利用できます。Windows の場合は WSL（Windows Subsystem for Linux）上で実行してください。 AWS CLI（バージョン2推奨）および jq を事前にインストールしてください。 AWS 認証情報の設定が必要です。aws configure 、IAM Identity Center（aws sso login）、 aws login 等で、スクリプト実行前に認証情報を構成してください。 スクリプトはタイムゾーン Asia/Tokyo を使用して購入タイミングの判定を行います。OS のタイムゾーンデータが正しくインストールされていることを確認してください。 Linux：“cat /etc/timezone” 等 macOS：“sudo systemsetup -gettimezone” 等 準備 入力ファイル（input.csv）を準備してください（フォーマットは後述）。次に、rds-ri-launchpad.sh を CloudShell へアップロード、または GitHub から直接取得し、実行権限を付与してください。 GitHub から直接取得する場合の例 curl -O https://raw.githubusercontent.com/aws-samples/sample-rds-ri-bulk-purchase-script/main/rds-ri-launchpad.sh chmod +x rds-ri-launchpad.sh スクリプトの特徴 スクリプトは「ドライラン（検証）モード」と「購入モード」の 2 段階で動作します。ドライランモードでは実際の購入を行わず、入力内容の検証のみを実施します。 ドライランモード（デフォルト） ./rds-ri-launchpad.sh input.csv 前述のとおり、RDS の RI には開始日時を指定した予約購入の機能がありません。そのため、本スクリプトではドライランモードを用意し、購入直前までの検証を事前に実施できるようにしています。以下のチェックを実施できます。 日本リージョン（ap-northeast-1 / ap-northeast-3）のみであること 前払いなし（No Upfront）のみであること インスタンスクラス形式の妥当性（db.xxx.xxx 形式） エンジン名の許可リスト検証 DescribeReservedDBInstancesOfferings API による Offering（購入可能な RI の条件と価格の組み合わせ）の存在確認 実際に稼働中のインスタンスとの突合（購入数量が稼働数を超過していないかの警告） 購入は一切実行されないため、実際のRI購入日である 4/1 より前に安全に事前確認が可能です。 購入モード ./rds-ri-launchpad.sh --purchase input.csv --purchase オプションを指定することで、実際の購入を実行します。購入時にはドライラン時のチェック項目に加えて、以下の制御が行われます。 購入タイミングの確認 — 4/1 09:00:00〜09:59:59（JST）の範囲外の場合はアラートを発行し、続行するかの確認プロンプトを表示 最終確認プロンプト — 購入実行前に yes/no の確認を要求 入力ファイル CSV 形式で購入情報を定義します。1 行目のヘッダー行はスクリプトが自動的にスキップします。 こちらはサンプルファイルです。 region,db_type,instance_class,engine,multi_az,quantity,duration,payment_option ap-northeast-1,RDS,db.t3.medium,mysql,yes,2,1,No Upfront ap-northeast-1,Aurora,db.r5.large,aurora-mysql,no,3,1,No Upfront フィールド 説明 許容値 region リージョン ap-northeast-1, ap-northeast-3 db_type DB 種別 RDS, Aurora instance_class インスタンスクラス db.xxx.xxx 形式 engine エンジン aurora-mysql, aurora-postgresql, mysql, postgresql, mariadb, oracle-se2, sqlserver-ex multi_az Multi-AZ yes, no（Aurora の場合は無視） quantity 購入数量 1 以上の整数 duration 期間（年） 1, 3 payment_option 支払いオプション No Upfront（他の文字列の場合はエラー） セキュリティ上の考慮 基本的なパストラバーサル対策 — 入力ファイルパスに .. が含まれる場合は即座に終了 入力値の許可リスト検証 — エンジン名、リージョン、支払いオプションを許可リストで検証 ロックディレクトリ機構 — 同時実行を防止し、二重購入を回避 結果ファイルのパーミッション制限 — chmod 600 で所有者のみ読み取り可能 エラー出力のサニタイズ — アカウント ID や ARN をマスクして表示 set -euo pipefail — 未定義変数やパイプエラーを即座に検出 エラーハンドリング スクリプトは「行単位の継続処理」を採用しています。ある行でバリデーションエラーや Offering 取得失敗が発生した場合でも、該当行をスキップして次の行の処理を継続します。AWS 認証エラーなど回復不能なエラーの場合のみスクリプトを終了します。 実行結果は ri_purchase_result_YYYYMMDD_HHMMSS.txt に自動出力され、成功・失敗・スキップの件数と各行の詳細が記録されます。一部の処理が失敗した場合は、 失敗した行のみを記載した新しいCSVファイルを作成し、再実行することで手動リトライが可能です。 本スクリプトは1回の実行あたり10〜100行程度の入力を想定しています。大量の入力（100行超）を処理する場合、AWS APIのスロットリングが発生する可能性があります。その場合はCSVファイルを分割し、複数回に分けて実行してください 。 ダウンロード サンプルスクリプトは以下リンクよりダウンロード可能です。 sample-rds-ri-bulk-purchase-script まとめ 本スクリプトは、限られた購入時間枠の中で大量の RDS / Aurora の RI を安全かつ効率的に一括購入するためのサンプルです。ドライランモードで事前に購入内容を検証し、購入モードで実行するという 2 段階のアプローチにより、オペレーションミスのリスクを低減します。 免責事項 本記事で紹介するスクリプトはサンプルコードであり、AWS サポートの対象外です。本番環境での使用前に、必ずテスト環境で十分な動作確認を行ってください。 本ブログや添付資料の内容はできる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。本ブログや添付資料はあくまで一例であり、すべての作業内容を充足するものではありません。本ブログや添付資料は AWS サービスの変更・追加などにより今後修正される場合があります。本ブログや添付資料の利用によって生じた損害等の責任は利用者が負うものとし、アマゾン ウェブ サービス ジャパン合同会社は一切の責任を負いません。上記ご了承の上、ご利用ください。 筆者について Hidenori Hiroki 廣木 秀典（Hidenori Hiroki）は、公共部門担当のTechnical Account Manager（TAM）。ポストフェーズにおけるお客様の課題解決をご支援しています。コスト最適化やセキュリティ設計など、お客様のクラウド活用を日々サポートしています。 Kazuki Fujimoto 藤本 一樹（Kazuki Fujimoto）は、パブリックセクターの自治体担当のソリューションアーキテクトです。自治体の基幹システムのクラウド移行やそれに伴うコスト最適化とモダナイゼーション、生成 AI の活用支援などをおこなっています。

ども！GitHub Copilot のニュースレターを眺めていた龍ちゃんです。 3月11日に届いたニュースレターで、 GitHub Copilot CLI が2月に GA（一般提供）になったことを知りました。ターミナルで動くエージェント型の AI アシスタントらしいんですよね。気になったのでとりあえずセットアップして触ってみました。 今回はセットアップだけまとめておきます。基本的には公式ドキュメントの補完なので、詳しくはそちらを参照してください。 About GitHub Copilot CLI – GitHub Docs Installing GitHub Copilot CLI – GitHub Docs GitHub Copilot CLI とは — ターミナルで動くエージェント型AI 一言でいうと、 ターミナルで動くエージェント型 AI アシスタント です。VSCode の Copilot Chat がエディタ内で動くのに対し、こちらは copilot コマンドを叩くだけで起動します。IDE も拡張機能も不要です。 イメージはClaude CodeのGitHub Copilot版を想像してもらえるとわかりやすいです。 2026年2月25日に GA（一般提供）になりました。約5ヶ月のプレビュー期間を経てのリリースで、GA バージョンは v1.0.2 です。既存の Copilot サブスクリプション（Free / Pro / Pro+ / Business / Enterprise）に含まれているので、追加費用はかかりません。 ただ！大きめの注意が必要です。デフォルトでプレミアムリクエストが消費されるので！気づいたら大量消費している可能性があるので気を付けてください。 旧 gh copilot（廃止済み）との違い 検索すると古い情報がよく出てくるので注意が必要です。「GitHub Copilot CLI」と検索すると、旧来の gh copilot の情報が混ざってくることがあるんですよね。まったくの別物なので整理しておきます。 旧: gh copilot 新: copilot コマンド 正式名称 GitHub Copilot in the CLI GitHub Copilot CLI 状態 2025年10月に廃止・アーカイブ 現行・GA インストール gh extension install github/gh-copilot npm install -g @github/copilot 等 できること コマンド提案・説明のみ エージェント型（コード生成・ファイル編集・コマンド実行） 旧 gh copilot はすでに廃止済みなので、今からインストールしようとしている方は新しい copilot コマンドを使ってください。 Copilot CLI のインストール方法（npm / Homebrew / WinGet 他5種類） 方法が5種類あります。使っている環境に合わせて選んでください。公式の手順は Installing GitHub Copilot CLI を参照。 方法 コマンド npm（全プラットフォーム） npm install -g @github/copilot Homebrew（macOS / Linux） brew install copilot-cli WinGet（Windows） winget install GitHub.Copilot シェルスクリプト（macOS / Linux） curl -fsSL https://gh.io/copilot-install | bash スタンドアロン実行ファイル GitHub Releases からダウンロード Homebrew / WinGet / シェルスクリプト経由は自動更新に対応しているので、個人的には Homebrew かシェルスクリプトがおすすめです。 npm を使う場合は Node.js 22 以上 が必要です。今回の検証はnpm経由で行いました。 npm だと npm update -g @github/copilot を手動で叩かないといけないので、そこだけ注意が必要です。 Codespaces を使っている方はプリインストール済みなので何もしなくて大丈夫です。 認証と初回起動の手順 インストールが終わったら、リポジトリのディレクトリに移動して copilot を叩くだけです。 cd /path/to/your-repo copilot 初回起動時は /login で認証を済ませてください。ブラウザが開いて GitHub の認証画面に飛びます。 > /login 起動すると「Environment loaded: 2 custom instructions, 24 skills, 11 agents, Visual Studio Code connected」のような表示が出ます。VSCode が開いていれば連携も自動で認識してくれます。 Business / Enterprise プランを使っている方は、組織の管理者が Copilot CLI のポリシーを有効化している必要があります。組織の Settings → Code, planning, and automation → Copilot → Policies から有効化できるので、使えない場合は管理者に確認してみてください。 基本操作と便利なスラッシュコマンド 起動したら、あとは日本語で話しかけるだけです。 # リポジトリの構成を聞く > このリポジトリの構成を説明して # テストの失敗原因を調べて修正してもらう > テストが失敗している原因を調べて修正して # ドキュメントを日本語に翻訳する > READMEを日本語に翻訳して ファイルの中身を読んで説明してくれたり、実際にコードを修正してくれたりします。VSCode の Chat と違うのは、ターミナルで完結することとエージェントとして動いてくれる点です。 この辺の使用感は Claude Code とほぼ同じで、「次のファイルを開いて」「このテストを直して」という自然な指示で動きます。 セッション中に使えるコマンド一覧 コマンド 説明 /plan 実行計画を確認してから作業を進める（いきなり変更させたくないときに） /model 使用するモデルを切り替える /usage プレミアムリクエストの消費量を確認する /context トークン使用量の詳細内訳を表示する /exit セッション終了（Ctrl+C でも可） /plan はplanエージェントが発火する形ですね。 /model でモデルを切り替えるで、大量のモデルが出てくるのもGitHub Copilotの特徴です。 Claude Sonnet 4.6 がデフォルトで、Claude Opus 4.6 や GPT-4.1 なども選べます。用途によって使い分けられます。 プレミアムリクエストの消費に注意 — Copilot Chat と共有枠 Copilot CLI に送る1プロンプトは、 1プレミアムリクエスト を消費します。そして、このプレミアムリクエストは Copilot Chat と同じ枠を共有しています 。 /usage で使用料を確認できるので、使いすぎが心配なときはこまめにチェックしておくといいです。ガッツリ使う作業の前に確認しておくのが無難です。 モデルを GPT-4o mini のような軽量モデルに切り替えると消費量を抑えられる場合もあるので、長丁場の作業には /model と合わせて使うといいと思います。 まとめ ニュースレターで知って、とりあえずセットアップして触ってみたという記事でした。ポイントだけまとめておきます。 ターミナルで動くエージェント型 AI — IDE 不要、Copilot サブスクで追加費用なし 旧 gh copilot とは別物 — 検索で古い情報が出てくるので注意 インストールは npm / Homebrew / WinGet — 自動更新が欲しいなら Homebrew かシェルスクリプト プレミアムリクエストは Chat と共有 — /usage でこまめに確認 セットアップ自体は数分で終わるので、Copilot のサブスクを持っている方はとりあえず入れてみるといいんじゃないかなと思います。 次回は Fleet モード について書く予定です。エージェントを複数同時に走らせて並列で作業させる機能で、これが CLI ならではの目玉っぽいんですよね。使ってみたらまたまとめます。 ではまた！ 関連記事 GitHub Copilot設定5種を網羅！生産性を最大化する使い分け術 — copilot-instructions.md やカスタムエージェントなど、Copilot の設定ファイル5種類を目的別フローチャートで整理した記事です。CLI を入れた後に設定まわりを整えたい方はこちらをどうぞ。 Claude Code→GitHub Copilot移行で使える設定ファイル6つの対応表 — 今回の記事で Claude Code に触れましたが、両方使っている方向けに CLAUDE.md と copilot-instructions.md など6種類の設定ファイルの対応関係を表でまとめています。 参考リンク GitHub Copilot CLI is now generally available – GitHub Changelog (2026-02-25) About GitHub Copilot CLI – GitHub Docs Installing GitHub Copilot CLI – GitHub Docs CLI Command Reference – GitHub Docs Requests in GitHub Copilot – GitHub Docs ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 2026年2月 GA：新 GitHub Copilot CLI を入れてみた — セットアップ手順まとめ first appeared on SIOS Tech Lab .

本投稿は、 2025 年 10 月 21 日に公開された記事 「 Restore self-managed Db2 Linux databases in Amazon RDS for Db2 」を翻訳したものです。 より多くの組織がセルフマネージドの Db2 on Linux ワークロードを Amazon Relational Database Service (Amazon RDS) for Db2 へ移行するにつれ、移行チームは「準備こそがプロジェクト遅延を防ぐ鍵」であることを学んでいます。よくある障壁として、移行プロセス中に表面化する古いデータベースバージョン、無効なオブジェクト、不適切なストレージ設定などが挙げられます。本記事では、これらの問題をスケジュールに影響を与える前に検出する Db2 移行前提条件検証ツール (Db2 Migration Prerequisites Validation Tool) を紹介します。このツールは徹底的な移行前検証を実施し、セルフマネージド 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 エントリが存在すること インタラクティブフローでは、ツールは以下の手順を実行します： Db2 バージョン情報を表示する 利用可能なインスタンスを一覧表示する 検証対象の現在のインスタンスを特定する 現在のインスタンス内のローカルデータベースを検出する Db2 サーバー上でスクリプトを実行できない場合はリモートデータベースを検証する 検証対象データベースを選択する 包括的な検証チェックを実行する 詳細レポートを生成する 以下のコマンドはインタラクティブ実行のコードです。 ツールの直接実行 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 としてローカルに保存します。 カテゴリ チェック内容・推奨事項・修正方法 db2updv115 最新の Amazon RDS for Db2 ソフトウェアを使用して RDS for Db2 インスタンスを作成していることを確認してください。IBM は db2updv115 ツール使用時に Db2 インスタンスクラッシュを引き起こす 既知の問題 を文書化しており、修正は Amazon RDS for Db2 ソフトウェアの最新リリースで提供されています。 これは RDS Db2 リストア失敗の最も一般的な原因の一つです。 db2updv115 ツールがデータベースで実行されたかどうかを検証する良い方法はありません。 推奨： db2updv115 -d <DBName> InDoubt Transaction（未確定トランザクション） 未確定トランザクションとは、準備済みだがまだコミットもロールバックもされていないトランザクションです。 すべてのトランザクションをコミットまたはロールバックする必要があります。 推奨： db2 list indoubt transactions with prompting Invalid Objects（無効オブジェクト） すべての無効オブジェクトを再検証またはドロップする必要があります。 推奨： db2 "call SYSPROC.ADMIN_REVALIDATE_DB_OBJECTS()" （複数回実行が必要な場合あり） Tablespace Check（テーブルスペースチェック） すべてのテーブルスペースが Normal 状態である必要があります。 推奨： テーブルスペースの状態は 20 種類以上あります。状態に応じて適切な対処を行ってください。IBM の ドキュメント の各テーブルスペース状態の説明を参照してください。 Non-Fenced Routines（ fenced でないルーティン） すべてのルーティンは fenced である必要があります。 推奨： fenced ではないルーティンは Amazon RDS for Db2 では許可されていません。すべてのルーティンを fenced に変換してください。 Automatic Storage（自動ストレージ） Amazon RDS for Db2 へのリストア失敗の一般的な原因です。少なくとも1つのストレージグループが存在する必要があります。 推奨： db2 "CREATE STOGROUP <name> ON '<PATHname>'" Database Config（データベース設定） 以下のパラメータが No である必要があります： Backup pending Rollforward pending Restore pending Upgrade pending Database Config（データベース設定） 循環ログの場合、ログファイル数は254以下であること。 アーカイブログの場合、ログファイル数は4096以下であること。 Database Sizing（データベースサイジング） Amazon RDS for Db2 のサイジング時は、データベースとログスペースの合計を考慮してください。 推奨： db2_migration_prereq_report_yyyymmdd_hhmmss.log の RDS_SIZING_TIER 変数を参照してください。 Federation（フェデレーション） すべての DBMS へのフェデレーションは Amazon RDS for Db2 でサポートされていません。サポートされていない DBMS へのフェデレーションがあっても Amazon RDS for Db2 へのリストア失敗は発生しませんが、アプリケーションがサポートされていない DBMS へのフェデレーションに依存している場合は機能が失われます。 推奨： サポートされているライブラリは libdb2drda.so と libdb2rcodbc.so です。 Java stored procedures（Java ストアドプロシージャ） データベースに JAR ファイルが定義されている場合（sysibm.sysjarcontents）、必要に応じて RDS for Db2 インスタンスに JAR ファイルを追加してください。 推奨： インストール： call sqlj.install_jar('jar-url', 'jar-id') → 例： call sqlj.install_jar('file:/home/rdsdb/Common.jar', 'COMMON') 置換： call sqlj.replace_jar('jar-url', 'jar-id') → 例： call sqlj.install_jar('file:/home/rdsdb/Common.jar', 'COMMON') 削除： db2 "sqlj.remove_jar('jar-id') → 例： call sqlj.remove_jar('COMMON') レポートの読み方と対応 以下の表は生成されるレポートをまとめたものです。 レポート名 詳細 db2_migration_prereq_report_yyyymmdd_hhmmss.log スキャンされたすべてのデータベースのチェック、推奨事項、修正方法を含むレポート。 db2_inventory_detail_ yyyymmdd_hhmmss.txt スキャンされた各データベースのテーブルスペース数、テーブル数、ビュー数、インデックス数などのインベントリ詳細。 db2_inventory_summary_ yyyymmdd_hhmmss.txt スキャンされたすべてのデータベースのインベントリ情報サマリー。 db2_inventory_ yyyymmdd_hhmmss.json スキャンされた各データベースのインベントリ詳細（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 コマンドが見つからない # db2 環境をソースする . ~/sqllib/db2profile # Db2 インストールを確認 which db2 echo $DB2INSTANCE Db2 インスタンスが見つからない # インスタンスが起動しているか確認 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 へのスムーズで成功した移行を実現できます。 このアプローチをご自身の環境で試しましたか？どのように機能したか、またはツールへの機能拡張要望があればぜひお知らせください。 著者について Vikram S Khatri Vikram は Amazon RDS for Db2 のSr. DBE です。Db2 において20年以上の経験を持ちます。ゼロからの新製品開発を楽しんでいます。余暇には瞑想を実践し、ポッドキャストを聴くことを楽しんでいます。 Umair Hussain Umair は Amazon RDS for Db2 のシニアデータベースエンジニアです。Db2 において20年以上の経験を持ちます。 Rajib Sarkar Rajib は Amazon RDS for Db2 のシニアデータベースエンジニアです。Db2 において20年以上の経験を持ちます。 この記事はクラウドサポートエンジニアの Shota Miyazaki が翻訳しました。