Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
APLICA-SE A:
Azure Data Factory
Azure Synapse Analytics
Gorjeta
Experimente o Data Factory no Microsoft Fabric, uma solução de análise tudo-em-um para empresas. O Microsoft Fabric abrange tudo, desde a movimentação de dados até ciência de dados, análises em tempo real, business intelligence e relatórios. Saiba como iniciar uma nova avaliação gratuitamente!
Este artigo descreve como usar a Atividade de Cópia para copiar dados de e para a Instância Gerenciada SQL do Azure e usar o Fluxo de Dados para transformar dados na Instância Gerenciada SQL do Azure. Para saber mais, leia os artigos introdutórios do Azure Data Factory e do Synapse Analytics.
Capacidades suportadas
Este conector de Instância Gerenciada SQL do Azure tem suporte para os seguintes recursos:
| Capacidades suportadas | IR | Ponto de extremidade privado gerido |
|---|---|---|
| Atividade de cópia (origem/destino) | (1) (2) | ✓ Pré-visualização pública |
| Mapeando o fluxo de dados (origem/destino) | (1) | ✓ Pré-visualização pública |
| Atividade de Pesquisa | (1) (2) | ✓ Pré-visualização pública |
| Atividade GetMetadata | (1) (2) | ✓ Pré-visualização pública |
| Atividade de script | (1) (2) | ✓ Pré-visualização pública |
| Atividade de procedimento armazenado | (1) (2) | ✓ Pré-visualização pública |
① Tempo de execução de integração do Azure ② Tempo de execução de integração auto-hospedado
Para atividade de cópia, este conector do Banco de Dados SQL do Azure dá suporte a estas funções:
- Copiar dados usando a autenticação SQL e a autenticação de token do Aplicativo Microsoft Entra com uma entidade de serviço ou identidades gerenciadas para recursos do Azure.
- Como origem, recuperando dados usando uma consulta SQL ou um procedimento armazenado. Você também pode optar por copiar paralelamente da fonte SQL MI, consulte a seção Cópia paralela do SQL MI para obter detalhes.
- Como um coletor, criando automaticamente a tabela de destino se não existir com base no esquema de origem; anexar dados a uma tabela ou invocar um procedimento armazenado com lógica personalizada durante a cópia.
Pré-requisitos
Para aceder ao ponto de extremidade público da Instância Gerenciada SQL, pode-se usar um runtime de integração gerido do Azure. Confirme que ativa o ponto final público e que também permite o tráfego de pontos finais públicos no grupo de segurança de rede, para que o serviço se possa ligar à base de dados. Para obter mais informações, consulte estas orientações.
Para aceder ao ponto final privado do SQL Managed Instance, configure um runtime de integração autoalojado que possa aceder à base de dados. Se aprovisionar o runtime de integração autoalojado na mesma rede virtual da instância gerida, confirme que a máquina virtual do runtime de integração está numa sub-rede diferente da instância gerida. Se aprovisionar o runtime de integração autoalojado numa rede virtual diferente da instância gerida na cloud, pode utilizar um emparelhamento de rede virtual ou uma ligação entre redes virtuais. Para obter mais informações, veja Ligar a aplicação ao SQL Managed Instance.
Introdução
Para executar a atividade de cópia com um pipeline, você pode usar uma das seguintes ferramentas ou SDKs:
- Ferramenta Copiar dados
- portal do Azure
- SDK do .NET
- Python SDK
- Azure PowerShell
- API REST
- Modelo Azure Resource Manager
Criar um serviço vinculado a uma instância gerenciada SQL do Azure usando a interface do usuário
Use as etapas a seguir para criar um serviço vinculado a uma instância gerenciada do SQL na interface do usuário do portal do Azure.
Navegue até a guia Gerenciar em seu espaço de trabalho do Azure Data Factory ou Synapse e selecione Serviços Vinculados e clique em Novo:
Procure SQL e selecione o conector de Instância Gerenciada do SQL Server do Azure.
Configure os detalhes do serviço, teste a conexão e crie o novo serviço vinculado.
Detalhes de configuração do conector
As seções a seguir fornecem detalhes sobre as propriedades usadas para definir entidades do Azure Data Factory específicas para o conector da Instância Gerenciada SQL.
Propriedades do serviço vinculado
A versão recomendada do conector da Instância Gerenciada SQL do Azure dá suporte ao TLS 1.3. Consulte esta
Versão recomendada
Estas propriedades genéricas têm suporte para um serviço vinculado de Instância Gerenciada SQL do Azure quando você aplica a versão Recomendada :
| Propriedade | Descrição | Obrigatório |
|---|---|---|
| tipo | A propriedade type deve ser definida como AzureSqlMI. | Sim |
| servidor | O nome ou endereço de rede da instância do SQL Server à qual você deseja se conectar. | Sim |
| base de dados | O nome do banco de dados. | Sim |
| tipoDeAutenticação | O tipo usado para autenticação. Os valores permitidos são SQL (padrão), ServicePrincipal, SystemAssignedManagedIdentity, UserAssignedManagedIdentity. Vá para a seção de autenticação relevante sobre propriedades e pré-requisitos específicos. | Sim |
| sempreConfiguraçõesCriptografadas | Especifique as informações alwaysencryptedsettings necessárias para ativar a funcionalidade Always Encrypted e proteger dados confidenciais armazenados no SQL Server, usando identidade de gestão ou um Service Principal. Para obter mais informações, consulte o exemplo JSON após a tabela e a seção Usando o Always Encrypted. Se não for especificado, a configuração padrão sempre criptografada será desabilitada. | Não |
| cifrar | Indique se a criptografia TLS é necessária para todos os dados enviados entre o cliente e o servidor. Opções: obrigatório (para verdadeiro, padrão)/opcional (para falso)/estrito. | Não |
| confiarNaCertificaçãoDoServidor | Indique se o canal será criptografado enquanto ignora a 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 |
| conectarVia | Este runtime de integração é utilizado para conectar ao armazenamento de dados. Você pode usar um runtime de integração auto-hospedado ou um runtime de integração do Azure se a sua instância gerida tiver um ponto de extremidade público e permitir que o serviço tenha acesso a ele. Se não for especificado, o tempo de execução de integração padrão do Azure será usado. | Sim |
Para obter propriedades de conexão adicionais, consulte a tabela abaixo:
| Propriedade | Descrição | Obrigatório |
|---|---|---|
| applicationIntent | O tipo de carga de trabalho do aplicativo ao se conectar a um servidor. Os valores permitidos são ReadOnly e ReadWrite. |
Não |
| connectTimeout | O período de tempo (em segundos) para aguardar uma conexão com o servidor antes de encerrar a tentativa e gerar um erro. | Não |
| connectRetryCount | O número de reconexões tentadas após a identificação de uma falha de conexão inativa. O valor deve ser um número inteiro entre 0 e 255. | Não |
| connectRetryInterval | A quantidade de tempo (em segundos) entre cada tentativa de reconexão após a identificação de uma falha de 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 a conexão viver no pool de conexões antes que a conexão seja destruída. | Não |
| tempo de espera do comando | O tempo de espera padrão (em segundos) antes de encerrar a tentativa de executar um comando e gerar um erro. | Não |
| Segurança integrada | Os valores permitidos são true ou 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 |
| failover partner | O nome ou endereço do servidor parceiro ao qual se conectar se o servidor primário estiver inativo. | Não |
| tamanhoMáximoDoPool | O número máximo de conexões permitido 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 ou false. Quando você especifica true, um aplicativo pode manter vários conjuntos de resultados ativos (MARS). Quando você especifica false, um aplicativo deve processar ou cancelar todos os conjuntos de resultados de um lote antes de poder executar quaisquer outros lotes nessa conexão. |
Não |
| multiSubnetFailover | Os valores permitidos são true ou false. Se o seu aplicativo estiver a conectar-se a um grupo de disponibilidade AlwaysOn (AG) em sub-redes diferentes, ao definir esta propriedade para true, proporciona uma detecção e conexão mais rápidas com o servidor atualmente ativo. |
Não |
| tamanhoDoPacote | O tamanho em bytes dos pacotes de rede usados para se comunicar com uma instância do servidor. | Não |
| Agrupamento | Os valores permitidos são true ou false. Quando você especificar true, a conexão será agrupada. Quando você 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 |
|---|---|---|
| nome de utilizador | O nome de usuário usado para se conectar ao servidor. | Sim |
| palavra-passe | A senha para o nome de usuário. Marque este campo como SecureString para armazená-lo com segurança. Ou, você pode fazer referência a um segredo armazenado no Cofre da Chave do Azure. | Sim |
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 uma senha no Cofre de Chaves do Azure
{
"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 do principal de serviço
Para usar a autenticação do principal 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 o ID do cliente do aplicativo. | Sim |
| servicePrincipalCredential | A credencial do principal de serviço. Especifique a chave do aplicativo. Marque este campo como SecureString para armazená-lo com segurança ou faça referência a um segredo armazenado no Cofre de Chaves do Azure. | Sim |
| inquilino | Especifique as informações do locatário, como o nome de domínio ou ID do locatário, sob o qual seu aplicativo reside. Recupere-o passando o mouse no canto superior direito do portal do Azure. | Sim |
| azureCloudType | Para autenticação do principal de serviço, especifique o tipo de ambiente de nuvem do Azure no qual a sua aplicação Microsoft Entra está registrada. Os valores permitidos são AzurePublic, AzureChina, AzureUsGovernment e AzureGermany. Por padrão, o ambiente de nuvem do serviço é usado. |
Não |
Você também precisa seguir os passos abaixo:
Siga as etapas para provisionar um administrador do Microsoft Entra para sua instância gerenciada.
Crie um aplicativo Microsoft Entra a partir do portal do Azure. Anote o nome do aplicativo e os seguintes valores que definem o serviço vinculado:
- ID da aplicação
- Chave de aplicação
- ID de Locatário
Crie logins 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 administrador de sistemas. No banco de dados mestre , execute o seguinte T-SQL:
CREATE LOGIN [your application name] FROM EXTERNAL PROVIDERCrie utilizadores de banco de dados contidos para o principal de serviço. Conecte-se ao banco de dados do qual você deseja copiar dados, execute o seguinte T-SQL:
CREATE USER [your application name] FROM EXTERNAL PROVIDERConceda à entidade de serviço as permissões necessárias como normalmente faz para usuários SQL e outros. Execute o código a seguir. Para mais opções, consulte este documento.
ALTER ROLE [role name e.g. db_owner] ADD MEMBER [your application name]Configure um serviço vinculado de Instância Gerenciada SQL.
Exemplo: usar a autenticação da 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
Um data factory ou espaço de trabalho Synapse pode ser associado a uma identidade gerenciada atribuída pelo sistema para recursos do Azure que representa o serviço para autenticação em outros serviços do Azure. Você pode usar essa identidade gerenciada para autenticação de Instância Gerenciada SQL. O serviço designado pode acessar e copiar dados de ou para seu 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 para sua instância gerenciada.
Crie logins para a identidade gerenciada atribuída ao sistema. No SQL Server Management Studio (SSMS), conecte-se à sua instância gerenciada usando uma conta do SQL Server que seja um administrador de sistemas. No banco de dados mestre , execute o seguinte T-SQL:
CREATE LOGIN [your_factory_or_workspace_ name] FROM EXTERNAL PROVIDERCrie usuários de banco de dados contidos para a identidade gerenciada atribuída ao sistema. Conecte-se ao banco de dados do qual você deseja copiar dados, execute o seguinte T-SQL:
CREATE USER [your_factory_or_workspace_name] FROM EXTERNAL PROVIDERConceda as permissões necessárias à identidade gerenciada atribuída ao sistema, como você normalmente faz para usuários SQL e outros. Execute o código a seguir. Para mais opções, consulte 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 SQL.
Exemplo: usa 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
Uma fábrica de dados ou um espaço de trabalho Synapse pode ser associado a identidades geridas atribuídas pelo utilizador que representam o serviço para autenticação em outros serviços do Azure. Você pode usar essa identidade gerenciada para autenticação de Instância Gerenciada SQL. O serviço designado pode acessar e copiar dados de ou para seu 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 de credencial. | Sim |
Você também precisa seguir os passos abaixo:
Siga as etapas para provisionar um administrador do Microsoft Entra para sua instância gerenciada.
Crie logins 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 administrador de sistemas. No banco de dados mestre , execute o seguinte T-SQL:
CREATE LOGIN [your_factory_or_workspace_ name] FROM EXTERNAL PROVIDERCrie usuários de banco de dados contidos para a identidade gerenciada atribuída pelo usuário. Conecte-se ao banco de dados do qual você deseja copiar dados, execute o seguinte T-SQL:
CREATE USER [your_factory_or_workspace_name] FROM EXTERNAL PROVIDERCrie 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 usuários SQL e outros. Execute o código a seguir. Para mais opções, consulte 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 ao seu data factory e crie credenciais para cada identidade gerenciada atribuída pelo usuário.
Configure serviço associado SQL Managed Instance.
Exemplo: usa 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 antiga
Estas propriedades genéricas têm suporte para um serviço vinculado de Instância Gerenciada SQL do Azure quando você aplica a versão herdada :
| Propriedade | Descrição | Obrigatório |
|---|---|---|
| tipo | A propriedade type deve ser definida como AzureSqlMI. | Sim |
| connectionString | Esta propriedade especifica as informações connectionString necessárias para se conectar à Instância Gerenciada SQL usando a autenticação SQL. Para obter mais informações, consulte os exemplos a seguir. A porta predefinida é 1433. Se você estiver usando a Instância Gerenciada SQL com um ponto de extremidade público, especifique explicitamente a porta 3342. Você também pode colocar uma senha no Cofre de Chaves do Azure. Se for autenticação SQL, extraia a password configuração da cadeia de conexão. Para obter mais informações, consulte Armazenar credenciais no Cofre da Chave do Azure. |
Sim |
| sempreConfiguraçõesCriptografadas | Especifique as informações alwaysencryptedsettings necessárias para ativar a funcionalidade Always Encrypted e proteger dados confidenciais armazenados no SQL Server, usando identidade de gestão ou um Service Principal. Para obter mais informações, consulte Using Always Encrypted. Se não for especificado, a configuração padrão sempre criptografada será desabilitada. | Não |
| conectarVia | Este runtime de integração é utilizado para conectar ao armazenamento de dados. Você pode usar um runtime de integração auto-hospedado ou um runtime de integração do Azure se a sua instância gerida tiver um ponto de extremidade público e permitir que o serviço tenha acesso a ele. Se não for especificado, o tempo de execução de integração padrão do Azure será usado. | Sim |
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 de service principal 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 do principal de serviço para a versão legada
Para usar a autenticação do principal 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 o ID do cliente do aplicativo. | Sim |
| chavePrincipalDoServiço | Especifique a chave do aplicativo. Marque este campo como SecureString para armazená-lo com segurança ou fazer referência a um segredo armazenado no Cofre de Chaves do Azure. | Sim |
| inquilino | Especifique as informações do locatário, como o nome de domínio ou ID do locatário, sob o qual seu aplicativo reside. Recupere-o passando o mouse no canto superior direito do portal do Azure. | Sim |
| azureCloudType | Para autenticação do principal de serviço, especifique o tipo de ambiente de nuvem do Azure no qual a sua aplicação Microsoft Entra está registrada. Os valores permitidos são AzurePublic, AzureChina, AzureUsGovernment e AzureGermany. Por padrão, a fábrica de dados ou o ambiente de nuvem do pipeline Synapse é usado. |
Não |
Você também precisa seguir as etapas em 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 gerida atribuída pelo sistema, siga a mesma etapa para a versão recomendada em Autenticação de identidade gerida atribuída pelo sistema.
Autenticação de identidade gerida pelo usuário para versões antigas
Para usar a autenticação de identidade gerenciada atribuída pelo usuário, siga a mesma etapa para a versão recomendada em Autenticação de identidade gerenciada atribuída pelo usuário.
Propriedades do conjunto de dados
Para obter uma lista completa de seções e propriedades disponíveis para uso para definir conjuntos de dados, consulte o artigo sobre conjuntos de dados. Esta seção fornece uma lista de propriedades suportadas pelo conjunto de dados da Instância Gerenciada SQL.
Para copiar dados de e para a Instância Gerenciada SQL, as seguintes propriedades são suportadas:
| Propriedade | Descrição | Obrigatório |
|---|---|---|
| tipo | A propriedade type do conjunto de dados deve ser definida como AzureSqlMITable. | Sim |
| esquema | Nome do esquema. | Não para a fonte, Sim para o lavatório |
| tabela | Nome da tabela/visão. | Não para a fonte, Sim para o lavatório |
| tableName | Nome da tabela/vista com esquema. Esta propriedade é suportada para compatibilidade com versões anteriores. Para nova carga de trabalho, use schema e table. |
Não para a fonte, Sim para o lavatório |
Exemplo
{
"name": "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 Copy
Para obter uma lista completa de seções e propriedades disponíveis para uso para definir atividades, consulte o artigo Pipelines . Esta secção fornece uma lista de propriedades suportadas pela origem e destino da Instância Gerenciada SQL.
Instância gerenciada SQL como origem
Gorjeta
Para carregar dados do SQL MI de forma eficiente usando o particionamento de dados, saiba mais em Cópia paralela do SQL MI.
Para copiar dados da Instância Gerenciada SQL, as seguintes propriedades são suportadas na seção Copiar fonte de atividade:
| Propriedade | Descrição | Obrigatório |
|---|---|---|
| tipo | A propriedade tipo da fonte de atividade de cópia deve ser definida como SqlMISource. | Sim |
| sqlReaderQuery | Esta propriedade usa a consulta SQL personalizada para ler dados. Um exemplo é select * from MyTable. |
Não |
| sqlReaderStoredProcedureName | Esta propriedade é o nome do procedimento armazenado que lê dados da tabela de origem. A última instrução SQL deve ser uma instrução SELECT no procedimento armazenado. | Não |
| parâmetrosDeProcedimentoArmazenado | Esses parâmetros são para o procedimento armazenado. Os valores permitidos são pares de nome ou valor. Os nomes e o invólucro dos parâmetros devem corresponder aos nomes e invólucros dos parâmetros do procedimento armazenado. |
Não |
| Nível de isolamento | Especifica o comportamento de bloqueio de transação para a fonte SQL. Os valores permitidos são: ReadCommitted, ReadUncommitted, RepeatableRead, Serializable, Snapshot. Se não for especificado, o nível de isolamento padrão do banco de dados será usado. Consulte este documento para obter mais detalhes. | Não |
| opções de partição | Especifica as opções de particionamento de dados usadas para carregar dados do SQL MI. Os valores permitidos são: None (padrão), PhysicalPartitionsOfTable e DynamicRange. Quando uma opção de partição está ativada (ou seja, não None), o grau de paralelismo para carregar simultaneamente dados do SQL MI é controlado pela configuração parallelCopies na atividade de cópia. |
Não |
| configurações de partição | Especifique o grupo de configurações para particionamento de dados. Aplique quando a opção de partição None não for. |
Não |
Em partitionSettings: |
||
| nomeDaColunaDePartição | 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á detetado automaticamente e usado como a coluna de partição.Aplique quando a opção de partição for DynamicRange. Se utilizar uma consulta para recuperar os dados de origem, inclua ?DfDynamicRangePartitionCondition na cláusula WHERE. Para obter um exemplo, consulte a seção Cópia paralela do banco de dados SQL. |
Não |
| partiçãoLimiteSuperior | O valor máximo da coluna de partição para divisão do intervalo de partições. Este valor é usado para determinar o passo da partição, e não para filtrar as linhas na tabela. Todas as linhas na tabela ou no resultado da consulta serão particionadas e copiadas. Se não for especificado, a atividade de cópia detetará automaticamente o valor. Aplique quando a opção de partição for DynamicRange. Para obter um exemplo, consulte a seção Cópia paralela do banco de dados SQL. |
Não |
| partiçãoLowerBound | O valor mínimo da coluna de partição para divisão do intervalo de partições. Este valor é usado para determinar o passo da partição, e não para filtrar as linhas na tabela. Todas as linhas na tabela ou no resultado da consulta serão particionadas e copiadas. Se não for especificado, a atividade de cópia detetará automaticamente o valor. Aplique quando a opção de partição for DynamicRange. Para obter um exemplo, consulte a seção Cópia paralela do banco de dados SQL. |
Não |
Tenha em atenção os seguintes pontos:
- Se sqlReaderQuery é especificado para SqlMISource, a atividade de cópia executará a consulta na Instância Gerenciada SQL como fonte para obter os dados. Você também pode especificar um procedimento armazenado especificando sqlReaderStoredProcedureName e storedProcedureParameters se o procedimento armazenado tiver parâmetros.
- Ao usar o procedimento armazenado na origem para recuperar dados, observe se o procedimento armazenado for projetado como retornando esquema diferente quando um valor de parâmetro diferente for passado, você poderá encontrar falha ou ver um resultado inesperado ao importar esquema da interface do usuário ou ao copiar dados para o banco de dados SQL com a criação automática de tabelas.
Exemplo: Usar 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 de procedimento armazenado
CREATE PROCEDURE CopyTestSrcStoredProcedureWithParameters
(
@stringData varchar(20),
@identifier int
)
AS
SET NOCOUNT ON;
BEGIN
select *
from dbo.UnitTestSrcTable
where dbo.UnitTestSrcTable.stringData != stringData
and dbo.UnitTestSrcTable.identifier != identifier
END
GO
Instância gerenciada SQL como um coletor
Gorjeta
Saiba mais sobre os comportamentos, configurações e práticas recomendadas de gravação com suporte em Práticas recomendadas para carregar dados na Instância Gerenciada SQL.
Para copiar dados para a Instância Gerida SQL, as seguintes propriedades são suportadas na seção de destino da atividade de cópia:
| Propriedade | Descrição | Obrigatório |
|---|---|---|
| tipo | A propriedade type do coletor de 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 de gravar dados na Instância Gerenciada SQL. É invocado apenas uma vez para cada execução de cópia. Você pode usar essa propriedade para limpar dados pré-carregados. | Não |
| opçãoTabela | Especifica se a tabela de destino deve ser criada automaticamente se não existir, com base no esquema de origem. A criação automática de tabelas não é suportada quando o coletor especifica o procedimento armazenado. Os valores permitidos são: none (padrão), autoCreate. |
Não |
| sqlWriterStoredProcedureName | O nome do procedimento armazenado que define como aplicar dados de origem em uma tabela de destino. Este procedimento armazenado é invocado por lote. Para operações que são executadas apenas uma vez e não têm nada a ver com dados de origem, por exemplo, excluir ou truncar, use a preCopyScript propriedade.Veja o exemplo de Invocar um procedimento armazenado a partir de um destino SQL. |
Não |
| procedimentoArmazenadoTabelaTipoNomeDoParâmetro | O nome do parâmetro do tipo de tabela especificado no procedimento armazenado. | Não |
| sqlWriterTableType | O nome do tipo de tabela a ser usado no procedimento armazenado. A atividade de cópia torna os dados que estão sendo movidos disponíveis em uma tabela temporária com esse tipo de tabela. O código de procedimento armazenado pode mesclar os dados que estão sendo copiados com os dados existentes. | Não |
| parâmetrosDeProcedimentoArmazenado | Parâmetros para o procedimento armazenado. Os valores permitidos são pares de nome e valor. Os nomes e o invólucro dos parâmetros devem corresponder aos nomes e invólucros dos parâmetros do procedimento armazenado. |
Não |
| writeBatchSize | Número de linhas a serem inseridas na tabela SQL por lote. Os valores permitidos são inteiros para o número de linhas. Por padrão, o serviço determina dinamicamente o tamanho de lote apropriado com base no tamanho da linha. |
Não |
| writeBatchTimeout | O tempo de espera para concluir a operação de inserção, upsert e procedimento armazenado antes de atingir o tempo limite. Os valores permitidos são para o período de tempo. Um exemplo é "00:30:00" por 30 minutos. Se nenhum valor for especificado, o tempo limite será padronizado como "00:30:00". |
Não |
| maxConcurrentConnections | O limite superior de conexões simultâneas estabelecidas para o armazenamento de dados durante a execução da atividade. Especifique um valor somente quando quiser limitar conexões simultâneas. | Não |
| WriteBehavior | Especifique o comportamento de gravação para a atividade de cópia para carregar dados no SQL MI do Azure. O valor permitido é Inserir e Upsert. Por padrão, o serviço usa inserção para carregar dados. |
Não |
| upsertSettings | Especifique o grupo de configurações para o comportamento de gravação. Aplique quando a opção WriteBehavior for Upsert. |
Não |
Em upsertSettings: |
||
| useTempDB | Especifique se deseja usar 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. valor é true. |
Não |
| interimSchemaName | Especifique o esquema provisório para criar uma tabela provisória se a tabela física for usada. Nota: o usuário precisa ter a permissão para criar e excluir tabela. Por padrão, a tabela temporária compartilhará o mesmo esquema da tabela de destino. Aplique quando a opção useTempDB for False. |
Não |
| chaves | Especifique os nomes das colunas para identificação de linha exclusiva. Uma única chave ou uma série de chaves podem ser usadas. Se não for especificado, a chave primária será usada. | Não |
Exemplo 1: Acrescentar dados
"activities":[
{
"name": "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 receptor SQL MI.
"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: Inserir ou atualizar 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",
"writeBehavior": "upsert",
"upsertSettings": {
"useTempDB": true,
"keys": [
"<column name>"
]
},
}
}
}
]
Cópia paralela a partir do SQL MI
O conector da Instância Gerenciada SQL do Azure 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 na fonte do SQL MI para carregar dados por partições. O grau paralelo é controlado pela configuração parallelCopies na atividade de cópia. Por exemplo, se você definir parallelCopies como quatro, o serviço gerará e executará simultaneamente quatro consultas com base na opção e nas configurações de partição especificadas, e cada consulta recuperará uma parte dos dados do seu SQL MI.
Sugere-se que habilite a cópia paralela com particionamento de dados, especialmente quando você carrega uma grande quantidade de dados do seu SQL MI. A seguir estão sugeridas configurações para diferentes cenários. Ao copiar dados para o armazenamento de dados baseado em arquivo, é recomendável gravar em uma pasta como vários arquivos (especifique apenas o nome da pasta), caso em que o desempenho é melhor do que gravar em um único arquivo.
| Cenário | Configurações sugeridas |
|---|---|
| Carga total a partir 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 deteta automaticamente as partições físicas e copia os dados por partições. Para verificar se a sua tabela tem partição física ou não, pode consultar esta consulta. |
| Carga completa a partir de uma tabela grande, sem partições físicas, mas com uma coluna de tipo inteiro ou datetime para particionamento de dados. |
Opções de partição: Partição de intervalo dinâmico. Coluna de partição (opcional): especifique a coluna usada para particionar dados. Se não for especificado, o índice ou a coluna de chave primária será usado. Limite superior da partição e limite inferior da partição (opcional): Especifique se deseja determinar o passo da partição. Isso não é para filtrar as linhas na tabela, todas as linhas na tabela serão particionadas e copiadas. Se não for especificado, a atividade de cópia detetará automaticamente os valores. Por exemplo, se a coluna de partição "ID" tiver valores que variam de 1 a 100 e você definir o limite inferior como 20 e o limite superior como 80, com cópia paralela como 4, o serviço recuperará dados por 4 partições - IDs no intervalo <=20, [21, 50], [51, 80] e >=81, respectivamente. |
| Carregue uma grande quantidade de dados usando uma consulta personalizada, sem partições físicas, mas com uma coluna do tipo inteiro ou de data ou data/hora para particionamento dos 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 passo da partição. Isso não é para filtrar as linhas na tabela, todas as linhas no resultado da consulta serão particionadas e copiadas. Se não for especificado, a atividade de cópia detetará automaticamente o valor. Por exemplo, se a coluna de partição "ID" tiver valores que variam de 1 a 100 e você definir o limite inferior como 20 e o limite superior como 80, com cópia paralela como 4, o serviço recuperará dados por 4 partições - IDs no intervalo <=20, [21, 50], [51, 80] e >=81, respectivamente. Aqui estão mais consultas de exemplo para diferentes cenários: 1. Consulte toda a tabela: SELECT * FROM <TableName> WHERE ?DfDynamicRangePartitionCondition2. Consulta de uma tabela com seleção de colunas e filtros adicionais na cláusula WHERE: SELECT <column_list> FROM <TableName> WHERE ?DfDynamicRangePartitionCondition AND <your_additional_where_clause>3. Consulta com subconsultas: SELECT <column_list> FROM (<your_sub_query>) AS T WHERE ?DfDynamicRangePartitionCondition AND <your_additional_where_clause>4. Consulta com partição em subconsulta: SELECT <column_list> FROM (SELECT <your_sub_query_column_list> FROM <TableName> WHERE ?DfDynamicRangePartitionCondition) AS T |
Práticas recomendadas para carregar dados com a opção de partição:
- Escolha uma coluna distinta como coluna de partição (como chave primária ou chave exclusiva) para evitar distorção de dados.
- Se a tabela tiver partição incorporada, use a opção de partição "Partições físicas da tabela" para obter um melhor desempenho.
- Se você usar o Tempo de Execução de Integração do Azure para copiar dados, poderá definir "Unidades de Integração de Dados (DIU)" (>4) maiores para utilizar mais recursos de computação. Verifique os cenários aplicáveis lá.
- "Grau de paralelismo de cópia controla os números de partição, estabelecer este número demasiado grande pode por vezes prejudicar o desempenho, recomenda-se definir este número como (DIU ou número de nós IR auto-hospedados) * (2 a 4)."
Exemplo: carga completa a partir de uma tabela grande com partições físicas
"source": {
"type": "SqlMISource",
"partitionOption": "PhysicalPartitionsOfTable"
}
Exemplo: consulta com partição de 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 partição física, você verá "HasPartition" como "sim" como a seguir.
Práticas recomendadas para carregar dados na Instância Gerenciada SQL
Ao copiar dados para a Instância Gerenciada SQL, você pode precisar de um comportamento de gravação diferente:
- Acrescentar: Meus dados de origem têm apenas novos registros.
- Upsert: Meus dados de origem têm inserções e atualizações.
- Substituir: Quero recarregar toda a tabela de dimensões de cada vez.
- Escrever com lógica personalizada: preciso de processamento extra antes da inserção final na tabela de destino.
Consulte as respetivas seções para saber como configurar e práticas recomendadas.
Acrescentar dados
O acrescentar dados é o comportamento padrão do conector de destino de Instância Gerenciada SQL. O serviço faz uma inserção em massa para gravar na sua tabela de forma eficiente. Você pode configurar a origem e o coletor de acordo com a atividade de cópia.
Inserir ou atualizar dados
A atividade de cópia já é capaz de carregar nativamente dados numa tabela temporária de base de dados e, em seguida, atualizar os dados na tabela de destino se a chave existir ou, caso contrário, inserir novos dados. Para saber mais sobre as configurações de upsert em atividades de cópia, consulte Instância gerenciada SQL como um coletor.
Substituir a tabela inteira
Você pode configurar a propriedade preCopyScript em um coletor de atividade de cópia. Nesse caso, para cada atividade de cópia executada, o serviço executa o script primeiro. Em seguida, ele executa a cópia para inserir os dados. Por exemplo, para substituir a tabela inteira pelos dados mais recentes, especifique um script para primeiro excluir todos os registros antes de carregar em massa os novos dados da fonte.
Gravar dados com lógica personalizada
As etapas para gravar dados com lógica personalizada são semelhantes às descritas na seção Upsert dados. Quando precisar aplicar processamento extra antes da inserção final dos dados de origem na tabela de destino, você poderá carregar em uma tabela de preparo e, em seguida, invocar a atividade de procedimento armazenado ou invocar um procedimento armazenado no coletor de atividade de cópia para aplicar dados.
Invocar um procedimento armazenado a partir de um coletor SQL
Ao copiar dados para a Instância Gerenciada do 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 tira partido dos parâmetros com valor de tabela.
Você pode usar um procedimento armazenado quando os mecanismos de cópia internos não atendem à finalidade. Um exemplo é quando você deseja aplicar processamento extra antes da inserção final dos dados de origem na tabela de destino. Alguns exemplos de processamento extra são quando você deseja mesclar colunas, procurar valores adicionais e inserir em mais de uma tabela.
O exemplo a seguir mostra como usar um procedimento armazenado para fazer um upsert em uma tabela no banco de dados do SQL Server. Suponha que os dados de entrada e a tabela de destino Marketing tenham três colunas: ProfileID, State e Category. Faça o upsert com base na coluna ProfileID e aplique-o apenas para uma categoria específica chamada "ProductA".
Em seu banco de dados, defina o tipo de tabela com o mesmo nome de sqlWriterTableType. O esquema do tipo de tabela é o mesmo que o esquema retornado pelos dados de entrada.
CREATE TYPE [dbo].[MarketingType] AS TABLE( [ProfileID] [varchar](256) NOT NULL, [State] [varchar](256) NOT NULL, [Category] [varchar](256) NOT NULL )Em seu banco de dados, defina o procedimento armazenado com o mesmo nome de sqlWriterStoredProcedureName. Ele processa dados de entrada da sua fonte especificada e integra na tabela de saída. O nome do parâmetro do tipo de tabela no procedimento armazenado é o mesmo que tableName definido no conjunto de dados.
CREATE PROCEDURE spOverwriteMarketing @Marketing [dbo].[MarketingType] READONLY, @category varchar(256) AS BEGIN MERGE [dbo].[Marketing] AS target USING @Marketing AS source ON (target.ProfileID = source.ProfileID and target.Category = @category) WHEN MATCHED THEN UPDATE SET State = source.State WHEN NOT MATCHED THEN INSERT (ProfileID, State, Category) VALUES (source.ProfileID, source.State, source.Category); ENDNo pipeline, defina a seção SQL MI sink na atividade de cópia da seguinte maneira:
"sink": { "type": "SqlMISink", "sqlWriterStoredProcedureName": "spOverwriteMarketing", "storedProcedureTableTypeParameterName": "Marketing", "sqlWriterTableType": "MarketingType", "storedProcedureParameters": { "category": { "value": "ProductA" } } }
Mapeando propriedades de fluxo de dados
Ao transformar dados em fluxo de dados de mapeamento, pode-se ler e gravar em tabelas da Instância Gerenciada SQL do Azure. Para obter mais informações, consulte a transformação de origem e a transformação de coletor no mapeamento de fluxos de dados.
Transformação da fonte
A tabela abaixo lista as propriedades suportadas pela origem da Instância Gerenciada SQL do Azure. Você pode editar essas propriedades na guia Opções de origem .
| Nome | Descrição | Obrigatório | Valores permitidos | Propriedade do script de fluxo de dados |
|---|---|---|---|---|
| Tabela | Se você selecionar Tabela como entrada, o fluxo de dados buscará todos os dados da tabela especificada no conjunto de dados. | Não | - | - |
| Query | Se você selecionar Consulta como entrada, especifique uma consulta SQL para buscar dados da origem, que substituirá qualquer tabela especificada no conjunto de dados. Usar consultas é uma ótima maneira de reduzir linhas para testes ou pesquisas. A cláusula Order By não é suportada, mas você pode definir uma instrução SELECT FROM completa. Você também pode usar funções de tabela definidas pelo usuário. select * from udfGetData() é um UDF em SQL que retorna uma tabela que você pode usar no fluxo de dados. Exemplo de consulta: Select * from MyTable where customerId > 1000 and customerId < 2000 |
Não | String | consulta |
| Tamanho do lote | Especifique um tamanho de lote para fragmentar dados grandes em leituras. | Não | Número inteiro | batchSize |
| Nível de isolamento | Escolha um dos seguintes níveis de isolamento: - Ler Comprometido - Ler Não confirmado (padrão) - Leitura repetível - Serializável - Nenhum (ignorar o nível de isolamento) |
Não | READ_COMMITTED READ_UNCOMMITTED REPEATABLE_READ (leitura repetível) SERIALIZÁVEL NENHUM |
Nível de isolamento |
| Ativar extração incremental | Use esta opção para indicar ao ADF que processe apenas as linhas que foram alteradas desde a última execução do pipeline. | Não | - | - |
| Coluna incremental | Ao usar o recurso de extração incremental, deve-se escolher a coluna de data/hora ou numérica que se deseja usar como marca de referência na tabela de origem. | Não | - | - |
| Habilitar captura nativa de dados de alteração (visualização) | Use esta opção para indicar ao ADF que processe apenas os dados delta capturados pela tecnologia de captura de dados de alteração do SQL desde a última vez que o pipeline foi executado. Com essa opção, os dados delta, incluindo inserção de linha, atualização e exclusão, serão carregados automaticamente sem a necessidade de qualquer coluna incremental. Você precisa habilitar a captura de dados de alteração no SQL MI do Azure antes de usar essa opção no ADF. Para obter mais informações sobre esta opção no ADF, consulte captura de dados de alterações nativa. | Não | - | - |
| Comece a ler desde o início | Definir essa opção com extração incremental instruirá o ADF a ler todas as linhas na primeira execução de um pipeline com a extração incremental ativada. | Não | - | - |
Gorjeta
A expressão de tabela comum (CTE) em SQL não é suportada no modo de consulta de fluxo de dados de mapeamento, porque para usar este modo, é necessário que as consultas possam ser utilizadas na cláusula SQL FROM, mas as CTEs não são compatíveis com isso. Para usar CTEs, você precisa criar um procedimento armazenado usando a seguinte consulta:
CREATE PROC CTESP @query nvarchar(max)
AS
BEGIN
EXECUTE sp_executesql @query;
END
Em seguida, use o
Exemplo de script de origem da Instância Gerenciada SQL do Azure
Quando você usa a Instância Gerenciada 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 do lavatório
A tabela abaixo lista as propriedades suportadas pelo coletor de Instância Gerenciada SQL do Azure. Você pode editar essas propriedades na guia Opções do coletor .
| Nome | Descrição | Obrigatório | Valores permitidos | Propriedade do script de fluxo de dados |
|---|---|---|---|---|
| Método de atualização | Especifique quais operações são permitidas no destino do banco de dados. O padrão é permitir apenas inserções. Para atualizar, inserir ou excluir linhas, é necessária uma transformação Alter de linha para marcar linhas para essas ações. |
Sim |
true ou false |
apagável inserível atualizável Passível de inserção e atualização |
| Colunas-chave | Para atualizações, inserções/atualizações e eliminações, as colunas chave devem ser definidas para determinar qual linha alterar. O nome da coluna que o utilizador escolher como chave será usado como parte das operações subsequentes de atualização, upsert e eliminação. Portanto, você deve escolher uma coluna que existe no mapeamento de coletor. |
Não | Matriz | chaves |
| Ignorar colunas chave | Se desejar não escrever o valor na coluna-chave, selecione "Ignorar a escrita nas colunas-chave". | Não |
true ou false |
skipKeyWrites |
| Ação da tabela | Determina se todas as linhas da tabela de destino devem ser recriadas ou removidas antes de serem escritas. - Nenhuma: Nenhuma ação será feita à tabela. - Recriar: A tabela será eliminada e recriada. Necessário apenas ao criar uma nova tabela dinamicamente. - Truncate: Todas as linhas da tabela de destino serão removidas. |
Não |
true ou false |
recriar truncar |
| Tamanho do lote | Especifique quantas linhas estão sendo escritas em cada lote. Lotes maiores melhoram a compactação e a otimização da memória, mas correm o risco de exceções de falta de memória ao armazenar dados em cache. | Não | Número inteiro | batchSize |
| Scripts pré e pós SQL | Especifique scripts SQL de várias linhas que serão executados antes (pré-processamento) e depois que os dados (pós-processamento) forem gravados no banco de dados do coletor. | Não | String | pré-SQLs postSQLs |
Gorjeta
- Recomenda-se dividir scripts de lote único que contenham vários comandos em lotes distintos.
- Somente instruções DDL (Data Definition Language) e DML (Data Manipulation Language) que retornam uma contagem de atualização simples podem ser executadas como parte de um lote. Saiba mais em Executando operações em lote
Exemplo de script de coletor de instância gerenciada SQL do Azure
Quando você usa a Instância Gerenciada SQL do Azure 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) ~> SQLMISink
Propriedades da atividade de consulta
Para saber detalhes sobre as propriedades, verifique Atividade de pesquisa.
Propriedades de atividade GetMetadata
Para saber detalhes sobre as propriedades, verifique a atividade GetMetadata
Mapeamento de tipo de dados para instância gerenciada SQL
Quando os dados são copiados de e para a Instância Gerenciada SQL usando a atividade de cópia, os mapeamentos a seguir são usados de tipos de dados de Instância Gerenciada SQL para tipos de dados provisórios usados internamente no serviço. Para saber como a atividade de cópia é mapeada do esquema de origem e do tipo de dados para o coletor, consulte Mapeamentos de esquema e tipo de dados.
| Tipo de dados da Instância Gerenciada SQL | Tipo de dados de serviço provisório |
|---|---|
| bigint | Int64 |
| binário | Byte[] |
| bit | booleano |
| char | Cadeia de caracteres, Array de caracteres |
| data | DateTime |
| Data e Hora | DateTime |
| datetime2 | DateTime |
| Datetimeoffset | DateTimeOffset |
| Decimal | Decimal |
| Atributo FILESTREAM (varbinary(max)) | Byte[] |
| Flutuante | Duplo |
| imagem | Byte[] |
| número inteiro | Int32 |
| dinheiro | Decimal |
| Nchar | Cadeia de caracteres, Array de caracteres |
| ntexto | Cadeia de caracteres, Array de caracteres |
| numérico | Decimal |
| nvarchar | Cadeia de caracteres, Array de caracteres |
| real | Única |
| versão de linha | Byte[] |
| smalldatetime | DateTime |
| smallint | Int16 |
| pequena quantia | Decimal |
| sql_variant | Objeto |
| enviar SMS | Cadeia de caracteres, Array de caracteres |
| tempo | TimeSpan |
| carimbo de data/hora | Byte[] |
| tinyint | Int16 |
| identificador único | GUID |
| Varbinary | Byte[] |
| varchar | Cadeia de caracteres, Array de caracteres |
| xml | String |
Nota
Para tipos de dados mapeados para o tipo provisório decimal, atualmente a atividade Copiar suporta precisão de até 28. Se você tiver dados que exijam precisão maior que 28, considere converter em uma cadeia de caracteres em uma consulta SQL.
Utilização de Always Encrypted
Quando você copia dados de/para a instância gerenciada SQL com Always Encrypted, siga as etapas abaixo:
Armazene a Chave Mestra de Coluna (CMK) em um Cofre de Chaves do Azure. Saiba mais sobre como configurar o Always Encrypted usando o Azure Key Vault
Certifique-se de ter acesso garantido ao cofre de chaves onde a Chave Mestra de Coluna (CMK) está armazenada. Consulte este artigo para obter as permissões necessárias.
Crie um serviço vinculado para se conectar ao seu banco de dados SQL e habilite a função 'Always Encrypted' usando a identidade gerida ou o principal de serviço.
Nota
A Instância Gerida de SQL Always Encrypted oferece suporte aos cenários abaixo:
- Os armazenamentos de dados de origem ou coletor estão usando identidade gerenciada ou entidade de serviço como tipo de autenticação de provedor de chave.
- Os armazenamentos de dados de fonte e destino estão usando identidade gerida como tipo de autenticação do fornecedor de chaves.
- Os armazenamentos de dados de fonte e destino estão usando o mesmo serviço principal como tipo de autenticação do provedor de chaves.
Nota
Atualmente, a Instância Gerenciada SQL Always Encrypted só tem suporte para transformação de origem no mapeamento de fluxos de dados.
Captura nativa de dados de alteração
O Azure Data Factory pode dar suporte a recursos nativos de captura de dados de alteração para SQL Server, Banco de Dados SQL do Azure e SQL MI do Azure. Os dados alterados, incluindo inserção de linha, atualização e exclusão em repositórios SQL, podem ser detetados e extraídos automaticamente pelo fluxo de dados de mapeamento do ADF. Com a experiência sem código no mapeamento de fluxo de dados, os usuários podem facilmente obter o cenário de replicação de dados de repositórios SQL anexando um banco de dados como armazenamento de destino. Além disso, os utilizadores podem também compor qualquer lógica de transformação de dados para conseguir um cenário de ETL incremental utilizando repositórios SQL.
Certifique-se de manter o pipeline e o nome da atividade inalterados, para que o ponto de verificação possa ser registado pelo ADF e assim você obtenha automaticamente os dados alterados da última execução. Se alterar o nome do pipeline ou o nome da atividade, o ponto de verificação será redefinido, o que o obriga a começar do início ou a aplicar as alterações a partir de agora na próxima execução do pipeline. Caso deseje alterar o nome do pipeline ou o nome da atividade, mas queira manter o ponto de verificação para obter dados modificados automaticamente da última execução, utilize sua própria chave de ponto de verificação na atividade de fluxo de dados para alcançar isso.
Quando você depura o pipeline, esse recurso funciona da mesma forma. Lembre-se de que o ponto de verificação será redefinido quando você atualizar o navegador durante a execução de depuração. Depois de estar satisfeito com o resultado da execução de depuração do pipeline, pode publicar e acionar o pipeline. No momento em que você aciona pela primeira vez seu pipeline publicado, ele é reiniciado automaticamente desde o início ou recebe alterações a partir de agora.
Na seção de monitoramento, você sempre tem a chance de executar novamente um pipeline. Quando você está fazendo isso, os dados alterados são sempre capturados do ponto de verificação anterior da execução do pipeline selecionado.
Exemplo 1:
Quando você encadeia diretamente uma transformação de origem referenciada ao conjunto de dados habilitado para SQL CDC com uma transformação de coletor referenciada a um banco de dados em um fluxo de dados de mapeamento, as alterações ocorridas na origem SQL serão aplicadas automaticamente ao banco de dados de destino, para que você obtenha facilmente o cenário de replicação de dados entre bancos de dados. Você pode usar o método update na transformação do coletor para selecionar se deseja permitir inserir, permitir atualização ou permitir exclusão no banco de dados de destino. O script de exemplo no mapeamento de fluxo de dados é como abaixo.
source(output(
id as integer,
name as string
),
allowSchemaDrift: true,
validateSchema: false,
enableNativeCdc: true,
netChanges: true,
skipInitialLoad: false,
isolationLevel: 'READ_UNCOMMITTED',
format: 'table') ~> source1
source1 sink(allowSchemaDrift: true,
validateSchema: false,
deletable:true,
insertable:true,
updateable:true,
upsertable:true,
keys:['id'],
format: 'table',
skipDuplicateMapInputs: true,
skipDuplicateMapOutputs: true,
errorHandlingOption: 'stopOnFirstError') ~> sink1
Exemplo 2:
Se quiser habilitar o cenário de ETL em vez da replicação de dados entre bancos de dados via SQL CDC, você pode usar expressões no mapeamento de fluxo de dados, incluindo isInsert(1), isUpdate(1) e isDelete(1) para diferenciar as linhas com diferentes tipos de operação. A seguir está um dos scripts de exemplo para mapear o fluxo de dados na derivação de uma coluna com o valor: 1 para indicar linhas inseridas, 2 para indicar linhas atualizadas e 3 para indicar linhas excluídas para transformações downstream para processar os dados delta.
source(output(
id as integer,
name as string
),
allowSchemaDrift: true,
validateSchema: false,
enableNativeCdc: true,
netChanges: true,
skipInitialLoad: false,
isolationLevel: 'READ_UNCOMMITTED',
format: 'table') ~> source1
source1 derive(operationType = iif(isInsert(1), 1, iif(isUpdate(1), 2, 3))) ~> derivedColumn1
derivedColumn1 sink(allowSchemaDrift: true,
validateSchema: false,
skipDuplicateMapInputs: true,
skipDuplicateMapOutputs: true) ~> sink1
Limitação conhecida:
- Somente as alterações líquidas do SQL CDC serão carregadas pelo ADF via cdc.fn_cdc_get_net_changes_.
Atualizar a versão da Instância Gerenciada SQL do Azure
Para atualizar a versão da Instância Gerenciada SQL do Azure, na página Editar serviço vinculado, selecione Recomendado em Versão e configure o serviço vinculado consultando as 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 SQL do Azure usando a versão recomendada e a versão herdada.
| Versão recomendada | Versão antiga |
|---|---|
Suporte TLS 1.3 via encrypt como strict. |
TLS 1.3 não é suportado. |
Conteúdos relacionados
Para obter uma lista de armazenamentos de dados suportados como fontes e destinos pela atividade de cópia, consulte Armazenamentos de dados suportados.