Copiar e transformar dados de e para o SQL Server usando o Azure Data Factory ou o Azure Synapse Analytics

Artigo
01/05/2024

APLICA-SE A: Azure Data Factory Azure Synapse Analytics

Gorjeta

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

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

Capacidades suportadas

Este conector do SQL Server tem suporte para os seguintes recursos:

Capacidades suportadas	IR
Atividade de cópia (origem/coletor)	(1) (2)
Mapeando o fluxo de dados (origem/coletor)	(1)
Atividade de Pesquisa	(1) (2)
Atividade GetMetadata	(1) (2)
Atividade de script	(1) (2)
Atividade de procedimento armazenado	(1) (2)

(1) Tempo de execução de integração do Azure (2) Tempo de execução de integração auto-hospedado

Para obter uma lista de armazenamentos de dados suportados como fontes ou coletores pela atividade de cópia, consulte a tabela Armazenamentos de dados suportados.

Especificamente, este conector do SQL Server oferece suporte:

SQL Server versão 2005 e superior.
Copiar dados usando autenticação SQL ou Windows.
Como origem, recuperando dados usando uma consulta SQL ou um procedimento armazenado. Você também pode optar por copiar paralelamente da origem do SQL Server, consulte a seção Cópia paralela do banco de dados SQL para obter detalhes.
Como um coletor, criando automaticamente a tabela de destino se não existir com base no esquema de origem; anexar dados a uma tabela ou invocar um procedimento armazenado com lógica personalizada durante a cópia.

Não há suporte para o SQL Server Express LocalDB .

Importante

A fonte de dados deve suportar o tipo de dados NVARCAR, pois afeta a codificação de dados quando uma codificação não universal está sendo aplicada nos dados.

Pré-requisitos

Se seu armazenamento de dados estiver localizado dentro de uma rede local, uma rede virtual do Azure ou a Amazon Virtual Private Cloud, você precisará configurar um tempo de execução de integração auto-hospedado para se conectar a ele.

Se o seu armazenamento de dados for um serviço de dados de nuvem gerenciado, você poderá usar o Tempo de Execução de Integração do Azure. Se o acesso for restrito a IPs aprovados nas regras de firewall, você poderá adicionar IPs do Azure Integration Runtime à lista de permissões.

Você também pode usar o recurso de tempo de execução de integração de rede virtual gerenciada no Azure Data Factory para acessar a rede local sem instalar e configurar um tempo de execução de integração auto-hospedado.

Para obter mais informações sobre os mecanismos de segurança de rede e as opções suportadas pelo Data Factory, consulte Estratégias de acesso a dados.

Começar agora

Para executar a atividade Copiar com um pipeline, você pode usar uma das seguintes ferramentas ou SDKs:

Criar um serviço vinculado do SQL Server usando a interface do usuário

Use as etapas a seguir para criar um serviço vinculado do SQL Server na interface do usuário do portal do Azure.

Navegue até a guia Gerenciar em seu espaço de trabalho do Azure Data Factory ou Synapse e selecione Serviços Vinculados e clique em Novo:
- Fábrica de Dados do Azure
- Azure Synapse
Procure SQL e selecione o conector do SQL Server.
Configure os detalhes do serviço, teste a conexão e crie o novo serviço vinculado.

Detalhes de configuração do conector

As seções a seguir fornecem detalhes sobre as propriedades usadas para definir entidades de pipeline do Data Factory e do Synapse específicas para o conector de banco de dados do SQL Server.

Propriedades do serviço vinculado

Este conector do SQL Server suporta os seguintes tipos de autenticação. Consulte as seções correspondentes para obter detalhes.

Autenticação SQL
Autenticação do Windows

Gorjeta

Se você acertar um erro com o código de erro "UserErrorFailedToConnectToSqlServer" e uma mensagem como "O limite de sessão para o banco de dados é XXX e foi atingido", adicione Pooling=false à sua cadeia de conexão e tente novamente.

Autenticação do SQL

Para usar a autenticação SQL, as seguintes propriedades são suportadas:

Property	Descrição	Obrigatório
tipo	A propriedade type deve ser definida como SqlServer.	Sim
connectionString	Especifique as informações connectionString necessárias para se conectar ao banco de dados do SQL Server. Especifique um nome de login como seu nome de usuário e verifique se o banco de dados que você deseja conectar está mapeado para esse login. Consulte os exemplos a seguir.	Sim
password	Se você quiser colocar uma senha no Cofre de Chaves do Azure, extraia a `password` configuração da cadeia de conexão. Para obter mais informações, consulte o exemplo JSON seguindo a tabela e Armazenar credenciais no Cofre da Chave do Azure.	Não
alwaysEncryptedSettings	Especifique as informações alwaysencryptedsettings necessárias para habilitar o Always Encrypted para proteger dados confidenciais armazenados no SQL Server usando identidade gerenciada ou entidade de serviço. Para obter mais informações, consulte o exemplo JSON seguindo a tabela e a seção Usando sempre criptografado . Se não for especificado, a configuração padrão sempre criptografada será desabilitada.	Não
ConecteVia	Esse tempo de execução de integração é usado para se conectar ao armazenamento de dados. Saiba mais na seção Pré-requisitos . Se não for especificado, o tempo de execução de integração padrão do Azure será usado.	Não

Exemplo: Usar autenticação SQL

{
    "name": "SqlServerLinkedService",
    "properties": {
        "type": "SqlServer",
        "typeProperties": {
            "connectionString": "Data Source=<servername>\\<instance name if using named instance>;Initial Catalog=<databasename>;Integrated Security=False;User ID=<username>;Password=<password>;"
        },
        "connectVia": {
            "referenceName": "<name of Integration Runtime>",
            "type": "IntegrationRuntimeReference"
        }
    }
}

Exemplo: Usar a autenticação SQL com uma senha no Cofre de Chaves do Azure

{
    "name": "SqlServerLinkedService",
    "properties": {
        "type": "SqlServer",
        "typeProperties": {
            "connectionString": "Data Source=<servername>\\<instance name if using named instance>;Initial Catalog=<databasename>;Integrated Security=False;User ID=<username>;",
            "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 sempre criptografado

{
    "name": "SqlServerLinkedService",
    "properties": {
        "type": "SqlServer",
        "typeProperties": {
            "connectionString": "Data Source=<servername>\\<instance name if using named instance>;Initial Catalog=<databasename>;Integrated Security=False;User ID=<username>;Password=<password>;"
        },
        "alwaysEncryptedSettings": {
            "alwaysEncryptedAkvAuthType": "ServicePrincipal",
            "servicePrincipalId": "<service principal id>",
            "servicePrincipalKey": {
                "type": "SecureString",
                "value": "<service principal key>"
            }
        },
        "connectVia": {
            "referenceName": "<name of Integration Runtime>",
            "type": "IntegrationRuntimeReference"
        }
    }
}

Autenticação do Windows

Para usar a autenticação do Windows, as seguintes propriedades são suportadas:

Property	Descrição	Obrigatório
tipo	A propriedade type deve ser definida como SqlServer.	Sim
connectionString	Especifique as informações connectionString necessárias para se conectar ao banco de dados do SQL Server. Consulte os exemplos a seguir.
nome de utilizador	Especifique um nome de usuário. Um exemplo é domainname\username.	Sim
password	Especifique uma senha para a conta de usuário especificada para o nome de usuário. Marque este campo como SecureString para armazená-lo com segurança. Ou, você pode fazer referência a um segredo armazenado no Cofre da Chave do Azure.	Sim
alwaysEncryptedSettings	Especifique as informações alwaysencryptedsettings necessárias para habilitar o Always Encrypted para proteger dados confidenciais armazenados no SQL Server usando identidade gerenciada ou entidade de serviço. Para obter mais informações, consulte a seção Usando sempre criptografado . Se não for especificado, a configuração padrão sempre criptografada será desabilitada.	Não
ConecteVia	Esse tempo de execução de integração é usado para se conectar ao armazenamento de dados. Saiba mais na seção Pré-requisitos . Se não for especificado, o tempo de execução de integração padrão do Azure será usado.	Não

Nota

A autenticação do Windows não é suportada no fluxo de dados.

Exemplo: Usar a autenticação do Windows

{
    "name": "SqlServerLinkedService",
    "properties": {
        "type": "SqlServer",
        "typeProperties": {
            "connectionString": "Data Source=<servername>\\<instance name if using named instance>;Initial Catalog=<databasename>;Integrated Security=True;",
            "userName": "<domain\\username>",
            "password": {
                "type": "SecureString",
                "value": "<password>"
            }
        },
        "connectVia": {
            "referenceName": "<name of Integration Runtime>",
            "type": "IntegrationRuntimeReference"
        }
    }
}

Exemplo: Usar a autenticação do Windows com uma senha no Cofre de Chaves do Azure

{
    "name": "SqlServerLinkedService",
    "properties": {
        "annotations": [],
        "type": "SqlServer",
        "typeProperties": {
            "connectionString": "Data Source=<servername>\\<instance name if using named instance>;Initial Catalog=<databasename>;Integrated Security=True;",
            "userName": "<domain\\username>",
            "password": {
                "type": "AzureKeyVaultSecret",
                "store": {
                    "referenceName": "<Azure Key Vault linked service name>",
                    "type": "LinkedServiceReference"
                },
                "secretName": "<secretName>"
            }
        },
        "connectVia": {
            "referenceName": "<name of Integration Runtime>",
            "type": "IntegrationRuntimeReference"
        }
    }
}

Propriedades do conjunto de dados

Para obter uma lista completa de seções e propriedades disponíveis para definir conjuntos de dados, consulte o artigo sobre conjuntos de dados. Esta seção fornece uma lista de propriedades com suporte no conjunto de dados do SQL Server.

Para copiar dados de e para um banco de dados do SQL Server, há suporte para as seguintes propriedades:

Property	Descrição	Obrigatório
tipo	A propriedade type do conjunto de dados deve ser definida como SqlServerTable.	Sim
esquema	Nome do esquema.	Não para a fonte, Sim para o lavatório
tabela	Nome da tabela/vista.	Não para a fonte, Sim para o lavatório
tableName	Nome da tabela/vista com esquema. Esta propriedade é suportada para compatibilidade com versões anteriores. Para nova carga de trabalho, use `schema` e `table`.	Não para a fonte, Sim para o lavatório

Exemplo

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

Propriedades da atividade Copy

Para obter uma lista completa de seções e propriedades disponíveis para uso para definir atividades, consulte o artigo Pipelines . Esta seção fornece uma lista de propriedades com suporte pela origem e pelo coletor do SQL Server.

SQL Server como origem

Gorjeta

Para carregar dados do SQL Server de forma eficiente usando o particionamento de dados, saiba mais em Cópia paralela do banco de dados SQL.

Para copiar dados do SQL Server, defina o tipo de origem na atividade de cópia como SqlSource. As seguintes propriedades são suportadas na seção de origem da atividade de cópia:

Property	Descrição	Obrigatório
tipo	A propriedade type da fonte de atividade de cópia deve ser definida como SqlSource.	Sim
sqlReaderQuery	Use a consulta SQL personalizada para ler dados. Um exemplo é `select * from MyTable`.	Não
sqlReaderStoredProcedureName	Esta propriedade é 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	Esses parâmetros são para o procedimento armazenado. Os valores permitidos são pares de nome ou valor. Os nomes e o invólucro dos parâmetros devem corresponder aos nomes e invólucros dos parâmetros do procedimento armazenado.	Não
Nível de isolamento	Especifica o comportamento de bloqueio de transação para a fonte 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. Consulte este documento para obter mais detalhes.	Não
partitionOptions	Especifica as opções de particionamento de dados usadas para carregar dados do SQL Server. Os valores permitidos são: None (padrão), PhysicalPartitionsOfTable e DynamicRange. Quando uma opção de partição é habilitada (ou seja, não `None`), o grau de paralelismo para carregar simultaneamente dados do SQL Server é controlado pela `parallelCopies` configuração na atividade de cópia.	Não
partitionSettings	Especifique o grupo de configurações para particionamento de dados. Aplique quando a opção de partição não `None`for .	Não
Em `partitionSettings`:
partitionColumnName	Especifique o nome da coluna de origem no número inteiro ou no tipo data/data/hora (`int`, `smallint`, `bigint`, `date`, `smalldatetimedatetimedatetime2`, , ou `datetimeoffset`) que será usado pelo particionamento de intervalo para cópia paralela. Se não for especificado, o índice ou a chave primária da tabela será detetado automaticamente e usado como a coluna de partição. Aplique quando a opção de partição for `DynamicRange`. Se você usar uma consulta para recuperar os dados de origem, conecte `?AdfDynamicRangePartitionCondition` a cláusula WHERE. Para obter um exemplo, consulte a seção Cópia paralela do banco de dados SQL.	Não
partiçãoUpperBound	O valor máximo da coluna de partição para divisão do intervalo de partições. Esse valor é usado para decidir a passada da partição, não para filtrar as linhas na tabela. Todas as linhas na tabela ou no resultado da consulta serão particionadas e copiadas. Se não for especificado, a atividade de cópia detetará automaticamente o valor. Aplique quando a opção de partição for `DynamicRange`. Para obter um exemplo, consulte a seção Cópia paralela do banco de dados SQL.	Não
partiçãoLowerBound	O valor mínimo da coluna de partição para divisão do intervalo de partições. Esse valor é usado para decidir a passada da partição, não para filtrar as linhas na tabela. Todas as linhas na tabela ou no resultado da consulta serão particionadas e copiadas. Se não for especificado, a atividade de cópia detetará automaticamente o valor. Aplique quando a opção de partição for `DynamicRange`. Para obter um exemplo, consulte a seção Cópia paralela do banco de dados SQL.	Não

Tenha em atenção os seguintes pontos:

Se sqlReaderQuery for especificado para SqlSource, a atividade de cópia executará essa consulta na fonte do SQL Server para obter os dados. Você também pode especificar um procedimento armazenado especificando sqlReaderStoredProcedureName e storedProcedureParameters se o procedimento armazenado tiver parâmetros.
Ao usar o procedimento armazenado na origem para recuperar dados, observe se o procedimento armazenado for projetado como retornando esquema diferente quando um valor de parâmetro diferente for passado, você poderá encontrar falha ou ver um resultado inesperado ao importar esquema da interface do usuário ou ao copiar dados para o banco de dados SQL com a criação automática de tabelas.

Exemplo: Usar consulta SQL

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

Exemplo: Usar um procedimento armazenado

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

A definição de 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

SQL Server como um coletor

Gorjeta

Saiba mais sobre os comportamentos, configurações e práticas recomendadas de gravação com suporte em Práticas recomendadas para carregar dados no SQL Server.

Para copiar dados para o SQL Server, defina o tipo de coletor na atividade de cópia como SqlSink. As seguintes propriedades são suportadas na seção coletor de atividade de cópia:

Property	Descrição	Obrigatório
tipo	A propriedade type do coletor de atividade de cópia deve ser definida como SqlSink.	Sim
pré-CopyScript	Esta propriedade especifica uma consulta SQL para a atividade de cópia a ser executada antes de gravar dados no SQL Server. É invocado apenas uma vez por execução de cópia. Você pode usar essa propriedade para limpar os dados pré-carregados.	Não
tableOption	Especifica se a tabela de coletor deve ser criada automaticamente se não existir com base no esquema de origem. A criação automática de tabelas não é suportada quando o coletor especifica o procedimento armazenado. Os valores permitidos são: `none` (padrão), `autoCreate`.	Não
sqlWriterStoredProcedureName	O nome do procedimento armazenado que define como aplicar dados de origem em uma tabela de destino. Este procedimento armazenado é invocado por lote. Para operações que são executadas apenas uma vez e não têm nada a ver com dados de origem, por exemplo, excluir ou trugar, use a `preCopyScript` propriedade. Veja o exemplo de Invocar um procedimento armazenado de um coletor SQL.	Não
storedProcedureTableTypeParameterName	O nome do parâmetro do tipo de tabela especificado no procedimento armazenado.	Não
sqlWriterTableType	O nome do tipo de tabela a ser usado no procedimento armazenado. A atividade de cópia torna os dados que estão sendo movidos disponíveis 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. Os valores permitidos são pares de nome e valor. Os nomes e o invólucro dos parâmetros devem corresponder aos nomes e invólucros dos parâmetros do procedimento armazenado.	Não
writeBatchSize	Número de linhas a serem inseridas na tabela SQL por lote. Os valores permitidos são inteiros para o número de linhas. Por padrão, o serviço determina dinamicamente o tamanho de lote apropriado com base no tamanho da linha.	Não
writeBatchTimeout	O tempo de espera para que a operação de inserção, upsert e procedimento armazenado seja concluída antes que ele atinja o tempo limite. Os valores permitidos são para o período de tempo. Um exemplo é "00:30:00" por 30 minutos. Se nenhum valor for especificado, o tempo limite será padronizado como "00:30:00".	Não
maxConcurrentConnections	O limite superior de conexões simultâneas estabelecidas para o armazenamento de dados durante a execução da atividade. Especifique um valor somente quando quiser limitar conexões simultâneas.	Não
WriteBehavior	Especifique o comportamento de gravação para a atividade de cópia para carregar dados no Banco de Dados do SQL Server. O valor permitido é Inserir e Upsert. Por padrão, o serviço usa inserir para carregar dados.	Não
upsertSettings	Especifique o grupo de configurações para o comportamento de gravação. Aplique quando a opção WriteBehavior for `Upsert`.	Não
Em `upsertSettings`:
useTempDB	Especifique se deseja usar uma tabela temporária global ou uma 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. valor é `true`.	Não
interimSchemaName	Especifique o esquema provisório para criar uma tabela provisória se a tabela física for usada. Nota: o usuário precisa ter a permissão para criar e excluir tabela. Por padrão, a tabela provisória compartilhará o mesmo esquema da tabela de coletores. Aplique quando a opção useTempDB for `False`.	Não
chaves	Especifique os nomes das colunas para identificação de linha exclusiva. Uma única chave ou uma série de chaves podem ser usadas. Se não for especificado, a chave primária será usada.	Não

Exemplo 1: Acrescentar dados

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

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

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

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

Exemplo 3: Dados Upsert

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

Cópia paralela do banco de dados SQL

O conector do SQL Server na atividade de cópia 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 ecrã das opções de partição

Quando você habilita a cópia particionada, a atividade de cópia executa consultas paralelas na fonte do SQL Server para carregar dados por partições. O grau paralelo é controlado pela parallelCopies configuração na atividade de cópia. Por exemplo, se você definir parallelCopies como quatro, o serviço gerará e executará simultaneamente quatro consultas com base na opção e nas configurações de partição especificadas, e cada consulta recuperará uma parte dos dados do SQL Server.

Sugere-se que habilite a cópia paralela com particionamento de dados, especialmente quando você carrega uma grande quantidade de dados do SQL Server. A seguir estão sugeridas configurações para diferentes cenários. Ao copiar dados para o armazenamento de dados baseado em arquivo, é recomendável gravar em uma pasta como vários arquivos (especifique apenas o nome da pasta), caso em que o desempenho é melhor do que gravar em um único arquivo.

Cenário	Configurações sugeridas
Carga completa a partir de uma mesa grande, com divisórias físicas.	Opção de partição: Partições físicas da tabela. Durante a execução, o serviço deteta automaticamente as partições físicas e copia os dados por partições. Para verificar se a sua tabela tem partição física ou não, pode consultar esta consulta.
Carga completa a partir de uma tabela grande, sem partições físicas, enquanto com uma coluna inteira ou datetime para 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 especificado, a coluna de chave primária será usada. Limite superior da partição e limite inferior da partição (opcional): Especifique se deseja determinar o passo da partição. Isso não é para filtrar as linhas na tabela, todas as linhas na tabela serão particionadas e copiadas. Se não for especificado, a atividade de cópia deteta automaticamente os valores e pode levar muito tempo, dependendo dos valores MIN e MAX. Recomenda-se fornecer limite superior e limite inferior. Por exemplo, se a coluna de partição "ID" tiver valores que variam de 1 a 100 e você definir o limite inferior como 20 e o limite superior como 80, com cópia paralela como 4, o serviço recuperará dados por 4 partições - IDs no intervalo <=20, [21, 50], [51, 80] e >=81, respectivamente.
Carregue uma grande quantidade de dados usando uma consulta personalizada, sem partições físicas, enquanto com uma coluna inteira ou data/data/hora para particionamento de dados.	Opções de partição: Partição de intervalo dinâmico. Consulta: `SELECT * FROM <TableName> WHERE ?AdfDynamicRangePartitionCondition 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 passo da partição. Isso não é para filtrar as linhas na tabela, todas as linhas no resultado da consulta serão particionadas e copiadas. Se não for especificado, a atividade de cópia detetará automaticamente o valor. Durante a execução, o serviço substitui `?AdfRangePartitionColumnName` pelo nome da coluna real e intervalos de valores para cada partição e envia para o SQL Server. Por exemplo, se a coluna de partição "ID" tiver valores que variam de 1 a 100 e você definir o limite inferior como 20 e o limite superior como 80, com cópia paralela como 4, o serviço recuperará dados por 4 partições - IDs no intervalo <=20, [21, 50], [51, 80] e >=81, respectivamente. Aqui estão mais consultas de exemplo para diferentes cenários: 1. Consulte toda a tabela: `SELECT * FROM <TableName> WHERE ?AdfDynamicRangePartitionCondition` 2. Consulta a partir de uma tabela com seleção de colunas e filtros adicionais de cláusula where: `SELECT <column_list> FROM <TableName> WHERE ?AdfDynamicRangePartitionCondition AND <your_additional_where_clause>` 3. Consulta com subconsultas: `SELECT <column_list> FROM (<your_sub_query>) AS T WHERE ?AdfDynamicRangePartitionCondition AND <your_additional_where_clause>` 4. Consulta com partição em subconsulta: `SELECT <column_list> FROM (SELECT <your_sub_query_column_list> FROM <TableName> WHERE ?AdfDynamicRangePartitionCondition) AS T`

Práticas recomendadas para carregar dados com a opção de partição:

Escolha uma coluna distinta como coluna de partição (como chave primária ou chave exclusiva) para evitar distorção de dados.
Se a tabela tiver partição incorporada, use a opção de partição "Partições físicas da tabela" para obter um melhor desempenho.
Se você usar o Tempo de Execução de Integração do Azure para copiar dados, poderá definir "Unidades de Integração de Dados (DIU)" (>4) maiores para utilizar mais recursos de computação. Verifique os cenários aplicáveis lá.
"Grau de paralelismo de cópia" controlar os números de partição, definir este número muito grande às vezes prejudica o desempenho, recomendo definir este número como (DIU ou número de nós IR auto-hospedados) * (2 a 4).

Exemplo: carga completa a partir de uma mesa grande com partições físicas

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

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

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

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 partição física, você verá "HasPartition" como "sim" como a seguir.

Resultado da consulta SQL

Práticas recomendadas para carregar dados no SQL Server

Ao copiar dados para o SQL Server, você pode precisar de um comportamento de gravação diferente:

Acrescentar: Meus dados de origem têm apenas novos registros.
Upsert: Meus dados de origem têm inserções e atualizações.
Substituir: Quero recarregar toda a tabela de dimensões de cada vez.
Escrever com lógica personalizada: preciso de processamento extra antes da inserção final na tabela de destino.

Consulte as respetivas seções para saber como configurar e práticas recomendadas.

Acrescentar dados

A anexação de dados é o comportamento padrão desse conector de coletor do SQL Server. O serviço faz uma inserção em massa para gravar na sua tabela de forma eficiente. Você pode configurar a origem e o coletor de acordo com a atividade de cópia.

Fazer upsert de dados

A atividade de cópia agora suporta o 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 insira novos dados. Para saber mais sobre configurações de upsert em atividades de cópia, consulte SQL Server como um coletor.

Substituir a tabela inteira

Você pode configurar a propriedade preCopyScript em um coletor de atividade de cópia. Nesse caso, para cada atividade de cópia executada, o serviço executa o script primeiro. 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 primeiro excluir todos os registros antes de carregar em massa os novos dados da fonte.

Gravar dados com lógica personalizada

As etapas para gravar dados com lógica personalizada são semelhantes às descritas na seção Dados Upsert. Quando precisar aplicar processamento extra antes da inserção final dos dados de origem na tabela de destino, você poderá carregar em uma tabela de preparo e, em seguida, invocar a atividade de procedimento armazenado ou invocar um procedimento armazenado no coletor de atividade de cópia para aplicar dados.

Invocar um procedimento armazenado a partir de um coletor SQL

Ao copiar dados para o banco de dados do SQL Server, 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 aproveita os parâmetros com valor de tabela. Observe que o serviço encapsula automaticamente o procedimento armazenado em sua própria transação, portanto, qualquer transação criada dentro do procedimento armazenado se tornará uma transação aninhada e poderá ter implicações para o tratamento de exceções.

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

O exemplo a seguir mostra como usar um procedimento armazenado para fazer um upsert em uma tabela no banco de dados do SQL Server. Suponha que os dados de entrada e a tabela Marketing do coletor tenham três colunas: ProfileID, State e Category. Faça o upsert com base na coluna ProfileID e aplique-o apenas para uma categoria específica chamada "ProductA".

Em seu banco de dados, defina o tipo de tabela com o mesmo nome de 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
)
```

Em seu banco de dados, defina o procedimento armazenado com o mesmo nome de sqlWriterStoredProcedureName. Ele lida com dados de entrada de sua fonte especificada e mescla na tabela de saída. O nome do parâmetro do tipo de tabela no procedimento armazenado é o mesmo que 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

Defina a seção do coletor SQL na atividade de cópia da seguinte maneira:

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

Mapeando propriedades de fluxo de dados

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

Nota

Para acessar o SQL Server local, você precisa usar o Azure Data Factory ou a Rede Virtual Gerenciada do espaço de trabalho Synapse usando um ponto de extremidade privado. Consulte este tutorial para obter etapas detalhadas.

Transformação da fonte

A tabela abaixo lista as propriedades suportadas pela origem do SQL Server. Você pode editar essas propriedades na guia Opções de origem .

Nome	Descrição	Obrigatório	Valores permitidos	Propriedade do script de fluxo de dados
Tabela	Se você selecionar Tabela como entrada, o fluxo de dados buscará todos os dados da tabela especificada no conjunto de dados.	Não	-	-
Query	Se você selecionar Consulta como entrada, especifique uma consulta SQL para buscar dados da origem, que substituirá qualquer tabela especificada no conjunto de dados. Usar consultas é uma ótima maneira de reduzir linhas para testes ou pesquisas. A cláusula Order By não é suportada, mas você pode definir uma instrução SELECT FROM completa. Você também pode usar funções de tabela definidas pelo usuário. *select from udfGetData()** é um UDF em SQL que retorna uma tabela que você pode usar no fluxo de dados. Exemplo de consulta: `Select * from MyTable where customerId > 1000 and customerId < 2000`	Não	String	query
Tamanho do lote	Especifique um tamanho de lote para fragmentar dados grandes em leituras.	Não	Número inteiro	batchSize
Nível de isolamento	Escolha um dos seguintes níveis de isolamento: - Ler Comprometido - Ler Não confirmado (padrão) - Leitura repetível - Serializável - Nenhum (ignorar o nível de isolamento)	Não	READ_COMMITTED READ_UNCOMMITTED REPEATABLE_READ SERIALIZÁVEL NENHUM	Nível de isolamento
Ativar extração incremental	Use essa opção para informar ao ADF para processar somente linhas que foram alteradas desde a última vez que o pipeline foi executado.	Não	-	-
Coluna de data incremental	Ao usar o recurso de extração incremental, você deve escolher a coluna de data/hora que deseja usar como marca d'água na tabela de origem.	Não	-	-
Habilitar captura nativa de dados de alteração (visualização)	Use essa opção para dizer ao ADF para processar apenas dados delta capturados pela tecnologia de captura de dados de alteração SQL desde a última vez que o pipeline foi executado. Com essa opção, os dados delta, incluindo inserção de linha, atualização e exclusão, serão carregados automaticamente sem a necessidade de qualquer coluna de data incremental. Você precisa habilitar a captura de dados de alteração no SQL Server 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ção nativa.	Não	-	-
Comece a ler desde o início	Definir essa opção com extração incremental instruirá o ADF a ler todas as linhas na primeira execução de um pipeline com a extração incremental ativada.	Não	-	-

Gorjeta

A expressão de tabela comum (CTE) em SQL não é suportada no modo de consulta de fluxo de dados de mapeamento, porque o pré-requisito de usar esse modo é que as consultas podem ser usadas na cláusula de consulta SQL FROM, 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

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

Exemplo de script de origem do SQL Server

Quando você usa o SQL Server como tipo de origem, o script de fluxo de dados associado é:

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

Transformação do lavatório

A tabela abaixo lista as propriedades suportadas pelo coletor do SQL Server. Você pode editar essas propriedades na guia Opções do coletor .

Nome	Descrição	Obrigatório	Valores permitidos	Propriedade do script de fluxo de dados
Método de atualização	Especifique quais operações são permitidas no destino do banco de dados. O padrão é permitir apenas inserções. Para atualizar, atualizar ou excluir linhas, uma transformação de linha Alter é necessária para marcar linhas para essas ações.	Sim	`true` ou `false`	suprimido inserível atualizável Atualizável
Colunas-chave	Para atualizações, upserts e exclusões, a(s) coluna(s) chave(s) deve(m) ser definida(s) para determinar qual linha alterar. O nome da coluna que você escolher como a chave será usado como parte da atualização subsequente, upsert, excluir. Portanto, você deve escolher uma coluna que existe no mapeamento de coletor.	Não	Matriz	chaves
Ignorar colunas de teclas de escrita	Se desejar não escrever o valor na coluna de chave, selecione "Ignorar colunas de chave de escrita".	Não	`true` ou `false`	skipKeyEscreve
Ação da tabela	Determina se todas as linhas da tabela de destino devem ser recriadas ou removidas antes da gravação. - Nenhuma: Nenhuma ação será feita para a mesa. - Recriar: A tabela será descartada e recriada. Necessário se criar uma nova tabela dinamicamente. - Truncate: Todas as linhas da tabela de destino serão removidas.	Não	`true` ou `false`	recriar truncate
Tamanho do lote	Especifique quantas linhas estão sendo escritas em cada lote. Lotes maiores melhoram a compactação e a otimização da memória, mas correm o risco de exceções de falta de memória ao armazenar dados em cache.	Não	Número inteiro	batchSize
Scripts pré e pós SQL	Especifique scripts SQL de várias linhas que serão executados antes (pré-processamento) e depois que os dados (pós-processamento) forem gravados no banco de dados do coletor.	Não	String	pré-SQLs postSQLs

Gorjeta

Recomenda-se quebrar scripts de lote único com vários comandos em vários lotes.
Somente instruções DDL (Data Definition Language) e DML (Data Manipulation Language) que retornam uma contagem de atualização simples podem ser executadas como parte de um lote. Saiba mais em Executando operações em lote

Exemplo de script de coletor do SQL Server

Quando você usa o SQL Server como tipo de coletor, o script de fluxo de dados associado é:

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

Mapeamento de tipo de dados para SQL Server

Quando você copia dados de e para o SQL Server, os mapeamentos a seguir são usados de tipos de dados do SQL Server para tipos de dados provisórios do Azure Data Factory. Os pipelines Synapse, que implementam o Data Factory, usam os mesmos mapeamentos. Para saber como a atividade de cópia mapeia o esquema de origem e o tipo de dados para o coletor, consulte Mapeamentos de esquema e tipo de dados.

Tipo de dados do SQL Server	Tipo de dados provisórios do Data Factory
bigint	Int64
binário	Byte[]
bit	Boolean
char	String, Char[]
data	DateTime
Datetime	DateTime
datetime2	DateTime
Datetimeoffset	DateTimeOffset
Decimal	Decimal
Atributo FILESTREAM (varbinary(max))	Byte[]
Float	Duplo
image	Byte[]
número inteiro	Int32
dinheiro	Decimal
Nchar	String, Char[]
ntexto	String, Char[]
numérico	Decimal
Nvarchar	String, Char[]
real	Única
versão de linha	Byte[]
PequenoDateTime	DateTime
smallint	Int16
dinheiro pequeno	Decimal
sql_variant	Object
texto	String, Char[]
hora	TimeSpan
carimbo de data/hora	Byte[]
tinyint	Int16
uniqueidentifier	GUID
Varbinary	Byte[]
varchar	String, Char[]
xml	String

Nota

Para tipos de dados mapeados para o tipo provisório decimal, atualmente a atividade Copiar suporta precisão de até 28. Se você tiver dados que exijam precisão maior que 28, considere converter em uma cadeia de caracteres em uma consulta SQL.

Ao copiar dados do SQL Server usando o Azure Data Factory, o tipo de dados de bits é mapeado para o tipo de dados provisório booleano. Se você tiver dados que precisam ser mantidos como o tipo de dados de bits, use consultas com T-SQL CAST ou CONVERT.

Propriedades da atividade de pesquisa

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

Propriedades de atividade GetMetadata

Para saber detalhes sobre as propriedades, verifique a atividade GetMetadata

Usando sempre criptografado

Quando você copia dados de/para o SQL Server com Always Encrypted, siga as etapas abaixo:

Armazene a Chave Mestra de Coluna (CMK) em um Cofre de Chaves do Azure. Saiba mais sobre como configurar o Always Encrypted usando o Azure Key Vault
Certifique-se de conceder acesso ao cofre de chaves onde a Chave Mestra de Coluna (CMK) está armazenada. Consulte este artigo para obter as permissões necessárias.
Crie um serviço vinculado para se conectar ao seu banco de dados SQL e habilite a função 'Sempre criptografado' usando a identidade gerenciada ou a entidade de serviço.

Nota

O SQL Server Always Encrypted oferece suporte aos cenários abaixo:

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

Nota

Atualmente, o SQL Server Always Encrypted só tem suporte para transformação de origem no mapeamento de fluxos de dados.

Captura nativa de dados de alteração

O Azure Data Factory pode dar suporte a recursos nativos de captura de dados de alteração para SQL Server, Banco de Dados SQL do Azure e SQL MI do Azure. Os dados alterados, incluindo inserção de linha, atualização e exclusão em repositórios SQL, podem ser detetados 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 podem facilmente obter o cenário de replicação de dados de repositórios SQL anexando um banco de dados como armazenamento de destino. Além disso, os usuários também podem compor qualquer lógica de transformação de dados para obter um cenário de ETL incremental a partir de repositórios SQL.

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

Quando você depura o pipeline, esse recurso funciona da mesma forma. Lembre-se de que o ponto de verificação será redefinido quando você atualizar o navegador durante a execução de depuração. Depois de estar satisfeito com o resultado do pipeline da execução de depuração, você pode ir em frente para publicar e acionar o pipeline. No momento em que você aciona pela primeira vez seu pipeline publicado, ele é reiniciado automaticamente desde o início ou recebe alterações a partir de agora.

Na seção de monitoramento, você sempre tem a chance de executar novamente um pipeline. Quando você está fazendo isso, os dados alterados são sempre capturados do ponto de verificação anterior da execução do pipeline selecionado.

Exemplo 1:

Quando você encadeia diretamente uma transformação de origem referenciada ao conjunto de dados habilitado para SQL CDC 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 SQL serão aplicadas automaticamente ao banco de dados de destino, para que você obtenha facilmente o cenário de replicação de dados entre bancos de dados. Você pode usar o método update na transformação do coletor para selecionar se deseja permitir inserir, permitir atualização ou permitir exclusão no banco de dados de destino. O script de exemplo no mapeamento de fluxo de dados é como 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 quiser habilitar o cenário de ETL em vez da replicação de dados entre bancos de dados via SQL CDC, você pode usar expressões no mapeamento de fluxo de dados, incluindo isInsert(1), isUpdate(1) e isDelete(1) para diferenciar as linhas com diferentes tipos de operação. A seguir está um dos scripts de exemplo para mapear o fluxo de dados na derivação de uma coluna com o valor: 1 para indicar linhas inseridas, 2 para indicar linhas atualizadas e 3 para indicar 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:

Somente as alterações líquidas do SQL CDC serão carregadas pelo ADF via cdc.fn_cdc_get_net_changes_.

Resolver problemas de ligação

Configure sua instância do SQL Server para aceitar conexões remotas. Inicie o SQL Server Management Studio, clique com o botão direito do mouse em servidor e selecione Propriedades. Selecione Conexões na lista e marque a caixa de seleção Permitir conexões remotas a este servidor .

Para obter etapas detalhadas, consulte Configurar a opção de configuração do servidor de acesso remoto.
Inicie o SQL Server Configuration Manager. Expanda Configuração de Rede do SQL Server para a instância desejada e selecione Protocolos para MSSQLSERVER. Os protocolos aparecem no painel direito. Habilite o TCP/IP clicando com o botão direito do mouse em TCP/IP e selecionando Ativar.

Para obter mais informações e formas alternativas de ativar o protocolo TCP/IP, consulte Ativar ou desativar um protocolo de rede de servidor.
Na mesma janela, clique duas vezes em TCP/IP para iniciar a janela Propriedades de TCP/IP.
Mude para o separador Endereços IP. Desloque-se para baixo para ver a secção IPAll . Anote a porta TCP. O padrão é 1433.
Crie uma regra para o Firewall do Windows na máquina para permitir o tráfego de entrada através dessa porta.
Verificar conexão: para se conectar ao SQL Server usando um nome totalmente qualificado, use o SQL Server Management Studio de uma máquina diferente. Um exemplo é "<machine>.<domain>.corp.<company>.com,1433".

Para obter uma lista de armazenamentos de dados suportados como fontes e coletores pela atividade de cópia, consulte Armazenamentos de dados suportados.

Copiar e transformar dados de e para o SQL Server usando o Azure Data Factory ou o Azure Synapse Analytics

Capacidades suportadas

Pré-requisitos

Começar agora

Criar um serviço vinculado do SQL Server usando a interface do usuário

Detalhes de configuração do conector

Propriedades do serviço vinculado

Autenticação do SQL

Autenticação do Windows

Propriedades do conjunto de dados

Propriedades da atividade Copy

SQL Server como origem

SQL Server como um coletor

Cópia paralela do banco de dados SQL

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

Práticas recomendadas para carregar dados no SQL Server

Acrescentar dados

Fazer upsert de dados

Substituir a tabela inteira

Gravar dados com lógica personalizada

Invocar um procedimento armazenado a partir de um coletor SQL

Mapeando propriedades de fluxo de dados

Transformação da fonte

Exemplo de script de origem do SQL Server

Transformação do lavatório

Exemplo de script de coletor do SQL Server

Mapeamento de tipo de dados para SQL Server

Propriedades da atividade de pesquisa

Propriedades de atividade GetMetadata

Usando sempre criptografado

Captura nativa de dados de alteração

Exemplo 1:

Exemplo 2:

Limitação conhecida:

Resolver problemas de ligação

Conteúdos relacionados

Recursos adicionais