Copiar e transformar dados na instância gerenciada do Azure SQL usando o pipeline do Azure Data Factory ou Synapse Analytics
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 para copiar dados de e para a Instância Gerenciada de SQL do Azure e usar o Fluxo de Dados para transformar dados na Instância Gerenciada de SQL do Azure. Para saber mais, leia o artigo introdutório do Azure Data Factory e do Synapse Analytics.
Funcionalidades com suporte
Este conector de Instância Gerenciada de SQL do Azure tem suporte para as seguintes funcionalidades:
Funcionalidades com suporte | IR | Ponto de extremidade privado gerenciado |
---|---|---|
Atividade de cópia (origem/coletor) | ① ② | ✓ Versão prévia pública |
Fluxo de dados de mapeamento (origem/coletor) | ① | ✓ Versão prévia pública |
Atividade de pesquisa | ① ② | ✓ Versão prévia pública |
Atividade GetMetadata | ① ② | ✓ Versão prévia pública |
Atividade de Script | ① ② | ✓ Versão prévia pública |
Stored procedure activity (Atividade de procedimento armazenado) | ① ② | ✓ Versão prévia pública |
① Runtime de integração do Azure ② Runtime de integração auto-hospedada
Para a atividade Copy, este conector do Banco de Dados SQL do Azure dá suporte a estas funções:
- Copiar dados usando a autenticação de token do Microsoft Entra e autenticação do SQL com uma entidade de serviço ou identidades gerenciadas para os recursos do Azure.
- Como uma origem, recuperar dados usando uma consulta SQL ou procedimento armazenado. Também é possível optar por copiar paralelamente da origem da MI de SQL, consulte a seção cópia paralela da MI de SQL para obter detalhes.
- Como um coletor, criar automaticamente a tabela de destino, se não existir uma, com base no esquema de origem; acrescentar dados a uma tabela ou invocar um procedimento armazenado com lógica personalizada durante a cópia.
Pré-requisitos
Para acessar o ponto de extremidade público da Instância Gerenciada de SQL, você pode usar um runtime de integração do Azure gerenciada. Certifique-se de habilitar o ponto de extremidade público e também permitir o tráfego do ponto de extremidade público no grupo de segurança de rede para que o serviço possa se conectar ao seu banco de dados. Para obter mais informações, consulte estas diretrizes.
Para acessar o ponto de extremidade privado da Instância Gerenciada de SQL, configure um runtime de integração auto-hospedada que possa acessar o banco de dados. Se você provisionar o runtime de integração auto-hospedada na mesma rede virtual que sua instância gerenciada, verifique se o computador do Integration Runtime está em uma sub-rede diferente de sua instância gerenciada. Se você provisionar seu runtime de integração auto-hospedada em uma rede virtual diferente de sua instância gerenciada, poderá usar um emparelhamento de rede virtual ou uma rede virtual para a conexão de rede virtual. Para obter mais informações, confira Conectar seu aplicativo à Instância Gerenciada de SQL.
Introdução
Para executar a atividade de Cópia com um pipeline, será possível usar as ferramentas ou os SDKs abaixo:
- A ferramenta Copiar Dados
- O portal do Azure
- O SDK do .NET
- O SDK do Python
- PowerShell do Azure
- A API REST
- O modelo do Azure Resource Manager
Criar um serviço vinculado para uma Instância Gerenciada do SQL do Azure usando a interface do usuário
Use as etapas a seguir para criar um serviço vinculado para uma Instância Gerenciada do SQL na interface do usuário do portal do Azure.
Navegue até a guia Gerenciar no workspace do Azure Data Factory ou do Synapse e selecione Serviços Vinculados. Depois, clique em Novo:
Pesquise por SQL e selecione o conector da Instância Gerenciada do Azure 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 a seguir fornecem detalhes sobre as propriedades que são usadas para definir entidades do Azure Data Factory específicas para o conector de Instância Gerenciada de SQL.
Propriedades do serviço vinculado
A versão recomendada do conector da Instância Gerenciada de SQL do Azure dá suporte ao TLS 1.3. Consulte esta seção para atualizar a versão do conector da Instância Gerenciada de SQL do Azure daquele Herdado. Para obter os detalhes da propriedade, consulte as seções correspondentes.
Versão recomendada
Essas propriedades genéricas têm suporte de um serviço vinculado do Instância Gerenciada de SQL do Azure quando você aplica a versão Recomendada:
Propriedade | Descrição | Obrigatório |
---|---|---|
type | A propriedade type deve ser definida como AzureSqlMI. | Yes |
Servidor | O nome ou o endereço de rede da instância de servidor SQL à qual você deseja se conectar. | Yes |
Banco de Dados | O nome do banco de dados. | Yes |
authenticationType | O tipo usado para autenticação. Os valores permitidos são SQL (padrão), ServicePrincipal, SystemAssignedManagedIdentity, UserAssignedManagedIdentity. Acesse a seção de autenticação relevante em propriedades e pré-requisitos específicos. | Yes |
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 |
criptografar | Indique se a criptografia TLS é necessária em todos os dados enviados entre o cliente e o servidor. Opções: obrigatória (para true, padrão)/opcional (para false)/strict. | Não |
trustServerCertificate | Indica se o canal será criptografado ao passar pela cadeia de certificados para validar a confiança. | Não |
hostNameInCertificate | O nome do host a ser usado ao validar o certificado do servidor para a conexão. Quando não é especificado, o nome do servidor é usado para validação de certificado. | Não |
connectVia | Esse Integration Runtime é usado para se conectar ao armazenamento de dados. Você pode usar um runtime de integração auto-hospedada ou um runtime de integração do Azure se sua instância gerenciada tiver um ponto de extremidade público e permitir que o serviço acesse-o. Se não especificado, o Azure Integration Runtime padrão será usado. | Yes |
Consulte a tabela abaixo para obter as propriedades de conexão adicionais:
Propriedade | Descrição | Obrigatório |
---|---|---|
applicationIntent | O tipo de carga de trabalho de aplicativo ao conectar-se a um servidor. Os valores permitidos são ReadOnly e ReadWrite . |
Não |
connectTimeout | O período time (em segundos) a aguardar para uma conexão ao servidor antes de terminar a tentativa e gerar um erro. | Não |
connectRetryCount | O número de tentativas de reconexões após identificar uma falha por conexão ociosa. O valor deve ser um número inteiro entre 0 e 255. | Não |
connectRetryInterval | O tempo (em segundos) entre cada tentativa de reconexão após identificar uma falha por conexão ociosa. O valor deve ser um número inteiro entre 1 e 60. | Não |
loadBalanceTimeout | O tempo mínimo (em segundos) para que a conexão resida no pool de conexões antes da conexão ser destruída. | Não |
commandTimeout | Define o tempo de espera (em segundos) antes de encerrar a tentativa de executar um comando e antes de gerar um erro. | Não |
integratedSecurity | Os valores permitidos são true e false . Ao especificar false , indique se userName e password estão especificados na conexão. Ao especificar true , indica se as credenciais atuais da conta do Windows são usadas para autenticação. |
Não |
failoverPartner | O nome ou endereço do servidor parceiro ao qual se conectar se o servidor primário estiver inativo. | Não |
maxPoolSize | O número máximo de conexões permitidas no pool de conexões para a conexão específica. | Não |
minPoolSize | O número mínimo de conexões permitidas no pool de conexões para a conexão específica. | Não |
multipleActiveResultSets | Os valores permitidos são true e false . Ao especificar true , um aplicativo pode manter vários conjuntos de resultados ativos múltiplos (MARS). Ao você especificar false , um aplicativo deve processar ou cancelar todos os conjuntos de resultados de um lote antes de poder executar outros lotes nessa conexão. |
Não |
multiSubnetFailover | Os valores permitidos são true e false . Se o aplicativo estiver se conectando a um AG (grupo de disponibilidade) AlwaysOn em diferentes sub-redes, definir true como true fornece uma detecção e uma conexão mais rápida ao servidor atualmente ativo. |
Não |
packetSize | Tamanho em bytes dos pacotes de rede usados para comunicar-se com uma instância de servidor. | Não |
pooling | Os valores permitidos são true e false . Ao especificar true , a conexão será colocada em pool. Ao especificar false , a conexão será aberta explicitamente toda vez que a conexão for solicitada. |
Não |
Autenticação do SQL
Para usar a autenticação SQL, além das propriedades genéricas descritas na seção anterior, especifique as seguintes propriedades:
Propriedade | Descrição | Obrigatório |
---|---|---|
userName | O nome de usuário usado para se conectar ao servidor. | Yes |
password | A senha do 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. | Yes |
Exemplo 1: usar a autenticação SQL
{
"name": "AzureSqlMILinkedService",
"properties": {
"type": "AzureSqlMI",
"typeProperties": {
"server": "<name or network address of the SQL server instance>",
"database": "<database name>",
"encrypt": "<encrypt>",
"trustServerCertificate": false,
"authenticationType": "SQL",
"userName": "<user name>",
"password": {
"type": "SecureString",
"value": "<password>"
}
},
"connectVia": {
"referenceName": "<name of Integration Runtime>",
"type": "IntegrationRuntimeReference"
}
}
}
Exemplo 2: usar a autenticação SQL com senha no Azure Key Vault
{
"name": "AzureSqlMILinkedService",
"properties": {
"type": "AzureSqlMI",
"typeProperties": {
"server": "<name or network address of the SQL server instance>",
"database": "<database name>",
"encrypt": "<encrypt>",
"trustServerCertificate": false,
"authenticationType": "SQL",
"userName": "<user name>",
"password": {
"type": "AzureKeyVaultSecret",
"store": {
"referenceName": "<Azure Key Vault linked service name>",
"type": "LinkedServiceReference"
},
"secretName": "<secretName>"
}
},
"connectVia": {
"referenceName": "<name of Integration Runtime>",
"type": "IntegrationRuntimeReference"
}
}
}
Exemplo 3: usar a autenticação SQL com Always Encrypted
{
"name": "AzureSqlMILinkedService",
"properties": {
"type": "AzureSqlMI",
"typeProperties": {
"server": "<name or network address of the SQL server instance>",
"database": "<database name>",
"encrypt": "<encrypt>",
"trustServerCertificate": false,
"authenticationType": "SQL",
"userName": "<user name>",
"password": {
"type": "SecureString",
"value": "<password>"
}
},
"alwaysEncryptedSettings": {
"alwaysEncryptedAkvAuthType": "ServicePrincipal",
"servicePrincipalId": "<service principal id>",
"servicePrincipalKey": {
"type": "SecureString",
"value": "<service principal key>"
}
},
"connectVia": {
"referenceName": "<name of Integration Runtime>",
"type": "IntegrationRuntimeReference"
}
}
}
Autenticação de entidade de serviço
Para usar a autenticação de entidade de serviço, além das propriedades genéricas descritas na seção anterior, especifique as propriedades a seguir
Propriedade | Descrição | Obrigatório |
---|---|---|
servicePrincipalId | Especifique a ID do cliente do aplicativo. | Yes |
servicePrincipalCredential | A credencial da entidade de serviço. Especifique a chave do aplicativo. Marque este campo como um SecureString para armazená-lo com segurança ou referencie um segredo armazenado no Azure Key Vault. | Yes |
locatário | Especifique as informações de locatário, como nome de domínio ou ID do locatário, em que o aplicativo reside. Recupere-as passando o mouse no canto superior direito do Portal do Azure. | Sim |
azureCloudType | Para autenticação da entidade de serviço, especifique o tipo de ambiente em nuvem do Azure em que seu aplicativo do Microsoft Entra está registrado. Os valores permitidos são AzurePublic, AzureChina, AzureUsGovernment e AzureGermany. Por padrão, é usado o ambiente de nuvem do serviço. |
Não |
Você também precisa seguir as etapas abaixo:
Siga as etapas para Provisionar um administrador do Microsoft Entra na sua Instância Gerenciada.
Criar um aplicativo do Microsoft Entra no portal do Azure. Anote o nome do aplicativo e os seguintes valores que definem o serviço vinculado:
- ID do aplicativo
- Chave do aplicativo
- ID do locatário
Crie logons para a entidade de serviço. No SQL Server Management Studio (SSMS), conecte-se à sua instância gerenciada usando uma conta do SQL Server que seja um sysadmin. No banco de dados mestre, execute o seguinte T-SQL:
CREATE LOGIN [your application name] FROM EXTERNAL PROVIDER
Crie usuários de banco de dados contidos para o diretor de serviços. Conecte-se ao banco de dados do ou para o qual você deseja copiar dados. Execute o seguinte T-SQL:
CREATE USER [your application name] FROM EXTERNAL PROVIDER
Conceda ao principal de serviço as permissões necessárias, como faria normalmente para usuários do SQL e outros. Execute o código a seguir. Para mais opções, confira este documento.
ALTER ROLE [role name e.g. db_owner] ADD MEMBER [your application name]
Configure um serviço vinculado de Instância Gerenciada de SQL.
Exemplo: usar autenticação de entidade de serviço
{
"name": "AzureSqlDbLinkedService",
"properties": {
"type": "AzureSqlMI",
"typeProperties": {
"server": "<name or network address of the SQL server instance>",
"database": "<database name>",
"encrypt": "<encrypt>",
"trustServerCertificate": false,
"hostNameInCertificate": "<host name>",
"authenticationType": "ServicePrincipal",
"servicePrincipalId": "<service principal id>",
"servicePrincipalCredential": {
"type": "SecureString",
"value": "<application key>"
},
"tenant": "<tenant info, e.g. microsoft.onmicrosoft.com>"
},
"connectVia": {
"referenceName": "<name of Integration Runtime>",
"type": "IntegrationRuntimeReference"
}
}
}
Autenticação de identidade gerenciada atribuída pelo sistema
É possível associar um data factory ou um workspace do Synapse a uma identidade gerenciada atribuída pelo sistema para recursos do Azure que representa o serviço ao autenticar em outros serviços do Azure. Você pode usar essa identidade gerenciada para autenticação da Instância Gerenciada de SQL. O serviço designado pode acessar dados do banco de dados e copiá-los para o banco de dados usando essa identidade.
Para usar a autenticação de identidade gerenciada atribuída pelo sistema, especifique as propriedades genéricas descritas na seção anterior e siga estas etapas.
Siga as etapas para Provisionar um administrador do Microsoft Entra na sua Instância Gerenciada.
Crie logons para a identidade gerenciada atribuída pelo sistema. No SQL Server Management Studio (SSMS), conecte-se à sua instância gerenciada usando uma conta do SQL Server que seja um sysadmin. No banco de dados mestre, execute o seguinte T-SQL:
CREATE LOGIN [your_factory_or_workspace_ name] FROM EXTERNAL PROVIDER
Crie usuários de banco de dados contidos para a identidade gerenciada atribuída pelo sistema. Conecte-se ao banco de dados do ou para o qual você deseja copiar dados. Execute o seguinte T-SQL:
CREATE USER [your_factory_or_workspace_name] FROM EXTERNAL PROVIDER
Conceda à identidade gerenciada atribuída pelo sistema as permissões necessárias como você faria normalmente para usuários de SQL e outros. Execute o código a seguir. Para mais opções, confira este documento.
ALTER ROLE [role name e.g. db_owner] ADD MEMBER [your_factory_or_workspace_name]
Configure um serviço vinculado de Instância Gerenciada de SQL.
Exemplo: usa a autenticação de identidade gerenciada atribuída pelo sistema
{
"name": "AzureSqlDbLinkedService",
"properties": {
"type": "AzureSqlMI",
"typeProperties": {
"server": "<name or network address of the SQL server instance>",
"database": "<database name>",
"encrypt": "<encrypt>",
"trustServerCertificate": false,
"authenticationType": "SystemAssignedManagedIdentity"
},
"connectVia": {
"referenceName": "<name of Integration Runtime>",
"type": "IntegrationRuntimeReference"
}
}
}
Autenticação de identidade gerenciada atribuída pelo usuário
É possível associar um data factory ou um workspace do Synapse a uma identidade gerenciada atribuída pelo usuário que representa o serviço ao autenticar em outros serviços do Azure. Você pode usar essa identidade gerenciada para autenticação da Instância Gerenciada de SQL. O serviço designado pode acessar dados do banco de dados e copiá-los para o banco de dados usando essa identidade.
Para usar a autenticação de identidade gerenciada atribuída pelo usuário, além das propriedades genéricas descritas na seção anterior, especifique as seguintes propriedades:
Propriedade | Descrição | Obrigatório |
---|---|---|
credenciais | Especifique a identidade gerenciada atribuída pelo usuário como o objeto da credencial. | Sim |
Você também precisa seguir as etapas abaixo:
Siga as etapas para Provisionar um administrador do Microsoft Entra na sua Instância Gerenciada.
Crie logons para a identidade gerenciada atribuída pelo usuário. No SQL Server Management Studio (SSMS), conecte-se à sua instância gerenciada usando uma conta do SQL Server que seja um sysadmin. No banco de dados mestre, execute o seguinte T-SQL:
CREATE LOGIN [your_factory_or_workspace_ name] FROM EXTERNAL PROVIDER
Crie usuários de banco de dados contidos para a identidade gerenciada atribuída pelo usuário. Conecte-se ao banco de dados do ou para o qual você deseja copiar dados. Execute o seguinte T-SQL:
CREATE USER [your_factory_or_workspace_name] FROM EXTERNAL PROVIDER
Crie uma ou várias identidades gerenciadas atribuídas pelo usuário e conceda à identidade gerenciada atribuída pelo usuário as permissões necessárias como você normalmente faz para SQL usuários e outros. Execute o código a seguir. Para mais opções, confira este documento.
ALTER ROLE [role name e.g. db_owner] ADD MEMBER [your_factory_or_workspace_name]
Atribua uma ou várias identidades gerenciadas atribuídas pelo usuário a seu data factory e crie credenciais para cada identidade gerenciada atribuída pelo usuário.
Configure um serviço vinculado de Instância Gerenciada de SQL.
Exemplo: usa a autenticação de identidade gerenciada atribuída pelo usuário
{
"name": "AzureSqlDbLinkedService",
"properties": {
"type": "AzureSqlMI",
"typeProperties": {
"server": "<name or network address of the SQL server instance>",
"database": "<database name>",
"encrypt": "<encrypt>",
"trustServerCertificate": false,
"authenticationType": "UserAssignedManagedIdentity",
"credential": {
"referenceName": "credential1",
"type": "CredentialReference"
}
},
"connectVia": {
"referenceName": "<name of Integration Runtime>",
"type": "IntegrationRuntimeReference"
}
}
}
Versão herdada
Essas propriedades genéricas têm suporte de um serviço vinculado do Instância Gerenciada de SQL do Azure quando você aplica a versão herdada:
Propriedade | Descrição | Obrigatório |
---|---|---|
type | A propriedade type deve ser definida como AzureSqlMI. | Sim |
connectionString | Essa propriedade especifica as informações de connectionString necessárias para conectar-se à Instância Gerenciada de SQL usando a autenticação SQL. Para obter mais informações, consulte os exemplos a seguir. A porta padrão é a 1433. Se você estiver usando a Instância Gerenciada de SQL com um ponto de extremidade público, especifique explicitamente a porta 3342. Você também pode colocar uma senha no Azure Key Vault. Se for a autenticação do SQL, extraia a password configuração da cadeia de conexão. Para obter mais informações, confira Armazenar credenciais no Azure Key Vault. |
Yes |
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. Você pode usar um runtime de integração auto-hospedada ou um runtime de integração do Azure se sua instância gerenciada tiver um ponto de extremidade público e permitir que o serviço acesse-o. Se não especificado, o Azure Integration Runtime padrão será usado. | Yes |
Para diferentes tipos de autenticação, consulte as seguintes seções sobre propriedades específicas e pré-requisitos, respectivamente:
- Autenticação SQL para a versão herdada
- Autenticação da entidade de serviço para a versão herdada
- Autenticação de identidade gerenciada atribuída pelo sistema para a versão herdada
- Autenticação de identidade gerenciada atribuída pelo usuário para a versão herdada
Autenticação SQL para a versão herdada
Para usar a autenticação SQL, especifique as propriedades genéricas descritas na seção anterior.
Autenticação da entidade de serviço para a versão herdada
Para usar a autenticação de entidade de serviço, além das propriedades genéricas descritas na seção anterior, especifique as seguintes propriedades:
Propriedade | Descrição | Obrigatório |
---|---|---|
servicePrincipalId | Especifique a ID do cliente do aplicativo. | Sim |
servicePrincipalKey | Especifique a chave do aplicativo. Marque este campo como um SecureString para armazená-lo com segurança ou referencie um segredo armazenado no Azure Key Vault. | Sim |
locatário | Especifique as informações de locatário, como nome de domínio ou ID do locatário, em que o aplicativo reside. Recupere-as passando o mouse no canto superior direito do Portal do Azure. | Sim |
azureCloudType | Para autenticação da entidade de serviço, especifique o tipo de ambiente em nuvem do Azure em que seu aplicativo do Microsoft Entra está registrado. Os valores permitidos são AzurePublic, AzureChina, AzureUsGovernment e AzureGermany. Por padrão, o data factory ou o ambiente de nuvem do pipeline do Synapse é usado. |
Não |
Você também precisa seguir as etapas na autenticação da entidade de serviço para conceder a permissão correspondente.
Autenticação de identidade gerenciada atribuída pelo sistema para a versão herdada
Para usar a autenticação de identidade gerenciada atribuída pelo sistema, siga a mesma etapa para a versão recomendada na autenticação de identidade gerenciada atribuída pelo sistema.
Autenticação de identidade gerenciada atribuída pelo usuário para versão herdada
Para usar a autenticação de identidade gerenciada atribuída pelo usuário, siga a mesma etapa para a versão recomendada na autenticação de identidade gerenciada atribuída pelo usuário.
Propriedades do conjunto de dados
Para obter uma lista completa das seções e das propriedades disponíveis para uso para definir conjuntos de dados, confira o artigo sobre conjuntos de dados. Esta seção fornece uma lista das propriedades com suporte pelo conjunto de dados da Instância Gerenciada de SQL.
Para copiar dados de e para a Instância Gerenciada de SQL, há suporte para as seguintes propriedades:
Propriedade | Descrição | Obrigatório |
---|---|---|
type | A propriedade type do conjunto de dados deve ser definida como AzureSqlMITable. | 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": "AzureSqlMIDataset",
"properties":
{
"type": "AzureSqlMITable",
"linkedServiceName": {
"referenceName": "<SQL Managed Instance linked service name>",
"type": "LinkedServiceReference"
},
"schema": [ < physical schema, optional, retrievable during authoring > ],
"typeProperties": {
"schema": "<schema_name>",
"table": "<table_name>"
}
}
}
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 da fonte de dados e coletor da Instância Gerenciada de SQL.
Instância Gerenciada de SQL como uma origem
Dica
Para carregar dados da MI de SQL com eficiência usando o particionamento de dados, saiba mais na seção Cópia paralela da MI de SQL.
Para copiar dados da Instância Gerenciada de SQL há suporte para as seguintes propriedades na seção da 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 SqlMISource. | Sim |
sqlReaderQuery | Essa propriedade usa a consulta SQL personalizada para ler 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 dos 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 da MI de SQL. 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 da MI de SQL é 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 ?DfDynamicRangePartitionCondition na cláusula WHERE. Para ver um exemplo, confira a seção Cópia paralela do banco de dados SQL. |
Não |
partitionUpperBound | O valor máximo da coluna de partição para divisão do intervalo de partição. Esse valor é usado para decidir o stride da partição, e não para filtrar as linhas na tabela. Todas as linhas da tabela ou do resultado da consulta serão particionadas e copiadas. Se não for especificado, a atividade de cópia detectará o valor automaticamente. Aplicar quando a opção de partição for DynamicRange . Para ver um exemplo, confira a seção Cópia paralela do banco de dados SQL. |
Não |
partitionLowerBound | O valor mínimo da coluna de partição para divisão do intervalo de partição. Esse valor é usado para decidir o stride da partição, e não para filtrar as linhas na tabela. Todas as linhas da tabela ou do resultado da consulta serão particionadas e copiadas. Se não for especificado, a atividade de cópia detectará o valor automaticamente. Aplicar quando a opção de partição for DynamicRange . Para ver um exemplo, confira a seção Cópia paralela do banco de dados SQL. |
No |
Observe os seguintes pontos:
- Se sqlReaderQuery for especificado para SqlMISource, a atividade de cópia executará essa consulta na origem da Instância Gerenciada de SQL 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 uma consulta SQL
"activities":[
{
"name": "CopyFromAzureSqlMI",
"type": "Copy",
"inputs": [
{
"referenceName": "<SQL Managed Instance input dataset name>",
"type": "DatasetReference"
}
],
"outputs": [
{
"referenceName": "<output dataset name>",
"type": "DatasetReference"
}
],
"typeProperties": {
"source": {
"type": "SqlMISource",
"sqlReaderQuery": "SELECT * FROM MyTable"
},
"sink": {
"type": "<sink type>"
}
}
}
]
Exemplo: usar um procedimento armazenado
"activities":[
{
"name": "CopyFromAzureSqlMI",
"type": "Copy",
"inputs": [
{
"referenceName": "<SQL Managed Instance input dataset name>",
"type": "DatasetReference"
}
],
"outputs": [
{
"referenceName": "<output dataset name>",
"type": "DatasetReference"
}
],
"typeProperties": {
"source": {
"type": "SqlMISource",
"sqlReaderStoredProcedureName": "CopyTestSrcStoredProcedureWithParameters",
"storedProcedureParameters": {
"stringData": { "value": "str3" },
"identifier": { "value": "$$Text.Format('{0:yyyy}', <datetime parameter>)", "type": "Int"}
}
},
"sink": {
"type": "<sink type>"
}
}
}
]
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
Instância Gerenciada de SQL como um coletor
Dica
Saiba mais sobre os comportamentos de gravação com suporte, as configurações e as melhores práticas da Melhor prática para carregar dados no SQL instância gerenciada.
Para copiar dados da Instância Gerenciada de SQL, 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 da atividade de cópia deve ser definida como SqlMISink. | Sim |
preCopyScript | Esta propriedade especifica uma consulta SQL para a atividade de cópia a ser executada antes da gravação de dados na Instância Gerenciada de SQL. É 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 da MI do Banco de Dados SQL do Azure. O valor permitido é insert e upsert. Por padrão, o serviço usa insert para carregar dados. |
Não |
upsertSettings | Especifique o grupo de configurações para comportamento de gravação. Aplicar quando a opção WriteBehavior for Upsert . |
Não |
Em upsertSettings : |
||
useTempDB | Especifique se deseja usar a tabela temporária global ou a tabela física como a tabela provisória para upsert. Por padrão, o serviço usa a tabela temporária global como a tabela provisória. O valor é true . |
Não |
interimSchemaName | Especifique o esquema provisório para criar a tabela provisória se a tabela física for usada. Observação: o usuário precisa ter a permissão para criar e excluir a tabela. Por padrão, a tabela provisória compartilhará o mesmo esquema que a tabela de coletor. Aplicar quando a opção useTempDB for False . |
Não |
chaves | Especifique os nomes de coluna para identificação de linha exclusiva. Uma única chave ou uma série de chaves pode ser usada. Se não for especificada, a chave primária será usada. | Não |
Exemplo 1: acrescentar dados
"activities":[
{
"name": "CopyToAzureSqlMI",
"type": "Copy",
"inputs": [
{
"referenceName": "<input dataset name>",
"type": "DatasetReference"
}
],
"outputs": [
{
"referenceName": "<SQL Managed Instance output dataset name>",
"type": "DatasetReference"
}
],
"typeProperties": {
"source": {
"type": "<source type>"
},
"sink": {
"type": "SqlMISink",
"tableOption": "autoCreate",
"writeBatchSize": 100000
}
}
}
]
Exemplo 2: invocar um procedimento armazenado durante a cópia
Saiba mais detalhes em Invocar um procedimento armazenado de um coletor de MI de SQL.
"activities":[
{
"name": "CopyToAzureSqlMI",
"type": "Copy",
"inputs": [
{
"referenceName": "<input dataset name>",
"type": "DatasetReference"
}
],
"outputs": [
{
"referenceName": "<SQL Managed Instance output dataset name>",
"type": "DatasetReference"
}
],
"typeProperties": {
"source": {
"type": "<source type>"
},
"sink": {
"type": "SqlMISink",
"sqlWriterStoredProcedureName": "CopyTestStoredProcedureWithParameters",
"storedProcedureTableTypeParameterName": "MyTable",
"sqlWriterTableType": "MyTableType",
"storedProcedureParameters": {
"identifier": { "value": "1", "type": "Int" },
"stringData": { "value": "str1" }
}
}
}
}
]
Exemplo 3: Dados upsert
"activities":[
{
"name": "CopyToAzureSqlMI",
"type": "Copy",
"inputs": [
{
"referenceName": "<input dataset name>",
"type": "DatasetReference"
}
],
"outputs": [
{
"referenceName": "<SQL Managed Instance output dataset name>",
"type": "DatasetReference"
}
],
"typeProperties": {
"source": {
"type": "<source type>"
},
"sink": {
"type": "SqlMISink",
"tableOption": "autoCreate",
"writeBehavior": "upsert",
"upsertSettings": {
"useTempDB": true,
"keys": [
"<column name>"
]
},
}
}
}
]
Cópia paralela do MI SQL
O conector de Instância Gerenciada de SQL 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.
Quando você habilita a cópia particionada, a atividade de cópia executa consultas paralelas com relação à origem da MI de SQL 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 MI.
É recomendável habilitar a cópia paralela com o particionamento de dados, especialmente quando você carrega grandes quantidades da MI de SQL. Veja a seguir as configurações sugeridas para cenários diferentes. Ao copiar dados para o armazenamento de dados baseado em arquivo, recomendamos gravá-los em uma pasta como vários arquivos (apenas especifique o nome da pasta) para ter um desempenho melhor do que gravar em um arquivo.
Cenário | Configurações sugeridas |
---|---|
Carregamento completo de uma tabela grande com partições físicas. | Opção de partição: partições físicas da tabela. Durante a execução, o serviço detecta automaticamente as partições físicas e copia os dados por partição. Para verificar se a tabela tem partição física, confira esta consulta. |
Carregamento completo de uma tabela grande, sem partições físicas e com uma coluna de inteiro ou de datetime para o particionamento de dados. | Opções de partição: partição de intervalo dinâmico. Coluna de partição (opcional): especifique a coluna usada para particionar dados. Se não for especificada, a coluna de chave primária ou de índice será usada. Limite superior da partição e limite inferior da partição (opcional): especifique se deseja determinar o stride da partição. A finalidade não é filtrar as linhas na tabela, todas as linhas da tabela serão particionadas e copiadas. Se não for especificado, a atividade Copy detectará os valores automaticamente. Por exemplo, se a “ID” da coluna de partição tiver valores no intervalo de 1 a 100 e você definir o limite inferior como 20 e o limite superior como 80, com a cópia paralela definida como 4, o serviço recuperará dados por 4 IDs de partição no intervalo <=20, [21, 50], [51, 80], e >=81, respectivamente. |
Carregar uma grande quantidade de dados usando uma consulta personalizada, sem partições físicas, com uma coluna de inteiro ou data/datetime para o particionamento de dados. | Opções de partição: partição de intervalo dinâmico. Consulta: SELECT * FROM <TableName> WHERE ?DfDynamicRangePartitionCondition AND <your_additional_where_clause> .Coluna de partição: especifique a coluna usada para particionar dados. Limite superior da partição e limite inferior da partição (opcional): especifique se deseja determinar o stride da partição. A finalidade não é filtrar as linhas na tabela, todas as linhas na consulta serão particionadas e copiadas. Se não for especificado, a atividade de cópia detectará o valor automaticamente. Por exemplo, se a “ID” da coluna de partição tiver valores no intervalo de 1 a 100 e você definir o limite inferior como 20 e o limite superior como 80, com a cópia paralela definida como 4, o serviço recuperará dados por 4 IDs de partição no intervalo <=20, [21, 50], [51, 80], e >=81, respectivamente. Veja mais exemplos de consultas para diferentes cenários: 1. Consultar a tabela inteira: SELECT * FROM <TableName> WHERE ?DfDynamicRangePartitionCondition 2. Consultar em uma tabela com seleção de coluna e filtros de cláusula "where" adicionais: SELECT <column_list> FROM <TableName> WHERE ?DfDynamicRangePartitionCondition AND <your_additional_where_clause> 3. Consultar com sub-consultas: SELECT <column_list> FROM (<your_sub_query>) AS T WHERE ?DfDynamicRangePartitionCondition AND <your_additional_where_clause> 4. Consultar com partição na sub-consulta: SELECT <column_list> FROM (SELECT <your_sub_query_column_list> FROM <TableName> WHERE ?DfDynamicRangePartitionCondition) AS T |
Melhores práticas para carregar dados com a opção de partição:
- 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": "SqlMISource",
"partitionOption": "PhysicalPartitionsOfTable"
}
Exemplo: consulta com a partição do intervalo dinâmico
"source": {
"type": "SqlMISource",
"query": "SELECT * FROM <TableName> WHERE ?DfDynamicRangePartitionCondition AND <your_additional_where_clause>",
"partitionOption": "DynamicRange",
"partitionSettings": {
"partitionColumnName": "<partition_column_name>",
"partitionUpperBound": "<upper_value_of_partition_column (optional) to decide the partition stride, not as data filter>",
"partitionLowerBound": "<lower_value_of_partition_column (optional) to decide the partition stride, not as data filter>"
}
}
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.
Melhor prática para carregar dados na Instância Gerenciada de SQL
Ao copiar dados para a Instância Gerenciada de SQL, pode ser necessário um comportamento de gravação diferente:
- Acrescentar: 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 do conector do coletor da Instância Gerenciada de SQL. 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 Instância Gerenciada de SQL 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 a Instância Gerenciada de SQL, você também pode configurar e invocar um procedimento armazenado especificado pelo usuário com parâmetros adicionais em cada lote da tabela de origem. O recurso de procedimento armazenado se beneficia de parâmetros com valores de tabela.
Você pode usar um procedimento armazenado quando os mecanismos internos de cópia não atendem à finalidade. Um exemplo é quando você deseja aplicar processamento adicional antes da inserção final dos dados de origem na tabela de destino. Alguns exemplos de processamento 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
No pipeline, defina a seção coletor do MI de SQL na atividade de cópia da seguinte maneira:
"sink": { "type": "SqlMISink", "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 da Instância Gerenciada de SQL do Azure. Para obter mais informações, confira transformação de origem e transformação do coletor nos fluxos de dados de mapeamento.
Transformação de origem
A tabela abaixo lista as propriedades com suporte da fonte da Instância Gerenciada de SQL do Azure. 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 incremental | Ao usar o recurso de extração incremental, será necessário escolher a coluna de data/hora ou numérica 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 incremental. Será necessário habilitar a captura de dados de alterações na MI do SQL do Azure antes de usar essa opção no ADF. Para obter mais informações sobre essa opção no ADF, consulte captura de dados de alterações nativas. | 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
. Depois, você poderá usar CTEs conforme o esperado.
Exemplo de script de origem da Instância Gerenciada de SQL do Azure
Quando você usa a Instância Gerenciada de SQL do Azure 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') ~> SQLMISource
Transformação de coletor
A tabela abaixo lista as propriedades com suporte pelo coletor de Instância Gerenciada de SQL do Azure. 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 Executar operações em lote
Exemplo de script de coletor de Instância Gerenciada de SQL do Azure
Quando você usa a Instância Gerenciada de SQL do Azure como tipo de coletor, o script do 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) ~> SQLMISink
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
Mapeamento do tipo de dados para a Instância Gerenciada de SQL
Quando dados são copiados para e da Instância Gerenciada de SQL, os seguintes mapeamentos são usados a partir dos tipos de dados da Instância Gerenciada de SQL para os tipos de dados provisórios usados internamente para o serviço. Para saber mais sobre como a atividade de cópia mapeia do tipo de dados e esquema de origem para o coletor, confira Mapeamentos de tipo de dados e esquema.
Tipo de dados da Instância Gerenciada de SQL | Tipo de dados provisório do serviço |
---|---|
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.
Como usar o Always Encrypted
Ao copiar dados de/para a Instância Gerenciada de SQL com 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
Confirme se concede acesso ao cofre de chaves onde a CMK (chave mestra de coluna) está armazenada. Confira 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
O Always Encrypted da Instância Gerenciada de SQL dá 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
No momento, o Always Encrypted da Instância Gerenciada de SQL dá 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_.
Atualize a versão da Instância Gerenciada de SQL do Azure
Para atualizar a versão do Instância Gerenciada de SQL do Azure, na página Editar serviço vinculado, selecione Recomendado em Versão e configure o serviço vinculado, referindo-se às propriedades do serviço vinculado para a versão recomendada.
Diferenças entre a versão recomendada e a versão herdada
A tabela abaixo mostra as diferenças entre a Instância Gerenciada de SQL do Azure usando a versão recomendada e a versão herdada.
Versão recomendada | Versão herdada |
---|---|
Suporta TLS 1.3 via encrypt como strict . |
TLS 1.3 não é compatível. |
Conteúdo relacionado
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.