Begränsningar och överväganden

Du bör vara medveten om följande begränsningar och överväganden när du använder en källa från Microsoft SQL Server (loggbaserad):

Begränsningar och överväganden för alla datauppgifter

• Microsoft SQL Server Replication Publisher-definitionerna för databasen som användes i uppgiften tas inte bort om du tar bort uppgiften. En Microsoft SQL Server-systemadministratör måste ta bort dessa definitioner från Microsoft SQL Server.
• Landing av Glesa tabeller stöds i läget "Fullständig inläsning" landing.
• Landing data från indexerade vyer stöds inte.
• TRUNCATE-händelser registreras inte.

• Landing av beräknade kolumner stöds endast i landing-uppgifter med fullständig laddning. Under CDC kommer INSERT:er till beräknade kolumner att visas som NULL på målet och UPDATE:er kommer att ignoreras.

• Partitionsväxling i Microsoft SQL Server stöds inte.
• När du använder verktygen WRITETEXT och UPDATETEXT, kommer händelser som tillämpas på källdatabasen inte att registreras.

• Följande DML-mönster stöds inte:

  select <*> into <new_table> from <existing_table>

• Kryptering på kolumnnivå stöds inte.
• Följande begränsningar gäller vid åtkomst till de säkerhetskopierade transaktionsloggarna:
  • Krypterade säkerhetskopior stöds inte.
  • Säkerhetskopieringar som lagras på en URL eller på Windows Azure stöds inte.
• Microsoft SQL Server-säkerhetskopiering till flera diskar (dvs. MIRROR TO DISK) stöds inte.
• När du infogar ett värde i SQL Servers rumsliga datatyper (GEOGRAPHY och GEOMETRY), kan du antingen ignorera egenskapen SRID (Spatial Reference System Identifier) – vilket innebär att förvalt SRID kommer att användas (0 för GEOMETRY och 4326 för GEOGRAPHY), eller ange ett annat nummer. När du använder landing tabeller med rumsliga datatyper kommer det SRID som användaren infogade att ersättas med förvalt SRID.
• Columnstore-index stöds inte.
• Minnesoptimerade tabeller (som använder In-Memory OLTP) stöds inte.
• Tidstabeller stöds inte
• Fördröjd hållbarhet stöds inte
• Spårning av tabelländringar stöds inte
• Maskerade data kommer att skapas i målet utan maskering.
• OpenLDAP stöds inte

• Landing direkt från en sekundär Microsoft SQL Server-databas stöds inte. Därför måste Microsoft SQL Server connector konfigureras för att ansluta till den primära databasen eller AlwaysOn Listener.

• Landing från databaser som är konfigurerade för att använda ADR (Accelerated Database Recovery) stöds inte.

• Landing en tabell eller ett schema med en apostrof (') i namnet stöds inte.

• Ändringar som tillämpas på databasen med hjälp av DACPAC kommer inte att registreras.

• CDC stöds inte från tabeller som har både komprimerade och okomprimerade partitioner.

• Systemtabeller och -vyer stöds inte.

Begränsningar och överväganden för replikering och mellanlagringsuppgifter

• Att byta namn på tabeller med sp_rename stöds inte (t.ex. sp_rename 'Sales.SalesRegion', 'SalesReg;)
• Att byta namn på kolumner med sp_rename stöds inte (t.ex. sp_rename 'Sales.Sales.Region', 'RegID', 'COLUMN';)

• Följande begränsningar gäller vid åtkomst till de säkerhetskopierade transaktionsloggarna på filnivå:

  • De säkerhetskopierade transaktionsloggarna måste finnas i en delad mapp med lämpliga behörigheter och åtkomsträttigheter.
  • Aktiva transaktionsloggar nås via Microsoft SQL Server API (och inte på filnivå).
  • Qlik Talend Data Integration och Microsoft SQL Server-datorerna måste finnas på samma domän.
  • Transparent Data Encryption (TDE) stöds inte. Observera att när du öppnar de säkerhetskopierade transaktionsloggarna med SQL Servers inbyggda funktionalitet (dvs. inte använder filåtkomst), stöds TDE-kryptering.
  • Unix-plattformar stöds inte.
  • Läsning av säkerhetskopieringsloggar från flera ränder stöds inte.
• Replikering av datatyperna GEOGRAPHY och GEOMETRY stöds endast i begränsat LOB-läge.
• Om din databas inte har konfigurerats för MS-REPLICATION eller MS-CDC, kan du fortfarande registrera tabeller som inte har en primärnyckel, men tänk på att i en sådan konfiguration kommer endast INSERT/DELETE DML-händelser att registreras. UPDATE-händelser kommer att ignoreras.

• Det finns inget stöd för att samla in DDL- och DML-satser i en enda transaktion.

• Uppdateringar av en primärnyckel/ett unikt index som påverkar flera rader kan orsaka konflikter när ändringarna tillämpas på målet. Detta kan till exempel inträffa om UPDATE-åtgärderna tillämpas på målet som INSERT/DELETE-åtgärder i stället för en enda UPDATE-åtgärd. I ett sådant scenario (där uppdateringar av en primärnyckel/ett unikt index påverkar flera rader) stöds inte arbete i läget Batch Optimized Apply Change Processing eftersom det kan leda till att tabellen ignoreras. Arbete i läget Transactional Apply Change Processing kan dock leda till överträdelser av begränsningar.

  Om detta inträffar måste du antingen läsa in den relevanta tabellen igen eller leta upp de problematiska posterna i Tillämpa undantagkontrolltabellen och redigera dem manuellt i måldatabasen. Se även: Change processing tuning.

Säkerhetsfunktioner i Microsoft SQL Server som inte stöds

Tabeller som använder följande säkerhetsfunktioner i Microsoft SQL Server stöds inte:

• Alltid krypterat
• Row-Level Security

Datatyper som inte stöds

Följande datatyper stöds inte:

• CURSOR
• SQL_VARIANT
• TABLE