Kopieren und Transformieren von Daten in Azure SQL Datenbank mithilfe von Azure Data Factory oder Azure Synapse Analytics

GILT FÜR: Azure Data Factory Azure Synapse Analytics

Tipp

Testen Sie Data Factory in Microsoft Fabric, eine All-in-One-Analyselösung für Unternehmen. Microsoft Fabric deckt alle Aufgaben ab, von der Datenverschiebung bis hin zu Data Science, Echtzeitanalysen, Business Intelligence und Berichterstellung. Erfahren Sie, wie Sie kostenlos eine neue Testversion starten!

In diesem Artikel wird beschrieben, wie Sie die Kopieraktivität in Azure Data Factory oder in Azure Synapse-Pipelines verwenden, um Daten von und nach Azure SQL Datenbank zu kopieren, und wie Sie Data Flow verwenden, um Daten in Azure SQL Datenbank zu transformieren. Um mehr zu lernen, lesen Sie den Einführungsartikel für Azure Data Factory oder Azure Synapse Analytics.

Unterstützte Funktionen

Dieser Connector für die Azure SQL-Datenbank wird für die folgenden Aktivitäten unterstützt:

Unterstützte Funktionen	IR	Verwalteter privater Endpunkt
Kopieraktivität (Quelle/Senke)	① ②	✓
Zuordnungsdatenfluss (Quelle/Senke)	①	✓
Lookup-Aktivität	① ②	✓
GetMetadata-Aktivität	① ②	✓
Skriptaktivität	① ②	✓
Aktivität „Gespeicherte Prozedur“	① ②	✓

① Azure Integration Runtime ② Selbstgehostete Integration Runtime

Für die Kopieraktivität unterstützt dieser Azure SQL-Datenbank-Connector folgende Funktionen:

• Kopieren von Daten mittels SQL-Authentifizierung und Microsoft Entra-Tokenauthentifizierung mit einem Dienstprinzipal oder verwalteten Identitäten für Azure-Ressourcen.
• Als Quelle das Abrufen von Daten mithilfe einer SQL-Abfrage oder gespeicherten Prozedur Sie können sich auch für das parallele Kopieren aus einer Azure SQL-Datenbank-Quelle entscheiden. Einzelheiten finden Sie im Abschnitt Paralleles Kopieren aus SQL-Datenbank.
• Als Senke das automatische Erstellen einer Zieltabelle, sofern noch nicht vorhanden, basierend auf dem Quellschema sowie das Anfügen von Daten an eine Tabelle oder das Aufrufen einer gespeicherten Prozedur mit benutzerdefinierter Logik während des Kopiervorgangs.

Wenn Sie die serverlose Dienstebene von Azure SQL-Datenbank verwenden, sollten Sie beachten, dass die Aktivitätsausführung bei angehaltenem Server zu einem Fehler führt und nicht darauf gewartet wird, dass die automatische Fortsetzung bereit ist. Sie können Aktivitätswiederholungen hinzufügen oder zusätzliche Aktivitäten verketten, um sicherzustellen, dass der Server zum Zeitpunkt der tatsächlichen Ausführung aktiv ist.

Wichtig

Wenn Sie Daten mithilfe der Azure Integration Runtime kopieren, konfigurieren Sie eine Firewallregel auf Serverebene, damit Azure-Dienste Zugriff auf den Server erhalten. Wenn Sie Daten mithilfe einer selbstgehosteten Integration Runtime kopieren, konfigurieren Sie die Firewall, um den entsprechenden IP-Adressbereich zuzulassen. Dieser Bereich schließt die IP-Adresse des Computers ein, der für die Verbindung mit Azure SQL-Datenbank verwendet wird.

Erste Schritte

Sie können eines der folgenden Tools oder SDKs verwenden, um die Kopieraktivität mit einer Pipeline zu verwenden:

• Das Tool „Daten kopieren“
• Azure-Portal
• Das .NET SDK
• Das Python SDK
• Azure PowerShell
• Die REST-API
• Die Azure Resource Manager-Vorlage

Erstellen eines verknüpften Azure SQL-Datenbank-Diensts mit Benutzeroberfläche

Verwenden Sie die folgenden Schritte, um einen verknüpften Azure SQL-Datenbank-Dienst auf der Azure-Portal Benutzeroberfläche zu erstellen.

1. Navigieren Sie in Ihrem Azure Data Factory- oder Synapse-Arbeitsbereich zu der Registerkarte „Verwalten“, wählen Sie „Verknüpfte Dienste“ aus und klicken Sie dann auf „Neu“:

   Azure Data Factory

   

   Azure Synapse

   

2. Suchen Sie nach SQL, und wählen Sie den connector Azure SQL-Datenbank.

   

3. Konfigurieren Sie die Dienstdetails, testen Sie die Verbindung, und erstellen Sie den neuen verknüpften Dienst.

   

Details zur Connector-Konfiguration

Die folgenden Abschnitte enthalten Details zu Eigenschaften, die zum Definieren von Azure Data Factory- oder Synapse Pipeline-Entitäten speziell für einen Azure SQL-Datenbank-Connector verwendet werden.

Eigenschaften des verknüpften Diensts

Diese generischen Eigenschaften werden für einen verknüpften Azure SQL-Datenbankdienst unterstützt:

Eigenschaft	Beschreibung	Erforderlich
type	Die type-Eigenschaft muss auf AzureSqlDatabase festgelegt sein.	Ja
connectionString	Geben Sie Informationen, die zur Verbindung mit der Azure SQL-Datenbank-Instanz erforderlich sind, für die connectionString-Eigenschaft ein. Sie können auch ein Kennwort oder einen Dienstprinzipalschlüssel in Azure Key Vault eingeben. Bei Verwendung der SQL-Authentifizierung pullen Sie die password-Konfiguration aus der Verbindungszeichenfolge. Weitere Informationen finden Sie im JSON-Beispiel unter der Tabelle sowie unter Speichern von Anmeldeinformationen in Azure Key Vault.	Ja
azureCloudType	Geben Sie für die Dienstprinzipalauthentifizierung die Art der Azure-Cloudumgebung an, bei der Ihre Microsoft Entra-Anwendung registriert ist. Zulässige Werte sind AzurePublic, AzureChina, AzureUsGovernment und AzureGermany. Standardmäßig wird die Cloudumgebung der Data Factory oder der Synapse-Pipeline verwendet.	Nein
Always Encrypted-Einstellungen	Geben Sie die Informationen zu denAlways Encrypted-Einstellungen an, die erforderlich sind, damit Always Encrypted vertrauliche Daten schützen kann, die auf dem SQL-Server mithilfe der verwalteten Identität oder des Dienstprinzipals gespeichert sind. Weitere Informationen finden Sie im JSON-Beispiel unter der Tabelle sowie in dem Bereich Verwenden von Always Encrypted. Wenn keine Angabe erfolgt, ist die standardmäßige Always Encrypted-Einstellung deaktiviert.	Nein
connectVia	Diese Integration Runtime wird zum Herstellen einer Verbindung mit dem Datenspeicher verwendet. Sie können die Azure Integration Runtime oder eine selbstgehostete Integration Runtime verwenden, sofern sich Ihr Datenspeicher in einem privaten Netzwerk befindet. Wenn kein Wert angegeben ist, wird die standardmäßige Azure Integration Runtime verwendet.	Nein

Informationen zu verschiedenen Authentifizierungstypen finden Sie jeweils in den folgenden Abschnitten zu bestimmten Eigenschaften, Voraussetzungen und JSON-Beispielen:

• SQL-Authentifizierung
• Dienstprinzipalauthentifizierung
• Authentifizierung mit einer systemseitig zugewiesenen verwalteten Identität
• Authentifizierung mit einer benutzerseitig zugewiesenen verwalteten Identität

Tipp

Wenn ein Fehler mit dem Fehlercode „UserErrorFailedToConnectToSqlServer“ auftritt und eine Meldung wie „Das Sitzungslimit für die Datenbank ist XXX und wurde erreicht“ angezeigt wird, fügen Sie Pooling=false zu Ihrer Verbindungszeichenfolge hinzu, und versuchen Sie es erneut. Pooling=false wird auch für das Setup eines verknüpften Diensts vom Typ SHIR (selbstgehostete Integration Runtime) empfohlen. Pooling- und weitere Verbindungsparameter können als neue Parameternamen und -werte im Erstellungsformular für einen verknüpften Dienst im Abschnitt Zusätzliche Verbindungseigenschaften hinzugefügt werden.

SQL-Authentifizierung

Um den Authentifizierungstyp SQL-Authentifizierung zu verwenden, geben Sie die generischen Eigenschaften an, die im vorherigen Abschnitt beschrieben sind.

Beispiel: Verwenden der SQL-Authentifizierung

{
    "name": "AzureSqlDbLinkedService",
    "properties": {
        "type": "AzureSqlDatabase",
        "typeProperties": {
            "connectionString": "Data Source=tcp:<servername>.database.windows.net,1433;Initial Catalog=<databasename>;User ID=<username>@<servername>;Password=<password>;Trusted_Connection=False;Encrypt=True;Connection Timeout=30"
        },
        "connectVia": {
            "referenceName": "<name of Integration Runtime>",
            "type": "IntegrationRuntimeReference"
        }
    }
}

Beispiel: Kennwort in Azure Key Vault

{
    "name": "AzureSqlDbLinkedService",
    "properties": {
        "type": "AzureSqlDatabase",
        "typeProperties": {
            "connectionString": "Data Source=tcp:<servername>.database.windows.net,1433;Initial Catalog=<databasename>;User ID=<username>@<servername>;Trusted_Connection=False;Encrypt=True;Connection Timeout=30",
            "password": {
                "type": "AzureKeyVaultSecret",
                "store": {
                    "referenceName": "<Azure Key Vault linked service name>",
                    "type": "LinkedServiceReference"
                },
                "secretName": "<secretName>"
            }
        },
        "connectVia": {
            "referenceName": "<name of Integration Runtime>",
            "type": "IntegrationRuntimeReference"
        }
    }
}

Beispiel: Verwenden von Always Encrypted

{
    "name": "AzureSqlDbLinkedService",
    "properties": {
        "type": "AzureSqlDatabase",
        "typeProperties": {
            "connectionString": "Data Source=tcp:<servername>.database.windows.net,1433;Initial Catalog=<databasename>;User ID=<username>@<servername>;Password=<password>;Trusted_Connection=False;Encrypt=True;Connection Timeout=30"
        },
        "alwaysEncryptedSettings": {
            "alwaysEncryptedAkvAuthType": "ServicePrincipal",
            "servicePrincipalId": "<service principal id>",
            "servicePrincipalKey": {
                "type": "SecureString",
                "value": "<service principal key>"
            }
        },
        "connectVia": {
            "referenceName": "<name of Integration Runtime>",
            "type": "IntegrationRuntimeReference"
        }
    }
}

Dienstprinzipalauthentifizierung

Um die Dienstprinzipal-Authentifizierung zu verwenden, geben Sie zusätzlich zu den im vorherigen Abschnitt beschriebenen allgemeinen Eigenschaften die folgenden Eigenschaften an:

Eigenschaft	Beschreibung	Erforderlich
servicePrincipalId	Geben Sie die Client-ID der Anwendung an.	Ja
servicePrincipalKey	Geben Sie den Schlüssel der Anwendung an. Markieren Sie dieses Feld als einen SecureString, um es sicher zu speichern, oder verweisen Sie auf ein in Azure Key Vault gespeichertes Geheimnis.	Ja
tenant	Geben Sie die Mandanteninformationen, wie Domänenname oder Mandanten-ID, für Ihre Anwendung an. Diese können Sie abrufen, indem Sie im Azure-Portal mit der Maus auf den Bereich oben rechts zeigen.	Ja

Sie müssen auch die folgenden Schritte ausführen:

1. Erstellen Sie eine Microsoft Entra-Anwendung im Azure-Portal. Notieren Sie sich den Anwendungsnamen und die folgenden Werte zum Definieren des verknüpften Diensts:

   • Anwendungs-ID
   • Anwendungsschlüssel
   • Mandanten-ID

2. Stellen Sie eine*n Microsoft Entra-Administrator*in für Ihren Server im Azure-Portal bereit, sofern dies noch nicht geschehen ist. Dabei kann es sich um eine*n Microsoft Entra-Benutzer*in oder eine Microsoft Entra-Gruppe, nicht aber um einen Dienstprinzipal handeln. Dieser Schritt ist erforderlich, damit Sie im nachfolgenden Schritt eine Microsoft Entra-Identität verwenden können, um eine* Benutzer*in einer eigenständigen Datenbank für den Dienstprinzipal erstellen können.

3. Erstellen Sie Benutzer der eigenständigen Datenbank für den Dienstprinzipal. Stellen Sie eine Verbindung mit der Datenbank her, aus der bzw. in die Sie Daten mithilfe von Tools wie SQL Server Management Studio kopieren möchten. Verwenden Sie dazu eine Microsoft Entra-Identität, die mindestens über die Berechtigung ALTER ANY USER verfügt. Führen Sie folgenden T-SQL-Code aus:

   CREATE USER [your application name] FROM EXTERNAL PROVIDER;
   

4. Gewähren Sie dem Dienstprinzipal die notwendigen Berechtigungen, wie bei SQL- oder anderen Benutzern üblich. Führen Sie den folgenden Code aus. Weitere Optionen finden Sie in diesem Dokument.

   ALTER ROLE [role name] ADD MEMBER [your application name];
   

5. Konfigurieren Sie einen mit Azure SQL-Datenbank verknüpften Dienst in Azure Data Factory oder Synapse Arbeitsbereich.

Beispiel eines verknüpften Diensts mit Dienstprinzipalauthentifizierung

{
    "name": "AzureSqlDbLinkedService",
    "properties": {
        "type": "AzureSqlDatabase",
        "typeProperties": {
            "connectionString": "Data Source=tcp:<servername>.database.windows.net,1433;Initial Catalog=<databasename>;Connection Timeout=30",
            "servicePrincipalId": "<service principal id>",
            "servicePrincipalKey": {
                "type": "SecureString",
                "value": "<service principal key>"
            },
            "tenant": "<tenant info, e.g. microsoft.onmicrosoft.com>"
        },
        "connectVia": {
            "referenceName": "<name of Integration Runtime>",
            "type": "IntegrationRuntimeReference"
        }
    }
}

Authentifizierung mit einer systemseitig zugewiesenen verwalteten Identität

Eine Datenfabrik oder ein Synapse-Arbeitsbereich kann mit einer systemzugewiesenen verwalteten Identität für Azure-Ressourcen verknüpft werden, die den Dienst bei der Authentifizierung gegenüber anderen Ressourcen in Azure repräsentiert. Sie können diese verwaltete Identität für die Azure SQL-Datenbank-Authentifizierung verwenden. Die angegebenen Factory oder Synapse Arbeitsbereiche können mittels dieser Identität auf Daten zugreifen und Daten aus der oder in die Datenbank kopieren.

Um die vom System zugewiesene verwaltete Identitätsauthentifizierung zu verwenden, geben Sie die generischen Eigenschaften an, die im vorherigen Abschnitt beschrieben sind, und führen Sie diese Schritte aus.

1. Stellen Sie eine*n Microsoft Entra-Administrator*in für Ihren Server im Azure-Portal bereit, sofern dies noch nicht geschehen ist. Dabei kann es sich um eine*n Microsoft Entra-Benutzer*in oder eine Microsoft Entra-Gruppe handeln. Wenn Sie der Gruppe mit der verwalteten Identität eine Administratorrolle zuweisen, überspringen Sie die Schritte 3 und 4. Der Administrator erhält Vollzugriff auf die Datenbank.

2. Erstellen Sie eine eigenständige Benutzerdatenbank für die verwaltete Data Factory-Identität. Stellen Sie eine Verbindung mit der Datenbank her, aus der bzw. in die Sie Daten mithilfe von Tools wie SQL Server Management Studio kopieren möchten. Verwenden Sie dazu eine Microsoft Entra-Identität, die mindestens über die Berechtigung ALTER ANY USER verfügt. Führen Sie folgenden T-SQL-Code aus:

   CREATE USER [your_resource_name] FROM EXTERNAL PROVIDER;
   

3. Gewähren Sie die notwendigen Berechtigungen, und gehen Sie dabei so vor, wie Sie es gewöhnlich für SQL-Benutzer und andere Benutzer tun. Führen Sie den folgenden Code aus. Weitere Optionen finden Sie in diesem Dokument.

   ALTER ROLE [role name] ADD MEMBER [your_resource_name];
   

4. Konfigurieren Sie einen verknüpften Azure SQL-Datenbank-Dienst.

Beispiel

{
    "name": "AzureSqlDbLinkedService",
    "properties": {
        "type": "AzureSqlDatabase",
        "typeProperties": {
            "connectionString": "Data Source=tcp:<servername>.database.windows.net,1433;Initial Catalog=<databasename>;Connection Timeout=30"
        },
        "connectVia": {
            "referenceName": "<name of Integration Runtime>",
            "type": "IntegrationRuntimeReference"
        }
    }
}

Authentifizierung mit einer benutzerseitig zugewiesenen verwalteten Identität

Eine Datenfabrik oder ein Synapse-Arbeitsbereich kann mit einer systemzugewiesenen verwalteten Identität für Azure-Ressourcen verknüpft werden, die den Dienst bei der Authentifizierung gegenüber anderen Ressourcen in Azure repräsentiert. Sie können diese verwaltete Identität für die Azure SQL-Datenbank-Authentifizierung verwenden. Die angegebenen Factory oder Synapse Arbeitsbereiche können mittels dieser Identität auf Daten zugreifen und Daten aus der oder in die Datenbank kopieren.

Um die vom Benutzer zugewiesene verwaltete Identitätsauthentifizierung zu verwenden, geben Sie zusätzlich zu den im vorherigen Abschnitt beschriebenen allgemeinen Eigenschaften die folgenden Eigenschaften an:

Eigenschaft	Beschreibung	Erforderlich
Anmeldeinformationen	Geben Sie die benutzerseitig zugewiesene verwaltete Identität als Anmeldeinformationsobjekt an.	Ja

Sie müssen auch die folgenden Schritte ausführen:

1. Stellen Sie eine*n Microsoft Entra-Administrator*in für Ihren Server im Azure-Portal bereit, sofern dies noch nicht geschehen ist. Dabei kann es sich um eine*n Microsoft Entra-Benutzer*in oder eine Microsoft Entra-Gruppe handeln. Wenn Sie der Gruppe mit der verwalteten Identität eine Administratorrolle zuweisen, überspringen Sie die Schritte 3 und 4. Der Administrator erhält Vollzugriff auf die Datenbank.

2. Erstellen Sie Benutzer der eigenständigen Datenbank für die benutzerseitig zugewiesene verwaltete Identität. Stellen Sie eine Verbindung mit der Datenbank her, aus der bzw. in die Sie Daten mithilfe von Tools wie SQL Server Management Studio kopieren möchten. Verwenden Sie dazu eine Microsoft Entra-Identität, die mindestens über die Berechtigung ALTER ANY USER verfügt. Führen Sie folgenden T-SQL-Code aus:

   CREATE USER [your_resource_name] FROM EXTERNAL PROVIDER;
   

3. Erstellen Sie mindestens eine benutzerseitig zugewiesene verwaltete Identität, und gewähren Sie dieser Identität die erforderlichen Berechtigungen, wie Sie es normalerweise für SQL- und andere Benutzer tun. Führen Sie den folgenden Code aus. Weitere Optionen finden Sie in diesem Dokument.

   ALTER ROLE [role name] ADD MEMBER [your_resource_name];
   

4. Weisen Sie Ihrer Data Factory eine oder mehrere benutzerseitig zugewiesene verwaltete Identitäten zu, und erstellen Sie Anmeldeinformationen für jede benutzerseitig zugewiesene verwaltete Identität.

5. Konfigurieren Sie einen verknüpften Azure SQL-Datenbank-Dienst.

Beispiel:

{
    "name": "AzureSqlDbLinkedService",
    "properties": {
        "type": "AzureSqlDatabase",
        "typeProperties": {
            "connectionString": "Data Source=tcp:<servername>.database.windows.net,1433;Initial Catalog=<databasename>;Connection Timeout=30",
            "credential": {
                "referenceName": "credential1",
                "type": "CredentialReference"
            }
        },
        "connectVia": {
            "referenceName": "<name of Integration Runtime>",
            "type": "IntegrationRuntimeReference"
        }
    }
}

Dataset-Eigenschaften

Eine vollständige Liste mit den verfügbaren Abschnitten und Eigenschaften zum Definieren von Datasets finden Sie unter Datasets.

Die folgenden Eigenschaften werden beim Azure SQL-Datenbank-Dataset unterstützt:

Eigenschaft	Beschreibung	Erforderlich
type	Die type-Eigenschaft des Datasets muss auf AzureSqlTable festgelegt sein.	Ja
schema	Name des Schemas.	Quelle: Nein, Senke: Ja
table	Name der Tabelle/Ansicht.	Quelle: Nein, Senke: Ja
tableName	Name der Tabelle/Ansicht mit Schema. Diese Eigenschaft wird aus Gründen der Abwärtskompatibilität weiterhin unterstützt. Verwenden Sie für eine neue Workload schema und table.	Quelle: Nein, Senke: Ja

Beispiel für Dataseteigenschaften

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

Eigenschaften der Kopieraktivität

Eine vollständige Liste der verfügbaren Abschnitte und Eigenschaften zum Definieren von Aktivitäten finden Sie unter Pipelines. Dieser Abschnitt enthält eine Liste der Eigenschaften, die von der Azure SQL-Datenbank-Quelle und -Senke unterstützt werden.

Azure SQL-Datenbank als Quelle

Tipp

Weitere Informationen zum effizienten Laden von Daten aus Azure SQL-Datenbank mithilfe der Datenpartitionierung finden Sie unter Paralleles Kopieren aus SQL-Datenbank.

Zum Kopieren von Daten aus Azure SQL-Datenbank werden die folgenden Eigenschaften im Abschnitt source der Kopieraktivität unterstützt:

Eigenschaft	Beschreibung	Erforderlich
type	Die type-Eigenschaft der Quelle der Kopieraktivität muss auf AzureSqlSource festgelegt werden. Der Typ „SqlSource“ wird aus Gründen der Abwärtskompatibilität weiterhin unterstützt.	Ja
sqlReaderQuery	Diese Eigenschaft verwendet die benutzerdefinierte SQL-Abfrage zum Lesen von Daten. z. B. select * from MyTable.	Nein
sqlReaderStoredProcedureName	Name der gespeicherten Prozedur, die Daten aus der Quelltabelle liest. Die letzte SQL-Anweisung muss eine SELECT-Anweisung in der gespeicherten Prozedur sein.	Nein
storedProcedureParameters	Parameter für die gespeicherte Prozedur. Zulässige Werte sind Namen oder Name-Wert-Paare. Die Namen und die Groß-/Kleinschreibung von Parametern müssen den Namen und der Groß-/Kleinschreibung der Parameter der gespeicherten Prozedur entsprechen.	Nein
isolationLevel	Gibt das Sperrverhalten für Transaktionen für die SQL-Quelle an. Zulässige Werte sind: ReadCommitted, ReadUncommitted, RepeatableRead, Serializable, Snapshot. Ohne Angabe wird die Standardisolationsstufe der Datenbank verwendet. Weitere Informationen finden Sie in dieser Dokumentation.	Nein
partitionOptions	Hiermit werden die Datenpartitionierungsoptionen angegeben, mit denen Daten aus Azure SQL-Datenbank geladen werden. Zulässige Werte sind: None (Standardwert), PhysicalPartitionsOfTable und DynamicRange. Wenn eine Partitionierungsoption aktiviert ist (d.h. nicht None), wird der Parallelitätsgrad für das gleichzeitige Laden von Daten aus einer Oracle-Datenbank durch die Einstellung parallelCopies der Kopieraktivität gesteuert.	Nein
partitionSettings	Geben Sie die Gruppe der Einstellungen für die Datenpartitionierung an. Verwenden Sie diese Option, wenn die Partitionsoption nicht None lautet.	Nein
Unter partitionSettings:
partitionColumnName	Geben Sie den Namen der Quellspalte als „integer“ oder „date/datetime“ (int, smallint, bigint, date, smalldatetime, datetime, datetime2 oder datetimeoffset) an, der von der Bereichspartitionierung für das parallele Kopieren verwendet wird. Wenn nichts angegeben wurde, wird der Index oder der Primärschlüssel der Tabelle automatisch erkannt und als Partitionsspalte verwendet. Verwenden Sie diese Option, wenn die Partitionsoption DynamicRange lautet. Wenn Sie die Quelldaten mithilfe einer Abfrage abrufen, integrieren Sie ?AdfDynamicRangePartitionCondition in die WHERE-Klausel. Ein Beispiel finden Sie im Abschnitt Paralleles Kopieren aus SQL-Datenbank.	Nein
partitionUpperBound	Der maximale Wert der Partitionsspalte für das Teilen des Partitionsbereichs. Dieser Wert wird zur Entscheidung über den Partitionssprung verwendet, nicht zum Filtern der Zeilen in der Tabelle. Alle Zeilen in der Tabelle oder im Abfrageergebnis werden partitioniert und kopiert. Wenn nicht angegeben, wird der Wert für die Kopieraktivität automatisch erkannt. Verwenden Sie diese Option, wenn die Partitionsoption DynamicRange lautet. Ein Beispiel finden Sie im Abschnitt Paralleles Kopieren aus SQL-Datenbank.	Nein
partitionLowerBound	Der minimale Wert der Partitionsspalte für das Teilen des Partitionsbereichs. Dieser Wert wird zur Entscheidung über den Partitionssprung verwendet, nicht zum Filtern der Zeilen in der Tabelle. Alle Zeilen in der Tabelle oder im Abfrageergebnis werden partitioniert und kopiert. Wenn nicht angegeben, wird der Wert für die Kopieraktivität automatisch erkannt. Verwenden Sie diese Option, wenn die Partitionsoption DynamicRange lautet. Ein Beispiel finden Sie im Abschnitt Paralleles Kopieren aus SQL-Datenbank.	Nein

Beachten Sie folgende Punkte:

• Wenn sqlReaderQuery für AzureSqlSource angegeben ist, führt die Kopieraktivität diese Abfrage für die Azure SQL-Datenbankquelle aus, um die Daten abzurufen. Sie können auch eine gespeicherte Prozedur angeben, indem Sie sqlReaderStoredProcedureName und storedProcedureParameters angeben, sofern die gespeicherten Prozeduren Parameter verwenden.
• Wenn Sie zum Abrufen von Daten eine gespeicherte Prozedur in der Quelle verwenden und die gespeicherte Prozedur beim Übergeben eines anderen Parameterwerts ein anderes Schema zurückgibt, kommt es möglicherweise beim Importieren eines Schemas über die Benutzeroberfläche oder beim Kopieren von Daten in eine SQL-Datenbank zu einem Fehler oder einem unerwarteten Ergebnis.

Beispiel für eine SQL-Abfrage

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

Beispiel für eine gespeicherte Prozedur

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

Definition der gespeicherten Prozedur

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

Azure SQL-Datenbank als Senke

Tipp

Weitere Informationen zum unterstützten Schreibverhalten, zu unterstützten Konfigurationen und bewährten Methoden finden Sie unter Bewährte Methode zum Laden von Daten in Azure SQL-Datenbank.

Zum Kopieren von Daten in Azure SQL-Datenbank werden die folgenden Eigenschaften im Abschnitt sink der Kopieraktivität unterstützt:

Eigenschaft	Beschreibung	Erforderlich
type	Die type-Eigenschaft der Senke der Kopieraktivität muss auf AzureSqlSink festgelegt werden. Der Typ „SqlSink“ wird aus Gründen der Abwärtskompatibilität weiterhin unterstützt.	Ja
preCopyScript	Geben Sie eine auszuführende SQL-Abfrage für die Kopieraktivität an, ehe Sie Daten in Azure SQL-Datenbank schreiben. Sie wird pro Ausführung der Kopieraktivität nur einmal aufgerufen. Sie können diese Eigenschaft nutzen, um vorab geladene Daten zu bereinigen.	Nein
tableOption	Gibt an, ob die Senkentabelle auf Basis des Quellschemas automatisch erstellt werden soll, wenn sie nicht vorhanden ist. Die automatische Tabellenerstellung wird nicht unterstützt, wenn die Senke eine gespeicherte Prozedur angibt. Zulässige Werte: none (Standard), autoCreate.	Nein
sqlWriterStoredProcedureName	Der Name der gespeicherten Prozedur, die definiert, wie Quelldaten auf eine Zieltabelle angewandt werden. Diese gespeicherte Prozedur wird pro Batch aufgerufen. Für nur einmalig ausgeführte Vorgänge, die nicht mit Quelldaten in Zusammenhang stehen (etwa Löschen/Kürzen), verwenden Sie die preCopyScript-Eigenschaft. Ein Beispiel finden Sie unter Aufrufen einer gespeicherten Prozedur aus einer SQL-Senke.	Nein
storedProcedureTableTypeParameterName	Der Parametername des Tabellentyps, der in der gespeicherten Prozedur angegeben ist.	Nein
sqlWriterTableType	Der Tabellentypname, der in der gespeicherten Prozedur verwendet werden soll. Die Kopieraktivität macht die verschobenen Daten in einer temporären Tabelle mit diesem Tabellentyp verfügbar. Der gespeicherte Prozedurcode kann dann die kopierten Daten mit vorhandenen Daten zusammenführen.	Nein
storedProcedureParameters	Parameter für die gespeicherte Prozedur. Zulässige Werte: Name-Wert-Paare. Die Namen und die Groß-/Kleinschreibung von Parametern müssen denen der Parameter der gespeicherten Prozedur entsprechen.	Nein
writeBatchSize	Anzahl der Zeilen, die pro Batch in die SQL-Tabelle eingefügt werden sollen. Zulässiger Wert: integer (Anzahl der Zeilen) Standardmäßig bestimmt der Dienst die geeignete Batchgröße dynamisch auf der Grundlage der Zeilengröße.	Nein
writeBatchTimeout	Die Wartezeit für den Abschluss der Insert- und Upsert-Vorgänge und die gespeicherte Prozedur, bevor ein Timeout auftritt. Zulässige Werte werden für den Zeitraum verwendet. Beispiel: „00:30:00“ für 30 Minuten. Wenn kein Wert festgelegt ist, wird für das Timeout der Standardwert „00:30:00“ verwendet.	No
disableMetricsCollection	Der Dienst sammelt Metriken wie Azure SQL Datenbank DTUs für die Optimierung der Kopierleistung und Empfehlungen, was einen zusätzlichen Master-DB-Zugriff ermöglicht. Wenn Sie sich wegen dieses Verhaltens Gedanken machen, geben Sie true an, um es zu deaktivieren.	Nein (Standard = false)
maxConcurrentConnections	Die Obergrenze gleichzeitiger Verbindungen mit dem Datenspeicher während der Aktivitätsausführung. Geben Sie diesen Wert nur an, wenn Sie die Anzahl der gleichzeitigen Verbindungen begrenzen möchten.	Ohne
WriteBehavior	Geben Sie das Schreibverhalten für die Kopieraktivität an, um Daten in Azure SQL-Datenbank zu laden. Die zulässigen Werte sind Insert und Upsert. Standardmäßig verwendet der Dienst „Insert“, um Daten zu laden.	Nein
upsertSettings	Geben Sie die Gruppe der Einstellungen für das Schreibverhalten an. Wenden Sie dies an, wenn die WriteBehavior-Option Upsert ist.	Nein
Unter upsertSettings:
useTempDB	Geben Sie an, ob eine globale temporäre Tabelle oder physische Tabelle als Zwischentabelle für Upserts verwendet werden soll. Standardmäßig verwendet der Dienst eine globale temporäre Tabelle als Zwischentabelle. Der Wert lautet true.	Nein
interimSchemaName	Geben Sie das Zwischenschema zum Erstellen einer Zwischentabelle an, wenn eine physische Tabelle verwendet wird. Hinweis: Benutzer müssen über die Berechtigung zum Erstellen und Löschen einer Tabelle verfügen. Standardmäßig verwendet die Zwischentabelle das gleiche Schema wie die Senkentabelle. Wird angewendet, wenn die useTempDB-Option False lautet.	Nein
keys	Geben Sie die Spaltennamen für die eindeutige Zeilenidentifikation an. Es kann entweder ein einzelner Schlüssel oder eine Reihe von Schlüsseln verwendet werden. Bei fehlender Angabe wird der Primärschlüssel verwendet.	Nein

Beispiel 1: Anfügen von Daten

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

Beispiel 2: Aufrufen einer gespeicherten Prozedur während des Kopiervorgangs

Weitere Informationen finden Sie unter Aufrufen einer gespeicherten Prozedur aus einer SQL-Senke.

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

Beispiel 3: Upsert-Daten

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

Paralleles Kopieren aus SQL-Datenbank

Der Connector für Azure SQL-Datenbank in der Kopieraktivität verfügt über eine integrierte Datenpartitionierung zum parallelen Kopieren von Daten. Die Datenpartitionierungsoptionen befinden sich auf der Registerkarte Quelle der Kopieraktivität.

Wenn Sie das partitionierte Kopieren aktivieren, führt die Kopieraktivität parallele Abfragen für Ihre Azure SQL-Datenbank-Quelle aus, um Daten in Partitionen zu laden. Der Parallelitätsgrad wird über die Einstellung parallelCopies der Kopieraktivität gesteuert. Wenn Sie beispielsweise parallelCopies auf vier setzen, generiert der Dienst gleichzeitig vier Abfragen auf der Grundlage der von Ihnen angegebenen Partitionsoption und -einstellungen und führt sie aus, wobei jede Abfrage einen Teil der Daten aus Ihrer Azure SQL-Datenbank abruft.

Es wird empfohlen, das parallele Kopieren mit Datenpartitionierung zu aktivieren, vor allem, wenn Sie große Datenmengen aus Ihrer Azure SQL-Datenbank-Instanz laden. Im Anschluss finden Sie empfohlene Konfigurationen für verschiedene Szenarien. Beim Kopieren von Daten in einen dateibasierten Datenspeicher wird empfohlen, mehrere Dateien in einen Ordner zu schreiben (nur den Ordnernamen anzugeben). In diesem Fall ist die Leistung besser als beim Schreiben in eine einzelne Datei.

Szenario	Empfohlene Einstellungen
Vollständiges Laden aus einer großen Tabelle mit physischen Partitionen	Partitionsoption: Physische Partitionen der Tabelle. Während der Ausführung erkennt der Dienst automatisch die physischen Partitionen und kopiert Daten nach Partitionen. Um zu überprüfen, ob Ihre Tabelle eine physische Partition besitzt oder nicht, können Sie auf diese Abfrage verweisen.
Vollständiges Laden aus einer großen Tabelle ohne physische Partitionen, aber mit einer integer- oder datetime-Spalte für die Datenpartitionierung.	Partitionsoptionen: Dynamische Bereichspartitionierung Partitionsspalte (optional): Geben Sie die Spalte für die Datenpartitionierung an. Ohne Angabe wird der Index oder die Primärschlüsselspalte verwendet. Obergrenze der Partition und Untergrenze der Partition (optional): Geben Sie an, ob Sie den Partitionssprung bestimmen möchten. Dies dient nicht zum Filtern der Zeilen in der Tabelle; alle Zeilen in der Tabelle werden partitioniert und kopiert. Wenn nicht angegeben, werden die Werte für die Kopieraktivität automatisch erkannt. Wenn Ihre Partitionsspalte "ID" beispielsweise einen Wertebereich von 1 bis 100 hat und Sie die untere Grenze auf 20 und die obere Grenze auf 80 und die Parallelkopie auf 4 setzen, ruft der Dienst Daten nach 4 Partitionen ab - IDs im Bereich <=20, [21, 50], [51, 80] bzw. >=81.
Laden einer großen Datenmenge unter Verwendung einer benutzerdefinierten Abfrage ohne physische Partitionen, aber mit einer integer- oder date/datetime-Spalte für die Datenpartitionierung.	Partitionsoptionen: Dynamische Bereichspartitionierung Abfrage: SELECT * FROM <TableName> WHERE ?AdfDynamicRangePartitionCondition AND <your_additional_where_clause> Partitionsspalte: Geben Sie die Spalte für die Datenpartitionierung an. Obergrenze der Partition und Untergrenze der Partition (optional): Geben Sie an, ob Sie den Partitionssprung bestimmen möchten. Dies dient nicht zum Filtern der Zeilen in der Tabelle; alle Zeilen im Abfrageergebnis werden partitioniert und kopiert. Wenn nicht angegeben, wird der Wert für die Kopieraktivität automatisch erkannt. Data Factory ersetzt ?AdfRangePartitionColumnName während der Ausführung durch den tatsächlichen Spaltennamen und die Wertebereiche für jede Partition und sendet die Daten an Azure SQL-Datenbank. Wenn Ihre Partitionsspalte „ID“ beispielsweise einen Wertebereich von 1 bis 100 hat und Sie die untere Grenze auf 20, die obere Grenze auf 80 und die Parallelkopie auf 4 festlegen, ruft der Dienst Daten nach 4 Partitionen ab – IDs im Bereich <=20, [21, 50], [51, 80] bzw. >=81. Hier finden Sie weitere Beispiele für verschiedene Szenarien: 1. Abfrage der gesamten Tabelle: SELECT * FROM <TableName> WHERE ?AdfDynamicRangePartitionCondition 2. Abfrage aus einer Tabelle mit Spaltenauswahl und zusätzlichen Where-Klausel-Filtern: SELECT <column_list> FROM <TableName> WHERE ?AdfDynamicRangePartitionCondition AND <your_additional_where_clause> 3. Abfragen mit Unterabfragen: SELECT <column_list> FROM (<your_sub_query>) AS T WHERE ?AdfDynamicRangePartitionCondition AND <your_additional_where_clause> 4. Abfrage mit Partition in Unterabfrage: SELECT <column_list> FROM (SELECT <your_sub_query_column_list> FROM <TableName> WHERE ?AdfDynamicRangePartitionCondition) AS T

Bewährte Methoden zum Laden von Daten mit Partitionierungsoption:

1. Wählen Sie eine aussagekräftige Spalte als Partitionsspalte (wie Primärschlüssel oder eindeutiger Schlüssel), um Datenabweichungen zu vermeiden.
2. Wenn die Tabelle eine integrierte Partition aufweist, verwenden Sie die Partitionsoption „Physikalische Partitionen der Tabelle“, um eine bessere Leistung zu erzielen.
3. Wenn Sie Azure Integration Runtime zum Kopieren von Daten verwenden, können Sie größere „Datenintegrationseinheiten (Data Integration Units, DIU)“ festlegen (> 4), um mehr Computingressourcen zu nutzen. Prüfen Sie dort die anwendbaren Szenarien.
4. „Grad der Kopierparallelität“ steuert die Partitionsnummern. Ein zu großer Wert schadet manchmal der Leistung. Deshalb wird empfohlen, diesen Wert wie folgt festzulegen: (DIU oder Anzahl der selbstgehosteten IR-Knoten) × (2 bis 4).

Beispiel: Vollständiges Laden aus einer großen Tabelle mit physischen Partitionen

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

Beispiel: Abfrage mit dynamischer Bereichspartition

"source": {
    "type": "AzureSqlSource",
    "query": "SELECT * FROM <TableName> WHERE ?AdfDynamicRangePartitionCondition 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>"
    }
}

Beispielabfrage zur Überprüfung der physischen Partition

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]'

Wenn die Tabelle eine physische Partition besitzt, würde „HasPartition“ wie folgt als „Yes“ (Ja) angezeigt werden.

Kopieren von Daten nach und aus Azure SQL-Datenbank

Beim Kopieren von Daten in Azure SQL-Datenbank ist möglicherweise ein anderes Schreibverhalten erforderlich:

• Anfügen: Meine Quelldaten enthalten nur neue Datensätze.
• Upsert: Meine Quelldaten umfassen sowohl Einfügungen als auch Aktualisierungen.
• Überschreiben: Ich möchte eine gesamte Dimensionstabelle jedes Mal neu laden.
• Schreiben von Daten mit benutzerdefinierter Logik: Ich benötige eine zusätzliche Verarbeitung vor dem endgültigen Einfügen in die Zieltabelle.

Lesen Sie die entsprechenden Abschnitte über die Konfiguration des Dienstes und bewährte Verfahren.

Anfügen von Daten

Das Anfügen von Daten ist das Standardverhalten dieses Senkenconnectors für Azure SQL-Datenbank. der Dienst führt eine Bulk-Einfügung durch, um effizient in Ihre Tabelle zu schreiben. Sie können die Quelle und Senke in der Kopieraktivität entsprechend konfigurieren.

Durchführen von Upsert für Daten

Die Kopieraktivität unterstützt ab sofort das native Laden von Daten in eine temporäre Datenbanktabelle und das anschließende Aktualisieren der Daten in der Senkentabelle, wenn der Schlüssel vorhanden ist. Andernfalls werden neue Daten eingefügt. Weitere Informationen zu Upsert-Einstellungen in Copy-Aktivitäten finden Sie unter Azure SQL-Datenbank als Senke.

Überschreiben der gesamten Tabelle

Sie können die preCopyScript-Eigenschaft in der Kopieraktivitätssenke konfigurieren. In diesem Fall führt Azure Data Factory für jede ausgeführte Copy-Aktivität zuerst das Skript aus. Dann wird der Kopiervorgang ausgeführt, um die Daten einzufügen. Beispiel: Um die gesamte Tabelle mit den neuesten Daten zu überschreiben, geben Sie ein Skript an, um zunächst alle Datensätze zu löschen, bevor die neuen Daten durch Massenladen aus der Quelle eingefügt werden.

Schreiben von Daten mit benutzerdefinierter Logik

Die Schritte zum Schreiben von Daten mit benutzerdefinierter Logik ähneln den im Abschnitt Durchführen von Upsert für Daten beschriebenen Schritten. Wenn Sie die Quelldaten vor dem endgültigen Einfügen in die Zieltabelle zusätzlich verarbeiten möchten, laden Sie sie in eine Stagingtabelle, und rufen Sie dann eine Aktivität der gespeicherten Prozedur oder eine gespeicherte Prozedur in der Senke der Kopieraktivität auf, um die Daten zu verarbeiten. Alternativ dazu können Sie auch einen Zuordnungsdatenfluss verwenden.

Aufrufen der gespeicherten Prozedur von der SQL-Senke

Beim Kopieren von Daten in eine Azure SQL-Datenbankinstanz können Sie auch eine vom Benutzer angegebene gespeicherte Prozedur mit zusätzlichen Parametern für jeden Batch der Quelltabelle konfigurieren und aufrufen. Das Feature der gespeicherten Prozedur nutzt Tabellenwertparameter.

Sie können eine gespeicherte Prozedur nutzen, wenn integrierte Kopiermechanismen nicht den Zweck erfüllen. Ein Beispiel hierfür ist ein Szenario, in dem Sie vor dem endgültigen Einfügen von Quelldaten in die Zieltabelle eine zusätzliche Verarbeitung anwenden möchten. Beispiele für eine zusätzliche Verarbeitung sind das Zusammenführen von Spalten, das Suchen nach zusätzlichen Werten und das Einfügen in mehr als eine Tabelle.

Das folgende Beispiel zeigt, wie Sie eine gespeicherte Prozedur verwenden, um einen einfachen Upsert-Vorgang in eine Tabelle in Azure SQL-Datenbank auszuführen. Im Beispiel wird angenommen, dass Eingabedaten vorhanden sind und die Senkentabelle Marketing drei Spalten enthält: ProfileID, State und Category. Führen Sie den Upsert-Vorgang basierend auf der Spalte ProfileID aus, und wenden Sie ihn nur auf die Kategorie „ProductA“ an.

1. Definieren Sie in Ihrer Datenbank den Tabellentyp mit dem gleichen Namen wie sqlWriterTableType. Das Schema des Tabellentyps muss mit dem Schema übereinstimmen, das von den Eingabedaten zurückgegeben wird.

   CREATE TYPE [dbo].[MarketingType] AS TABLE(
       [ProfileID] [varchar](256) NOT NULL,
       [State] [varchar](256) NOT NULL,
       [Category] [varchar](256) NOT NULL
   )
   

2. Definieren Sie die gespeicherte Prozedur in Ihrer Datenbank mit demselben Namen wie SqlWriterStoredProcedureName. Sie verarbeitet die Eingabedaten aus der angegebenen Quelle und führt sie mit der Ausgabetabelle zusammen. Der Parametername des Tabellentyps in der gespeicherten Prozedur entspricht dem im Dataset definierten 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
   

3. Definieren Sie in Azure Data Factory oder Synapse Pipeline den Abschnitt SQL-Senke in der Copy-Activity wie folgt:

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

Wenn Sie Daten mit Hilfe einer gespeicherten Prozedur in die Azure SQL-Datenbank schreiben, teilt die Senke die Quelldaten in Mini-Batches auf und fügt sie dann ein, so dass die zusätzliche Abfrage in der gespeicherten Prozedur mehrfach ausgeführt werden kann. Wenn Sie die Abfrage für die Kopieraktivität vor dem Schreiben der Daten in die Azure SQL-Datenbank ausführen möchten, sollten Sie sie nicht zur gespeicherten Prozedur hinzufügen, sondern in das Feld Skript vor dem Kopieren einfügen.

Eigenschaften von Mapping Data Flow

Beim Transformieren von Daten im Zuordnungsdatenfluss können Sie Tabellen in der Azure SQL-Datenbank lesen und in diese schreiben. Weitere Informationen finden Sie unter Quellentransformation und Senkentransformation in Zuordnungsdatenflüssen.

Quellentransformation

Spezifische Einstellungen für Azure SQL-Datenbank sind auf der Registerkarte Quellenoptionen der Quellentransformation verfügbar.

Eingabe: Wählen Sie aus, ob Sie Ihre Quelle auf eine Tabelle verweisen (Äquivalent von Select * from <table-name>) oder eine benutzerdefinierte SQL-Abfrage eingeben.

Query (Abfrage): Wenn Sie im Eingabefeld „Abfrage“ auswählen, geben Sie eine SQL-Abfrage für die Quelle ein. Diese Einstellung überschreibt jede Tabelle, die Sie im Dataset ausgewählt haben. Order By-Klauseln werden hier nicht unterstützt. Sie können aber eine vollständige SELECT FROM-Anweisung festlegen. Sie können auch benutzerdefinierte Tabellenfunktionen verwenden. select * from udfGetData() ist eine benutzerdefinierte Funktion in SQL, die eine Tabelle zurückgibt. Diese Abfrage generiert eine Quelltabelle, die Sie in Ihrem Datenfluss verwenden können. Die Verwendung von Abfragen stellt auch eine gute Möglichkeit dar, um die Zeilen für Tests oder Suchvorgänge zu verringern.

Tipp

Der allgemeine Tabellenausdruck (CTE) in SQL wird im Abfragemodus des Zuordnungsdatenflusses nicht unterstützt, da dieser Modus voraussetzt, dass Abfragen in der FROM-Klausel der SQL-Abfrage verwendet werden können, was CTEs jedoch nicht tun können. Um CTEs zu verwenden, müssen Sie eine gespeicherte Prozedur mithilfe der folgenden Abfrage erstellen:

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

Verwenden Sie dann den Gespeicherte Prozedur-Modus in der Quellentransformation des Zuordnungsdatenflusses, und legen Sie die @query wie im Beispiel with CTE as (select 'test' as a) select * from CTE fest. Daraufhin können Sie CTEs wie erwartet verwenden.

Gespeicherte Prozedur: Wählen Sie diese Option aus, wenn Sie eine Projektion und Quelldaten aus einer gespeicherten Prozedur generieren möchten, die von der Quelldatenbank ausgeführt wird. Sie können das Schema, den Prozedurnamen und die Parameter eingeben oder auf Aktualisieren klicken, um den Dienst aufzufordern, die Schemas und Prozedurnamen zu ermitteln. Anschließend können Sie auf „Importieren“ klicken, um alle Prozedurparameter mit dem Formular @paraName zu importieren.

• SQL-Beispiel: Select * from MyTable where customerId > 1000 and customerId < 2000
• Parametrisiertes SQL-Beispiel: "select * from {$tablename} where orderyear > {$year}"

Batchgröße: Geben Sie eine Batchgröße ein, um große Datenmengen in Leseblöcke zu segmentieren.

Isolationsstufe: Der Standardwert für SQL-Quellen in Mapping Data Flow lautet „Lesen nicht zugesichert“. Sie können die Isolationsstufe hier in einen der folgenden Werte ändern:

• Lesen zugesichert
• Lesen nicht zugesichert
• Wiederholbarer Lesevorgang
• Serialisierbar
• Keine (Isolationsstufe ignorieren)

Inkrementelle Extrahierung aktivieren: Verwenden Sie diese Option, um ADF anzuweisen, nur Zeilen zu verarbeiten, die sich seit der letzten Ausführung der Pipeline geändert haben. Um die inkrementelle Extrahierung mit Schemaabweichung zu aktivieren, wählen Sie Tabellen, die auf inkrementellen bzw. Wasserzeichenspalten basieren, anstelle von Tabellen aus, die für natives CDC (Change Data Capture) aktiviert sind.

Inkrementelle Spalte: Wenn Sie das Feature für die inkrementelle Extrahierung verwenden, müssen Sie die Datums-/Uhrzeitspalte oder numerische Spalte auswählen, die Sie als Grenzwert in der Quelltabelle verwenden möchten.

Natives Change Data Capture aktivieren (Vorschau): Verwenden Sie diese Option, um ADF mitzuteilen, dass nur Deltadaten verarbeitet werden, die seit dem letzten Ausführen der Pipeline von der SQL-Change Data Capture-Technologie erfasst wurden. Mit dieser Option werden die Deltadaten (einschließlich Einfügen, Aktualisieren und Löschen von Zeilen) automatisch geladen, ohne dass eine inkrementelle Spalte erforderlich ist. Sie müssen für Azure SQL DB Change Data Capture aktivieren, bevor Sie diese Option in ADF verwenden. Weitere Informationen zu dieser Option in ADF finden Sie unter Natives Change Data Capture.

Beginnen Sie mit dem Lesen von Anfang: Wenn Sie diese Option mit inkrementellen Extrakt festlegen, wird ADF angewiesen, alle Zeilen bei der ersten Ausführung einer Pipeline zu lesen, wobei der inkrementelle Extrakt aktiviert ist.

Senkentransformation

Spezifische Einstellungen für Azure SQL-Datenbank sind auf der Registerkarte Einstellungen der Senkentransformation verfügbar.

Updatemethode: Bestimmt, welche Vorgänge für das Datenbankziel zulässig sind. Standardmäßig sind lediglich Einfügevorgänge zulässig. Wenn Sie für Zeilen Update-, Upsert- oder Löschvorgänge verwenden möchten, fügen Sie zunächst eine Transformation zur Änderung von Zeilen hinzu, um Zeilen für diese Aktionen zu kennzeichnen. Für Update-, Upsert- und Löschvorgänge muss mindestens eine Schlüsselspalte festgelegt werden, um die Zeile zu bestimmen, die geändert werden soll.

Der Spaltenname, den Sie hier als Schlüssel wählen, wird vom Dienst als Teil der nachfolgenden Aktualisierung, Upsert, Löschung verwendet. Daher müssen Sie eine Spalte auswählen, die in der Senkenzuordnung vorhanden ist. Wenn Sie den Wert nicht in diese Schlüsselspalte schreiben möchten, klicken Sie auf „Skip writing key columns“ (Schreiben von Schlüsselspalten überspringen).

Sie können die hier verwendete Schlüsselspalte zum Aktualisieren der Azure SQL-Datenbank-Zieltabelle parametrisieren. Wenn Sie über mehrere Spalten für einen zusammengesetzten Schlüssel verfügen, klicken Sie auf „Benutzerdefinierter Ausdruck“. Sie können dann dynamischen Inhalt mithilfe des Datenfluss-Sprachausdruck hinzufügen, der ein Array von Zeichenfolgen mit Spaltennamen für einen zusammengesetzten Schlüssel enthalten kann.

Tabellenaktion: Bestimmt, ob die Zieltabelle vor dem Schreiben neu erstellt werden soll oder alle Zeilen aus der Zieltabelle entfernt werden sollen.

• Keine: Es wird keine Aktion an der Tabelle vorgenommen.
• Neu erstellen: Die Tabelle wird gelöscht und neu erstellt. Erforderlich, wenn eine neue Tabelle dynamisch erstellt wird.
• Abschneiden: Alle Zeilen werden aus der Zieltabelle entfernt.

Batchgröße: Steuert, wie viele Zeilen in die einzelnen Buckets geschrieben werden. Durch größere Batches werden zwar Komprimierung und Arbeitsspeicheroptimierung verbessert, beim Zwischenspeichern von Daten besteht aber die Gefahr, dass Ausnahmen wegen unzureichenden Arbeitsspeichers auftreten.

Verwenden von TempDB: Standardmäßig verwendet der Dienst eine globale temporäre Tabelle, um Daten als Teil des Ladevorgangs zu speichern. Sie können alternativ die Option "TempDB verwenden" deaktivieren und stattdessen den Dienst bitten, die temporäre Tabelle in einer Benutzerdatenbank zu speichern, die sich in der Datenbank befindet, die für diese Senke verwendet wird.

Pre- und Post SQL-Skripts: Geben Sie mehrzeilige SQL-Skripts ein, die ausgeführt werden, bevor Daten in die Senkendatenbank geschrieben werden (Vorverarbeitung) und danach (Nachbearbeitung).

Tipp

1. Es wird empfohlen, einzelne Batchskripts mit mehreren Befehlen in mehrere Batches aufzuteilen.
2. In einem Batch können nur DDL- (Data Definition Language) und DML-Anweisungen (Data Manipulation Language) ausgeführt werden, die eine einfache Updatezählung zurückgeben. Weitere Informationen finden Sie unter Ausführen von Batchvorgängen.

Fehlerzeilenbehandlung

Beim Schreiben in Azure SQL-Datenbank können aufgrund von Einschränkungen durch das Ziel Fehler bei bestimmten Datenzeilen auftreten. Häufige Fehler sind z. B. folgende:

• Zeichenfolgen- oder Binärdaten würden in der Tabelle abgeschnitten.
• Der Wert NULL kann nicht in die Spalte einfügt werden.
• Die INSERT-Anweisung steht in Konflikt mit der CHECK-Einschränkung.

Standardmäßig scheitert eine Datenflussausführung beim ersten erhaltenen Fehler. Sie können die Option Bei Fehler fortsetzen auswählen, die einen Abschluss des Datenflusses auch dann ermöglicht, wenn einzelne Zeilen Fehler aufweisen. Der Dienst bietet Ihnen verschiedene Optionen, mit denen Sie diese Fehlerzeilen behandeln können.

Transaktionscommit: Wählen Sie aus, ob Ihre Daten in einer einzelnen Transaktion oder in Batches geschrieben werden. Eine einzelne Transaktion führt zu einer schlechteren Leistung, doch sind keine geschriebenen Daten für andere sichtbar, bis die Transaktion abgeschlossen ist.

Abgelehnte Daten ausgeben: Wenn diese Option aktiviert ist, können Sie die Fehlerzeilen in eine CSV-Datei in Azure Blob Storage oder ein Azure Data Lake Storage Gen2-Konto Ihrer Wahl ausgeben. Dadurch werden die Fehlerzeilen mit drei zusätzlichen Spalten geschrieben: dem SQL-Vorgang wie INSERT oder UPDATE, dem Datenfluss-Fehlercode und der Fehlermeldung für die Zeile.

Bericht bei Fehler als erfolgreich markieren: Wenn diese Option aktiviert ist, wird der Datenfluss als erfolgreich markiert, auch wenn Fehlerzeilen gefunden werden.

Datentypzuordnung für Azure SQL-Datenbank

Beim Kopieren von Daten aus bzw. nach Azure SQL-Datenbank werden die folgenden Zuordnungen von Azure SQL-Datenbank-Datentypen zu Azure Data Factory-Zwischendatentypen verwendet. Die gleichen Zuordnungen werden von der Synapse-Pipelinefunktion verwendet, die Azure Data Factory direkt implementiert. Informationen dazu, wie die Kopieraktivität das Quellschema und den Datentyp zur Senke zuordnet, finden Sie unter Schema- und Datentypzuordnungen.

Azure SQL-Datenbank-Datentyp	Data Factory-Zwischendatentyp
BIGINT	Int64
BINARY	Byte[]
bit	Boolean
char	String, Char[]
date	Datetime
Datetime	Datetime
datetime2	Datetime
Datetimeoffset	DateTimeOffset
Decimal	Decimal
FILESTREAM attribute (varbinary(max))	Byte[]
Float	Double
image	Byte[]
INT	Int32
money	Decimal
NCHAR	String, Char[]
ntext	String, Char[]
NUMERIC	Decimal
NVARCHAR	String, Char[]
real	Single
rowversion	Byte[]
smalldatetime	Datetime
SMALLINT	Int16
SMALLMONEY	Decimal
sql_variant	Object
text	String, Char[]
time	TimeSpan
timestamp	Byte[]
TINYINT	Byte
UNIQUEIDENTIFIER	Guid
varbinary	Byte[]
varchar	String, Char[]
Xml	String

Hinweis

Für Datentypen, die dem Zwischendatentyp „Decimal“ zugeordnet sind, unterstützt die Kopieraktivität derzeit eine Genauigkeit von bis zu 28. Daten mit einer höheren Genauigkeit als 28 müssen in SQL-Abfragen ggf. in eine Zeichenfolge konvertiert werden.

Eigenschaften der Lookup-Aktivität

Ausführliche Informationen zu den Eigenschaften finden Sie unter Lookup-Aktivität.

Eigenschaften der GetMetadata-Aktivität

Ausführliche Informationen zu den Eigenschaften finden Sie unter GetMetadata-Aktivität.

Verwenden von Always Encrypted

Führen Sie beim Kopieren von Daten aus bzw. in Azure SQL-Datenbank mit Always Encrypted die folgenden Schritte aus:

1. Speichern Sie den Spalten-Hauptschlüssel (Column Master Key, CMK) in einem Azure Key Vault. Weitere Informationen: Konfigurieren von Always Encrypted mithilfe von Azure Key Vault

2. Stellen Sie sicher, dass der Zugriff auf den Schlüsseltresor gewährt wird, in dem der Spaltenhauptschlüssel (Column Master Key, CMK) gespeichert ist. Die erforderlichen Berechtigungen finden Sie in diesem Artikel.

3. Erstellen Sie einen verknüpften Dienst, um eine Verbindung mit der SQL-Datenbank herzustellen und aktivieren Sie die „Always Encrypted“-Funktion mithilfe einer verwalteten Identität oder eines Dienstprinzipals.

Hinweis

Always Encrypted für Azure SQL-Datenbank unterstützt die folgenden Szenarien:

1. Die Quell- oder Senkendatenspeicher verwenden die verwaltete Identität oder den Dienstprinzipal als Schlüsselanbieter-Authentifizierungstyp.
2. Sowohl Quell- als auch Senkendatenspeicher verwenden die verwaltete Identität als Schlüsselanbieter-Authentifizierungstyp.
3. Sowohl Quell- als auch Senkendatenspeicher verwenden denselben Dienstprinzipal als Schlüsselanbieter-Authentifizierungstyp.

Hinweis

Derzeit wird Always Encrypted für Azure SQL-Datenbank nur für die Quelltransformation in Zuordnungsdatenflüssen unterstützt.

Natives Change Data Capture

Azure Data Factory kann native Change Data Capture-Funktionen für SQL Server, Azure SQL DB und Azure SQL MI unterstützen. Die geänderten Daten einschließlich Einfügen, Aktualisieren und Löschen von Zeilen in SQL-Speichern können durch den ADF-Zuordnungsdatenfluss automatisch erkannt und extrahiert werden. Mit der No-Code-Erfahrung im Zuordnungsdatenfluss können Benutzer leicht ein Datenreplikationsszenario aus SQL-Speichern erreichen, indem sie eine Datenbank als Zielspeicher anhängen. Darüber hinaus können Benutzer auch eine beliebige Datentransformationslogik zwischenschalten, um ein inkrementelles ETL-Szenario aus SQL-Speichern zu erreichen.

Stellen Sie sicher, dass Sie die Pipeline und den Aktivitätsnamen unverändert lassen, damit der Prüfpunkt von ADF aufgezeichnet werden kann, damit Sie geänderte Daten aus der letzten Ausführung automatisch erhalten. Wenn Sie ihren Pipelinenamen oder Aktivitätsnamen ändern, wird der Prüfpunkt zurückgesetzt, was dazu führt, dass Sie bei der nächsten Ausführung von Anfang an beginnen oder Änderungen von jetzt erhalten. Wenn Sie den Pipelinenamen oder Aktivitätsnamen ändern möchten, aber weiterhin den Prüfpunkt beibehalten möchten, um geänderte Daten aus der letzten Ausführung automatisch abzurufen, verwenden Sie hierzu bitte Ihren eigenen Prüfpunktschlüssel in der Datenflussaktivität.

Wenn Sie die Pipeline debuggen, funktioniert dieses Feature genauso. Beachten Sie, dass der Prüfpunkt zurückgesetzt wird, wenn Sie Ihren Browser während der Debug-Ausfürung aktualisieren. Wenn Sie mit dem Pipelineergebnis der Debug-Ausführung zufrieden sind, können Sie die Pipeline veröffentlichen und auslösen. Wenn Sie ihre veröffentlichte Pipeline zum ersten Mal auslösen, wird sie automatisch von Anfang an neu gestartet oder erhält von nun an Änderungen.

Im Abschnitt „Überwachung“ haben Sie immer die Möglichkeit, eine Pipeline erneut ausführen. Dabei werden die geänderten Daten immer vom vorherigen Prüfpunkt des ausgewählten Pipelinelaufs erfasst.

Beispiel 1:

Wenn Sie eine Quellentransformation, die ein SQL CDC-fähiges Dataset referenziert, direkt mit einer Senkentransformation verketten, die eine Datenbank in einem Zuordnungsdatenfluss referenziert, werden die in der SQL-Quelle vorgenommenen Änderungen automatisch auf die Zieldatenbank angewendet, sodass Sie leicht ein Datenreplikationsszenario zwischen Datenbanken erhalten. Sie können die Updatemethode in der Senkentransformation verwenden, um auszuwählen, ob Sie in der Zieldatenbank Einfügen, Aktualisieren oder Löschen zulassen möchten. Unten sehen Sie das Beispielskript im Zuordnungsdatenfluss.

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

Beispiel 2:

Wenn Sie ein ETL-Szenario anstelle der Datenreplikation zwischen Datenbanken über SQL CDC aktivieren möchten, können Sie im Zuordnungsdatenfluss Ausdrücke einschließlich isInsert(1), isUpdate(1) und isDelete(1) verwenden, um die Zeilen mit unterschiedlichen Vorgangstypen zu unterscheiden. Nachfolgend sehen Sie eines der Beispielskripts für den Zuordnungsdatenfluss zur Ableitung einer Spalte mit dem Wert 1 zur Kennzeichnung eingefügter Zeilen, 2 zur Kennzeichnung aktualisierter Zeilen und 3 zur Kennzeichnung gelöschter Zeilen für nachgeschaltete Transformationen zur Verarbeitung der Deltadaten.

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

Bekannte Einschränkung:

• Nur Nettoänderungen von SQL CDC werden von ADF über cdc.fn_cdc_get_net_changes_ geladen.

Zugehöriger Inhalt

Eine Liste der Datenspeicher, die als Quellen und Senken für die Copy-Aktivität unterstützt werden, finden Sie unter Unterstützte Datenspeicher und Formate.