Azure Data Factory または Azure Synapse Analytics を使用して SQL Server との間でデータをコピーおよび変換する

[アーティクル]
06/26/2024

適用対象: Azure Data Factory Azure Synapse Analytics

ヒント

企業向けのオールインワン分析ソリューション、Microsoft Fabric の Data Factory をお試しください。 Microsoft Fabric は、データ移動からデータサイエンス、リアルタイム分析、ビジネスインテリジェンス、レポートまで、あらゆるものをカバーしています。無料で新しい試用版を開始する方法について説明します。

この記事では、Azure Data Factory および Azure Synapse パイプラインで Copy アクティビティを使用して、SQL Server データベースとの間でデータをコピーし、Data Flow を使用して SQL Server データベースのデータを変換する方法について説明します。詳細については、Azure Data Factory または Azure Synapse Analytics の概要記事を参照してください。

サポートされる機能

この SQL Server コネクタは、次の機能でサポートされます。

サポートされる機能	IR
Copy アクティビティ (ソース/シンク)	① ②
マッピングデータフロー (ソース/シンク)	①
Lookup アクティビティ	① ②
GetMetadata アクティビティ	① ②
スクリプト活動	① ②
ストアドプロシージャアクティビティ	① ②

① Azure 統合ランタイム ② セルフホステッド統合ランタイム

コピーアクティビティによってソースまたはシンクとしてサポートされるデータストアの一覧については、サポートされるデータストアに関する記事の表をご覧ください。

具体的には、この SQL Server コネクタは以下をサポートします。

SQL Server バージョン 2005 以降。
SQL または Windows 認証を使用したデータのコピー。
ソースとして、SQL クエリまたはストアドプロシージャを使用してデータを取得する。 SQL Server ソースからの並列コピーを選択することもできます。詳細については、「SQL データベースからの並列コピー」セクションを参照してください。
シンクとして、ソースのスキーマに基づいて、宛先テーブルが存在しない場合はこれを自動的に作成する。テーブルにデータを追加するか、コピー中にカスタムロジックを使用してストアドプロシージャを呼び出す。

SQL Server Express LocalDB はサポートされていません。

重要

NVARCHAR データ型は、非ユニバーサルコーディングがデータに適用されている場合にデータエンコードに影響するため、データソースは NVARCHAR データ型をサポートする必要があります。

前提条件

データストアがオンプレミスネットワーク、Azure 仮想ネットワーク、または Amazon Virtual Private Cloud 内にある場合は、それに接続するようセルフホステッド統合ランタイムを構成する必要があります。

データストアがマネージドクラウドデータサービスである場合は、Azure Integration Runtime を使用できます。ファイアウォール規則で承認されている IP にアクセスが制限されている場合は、Azure Integration Runtime の IP を許可リストに追加できます。

また、Azure Data Factory のマネージド仮想ネットワーク統合ランタイム機能を使用すれば、セルフホステッド統合ランタイムをインストールして構成しなくても、オンプレミスネットワークにアクセスすることができます。

Data Factory によってサポートされるネットワークセキュリティメカニズムやオプションの詳細については、「データアクセス戦略」を参照してください。

はじめに

パイプラインでコピーアクティビティを実行するには、次のいずれかのツールまたは SDK を使用します。

UI を使用して SQL Server のリンクサービスを作成する

次の手順を使用して、Azure portal UI で SQL Server のリンクサービスを作成します。

Azure Data Factory または Synapse ワークスペースの [管理] タブに移動し、[リンクされたサービス] を選択して、[新規] をクリックします。
- Azure Data Factory
- Azure Synapse
SQL を検索し、SQL Server コネクタを選択します。
サービスの詳細を構成し、接続をテストして、新しいリンクサービスを作成します。

コネクタの構成の詳細

以下のセクションでは、SQL Server データベースコネクタに固有の Data Factory および Synapse パイプラインエンティティの定義に使用されるプロパティについて詳しく説明します。

リンクされたサービスプロパティ

SQL Server の推奨バージョンでは、TLS 1.3 がサポートされています。 レガシ バージョンを使用する場合は、このセクションを参照して SQL Server のリンクサービスをアップグレードしてください。プロパティの詳細については、対応するセクションを参照してください。

推奨されるバージョン
レガシバージョン

ヒント

エラーコード "UserErrorFailedToConnectToSqlServer" および "The session limit for the database is XXX and has been reached" (データベースのセッション制限 XXX に達しました) のようなメッセージのエラーが発生する場合は、Pooling=false を接続文字列に追加して、もう一度試してください。

推奨されるバージョン

推奨バージョンを適用すると、SQL Server のリンクサービスで次の汎用プロパティがサポートされます。

プロパティ	内容	必須
type	type プロパティを SqlServer に設定する必要があります。	はい
サーバー	接続先の SQL Server インスタンスの名前またはネットワークアドレス。	はい
database	データベースの名前。	はい
authenticationType	認証に使用される型。使用できる値は、SQL (既定値)、Windows、UserAssignedManagedIdentity (Azure VM 上のSQL Server の場合のみ) です。特定のプロパティと前提条件に関する関連する認証セクションに移動します。	はい
alwaysEncryptedSettings	マネージド ID またはサービスプリンシパルを使用して、SQL サーバーに格納されている機密データを保護する Always Encrypted を有効にするために必要な alwaysencryptedsettings 情報を指定します。詳細については、この表の後にある JSON の例および「Always Encrypted の使用」を参照してください。指定されていない場合、既定の always encrypted 設定は無効になります。	いいえ
encrypt	クライアントとサーバーの間で送信されるすべてのデータに TLS 暗号化が必要かどうかを示します。オプション: 必須 (true の場合、既定値)/省略可能 (false の場合)/strict。	いいえ
trustServerCertificate	信頼を検証するための証明書チェーンをバイパスする間、チャネルが暗号化されるかどうかを示します。	いいえ
hostNameInCertificate	接続のサーバー証明書を検証するときに使用するホスト名。指定しない場合、サーバー名が証明書の検証に使用されます。	いいえ
connectVia	この統合ランタイムは、データストアに接続するために使用されます。詳細については、「前提条件」セクションを参照してください。指定されていない場合は、既定の Azure Integration Runtime が使用されます。	いいえ

その他の接続プロパティについては、次の表を参照してください。

プロパティ	内容	必須
applicationIntent	サーバーに接続するときのアプリケーションのワークロードの種類。使用できる値は `ReadOnly` と `ReadWrite` です。	いいえ
connectTimeout	試行を終了してエラーを生成するまでに、サーバーへの接続を待機する時間 (秒)。	いいえ
connectRetryCount	アイドル状態の接続の失敗を特定した後に試された再接続の数。値は 0 から 255 までの整数である必要があります。	いいえ
connectRetryInterval	アイドル状態の接続エラーを特定した後の、再接続試行の時間間隔 (秒)。 SQL Server のバージョンをアップグレードする値は 1 から 60 までの整数である必要があります。	いいえ
loadBalanceTimeout	接続が破棄される前に接続が接続プールに存在する最小時間 (秒)。	いいえ
commandTimeout	コマンド実行の試行を終了してエラーを生成するまでの既定の待機時間 (秒)。	いいえ
integratedSecurity	使用できる値は `true` または `false` です。 `false` を指定する場合は、接続に userName とパスワードが指定されるかどうかを示します。 `true` を指定する場合は、現在の Windows アカウントの資格情報が認証に使用されるかどうかを示します。	いいえ
failoverPartner	プライマリサーバーがダウンしている場合に接続するパートナーサーバーの名前またはアドレス。	いいえ
maxPoolSize	特定の接続について、接続プールで許可される接続の最大数。	いいえ
minPoolSize	特定の接続について、接続プールで許可される接続の最小数。	いいえ
multipleActiveResultSets	使用できる値は `true` または `false` です。 `true` を指定すると、アプリケーションは複数のアクティブな結果セット (MARS) を維持できます。 `false` を指定すると、アプリケーションは、その接続で他のバッチを実行する前に、1 つのバッチからすべての結果セットを処理または取り消す必要があります。	いいえ
multiSubnetFailover	使用できる値は `true` または `false` です。アプリケーションが異なるサブネット上の AlwaysOn 可用性グループ (AG) に接続する場合、このプロパティを `true` に設定すると、現在アクティブなサーバーの検出と接続が速くなります。	いいえ
packetSize	サーバーのインスタンスとの通信に使用されるネットワークパケットのサイズ (バイト)。	いいえ
プール	使用できる値は `true` または `false` です。 `true` を指定すると、接続がプールされます。 `false` を指定すると、接続が要求されるたびに接続が明示的に開かれます。	いいえ

SQL 認証

SQL 認証を使用するには、前のセクションで説明した汎用プロパティに加えて、次のプロパティを指定します。

プロパティ	内容	必要
userName	サーバーに接続するときに使用するユーザー名。	はい
password	該当するユーザー名のパスワード。安全に保存するには、このフィールドを SecureString としてマークします。また、Azure Key Vault に格納されているシークレットを参照することもできます。	いいえ

例: SQL 認証を使用する

{
    "name": "SqlServerLinkedService",
    "properties": {
        "type": "SqlServer",
        "typeProperties": {
            "server": "<name or network address of the SQL server instance>",
            "database": "<database name>",
            "encrypt": "<encrypt>",
            "trustServerCertificate": false,
            "authenticationType": "SQL",
            "userName": "<user name>",
            "password": {
                "type": "SecureString",
                "value": "<password>"
            }
        },
        "connectVia": {
            "referenceName": "<name of Integration Runtime>",
            "type": "IntegrationRuntimeReference"
        }
    }
}

例: Azure Key Vault 内のパスワードで SQL 認証を使用する

{
    "name": "SqlServerLinkedService",
    "properties": {
        "type": "SqlServer",
        "typeProperties": {
            "server": "<name or network address of the SQL server instance>",
            "database": "<database name>",
            "encrypt": "<encrypt>",
            "trustServerCertificate": false,
            "authenticationType": "SQL",
            "userName": "<user name>",
            "password": { 
                "type": "AzureKeyVaultSecret", 
                "store": { 
                    "referenceName": "<Azure Key Vault linked service name>", 
                    "type": "LinkedServiceReference" 
                }, 
                "secretName": "<secretName>" 
            }
        },
        "connectVia": {
            "referenceName": "<name of Integration Runtime>",
            "type": "IntegrationRuntimeReference"
        }
    }
}

例: Always Encrypted の使用

{
    "name": "SqlServerLinkedService",
    "properties": {
        "type": "SqlServer",
        "typeProperties": {
            "server": "<name or network address of the SQL server instance>",
            "database": "<database name>",
            "encrypt": "<encrypt>",
            "trustServerCertificate": false,
            "authenticationType": "SQL",
            "userName": "<user name>",
            "password": {
                "type": "SecureString",
                "value": "<password>"
            }
        },
        "alwaysEncryptedSettings": {
            "alwaysEncryptedAkvAuthType": "ServicePrincipal",
            "servicePrincipalId": "<service principal id>",
            "servicePrincipalKey": {
                "type": "SecureString",
                "value": "<service principal key>"
            }
        },
        "connectVia": {
            "referenceName": "<name of Integration Runtime>",
            "type": "IntegrationRuntimeReference"
        }
    }
}

Windows 認証

前のセクションで説明した汎用的なプロパティに加えて、Windows 認証を使用するには、次のプロパティを指定します。

プロパティ	内容	必要
userName	ユーザー名を指定します。例: domainname\username。	はい
password	ユーザー名に指定したユーザーアカウントのパスワードを指定します。安全に保存するには、このフィールドを SecureString としてマークします。また、Azure Key Vault に格納されているシークレットを参照することもできます。	はい

Note

データフローでは、Windows 認証はサポートされません。

例: Windows 認証を使用する

{
    "name": "SqlServerLinkedService",
    "properties": {
        "type": "SqlServer",
        "typeProperties": {
            "server": "<name or network address of the SQL server instance>",
            "database": "<database name>",
            "encrypt": "<encrypt>",
            "trustServerCertificate": false,
            "authenticationType": "Windows",
            "userName": "<domain\\username>",
            "password": {
                "type": "SecureString",
                "value": "<password>"
            }
        },
        "connectVia": {
            "referenceName": "<name of Integration Runtime>",
            "type": "IntegrationRuntimeReference"
        }
    }
}

例: Azure Key Vault 内のパスワードで Windows 認証を使用する

{
    "name": "SqlServerLinkedService",
    "properties": {
        "annotations": [],
        "type": "SqlServer",
        "typeProperties": {
            "server": "<name or network address of the SQL server instance>",
            "database": "<database name>",
            "encrypt": "<encrypt>",
            "trustServerCertificate": false,
            "authenticationType": "Windows",
            "userName": "<domain\\username>",
            "password": {
                "type": "AzureKeyVaultSecret",
                "store": {
                    "referenceName": "<Azure Key Vault linked service name>",
                    "type": "LinkedServiceReference"
                },
                "secretName": "<secretName>"
            }
        },
        "connectVia": {
            "referenceName": "<name of Integration Runtime>",
            "type": "IntegrationRuntimeReference"
        }
    }
}

ユーザー割り当てマネージド ID 認証

Note

ユーザー割り当てマネージド ID 認証は、Azure VM 上の SQL Server にのみ適用されます。

データファクトリまたは Synapse ワークスペースは、Azure の他のリソースに対して認証するときにそのサービスを表す、ユーザー割り当てマネージド ID に関連付けることができます。このマネージド ID は、Azure VM 上の SQL Server の認証に使用できます。指定されたファクトリまたは Synapse ワークスペースでは、この ID を使用してデータベースにアクセスし、データベースとの間でデータをコピーできます。

前のセクションで説明した汎用的なプロパティに加えて、ユーザー割り当てマネージド ID 認証を使用するには、次のプロパティを指定します。

プロパティ	内容	必須
資格情報	ユーザー割り当てマネージド ID を資格情報オブジェクトとして指定します。	はい

以下の手順に従う必要もあります。

ユーザー割り当てマネージド ID にアクセス許可を付与します。
Azure VM 上の SQL Server に対する Microsoft Entra 認証を有効にします。
ユーザー割り当てマネージド ID の包含データベースユーザーを作成します。 SQL Server Management Studio のようなツールと、少なくとも ALTER ANY USER アクセス許可を持つ Microsoft Entra ID を使用して、データをコピーするデータベースに接続します。次の T-SQL を実行します。
```
CREATE USER [your_resource_name] FROM EXTERNAL PROVIDER;
```
1 つ以上のユーザー割り当てマネージド ID を作成し、通常の SQL ユーザーなどと同様に、ユーザー割り当てマネージド ID に必要なアクセス許可を付与します。次のコードを実行します。詳細については、こちらのドキュメントを参照してください。
```
ALTER ROLE [role name] ADD MEMBER [your_resource_name];
```
1 つ以上のユーザー割り当てマネージド ID をデータファクトリに割り当てて、ユーザー割り当てマネージド ID ごとに資格情報を作成します。
SQL Server のリンクサービスを構成します。

例

{
    "name": "SqlServerLinkedService",
    "properties": {
        "type": "SqlServer",
        "typeProperties": {
            "server": "<name or network address of the SQL server instance>",
            "database": "<database name>",
            "encrypt": "<encrypt>",
            "trustServerCertificate": false,
            "authenticationType": "UserAssignedManagedIdentity",
            "credential": {
                "referenceName": "credential1",
                "type": "CredentialReference"
            }
        },
        "connectVia": {
            "referenceName": "<name of Integration Runtime>",
            "type": "IntegrationRuntimeReference"
        }
    }
}

レガシバージョン

レガシ バージョンを適用すると、SQL Server のリンクサービスで次の汎用プロパティがサポートされます。

プロパティ	内容	必須
type	type プロパティを SqlServer に設定する必要があります。	はい
alwaysEncryptedSettings	マネージド ID またはサービスプリンシパルを使用して、SQL サーバーに格納されている機密データを保護する Always Encrypted を有効にするために必要な alwaysencryptedsettings 情報を指定します。詳しくは、「Always Encrypted の使用」セクションをご覧ください。指定されていない場合、既定の always encrypted 設定は無効になります。	いいえ
connectVia	この統合ランタイムは、データストアに接続するために使用されます。詳細については、「前提条件」セクションを参照してください。指定されていない場合は、既定の Azure Integration Runtime が使用されます。	いいえ

この SQL Server コネクタでは、次の認証の種類がサポートされています。詳細については、対応するセクションをご覧ください。

レガシバージョンの SQL 認証
レガシバージョンの Windows 認証

レガシバージョンの SQL 認証

SQL 認証を使用するには、前のセクションで説明した汎用プロパティに加えて、次のプロパティを指定します。

プロパティ	内容	必須
connectionString	SQL Server データベースに接続するために必要な connectionString 情報を指定します。ユーザー名としてログイン名を指定し、接続するデータベースがこのログインにマップされていることを確認します。	はい
password	パスワードを Azure Key Vault に格納する場合、接続文字列から `password` 構成をプルします。詳細については、「Azure Key Vault への資格情報の格納」を参照してください。	いいえ

レガシバージョンの Windows 認証

前のセクションで説明した汎用的なプロパティに加えて、Windows 認証を使用するには、次のプロパティを指定します。

プロパティ	内容	必須
connectionString	SQL Server データベースに接続するために必要な connectionString 情報を指定します。	はい
userName	ユーザー名を指定します。例: domainname\username。	はい
password	ユーザー名に指定したユーザーアカウントのパスワードを指定します。安全に保存するには、このフィールドを SecureString としてマークします。また、Azure Key Vault に格納されているシークレットを参照することもできます。	はい

データセットのプロパティ

データセットを定義するために使用できるセクションとプロパティの完全な一覧については、データセットに関する記事をご覧ください。このセクションでは、SQL Server データセットでサポートされるプロパティの一覧を示します。

SQL Server データベースをコピー元またはコピー先にしたデータコピーについては、次のプロパティがサポートされています。

プロパティ	内容	必須
type	データセットの type プロパティは SqlServerTable に設定する必要があります。	はい
schema	スキーマの名前。	ソースの場合はいいえ、シンクの場合ははい
table	テーブル/ビューの名前。	ソースの場合はいいえ、シンクの場合ははい
tableName	スキーマがあるテーブル/ビューの名前。このプロパティは下位互換性のためにサポートされています。新しいワークロードでは、`schema` と `table` を使用します。	ソースの場合はいいえ、シンクの場合ははい

例

{
    "name": "SQLServerDataset",
    "properties":
    {
        "type": "SqlServerTable",
        "linkedServiceName": {
            "referenceName": "<SQL Server linked service name>",
            "type": "LinkedServiceReference"
        },
        "schema": [ < physical schema, optional, retrievable during authoring > ],
        "typeProperties": {
            "schema": "<schema_name>",
            "table": "<table_name>"
        }
    }
}

コピーアクティビティのプロパティ

アクティビティの定義に利用できるセクションとプロパティの完全な一覧については、パイプラインに関する記事を参照してください。このセクションでは、SQL Server のソースおよびシンクでサポートされるプロパティの一覧を示します。

ソースとしての SQL Server

ヒント

データパーティション分割を使用して、SQL Server からデータを効率的に読み込む方法の詳細については、SQL データベースからの並列コピーに関するセクションを参照してください。

SQL Server からデータをコピーするには、コピーアクティビティのソースの種類を SqlSource に設定します。コピーアクティビティの source セクションでは、次のプロパティがサポートされます。

プロパティ	内容	必須
type	コピーアクティビティのソースの type プロパティを SqlSource に設定する必要があります。	はい
sqlReaderQuery	カスタム SQL クエリを使用してデータを読み取ります。たとえば `select * from MyTable` です。	いいえ
sqlReaderStoredProcedureName	このプロパティは、ソーステーブルからデータを読み取るストアドプロシージャの名前です。最後の SQL ステートメントはストアドプロシージャの SELECT ステートメントにする必要があります。	いいえ
storedProcedureParameters	これらのパラメーターは、ストアドプロシージャ用です。使用可能な値は、名前または値のペアです。パラメーターの名前とその大文字と小文字は、ストアドプロシージャのパラメーターの名前とその大文字小文字と一致する必要があります。	いいえ
isolationLevel	SQL ソースのトランザクションロック動作を指定します。使用できる値は、次のとおりです。ReadCommitted、ReadUncommitted、RepeatableRead、Serializable、Snapshot。指定しなかった場合は、データベースの既定の分離レベルが使用されます。詳細についてはこちらのドキュメントをご覧ください。	いいえ
partitionOptions	SQL Server からデータを読み込むときに使用するデータパーティション分割オプションを指定します。使用できる値は、以下のとおりです。None (既定値)、PhysicalPartitionsOfTable、および DynamicRange。パーティションオプションが有効になっている (つまり、`None` ではない) 場合、SQL Server から同時にデータを読み込む並列度は、コピーアクティビティの `parallelCopies` の設定によって制御されます。	いいえ
partitionSettings	データパーティション分割の設定のグループを指定します。パーティションオプションが `None` でない場合に適用されます。	いいえ
`partitionSettings` の下:
partitionColumnName	並列コピーの範囲パーティション分割で使用される整数型または日付/日時型 (`int`、`smallint`、`bigint`、`date`、`smalldatetime`、`datetime`、`datetime2`、または `datetimeoffset`) のソース列の名前を指定します。指定されない場合は、テーブルのインデックスまたは主キーが自動検出され、パーティション列として使用されます。パーティションオプションが `DynamicRange` である場合に適用されます。クエリを使用してソースデータを取得する場合は、WHERE 句で `?DfDynamicRangePartitionCondition` をフックします。例については、「SQL データベースからの並列コピー」セクションを参照してください。	いいえ
partitionUpperBound	パーティション範囲の分割のための、パーティション列の最大値。この値は、テーブル内の行のフィルター処理用ではなく、パーティションのストライドを決定するために使用されます。テーブルまたはクエリ結果に含まれるすべての行がパーティション分割され、コピーされます。指定されていない場合は、コピーアクティビティによって値が自動検出されます。パーティションオプションが `DynamicRange` である場合に適用されます。例については、「SQL データベースからの並列コピー」セクションを参照してください。	いいえ
partitionLowerBound	パーティション範囲の分割のための、パーティション列の最小値。この値は、テーブル内の行のフィルター処理用ではなく、パーティションのストライドを決定するために使用されます。テーブルまたはクエリ結果に含まれるすべての行がパーティション分割され、コピーされます。指定されていない場合は、コピーアクティビティによって値が自動検出されます。パーティションオプションが `DynamicRange` である場合に適用されます。例については、「SQL データベースからの並列コピー」セクションを参照してください。	いいえ

以下の点に注意してください。

SqlSource に sqlReaderQuery が指定されている場合、コピーアクティビティでは、データを取得するために SQL Server ソースに対してこのクエリを実行します。 sqlReaderStoredProcedureName と storedProcedureParameters を指定して、ストアドプロシージャを指定することもできます (ストアドプロシージャでパラメーターを使用する場合)。
ソースのストアドプロシージャを使用してデータを取得する場合、異なるパラメーター値が渡されたときに別のスキーマを返すようにストアドプロシージャが設計されていると、UI からスキーマをインポートするときや、テーブルの自動作成を使用して SQL データベースにデータをコピーするときに、エラーが発生したり、予期しない結果になったりする可能性があります。

例:SQL クエリを使用する

"activities":[
    {
        "name": "CopyFromSQLServer",
        "type": "Copy",
        "inputs": [
            {
                "referenceName": "<SQL Server input dataset name>",
                "type": "DatasetReference"
            }
        ],
        "outputs": [
            {
                "referenceName": "<output dataset name>",
                "type": "DatasetReference"
            }
        ],
        "typeProperties": {
            "source": {
                "type": "SqlSource",
                "sqlReaderQuery": "SELECT * FROM MyTable"
            },
            "sink": {
                "type": "<sink type>"
            }
        }
    }
]

例:ストアドプロシージャの使用

"activities":[
    {
        "name": "CopyFromSQLServer",
        "type": "Copy",
        "inputs": [
            {
                "referenceName": "<SQL Server input dataset name>",
                "type": "DatasetReference"
            }
        ],
        "outputs": [
            {
                "referenceName": "<output dataset name>",
                "type": "DatasetReference"
            }
        ],
        "typeProperties": {
            "source": {
                "type": "SqlSource",
                "sqlReaderStoredProcedureName": "CopyTestSrcStoredProcedureWithParameters",
                "storedProcedureParameters": {
                    "stringData": { "value": "str3" },
                    "identifier": { "value": "$$Text.Format('{0:yyyy}', <datetime parameter>)", "type": "Int"}
                }
            },
            "sink": {
                "type": "<sink type>"
            }
        }
    }
]

ストアドプロシージャの定義

CREATE PROCEDURE CopyTestSrcStoredProcedureWithParameters
(
    @stringData varchar(20),
    @identifier int
)
AS
SET NOCOUNT ON;
BEGIN
    select *
    from dbo.UnitTestSrcTable
    where dbo.UnitTestSrcTable.stringData != stringData
    and dbo.UnitTestSrcTable.identifier != identifier
END
GO

シンクとしての SQL Server

ヒント

サポートされる書き込み動作、構成、およびベストプラクティスの詳細については、「SQL Server にデータを読み込むときのベストプラクティス」を参照してください。

SQL Server にデータをコピーするには、コピーアクティビティのシンクの種類を SqlSink に設定します。コピーアクティビティの sink セクションでは、次のプロパティがサポートされます。

プロパティ	内容	必須
type	コピーアクティビティのシンクの type プロパティは、SqlSink に設定する必要があります。	はい
preCopyScript	このプロパティでは、コピーアクティビティで SQL Server にデータを書き込む前に実行する SQL クエリを指定します。これは、コピー実行ごとに 1 回だけ呼び出されます。このプロパティを使用して、事前に読み込まれたデータをクリーンアップできます。	いいえ
tableOption	ソースのスキーマに基づいて自動的にシンクテーブルを作成するかどうかを指定します (存在しない場合)。シンクでストアドプロシージャが指定されている場合、テーブルの自動作成はサポートされません。使用できる値は `none` (既定値)、`autoCreate` です。	いいえ
sqlWriterStoredProcedureName	ターゲットテーブルにソースデータを適用する方法を定義しているストアドプロシージャの名前です。このストアドプロシージャはバッチごとに呼び出されます。 1 回だけ実行され、ソースデータとは関係がない操作 (削除/切り詰めなど) の場合は、`preCopyScript` プロパティを使用します。例については、「SQL シンクからのストアドプロシージャの呼び出し」を参照してください。	いいえ
storedProcedureTableTypeParameterName	ストアドプロシージャで指定されたテーブル型のパラメーター名。	いいえ
sqlWriterTableType	ストアドプロシージャで使用するテーブル型の名前。コピーアクティビティでは、このテーブル型の一時テーブルでデータを移動できます。その後、ストアドプロシージャのコードにより、コピーされたデータを既存のデータと結合できます。	いいえ
storedProcedureParameters	ストアドプロシージャのパラメーター。使用可能な値は、名前と値のペアです。パラメーターの名前とその大文字と小文字は、ストアドプロシージャのパラメーターの名前とその大文字小文字と一致する必要があります。	いいえ
writeBatchSize	SQL テーブルに挿入する "バッチあたりの" 行数。使用可能な値は、行数の場合整数です。既定では行のサイズに基づいて、サービスにより適切なバッチサイズが動的に決定されます。	いいえ
writeBatchTimeout	タイムアウトする前に挿入、アップサート、およびストアドプロシージャ操作が完了するまでの待機時間です。使用可能な値は期間に対する値です。たとえば "00:30:00" (30 分) を指定できます。値を指定しなかった場合、タイムアウトの既定値は "00:30:00" です。	いいえ
maxConcurrentConnections	アクティビティの実行中にデータストアに対して確立されたコンカレント接続数の上限。コンカレント接続を制限する場合にのみ、値を指定します。	なし
WriteBehavior	SQL Server Database にデータを読み込むコピーアクティビティの書き込み動作を指定します。使用できる値は、Insert と Upsert です。既定では、サービスは Insert を使用してデータを読み込みます。	いいえ
upsertSettings	書き込み動作の設定のグループを指定します。 WriteBehavior オプションが `Upsert` である場合に適用します。	いいえ
`upsertSettings` の下:
useTempDB	アップサートの中間テーブルとしてグローバル一時テーブルと物理テーブルのいずれを使用するかを指定します。既定では、サービスはグローバル一時テーブルを中間テーブルとして使用します。値は `true` です。	No
interimSchemaName	物理テーブルを使う場合は、中間テーブルを作成するために中間スキーマを指定します。注: ユーザーは、テーブルの作成と削除を行うアクセス許可を持っている必要があります。既定では、中間テーブルはシンクテーブルと同じスキーマを共有します。 useTempDB オプションが `False` である場合に適用します。	No
キー	行を一意に識別するための列名を指定します。 1 つのキーまたは一連のキーのいずれかを使用できます。指定しない場合は、主キーが使用されます。	いいえ

例 1: データを追加する

"activities":[
    {
        "name": "CopyToSQLServer",
        "type": "Copy",
        "inputs": [
            {
                "referenceName": "<input dataset name>",
                "type": "DatasetReference"
            }
        ],
        "outputs": [
            {
                "referenceName": "<SQL Server output dataset name>",
                "type": "DatasetReference"
            }
        ],
        "typeProperties": {
            "source": {
                "type": "<source type>"
            },
            "sink": {
                "type": "SqlSink",
                "tableOption": "autoCreate",
                "writeBatchSize": 100000
            }
        }
    }
]

例 2: コピー中にストアドプロシージャを呼び出す

詳しくは、「SQL シンクからのストアドプロシージャの呼び出し」をご覧ください。

"activities":[
    {
        "name": "CopyToSQLServer",
        "type": "Copy",
        "inputs": [
            {
                "referenceName": "<input dataset name>",
                "type": "DatasetReference"
            }
        ],
        "outputs": [
            {
                "referenceName": "<SQL Server output dataset name>",
                "type": "DatasetReference"
            }
        ],
        "typeProperties": {
            "source": {
                "type": "<source type>"
            },
            "sink": {
                "type": "SqlSink",
                "sqlWriterStoredProcedureName": "CopyTestStoredProcedureWithParameters",
                "storedProcedureTableTypeParameterName": "MyTable",
                "sqlWriterTableType": "MyTableType",
                "storedProcedureParameters": {
                    "identifier": { "value": "1", "type": "Int" },
                    "stringData": { "value": "str1" }
                }
            }
        }
    }
]

例 3: データをアップサートする

"activities":[
    {
        "name": "CopyToSQLServer",
        "type": "Copy",
        "inputs": [
            {
                "referenceName": "<input dataset name>",
                "type": "DatasetReference"
            }
        ],
        "outputs": [
            {
                "referenceName": "<SQL Server output dataset name>",
                "type": "DatasetReference"
            }
        ],
        "typeProperties": {
            "source": {
                "type": "<source type>"
            },
            "sink": {
                "type": "SqlSink",
                "tableOption": "autoCreate",
                "writeBehavior": "upsert",
                "upsertSettings": {
                    "useTempDB": true,
                    "keys": [
                        "<column name>"
                    ]
                },
            }
        }
    }
]

SQL データベースからの並列コピー

SQL Server コネクタでは、コピーアクティビティの際に、データを並列でコピーするための組み込みのデータパーティション分割が提供されます。データパーティション分割オプションは、コピーアクティビティの [ソース] タブにあります。

パーティションのオプションのスクリーンショット

パーティション分割でのコピーを有効にすると、コピーアクティビティによってユーザーの SQL Server ソースに対して並列クエリが実行され、パーティションごとにデータが読み込まれます。並列度は、コピーアクティビティの parallelCopies 設定によって制御されます。たとえば、parallelCopies を 4 に設定した場合、指定したパーティションオプションと設定に基づいて 4 つのクエリが同時に生成され、実行されます。各クエリでは、SQL Server からデータの一部を取得します。

特に、自分の SQL Server から大量のデータを読み込む場合は、データのパーティション分割を使用した並列コピーを有効にすることをお勧めします。さまざまなシナリオの推奨構成を以下に示します。ファイルベースのデータストアにデータをコピーする場合は、複数のファイルとしてフォルダーに書き込む (フォルダー名のみを指定する) ことをお勧めします。この場合、1 つのファイルに書き込むよりもパフォーマンスが優れています。

シナリオ	推奨設定
物理パーティションに分割された大きなテーブル全体から読み込む。	パーティションオプション: テーブルの物理パーティション。実行中に、サービスによって物理パーティションが自動的に検出され、パーティションごとにデータがコピーされます。テーブルに物理パーティションがあるかどうかを確認するには、こちらのクエリを参照してください。
物理パーティションがなく、データパーティション分割用の整数または日時の列がある大きなテーブル全体から読み込む。	パーティションオプション: 動的範囲パーティション。パーティション列 (省略可能):データのパーティション分割に使用される列を指定します。指定されていない場合は、主キー列が使用されます。パーティションの上限とパーティションの下限 (省略可能):パーティションのストライドを決定する場合に指定します。これは、テーブル内の行のフィルター処理用ではなく、テーブル内のすべての行がパーティション分割されてコピーされます。指定されていない場合は、Copy アクティビティによって値が自動検出されます。最小値と最大値によっては時間がかかることがあります。上限と下限を指定することをお勧めします。たとえば、パーティション列「ID」の値の範囲が 1 ～ 100 で、下限を 20 に、上限を 80 に設定し、並列コピーを 4 にした場合、サービスによって 4 つのパーティションでデータが取得されます。ID の範囲は、それぞれ、20 以下、21 ～ 50、51 ～ 80、81 以上となります。
物理パーティションがなく、データパーティション分割用の整数列または日付/日時列がある大量のデータを、カスタムクエリを使用して読み込む。	パーティションオプション: 動的範囲パーティション。クエリ: `SELECT * FROM <TableName> WHERE ?DfDynamicRangePartitionCondition AND <your_additional_where_clause>` パーティション列: データのパーティション分割に使用される列を指定します。パーティションの上限とパーティションの下限 (省略可能):パーティションのストライドを決定する場合に指定します。これは、テーブル内の行のフィルター処理用ではなく、クエリ結果のすべての行がパーティション分割されてコピーされます。指定されていない場合は、Copy アクティビティによって値が自動検出されます。たとえば、パーティション列「ID」の値の範囲が 1 ～ 100 で、下限を 20 に、上限を 80 に設定し、並列コピーを 4 にした場合、サービスによって 4 つのパーティションでデータが取得されます。ID の範囲は、それぞれ、20 以下、21 ～ 50、51 ～ 80、81 以上となります。さまざまなシナリオのサンプルクエリを次に示します。 1.テーブル全体に対してクエリを実行する: `SELECT * FROM <TableName> WHERE ?DfDynamicRangePartitionCondition` 2.列の選択と追加の where 句フィルターが含まれるテーブルからのクエリ: `SELECT <column_list> FROM <TableName> WHERE ?DfDynamicRangePartitionCondition AND <your_additional_where_clause>` 3.サブクエリを使用したクエリ: `SELECT <column_list> FROM (<your_sub_query>) AS T WHERE ?DfDynamicRangePartitionCondition AND <your_additional_where_clause>` 4.サブクエリにパーティションがあるクエリ: `SELECT <column_list> FROM (SELECT <your_sub_query_column_list> FROM <TableName> WHERE ?DfDynamicRangePartitionCondition) AS T`

パーティションオプションを使用してデータを読み込む場合のベストプラクティス:

データスキューを回避するため、パーティション列 (主キーや一意キーなど) には特徴のある列を選択します。
テーブルに組み込みパーティションがある場合は、パフォーマンスを向上させるためにパーティションオプションとして "テーブルの物理パーティション" を使用します。
Azure Integration Runtime を使用してデータをコピーする場合は、より大きな (4 より大きい) "データ統合単位 (DIU)" (>4) を設定すると、より多くのコンピューティングリソースを利用できます。そこで、該当するシナリオを確認してください。
パーティション数は、"コピーの並列処理の次数" によって制御されます。この数値を大きくしすぎるとパフォーマンスが低下するため、この数値は、(DIU またはセルフホステッド IR ノードの数) x (2 から 4) に設定することをお勧めします。

例: 複数の物理パーティションがある大きなテーブル全体から読み込む

"source": {
    "type": "SqlSource",
    "partitionOption": "PhysicalPartitionsOfTable"
}

例: 動的範囲パーティションを使用してクエリを実行する

"source": {
    "type": "SqlSource",
    "query": "SELECT * FROM <TableName> WHERE ?DfDynamicRangePartitionCondition AND <your_additional_where_clause>",
    "partitionOption": "DynamicRange",
    "partitionSettings": {
        "partitionColumnName": "<partition_column_name>",
        "partitionUpperBound": "<upper_value_of_partition_column (optional) to decide the partition stride, not as data filter>",
        "partitionLowerBound": "<lower_value_of_partition_column (optional) to decide the partition stride, not as data filter>"
    }
}

物理パーティションを確認するためのサンプルクエリ

SELECT DISTINCT s.name AS SchemaName, t.name AS TableName, pf.name AS PartitionFunctionName, c.name AS ColumnName, iif(pf.name is null, 'no', 'yes') AS HasPartition
FROM sys.tables AS t
LEFT JOIN sys.objects AS o ON t.object_id = o.object_id
LEFT JOIN sys.schemas AS s ON o.schema_id = s.schema_id
LEFT JOIN sys.indexes AS i ON t.object_id = i.object_id 
LEFT JOIN sys.index_columns AS ic ON ic.partition_ordinal > 0 AND ic.index_id = i.index_id AND ic.object_id = t.object_id 
LEFT JOIN sys.columns AS c ON c.object_id = ic.object_id AND c.column_id = ic.column_id 
LEFT JOIN sys.partition_schemes ps ON i.data_space_id = ps.data_space_id 
LEFT JOIN sys.partition_functions pf ON pf.function_id = ps.function_id 
WHERE s.name='[your schema]' AND t.name = '[your table name]'

テーブルに物理パーティションがある場合、次のように、"HasPartition" は "yes" と表示されます。

SQL クエリの結果

SQL Server にデータを読み込むときのベストプラクティス

SQL Server にデータをコピーするときは、さまざまな書き込み動作が必要になることがあります。

追加: ソースデータには新しいレコードのみが含まれている。
アップサート: ソースデータには挿入と更新の両方が含まれている。
上書き: 毎回ディメンションテーブル全体を再度読み込みたい。
カスタムロジックでの書き込み: 宛先テーブルへの最終挿入の前に追加の処理が必要である。

構成方法とベストプラクティスについては、対応するセクションを参照してください。

データを追加する

データの追加は、この SQL Server シンクコネクタの既定の動作です。サービスでは、テーブルに効率的に書き込むために一括挿入が実行されます。コピーアクティビティで、それに応じてソースとシンクを構成できます。

データをアップサートする

Copy アクティビティは、データベースの一時テーブルにデータを読み込み、キーが存在する場合はシンクテーブルのデータを更新し、そうでない場合は新しいデータを挿入する処理をネイティブにサポートするようになりました。コピーアクティビティのアップサート設定の詳細については、「シンクとしての SQL Server」を参照してください。

テーブル全体を上書きする

コピーアクティビティシンクで preCopyScript プロパティを構成できます。この場合、実行される Copy アクティビティごとに、サービスで最初にスクリプトが実行されます。次に、コピーが実行されてデータが挿入されます。たとえば、テーブル全体を最新のデータで上書きするには、ソースから新しいデータを一括で読み込む前に、すべてのレコードを最初に削除するスクリプトを指定します。

カスタムロジックでデータを書き込む

カスタムロジックでデータを書き込む手順は、「データをアップサートする」セクションで説明されている手順に似ています。宛先テーブルへのソースデータの最終挿入の前に追加の処理を適用する必要がある場合は、ステージングテーブルに読み込んだ後、ストアドプロシージャアクティビティを呼び出すか、コピーアクティビティのシンクのストアドプロシージャを呼び出してデータを適用することができます。

SQL シンクからのストアドプロシージャの呼び出し

SQL Server データベースにデータをコピーするときに、ユーザーが指定したストアドプロシージャを構成し、ソーステーブルの各バッチに関する追加のパラメーターと共に呼び出すこともできます。ストアドプロシージャ機能はテーブル値パラメーターを利用しています。このサービスでは、ストアドプロシージャがそれ自体のトランザクションでラップされることにご留意ください。つまり、ストアドプロシージャ内で作成されたトランザクションはすべて入れ子になり、例外処理を意味することがあります。

組み込みのコピーメカニズムでは目的を達成できない場合は、ストアドプロシージャを使用できます。 1 つの例は、宛先テーブルへのソースデータの最終挿入の前に追加の処理を適用する場合です。その他の処理の例をいくつか挙げると、列のマージ、追加の値の検索、複数のテーブルへの挿入があります。

次の例では、SQL Server データベース内のテーブルに upsert を行うストアドプロシージャを使用する方法を示します。入力データとシンクの Marketing テーブルには、それぞれ 3 つの列 (ProfileID、State、Category) があるものとします。 ProfileID 列に基づいてアップサートを行い、"ProductA" という特定のカテゴリに対してのみ適用します。

データベースで、sqlWriterTableType と同じ名前のテーブル型を定義します。テーブル型のスキーマは、入力データから返されるスキーマと同じです。
```
CREATE TYPE [dbo].[MarketingType] AS TABLE(
    [ProfileID] [varchar](256) NOT NULL,
    [State] [varchar](256) NOT NULL,
    [Category] [varchar](256) NOT NULL
)
```

データベース内で、sqlWriterStoredProcedureName と同じ名前のストアドプロシージャを定義します。これによって指定したソースの入力データが処理され、出力テーブルにマージされます。ストアドプロシージャ内のテーブル型のパラメーター名は、データセットで定義されている tableName と同じです。

CREATE PROCEDURE spOverwriteMarketing @Marketing [dbo].[MarketingType] READONLY, @category varchar(256)
AS
BEGIN
MERGE [dbo].[Marketing] AS target
USING @Marketing AS source
ON (target.ProfileID = source.ProfileID and target.Category = @category)
WHEN MATCHED THEN
    UPDATE SET State = source.State
WHEN NOT MATCHED THEN
    INSERT (ProfileID, State, Category)
    VALUES (source.ProfileID, source.State, source.Category);
END

コピーアクティビティの SQL シンク セクションを次のように定義します。

"sink": {
    "type": "SqlSink",
    "sqlWriterStoredProcedureName": "spOverwriteMarketing",
    "storedProcedureTableTypeParameterName": "Marketing",
    "sqlWriterTableType": "MarketingType",
    "storedProcedureParameters": {
        "category": {
            "value": "ProductA"
        }
    }
}

Mapping Data Flow のプロパティ

マッピングデータフローでデータを変換する場合、SQL Server Database からテーブルの読み取りと書き込みを実行できます。詳細については、マッピングデータフローのソース変換とシンク変換に関する記事をご覧ください。

Note

オンプレミスの SQL Server にアクセスするには、プライベートエンドポイントを使用して、Azure Data Factory または Synapse ワークスペースのマネージド仮想ネットワークを使用する必要があります。詳細な手順については、このチュートリアルを参照してください。

ソース変換

次の表に、SQL Server ソースでサポートされるプロパティの一覧を示します。これらのプロパティは、 [ソースオプション] タブで編集できます。

名前	説明	必須	使用できる値	データフロースクリプトのプロパティ
テーブル	[テーブル] を入力として選択した場合、データセットで指定されたテーブルからすべてのデータがデータフローによってフェッチされます。	いいえ	-	-
クエリ	[クエリ] を入力として選択した場合は、ソースからデータをフェッチする SQL クエリを指定します。これにより、データセットで指定したテーブルがオーバーライドされます。テストまたはルックアップ対象の行を減らすうえで、クエリの使用は有効な手段です。 Order By 句はサポートされていませんが、完全な SELECT FROM ステートメントを設定することができます。ユーザー定義のテーブル関数を使用することもできます。 *select from udfGetData()** は、データフローで使用できるテーブルを返す SQL の UDF です。クエリの例: `Select * from MyTable where customerId > 1000 and customerId < 2000`	いいえ	String	query
バッチサイズ	大量データを読み取りにまとめるバッチサイズを指定します。	いいえ	Integer	batchSize
Isolation Level	次のいずれかの分離レベルを選択します。 - コミットされたものを読み取り - コミットされていないものを読み取り (既定値) - 反復可能読み取り - シリアル化可能 - なし (分離レベルを無視)	いいえ	READ_COMMITTED READ_UNCOMMITTED REPEATABLE_READ SERIALIZABLE NONE	isolationLevel
増分抽出を有効にする	このオプションを使用して、パイプラインが前回実行されてから変更された行のみを処理するように ADF に指示します。	いいえ	-	-
増分日付列	増分抽出機能を使用する場合は、ソーステーブルのウォーターマークとして使用する日時列を選択する必要があります。	いいえ	-	-
ネイティブ変更データキャプチャを有効にする (プレビュー)	このオプションを使用して、パイプラインが前回実行されてから SQL 変更データキャプチャテクノロジによってキャプチャされた差分データのみを処理するように ADF に指示します。このオプションを使用すると、行の挿入、更新、削除を含む差分データが自動的に読み込まれ、増分日付列は必要ありません。 ADF でこのオプションを使用する前に、SQL Server で変更データキャプチャを有効にする必要があります。 ADF のこのオプションの詳細については、「ネイティブ変更データキャプチャ」を参照してください。	いいえ	-	-
最初から読み取りを開始する	増分抽出でこのオプションを設定すると、増分抽出が有効になっているパイプラインの最初の実行時にすべての行を読み取るよう ADF に指示します。	いいえ	-	-

ヒント

SQL の共通テーブル式 (CTE) は、マッピングデータフローの Query モードではサポートされません。このモードを使用する前提条件は、クエリを SQL クエリの FROM 句で使用することはできるが CTE では使用できないという条件であるためです。 CTE を使用するには、次のクエリを使用してストアドプロシージャを作成する必要があります。

CREATE PROC CTESP @query nvarchar(max)
AS
BEGIN
EXECUTE sp_executesql @query;
END

次に、マッピングデータフローのソース変換でストアドプロシージャ モードを使用し、with CTE as (select 'test' as a) select * from CTE の例のように @query を設定します。その後、期待どおりに CTE を使用できます。

SQL Server ソーススクリプトの例

ソースの種類として SQL Server を使用すると、関連付けられているデータフロースクリプトは次のようになります。

source(allowSchemaDrift: true,
    validateSchema: false,
    isolationLevel: 'READ_UNCOMMITTED',
    query: 'select * from MYTABLE',
    format: 'query') ~> SQLSource

シンク変換

次の表に、SQL Server シンクでサポートされるプロパティの一覧を示します。これらのプロパティは、 [シンクオプション] タブで編集できます。

名前	説明	必須	使用できる値	データフロースクリプトのプロパティ
更新方法	対象となるデータベースに対して許可される操作を指定します。既定では、挿入のみが許可されます。行を更新、アップサート、または削除するには、それらのアクションに対して行をタグ付けするために行の変更変換が必要になります。	はい	`true` または `false`	deletable insertable updateable upsertable
[キー列]	更新、upsert、削除の場合、キー列 (複数可) を設定して、変更する行を決定する必要があります。キーとして選択する列の名前は、後続の更新、upsert、削除の一部として使用されます。そのため、シンクマッピングに存在する列を選択する必要があります。	いいえ	Array	キー
Skip writing key columns\(キー列の書き込みをスキップする)	キー列に値を書き込まない場合は、[Skip writing key columns](キー列の書き込みをスキップする) を選択します。	いいえ	`true` または `false`	skipKeyWrites
テーブルアクション	書き込み前に変換先テーブルのすべての行を再作成するか削除するかを指定します。 - なし: テーブルに対してアクションは実行されません。 - Recreate:テーブルが削除され、再作成されます。新しいテーブルを動的に作成する場合に必要です。 - Truncate:ターゲットテーブルのすべての行が削除されます。	いいえ	`true` または `false`	recreate truncate
バッチサイズ	各バッチで書き込まれる行の数を指定します。バッチサイズを大きくすると、圧縮とメモリの最適化が向上しますが、データをキャッシュする際にメモリ不足の例外が発生するリスクがあります。	いいえ	Integer	batchSize
事前および事後の SQL スクリプト	データがシンクデータベースに書き込まれる前 (前処理) と書き込まれた後 (後処理) に実行される複数行の SQL スクリプトを指定します。	いいえ	String	preSQLs postSQLs

ヒント

複数のコマンドを含む単一のバッチスクリプトを複数のバッチに分割することをお勧めします。
バッチの一部として実行できるのは、単純に更新数を返すデータ操作言語 (DML) ステートメントおよびデータ定義言語 (DDL) ステートメントだけです。詳細については、「バッチ操作の実行」を参照してください。

SQL Server シンクスクリプトの例

シンクの種類として SQL Server を使用すると、関連付けられているデータフロースクリプトは次のようになります。

IncomingStream sink(allowSchemaDrift: true,
    validateSchema: false,
    deletable:false,
    insertable:true,
    updateable:true,
    upsertable:true,
    keys:['keyColumn'],
    format: 'table',
    skipDuplicateMapInputs: true,
    skipDuplicateMapOutputs: true) ~> SQLSink

SQL Server のデータ型のマッピング

SQL Server との間でデータをコピーするとき、SQL Server のデータ型から Azure Data Factory の中間データ型への、以下のマッピングが使用されます。 Data Factory を実装する Synapse パイプラインでは、同じマッピングが使用されます。コピーアクティビティでソースのスキーマとデータ型がシンクにマッピングされるしくみについては、スキーマとデータ型のマッピングに関する記事を参照してください。

SQL Server のデータ型	Data Factory の中間データ型
bigint	Int64
binary	Byte[]
bit	Boolean
char	String, Char[]
date	DateTime
Datetime	DateTime
datetime2	DateTime
Datetimeoffset	DateTimeOffset
Decimal	Decimal (10 進数型)
FILESTREAM attribute (varbinary(max))	Byte[]
Float	Double
image	Byte[]
INT	Int32
money	Decimal (10 進数型)
nchar	String, Char[]
ntext	String, Char[]
numeric	Decimal (10 進数型)
nvarchar	String, Char[]
real	Single
rowversion	Byte[]
smalldatetime	DateTime
smallint	Int16
smallmoney	Decimal (10 進数型)
sql_variant	Object
text	String, Char[]
time	TimeSpan
timestamp	Byte[]
tinyint	Int16
UNIQUEIDENTIFIER	Guid
varbinary	Byte[]
varchar	String, Char[]
xml	String

注意

10 進の中間型にマップされるデータ型の場合、コピーアクティビティでは、現在、最大 28 の有効桁数がサポートされています。 28 よりも大きな有効桁数を必要とするデータがある場合は、SQL クエリで文字列に変換することを検討してください。

Azure Data Factory を使用して SQL Server からデータをコピーする場合、bit データ型は、ブール値の中間データ型にマップされます。 bit データ型として保持する必要があるデータがある場合は、T-SQL CAST または CONVERT を使用したクエリを使用します。

Lookup アクティビティのプロパティ

プロパティの詳細については、Lookup アクティビティに関するページを参照してください。

GetMetadata アクティビティのプロパティ

プロパティの詳細については、GetMetadata アクティビティに関するページを参照してください。

Always Encrypted の使用

Always Encrypted を使用して SQL Server との間でデータをコピーする場合は、次の手順に従います。

列マスターキー (CMK) を Azure Key Vault に保存します。詳細については、Azure Key Vault を使用して Always Encrypted を構成する方法に関する記事を参照してください
列マスターキー (CMK) が格納されているキーコンテナーへのアクセス権を付与します。必要なアクセス許可については、こちらの記事を参照してください。
リンクサービスを作成して SQL データベースに接続し、マネージド ID またはサービスプリンシパルを使用して "Always Encrypted" 機能を有効にします。

Note

SQL Server の Always Encrypted では、次のシナリオがサポートされています。

ソースデータストアまたはシンクデータストアのいずれかで、キープロバイダー認証の種類としてマネージド ID またはサービスプリンシパルを使用する。
ソースデータストアとシンクデータストアの両方で、キープロバイダー認証の種類としてマネージド ID を使用する。
ソースデータストアとシンクデータストアの両方で、キープロバイダー認証の種類として同じサービスプリンシパルを使用する。

注意

現在、SQL Server Always Encrypted では、マッピングデータフローでのソース変換でのみサポートされています。

ネイティブ変更データキャプチャ

Azure Data Factory は、SQL Server、Azure SQL DB、Azure SQL MI のネイティブ変更データキャプチャ機能をサポートできます。 SQL ストアの行の挿入、更新、削除などの変更されたデータは、ADF マッピングデータフローによって自動的に検出および抽出できます。マッピングデータフローのコードエクスペリエンスがないため、ユーザーはデータベースを宛先のストアとして追加することで、SQL ストアからのデータレプリケーションシナリオを簡単に実現できます。さらに、ユーザーは間にデータ変換ロジックを作成して、SQL ストアから増分 ETL シナリオを実現することもできます。

チェックポイントを ADF が記録して最後の実行から変更データを自動的に取得できるようにするために、パイプラインとアクティビティ名は変更しないようにしてください。パイプライン名またはアクティビティ名を変更すると、チェックポイントがリセットされます。これにより、次回の実行時に最初から変更を開始したり、変更を取得したりすることができます。パイプライン名またはアクティビティ名を変更しても、直近の実行の後に変更されたデータを自動的に取得するためにチェックポイントを保持する場合は、データフローアクティビティで独自のチェックポイントキーを使用して、これを実現してください。

パイプラインをデバッグすると、この機能は同じように動作します。デバッグ実行中にブラウザーを更新すると、チェックポイントがリセットされることに注意してください。デバッグ実行のパイプライン結果に問題がなければ、パイプラインの発行とトリガーに進むことができます。最初に発行されたパイプラインをトリガーした時点では、最初から自動的に再起動されるか、またはその後からの変更が取得されます。

[モニター] セクションでは、常にパイプラインを再実行できます。この場合、変更されたデータは、選択したパイプライン実行の前のチェックポイントから常にキャプチャされます。

例 1:

マッピングデータフロー内のデータベースに参照されるシンク変換を使用して SQL CDC 対応データセットに参照されるソース変換を直接チェーンすると、SQL ソースで行われた変更がターゲットデータベースに自動的に適用されるため、データベース間のデータレプリケーションシナリオを簡単に取得できます。シンク変換で更新方法を使用して、挿入を許可するか、更新を許可するか、ターゲットデータベースで削除を許可するかを選択できます。マッピングデータフローのスクリプトの例を次に示します。

source(output(
		id as integer,
		name as string
	),
	allowSchemaDrift: true,
	validateSchema: false,
	enableNativeCdc: true,
	netChanges: true,
	skipInitialLoad: false,
	isolationLevel: 'READ_UNCOMMITTED',
	format: 'table') ~> source1
source1 sink(allowSchemaDrift: true,
	validateSchema: false,
	deletable:true,
	insertable:true,
	updateable:true,
	upsertable:true,
	keys:['id'],
	format: 'table',
	skipDuplicateMapInputs: true,
	skipDuplicateMapOutputs: true,
	errorHandlingOption: 'stopOnFirstError') ~> sink1

例 2:

SQL CDC を使用したデータベース間のデータレプリケーションではなく ETL シナリオを有効にする場合は、isInsert(1)、isUpdate(1)、isDelete(1) などのマッピングデータフローで式を使用して、異なる操作の種類の行を区別できます。値を持つ 1 つの列を派生する際にデータフローをマッピングするためのスクリプト例の 1 つを次に示します。1 は挿入された行を示し、2 は更新された行を示し、3 はダウンストリーム変換で差分データを処理するために削除された行を示します。

source(output(
		id as integer,
		name as string
	),
	allowSchemaDrift: true,
	validateSchema: false,
	enableNativeCdc: true,
	netChanges: true,
	skipInitialLoad: false,
	isolationLevel: 'READ_UNCOMMITTED',
	format: 'table') ~> source1
source1 derive(operationType = iif(isInsert(1), 1, iif(isUpdate(1), 2, 3))) ~> derivedColumn1
derivedColumn1 sink(allowSchemaDrift: true,
	validateSchema: false,
	skipDuplicateMapInputs: true,
	skipDuplicateMapOutputs: true) ~> sink1

既知の制限事項:

SQL CDC からの net 変更のみが、cdc.fn_cdc_get_net_changes_ 経由で ADF によって読み込まれます。

接続の問題のトラブルシューティング

リモート接続を受け付けるように、SQL Server インスタンスを構成します。 SQL Server Management Studio を開始し、サーバーを右クリックして、 [プロパティ] を選択します。一覧から [接続] を選択し、 [このサーバーへのリモート接続を許可する] チェックボックスをオンにします。

詳細な手順については、「remote access サーバー構成オプションの構成」をご覧ください。
SQL Server 構成マネージャーを開始します。目的のインスタンスの [SQL Server ネットワークの構成] を展開し、 [MSSQLSERVER のプロトコル] を選択します。右側のウィンドウにプロトコルが表示されます。 [TCP/IP] を右クリックして [有効化] を選択し、TCP/IP を有効にします。

TCP/IP プロトコルの有効化の詳細および別の方法については、「サーバーネットワークプロトコルの有効化または無効化」をご覧ください。
同じウィンドウで、 [TCP/IP] をダブルクリックして、 [TCP/IP のプロパティ] ウィンドウを起動します。
[IP アドレス] タブに切り替えます。下へスクロールして [IPAll] セクションを表示します。 [TCP ポート] を書き留めます。既定値は 1433 です。
コンピューターに Windows Firewall のルール を作成し、このポート経由の受信トラフィックを許可します。
接続の確認: 完全修飾名を使って SQL Server に接続するには、別のコンピューターから SQL Server Management Studio を使用します。たとえば "<machine>.<domain>.corp.<company>.com,1433" です。

SQL Server のバージョンをアップグレードする

SQL Server のバージョンをアップグレードするには、[リンクサービスの編集] ページで [バージョン] の [推奨] を選択し、推奨バージョンのリンクサービスプロパティを参照してリンクサービスを構成します。

推奨バージョンとレガシバージョンの違い

以下の表は、推奨バージョンとレガシバージョンを使用する SQL Server の違いを示しています。

推奨されるバージョン	レガシバージョン
`encrypt` を `strict` とすることで TLS 1.3 をサポートします。	TLS 1.3 はサポートされません。

コピーアクティビティによってソース、シンクとしてサポートされるデータストアの一覧については、サポートされるデータストアに関するセクションを参照してください。

次の方法で共有

Azure Data Factory または Azure Synapse Analytics を使用して SQL Server との間でデータをコピーおよび変換する

サポートされる機能

前提条件

はじめに

UI を使用して SQL Server のリンク サービスを作成する

コネクタの構成の詳細

リンクされたサービス プロパティ

推奨されるバージョン

SQL 認証

Windows 認証

ユーザー割り当てマネージド ID 認証

レガシ バージョン

レガシ バージョンの SQL 認証

レガシ バージョンの Windows 認証

データセットのプロパティ

コピー アクティビティのプロパティ

ソースとしての SQL Server

シンクとしての SQL Server

SQL データベースからの並列コピー

物理パーティションを確認するためのサンプル クエリ

SQL Server にデータを読み込むときのベスト プラクティス

データを追加する

データをアップサートする

テーブル全体を上書きする

カスタム ロジックでデータを書き込む

SQL シンクからのストアド プロシージャの呼び出し

Mapping Data Flow のプロパティ

ソース変換

SQL Server ソース スクリプトの例

シンク変換

SQL Server シンク スクリプトの例

SQL Server のデータ型のマッピング

Lookup アクティビティのプロパティ

GetMetadata アクティビティのプロパティ

Always Encrypted の使用

ネイティブ変更データ キャプチャ

例 1:

例 2:

既知の制限事項:

接続の問題のトラブルシューティング

SQL Server のバージョンをアップグレードする

推奨バージョンとレガシ バージョンの違い

関連するコンテンツ

フィードバック

その他のリソース

UI を使用して SQL Server のリンクサービスを作成する

リンクされたサービスプロパティ

レガシバージョン

レガシバージョンの SQL 認証

レガシバージョンの Windows 認証

コピーアクティビティのプロパティ

物理パーティションを確認するためのサンプルクエリ

SQL Server にデータを読み込むときのベストプラクティス

カスタムロジックでデータを書き込む

SQL シンクからのストアドプロシージャの呼び出し

SQL Server ソーススクリプトの例

SQL Server シンクスクリプトの例

ネイティブ変更データキャプチャ

推奨バージョンとレガシバージョンの違い