Copiar e transformar dados de/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

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 de cópia nos pipelines do Azure Data Factory e do Azure Synapse para copiar dados de/para o banco de dados do SQL Server e como 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.

Funcionalidades com suporte

Há suporte para este conector do SQL Server nas seguintes funcionalidades:

Funcionalidades com suporte	IR
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 obter uma lista de armazenamentos de dados que têm suporte como fontes ou coletores da atividade de cópia, confira a tabela Armazenamentos de dados com suporte.

Especificamente, este conector do SQL Server dá suporte a:

SQL Server versão 2005 e superior.
Copiar dados usando a autenticação do SQL ou do Windows.
Como uma origem, recuperar dados usando uma consulta SQL ou um procedimento armazenado. Você também pode optar por copiar paralelamente da origem SQL Server, consulte a seção cópia paralela do banco de dados SQL para obter detalhes.
Como um 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.

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

Importante

A fonte de dados precisa dar suporte ao tipo de dados NVARCHAR, pois afeta a codificação de dados quando uma codificação não universal está sendo aplicada nos dados.

Pré-requisitos

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

Se o armazenamento de dados for um serviço de dados de nuvem gerenciado, você poderá usar o Azure Integration Runtime. Se o acesso for restrito aos IPs que estão 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 runtime de integração da rede virtual gerenciada no Azure Data Factory para acessar a rede local sem instalar e configurar um runtime de integração auto-hospedada.

Para obter mais informações sobre os mecanismos de segurança de rede e as opções compatíveis com o Data Factory, consulte Estratégias de acesso a dados.

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 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 no workspace do Azure Data Factory ou do Synapse, selecione Serviços Vinculados e clique em Novo:
- Azure Data Factory
- Azure Synapse
Procure SQL e selecione o conector SQL Server.
Configure os detalhes do serviço, teste a conexão e crie o novo serviço vinculado.

Detalhes da configuração do conector

As seções que se seguem fornecem detalhes sobre as propriedades usadas para definir entidades dos pipelines do Data Factory e do Synapse específicas ao conector do banco de dados SQL Server.

Propriedades do serviço vinculado

Esse conector do SQL Server dá suporte aos seguintes tipos de autenticação. Consulte as seções correspondentes para obter detalhes.

Autenticação do SQL
Autenticação do Windows

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.

Autenticação SQL

Para usar a autenticação de SQL, há suporte para as seguintes propriedades:

Propriedade	Descrição	Obrigatório
type	A propriedade type deve ser definida como SqlServer.	Sim
connectionString	Especifique as informações de connectionString necessárias para se conectar ao banco de dados do SQL Server. Especifique um nome de logon como seu nome de usuário e verifique se o banco de dados que deseja conectar está mapeado para esse logon. Consulte os exemplos a seguir.	Sim
password	Se quiser colocar uma senha no Azure Key Vault, efetue pull da 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.	No
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. Saiba mais na seção Pré-requisitos. Se não especificado, o Azure Integration Runtime padrão 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 autenticação SQL com uma senha no Azure Key Vault

{
    "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 o Always Encrypted

{
    "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, há suporte para as seguintes propriedades:

Propriedade	Descrição	Obrigatório
type	A propriedade type deve ser definida como SqlServer.	Sim
connectionString	Especifique as informações de connectionString necessárias para se conectar ao banco de dados do SQL Server. Consulte os exemplos a seguir.
userName	Especifique um nome de usuário. Um exemplo é domainname\username.	Sim
password	Especifique uma senha para a conta de usuário que você especificou para o nome de usuário. Marque esse campo como SecureString para armazená-lo com segurança. Você também pode referenciar um segredo armazenado no Azure Key Vault.	Sim
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 saber mais, confira a seção Usar 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. Saiba mais na seção Pré-requisitos. Se não especificado, o Azure Integration Runtime padrão será usado.	Não

Observação

O fluxo de dados não fornece suporte à autenticação do Windows.

Exemplo: usar 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 autenticação do Windows com uma senha no Azure Key Vault

{
    "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 das seções e propriedades disponíveis para definir os conjuntos de dados, confira o artigo sobre conjuntos de dados. Esta seção fornece uma lista das propriedades com suporte pelo o conjunto de dados de SQL Server.

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

Propriedade	Descrição	Obrigatório
type	A propriedade type do conjunto de dados deve ser definida como SqlServerTable.	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

{
    "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 de cópia

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

SQL Server como uma origem

Dica

Para carregar dados do SQL Server com eficiência usando o particionamento de dados, saiba mais na seção 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 propriedades a seguir têm suporte na seção de origem da atividade de cópia:

Propriedade	Descrição	Obrigatório
type	A propriedade type da origem da atividade de cópia deve ser definida como SqlSource.	Sim
sqlReaderQuery	Utiliza a consulta SQL personalizada para ler os dados. Um exemplo é `select * from MyTable`.	Não
sqlReaderStoredProcedureName	Essa 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. 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 de 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 dados simultaneamente de SQL Server é controlado pela configuração `parallelCopies` na atividade de cópia.	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 for especificado, o índice ou a chave primária da tabela será auto-detectado e usado como 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 `?AdfDynamicRangePartitionCondition` 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 SqlSource, a atividade de cópia executará essa consulta na origem do SQL Server 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: usar a 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 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

SQL Server como um coletor

Dica

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

Para copiar dados para o SQL Server, defina o tipo de coletor na atividade de cópia como SqlSink. Há suporte para as seguintes propriedades na seção do coletor da atividade de cópia:

Propriedade	Descrição	Obrigatório
type	A propriedade type do coletor de atividade de cópia deve ser definida como SqlSink.	Sim
preCopyScript	Esta propriedade especifica uma consulta SQL para que a atividade de cópia a ser executada antes da gravação de dados em SQL Server. É chamado apenas uma vez por execução de cópia. Você pode usar essa propriedade para limpar os dados previamente 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. Os valores permitidos são inteiros para o 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
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 do SQL Server. 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": "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 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 de 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 tela das opções de partição

Quando você habilita a cópia particionada, a atividade de cópia executa consultas paralelas com relação à sua fonte do SQL Server 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 especificada e nas configurações, e cada consulta recupera uma parte dos dados do SQL Server.

É recomendável habilitar a cópia paralela com o particionamento de dados, especialmente quando você carrega grandes quantidades de dados do seu SQL Server. 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 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 de cópia detectará automaticamente os valores e poderá levar muito tempo, dependendo dos valores MÍN e MÁX. É recomendável fornecer o limite superior e o limite inferior. 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 ?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 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. Durante a execução, o serviço substitui `?AdfRangePartitionColumnName` pelo nome real da coluna e os intervalos de valores de cada partição e envia ao SQL Server. 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 ?AdfDynamicRangePartitionCondition` 2. Consultar em uma tabela com seleção de coluna e filtros de cláusula "where" adicionais: `SELECT <column_list> FROM <TableName> WHERE ?AdfDynamicRangePartitionCondition AND <your_additional_where_clause>` 3. Consultar com sub-consultas: `SELECT <column_list> FROM (<your_sub_query>) AS T WHERE ?AdfDynamicRangePartitionCondition 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 ?AdfDynamicRangePartitionCondition) AS T`

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

Escolha a coluna distinta como coluna de partição (como chave primária ou chave exclusiva) para evitar a distorção de dados.
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.
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.
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": "SqlSource",
    "partitionOption": "PhysicalPartitionsOfTable"
}

Exemplo: consulta com a partição do 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 uma partição física, você verá "HasPartition" como "yes" conforme segue.

Resultado da consulta SQL

Prática recomendada para carregar dados em SQL Server

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

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

Confira as respectivas seções sobre como configurar e as práticas recomendadas.

Acrescentar dados

Acrescentar dados é o comportamento padrão desse conector do coletor de SQL Server. 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 SQL Server como coletor.

Substituir a tabela inteira

Você pode configurar a propriedade preCopyScript em um coletor de atividade de cópia. 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 de dados Upsert. Quando você precisa aplicar processamento extra antes da inserção final dos dados de origem na tabela de destino, você pode 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 de um coletor SQL

Ao copiar dados para o banco de 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 se beneficia de parâmetros com valores 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 no tratamento de exceção.

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 extra são quando você deseja mesclar colunas, pesquisar 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 de Marketing do coletor tenham três colunas cada um: 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".

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
)
```

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

Defina a seção Coletor SQL na atividade de cópia conforme demonstrado a seguir:

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

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 do SQL Server. Para obter mais informações, confira transformação de origem e transformação do coletor nos fluxos de dados de mapeamento.

Observação

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

Transformação de origem

A tabela abaixo lista as propriedades com suporte por uma fonte do SQL Server. Você pode editar essas propriedades na guia Opções de origem.

Nome	Descrição	Obrigatório	Valores permitidos	Propriedade do script do 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.	No	-	-
Consulta	Se você selecionar consulta como entrada, especifique uma consulta SQL para buscar dados da origem, o que substitui qualquer tabela que você especificar no conjunto de dados. O uso de consultas também é uma ótima maneira de reduzir linhas para testes ou pesquisas. Não há suporte para a cláusula Ordenar por 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 que você pode usar no fluxo de dados. Exemplo de consulta: `Select * from MyTable where customerId > 1000 and customerId < 2000`	Não	String	Consulta
Tamanho do lote	Especifique um tamanho de lote para dividir em partes os dados grandes em leituras.	No	Integer	batchSize
Nível de Isolamento	Escolha um dos seguintes níveis de isolamento: - Leitura confirmada - Leitura não confirmada (padrão) - Leitura repetida - Serializável - Nenhum (ignorar o nível de isolamento)	No	READ_COMMITTED READ_UNCOMMITTED REPEATABLE_READ SERIALIZABLE NONE	isolationLevel
Habilitar a extração incremental	Use esta opção para informar ao ADF para processar apenas as linhas que foram alteradas desde a última vez que o pipeline executou.	Não	-	-
Coluna de data incremental	Ao usar o recurso de extração incremental, será necessário escolher a coluna de data/hora que você deseja usar como marca d'água na tabela de origem.	Não	-	-
Habilitar a captura de dados de alteração nativa (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ção do SQL desde a última vez em 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 de data incremental. É necessário habilitar a captura de dados de alterações 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ções nativas.	Não	-	-
Iniciar a leitura 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	-	-

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. Em seguida, você pode usar as CTEs conforme o esperado.

Exemplo de script de origem do SQL Server

Quando você usa 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 de coletor

A tabela abaixo lista as propriedades com suporte por um 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 do Fluxo de Dados
Método Update	Especifique 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.	Sim	`true` ou `false`	deletable insertable Pode ser atualizado upsertable
Colunas de chaves	Para atualizações, upserts e exclusões, coluna(s) de chave devem ser definidas para determinar qual linha alterar. O nome da coluna que você escolhe como chave será usado como parte da atualização, upsert, exclusão seguinte. Portanto, você deve escolher uma coluna que exista no mapeamento de coletor.	Não	Array	chaves
Ignorar colunas de chave de gravação	Se você não quiser gravar o valor na coluna de chave, selecione "Ignorar gravação de colunas de chave".	No	`true` ou `false`	skipKeyWrites
Ação tabela	determina se deve-se recriar ou remover todas as linhas da tabela de destino antes da gravação. - None: nenhuma ação será feita na tabela. - Recreate: a tabela será descartada e recriada. Necessário ao criar uma tabela dinamicamente. - Truncate: todas as linhas da tabela de destino serão removidas.	Não	`true` ou `false`	recreate truncate
Tamanho do lote	Especifique quantas linhas estão sendo gravadas em cada lote. 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.	No	Integer	batchSize
Pré-scripts e Pós-scripts SQL	Especifique scripts SQL multilinhas que serão executados antes (pré-processamento) e após (pós-processamento) os dados serem gravados no banco de dados do coletor.	Não	String	preSQLs postSQLs

Dica

É recomendável quebrar scripts de lote únicos com vários comandos em vários lotes.
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

Exemplo de script de coletor do SQL Server

Quando você usa 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 o SQL Server

Quando você copia dados de e para o SQL Server, os seguintes mapeamentos são usados de tipos de dados do SQL Server para tipos de dados provisórios do Azure Data Factory. Os pipelines do Synapse, que implementam o Data Factory, usam os mesmos mapeamentos. 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 SQL Server	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	Int16
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 que exijam precisão maior que 28, considere converter para uma cadeia de caracteres em uma consulta SQL.

Ao copiar dados do SQL Server com o Azure Data Factory, o tipo de dados bit é mapeado para o tipo de dados intermediário booliano. Se você tiver dados que precisam ser mantidos no tipo de dados bit, use consultas com T-SQL CAST ou CONVERT.

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 SQL Server com o Always Encrypted, siga as etapas abaixo:

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
Certifique-se de conceder acesso ao cofre de chaves onde a CMK (chave mestra de coluna) está armazenada. Veja este artigo para obter as permissões necessárias.
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

No SQL Server, o Always Encrypted oferece suporte aos cenários abaixo:

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.
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.
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 SQL Server 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:

Apenas as alterações líquidas da CDA do SQL serão carregadas pelo ADF por meio de cdc.fn_cdc_get_net_changes_.

Solucionar problemas de conexão

Configure seu 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 com este servidor.

Para obter etapas detalhadas, consulteConfigurar a opção de configuração do servidor de acesso remoto para obter as etapas detalhadas.
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 Habilitar.

Para obter mais informações e maneiras alternativas de habilitar o protocolo TCP/IP, consulte, Habilitar ou desabilitar um protocolo de rede do servidor.
Na mesma janela, clique duas vezes em TCP/IP para iniciar a janela Propriedades de TCP/IP.
Alterne para a guia Endereços IP. Role para baixo para ver a seção IPAll. Anote a porta TCP. O padrão é 1433.
Crie uma regra para o Firewall do Windows no computador para permitir a entrada de tráfego por essa porta.
Verifique a conexão: para se conectar ao SQL Server usando um nome totalmente qualificado, use o SQL Server Management Studio de um computador diferente. Um exemplo é "<machine>.<domain>.corp.<company>.com,1433".

Para obter uma lista dos armazenamentos de dados com suporte como coletores e fontes da atividade de cópia, confira os Armazenamentos de dados com suporte.

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

Funcionalidades com suporte

Pré-requisitos

Introdução

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

Detalhes da configuração do conector

Propriedades do serviço vinculado

Autenticação SQL

Autenticação do Windows

Propriedades do conjunto de dados

Propriedades da atividade de cópia

SQL Server como uma 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ática recomendada para carregar dados em SQL Server

Acrescentar dados

Upsert data

Substituir a tabela inteira

Gravar dados com lógica personalizada

Invocar um procedimento armazenado de um coletor SQL

Propriedades do fluxo de dados de mapeamento

Transformação de origem

Exemplo de script de origem do SQL Server

Transformação de coletor

Exemplo de script de coletor do SQL Server

Mapeamento de tipo de dados para o SQL Server

Pesquisar propriedades de atividade

Propriedades de atividade GetMetadata

Como usar o Always Encrypted

Captura de dados de alterações nativas

Exemplo 1:

Exemplo 2:

Limitação conhecida:

Solucionar problemas de conexão

Conteúdo relacionado

Recursos adicionais