Skip to content

MS_SQLServerUpgradeMigration

Jump to bottom
nishi_74322014 edited this page Aug 18, 2026 · 1 revision

SQL Server のアップグレードと移行

概要

以下は種々のアップグレード・パスの参考資料です。

アップグレードとマイグレーション

コンポーネント アップグレード マイグレーション
全コンポーネント セットアップ ウィザード ―
データベース エンジン 〃 デタッチ/アタッチ
〃 〃 バックアップ/復元
〃 〃 データベース コピー ウィザード
〃 〃 SSIS (SQL Server Integration Services)
〃 〃 SQL Server スクリプト生成ウィザードによる、スクリプトの生成・実行
〃 〃 SQL Server Migration Assistant 移行ツール（Oracle / Access / MySQL / Sybase 向け）
Analysis Services 〃 Analysis Services 移行ウィザード（オブジェクトの最適化は行われない）
Reporting Services 〃 Reporting Services Configuration Tool
データ変換サービス (DTS) － SQL Server Integration Services 移行ウィザード
〃 〃 既存 SQL Server 2005 の DTS パッケージ並行稼動

補足（2つの方式の違い）: 用語が紛らわしいので整理しておく。

アップグレード（in-place） マイグレーション（side-by-side）
手順 既存インスタンスを上書き更新 新サーバを建てて移す
停止時間 比較的短い 切り替えのみ（事前準備が可能）
切り戻し 困難（バックアップからの復旧のみ） 容易（旧環境が残る）
ハード更改 伴わない 伴える

実務ではマイグレーション（新環境構築 → 移行）が圧倒的に推奨される。
切り戻しができること、事前に新環境で十分に検証できることが理由である。
本ページ後半の自習書のケース 1〜3 も、
この 2 方式の組み合わせを扱っている。

アップグレード

基本的なアップグレードと移行方法は、インストール ファイルの Setup.exe から
セットアップ ウィザードでの実行となります。
アップグレードの実行で、既存のコンポーネントやデータベースに
問題が発生しないか、既存インスタンスの解析を行います。
その結果、問題となる部分が発見された場合には、
アップグレードを実行する前に必ず対処しておく必要があります。
さらに Upgrade Advisor によって得た結果を、
Upgrade Advisor Report Viewer によってレポート形式で出力することもできます。

Upgrade Advisor ツールは既定でインストールされないため、
セットアップ メニューから [Install SQL Server Upgrade Advisor] を選択して、
ツールをインストールする必要があります。

  • バージョンとエディションのアップグレード
  • SQL Server コンポーネントのアップグレード
  • アップグレード アドバイザーを使用したアップグレードの準備

補足（最新化：Upgrade Advisor は廃止）: Upgrade Advisor は
SQL Server 2016 で廃止され、後継は
Data Migration Assistant (DMA) である。

ツール 用途
Data Migration Assistant (DMA) 互換性の問題を検出し、移行を実行する。Upgrade Advisor の後継
Database Experimentation Assistant (DEA) 本番のワークロードを記録し、新旧バージョンで再生して比較する
Azure Migrate / Azure Database Migration Service Azure への移行

DMA が検出するのは以下の 3 種類。

  • 破壊的変更（そのままでは動作しない）
  • 動作の変更（動くが結果や性能が変わる）
  • 非推奨機能（将来のバージョンで削除される）

DEA は特に価値が高く、
「アップグレード後に一部のクエリだけ遅くなる」という
典型的な事故を事前に検出できる
（SQL Server のバージョンの互換性レベルの補足も参照）。

マイグレーション

  • Analysis Services
  • Reporting Services
  • Integration Services

については、専用の移行ツールが備えられており、
ウィザードで移行作業にかかる工数を簡略化することができます。

サポートされるアップグレード・パス

サポートされているバージョンとエディションのアップグレードは、
バージョンごとに Microsoft Learn のドキュメントで公開されている。

SQL Server 2000 → SQL Server 2012 アップグレードは、
サポートされず、2008 などの DB を経由する必要があるようです。

補足（2 世代ルール）: SQL Server の直接アップグレードは
概ね2〜3 世代前までしかサポートされない。
古いバージョンからは中継が必要になる。

ただし、バックアップ/復元やデタッチ/アタッチであれば、
より広い範囲から直接移行できることが多い
（復元可能な最古のバージョンは製品によって異なる）。
「アップグレード（in-place）はできないが、
新環境への復元はできる」というケースがあるため、
マイグレーション方式のほうが選択肢が広い。

アップグレード

アップグレード アドバイザー

アップグレード アドバイザーでは、
以前のバージョンの SQL Server でインストールされたコンポーネントが分析され、
アップグレードの前または後に修正する必要がある問題を示すレポートが生成されます。

（前述のとおり、現在は Data Migration Assistant (DMA) を使用する）

インストール ウィザード

SQL Server インストール ウィザードでは、1 つの機能ツリーを使用して、
SQL Server コンポーネントをアップグレードできます。

マイグレーション

バックアップ / リストア

バックアップと復元によるデータベースのコピー
https://learn.microsoft.com/ja-jp/sql/relational-databases/backup-restore/copy-databases-with-backup-and-restore\ ＃オンライン・バックアップに相当する。

  • 復元を使用してデータベースをアップグレードする場合
    バックアップを SQL Server 2005 または SQL Server 2008 から復元する場合は、
    バックアップにある各フルテキスト カタログのパス（ドライブとディレクトリ）が
    コピー先コンピューターに存在するかどうかを事前に知っておくと便利です。

  • 復元時、GUI からは［オプション］ページから復元先のパスを変更することができます。
    T-SQL の RESTORE ステートメントからリストアする場合も
    MOVE ... TO でパス変更可能です。
    これは、移行元と移行先でドライブ構成やフォルダ構成が異なる場合に利用します。

  • 復元の後、ユーザーおよびアプリケーションに一貫した使用環境を提供するために、
    復元先のサーバー インスタンスで、ログイン、ジョブ、権限などの
    データベースのメタデータの一部またはすべてを作成し直す必要が生じる場合があります。

補足（バージョンは後戻りできない）: 復元は
上位バージョンへは可能だが、下位バージョンへは不可能である。
一度新バージョンで復元（＝アップグレード）したデータベースは、
旧バージョンに戻せない。

このため、切り戻しは
移行元のバックアップを保持しておくことでしか実現できない。
移行後も一定期間は旧環境を残すのが定石である
（SQL Server のバックアップ、
SQL Server の障害復旧）。

デタッチ / アタッチ

ファイルのデタッチ / アタッチもバックアップ / リストアの一種です。
＃オフライン・バックアップに相当する。

補足（バックアップ/復元のほうが安全）: デタッチ/アタッチは
ファイルをそのまま移すため速いが、

  • デタッチ中にファイルを失うとバックアップが存在しない
  • デタッチ操作自体が失敗するとデータベースが宙に浮く

というリスクがある。
バックアップ/復元であれば元のデータベースは無傷のままなので、
移行手段としてはこちらを優先すべきである。

ファイル グループなどの構成変更は可能か？

補足: sp_attach_db は非推奨であり、現在は
CREATE DATABASE ... FOR ATTACH を使用する。
ファイルの配置先を変える場合は
RESTORE ... WITH MOVE のほうが扱いやすい
（SQL Server のファイルの配置、
SQL Server のファイル・グループ）。

補足情報

SQL Server データベースのアップグレード後

  • データベースにフルテキスト インデックスがある場合、
    upgrade_option サーバー プロパティの設定に応じて、
    アップグレード プロセスでデータベースのインポート、リセット、
    または再構築のいずれかが行われます。

  • アップグレード前のユーザー データベースの互換性レベルが

    • 90 または 100 の場合は、アップグレード後も互換性レベルは変わりません。
    • 80 以下の場合、アップグレードされたデータベースの互換性レベルは 90 に設定されます。

  • データベースを別のサーバー インスタンスにアタッチするときは、
    ユーザーおよびアプリケーションに一貫した使用環境を提供するために、
    アタッチ先のサーバー インスタンスで、ログイン、ジョブ、権限などの
    データベースのメタデータの一部またはすべてを作成し直す必要が生じる場合があります。

  • 3DES から AES へのサービス マスター キーとデータベース マスター キーの再暗号化

移行メモ（体裁）: 元ページの最終項目は
「3DES から AES へのサービス マスター キーとデータベース マスター」で
文が途切れていたため、文意を補って掲載した。

データベース コピー ウィザード

データベース コピー ウィザードは
内部的に「デタッチとアタッチ」を使用している。

補足: データベース コピー ウィザードには
「デタッチとアタッチ」方式と「SMO 方式」の 2 つがあり、
後者はソース DB をオンラインのまま実行できる。
ただし現在は、バックアップ/復元か
DACPAC / BACPAC（後述のデータ層アプリケーション）を使うことが多い。

エクスポート & インポート

インポート / エクスポートウィザード

  • SQL Server インポートおよびエクスポート ウィザード
    https://learn.microsoft.com/ja-jp/sql/integration-services/import-export-data/import-and-export-data-with-the-sql-server-import-and-export-wizard

    ジョブやログイン、DTS パッケージの移行等を考慮する必要がありますが、
    データベース単体であればスキーマと、データを
    インポート / エクスポート ウィザード（SSIS）で移行できます。

    ただし、同様にインポートの後、
    ユーザーおよびアプリケーションに一貫した使用環境を提供するために、
    アタッチ先のサーバー インスタンスで、ログイン、ジョブ、権限などの
    データベースのメタデータの一部またはすべてを作成し直す必要が生じる場合があります。

  • 以下、「SE の雑記」からの引用

    インポート / エクスポート ウィザードでテーブルを作成しデータを移行した場合、
    インデックス等の情報は移行されていませんので、
    ウィザードでテーブルを作成するのではなく、
    スクリプトの生成で一度スクリプトを作成して、移行するのが良いと思います。

補足（最新化：DACPAC / BACPAC）: 現在は、
データ層アプリケーションという枠組みが用意されている。

形式 内容
DACPAC スキーマのみ（テーブル・インデックス・ストアド等）
BACPAC スキーマ + データ

SSMS の「データ層アプリケーションのエクスポート／インポート」や
SqlPackage.exe で扱え、Azure SQL Database への移行の標準手段でもある。
「スクリプト生成 + データ移行」を 1 つのファイルにまとめたもの、と
理解すると分かりやすい。

bcpユーティリティ、BULK INSERT

一括インポート操作と一括エクスポート操作。

Identity列がある場合

Identity 列がある場合も考慮が必要になります。

補足: bcp では -E オプション、BULK INSERT では KEEPIDENTITY、
INSERT 文では SET IDENTITY_INSERT テーブル名 ON を使う。
移行後はシードの再設定（DBCC CHECKIDENT）も忘れないこと。
これを怠ると、次の採番が既存値と衝突して主キー違反になる。

一括インポートの際の注意事項

一括インポートの際は、以下の項目に注意ください。

一括インポートのパフォーマンスの最適化
https://learn.microsoft.com/ja-jp/sql/relational-databases/import-export/prerequisites-for-minimal-logging-in-bulk-import

特定の一括インポート操作のパフォーマンスの最適化に影響を与える要素と高速化の方法

  • テーブルに制約、トリガのいずれかまたは両方が含まれているかどうか。

    • 制約の無効化（一括インポート操作による制約チェックの制御）
    • トリガの無効化（データの一括インポート時のトリガ実行の制御）
      （SQL Server のトリガ）

  • データベースによって使用される復旧モデル。

    • 最小ログ記録の使用（完全復旧モデルまたは一括ログ復旧モデルからの切り替え）
    • バッチの使用（一括インポートのバッチの管理）

  • データのコピー先となるテーブルが空かどうか。

    • 1 台のクライアント（またはストリーム）から空のテーブルへのデータのインポート
    • 1 台のクライアント（またはストリーム）から空でないテーブルへのデータのインポート

  • テーブルにインデックスが含まれているかどうか。

    • データ ファイルのデータの順序付け（データの一括インポート時の並べ替え順の制御）

  • TABLOCK が指定されているかどうか。
    データが 1 つのクライアントからコピーされているか、
    複数のクライアントから同時にコピーされているか。

    • テーブルレベル ロックと並行したデータのインポート
    • 一括インポートのロック動作の制御

  • データが SQL Server を実行している
    2 台のコンピュータ間でコピーされるかどうか。

    • サーバー間でのデータのコピー
      • ネイティブ形式を使用したデータのインポートまたはエクスポート (SQL Server)
      • Unicode ネイティブ形式を使用したデータのインポートまたはエクスポート (SQL Server)

  • DB ファイルの自動拡張
    SQL Server に関してよくある間違いトップ 10

    データベース ファイルとトランザクション ログ ファイルのサイズが十分大きく、
    通常の毎日の運用中に自動拡張が行われないことを確認してください。
    これは、終了するまでユーザを待たせることになる非常に低速な動作です。

補足: 最小ログ記録の条件と副作用（ポイントインタイム復旧不可）は
SQL Server 大量データ処理時の性能問題に、
自動拡張の設定指針は
データ ファイルの圧縮と拡張にまとめてある。

その他の移行方式

以下の方法が有用です。

互換性レベル

データベースの互換性レベルの表示または変更
https://learn.microsoft.com/ja-jp/sql/relational-databases/databases/view-or-change-the-compatibility-level-of-a-database

互換性レベルには以下のものがあり、

  • [SQL Server 2005 (90)]
  • [SQL Server 2008 (100)]
  • [SQL Server 2012 (110)]

データベース単位で動作を変える事ができます。
互換性レベルの詳細は以下を参照してください。

ALTER DATABASE 互換性レベル (Transact-SQL)
https://learn.microsoft.com/ja-jp/sql/t-sql/statements/alter-database-transact-sql-compatibility-level

補足: 現在の互換性レベルの一覧と、
アップグレード時に段階的に上げる手順は
SQL Server のバージョンにまとめてある。
要点は、

  1. インスタンスをアップグレードし、互換性レベルは据え置く
  2. クエリ ストアを有効化してベースラインを取得
  3. 互換性レベルを上げる
  4. 回帰したクエリをクエリ ストアで特定し、プランを強制する

という順序で進めること。
特に SQL Server 2014（レベル 120）の
新カーディナリティ推定が性能回帰の主因になりやすい
（SQL Server のオプティマイザ）。

メタデータ移行

データベースを別のサーバー インスタンスに移行するときは、
ユーザーおよびアプリケーションに一貫した使用環境を提供するために、
移行先のサーバー インスタンスで、ログイン、ジョブ、権限などの
データベースのメタデータの一部またはすべてを作成し直す必要が生じる場合があります。

詳しくは、以下を参照下さい。

データベースを別のサーバー インスタンスで
使用できるようにするときのメタデータの管理
https://learn.microsoft.com/ja-jp/sql/relational-databases/databases/manage-metadata-when-making-a-database-available-on-another-server

基本的に、新規構築手順を踏んだり、SQL スクリプト生成で対応します。
（master や msdb の復元での移行はしない）

この部分の操作イメージについては、
「SQL Server 2008 自習書シリーズ No.21 移行とアップグレード」
を参照すると良いかと考えます。

補足（孤立ユーザー問題）: 移行で最も頻発するのが
**孤立ユーザー（orphaned users）**である。
データベース内のユーザーは、サーバーのログインと SID で紐づいているが、
移行先で同名のログインを新規作成すると SID が変わるため、
紐づきが切れて「ログインできるが権限がない」状態になる。

対処は以下。

-- 孤立ユーザーの確認
SELECT dp.name, dp.principal_id, dp.sid
FROM sys.database_principals AS dp
LEFT JOIN sys.server_principals AS sp ON dp.sid = sp.sid
WHERE dp.type IN ('S','U','G') AND sp.sid IS NULL
  AND dp.principal_id > 4;

-- 再マッピング
ALTER USER [ユーザー名] WITH LOGIN = [ログイン名];

根本的な回避策としては、

  • SID を指定してログインを作成する
    （sp_help_revlogin で移行元からスクリプトを生成する）
  • 包含データベース（Contained Database）にして
    ユーザーを DB 内に閉じる
  • Windows 認証やマイクロソフト Entra ID 認証にする（SID が AD 側で一意）

がある。
ジョブ（msdb）とリンク サーバー、資格情報も
同様に個別移行が必要になる。

サブシステムの移行

  • SQL Server 2008 R2 への移行

    • Reporting Services のインストールを移行する方法（SSRS）
    • Integration Services パッケージのアップグレード（SSIS）
    • データ変換サービス パッケージの移行

  • 移行 (Reporting Services)

    • Reporting Services のインストールの移行 (ネイティブ モード)
    • 別のコンピューターへのレポート サーバー データベースの移動

  • 移行 (Integration Services)

    • データ変換サービス パッケージの移行
    • データ変換サービス パッケージを Integration Services に移行する方法

  • SSIS パッケージ アップグレード ウィザードの F1 ヘルプ

データ変換方式

基本的にファイルにエクスポートした後にデータ変換を行い、
データ変換後にファイルからインポートを行うのが高性能。
（ファイル to ファイルをシーケンシャル・アクセスで処理）

ただし、変換処理に検索 SQL を使用したいケースもある
（通常、処理性能を考慮して Transact-SQL を使用する）。
このような場合、検索 SQL でインデックスが必要になるため、
データのインポート後に統計情報の更新を行っておくと良い。
（これを行わない場合、検索 SQL で不適格なプランが使用され性能が出ない事がある）

また、上記の様にデータ変換にてインデックスを使用する場合、
インポート（インサート）時にはインデックスを定義しないで、
インポート（インサート）完了後にインデックスを定義するようにする。

これは、インデックスの更新も発生するためオーバーヘッドがあるためである。

特に、インデックスに対しシーケンシャルにインサートを実行しないと、
インデックス更新負荷が増加し、性能が大幅に劣化することがある。
（データ件数が多くインデックス サイズも大きい場合に限られる）

移行メモ（体裁）: 元ページの「検索 SQL でインデックス必要があるため」は
「インデックスが必要になるため」の脱字と判断し、補って掲載した。

補足（この節の要点）: ここに書かれている 3 点は、
大量データ移行における鉄則である。

原則 理由
ファイル to ファイルで変換する シーケンシャル アクセスが最も速い（大量データの処理方式1）
投入後にインデックスを作る 1 行ごとの B ツリー更新とページ分割を避けられる
投入後に統計を更新する 古い統計のまま検索すると不適格なプランになる（SQL Server 大量データ処理時の性能問題）

「シーケンシャルにインサートしないとインデックス更新負荷が増加する」のは、
ランダムな順序で挿入するとページ分割が多発するため
（SQL Server のインデックス）。
クラスタ化キーの順にソートしてから投入すると大幅に改善する
（bcp の ORDER ヒント、BULK INSERT の ORDER オプション）。

参考

アップグレードとマイグレーション

自習書

SQL Server 2008 自習書シリーズ No.21 移行とアップグレード

  • ケース1
    ハードウェアの老朽化によるハードウェア リプレイスを想定して、
    リプレイス後の新規サーバーへ SQL Server 2008 をインストールし、
    そこへデータベースや各種の設定（ログイン アカウントやリンク サーバー、
    ジョブ、保守計画、DTS）を移行する手順を説明。

    1. アップグレード アドバイザによる移行チェックを行う
    2. 新規サーバーへの SQL Server 2008 をインストールする
    3. 新規サーバーへの SQL Server 2008 の最新の修正プログラムをインストールする
    4. SQL Server 2000 データベースを新規サーバー（SQL Server 2008）へ移行する
    5. システム データベース関連のオブジェクトを移行する
    6. レジストリに格納されている情報を再設定する
    7. 統計情報（Statistics）を更新する
    8. フルテキスト インデックスを再構築する（フルテキスト インデックスを利用している場合）
    9. 互換性レベルを調整する
    10. DTS パッケージを移行する（DTS パッケージを利用している場合）

  • ケース2
    旧システム環境を残したアップグレードを行う方法を説明。

    1. 現在のマスタ環境を丸ごと新規サーバーへ複製する（ハードウェア リプレイスを行う）
    2. アップグレード アドバイザによる事前チェックを行う
    3. 新規サーバーを SQL Server 2008 へアップグレードする
    4. SQL Server 2008 の Service Pack や修正プログラムをインストールする
    5. レジストリに格納されている情報を再設定する
      （サービスの自動起動やサービス アカウント、認証モード、TCP ポート番号など）
    6. 統計情報（Statistics）を更新する
    7. フルテキスト インデックスを再構築する（フルテキスト インデックスを利用している場合）
    8. 互換性レベルを調整する
    9. DTS パッケージを移行する（SQL Server 2000 の DTS パッケージを利用している場合）
    10. 保守計画を移行する（保守計画を利用している場合）

  • ケース3
    旧システム環境を残さず同一マシンでアップグレードを行う方法を説明。

    1. アップグレード アドバイザによる事前チェックを行う
    2. 新規サーバーを SQL Server 2008 へアップグレード インストールする
    3. SQL Server 2008 の Service Pack や修正プログラムをインストールする
    4. レジストリに格納されている情報を再設定する
      （サービスの自動起動やサービス アカウント、認証モード、TCP ポート番号など）
    5. 統計情報（Statistics）を更新する
    6. フルテキスト インデックスを再構築する（フルテキスト インデックスを利用している場合）
    7. 互換性レベルを調整する
    8. DTS パッケージを移行する（SQL Server 2000 の DTS パッケージを利用している場合）
    9. 保守計画を利用している場合は再作成する

補足（3ケースに共通する手順）: いずれのケースでも
「統計情報の更新」「フルテキスト インデックスの再構築」
「互換性レベルの調整」が含まれている点に注目したい。
これらはアップグレード後に必ず実施すべき作業であり、
省くと性能問題や検索機能の不具合として顕在化する。

SE の雑記

SQL Server 2000 のデータベースを SQL Server 2012 に移行 - SE の雑記
http://engineermemo.wordpress.com/2012/04/18/

  • データベースのバックアップ / リストアを使用した移行
  • データベースのデタッチ / アタッチを使用した移行
  • インポート / エクスポート ウィザードを使用したデータの移行

データベース友の会

第1回 SQL Server 勉強会 データ移行のテクニックいろいろ

  • データベース単位

    1. 完全バックアップ / 復元
    2. デタッチ / アタッチ
    3. SSIS（SQL Server Integration Services）

  • テーブル単位

    1. SSIS
    2. bcp ユーティリティ
    3. sqlcmd ユーティリティ
    4. BULK INSERT
    5. 番外編：MS Access、リンクサーバー

Azure SQL データベースへの移行

Windows Azure SQL データベース (以前の SQL Azure) へのデータベース移行

  • 既存データベースのスクリプト生成による SQL データベースへのデータベース移行
  • Microsoft Sync Framework 2.1 の使用による SQL データベースへのデータベース移行
  • データ層アプリケーションのエクスポート/インポートによる
    SQL データベースへのデータベース移行
  • SQL データベースへのデータの移行
    • SQL Server Integration Services
    • SQL データベース移行ウィザードによる SQL データベースへのデータベース移行
    • bcp ユーティリティ

補足（最新化：現在の Azure 移行）: 上記のツール類は
ほぼすべて世代交代している。現在の標準手段は以下。

移行先 手段
Azure SQL Database DMA または BACPAC（SqlPackage）／Azure Database Migration Service
Azure SQL Managed Instance ネイティブのバックアップ/復元（RESTORE FROM URL）が使える。互換性が高く移行しやすい
SQL Server on Azure VM 通常のバックアップ/復元。オンプレミスと同じ

事前評価は DMA で行い、
「Azure SQL Database では使えない機能」
（SQL Server Agent、リンク サーバー、SSIS、
クロス DB クエリ、MS-DTCなど）を洗い出す。
これらを使っている場合は Managed Instance を選ぶのが定石である。

異種DBMSからの移行

SSMA

Microsoft SQL Server Migration Assistant（SSMA：DB 移行支援ツール）
SSMA は SQL Server 以外の異種 DBMS からの移行を支援します。

  • SSMA for MySQL / Access / Oracle / Sybase / DB2

補足（最新化）: SSMA は現在も提供・更新されており、
DB2 向けも追加されている。
スキーマ変換・データ移行に加え、
ストアド プロシージャ（PL/SQL → T-SQL）のコード変換も行う。
ただし完全自動ではないため、変換後のレビューとテストは必須である。

SSIS

前述のインポート / エクスポート ウィザード（＝SSIS）も利用可能。

その他

Oracle Database から SQL Server への移行に関する情報は以下に纏まっています。

  • Oracle Database から SQL Azure Database への移行 - S-N Ratio (by SATO Naoki)
    http://satonaoki.wordpress.com/2011/01/20/

    • Guide to Migrating from Oracle to SQL Server 2008
    • Oracle から SQL Server 2008 への移行ガイド（上記資料の日本語訳）
    • Migrating Oracle on UNIX to SQL Server on Windows
    • Oracle Database からの移行アセスメント

その他の情報

補足（異種 DBMS 移行で残る作業）: SSMA が自動化できるのは
スキーマとデータ、および定型的なコード変換までである。
以下は必ず人手で確認する必要がある。

論点 内容
分離レベルの違い Oracle（MVCC）→ SQL Server（ロック法）で参照が詰まる。RCSI の有効化を検討（DBMSのロック・分離戦略と同時実行制御）
空文字と NULL Oracle は '' を NULL 扱いする（クロスDB対応）
日付型 Oracle の DATE は時刻を含む
採番 SEQUENCE と IDENTITY の挙動差
階層クエリ CONNECT BY → 再帰 CTE への書き換え
アプリ側 パラメータ記法（: → @）、データプロバイダの差し替え（ADO.NETデータプロバイダ）

特に 1 番目の分離レベルの違いは、
移行後の性能問題として顕在化する最大の要因である。

Tags: 移行, データアクセス, SQL Server

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally