Inställningar för molnlagringsmål

Du kan ändra standardinställningen för mellanlagring i datasjö efter dina behov.

Allmänt

Uppdateringsmetod

Du kan mellanlagra data i två olika lägen. Det går inte att ändra läge när mellanlagringsuppgiften för datasjö har förberetts.

• Ändringsdatafångst (CDC) med ändringstabeller: Mellanlagringsuppgiften för datasjö börjar med en fullständig laddning (under denna mellanlagras alla valda tabeller till målet). Måldata hålls sedan uppdaterade med hjälp av CDC-teknik (Change Data Capture).

  Anteckning om informationCDC (Change Data Capture) av DDL-operationer stöds inte.

  När du arbetar med Gateway för dataflytt, förutom när du använder en SaaS-applikationskälla, registreras ändringar från källan i nära realtid. När du arbetar utan Gateway för dataflytt eller med SaaS-applikationskällor, registreras ändringar enligt schemaläggarens inställningar. Mer information finns i Scheduling tasks.

• Ladda om: Utför en fullständig laddning av data från de valda källtabellerna till målplattformen och skapar måltabellerna vid behov. Den fullständiga laddningen sker automatiskt när uppgiften startar, men kan också utföras manuellt eller schemalagt om den behöver upprepas periodiskt.

  Anteckning om informationDen här inställningen är inte tillgänglig för en SaaS-applikationskoppling.

Mapp som ska användas

Välj ett av följande, beroende på vilken bucket-mapp du vill att filerna ska skrivas till:

• Standardmapp

  Formatet för standardmappen är <ditt-projektnamn>/<ditt-uppgiftsnamn>

• Rotmapp

  Filerna kommer att skrivas till bucket-rotmappen.

• Mapp

  Ange ett mappnamn. Mappen skapas under datauppgiften om den inte redan finns.

  Anteckning om information Mappnamnet får inte innehålla specialtecken (till exempel @, #, ! och så vidare).

Uppladdning av data

Filattribut

Fältavgränsare

Den avgränsare som kommer att användas för att separera fält (kolumner) i målfilerna. Standardvärdet är ett komma.

Exempel på att använda ett komma som avgränsare:

"mike","male"

Avgränsare kan vara standardtecken eller ett hexadecimalt (hex-) värde. Observera att "0x" prefixet måste användas för att ange en hexadecimal avgränsare (t.ex. 0x01 = SOH0x01 = SOH). I fälten Fältavgränsare, Postavgränsare och Null-värde kan avgränsaren bestå av konkatenerade hexvärden (t.ex. 0x0102 = SOHSTX), medan den bara kan vara ett enstaka hexvärde i fälten Citattecken och Citat-undantagstecken.

Hexadecimaltalet 0x00 stöds inte (dvs. endast 0x01-0xFF stöds).

Null-värde

Strängen som kommer att användas för att ange ett nullvärde i målfilerna.

Exempel (där \n är postavgränsaren och @ är nullvärdet):

Postavgränsare

Den avgränsare som kommer att användas för att separera fält (rader) i målfilerna. Standard är ett nyradstecken (\n).

Exempel:

Citattecken

Det tecken som kommer att användas i början och på slutet av en textkolumn. Standard är dubbelcitattecknet ("). När en kolumn som innehåller kolumnavgränsare är omsluten av dubbelcitattecken tolkas kolumnavgränsartecknen som verkliga data och inte som kolumnavgränsare.

Exempel (där är citattecknet):

Citat-undantagstecken

Det tecken som används för att undanta ett citattecken finns i de aktuella data. Standard är dubbelcitattecknet (").

Exempel (där " är citattecknet och \ är undantagstecknet):

Parquet-version

Välj vilken version som ska användas beroende på vilken version som målplattformen har stöd för. Observera att Parquet version 1.0 endast har stöd för tidsmarkörenheten MICRO , medan Parquet version 2.6 har stöd både för tidsmarkörerna MICRO och NANO.

Tidsmarkörenhet för Parquet

Om Parquet-versionen ställs in till 2.6 väljer du MICRO eller NANO. Om Parquet-versionen ställs in till 1.0 stöds bara MICRO.

Högsta LOB-storlek (kB) för Parquet

Standardvärdet för maximal LOB-storlek är 64 KB och maxvärdet du kan ange i det här fältet är 10 000 KB. Hantering av LOB-kolumner kräver större resurser, vilket i sin tur påverkar prestandan. Öka bara det här värdet om du replikerar LOB-data som är större än 64 KB och all LOB-data ska replikeras till målet.

Maximal filstorlek

Den maximala storleken en fil kan nå innan den stängs (och eventuellt komprimeras).

Den maximala storleken en fil kan nå innan den stängs. Mindre filer kan laddas upp snabbare (beroende på nätverket) och förbättrar prestandan när de används i kombination med alternativet parallell körning. Att belamra databasen med små filer anses emellertid generellt vara en dålig arbetsmetod.

Komprimera filer med

Välj ett av komprimeringsalternativen för att komprimera målfilerna NONE (standard) för att lämna dem okomprimerade. Observera att de tillgängliga komprimeringsalternativen beror på vilket filformat som har valts.

Lägg till metadatahuvud

Om du vill kan du lägga till en rubrikrad i datafilerna. Rubrikraden kan innehålla källkolumnens namn och/eller datatyperna på mellannivå (dvs. Qlik Talend Data Integration.

Exempel på en målfil med en rubrikrad när både Med kolumnnamn och Med datatyper har valts:

Position:DECIMAL(38,0),Color:VARCHAR(10)

1,"BLUE"

2,"BROWN"

3,"RED"

...

Ändra behandling

I det här delavsnittet beskrivs villkorliga inställningar i Ändringsbearbetning.

Tillämpa/lagra ändringar när

• Filstorlek når: ange den maximala mängden ändringsdata som får ackumuleras innan filen laddas upp till målet.
• Förbrukad tid når: förbrukad tid når x.

Metadatafiler

När alternativet Skapa metadatafiler i målmappen väljs kommer en motsvarande metadatafil med filtillägget .dfm att skapas i den angivna målmappen. Metadatafilerna innehåller ytterligare information om uppgiften/data, exempelvis typ av källkoppling, källtabellens namn, antalet poster i datafilen och så vidare.

En fullständig beskrivning av metadatafilen och om möjliga tillämpningar finns i Metadatafilbeskrivning

Metadata

LOB-kolumner

Inkludera LOB-kolumner och begränsa kolumnstorleken till (kB)

Du kan välja att inkludera LOB-kolumner i uppgiften och ställa in maximal LOB-storlek. LOB:er som är större än maximal storlek kommer att trunkeras.

Mappning av JSON-kolumner

Mappa kompatibla JSON-kolumner från källa till mål

När det här alternativet är valt mappas JSON-kolumner på källan automatiskt till JSON-kolumner på målet.

Det här alternativets tillstånd och synlighet bestäms av följande faktorer:

• Nya uppgifter: Detta alternativ kommer att vara aktiverat som standard om både källan och målet stöder JSON-datatypen.

• Befintliga uppgifter: Detta alternativ kommer att vara inaktiverat som standard, även om både källan och målet stöder JSON-datatypen. Detta är för att bevara bakåtkompatibilitet med nedströms processer – såsom transformationer – som förväntar sig att måldata ska vara i STRING-format (vilket är det äldre beteendet). Du kan antingen lämna alternativet inaktiverat eller så kan du redigera de nedströms processerna så att de är kompatibla med JSON-format, och sedan aktivera det här alternativet.

• Nya och befintliga uppgifter: Om bara källan stöder JSON-datatypen kommer detta alternativ inte att vara synligt. Om JSON-stöd läggs till målet i ett senare skede kommer alternativet att bli synligt men förbli inaktiverat. Detta är för att bevara bakåtkompatibilitet med nedströms processer – såsom transformationer – som förväntar sig att måldata ska vara i STRING-format (vilket är det äldre beteendet).

Kontrolltabeller

Välj vilka av följande Kontrolltabeller du vill ska skapas på målplattformen:

• Replikationsstatus: Ger information om den aktuella mellanlagringsuppgiften, inklusive uppgiftsstatus, hur mycket minne som uppgiften använder, antal ändringar som ännu inte har tillämpats på dataplattformen och positionen i datakällan som data läses från för närvarande.
• Inaktiverade tabeller: Tillhandahåller en lista med inaktiverade tabeller, och anledningen till att de inaktiverades.
• Mellanlagringshistorik: Tillhandahåller information om uppgiftshistoriken, inklusive antalet och volymen med poster som bearbetas under en mellanlagringsuppgift, latensen i slutet av en CDC-uppgift och mer.
• Ändra datapartitioner: Tillhandahåller poster med partitioner som skapats på måldatabasen på grund av Ändra datauppdelning. Du kan använda den här informationen för att identifiera partitionerade data som behöver bearbetas ytterligare.

En detaljerad beskrivning av alla kontrolltabeller finns i Kontrolltabeller.

Fullständig laddning

Finjustering av prestanda

• Maximalt antal tabeller som ska laddas parallellt: ange det maximala antalet tabeller som ska laddas till målet samtidigt. Som standard är värdet 5.

• Tidsgräns för transaktionskonsekvens (sekunder): Ange antalet sekunder att vänta på att öppna transaktioner ska stängas, innan åtgärden fullständig laddning påbörjas. Standardvärdet är 600 (10 minuter). Den fullständiga laddningen kommer att påbörjas efter att värdet för överskriden tidsgräns har nåtts även om det fortfarande finns öppna transaktioner.

  Anteckning om informationFör att replikera transaktioner som var öppna när fullständig laddning startades men inte överfördes förrän efter att värdet för tidsgränsen nåddes måste du ladda om måltabellerna.
• Allokeringsfrekvens vid fullständig laddning: det maximala antalet händelser som kan överföras tillsammans. Som standard är värdet 10 000.

Efter slutförd fullständig laddning

Skapa primär nyckel eller unik: välj det här alternativet om du vill fördröja skapandet av primärnycklar eller unika index på målet tills efter den fullständiga laddningen har slutförts.

För initial laddning

Lagringsändringar

När du väljer uppdateringsmetoden Change Data Capture (CDC) kommer uppdateringar av källdata att lagras i ändringstabeller på målplattformen. Ändringstabeller samlar in alla infognings-, uppdaterings- och borttagningsåtgärder från källan, vilket gör att efterföljande program kan bearbeta ändringar inkrementellt.

I detta delavsnitt beskrivs hur du konfigurerar alternativen för ändringstabeller: DDL-hantering, lagring av uppdateringsbilder och beteende vid tabellskapande.

För djupgående information om ändringstabeller, se Använda Ändringstabeller.

Grundläggande inställningar

DDL-alternativ

DDL-alternativ (Data Definition Language) avgör hur schemarelaterade ändringar från källan ska hanteras i ändringstabellerna.

• Tillämpa på ändringstabell: När du väljer det här alternativet tillämpar systemet automatiskt DDL-ändringar från källtabellerna (till exempel att lägga till eller ta bort kolumner) på motsvarande ändringstabeller. Använd det här alternativet när dina nedströmsapplikationer behöver ändringstabeller för att återspegla alla schemändringar från källan.

• Ignorera: Systemet ignorerar alla DDL-ändringar i källan. Ändringstabellens struktur förblir oförändrad. Använd det här alternativet när DDL-ändringar i källan inte ska påverka de lagrade ändringarna, eller när ditt målsystem kräver fasta tabellscheman.

Avancerade inställningar

Vid uppdatering

Inställningar för UPPDATERING styr vilken data som fångas när en källpost uppdateras.

Lagra före och efter bild: Systemet fångar både originaldata (före uppdateringen) och de modifierade data (efter uppdateringen). Detta alternativ kräver mer lagringsutrymme men ger fullständig revisionsinformation, vilket gör att nedströmsystem kan jämföra gamla och nya värden eller utföra komplex förändringsanalys. Använd detta när dina applikationer behöver fullständig ändringskontext.

När det här alternativet är inaktiverat fångar systemet bara den modifierade datan (efter uppdateringen), inte de ursprungliga värdena. Detta alternativ minskar lagringskraven på målet. Använd detta när du endast behöver det aktuella tillståndet för ändrade poster och inte kräver historiska före-värden.

Skapande av ändringstabell

Åsidosätta standardinställningen för ändringstabellsuffix och rubrikkolumnprefix

• Suffix: Ange en sträng som ska användas som suffix för alla Ändringstabeller. Standardvärdet är __ct. Namnen i Ändringstabellen är namnen på måltabellen med suffixet tillagt. Om exempelvis standardvärdet används kommer namnet på Ändringstabellen att bli HR__ct.
• Prefix för rubrikkolumn: Ange en sträng som ska användas som prefix för alla kolumner för Ändringstabellers i rubriker. Standardvärdet är header__. Om exempelvis standardvärdet används kommer rubrikkolumnen stream_position benämnas header__stream_position.

Avgöra hur befintliga ändringstabeller hanteras när fullständig laddning startar

När en fullständig laddning startar, avgör dessa inställningar hur befintliga ändringstabeller på målet hanteras. Välj det alternativ som bäst passar dina krav på datarekonstruktion och lagring:

• Ta bort och skapa: Systemet tar bort den befintliga ändringstabellen helt och hållet och skapar en ny tom sådan. Alla tidigare lagrade ändringar tas bort. Använd detta när du vill ha en nystart med varje fullständig laddningscykel.

• Ta bort gamla ändringar och lagra nya ändringar i befintlig ändringstabell: Systemet tar bort all data från den befintliga ändringstabellen utan att påverka dess struktur eller metadata. Nya ändringar lagras i samma tabell. Använd detta när du vill behålla tabellstrukturen men radera tidigare ändringar.

• Behåll gamla ändringar och spara nya ändringar i befintlig ändringstabell: Systemet bevarar all befintlig data och metadata i ändringstabellen. Nya ändringar läggs till befintliga data. Använd detta när du behöver samla alla ändringar över flera cykler med fullständig laddning.

Ändra datauppdelning

I en vanlig mellanlagringsuppgift (utan Ändringsdatapartitionering) mellanlagras ändringar i målet utan inbördes ordning. Ändra datapartitionering möjliggör bearbetning av ändringsdata från många tabeller på ett enhetligt sätt. Du kan definiera varaktigheten för partitioner och tidsperioden för partitioneringen så att den övergripande enhetligheten för partitionerade data säkerställs (dvs. inga delvisa transaktioner, inga orderrubriker utan orderrader och så vidare).

Information om partitionerna registreras i Kontrolltabellen attrep_cdc_partitions i måldatabasen. Den här informationen kan användas för att identifiera partitionerade data som behöver bearbetas ytterligare.

Förstå hur partitionering fungerar enligt källtyp

• Från databaskällor:

  I en vanlig mellanlagringsuppgift (utan Ändringsdatapartitionering) mellanlagras ändringar i målet utan inbördes ordning. Ändra datapartitionering möjliggör bearbetning av ändringsdata från många tabeller på ett enhetligt sätt. Du kan definiera varaktigheten för partitioner och tidsperioden för partitioneringen så att den övergripande enhetligheten för partitionerade data säkerställs (dvs. inga delvisa transaktioner, inga orderrubriker utan orderrader och så vidare).

  • Schemalagd CDC: Partitioner skapas när den schemalagda uppgiftsinstansen körs. Så, till exempel, om en aktivitet är schemalagd att köras vid midnatt varje dag, och Partitionera var är inställt på 4 timmar, då kommer antalet skapade partitioner att representera tiden då commitarna inträffade under de senaste 24 timmarna. Om incheckningar skedde 01:00-03:00 och 16:15-18:00 och bastid för uppdelning är inställd på 0:00, skapas två uppdelningar: 0:00-04:00 och 16:00-20:00.

  • Kontinuerlig CDC: Om Partition every är inställt på 4 timmar, Replicate skapar en partition var 4:e timme som innehåller alla commits som inträffade under den perioden. Om inga commits gjordes under 4 timmar, kommer ingen partition att skapas för den perioden.

• Från SaaS-applikationskällor:

  Uppgifter som extraherar data från SaaS-applikationskällor är alltid schemalagda. Partitioner baseras på dataextraktionstid, eftersom begreppet commits inte existerar i SaaS-applikationskällor. Dataextraktion börjar när den schemalagda uppgiftsinstansen körs. Så, till exempel, om en aktivitet är schemalagd att köras vid midnatt varje dag, och Partitionera var är inställt på 4 timmar, då kommer antalet skapade partitioner att representera datainsamlingens varaktighet. Om dataextraktionen tar mindre än två timmar, skapas en enda partition. Men om extraktionen tar sex timmar (till exempel), skapas två partitioner.

Partitionsalternativ

• Partition every - Ange längden (i timmar och minuter) för varje partition.

  Anteckning om information

  Vi rekommenderar att du anger en partitionslängd på minst en timme. Även om latensen kan förbättras genom att ange en partitionslängd som är mindre än en timme kan (mål-) prestandan även påverkas genom att skapa många partitioner på målet (särskilt på system med stora volymer med ändringar).

  Om du återupptar en uppgift från före (BEFORE) den tid då den senaste partitionen skapades kommer mellanlagringsuppgiften i datasjö skriva till en partition som redan har stängts.

• Tidsperiod för partitioner - Partitioner skapas under en 24-timmarsperiod som beräknas enligt den specificerade "tidsperiod för partitionering" på källdatabasen i UTC-tid. Ett uppdelningsintervall på 8 timmar med en "bastid för uppdelning" kl. 02:00 skapar t.ex. följande uppdelningar: 02:00-10:00, 10:00-18:00, 18:00-02:00, men inte nödvändigtvis i den ordningen. Om en aktivitet startade kl. 01:00, kommer tidsramarna för den första uppdelningen att vara 18:00-02:00. Om en aktivitet startar mitt i en uppdelning (t.ex. kl. 04:00) kommer dess ändringsdata att inkluderas i 02:00-10:00-uppdelningen även om inga ändringar registrerade före kl. 04:00.

Kolumner för tabellrubrik

Ändringstabellen innehåller systemmetadatakolumner med ett konfigurerbart prefix. Som standard har dessa kolumner prefixet header__ (till exempel, header__stream_position, header__operation). Dessa kolumner ger information om varje ändringspost, till exempel åtgärdstypen (INSERT, UPDATE, DELETE) och den ordning i vilken ändringar inträffade.

Du kan exkludera specifika rubrikkolumner från Ändringstabellen om du inte behöver den metadata. Detta minskar lagringsbehovet på målplattformen.

Felhantering

Datafel

Datatrunkeringsfel

För datatrunkeringsfel: Välj vad du vill ska hända när en trunkering sker i en eller flera poster. Du kan välja något av följande från listan:

• Ignorera: Uppgiften fortsätter och felet ignoreras.
• Inaktivera tabell: Uppgiften fortsätter men data från tabellen med felposten flyttas till ett feltillstånd och dess data replikeras inte
• Stoppa uppgift: Uppgiften stoppas och manuellt ingrepp krävs.

Övriga datafel

För övriga datafel: Välj vad du vill ska hända när ett fel sker i en eller flera poster. Du kan välja något av följande från listan:

• Ignorera: Uppgiften fortsätter och felet ignoreras.
• Inaktivera tabell: Uppgiften fortsätter men data från tabellen med felposten flyttas till ett feltillstånd och dess data replikeras inte
• Stoppa uppgift: Uppgiften stoppas och manuellt ingrepp krävs.

Eskalera datafelhantering

Eskalera felhantering när övriga datafel når (per tabell) : Välj den här kryssrutan för att eskalera felhantering när antalet icke-trunkeringsdatafel (per tabell) når det angivna antalet: Giltiga värden är 1–10 000.

Eskaleringsåtgärd: Välj vad som ska hända när felhantering eskaleras. Observera att de tillgängliga åtgärderna beror på vilken åtgärd som väljs från listrutan För övriga datafel som beskrivs ovan.

• Inaktivera tabell (standard): Uppgiften fortsätter men data från tabellen med felposten flyttas till ett feltillstånd och dess data landed inte.

• Stoppa uppgift: Uppgiften stoppas och manuellt ingrepp krävs.

Tabellfel

När du stöter på ett tabellfel: välj något av följande från listrutan:

• Stänga av tabell (standard): uppgiften fortsätter men data från tabellen med felposten flyttas till ett feltillstånd och dess data replikeras inte.
• Stoppa uppgift : uppgiften stoppas och manuellt ingrepp krävs.

Eskalera felhantering när tabellfel når (per tabell): välj den här kryssrutan för att eskalera felhantering när antalet tillämpningskonflikter (per tabell) når det angivna antalet. Giltiga värden är 1–10 000.

Eskaleringspolicy: eskaleringspolicyn för tabellfel är inställd på Stoppa uppgift och kan inte ändras.

Miljö

• Maximalt antal nya försök: Välj det här alternativet och ange sedan det maximala antalet försök att utföra en uppgift igen när ett återställningsbart miljöfel inträffar. Efter att uppgiften har försökt utföras det angivna antalet gånger stoppas uppgiften och manuellt ingrepp krävs.

  För att aldrig försöka utföra uppgiften igen avmarkerar du kryssrutan eller anger "0".

  För att försöka utföra uppgiften ett oändligt antal gånger anger du "-1".

  • Mellanrum mellan försök (sekunder): Använd räknaren för att välja eller ange antalet sekunder som systemet väntar mellan försöken att utföra en uppgift.

    Giltiga värden är 0–2 000.

• Förläng intervallet mellan försök vid långa avbrott: Välj den här kryssrutan för att förlänga intervallet mellan försök vid långa avbrott. När det här alternativet är aktiverat fördubblas intervallet mellan varje försök tills Maximalt intervall nås (och fortsätter att försöka enligt det angivna maximala intervallet).
  • Maximalt intervall mellan försök (sekunder): Använd räknaren för att välja eller ange antalet sekunder för väntetiden mellan försöken att utföra en uppgift när alternativet Förläng intervallet för nytt försök vid långa avbrott är aktiverat. Giltiga värden är 0–2 000.

Ändra finjustering av behandling

Optimering av avlastning av transaktioner

• Avlasta pågående transaktioner till disk om:

  Transaktionsdata behålls normalt i minnet tills det är fullständigt överfört till målet eller källan. Men transaktioner som är större än det tilldelade minnet eller inte överförs inom den angivna tidsgränsen kommer att avlastas till disk.

  • Total minnesstorlek för alla transaktioner överskrider (MB): den maximala storleken som alla transaktioner kan uppta i minnet innan de avlastas till disk. Standardvärdet är 1024.
  • Transaktionens varaktighet överskrider (sekunder): den maximala tiden som varje transaktion kan uppta i minnet innan de avlastas till disk. Varaktigheten beräknas från tiden Qlik Talend Data Integration började registrera transaktionen. Standardvärdet är 60.

Finjustering av batch

• Maximalt antal ändringar per transaktion: Det minsta antalet ändringar som ska tas med i varje transaktion. Som standard är värdet 1000.

  Anteckning om information

  Ändringarna tillämpas i målet antingen när antalet ändringar är lika med eller större än värdet Minsta antalet ändringar per transaktion ELLER när värdet Maximal tid att samla transaktioner i batcher före tillämpning (sekunder) som beskrivs nedan nås, beroende på vilket som kommer först. Eftersom frekvensen av ändringar som tillämpas på målet styrs av dessa två parametrar kommer ändringar i källposterna eventuellt inte att återspeglas omedelbart i målposterna.

• Maxtid att samla transaktioner i batcher före tillämpning (sekunder): maxtiden för att samla transaktioner i batcher innan en tidsgräns överskrids. Som standard är värdet 1.

Interval

• Läs in ändringar var (minuter)

  Ställ in antal minuter för intervallet mellan inläsning av ändringar från källan. Giltigt intervall är 1 till 1 440.

  Anteckning om information

  Det här alternativet är endast tillgängligt för arbetsuppgifter som använder:

  • Gateway för dataflytt
  • Uppdateringsmetoden Sammanställning av ändringsdata (CDC).

Kontrollera om det finns ändringar

• Enligt intervallet för deltaextrahering: När det här alternativet är valt kontrollerar datauppgiften om det finns ändringar enligt intervallet för deltaextrahering.

  Anteckning om informationIntervallet startar efter varje ”runda”. En runda kan definieras som den tid det tar för datauppgiften att läsa ändringarna från källtabellerna och skicka dem till målet (som en enskild transaktion). Längden på en runda varierar beroende på antalet tabeller och ändringar. Så om du anger ett intervall på 10 minuter och en runda tar 4 minuter, kommer den faktiska tiden mellan kontrollerna efter ändringar att vara 14 minuter.

  • Deltaextraktionsintervall: Frekvensen med vilken deltan kommer att extraheras från ditt system. Standardtiden är var 60:e sekund.

• Enligt schema: När det här alternativet är valt kommer datauppgiften att extrahera deltat en gång och sedan stoppa. Den kommer sedan att fortsätta att köras enligt schema.

  Anteckning om informationDet här alternativet är endast relevant om intervallet mellan CDC-cyklerna är 24 timmar eller mer.

  För information om schemaläggning:

  • "Mellanlagra data i datasjö"-uppgifter i ett replikeringsprojekt, se Schemaläggning av CDC för mellanlagringsuppgift i datasjö

Diverse finjustering

• Uttryckscachestorlek (antal uttryck): Det maximala antalet förberedda satser som ska lagras på servern för senare körning (när ändringar tillämpas på målet). Standardvärdet är 50. Maxvärdet är 200.

• DELETE och INSERT vid uppdatering av en primärnyckelkolumn: För det här alternativet måste full kompletterande loggning vara aktiverat i källdatabasen.

  Anteckning om informationDen här inställningen är inte tillgänglig för uppgifter som använder en SaaS-applikationskoppling, såvida det inte är en Lite-koppling.

Automatisk utveckling av schema

Välj hur du ska hantera följande typer av DDL-ändringar i schemat. När du har ändrat inställningarna för schemautveckling måste du förbereda uppgiften på nytt. I tabellen nedan beskrivs vilka åtgärder som är tillgängliga för de DDL-ändringar som stöds.

Teckenbyte

Du kan ersätta eller ta bort källtecken i måldatabasen och/eller du kan ersätta eller ta bort källtecken som inte stöds av en vald teckenuppsättning.

Byta ut eller radera källtecken

Använd tabellen Ersätt eller ta bort källtecken för att definiera ersättningar för specifika källtecken. Detta kan exempelvis vara användbart när Unicode-representationen av ett tecken är olika på käll- och målplattformarna. Exempelvis visas minustecknet i teckenuppsättningen Shift_JIS som U+2212 på Linux, men på Windows visas det som U+FF0D.

Ersätta eller ta bort källtecken som inte stöds av den valda teckenuppsättningen.

Använd tabellen Källtecken som inte stöds av teckenuppsättning för att definiera ett enda ersättningstecken för alla tecken som inte stöds av den valda teckenuppsättningen.

Parallell inläsning av datauppsättningssegment

Vid fullständig laddning kan du påskynda inläsningen av stora datauppsättningar genom att dela upp datauppsättningen i segment som läses in parallellt. Tabeller kan delas upp efter dataintervall, alla partitioner, alla underpartitioner eller specifika partitioner.

Mer information finns i Parallell replikering av datauppsättningssegment.

Fler alternativ

Dessa alternativ visas inte i gränssnittet eftersom de bara är relevanta för specifika versioner eller miljöer. Konfigurera därför inte dessa alternativ om du inte uttryckligen har blivit instruerad att göra det av Qlik Support eller om det står i produktdokumentationen.Qlik

För att ställa in ett alternativ kopierar du bara alternativet i fältet Lägg till funktionsnamn och klickar på Lägg till. Ställ sedan in värdet eller aktivera alternativet enligt de instruktioner du har fått.

Schemaläggning av CDC för mellanlagringsuppgift i datasjö

I följande användningsfall måste du definiera ett schemaläggningsintervall för att hålla måldata uppdaterade:

• Vid åtkomst till en datakälla utan Gateway för dataflytt
• Använda en SaaS-applikationskoppling som inte är en Lite-koppling.
• När du samlar in ändringar från en SAP OData-källa med alternativet Enligt schema.

Schemat avgör hur ofta måldatauppsättningen ska uppdateras med ändringar i källdatauppsättningen. Medan schemat bestämmer uppdateringsfrekvensen, bestämmer typen av datauppsättning uppdateringsmetoden. Om en datauppsättning stöder CDC, kommer endast ändringarna i den datauppsättningen att hämtas och propageras till motsvarande måltabell. Om en datauppsättning inte har stöd för CDC, (till exempel en vy), kommer ändringar att spridas genom att ladda om hela datauppsättningen. Med SaaS-programanslutningar skapas en enskild uppgift med möjlighet att schemalägga CDC-intervall och omlastningsintervall under introduktionen, och senare i uppgiftens schemaläggningsinställningar. När du använder andra anslutningstyper (till exempel databaser) med CDC-uppdateringsmetoden, om vissa av de valda datauppsättningarna stöder CDC och vissa inte gör det, kommer två separata underuppgifter att skapas: en för att hämta ändringarna i de datauppsättningar som stöder CDC, och den andra för att ladda om de datauppsättningar som inte stöder CDC.

Så här ändrar du schemaläggningen:

1. Öppna ditt pipelineprojekt och gör sedan något av följande:

   • I uppgiftsvyn klickar du på på en datauppgift och välj Schemaläggning.
   • I pipelinevyn, klicka på en datauppgift och välj Schemaläggning.
   • Öppna replikeringsuppgiften och klicka på knappen Schemaläggning i verktygsfältet.
2. Ändra schemaläggningsinställningarna efter behov och klicka sedan på OK.

Kör en missad körning för en uppgift baserat på Gateway för dataflytt

Ibland kan ett nätverksproblem leda till att kopplingen till Gateway för dataflytt går förlorad. Om kopplingen till Gateway för dataflytt inte återställs före nästa schemalagda körning kommer inte dataaktiviteten att kunna köras som schemalagt. I sådana fall kan du välja om du vill köra en körning eller inte omedelbart efter att kopplingen har återställts.

Standardinställningarna för alla Gateway för dataflyttar är definierade i aktivitetscentret Administration. Du kan åsidosätta dessa inställningar för enskilda uppgifter enligt beskrivningen nedan.

Så här gör du

1. Öppna ditt projekt och gör sedan något av följande:

   • I uppgiftsvyn klickar du på på datauppgiften och välj Schemaläggning.

   • I pipelinevyn, klicka på datauppgiften och välj Schemaläggning.

   • Öppna datauppgiften och klicka på knappen Schemaläggning i verktygsfältet.

   Dialogrutan Schemaläggning – <task> öppnas.

2. Aktivera Använd anpassade inställningar för den här uppgiften.

3. Längst ned i dialogrutan väljer du något av följande alternativ för Kör missade schemalagda uppgifter.

   • Så snart som möjligt och sedan enligt schema om det är viktigt att köra en uppgift före nästa schemalagda instans

   • Enligt schemat att köra uppgiften vid nästa schemalagda instans

4. Spara dina inställningar.

Se även: Utförande av en uppgiftskörning efter ett missat schema.