データベース

複数の結果セット: Database Migration Service における SQL Server から PostgreSQL への変換の自動化

2026年8月20日

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_YZKIgBS.max-2000x2000.jpg

Assaf Fraenkel

SQL Server Blackbelt

Yuval Ben Arie

Senior Software Engineer

Try Gemini Enterprise Business Edition today

The front door to AI in the workplace

Try now

※この投稿は米国時間 2026 年 8 月 5 日に、Google Cloud blog に投稿されたものの抄訳です。

Medium のブログ投稿「From MARS to SETOF REFCURSOR: Migrating Multi-Result Stored Procedures to PostgreSQL」（MARS から SETOF REFCURSOR へ: 複数の結果を返すストアドプロシージャを PostgreSQL に移行する）で、複数の結果セットに関する SQL Server と PostgreSQL の基本的なアーキテクチャの違いについて説明しました。SQL Server では 1 回の実行で複数の表形式ストリームをネイティブにストリーミングする一方、PostgreSQL では、明示的なカーソル操作を使用する、より慎重な戦略が必要であるという内容でした。

このようなプロシージャが数百もある大規模なデータベース移行に対応しなければならない場合、手動での書き換えは現実的ではありません。こうした状況で役立つのが自動ツールです。この投稿では、この課題に対する Google Cloud の Database Migration Service（DMS）のアプローチ、その内部で適用される変換ロジック、生成されたコードを実際に実行してテストする方法について詳しく説明します。

DMS の中核的な変換戦略

データベースを PostgreSQL に移行する要因は数多くあります。たとえば、エンタープライズ規模のパフォーマンスと可用性、拡大し続けるデベロッパーとユーザーのコミュニティ、強力な AI 機能などです。しかし、複数の結果セットを含むクエリなどの複雑なクエリの場合、移行プロジェクトの遅延を招く可能性があります。

DMS が確認するのは、プロシージャが返す結果セットの数と、スカラー戻り値（RETURN）を使用するかどうかの 2 点です。

変換に関する意思決定マトリックスは次のようなものです。

シナリオ	SQL Server の特性	PostgreSQL ターゲットオブジェクト	メカニズム
シナリオ A	結果セット 1 つ、またはスカラー戻り値 1 つのみ	ストアドプロシージャ	INOUT refcursor パラメータまたは標準の変数トラッキングを介してネイティブに処理。
シナリオ B	複数の結果セット、または結果セットとスカラー戻り値の組み合わせ	関数	RETURNS SETOF refcursor ブロックに変換。スカラー戻り値は、独自の個別カーソルデータセットとして追加される。

複数の結果セットの変換を自動化: DMS 内部の動作

SQL Server は、明示的な宣言なしで単一の接続実行パスを介して複数の結果を送信できるようにする、表形式データストリームプロトコルを利用します。一方、PostgreSQL は、カーソルを介して複数のデータセットが決定的に管理される、別個の実行プロトコルに依存しています。この構造上の違いを補うため、DMS は変換ロジックを自動化します。

医療報告のベースラインシナリオを例に考えてみましょう。マスタープロシージャ（sp_GetPatientSummary）は、検査結果用（sp_GetPatientLabResults）と診察用（sp_GetPatientDoctorVisits）の 2 つの子プロシージャを条件付きで呼び出すことで、患者のデータ取得をオーケストレートします。

条件付きロジックと手続き型実行パスに応じて、1 回の実行で最大 4 つの異なる結果セットと、患者が見つかったかどうかを示すステータス整数を返すことができます。

SQL

読み込んでいます...

ターゲット: PostgreSQL の決定的カーソル

PostgreSQL の実行モデルに合わせるため、DMS は SETOF refcursor と明示的なカーソル管理を使用して、元の T-SQL の動作を構造的な PL/pgSQL アーキテクチャにマッピングします。

1. シンプルなトラッキング: ストアドプロシージャの変換

1 つの結果セットのみを生成する子プロシージャ sp_getpatientdoctorvisits について、DMS は標準の PostgreSQL PROCEDURE を作成します。その際、明示的な INOUT refcursor パラメータを使用して、ポインタを呼び出し元に安全に返します。

SQL

読み込んでいます...

2. マルチセットトラッキング: 関数への変換

マスタールーティンと複雑な検査の子ルーティンについては、INOUT パラメータだけではさまざまな出力配列を取り込めません。DMS は、SETOF refcursor を返す PL/pgSQL 関数にこれらを変換します。

変換された sp_getpatientlabresults がカーソルを順番に構築し、最後に「return_value」と明示的に命名された個別のカーソルを動的に開いて、スカラー整数を実行スタックに返す方法に注目してください。

SQL

読み込んでいます...

CREATE OR REPLACE FUNCTION dbo.sp_getpatientlabresults(_patientid INTEGER, _querytype INTEGER)
RETURNS SETOF refcursor
LANGUAGE plpgsql
AS $$
DECLARE   rc refcursor;   _recordsfound INTEGER := 0;
BEGIN
  IF _querytype IN (1, 3) THEN
    OPEN rc FOR 
      SELECT resultid, patientid, testname, testdate, isexception
      FROM dbo.labresults
      WHERE patientid = _patientid 
        AND testdate >= localtimestamp - interval '6 months';
    RETURN NEXT rc;

IF EXISTS (
      SELECT 1 FROM dbo.labresults 
      WHERE patientid = _patientid 
        AND testdate >= localtimestamp - interval '6 months'
    ) THEN recordsfound := 1; 
    END IF;
  END IF;

IF _querytype IN (2, 3) THEN 
    rc := NULL; -- Reset to generate a new unique cursor name
    OPEN rc FOR 
      SELECT resultid, patientid, testname, testdate, isexception
      FROM dbo.labresults
      WHERE patientid = _patientid 
        AND isexception = TRUE 
        AND testdate >= localtimestamp - interval '2 years';
    RETURN NEXT rc;

IF EXISTS (
      SELECT 1 FROM dbo.labresults 
      WHERE patientid = _patientid 
        AND isexception = TRUE 
        AND testdate >= localtimestamp - interval '2 years'
    ) THEN 
      _recordsfound := 1; 
    END IF;
  END IF;

rc := 'return_value';
  OPEN rc FOR SELECT _recordsfound AS return_value;
  RETURN NEXT rc;
END;
$$;

プログラムによる出力の解析

移行したルーティンを再びアプリケーションのデータアクセスレイヤに統合する際、QA エンジニアとアプリケーションエンジニアは、実行結果の処理方法を調整する必要があります。呼び出し元のアプリケーションまたはテストハーネスは、標準的な表形式の行を順番に読み取るのではなく、カーソル参照の配列を受け取ります。これをプログラムで処理するには、返された各ポータルからデータを順番に取得する必要があります。DMS は、実行スタックの最後で、明示的に命名された専用の「return_value」カーソルデータセット内にスカラー戻り値を配置することで、このスカラー戻り値を分離します。この構造マッピングに対応できるよう開発チームの体制を整えることで、アプリケーションロジックと検証スクリプトが、多層のレスポンス配列を中断なく正確に解析できるようになります。

移行したコードの実行とテスト

PostgreSQL で移行されたオブジェクトをテストする場合、明示的なトランザクションブロック内で作業する必要があります。PostgreSQL カーソルはトランザクションのライフサイクルにバインドされているため、メモリポータルからデータにアクセスするには、実行コマンドとデータ取得コマンドを 1 つの BEGIN ... COMMIT ブロック内にカプセル化する必要があります。

PostgreSQL 内で患者 3 の複雑なデータセット全体を実行して取得する方法は次のとおりです。

SQL

読み込んでいます...

DMS の技術詳解: 結果セットのカウントの仕組み

https://storage.googleapis.com/gweb-cloudblog-publish/images/2_mgkHjQS.max-2000x2000.jpg

DMS プロダクトは、予想される結果セットの数と戻り値の存在の可能性を把握するための高度な前処理メカニズムを採用しています。最終的な目標は、すべての SQL Server プロシージャを 3 種類のカテゴリのいずれか（結果セットなし、結果セット 1 つ、複数の動的な結果セット数）にマッピングすることです。

これを正確に実行するために、DMS は詳細な構造分析を行います。

直接結果セット: まず、エンジンがプロシージャのボディ部分をスキャンして、直接結果セットをカウントします。直接結果セットとは、プロシージャ内で直接実行される明示的な SELECT ステートメントです。
動的考慮: ループまたは条件付きの SELECT / EXEC ステートメントを扱う場合は、特別な考慮が必要です。これらの構成要素は本質的に、返される結果セットの数が実行ごとに異なる可能性があることを意味するため、そのプロシージャの数は即座に「動的」としてマークされます。
呼び出しネットワークの構築: 他のストアドプロシージャへの参照を検出した時点のエンジンは、それらの子プロシージャが公開する結果セットの数をまだ把握していません。これを解決するために、DMS は包括的な有向グラフを構築して、プロシージャ間の呼び出し階層全体をモデル化します。
DFS の伝播: この有向ネットワークが完全に構築されて初めて、エンジンは深さ優先探索（DFS）アルゴリズムを実行できます。この DFS トラバーサルでは、固定整数または動的フラグのいずれであっても、結果セットの数が呼び出しチェーンをさかのぼって最上位のプロシージャに体系的に伝播されます。

結果的に、生成されたコードは、外部データセットを返すように、またネストされた実行スタック内で子ルーティンを正しく呼び出すことができるように、正確に変更されます。このグラフベースのアプローチにより精度が保証され、直接再帰と間接再帰の両方を含む、非常に複雑なプロシージャ間のやり取りがシームレスにサポートされます。

まとめ

Google Cloud の Database Migration Service は、結果セットの数に基づいて FUNCTION と PROCEDURE のディシジョンツリーをプログラムで適用することで、構造変換の不確実性を排除します。中核的なビジネスおよび条件付き実行ロジックは完全に保持されますが、アプリケーション接続プールと QA エンジニアが実行結果を処理する方法は変わります。

この自動化されたアーキテクチャについて理解することで、PostgreSQL での Day 2（2 日目からの）運用がシームレスになるよう、検証スクリプトを効果的にマッピングし、データアクセスレイヤを構成できます。

以上で、複数の結果セットを変換する方法を習得できました。早速、Google Cloud で PostgreSQL データベースを活用しましょう。ぜひ、皆様のご体験をお聞かせください。

Google Cloud の $300 分の無料クレジットで Database Migration Service をご利用いただけます。無料で構築を始める

- SQL Server ブラックベルト、Assaf Fraenkel

- シニアソフトウェアエンジニア、Yuval Ben Arie

投稿先