Begränsningar för SQL Server-anslutningsappen

På den här sidan visas begränsningar och överväganden för SQL Server-inmatning med Databricks Lakeflow Connect.

Allmänna begränsningar för databasanslutningar

Begränsningarna i det här avsnittet gäller för alla databasanslutningar i Lakeflow Connect. Fortsätt läsa för anslutningsspecifika begränsningar.

När du kör en schemalagd pipeline utlöses inte aviseringar omedelbart. I stället utlöses de när nästa uppdatering körs.
När en källtabell tas bort tas inte måltabellen bort automatiskt. Du måste ta bort destinationstabellen manuellt. Det här beteendet överensstämmer inte med beteendet hos Lakeflow Spark Deklarativa Pipeline.
Mellanlagringskatalogen får inte vara en extern katalog.
Under källunderhållsperioder kanske Databricks inte kan komma åt dina data.
Om ett källtabellnamn står i konflikt med ett befintligt måltabellnamn misslyckas pipelineuppdateringen.
Stöd för pipeline med flera destinationer är endast tillgängligt via API.
Du kan välja att byta namn på en tabell som du importerar. Om du byter namn på en tabell i din pipeline, blir det en API-endast pipeline, och du kan inte längre redigera pipelinen i UI:t.
Om du väljer en kolumn efter att en pipeline redan har startat, fyller inte kontakten automatiskt i data för den nya kolumnen. För att hämta historiska data, kör manuellt en fullständig uppdatering av tabellen.
Databricks kan inte mata in två eller flera tabeller med samma namn i samma pipeline, även om de kommer från olika källscheman.
Källsystemet förutsätter att markörkolumnerna ökar monotont.

Hanterade inmatningspipelines stöds inte för FedRAMP High- eller FedRAMP Moderate-arbetsytor.

Anslutningsappen matar in rådata utan transformeringar. Använd nedströms Lakeflow Spark Deklarativa Pipelines för transformationer.

Stödet är begränsat till primära SQL Server-instanser. Det beror på att ändringsspårning och ändringsdatainsamling inte stöds på läsrepliker eller sekundära instanser.

Anslutningsappen stöder grundläggande autentisering (användarnamn och lösenord). För Azure SQL Database och Azure SQL Managed Instance stöder anslutningsappen även Microsoft Entra ID-autentisering.
Klusterkonfigurationer för redundanskluster med flera undernät måste ange en enda framåtriktad IP-adress.

Anslutningsappen stöder Azure SQL Database-, Azure SQL Managed Instance- och Amazon RDS SQL-databaser. Detta inkluderar SQL Server som körs på virtuella Azure-datorer (VM) och Amazon EC2. Anslutningsappen har också stöd för SQL Server lokalt med hjälp av Azure ExpressRoute- och AWS Direct Connect-nätverk. Mer information om anslutningar mellan moln finns i Nätverksanslutning.
Så här använder du Microsofts insamling av ändringsdata (CDC):
- Du måste ha SQL Server 2012 Service Pack 1 (SP1) kumulativt uppdateringspaket 3 (CU3) eller senare.
  
  Den här uppdateringen introducerade __$command_id kolumnen. Utan den här kolumnen kan inmatningsgatewayen inte på ett tillförlitligt sätt skilja mellan typer av dataändringsåtgärder (till exempel UPDATE åtgärder som manifesteras som DELETE-INSERT par med identiska __$seqval värden). Detta kan orsaka datainkonsekvenser.
- För tidigare versioner än SQL Server 2016 krävs även Enterprise Edition.
Om du vill använda Microsofts ändringsspårning måste du ha SQL Server 2012 eller senare.

Varje inmatningspipeline måste associeras med exakt en inmatningsgateway. Gatewayer kan inte delas mellan pipelines.
Även om inmatningspipelinen körs på serverlös beräkning måste inmatningsgatewayen köras på klassisk beräkning.

Anslutningsappen hanterar automatiskt nya och borttagna kolumner om du inte avregistrerar dig.

När en ny kolumn visas i källan matar Databricks automatiskt in den vid nästa körning av pipelinen. Du kan dock välja bort detta.
När en kolumn tas bort från källan tar Databricks inte bort den automatiskt. I stället använder anslutningen en tabellegenskap för att ange den borttagna kolumnen till inactive i målplatsen. Om en annan kolumn senare visas som har ett motstridigt namn med inactive kolumnen misslyckas pipelinen. I det här fallet kan du köra en fullständig uppdatering av tabellen eller manuellt släppa den inaktiva kolumnen.

Detta gäller för nya och borttagna tabeller i ett schema om du matar in hela schemat.

Slutligen kan anslutningsappen hantera kolumnbyten, även om det kräver en fullständig uppdatering av tabellen.

Ytterligare schemaändringar (till exempel ändringar av datatyp) kräver också en fullständig uppdatering av måltabellerna.

Mellanlagringskatalogen får inte vara en utländsk katalog.

Databricks rekommenderar att du matar in 250 eller färre tabeller per pipeline. Det finns dock ingen gräns för hur många rader eller kolumner som stöds i dessa objekt.
Databricks kan inte mata in två tabeller vars namn endast skiljer sig åt om (till exempel MyTable och MYTABLE) använder en pipeline. För att stödja sådana fall skapar du två pipelinepar för gatewayinmatning som publicerar till målscheman.
Namnen source_catalog, source_schemaoch source_table är skiftlägeskänsliga. Om källdatabaskatalogen till exempel anges som Marketing i sys.databaseskan du inte ange den som marketing i ingestion_definition.
Även om du kan mata in från flera källkataloger eller scheman i en pipeline kan du inte mata in två tabeller med samma namn. Du kan till exempel inte mata in både schema1.Marketing och schema2.Marketing i samma pipeline.
Flera tabell- eller schemaspecifikationer kan inkluderas i objects fältet i ingestion_definition. Källtabellnamnen i olika källscheman kan dock inte överlappa varandra. Detta resulterar i inmatningspipelinefel.

Var den här sidan till hjälp?