Limitações do conector do SQL Server

info

Visualização

O conector do Microsoft SQL Server está em Public Preview.

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

Limitações gerais do conector de banco

As limitações desta seção se aplicam a todos os conectores de banco de dados em LakeFlow Connect.

Quando o senhor executa um pipeline agendado, o alerta não é acionado 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 da DLT.
Durante os períodos de manutenção da fonte, a 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 de vários destinos é somente de API.
Opcionalmente, você pode renomear uma tabela que você ingere. Se o senhor renomear uma tabela no pipeline, ela se tornará um pipeline somente de API e não será mais possível editar o pipeline na interface do usuário.
Se o senhor selecionar uma coluna depois que um pipeline já tiver começado, o conector não preencherá automaticamente os dados da nova coluna. Para ingerir dados históricos, o senhor deve executar manualmente um refresh completo na tabela.
O pipeline de ingestão gerenciar não é compatível com o seguinte:
- espaço de trabalho em AWS GovCloud regiões
- espaço de trabalho em Azure GovCloud regiões
- Espaço de trabalho em conformidade com o FedRAMP
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.

As limitações desta seção são específicas do conector do SQL Server.

O conector só oferece suporte à autenticação de nome de usuário e senha.
As configurações de clustering de failover de várias sub-redes devem fornecer um único endereço IP de encaminhamento.

O conector é compatível com os bancos de dados SQL do Azure SQL e do Amazon RDS. Isso inclui o SQL Server em execução nas máquinas virtuais (VMs) do Azure e no Amazon EC2. O conector também oferece suporte ao SQL Server no local usando o Azure ExpressRoute e a rede AWS Direct Connect.
Para usar o site Microsoft captura de dados de alterações (CDC) (CDC):
- O senhor deve ter o SQL Server 2012 serviço pack 1 (SP1) cumulative update pacote 3 (CU3) ou superior.
  
  Essa atualização introduziu a coluna __$command_id. Sem essa coluna, o gateway de ingestão não pode distinguir de forma confiável os tipos de operações de modificação de dados (por exemplo, UPDATE operações que se manifestam como pares DELETE-INSERT com valores __$seqval idênticos). Isso pode causar inconsistências nos dados.
- Para versões anteriores ao SQL Server 2016, o Enterprise Edition também é necessário.
Para usar o Microsoft change acompanhamento, o senhor deve ter o SQL Server 2012 ou o acima.

Cada pipeline de ingestão deve estar associado a exatamente um gateway de ingestão.
Embora a ingestão pipeline seja executada em serverless compute, o gateway de ingestão deve ser executado no clássico compute.

O conector processa automaticamente colunas novas e excluídas, a menos que você opte por não participar.

Quando uma nova coluna aparece na fonte, o Databricks a ingere automaticamente na próxima execução do pipeline. No entanto, você pode optar por não participar disso.
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 outra coluna aparecer posteriormente com um nome conflitante com a coluna inactive, o pipeline falhará. Nesse caso, o senhor pode executar um refresh completo da tabela ou eliminar manualmente a coluna inativa.

Isso vale para tabelas novas e excluídas em um esquema se você ingerir todo o esquema.

Por fim, o conector pode lidar com renomeações de colunas, embora isso exija um refresh completo da tabela.

Alterações adicionais no esquema (por exemplo, alterações no tipo de dados) também exigem um refresh completo das tabelas de destino.

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

A Databricks recomenda a ingestão de 250 ou menos 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 esses casos, crie dois pares gateway-ingestion pipeline que publiquem 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 em sys.databases, você não poderá especificá-lo como marketing no ingestion_definition.
Embora o senhor possa fazer a ingestão de vários catálogos ou esquemas de origem em um pipeline, não é possível fazer a ingestão de duas tabelas com o mesmo nome. Por exemplo, o senhor não pode ingerir tanto schema1.Marketing quanto 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 das tabelas de origem em diferentes esquemas de origem não podem se sobrepor. Isso resulta em falha no pipeline de ingestão.