Copiar e transformar dados no Banco de Dados SQL do Azure usando o Azure Data Factory ou o Azure Synapse Analytics

  • Artigo

APLICA-SE A: Azure Data Factory Azure Synapse Analytics

Dica

Experimente o Data Factory no Microsoft Fabric, uma solução de análise tudo-em-um para empresas. O Microsoft Fabric abrange desde movimentação de dados até ciência de dados, análise em tempo real, business intelligence e relatórios. Saiba como iniciar uma avaliação gratuita!

Este artigo descreve como usar a atividade Copy em pipelines do Azure Data Factory ou do Azure Synapse para copiar dados de e para o Banco de Dados SQL do Azure, e como usar o Fluxo de Dados para transformar dados no Banco de Dados SQL do Azure. Para saber mais, leia o artigo introdutório do Azure Data Factory ou do Azure Synapse Analytics.

Funcionalidades com suporte

Este conector do Banco de Dados SQL do Azure é compatível com as seguintes funcionalidades:

Funcionalidades com suporte IR Ponto de extremidade privado gerenciado
Atividade de cópia (origem/coletor) ① ② ✓
Fluxo de dados de mapeamento (origem/coletor) ① ✓
Atividade de pesquisa ① ② ✓
Atividade GetMetadata ① ② ✓
Atividade de Script ① ② ✓
Stored procedure activity (Atividade de procedimento armazenado) ① ② ✓

① Runtime de integração do Azure ② Runtime de integração auto-hospedada

Para a atividade Copy, este conector do Banco de Dados SQL do Azure dá suporte a estas funções:

  • Copiar dados usando a autenticação de token do Microsoft Entra e autenticação do SQL com uma entidade de serviço ou identidades gerenciadas para os recursos do Azure.
  • Como uma origem, recuperar dados usando uma consulta SQL ou um procedimento armazenado. Você também pode optar por copiar paralelamente de uma fonte do Banco de Dados SQL do Azure, confira a seção Cópia paralela do banco de dados SQL para obter detalhes.
  • Como coletor, criar automaticamente a tabela de destino, se não existir, com base no esquema de origem, acrescentar dados a uma tabela ou invocar um procedimento armazenado com lógica personalizada durante a cópia.

Se você usar a camada sem servidor do Banco de Dados SQL do Azure, observe que quando o servidor estiver pausado, a execução da atividade falhará em vez de esperar que a retomada automática esteja pronta. Você pode adicionar uma repetição de atividade ou encadear outras atividades para garantir que o servidor esteja ativo na execução real.

Importante

Se você copiar dados usando o runtime de integração do Azure, configure uma regra de firewall no nível do servidor para que os serviços do Azure possam acessar o servidor. Se você copiar dados usando um runtime de integração auto-hospedada, configure o firewall para permitir o intervalo de IP apropriado. Esse intervalo inclui o IP da máquina usado para se conectar ao Banco de Dados SQL do Azure.

Introdução

Para executar a atividade de Cópia com um pipeline, será possível usar as ferramentas ou os SDKs abaixo:

Criar um serviço vinculado do Banco de Dados SQL do Azure usando a interface do usuário

Siga as etapas abaixo para criar um serviço vinculado do Banco de Dados SQL do Azure na interface de usuário do portal do Azure.

  1. Navegue até a guia Gerenciar no workspace do Azure Data Factory ou do Synapse, selecione Serviços Vinculados e clique em Novo:

  2. Pesquise SQL e selecione o conector do Banco de Dados SQL do Azure.

    Selecione o conector do Banco de Dados SQL do Azure.

  3. Configure os detalhes do serviço, teste a conexão e crie o novo serviço vinculado.

    Captura de tela da configuração do serviço vinculado ao Banco de Dados SQL do Azure.

Detalhes da configuração do conector

As seções a seguir fornecem detalhes sobre as propriedades usadas para definir entidades de pipeline do Azure Data Factory ou do Azure Synapse específicas de um conector do Banco de Dados SQL do Azure.

Propriedades do serviço vinculado

Estas propriedades genéricas têm suporte de um serviço vinculado do Banco de Dados SQL do Azure:

Propriedade Descrição Obrigatório
type A propriedade tipo deve ser definida como AzureSqlDatabase. Sim
connectionString Especifique as informações necessárias para se conectar à instância do Banco de Dados SQL do Azure para a propriedade connectionString.
Você também pode colocar uma senha ou chave de entidade de serviço no Azure Key Vault. Se a autenticação for SQL, extraia a configuração password da cadeia de conexão. Para obter mais informações, confira o exemplo de JSON após a tabela e a seção Armazenar as credenciais no Azure Key Vault.		 Sim
azureCloudType Para autenticação da entidade de serviço, especifique o tipo de ambiente em nuvem do Azure em que seu aplicativo do Microsoft Entra está registrado.
Os valores permitidos são AzurePublic, AzureChina, AzureUsGovernment e AzureGermany. Por padrão, o data factory ou o ambiente de nuvem do pipeline do Synapse é usado.		 Não
alwaysEncryptedSettings Especifique as informações alwaysencryptedsettings necessárias para habilitar o Always Encrypted e proteger dados confidenciais armazenados em um SQL Server usando a identidade gerenciada ou a entidade de serviço. Para obter mais informações, confira o exemplo JSON após a tabela e a seção Usar o Always Encrypted. Se não for especificada, a configuração padrão sempre criptografada estará desabilitada. Não
connectVia Esse Integration Runtime é usado para se conectar ao armazenamento de dados. Você poderá usar o runtime de integração do Azure ou um runtime de integração auto-hospedada se o seu armazenamento de dados estiver localizado em uma rede privada. Se não especificado, o Azure Integration Runtime padrão será usado. Não

Para diferentes tipos de autenticação, consulte as seguintes seções sobre propriedades específicas, pré-requisitos e amostras de JSON, respectivamente:

Dica

Se você encontrar erro com o código de erro "UserErrorFailedToConnectToSqlServer" e uma mensagem como "O limite da sessão para o banco de dados é XXX e foi atingido," adicione Pooling=false à cadeia de conexão e tente novamente. Pooling=false também é recomendado para a configuração de serviço vinculado do tipo SHIR (Runtime de Integração Auto-Hospedada). O pooling e outros parâmetros de conexão podem ser adicionados como novos nomes de parâmetro e valores na seção Propriedades de conexão adicionais do formulário de criação de serviço vinculado.

Autenticação SQL

Para usar o tipo de autenticação SQL, especifique as propriedades genéricas descritas na seção anterior.

Exemplo: uso de autenticação SQL

{
    "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"
        }
    }
}

Exemplo: senha no 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"
        }
    }
}

Exemplo: Usar o 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"
        }
    }
}

Autenticação de entidade de serviço

Para usar a autenticação de entidade de serviço, além das propriedades genéricas descritas na seção anterior, especifique as seguintes propriedades:

Propriedade Descrição Obrigatório
servicePrincipalId Especifique a ID do cliente do aplicativo. Sim
servicePrincipalKey Especifique a chave do aplicativo. Marque este campo como um SecureString para armazená-lo com segurança ou referencie um segredo armazenado no Azure Key Vault. Sim
locatário Especifique as informações de locatário, como nome de domínio ou ID do locatário, em que o aplicativo reside. Recupere-as passando o mouse no canto superior direito do Portal do Azure. Sim

Você também precisa seguir as etapas abaixo:

  1. Crie um aplicativo do Microsoft Entra no portal do Azure. Anote o nome do aplicativo e os seguintes valores que definem o serviço vinculado:

    • ID do aplicativo
    • Chave do aplicativo
    • ID do locatário

  2. Provisione um administrador do Microsoft Entra para o servidor no portal do Azure, caso ainda não tenha feito isso. O administrador do Microsoft Entra deve ser um usuário do Microsoft Entra ou um grupo do Microsoft Entra, mas não pode ser uma entidade de serviço. Essa etapa é feita para que, na próxima etapa, você possa usar uma identidade do Microsoft Entra para criar um usuário de banco de dados contido para a entidade de serviço.

  3. Crie usuários de banco de dados contidos para o diretor de serviços. Conecte-se ao banco de dados do qual ou para o qual deseja copiar dados usando ferramentas como o SQL Server Management Studio, com uma identidade do Microsoft Entra que tenha, pelo menos, a permissão ALTER ANY USER. Execute o seguinte T-SQL:

    CREATE USER [your application name] FROM EXTERNAL PROVIDER;

  4. Conceda ao principal de serviço as permissões necessárias, como faria normalmente para usuários do SQL ou outros. Execute o código a seguir. Para mais opções, confira este documento.

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

  5. Configure um serviço vinculado do Banco de Dados SQL do Azure em um espaço de trabalho do Azure Data Factory ou do Synapse.

Exemplo de serviço vinculado que usa autenticação principal de serviço

{
    "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"
        }
    }
}

Autenticação de identidade gerenciada atribuída pelo sistema

É possível associar um data factory ou um workspace do Synapse a uma identidade gerenciada atribuída para o sistema para recursos do Azure que representa o serviço ao autenticar em outros recursos do Azure. Você pode usar essa identidade gerenciada para autenticação do Banco de Dados SQL do Azure. Usando essa identidade, o alocador ou o espaço de trabalho do Synapse designados podem acessar e copiar dados de e para o seu banco de dados.

Para usar a autenticação de identidade gerenciada atribuída pelo sistema, especifique as propriedades genéricas descritas na seção anterior e siga estas etapas.

  1. Provisione um administrador do Microsoft Entra para o servidor no portal do Azure, caso ainda não tenha feito isso. O administrador do Microsoft Entra pode ser um usuário do Microsoft Entra ou um grupo do Microsoft Entra. Se você conceder uma função de administrador ao grupo com a identidade gerenciada, ignore as etapas 3 e 4. O administrador tem acesso completo ao banco de dados.

  2. Crie usuários de bancos de dados independentes para a identidade gerenciada. Conecte-se ao banco de dados do qual ou para o qual deseja copiar dados usando ferramentas como o SQL Server Management Studio, com uma identidade do Microsoft Entra que tenha, pelo menos, a permissão ALTER ANY USER. Execute o seguinte T-SQL:

    CREATE USER [your_resource_name] FROM EXTERNAL PROVIDER;

  3. Conceda à identidade gerenciada as permissões necessárias como você faria normalmente para usuários de SQL e outros. Execute o código a seguir. Para mais opções, confira este documento.

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

  4. Configure um serviço vinculado do Banco de Dados SQL do Azure.

Exemplo

{
    "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"
        }
    }
}

Autenticação de identidade gerenciada atribuída pelo usuário

É possível associar um data factory ou um workspace do Synapse a uma identidade gerenciada atribuída pelo usuário que representa o serviço ao autenticar em outros recursos do Azure. Você pode usar essa identidade gerenciada para autenticação do Banco de Dados SQL do Azure. Usando essa identidade, o alocador ou o espaço de trabalho do Synapse designados podem acessar e copiar dados de e para o seu banco de dados.

Para usar a autenticação de identidade gerenciada atribuída pelo usuário, além das propriedades genéricas descritas na seção anterior, especifique as seguintes propriedades:

Propriedade Descrição Obrigatório
credenciais Especifique a identidade gerenciada atribuída pelo usuário como o objeto da credencial. Sim

Você também precisa seguir as etapas abaixo:

  1. Provisione um administrador do Microsoft Entra para o servidor no portal do Azure, caso ainda não tenha feito isso. O administrador do Microsoft Entra pode ser um usuário do Microsoft Entra ou um grupo do Microsoft Entra. Se você conceder uma função de administrador ao grupo com a identidade gerenciada atribuída pelo usuário, ignore a etapa 3. O administrador tem acesso completo ao banco de dados.

  2. Crie usuários de banco de dados contidos para a identidade gerenciada atribuída pelo usuário. Conecte-se ao banco de dados do qual ou para o qual deseja copiar dados usando ferramentas como o SQL Server Management Studio, com uma identidade do Microsoft Entra que tenha, pelo menos, a permissão ALTER ANY USER. Execute o seguinte T-SQL:

    CREATE USER [your_resource_name] FROM EXTERNAL PROVIDER;

  3. Crie uma ou várias identidades gerenciadas atribuídas pelo usuário e conceda à identidade gerenciada atribuída pelo usuário as permissões necessárias como você normalmente faz para SQL usuários e outros. Execute o código a seguir. Para mais opções, confira este documento.

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

  4. Atribua uma ou várias identidades gerenciadas atribuídas pelo usuário a seu data factory e crie credenciais para cada identidade gerenciada atribuída pelo usuário.

  5. Configure um serviço vinculado do Banco de Dados SQL do Azure.

Exemplo:

{
    "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"
        }
    }
}

Propriedades do conjunto de dados

Para obter uma lista completa das seções e propriedades disponíveis para definir os conjuntos de dados, confira Conjuntos de dados.

As propriedades a seguir têm suporte no conjunto de dados do Banco de Dados SQL do Azure:

Propriedade Descrição Obrigatório
type A propriedade tipo do conjunto de dados deve ser definida como AzureSqlTable. Sim
esquema Nome do esquema. Não para fonte, Sim para o coletor
tabela Nome da tabela/exibição. Não para fonte, Sim para o coletor
tableName Nome da tabela/exibição com esquema. Essa propriedade é compatível com versões anteriores. Para uma nova carga de trabalho, use schema e table. Não para fonte, Sim para o coletor

Exemplo de propriedades do conjunto de dados

{
    "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>"
        }
    }
}

Propriedades da atividade de cópia

Para obter uma lista completa das seções e propriedades disponíveis para definir as atividades, veja Pipelines. Esta seção fornece uma lista de propriedades suportadas pela origem e pelo coletor do Banco de Dados SQL do Azure.

Banco de Dados SQL do Azure como a origem

Dica

Para carregar dados do Banco de Dados SQL do Azure com eficiência usando o particionamento de dados, saiba mais na seção Cópia paralela no banco de dados SQL.

Para copiar dados do Banco de Dados SQL do Azure, há suporte para as seguintes propriedades na seção origem da atividade Copy:

Propriedade Descrição Obrigatório
type A propriedade type da origem da atividade Copy deve ser definida como AzureSqlSource. O tipo "SqlSource" ainda tem suporte para compatibilidade com versões anteriores. Sim
sqlReaderQuery Essa propriedade usa a consulta SQL personalizada para ler dados. Um exemplo é select * from MyTable. Não
sqlReaderStoredProcedureName O nome do procedimento armazenado que lê dados da tabela de origem. A última instrução SQL deve ser uma instrução SELECT no procedimento armazenado. Não
storedProcedureParameters Parâmetros para o procedimento armazenado.
Valores permitidos são pares de nome ou valor. Os nomes e o uso de maiúsculas e minúsculas de parâmetros devem corresponder aos nomes e o uso de maiúsculas e minúsculas dos parâmetros do procedimento armazenado.		 Não
isolationLevel Especifica o comportamento de bloqueio de transação para a origem do SQL. Os valores permitidos são: ReadCommitted, ReadUncommitted, RepeatableRead, Serializable, Snapshot. Se não for especificado, o nível de isolamento padrão do banco de dados será usado. Veja este documento para obter mais detalhes. Não
partitionOptions Especifica as opções de particionamento de dados usadas para carregar dados do Banco de Dados SQL do Azure.
Os valores permitidos são: None (padrão), PhysicalPartitionsOfTable e DynamicRange.
Quando uma opção de partição está habilitada (ou seja, não None), o grau de paralelismo para carregar dados simultaneamente do Banco de Dados SQL do Azure é controlado pela configuração parallelCopies na atividade Copy.		 Não
partitionSettings Especifique o grupo de configurações para o particionamento de dados.
Aplicar quando a opção de partição não for None.		 No
Em partitionSettings:
partitionColumnName Especifique o nome da coluna de origem no tipo inteiro ou data/datetime (int, smallint, bigint, date, smalldatetime, datetime, datetime2 ou datetimeoffset) que será usado pelo particionamento de intervalo para cópia paralela. Se não especificado, o índice chave primária da tabela será detectada automaticamente e usado como a coluna de partição.
Aplicar quando a opção de partição for DynamicRange. Se você usar uma consulta para recuperar os dados de origem, conecte ?DfDynamicRangePartitionCondition na cláusula WHERE. Para ver um exemplo, confira a seção Cópia paralela do banco de dados SQL.		 Não
partitionUpperBound O valor máximo da coluna de partição para divisão do intervalo de partição. Esse valor é usado para decidir o stride da partição, e não para filtrar as linhas na tabela. Todas as linhas da tabela ou do resultado da consulta serão particionadas e copiadas. Se não for especificado, a atividade de cópia detectará o valor automaticamente.
Aplicar quando a opção de partição for DynamicRange. Para ver um exemplo, confira a seção Cópia paralela do banco de dados SQL.		 Não
partitionLowerBound O valor mínimo da coluna de partição para divisão do intervalo de partição. Esse valor é usado para decidir o stride da partição, e não para filtrar as linhas na tabela. Todas as linhas da tabela ou do resultado da consulta serão particionadas e copiadas. Se não for especificado, a atividade de cópia detectará o valor automaticamente.
Aplicar quando a opção de partição for DynamicRange. Para ver um exemplo, confira a seção Cópia paralela do banco de dados SQL.		 No

Observe os seguintes pontos:

  • Se sqlReaderQuery for especificado para AzureSqlSource, a atividade Copy executa essa consulta em relação à fonte do Banco de Dados SQL do Azure para obter os dados. Você também pode especificar um procedimento armazenado especificando o sqlReaderStoredProcedureName e o storedProcedureParameters se o procedimento armazenado usa parâmetros.
  • ao usar um procedimento armazenado na origem para recuperar dados, observe que, se o procedimento armazenado for projetado para retornar um esquema diferente quando um valor de parâmetro diferente for passado, você poderá ter uma falha ou um resultado inesperado ao importar o esquema da interface do usuário ou ao copiar dados para o banco de dados SQL com a criação automática de tabela.

Exemplo de consulta SQL

"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>"
            }
        }
    }
]

Exemplo de procedimento armazenado

"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>"
            }
        }
    }
]

Definição do procedimento armazenado

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

Banco de Dados SQL do Azure como o coletor

Dica

Saiba mais sobre os comportamentos, as configurações e as melhores práticas de gravação com suporte na seção Melhor prática para carregar dados no Banco de Dados SQL do Azure.

Para copiar dados para o Banco de Dados SQL do Azure, há suporte para as seguintes propriedades na seção coletor da atividade Copy:

Propriedade Descrição Obrigatório
type A propriedade type do coletor da atividade Copy deve ser definida como AzureSqlSink. O tipo "SqlSink" ainda tem suporte para compatibilidade com versões anteriores. Sim
preCopyScript Especifique uma consulta SQL para que a atividade Copy seja executada antes de gravar dados no Banco de Dados SQL do Azure. É chamado apenas uma vez por execução de cópia. Use essa propriedade para limpar os dados pré-carregados. Não
tableOption Especifica se a tabela do coletor deve ser criada automaticamente caso ela não exista com base no esquema de origem.
Não há suporte para a criação de tabela automática quando o coletor especifica o procedimento armazenado.
Os valores permitidos são none (padrão) e autoCreate.		 Não
sqlWriterStoredProcedureName O nome do procedimento armazenado que define como aplicar dados de origem em uma tabela de destino.
Este procedimento armazenado é chamado por lote. Para operações executadas apenas uma vez e que não tenham relação alguma com os dados de origem, por exemplo, excluir ou truncar, use a propriedade preCopyScript.
Confira o exemplo em Invocar um procedimento armazenado de um coletor SQL.		 Não
storedProcedureTableTypeParameterName O nome do parâmetro do tipo de tabela especificado no procedimento armazenado. No
sqlWriterTableType O nome do tipo de tabela a ser usado no procedimento armazenado. A atividade de cópia disponibiliza aqueles dados sendo movidos em uma tabela temporária com esse tipo de tabela. O código de procedimento armazenado pode mesclar os dados que estão sendo copiados com os dados existentes. Não
storedProcedureParameters Parâmetros para o procedimento armazenado.
Valores permitidos são pares de nome e valor. Nomes e uso de maiúsculas e minúsculas de parâmetros devem corresponder aos nomes e o uso de maiúsculas e minúsculas dos parâmetros do procedimento armazenado.		 Não
writeBatchSize Número de linhas a serem inseridas na tabela SQL por lote.
O valor permitido é inteiro (número de linhas). Por padrão, o serviço determina dinamicamente o tamanho do lote apropriado com base no tamanho da linha.		 No
writeBatchTimeout O tempo de espera para que a operação de inserção, upsert e procedimento armazenado seja concluída antes de atingir o tempo limite.
Os valores permitidos são para o timespan. Um exemplo é "00:30:00" por 30 minutos. Se nenhum valor for especificado, o tempo limite padrão será "00:30:00".		 Não
disableMetricsCollection O serviço coleta métricas como DTUs do Banco de Dados SQL do Azure para otimização e recomendações de desempenho de cópia, o que introduz acesso mestre adicional ao banco de dados. Se você estiver preocupado com esse comportamento, especifique true para desativá-lo. Não (o padrão é false)
 maxConcurrentConnections O limite superior de conexões simultâneas estabelecidas com o armazenamento de dados durante a execução da atividade. Especifique um valor somente quando desejar limitar as conexões simultâneas.  Nenhum
WriteBehavior Especifique o comportamento de gravação da atividade de cópia para carregar dados Banco de Dados SQL do Azure.
O valor permitido é insert e upsert. Por padrão, o serviço usa insert para carregar dados.		 Não
upsertSettings Especifique o grupo de configurações para comportamento de gravação.
Aplicar quando a opção WriteBehavior for Upsert.		 Não
Em upsertSettings:
useTempDB Especifique se deseja usar a tabela temporária global ou a tabela física como a tabela provisória para upsert.
Por padrão, o serviço usa a tabela temporária global como a tabela provisória. O valor é true.		 Não
interimSchemaName Especifique o esquema provisório para criar a tabela provisória se a tabela física for usada. Observação: o usuário precisa ter a permissão para criar e excluir a tabela. Por padrão, a tabela provisória compartilhará o mesmo esquema que a tabela de coletor.
Aplicar quando a opção useTempDB for False.		 Não
chaves Especifique os nomes de coluna para identificação de linha exclusiva. Uma única chave ou uma série de chaves pode ser usada. Se não for especificada, a chave primária será usada. Não

Exemplo 1: acrescentar dados

"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
            }
        }
    }
]

Exemplo 2: invocar um procedimento armazenado durante a cópia

Saiba mais detalhes em Invocar um procedimento armazenado de um coletor SQL.

"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" }
                }
            }
        }
    }
]

Exemplo 3: dados upsert

"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>"
                    ]
                },
            }
        }
    }
]

Cópia paralela do banco de dados SQL

O conector do Banco de Dados SQL do Azure na atividade Copy fornece particionamento de dados interno para copiar dados em paralelo. Você pode encontrar opções de particionamento de dados na guia Origem da atividade de cópia.

Captura de tela das opções de partição

Quando você habilita a cópia particionada, a atividade Copy executa consultas paralelas com relação à sua origem do Banco de Dados SQL do Azure para carregar dados por partições. O grau paralelo é controlado pela configuração do parallelCopies na atividade de cópia. Por exemplo, ao definir parallelCopies como quatro, o serviço gera e executa simultaneamente quatro consultas com base na opção de partição e nas configurações especificadas. Cada consulta recupera uma parte dos dados do Banco de Dados SQL do Azure.

É recomendável habilitar a cópia paralela com o particionamento de dados, especialmente quando você carrega grandes quantidades de dados do Banco de Dados SQL do Azure. Veja a seguir as configurações sugeridas para cenários diferentes. Ao copiar dados para o armazenamento de dados baseado em arquivo, recomendamos gravá-los em uma pasta como vários arquivos (apenas especifique o nome da pasta) para ter um desempenho melhor do que gravar em um arquivo.

Cenário Configurações sugeridas
Carregamento completo de uma tabela grande com partições físicas. Opção de partição: partições físicas da tabela.

Durante a execução, o serviço detecta automaticamente as partições físicas e copia os dados por partição.

Para verificar se a tabela tem partição física, confira esta consulta.
Carregamento completo de uma tabela grande, sem partições físicas e com uma coluna de inteiro ou de datetime para o particionamento de dados. Opções de partição: partição de intervalo dinâmico.
Coluna de partição (opcional): especifique a coluna usada para particionar dados. Se não for especificada, a coluna de chave primária ou de índice será usada.
Limite superior da partição e limite inferior da partição (opcional): especifique se deseja determinar o stride da partição. A finalidade não é filtrar as linhas na tabela, todas as linhas da tabela serão particionadas e copiadas. Se não for especificado, a atividade Copy detectará os valores automaticamente.

Por exemplo, se a “ID” da coluna de partição tiver valores no intervalo de 1 a 100 e você definir o limite inferior como 20 e o limite superior como 80, com a cópia paralela definida como 4, o serviço recuperará dados por 4 IDs de partição no intervalo <=20, [21, 50], [51, 80], e >=81, respectivamente.
Carregar uma grande quantidade de dados usando uma consulta personalizada, sem partições físicas, com uma coluna de inteiro ou data/datetime para o particionamento de dados. Opções de partição: partição de intervalo dinâmico.
Consulta: SELECT * FROM <TableName> WHERE ?DfDynamicRangePartitionCondition AND <your_additional_where_clause>.
Coluna de partição: especifique a coluna usada para particionar dados.
Limite superior da partição e limite inferior da partição (opcional): especifique se deseja determinar o stride da partição. A finalidade não é filtrar as linhas na tabela, todas as linhas na consulta serão particionadas e copiadas. Se não for especificado, a atividade de cópia detectará o valor automaticamente.

Por exemplo, se a “ID” da coluna de partição tiver valores no intervalo de 1 a 100 e você definir o limite inferior como 20 e o limite superior como 80, com a cópia paralela definida como 4, o serviço recuperará dados por 4 IDs de partição no intervalo <=20, [21, 50], [51, 80], e >=81, respectivamente.

Veja mais exemplos de consultas para diferentes cenários:
1. Consultar a tabela inteira:
SELECT * FROM <TableName> WHERE ?DfDynamicRangePartitionCondition
2. Consultar em uma tabela com seleção de coluna e filtros de cláusula "where" adicionais:
SELECT <column_list> FROM <TableName> WHERE ?DfDynamicRangePartitionCondition AND <your_additional_where_clause>
3. Consultar com sub-consultas:
SELECT <column_list> FROM (<your_sub_query>) AS T WHERE ?DfDynamicRangePartitionCondition AND <your_additional_where_clause>
4. Consultar com partição na sub-consulta:
SELECT <column_list> FROM (SELECT <your_sub_query_column_list> FROM <TableName> WHERE ?DfDynamicRangePartitionCondition) AS T

Melhores práticas para carregar dados com a opção de partição:

  1. Escolha a coluna distinta como coluna de partição (como chave primária ou chave exclusiva) para evitar a distorção de dados.
  2. Se a tabela tiver uma partição interna, use a opção de partição "Partições físicas da tabela" para ter um melhor desempenho.
  3. Se você usa o Azure Integration Runtime para copiar dados, pode definir "DIUs (unidades de integração de dados)" maiores (>4) para utilizar mais recursos de computação. Verifique os cenários aplicáveis.
  4. O "grau de paralelismo de cópia" controla os números de partições. Às vezes, definir um número muito grande afeta o desempenho; é recomendável definir esse número como (DIU ou número de nós de IR auto-hospedados) * (2 a 4).

Exemplo: carregamento completo de uma tabela grande com partições físicas

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

Exemplo: consulta com a partição do intervalo dinâmico

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

Exemplo de consulta para verificar a partição física

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

Se a tabela tiver uma partição física, você verá "HasPartition" como "yes" conforme segue.

Resultado da consulta SQL

Melhor prática para carregar dados no Banco de Dados SQL do Azure

Quando você copia dados para o Banco de Dados SQL do Azure, talvez um comportamento de gravação diferente seja necessário:

  • Acrescentar: meus dados de origem só têm registros novos.
  • Upsert: meus dados de origem têm inserções e atualizações.
  • Substituir: quero recarregar uma tabela de dimensão inteira a cada vez.
  • Gravar com lógica personalizada: preciso de processamento adicional antes da inserção final na tabela de destino.

Veja as respectivas seções sobre como configurar no serviço, incluindo as melhores práticas.

Acrescentar dados

Acrescentar dados é o comportamento padrão desse conector de coletor do Banco de Dados SQL do Azure. o serviço faz uma inserção em massa para gravar na tabela de maneira eficiente. Você pode configurar a origem e o coletor de acordo com a atividade Copy.

Upsert data

A atividade Copy agora dá suporte ao carregamento nativo de dados em uma tabela temporária de banco de dados e, em seguida, atualize os dados na tabela de coletor se a chave existir e, caso contrário, insira novos dados. Para saber mais sobre as configurações de upsert em atividades de cópia, confira Banco de Dados SQL do Azure como coletor.

Substituir a tabela inteira

Você pode configurar a propriedade preCopyScript no coletor da atividade Copy. Nesse caso, para cada atividade Copy executada, o serviço executa primeiro o script. Em seguida, ele executa a cópia para inserir os dados. Por exemplo, para substituir a tabela inteira pelos dados mais recentes, especifique um script para excluir primeiro todos os registros, antes de carregar em massa os novos dados da origem.

Gravar dados com lógica personalizada

As etapas para gravar dados com lógica personalizada são semelhantes às descritas na seção Executar upsert de dados. Quando você precisa aplicar processamento adicional antes da inserção final dos dados de origem na tabela de destino, pode carregar em uma tabela de preparo e, em seguida, invocar a atividade de procedimento armazenado ou invocar um procedimento armazenado no coletor da atividade Copy para aplicar os dados ou usar o fluxo de dados de mapeamento.

Invocar um procedimento armazenado de um coletor SQL

Quando você copiar dados para o Banco de Dados SQL do Azure, você também pode configurar e invocar um procedimento armazenado especificado pelo usuário com parâmetros adicionais em cada lote da tabela de origem. O recurso de procedimento armazenado se beneficia de parâmetros com valores de tabela.

Você pode usar um procedimento armazenado quando os mecanismos internos de cópia não atendem à finalidade. Um exemplo é quando você deseja aplicar processamento adicional antes da inserção final dos dados de origem na tabela de destino. Alguns exemplos de processamento adicional são colunas de mesclagem, pesquisa de outros valores e inserção em mais de uma tabela.

A amostra a seguir mostra como usar um procedimento armazenado para fazer um upsert em uma tabela no Banco de Dados SQL do Azure. Suponha que os dados de entrada e a tabela Marketing de recebimento tenham três colunas: ID do perfil, Estado e Categoria. Faça o upsert com base na coluna ProfileID e aplique-o apenas a uma categoria específica denominada "ProductA".

  1. No banco de dados, defina o tipo de tabela com o mesmo nome que sqlWriterTableType. O esquema do tipo de tabela é o mesmo que o esquema retornado pelos dados de entrada.

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

  2. No banco de dados, defina o procedimento armazenado com o mesmo nome que sqlWriterStoredProcedureName. Ele manipula os dados de entrada da sua origem especificada e mescla na tabela de saída. O nome do parâmetro do tipo de tabela no procedimento armazenado deve ser o mesmo que o tableName definido no conjunto de dados.

    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. Na pipeline do Azure Data Factory ou do Synapse, defina a seção Coletor do SQL na atividade Copy da seguinte maneira:

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

Ao gravar dados no Banco de Dados SQL do Azure usando o procedimento armazenado, o coletor divide os dados de origem em minilotes e, em seguida, faz a inserção para que a consulta extra no procedimento armazenado possa ser executada várias vezes. Se você tiver a consulta para que a atividade de cópia seja executada antes de gravar dados no Banco de Dados SQL do Azure, não é recomendável adicioná-la ao procedimento armazenado, adicione-a na caixa Script de pré-cópia.

Propriedades do fluxo de dados de mapeamento

Ao transformar dados no fluxo de dados de mapeamento, você pode ler e gravar em tabelas do Banco de Dados SQL do Azure. Para obter mais informações, confira transformação de origem e transformação do coletor nos fluxos de dados de mapeamento.

Transformação de origem

As configurações específicas para o Banco de Dados SQL do Azure estão disponíveis na guia Opções de Origem da transformação de origem.

Entrada: selecione se você apontar sua origem em uma tabela (equivalente a Select * from <table-name>) ou inserir uma consulta SQL personalizada.

Consulta: se você selecionar Consulta no campo de entrada, insira uma consulta SQL para sua origem. Essa configuração substitui qualquer tabela que você tenha escolhido no conjunto de dados. Cláusulas Order By não são compatíveis aqui, mas você pode definir uma instrução SELECT FROM completa. Também pode usar funções de tabela definidas pelo usuário. select * from udfGetData() é um UDF no SQL que retorna uma tabela. Essa consulta produzirá uma tabela de origem que você pode usar em seu fluxo de dados. O uso de consultas também é uma ótima maneira de reduzir linhas para testes ou pesquisas.

Dica

A CTE (expressão de tabela comum) no SQL não é compatível com o modo Consulta do fluxo de dados de mapeamento, pois o pré-requisito de uso desse modo é que as consultas possam ser usadas na cláusula FROM da consulta SQL, mas as CTEs não podem fazer isso. Para usar CTEs, você precisa criar um procedimento armazenado usando a seguinte consulta:

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

Depois, use o modo Procedimento armazenado na transformação de origem do fluxo de dados de mapeamento e defina o @query como o exemplo with CTE as (select 'test' as a) select * from CTE. Depois, você poderá usar CTEs conforme o esperado.

Procedimento armazenado: escolha esta opção se desejar gerar uma projeção e dados de origem de um procedimento armazenado executado no banco de dado de origem. Você pode digitar o esquema, o nome do procedimento e os parâmetros ou clicar em atualizar para solicitar que o serviço descubra os esquemas e os nomes dos procedimentos. Em seguida, você pode clicar em Importar para importar todos os parâmetros de procedimento usando o formulário @paraName.

Procedimento armazenado

  • Exemplo do SQL: Select * from MyTable where customerId > 1000 and customerId < 2000
  • Exemplo de SQL parametrizado: "select * from {$tablename} where orderyear > {$year}"

Tamanho do lote: insira um tamanho de lote para dividir dados grandes em leituras.

Nível de isolamento: o padrão para as origens SQL no fluxo de dados de mapeamento é leitura não confirmada. Você pode alterar o nível de isolamento aqui para um destes valores:

  • Leitura Confirmada
  • Leitura Não Confirmada
  • Leitura repetida
  • Serializável
  • Nenhum (ignorar o nível de isolamento)

Nível de Isolamento

Habilitar a extração incremental: use essa opção para instruir o ADF a processar apenas as linhas que foram alteradas desde a última vez em que o pipeline foi executado. Para habilitar a extração incremental com descompasso de esquema, escolha tabelas com base em colunas Incrementais/Marca d'água em vez de tabelas habilitadas para a Captura de dados de alterações nativas.

Coluna incremental: ao usar o recurso de extração incremental, escolha a coluna data/hora ou numérica que você deseja usar como marca d'água na tabela de origem.

Habilitar a captura de dados de alterações nativas (versão prévia): use essa opção para informar ao ADF para processar apenas os dados delta capturados pela tecnologia de captura de dados de alterações do SQL desde a última vez que o pipeline executou. Com essa opção, os dados delta, incluindo a inserção, atualização e exclusão de linha, serão carregados automaticamente sem a necessidade de nenhuma coluna incremental. Será necessário habilitar a captura de dados de alterações no BD do SQL do Azure antes de usar essa opção no ADF. Para obter mais informações sobre essa opção no ADF, consulte captura de dados de alterações nativas.

Comece a ler desde o início: definir essa opção com a extração incremental dirá ao ADF para ler todas as linhas na primeira execução de um pipeline com a extração incremental ativada.

Transformação de coletor

As configurações específicas para o Banco de Dados SQL do Azure estão disponíveis na guia Configurações da transformação de coletor.

Método Update: determina quais operações são permitidas no destino do banco de dados. O padrão é permitir apenas inserções. Para atualizar, fazer upsert ou excluir linhas, uma transformação alter-row é necessária para marcar as linhas para essas ações. Para atualizações, upserts e exclusões, é necessário selecionar uma coluna de chave ou colunas para determinar qual linha alterar.

Colunas de Chave

O nome da coluna escolhida como a chave será usado pelo serviço como parte da atualização, execução de upsert e exclusão subsequentes. Portanto, você deve escolher uma coluna existente no mapeamento do coletor. Se você não quiser gravar o valor nessa coluna de chave, clique em "Ignorar a gravação de colunas de chave".

Você pode parametrizar a coluna de chave usada aqui para atualizar a tabela do Banco de Dados SQL do Azure de destino. Se você tiver várias colunas para uma chave composta, clique em "Expressão Personalizada" e você poderá adicionar conteúdo dinâmico usando a linguagem de expressão do fluxo de dados, que pode incluir uma matriz de cadeias de caracteres com nomes de coluna para uma chave composta.

Ação de tabela: determina se deve-se recriar ou remover todas as linhas da tabela de destino antes da gravação.

  • Nenhuma: nenhuma ação será feita na tabela.
  • Recriar: a tabela será descartada e recriada. Necessário ao criar uma tabela dinamicamente.
  • Truncar: todas as linhas da tabela de destino serão removidas.

Tamanho do lote: controla quantas linhas estão sendo gravadas em cada bucket. Tamanhos de lote maiores aprimoram a compactação e a otimização de memória, mas geram risco de exceções de memória insuficiente ao armazenar dados em cache.

Usar TempDB: por padrão, o serviço usará uma tabela temporária global para armazenar dados como parte do processo de carregamento. Como alternativa, você pode desmarcar a opção "Usar TempDB" e, em vez disso, solicitar ao serviço para armazenar a tabela temporária em um banco de dados de usuário localizado no banco de dados usado para esse coletor.

Usar TempDB

Scripts SQL prévios e posteriores: Insira scripts SQL de várias linhas que serão executados antes (pré-processamento) e após (pós-processamento) os dados serem gravados no banco de dados do coletor

Captura de tela que mostra as configurações do Coletor com scripts de processamento SQL prévios e posteriores.

Dica

  1. É recomendável quebrar scripts de lote únicos com vários comandos em vários lotes.
  2. Apenas as instruções DDL (linguagem de definição de dados) e DML (linguagem de manipulação de dados) que retornam uma contagem de atualização simples podem ser executadas como parte de um lote. Saiba mais sobre Executando operações em lote

Tratamento da linha de erros

Ao gravar no Banco de Dados SQL do Azure, determinadas linhas de dados podem falhar devido a restrições definidas pelo destino. Alguns erros comuns incluem:

  • Cadeia de caracteres ou dados de binário seriam truncados na tabela
  • Não é possível inserir o valor NULL na coluna
  • A instrução INSERT está em conflito com a restrição CHECK

Por padrão, uma execução de fluxo de dados falhará no primeiro erro obtido. É possível optar por continuar se houver erro que permite que o fluxo de dados seja concluído mesmo se as linhas individuais tiverem erros. O serviço fornece opções diferentes para você identificar essas linhas de erro.

Confirmação de transação: escolha se os dados são gravados em uma única transação ou em lotes. Uma única transação proporciona um desempenho pior, mas os dados gravados não ficarão visíveis para outras pessoas até que a transação seja concluída.

Dados rejeitados na saída: se esta opção estiver habilitada, você poderá gerar as linhas de erro em um arquivo CSV no Armazenamento de Blobs do Azure ou em uma conta do Azure Data Lake Storage Gen2 de sua escolha. Isso gravará as linhas de erro com três colunas adicionais: a operação SQL como INSERT ou UPDATE, o código de erro do fluxo de dados e a mensagem de erro na linha.

Relatar sucesso no erro: se esta opção estiver habilitada, o fluxo de dados será marcado como sucesso, mesmo que linhas de erro sejam encontradas.

Tratamento da linha de erros

Mapeamento do tipo de dados do Banco de Dados SQL do Azure

Quando os dados são copiados no Banco de Dados SQL do Azure, os seguintes mapeamentos são usados dos tipos de dados do Banco de Dados SQL do Azure para os tipos de dados temporários do Azure Data Factory. Os mesmos mapeamentos são usados pelo recurso de pipeline do Synapse, que implementa o Azure Data Factory diretamente. Para saber mais sobre como a atividade de cópia mapeia o tipo de dados e esquema de origem para o coletor, consulte Mapeamentos de tipo de dados e esquema.

Tipo de dados do Banco de Dados SQL do Azure Tipo de dados provisório do Data Factory
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 Objeto
text String, Char[]
time TimeSpan
timestamp Byte[]
TINYINT Byte
UNIQUEIDENTIFIER Guid
varbinary Byte[]
varchar String, Char[]
Xml String

Observação

Para tipos de dados que mapeiam para o tipo provisório Decimal, no momento, a atividade Copy dá suporte à precisão de até 28. Se você tiver dados com precisão maior do que 28, converta para uma cadeia de caracteres na consulta SQL.

Pesquisar propriedades de atividade

Para saber detalhes sobre as propriedades, verifique Atividade de pesquisa.

Propriedades de atividade GetMetadata

Para saber detalhes sobre as propriedades, verifique Atividade GetMetadata

Como usar o Always Encrypted

Ao copiar dados de/para o Banco de Dados SQL do Azure com o Always Encrypted, siga as etapas abaixo:

  1. Armazene a chave mestra de coluna (CMK) em um Azure Key Vault. Saiba mais sobre como configurar o Always Encrypted usando o Azure Key Vault

  2. Obtenha acesso ao cofre de chaves em que a CMK (Chave Mestra da Coluna)é armazenada. Veja este artigo para obter as permissões necessárias.

  3. Crie um serviço vinculado para se conectar ao banco de dados SQL e habilite a função “Always Encrypted” usando a identidade gerenciada ou a entidade de serviço.

Observação

O Banco de Dados SQL do Azure Always Encrypted dá suporte aos cenários abaixo:

  1. Os armazenamentos de dados de origem ou do coletor estão usando a identidade gerenciada ou a entidade de serviço como o tipo de autenticação do provedor de chaves.
  2. Os armazenamentos de dados de origem e do coletor estão usando a identidade gerenciada como o tipo de autenticação do provedor de chaves.
  3. Os armazenamentos de dados de origem e do coletor estão usando a mesma entidade de serviço como o tipo de autenticação do provedor de chaves.

Observação

Atualmente, o Banco de Dados SQL do Azure Always Encrypted tem suporte apenas para transformação de origem em fluxos de dados de mapeamento.

Captura de dados de alterações nativas

O Azure Data Factory pode dar suporte a recursos de captura de dados de alterações nativas para SQL Server, BD do SQL do Azure e MI do SQL do Azure. Os dados alterados, incluindo a inserção, atualização e exclusão de linha em armazenamentos SQL, poderão ser detectados e extraídos automaticamente pelo fluxo de dados de mapeamento do ADF. Com a experiência sem código no mapeamento de fluxo de dados, os usuários poderão obter facilmente o cenário de replicação de dados de repositórios SQL anexando um banco de dados como o repositório de destino. Além disso, os usuários também poderão redigir qualquer lógica de transformação de dados para obter um cenário de ETL incremental a partir de repositórios SQL.

Mantenha o pipeline e o nome da atividade inalterados para que o ponto de verificação possa ser registrado pelo ADF para que você receba automaticamente os dados alterados da última execução. Se você alterar o nome do pipeline ou da atividade, o ponto de verificação será redefinido, o que fará com que você comece do início ou receba alterações a partir de agora na próxima execução. Se você quiser alterar o nome do pipeline ou da atividade, mas ainda manter o ponto de verificação para obter os dados alterados da última execução automaticamente, use sua própria chave de ponto de verificação na atividade do fluxo de dados para conseguir isso.

Ao depurar o pipeline, esse recurso funcionará da mesma forma. Tenha em mente que o ponto de verificação será redefinido quando você atualizar o navegador durante a execução da depuração. Depois que estiver satisfeito com o resultado do pipeline da sequência de depuração, você poderá publicar e disparar o pipeline. Ao disparar pela primeira vez o pipeline publicado, ele será reiniciado automaticamente do início ou passará a obter alterações desse momento em diante.

Na seção de monitoramento, sempre existe a possibilidade de reexecutar um pipeline. Ao fazer isso, os dados alterados sempre serão capturados do ponto de verificação anterior da sua versão de pipeline selecionada.

Exemplo 1:

Ao encadear diretamente uma transformação de origem referenciada ao conjunto de dados habilitado para CDA do SQL com uma transformação de coletor referenciada a um banco de dados em um fluxo de dados de mapeamento, as alterações ocorridas na origem do SQL serão aplicadas automaticamente ao banco de dados de destino para que seja possível obter facilmente o cenário de replicação de dados entre bancos de dados. É possível usar o método de atualização na transformação do coletor para selecionar se você quer permitir inserção, permitir atualização ou permitir exclusão no banco de dados de destino. O script de exemplo no fluxo de dados de mapeamento é conforme abaixo.

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

Exemplo 2:

Se você quiser habilitar o cenário de ETL, em vez de replicação de dados entre banco de dados por meio de CDA do SQL, poderá usar expressões no fluxo de dados de mapeamento incluindo isInsert(1), isUpdate(1) e isDelete(1) para diferenciar as linhas com diferentes tipos de operação. A seguir é apresentado um dos scripts de exemplo para mapear o fluxo de dados ao derivar uma coluna com o valor: 1 para indicar as linhas inseridas, 2 para indicar as linhas atualizadas e 3 para indicar as linhas excluídas para transformações downstream para processar os dados delta.

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

Limitação conhecida:

Conteúdo relacionado

Para obter uma lista de armazenamentos de dados com suporte como fontes e coletores por atividade Copy, consulte armazenamentos de dados e formatos compatíveis.