Limitações do conector do SQL Server

Esta página lista limitações e considerações para a ingestão do SQL Server usando o Databricks Lakeflow Connect.

Limitações gerais do conector do banco de dados

As limitações nesta seção se aplicam a todos os conectores de banco de dados no Lakeflow Connect. Continue lendo para ver as limitações específicas do conector.

• Quando você executa um pipeline agendado, os alertas não são acionados imediatamente. Em vez disso, eles são acionados quando a próxima atualização é executada.
• Quando uma tabela de origem é excluída, a tabela de destino não é excluída automaticamente. Você deve excluir a tabela de destino manualmente. Esse comportamento não é consistente com o comportamento do Lakeflow Spark Declarative Pipelines.
• O catálogo de preparo não pode ser um catálogo estrangeiro.
• Durante os períodos de manutenção de origem, o Databricks pode não conseguir acessar seus dados.
• Se um nome de tabela de origem entrar em conflito com um nome de tabela de destino existente, a atualização do pipeline falhará.
• O suporte a pipeline para múltiplos destinos é somente através da API.
• Opcionalmente, você pode renomear uma tabela ingerida. Se você renomear uma tabela em seu pipeline, ela se tornará um pipeline somente de API e você não poderá mais editar o pipeline na interface do usuário.
• Se você selecionar uma coluna depois que um pipeline já tiver iniciado, o conector não preencherá automaticamente os dados da nova coluna. Para ingerir dados históricos, execute manualmente uma atualização completa na tabela.
• O Databricks não pode ingerir duas ou mais tabelas com o mesmo nome no mesmo pipeline, mesmo que elas venham de esquemas de origem diferentes.
• O sistema de origem assume que as colunas do cursor estão aumentando monotonicamente.

• Pipelines de ingestão geridas não são suportadas para espaços de trabalho FedRAMP High ou FedRAMP Moderate.

• O conector ingere dados brutos sem transformações. Use os pipelines declarativos de Lakeflow Spark a jusante para transformações.

• O suporte é limitado às instâncias primárias do SQL Server. Isso ocorre porque o controle de alterações e a captura de dados de alterações não são suportados em réplicas de leitura ou instâncias secundárias.

Autenticação

• O conector suporta autenticação básica (nome de utilizador e palavra-passe). Para Base de Dados SQL do Azure e Azure SQL Managed Instance, o conector também suporta autenticação Microsoft Entra ID.
• As configurações de cluster de failover de várias sub-redes devem fornecer um único endereço IP voltado para frente.

Variações do banco de dados

• O conector oferece suporte ao Banco de Dados SQL do Azure, à Instância Gerenciada SQL do Azure e aos bancos de dados SQL do Amazon RDS. Isso inclui o SQL Server em execução em máquinas virtuais (VMs) do Azure e o Amazon EC2. O conector também oferece suporte ao SQL Server local usando a rede Azure ExpressRoute e AWS Direct Connect. Para detalhes sobre conectividade entre cloud, veja Conectividade de rede.

• Para usar a captura de alterações de dados da Microsoft (CDC):

  • Você deve ter o SQL Server 2012 service pack 1 (SP1) pacote de atualização cumulativa 3 (CU3) ou superior.

    Esta atualização introduziu a __$command_id coluna. Sem esta coluna, o gateway de ingestão não pode distinguir de forma confiável entre os tipos de operação de modificação de dados (por exemplo, operações UPDATE que se manifestam como pares DELETE-INSERT com __$seqval valores idênticos). Isso pode causar inconsistências de dados.

  • Para versões anteriores ao SQL Server 2016, o Enterprise Edition também é necessário.

• Para usar o controle de alterações da Microsoft, você deve ter o SQL Server 2012 ou superior.

Tubulações

• Cada pipeline de entrada deve estar associado a exatamente um gateway de entrada. Os gateways não podem ser partilhados entre pipelines.
• Embora o pipeline de ingestão seja executado em computação sem servidor, o gateway de ingestão deve ser executado em computação clássica.

Evolução do esquema

O conector lida automaticamente com colunas novas e excluídas, a menos que você desative.

• Quando uma nova coluna aparece na origem, o Databricks ingere-a automaticamente na próxima execução do pipeline. No entanto, você pode optar por não participar.
• Quando uma coluna é excluída da fonte, o Databricks não a exclui automaticamente. Em vez disso, o conector usa uma propriedade de tabela para definir a coluna excluída como inactive no destino. Se aparecer mais tarde outra coluna com um nome conflitante com a inactive coluna, o pipeline falhará. Nesse caso, você pode executar uma atualização completa da tabela ou soltar manualmente a coluna inativa.

Isso é verdadeiro para tabelas novas e excluídas dentro de um esquema se você ingerir o esquema inteiro.

Finalmente, o conector pode lidar com renomeações de coluna, embora isso exija uma atualização completa da tabela.

Alterações adicionais de esquema (por exemplo, alterações de tipo de dados) também exigem uma atualização completa das tabelas de destino.

Preparação

O catálogo de preparação não pode ser um catálogo estrangeiro.

Tabelas

• A Databricks recomenda a ingestão de no máximo 250 tabelas por pipeline. No entanto, não há limite para o número de linhas ou colunas suportadas nesses objetos.
• O Databricks não pode ingerir duas tabelas cujos nomes diferem apenas no caso (por exemplo, MyTable e MYTABLE) usando um pipeline. Para dar suporte a tais casos, crie dois pares de pipelines de ingestão associadas a gateways que publicam em esquemas de destino.
• Os nomes source_catalog, source_schema e source_table diferenciam maiúsculas de minúsculas. Por exemplo, se o catálogo do banco de dados de origem for especificado como Marketing no sys.databases, você não poderá especificá-lo como marketing no ingestion_definition.
• Embora seja possível ingerir a partir de vários catálogos ou esquemas de origem em um pipeline, não é possível ingerir duas tabelas com o mesmo nome. Por exemplo, você não pode ingerir ambos schema1.Marketing e schema2.Marketing no mesmo pipeline.
• Várias especificações de tabela ou esquema podem ser incluídas no campo objects do ingestion_definition. No entanto, os nomes da tabela de origem em esquemas de origem diferentes não podem se sobrepor. Isso resulta em falha no pipeline de ingestão.