Freigeben über


Kopieren und Umwandeln von Daten in Azure SQL Managed Instance mit Azure Data Factory oder 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!

Dieser Artikel beschreibt, wie Sie mit der Copy-Aktivität Daten von und zu Azure SQL Managed Instance kopieren und mit dem Datenfluss Daten in Azure SQL Managed Instance umwandeln können. Wenn Sie mehr erfahren möchten, lesen Sie die Einführungsartikel zu Azure Data Factory und Synapse Analytics.

Unterstützte Funktionen

Dieser Connector für Azure SQL Managed Instance wird für die folgenden Funktionen unterstützt:

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

① 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 der SQL MI-Quelle entscheiden. Einzelheiten finden Sie im Abschnitt Paralleles Kopieren aus SQL MI.
  • Als Senke das automatische Erstellen einer Zieltabelle (sofern nicht vorhanden) basierend auf dem Quellschema. Außerdem das Anfügen von Daten an eine Tabelle oder das Aufrufen einer gespeicherten Prozedur mit benutzerdefinierter Logik während des Kopiervorgangs.

Voraussetzungen

Für den Zugriff auf die SQL Managed Instance öffentlichen Endpunkt können Sie eine verwaltete Azure-Integrationslaufzeit verwenden. Stellen Sie sicher, dass Sie den öffentlichen Endpunkt aktivieren und auch den öffentlichen Endpunktverkehr in der Netzwerksicherheitsgruppe zulassen, damit der Dienst eine Verbindung zu Ihrer Datenbank herstellen kann. Weitere Informationen finden Sie in dieser Anleitung.

Richten Sie für den Zugriff auf den privaten Endpunkt der verwalteten SQL-Instanz eine selbstgehostete Integration Runtime ein, die Zugriff auf die Datenbank hat. Wenn Sie die selbstgehostete Integration Runtime im gleichen virtuellen Netzwerk wie Ihre verwaltete Instanz bereitstellen, stellen Sie sicher, dass sich der Computer mit der Integration Runtime in einem anderen Subnetz als die verwaltete Instanz befindet. Wenn Sie die selbstgehostete Integration Runtime in einem anderen virtuellen Netzwerk bereitstellen als die verwaltete Instanz, empfiehlt sich ein Peering virtueller Netzwerke oder eine Verbindung zwischen den virtuellen Netzwerken. Weitere Informationen finden Sie unter Herstellen einer Verbindung zwischen einer Anwendung und einer verwalteten SQL-Instanz.

Erste Schritte

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

Erstellen eines verknüpften Diensts mit einer verwalteten Azure SQL-Instanz über die Benutzeroberfläche

Verwenden Sie die folgenden Schritte, um einen verknüpften Dienst mit einer verwalteten SQL-Instanz 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“:

  2. Suchen Sie nach SQL und wählen Sie den von Azure SQL Server verwalteten Instanz-Connector aus.

    Ein Screenshot, der den von Azure SQL Server verwalteten Instanz-Connector zeigt.

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

    Ein Screenshot, der die Konfiguration des verknüpften Diensts für eine von SQL verwaltete Instanz zeigt.

Details zur Connector-Konfiguration

Die folgenden Abschnitte enthalten Details zu Eigenschaften, die zum Definieren von Azure Data Factory-Entitäten verwendet werden, die speziell für den Connector für die verwaltete SQL-Instanz verfügbar sind.

Eigenschaften des verknüpften Diensts

Die empfohlene Version des Konnektors für Azure SQL Managed Instance unterstützt TLS 1.3. In diesem Abschnitt erfahren Sie, wie Sie die Version des Konnektors für Azure SQL Managed Instance von der Legacy-Version aktualisieren. Einzelheiten zu den Eigenschaften finden Sie in den entsprechenden Abschnitten.

Diese generischen Eigenschaften werden für einen verknüpften Dienst von Azure SQL Managed Instance unterstützt, wenn Sie die empfohlene Version anwenden:

Eigenschaft Beschreibung Erforderlich
type Die type-Eigenschaft muss auf AzureSqlMI festgelegt werden. Ja
server Name oder Netzwerkadresse der SQL Server-Instanz, mit der Sie eine Verbindung herstellen möchten Ja
database Der Name der Datenbank. Ja
authenticationType Der Typ, der für die Authentifizierung verwendet wird. Die zulässigen Werte lauten: SQL (Standard), ServicePrincipal, SystemAssignedManagedIdentity und UserAssignedManagedIdentity. Einzelheiten zu bestimmten Eigenschaften und Voraussetzungen finden Sie im entsprechenden Authentifizierungsabschnitt. Ja
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. No
encrypt Geben Sie an, ob die TLS-Verschlüsselung für alle Daten erforderlich ist, die zwischen dem Client und dem Server gesendet werden. Optionen: obligatorisch (für TRUE, Standard)/optional (für FALSE)/streng No
trustServerCertificate Geben Sie an, ob der Kanal verschlüsselt wird, während die Zertifikatskette zum Überprüfen der Vertrauensstellung umgangen wird. No
hostNameInCertificate Hostname, der beim Validieren des Serverzertifikats für die Verbindung verwendet werden soll. Falls nicht angegeben, wird der Servername für die Zertifikatvalidierung verwendet No
connectVia Diese Integration Runtime wird zum Herstellen einer Verbindung mit dem Datenspeicher verwendet. Sie können eine selbst gehostete Integrationslaufzeit oder eine Azure-Integrationslaufzeit verwenden, wenn Ihre verwaltete Instanz einen öffentlichen Endpunkt hat und dem Dienst den Zugriff darauf erlaubt. Wenn kein Wert angegeben ist, wird die standardmäßige Azure Integration Runtime verwendet. Ja

Weitere Verbindungseigenschaften finden Sie in der folgenden Tabelle:

Eigenschaft Beschreibung Erforderlich
applicationIntent Workloadtyp der Anwendung beim Herstellen einer Verbindung mit einem Server. Zulässige Werte sind ReadOnly und ReadWrite. No
connectTimeout Dauer (in Sekunden), die auf eine Verbindung mit dem Server gewartet wird, bevor der Versuch abgebrochen wird und ein Fehler generiert wird No
connectRetryCount Anzahl der Neuverbindungsversuche, nachdem ein Leerlaufverbindungsfehler erkannt wurde. Der Wert sollte eine ganze Zahl zwischen 0 und 255 sein. No
connectRetryInterval Dauer (in Sekunden) zwischen jedem Neuverbindungsversuch, nachdem ein Leerlaufverbindungsfehler erkannt wurde. Der Wert sollte eine ganze Zahl zwischen 1 und 60 sein. No
loadBalanceTimeout Mindestdauer (in Sekunden), die eine Verbindung im Verbindungspool verbleiben soll, bevor die Verbindung abgebrochen wird. No
commandTimeout Standardwartezeit (in Sekunden), die gewartet werden soll, bis der Versuch einer Befehlsausführung beendet und ein Fehler generiert wird No
integratedSecurity Die zulässigen Werte lauten true oder false. Geben Sie beim Wert false an, ob „userName“ und „password“ in der Verbindung angegeben werden. Geben Sie beim Wert true an, ob die aktuellen Anmeldeinformationen für das Windows-Konto für die Authentifizierung verwendet werden. No
failoverPartner Name oder Adresse des Partnerservers, mit dem eine Verbindung hergestellt werden soll, wenn der primäre Server ausgefallen ist No
maxPoolSize Im Verbindungspool zulässige Höchstanzahl der Verbindungen für die angegebene Verbindung No
minPoolSize Im Verbindungspool zulässige Mindestanzahl der Verbindungen für die angegebene Verbindung. No
multipleActiveResultSets Die zulässigen Werte lauten true oder false. Wenn Sie true angeben, kann eine Anwendung mehrere aktive Resultsets (MARS) verwalten. Wenn Sie false angeben, muss die Anwendung alle Resultsets aus einem Batch verarbeiten oder abbrechen, bevor andere Batches über diese Verbindung ausgeführt werden können. No
multiSubnetFailover Die zulässigen Werte lauten true oder false. Wenn Ihre Anwendung eine Verbindung mit einer AlwaysOn-Verfügbarkeitsgruppe in unterschiedlichen Subnetzen herstellt, ermöglicht das Festlegen dieser Eigenschaft auf true eine schnellere Erkennung des derzeit aktiven Servers und eine schnellere Verbindung mit dem Server. No
packetSize Größe der Netzwerkpakete (in Byte), die bei der Kommunikation mit einer Instanz des Servers verwendet werden No
pooling Die zulässigen Werte lauten true oder false. Wenn Sie true angeben, wird die Verbindung gepoolt. Wenn Sie false angeben, wird die Verbindung bei jeder Anforderung der Verbindung explizit geöffnet. No

SQL-Authentifizierung

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

Eigenschaft Beschreibung Erforderlich
userName Benutzername, der zum Herstellen einer Verbindung mit dem Server verwendet wird. Ja
Kennwort Das Kennwort für den Benutzernamen. Markieren Sie dieses Feld als SecureString, um es sicher zu speichern. Alternativ können Sie auf ein in Azure Key Vault gespeichertes Geheimnis verweisen. Ja

Beispiel 1: Verwenden der SQL-Authentifizierung

{
    "name": "AzureSqlMILinkedService",
    "properties": {
        "type": "AzureSqlMI",
        "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"
        }
    }
}

Beispiel 2: Verwenden der SQL-Authentifizierung mit einem Kennwort in Azure Key Vault

{
    "name": "AzureSqlMILinkedService",
    "properties": {
        "type": "AzureSqlMI",
        "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"
        }
    }
}

Beispiel 3: Verwenden der SQL Authentifizierung mit Always Encrypted

{
    "name": "AzureSqlMILinkedService",
    "properties": {
        "type": "AzureSqlMI",
        "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"
        }
    }
}

Dienstprinzipalauthentifizierung

Um die Dienstprinzipalauthentifizierung zu verwenden, geben Sie zusätzlich zu den im vorherigen Abschnitt beschriebenen generischen Eigenschaften die folgenden Eigenschaften an

Eigenschaft Beschreibung Erforderlich
servicePrincipalId Geben Sie die Client-ID der Anwendung an. Ja
servicePrincipalCredential Die Anmeldeinformationen für den Dienstprinzipal. 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
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 des Diensts verwendet.
No

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

  1. Folgen Sie den Schritten zum Bereitstellen eines Microsoft Entra-Administrators für Ihre verwaltete Instanz.

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

    • Anwendungs-ID
    • Anwendungsschlüssel
    • Mandanten-ID
  3. Erstellen Sie Anmeldungen für den Dienstprinzipal. Stellen Sie in SQL Server Management Studio (SSMS) über ein SQL Server-Konto (ein SysAdmin-Konto) eine Verbindung mit Ihrer verwalteten Instanz her. Führen Sie in der Masterdatenbank den folgenden T-SQL-Befehl aus:

    CREATE LOGIN [your application name] FROM EXTERNAL PROVIDER
    
  4. 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 kopieren möchten, und führen Sie den folgenden T-SQL-Befehl aus:

    CREATE USER [your application name] FROM EXTERNAL PROVIDER
    
  5. Gewähren Sie dem Dienstprinzipal 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 e.g. db_owner] ADD MEMBER [your application name]
    
  6. Konfigurieren Sie einen mit SQL Managed Instance verknüpften Dienst.

Beispiel: Verwenden der Dienstprinzipalauthentifizierung

{
    "name": "AzureSqlDbLinkedService",
    "properties": {
        "type": "AzureSqlMI",
        "typeProperties": {
            "server": "<name or network address of the SQL server instance>",
            "database": "<database name>",
            "encrypt": "<encrypt>",
            "trustServerCertificate": false,
            "hostNameInCertificate": "<host name>",
            "authenticationType": "ServicePrincipal",
            "servicePrincipalId": "<service principal id>",
            "servicePrincipalCredential": {
                "type": "SecureString",
                "value": "<application 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 Data Factory oder ein Synapse-Arbeitsbereich kann einer systemseitig zugewiesenen verwalteten Identität für Azure-Ressourcen zugeordnet werden, die den Dienst für die Authentifizierung gegenüber anderen Azure-Diensten darstellt. Sie können diese verwaltete Identität für die Authentifizierung einer verwalteten SQL-Instanz verwenden. Der benannte Dienst kann unter Verwendung dieser Identität auf Ihre Datenbank zugreifen und Daten aus ihr oder in sie 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. Folgen Sie den Schritten zum Bereitstellen eines Microsoft Entra-Administrators für Ihre verwaltete Instanz.

  2. Erstellen Sie Anmeldungen für die systemseitig zugewiesene verwaltete Identität. Stellen Sie in SQL Server Management Studio (SSMS) über ein SQL Server-Konto (ein SysAdmin-Konto) eine Verbindung mit Ihrer verwalteten Instanz her. Führen Sie in der Masterdatenbank den folgenden T-SQL-Befehl aus:

    CREATE LOGIN [your_factory_or_workspace_ name] FROM EXTERNAL PROVIDER
    
  3. Erstellen Sie Benutzer der eigenständigen Datenbank für die systemseitig zugewiesene verwaltete Identität. Stellen Sie eine Verbindung mit der Datenbank her, aus der bzw. in die Sie Daten kopieren möchten, und führen Sie den folgenden T-SQL-Befehl aus:

    CREATE USER [your_factory_or_workspace_name] FROM EXTERNAL PROVIDER
    
  4. Gewähren Sie der systemseitig zugewiesenen verwalteten Identität erforderliche 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 e.g. db_owner] ADD MEMBER [your_factory_or_workspace_name]
    
  5. Konfigurieren Sie einen mit SQL Managed Instance verknüpften Dienst.

Beispiel: Verwendet Authentifizierung mit einer systemseitig zugewiesenen verwalteten Identität

{
    "name": "AzureSqlDbLinkedService",
    "properties": {
        "type": "AzureSqlMI",
        "typeProperties": {
            "server": "<name or network address of the SQL server instance>",
            "database": "<database name>",
            "encrypt": "<encrypt>",
            "trustServerCertificate": false,
            "authenticationType": "SystemAssignedManagedIdentity"
        },
        "connectVia": {
            "referenceName": "<name of Integration Runtime>",
            "type": "IntegrationRuntimeReference"
        }
    }
}

Authentifizierung mit einer benutzerseitig zugewiesenen verwalteten Identität

Eine Data Factory oder ein Synapse-Arbeitsbereich kann einer benutzerseitig zugewiesenen verwalteten Identität zugeordnet werden, die den Dienst für die Authentifizierung gegenüber anderen Azure-Diensten darstellt. Sie können diese verwaltete Identität für die Authentifizierung einer verwalteten SQL-Instanz verwenden. Der benannte Dienst kann unter Verwendung dieser Identität auf Ihre Datenbank zugreifen und Daten aus ihr oder in sie 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. Folgen Sie den Schritten zum Bereitstellen eines Microsoft Entra-Administrators für Ihre verwaltete Instanz.

  2. Erstellen Sie Anmeldungen für die benutzerseitig zugewiesene verwaltete Identität. Stellen Sie in SQL Server Management Studio (SSMS) über ein SQL Server-Konto (ein SysAdmin-Konto) eine Verbindung mit Ihrer verwalteten Instanz her. Führen Sie in der Masterdatenbank den folgenden T-SQL-Befehl aus:

    CREATE LOGIN [your_factory_or_workspace_ name] FROM EXTERNAL PROVIDER
    
  3. 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 kopieren möchten, und führen Sie den folgenden T-SQL-Befehl aus:

    CREATE USER [your_factory_or_workspace_name] FROM EXTERNAL PROVIDER
    
  4. 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 e.g. db_owner] ADD MEMBER [your_factory_or_workspace_name]
    
  5. 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.

  6. Konfigurieren Sie einen mit SQL Managed Instance verknüpften Dienst.

Beispiel: Verwendet Authentifizierung mit benutzerseitig zugewiesener verwalteter Identität

{
    "name": "AzureSqlDbLinkedService",
    "properties": {
        "type": "AzureSqlMI",
        "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"
        }
    }
}

Legacy-Version

Diese generischen Eigenschaften werden für einen verknüpften Dienst von Azure SQL Managed Instance unterstützt, wenn Sie die Legacy- Version anwenden:

Eigenschaft Beschreibung Erforderlich
type Die type-Eigenschaft muss auf AzureSqlMI festgelegt werden. Ja
connectionString Diese Eigenschaft gibt die connectionString-Informationen an, die zum Herstellen einer Verbindung mit der verwalteten Instanz über die SQL-Authentifizierung benötigt werden. Weitere Informationen finden Sie in den folgenden Beispielen.
Der Standardport ist 1433. Wenn Sie die verwaltete SQL-Instanz mit einem öffentlichen Endpunkt verwenden, geben Sie explizit Port 3342 an.
Sie können auch ein Kennwort in Azure Key Vault speichern. Bei Verwendung der SQL-Authentifizierung pullen Sie die password-Konfiguration aus der Verbindungszeichenfolge. Weitere Informationen finden Sie unter Speichern von Anmeldeinformationen in Azure Key Vault.
Ja
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 Abschnitt 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 eine selbst gehostete Integrationslaufzeit oder eine Azure-Integrationslaufzeit verwenden, wenn Ihre verwaltete Instanz einen öffentlichen Endpunkt hat und dem Dienst den Zugriff darauf erlaubt. Wenn kein Wert angegeben ist, wird die standardmäßige Azure Integration Runtime verwendet. Ja

Informationen zu verschiedenen Authentifizierungstypen finden Sie in den folgenden Abschnitten zu bestimmten Eigenschaften und Voraussetzungen:

SQL-Authentifizierung für die Legacy-Version

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

Dienstprinzipalauthentifizierung für die Legacy-Version

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
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.
No

Außerdem müssen Sie die Schritte im Abschnitt Dienstprinzipalauthentifizierung ausführen, um die entsprechende Berechtigung zu erteilen.

Authentifizierung mit einer systemseitig zugewiesenen verwalteten Identität für die Legacyversion

Um die Authentifizierung mit einer systemseitig zugewiesenen verwalteten Identität zu verwenden, führen Sie den gleichen Schritt für die empfohlene Version im Abschnitt Authentifizierung mit einer systemseitig zugewiesenen verwalteten Identität aus.

Authentifizierung mit einer benutzerseitig zugewiesenen verwalteten Identität für die Legacyversion

Um die Authentifizierung mit einer benutzerseitig zugewiesenen verwalteten Identität zu verwenden, führen Sie den gleichen Schritt für die empfohlene Version im Abschnitt Authentifizierung mit einer benutzerseitig zugewiesenen verwalteten Identität aus.

Dataset-Eigenschaften

Eine vollständige Liste mit den Abschnitten und Eigenschaften, die zum Definieren von Datasets zur Verfügung stehen, finden Sie im Artikel zu Datasets. Dieser Abschnitt enthält eine Liste mit Eigenschaften, die vom Dataset der verwalteten SQL-Instanz unterstützt werden.

Zum Kopieren von Daten in die bzw. aus der verwaltete(n) SQL-Instanz werden die folgenden Eigenschaften unterstützt:

Eigenschaft Beschreibung Erforderlich
type Die type-Eigenschaft des Datasets muss auf AzureSqlMITable festgelegt werden. 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

{
    "name": "AzureSqlMIDataset",
    "properties":
    {
        "type": "AzureSqlMITable",
        "linkedServiceName": {
            "referenceName": "<SQL Managed Instance 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 mit den Abschnitten und Eigenschaften zum Definieren von Aktivitäten finden Sie im Artikel Pipelines. Dieser Abschnitt enthält eine Liste mit Eigenschaften, die von der Quelle und der Senke der verwalteten SQL-Instanz unterstützt werden.

Verwaltete SQL-Instanz als Quelle

Tipp

Weitere Informationen zum effizienten Laden von Daten aus SQL MI mittels Datenpartitionierung finden Sie unter Paralleles Kopieren aus SQL MI.

Zum Kopieren von Daten aus der verwalteten SQL-Instanz werden im Abschnitt für die Kopieraktivität der Quelle die folgenden Eigenschaften unterstützt:

Eigenschaft Beschreibung Erforderlich
type Die type-Eigenschaft der Quelle der Kopieraktivität muss auf SqlMISource festgelegt werden. Ja
sqlReaderQuery Diese Eigenschaft verwendet die benutzerdefinierte SQL-Abfrage zum Lesen von Daten. z. B. select * from MyTable. Nein
sqlReaderStoredProcedureName Diese Eigenschaft ist der 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 Diese Parameter werden für die gespeicherte Prozedur verwendet.
Zulässige Werte sind Namen oder Name-Wert-Paare. Die Namen und die Groß-/Kleinschreibung der Parameter müssen denen 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 Gibt die Datenpartitionierungsoptionen an, mit denen Daten aus SQL MI geladen werden.
Zulässige Werte sind: None (Standardwert), PhysicalPartitionsOfTable und DynamicRange.
Wenn eine Partitionsoption aktiviert ist (nicht None), wird der Grad an Parallelität zum gleichzeitigen Laden von Daten von SQL MI durch die Einstellung parallelCopies für die 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. Ohne Angabe 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 ?DfDynamicRangePartitionCondition 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 SqlMISource angegeben ist, führt die Kopieraktivität diese Abfrage für die Quelle der verwalteten SQL-Instanz 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: Verwenden einer SQL-Abfrage

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

Beispiel: Verwenden einer gespeicherten Prozedur

"activities":[
    {
        "name": "CopyFromAzureSqlMI",
        "type": "Copy",
        "inputs": [
            {
                "referenceName": "<SQL Managed Instance input dataset name>",
                "type": "DatasetReference"
            }
        ],
        "outputs": [
            {
                "referenceName": "<output dataset name>",
                "type": "DatasetReference"
            }
        ],
        "typeProperties": {
            "source": {
                "type": "SqlMISource",
                "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

Verwaltete SQL-Instanz als Senke

Tipp

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

Zum Kopieren von Daten in die verwaltete SQL-Instanz werden im Abschnitt für die Kopieraktivität der Senke die folgenden Eigenschaften unterstützt:

Eigenschaft Beschreibung Erforderlich
type Die type-Eigenschaft der Senke der Kopieraktivität muss auf SqlMISink festgelegt werden. Ja
preCopyScript Diese Eigenschaft gibt eine SQL-Abfrage für die Kopieraktivität an, die vor dem Schreiben von Daten in die verwaltete SQL-Instanz ausgeführt werden soll. Sie wird pro Ausführung der Kopieraktivität nur einmal aufgerufen. Sie können diese Eigenschaft nutzen, um die vorab geladenen 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ässige Werte sind Integer-Werte für die 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
 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 die verwaltete Azure SQL-Datenbank-Instanz 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 eine 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": "CopyToAzureSqlMI",
        "type": "Copy",
        "inputs": [
            {
                "referenceName": "<input dataset name>",
                "type": "DatasetReference"
            }
        ],
        "outputs": [
            {
                "referenceName": "<SQL Managed Instance output dataset name>",
                "type": "DatasetReference"
            }
        ],
        "typeProperties": {
            "source": {
                "type": "<source type>"
            },
            "sink": {
                "type": "SqlMISink",
                "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-MI-Senke.

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

Beispiel 3: Upsert-Daten

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

Paralleles Kopieren aus SQL MI

Der Azure SQL Managed Instance-Connector 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.

Screenshot der Partitionierungsoptionen

Wenn Sie partitioniertes Kopieren aktivieren, führt die Kopieraktivität parallele Abfragen für Ihre SQL MI-Quelle aus, um Daten anhand von Partitionen zu laden. Der Parallelitätsgrad wird über die Einstellung parallelCopies der Kopieraktivität gesteuert. Wenn Sie z. B. 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 SQL MI abruft.

Es wird empfohlen, das parallele Kopieren mit Datenpartitionierung zu aktivieren. Das gilt insbesondere, wenn Sie große Datenmengen aus Ihrer SQL MI-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 ?DfDynamicRangePartitionCondition 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.

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 ?DfDynamicRangePartitionCondition
2. Abfrage aus einer Tabelle mit Spaltenauswahl und zusätzlichen Where-Klausel-Filtern:
SELECT <column_list> FROM <TableName> WHERE ?DfDynamicRangePartitionCondition AND <your_additional_where_clause>
3. Abfragen mit Unterabfragen:
SELECT <column_list> FROM (<your_sub_query>) AS T WHERE ?DfDynamicRangePartitionCondition AND <your_additional_where_clause>
4. Abfrage mit Partition in Unterabfrage:
SELECT <column_list> FROM (SELECT <your_sub_query_column_list> FROM <TableName> WHERE ?DfDynamicRangePartitionCondition) 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": "SqlMISource",
    "partitionOption": "PhysicalPartitionsOfTable"
}

Beispiel: Abfrage mit dynamischer Bereichspartition

"source": {
    "type": "SqlMISource",
    "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>"
    }
}

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.

SQL-Abfrageergebnis

Bewährte Methode zum Laden von Daten in eine verwaltete SQL-Instanz

Beim Kopieren von Daten in eine verwaltete SQL-Instanz ist möglicherweise ein anderes Schreibverhalten erforderlich:

Informationen zur Konfiguration und zu bewährten Methoden finden Sie in den entsprechenden Abschnitten.

Anfügen von Daten

Das Anfügen von Daten ist das Standardverhalten dieses Senkenconnectors für die verwaltete SQL-Instanz. Der Dienst führt eine Masseneinfü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 SQL Managed Instance als Senke.

Überschreiben der gesamten Tabelle

Sie können die preCopyScript-Eigenschaft in einer 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 vor dem Einfügen von Quelldaten in die Zieltabelle weitere Verarbeitungsschritte erforderlich sind, können Sie die Daten in eine Stagingtabelle laden und dann Aktivitäten einer gespeicherten Prozedur oder eine gespeicherte Prozedur in der Kopieraktivität der Senke aufrufen, um die Daten anzuwenden.

Aufrufen der gespeicherten Prozedur von der SQL-Senke

Beim Kopieren von Daten in eine verwaltete SQL-Instanz 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 der SQL Server-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 Ihrer Pipeline den Abschnitt SQL MI sink in der Kopieraktivität wie folgt:

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

Eigenschaften von Mapping Data Flow

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

Quellentransformation

In der folgenden Tabelle sind die von der Azure SQL Managed Instance-Quelle unterstützten Eigenschaften aufgeführt. Sie können diese Eigenschaften auf der Registerkarte Quelloptionen bearbeiten.

Name BESCHREIBUNG Erforderlich Zulässige Werte Datenflussskript-Eigenschaft
Tabelle Wenn Sie „Tabelle“ als Eingabe auswählen, ruft der Datenfluss alle Daten aus der im Dataset angegebenen Tabelle ab. Nein - -
Abfrage Wenn Sie „Abfrage“ als Eingabe auswählen, geben Sie eine SQL-Abfrage zum Abrufen von Daten aus der Quelle an, die Vorrang vor jeder im Dataset angegebenen Tabelle hat. Die Verwendung von Abfragen stellt eine gute Möglichkeit dar, um die Zeilen für Tests oder Suchvorgänge zu verringern.

Die Order By-Klausel wird 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, mit der eine Tabelle zurückgegeben wird, die Sie im Datenfluss verwenden können.
Abfragebeispiel: Select * from MyTable where customerId > 1000 and customerId < 2000
Nein String Abfrage
Batchgröße Geben Sie eine Batchgröße an, um große Datenmengen in Leseblöcke zu segmentieren. Nein Integer batchSize
Isolationsstufe Wählen Sie eine der folgenden Isolationsstufen aus:
– Lesen zugesichert
– Lesen nicht zugesichert (Standard)
– Wiederholbarer Lesevorgang
– Serialisierbar
– Keine (Isolationsstufe ignorieren)
Nein READ_COMMITTED
READ_UNCOMMITTED
REPEATABLE_READ
SERIALIZABLE
NONE
isolationLevel
Inkrementelle Extrahierung aktivieren Verwenden Sie diese Option, um ADF mitzuteilen, dass nur Zeilen verarbeitet werden sollen, die seit der letzten Ausführung der Pipeline geändert wurden. Nein - -
Inkrementelle Spalte Wenn Sie das Feature für die inkrementelle Extrahierung verwenden, müssen Sie die Datums-/Uhrzeitspalte oder eine numerische Spalte auswählen, die Sie als Grenzwert in der Quelltabelle verwenden möchten. Nein - -
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 in Azure SQL MI 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. Nein - -
Lesen von Anfang an beginnen Wenn Sie diese Option mit der inkrementellen Extrahierung festlegen, wird ADF angewiesen, alle Zeilen bei der ersten Ausführung einer Pipeline zu lesen, wenn die inkrementelle Extrahierung aktiviert ist. Nein - -

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.

Skriptbeispiel für Azure SQL Managed Instance-Quelle

Wenn Sie Azure SQL Managed Instance als Quelltyp verwenden, sieht das zugehörige Datenflussskript wie folgt aus:

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

Senkentransformation

In der folgenden Tabelle sind die von der Azure SQL Managed Instance-Senke unterstützten Eigenschaften aufgeführt. Sie können diese Eigenschaften auf der Registerkarte Senkenoptionen bearbeiten.

Name BESCHREIBUNG Erforderlich Zulässige Werte Datenflussskript-Eigenschaft
Updatemethode Geben Sie an, welche Vorgänge für das Datenbankziel zulässig sind. Standardmäßig sind lediglich Einfügevorgänge zulässig.
Um Aktualisierungs-, Upsert- oder Löschaktionen auf Zeilen anzuwenden, muss eine Zeilenänderungstransformation zum Kennzeichnen von Zeilen für diese Aktionen erfolgen.
Ja true oder false deletable
insertable
updateable
upsertable
Schlüsselspalten Für Update-, Upsert- und Löschvorgänge müssen Schlüsselspalten festgelegt werden, um die Zeile zu bestimmen, die geändert werden soll.
Der Spaltenname, den Sie als Schlüssel auswählen, wird als Teil der nachfolgenden Update-, Upsert- und Löschvorgänge verwendet. Daher müssen Sie eine Spalte auswählen, die in der Senkenzuordnung vorhanden ist.
Nein Array keys
Schreiben von Schlüsselspalten überspringen Wenn Sie den Wert nicht in die Schlüsselspalte schreiben möchten, wählen Sie „Schreiben von Schlüsselspalten überspringen“ aus. Nein true oder false skipKeyWrites
Aktion table 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.
Nein true oder false Neu erstellen
truncate
Batchgröße Geben Sie an, wie viele Zeilen in die einzelnen Batches 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. Nein Integer batchSize
Pre- und Post-SQL-Skripts Geben Sie mehrzeilige SQL-Skripts an, die ausgeführt werden, bevor Daten in die Senkendatenbank geschrieben werden (Vorverarbeitung) und danach (Nachbearbeitung). Nein String preSQLs
postSQLs

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.

Skriptbeispiel für Azure SQL Managed Instance-Senke

Wenn Sie Azure SQL Managed Instance als Senkentyp verwenden, sieht das zugehörige Datenflussskript wie folgt aus:

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

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.

Datentypzuordnung für eine verwaltete SQL-Instanz

Wenn Daten mit Hilfe der Kopieraktivität in die und aus der SQL Managed Instance kopiert werden, werden die folgenden Zuordnungen von Datentypen der SQL Managed Instance zu den intern im Dienst verwendeten Interimsdatentypen verwendet. Informationen dazu, wie die Kopieraktivität das Quellschema und den Datentyp zur Senke zuordnet, finden Sie unter Schema- und Datentypzuordnungen.

Datentyp der verwalteten SQL-Instanz Datentyp der Zwischendienstleistung
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 Int16
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. Wenn Ihre Daten eine höhere Genauigkeit als 28 erfordern, erwägen Sie, sie per SQL-Abfrage in eine Zeichenfolge zu konvertieren.

Verwenden von Always Encrypted

Führen Sie beim Kopieren von Daten aus bzw. in SQL Managed Instance 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 Sie auf den Schlüsseltresor zugreifen können, in dem der Spalten-Hauptschlü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

SQL Managed Instance Always Encrypted 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 SQL Managed Instance 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:

Upgrade der Version von Azure SQL Managed Instance

Zum Upgrade der Version von Azure SQL Managed Instance wählen Sie auf der Seite Verknüpften Dienst bearbeiten unter Version die Option Empfohlen aus, und konfigurieren Sie den verknüpften Dienst. Beziehen Sie sich dabei auf Eigenschaften des verknüpften Diensts für die empfohlene Version.

In der nachstehenden Tabelle sind die Unterschiede zwischen Azure SQL Managed Instance unter Verwendung der empfohlenen Version und der Legacyversion dargestellt.

Empfohlene Version Legacyversion
Unterstützung von TLS 1.3 über encrypt als strict. TLS 1.3 wird nicht unterstützt.

Eine Liste der Datenspeicher, die als Quelles und Senken für die Kopieraktivität unterstützt werden, finden Sie in Unterstützte Datenspeicher.