View a markdown version of this page

DDL ファイルをアップロードする (オフラインワークフロー) - AWS 変換

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

DDL ファイルをアップロードする (オフラインワークフロー)

このワークフローでは、 AWS Transform はアップロードされた DDL ファイルからスキーマを完全にモダナイズします。データベースへの直接接続は必要ありません。SQL Server に対して提供された抽出スクリプトを実行し、結果のスキーマファイルをアップロードすると、 AWS Transform はスキーマを検出、評価、変換し、Amazon Aurora PostgreSQL にデプロイします。データベースを直接接続に公開できない場合、またはネットワークアクセスを許可する前に実現可能性評価とスキーマ変換が必要な場合は、このワークフローを選択します。

重要

オフラインワークフローは、スキーマのみを変換してデプロイします。実際のデータは移行されません。利用可能な場合は、合成テストデータを生成してターゲットを検証できます。実際のデータを移行する必要がある場合は、DMS AWS コンソールを使用して新しいデータ移行プロジェクトを作成します。

オフラインワークフローの前提条件

  • サポートされている SQL Server バージョン (2008 R2~2022、すべてのエディション)。

  • 抽出スクリプトを実行する PowerShell 7 以降。PowerShell は Windows にプリインストールされています。macOS または Linux で PowerShell 7+ をインストールし、 でスクリプトを実行しますpwsh。Microsoft インストールガイドを参照してください。

  • PATH で使用できるsqlcmdユーティリティ。「sqlcmd ユーティリティ」を参照してください。

  • 少なくとも VIEW SERVER STATEおよび アクセスVIEW ANY DEFINITION許可を持つ SQL Server 認証ログイン (ユーザー名とパスワード)。スクリプトは Windows またはドメイン認証をサポートしていません。

  • IAM Identity Center または IAM 認証を有効にした後のフェーズ (Aurora PostgreSQL ターゲットの作成と変換されたスキーマのデプロイ) の AWS アカウント。

  • スキーマ分析と変換フェーズでは、 へのインバウンドまたはアウトバウンドのデータベース接続 AWS は必要ありません。

ワークフローステップ

  1. DDL ファイルのアップロード — AWS 変換は、チャット内の抽出スクリプトのダウンロードボタンを提供します。SQL Server に対してスクリプトをダウンロードして実行します。必要に応じて、抽出をカンマ区切りのインクルードリスト (大文字と小文字を区別しない) を持つ特定のデータベースに制限します。このスクリプトは、.zipSQL DDL ファイルのタイムスタンプを生成します。チャットアップロードボタンを使用して .zip (または個々の.sqlファイル) をアップロードします。

  2. 検出 — AWS 変換は、アップロードされたファイルを解析し、データベースオブジェクト (テーブル、ストアドプロシージャ、ビュー、トリガー、インデックス、制約、シーケンスなど) をデータベース別にグループ化してカタログ化します。データベースごとの概要を確認し、評価するデータベースを選択します。一部のステートメントを解析できない場合、 AWS Transform は問題をレポートし、解析したオブジェクトを続行したり、特定のデータベースを選択したり、修正したファイルをアップロードしたりできます。

  3. 評価 — AWS 変換は、選択したデータベースの変換の実現可能性を評価し、エグゼクティブサマリー、データベースごとのオブジェクト概要、およびlevel-of-effort (LOE) の見積もりを含むダウンロード可能なレポートを生成します。LOE スコアをカスタマイズするか、追加のファイルをアップロードするか、変換に進みます。

  4. スキーマ変換 — AWS 変換は、SQL Server スキーマ (T-SQL ストアドプロシージャを含む) を一度に 1 つのデータベースである Aurora PostgreSQL に変換します。1 つのデータベースが自動的に変換されます。複数のデータベースでは、変換するデータベースを選択します。データベースは独立して並行して変換されます。

  5. ターゲットプロビジョニング — 変換されたデータベースごとに、 AWS Transform は AWS アカウントで Amazon Aurora PostgreSQL クラスターを作成または再利用します。ガイド付きプロンプトを使用して、ネットワークとターゲットの設定を選択します。

  6. スキーマのデプロイ — AWS 変換は変換されたスキーマを Aurora クラスターに適用します。デプロイ後、チャットまたは IDE の残りのオブジェクトを修正するか、合成テストデータ (利用可能な場合) を生成するか、終了します。

  7. アプリケーションコードのモダナイゼーション (オプション) — AWS トランスフォームは、関連する .NET 6+ アプリケーションを更新して Aurora PostgreSQL と連携させることができます。このサービスは、ソースコードのデータベース接続を更新し、Entity Framework および ADO.NET の ORM コードを変更して、人間の監督による統合ワークフローで Aurora PostgreSQL と互換性を持たせます。GitHub および GitLab の AWS CodeConnections または Personal Access Token (PAT) を使用してソースコードリポジトリを接続するか、ソースコードを含む zip ファイルの S3 URI を指定します。

注記

Amazon Aurora PostgreSQL は、このワークフローでサポートされている唯一のターゲットエンジンです。

オフラインワークフローのサービス制限

オフラインワークフローには、次のデフォルトの制限が適用されます。一部の制限はアカウントごとに設定できます。 AWS アカウントチームに連絡して引き上げをリクエストしてください。

制限 デフォルト 適用先
ジョブあたりのアップロードサイズ 1,024 MB (1 GB)、ジョブ内のすべてのアップロードで累積 DDL ファイルをアップロードする
1 か月あたりに変換されたデータベース アカウントあたり 10 個 スキーマ変換
データベースあたりのストアドプロシージャ 250 スキーマ変換
同時スキーマ変換 一度に 5 つのデータベース スキーマ変換
同時実行ジョブ 5 アカウントあたり
  • アップロードサイズの制限は、ジョブごとの累積予算です。入力設定をリセットすると、予算はクリアされます (これにより、アップロード済みのファイルは破棄され、同じジョブ内で検出と評価が再実行されます)。

  • 変換するデータベースを 5 つ以上選択すると、追加のデータベースがキューに入れられ、実行中の変換が終了すると自動的に開始されます。

  • データベースstored-procedure-per-databaseの制限によって評価がブロックされることはありません。スキーマ変換のみが影響を受けます。

オフラインワークフローのトラブルシューティング

抽出スクリプト

  • pwsh: command not found (macOS/Linux) — PowerShell 7+ がインストールされていません。インストールして を実行しますpwsh ./ExtractDatabaseMetadata.ps1。

  • 参照エラー sqlcmd — sqlcmdユーティリティが PATH にありません。インストールし、PATH にあることを確認します。

  • ログインまたはアクセス許可エラー — VIEW SERVER STATEおよび で SQL Server 認証ログインを使用しますVIEW ANY DEFINITION。Windows/ドメイン認証はサポートされていません。

  • エクスポートされたデータベースの一部のみ — インクルードリストによってスコープが絞り込まれました。これなしで再実行するか、正しいカンマ区切りのデータベース名を指定します。

アップロード

  • サイズメッセージでアップロードが拒否されました — ジョブごとのアップロード予算を超えています。小さいファイルをアップロードするか、エージェントに入力設定をリセットして同じジョブ内の予算をクリアするように依頼します。推定するのではなく、現在の残りの予算についてエージェントに依頼します。

  • ファイルが承認されない — スクリプトによって.zip生成された または個々の.sqlファイルをアップロードします。複数のファイルを 1 つのアーカイブに圧縮します。

発見

  • SQL 構文の問題が検出されました — 問題レポートをダウンロードします。エラーのないセクションのオブジェクトは引き続きカタログ化されます。解析されたオブジェクトを続行するか、特定のデータベースを選択するか、修正されたファイルをアップロードするかを選択します。

  • 汎用名でグループ化されたオブジェクト — パーサーはUSE [Database]ステートメントを見つけることができませんでした。プロンプトが表示されたら、正しいデータベース名を入力します。

  • オブジェクトが見つかりません — ファイルにはCREATEステートメントが含まれていないか、すべて解析に失敗しました。有効な DDL を再アップロードします。

評価

  • LOE 見積りのルックオフ — LOE スコアをカスタマイズし、テンプレートを編集し、再アップロードして評価を再生成することを選択します。

  • 見逃したオブジェクト — 追加の SQL ファイルをアップロードすることを選択します。検出と評価は自動的に再実行されます。

スキーマ変換

  • データベース変換が失敗する — AWS 変換によって理由が報告されます。再試行をリクエストすると、そのデータベースの変換が再開されます。

  • レスポンスが間違ったデータベースに送られる — 複数のデータベースが入力を待っている場合は、メッセージの送信先のデータベースを指定します。で特定のデータベースに対処できます@DatabaseName:。

ターゲットのプロビジョニングとデプロイ

  • Aurora クラスターを作成できない — ガイド付き認証情報とネットワークプロンプトを完了し、アカウントに Aurora PostgreSQL を作成するアクセス許可があることを確認します。

  • 一部のオブジェクトがデプロイされなかった — デプロイ後のオプションを使用して、チャットまたは IDE 内の残りのオブジェクトを修正し、再デプロイします。