Inställningar för molnlagringsmål

Du kan ändra standardinställningarna för mellanlagring i datalake 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 uppgiften för mellanlagring i datalake har förberetts.

• Sammanställning av ändringsdata (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 registreras ändringar från källan i nära realtid. När du arbetar utan Gateway för dataflytt registreras ändringar enligt schemaläggarens inställningar. Mer information finns här Inställningar för molnlagringsmål.

• Ladda: 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.

Mapp att använda

Välj en av följande beroende på vilken bucketmapp du vill att filerna ska skrivas till:

• Standardmapp: Standardmappformatet är <ditt-projekt-namn>/<din-uppgifts-namn>
• Rotmapp: filerna kommer att skrivas direkt till bucketen.

• Mapp: ange mappens namn. Mappen kommer att skapas under mellanlagringsuppgiften för datasjö om den inte finns.

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

Ändra datapartitionering

I en standarduppgift för mellanlagring mellanlagras ändringar till målet utan någon särskild ordning. Ändra datapartitionering möjliggör bearbetning av ändringsdata från många tabeller på ett konsekvent sätt. Du kan definiera varaktigheten för partitioner samt partitioneringens bas-tidsmarkör, vilket säkerställer övergripande konsekvens för den partitionerade datan (dvs. inga partiella transaktioner, inga orderhuvuden utan orderrader, och så vidare).

Information om partitionerna registreras i kontrolltabellen attrep_cdc_partitions i måldatabasen. Denna information kan användas för att identifiera partitionerad data som behöver bearbetas ytterligare.

Partitioneralternativen är följande:

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

  Anteckning om information

  Det rekommenderas att ange en partitionslängd som överstiger en timme. Även om det kan förbättra latensen att ange en partitionslängd på mindre än en timme, kan skapandet av många partitioner på målet också påverka (mål)prestandan (särskilt i system med stora volymer av ändringar).

  Om du återupptar en uppgift från INNAN den tidpunkt då den senaste partitionen skapades, kommer uppgiften för mellanlagring i datalake att skriva till en partition som redan har stängts.

• Partitioneringens bas-tidsmarkör - Partitioner skapas under en 24-timmarsperiod, vilket beräknas enligt den angivna "Partitioneringens bas-tidsmarkör" på källdatabasen (i UTC-tid). Till exempel kommer ett partitionsintervall på 8 timmar med en "Partitioneringens bas-tidsmarkör" på 02:00 att skapa följande partitioner: 02:00-10:00, 10:00-18:00, 18:00-02:00 - men inte nödvändigtvis i den ordningen. Om en uppgift till exempel startade kl. 01:00, kommer tidsramen för den första partitionen att vara 18:00-02:00. Dessutom, om en uppgift startade mitt i en partition (t.ex. kl. 04:00), kommer dess ändringsdata att infogas i partitionen 02:00-10:00 (även om inga ändringar fångades upp före kl. 04:00).

Dataöverföring

Filattribut

Fäljavgränsare

Avgränsaren som kommer att användas för att separera fält (kolumner) i målfilerna. Standard är ett kommatecken.

Exempel med ett kommatecken som avgränsare:

"mike","male"

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

Det hexadecimala numret 0x00 stöds inte (dvs. endast 0x01-0xFF stöds).

Null-värde

Strängen som kommer att användas för att indikera ett null-värde i målfilerna.

Exempel (där \n är postavgränsaren och @ är null-värdet):

Postavgränsare

Avgränsaren som kommer att användas för att separera poster (rader) i målfilerna. Standard är en ny rad (\n).

Exempel:

Citattecken

Tecknet som kommer att användas i början och slutet av en textkolumn. Standard är dubbelt citattecken ("). När en kolumn som innehåller kolumnavgränsare omsluts av dubbla citattecken tolkas kolumnavgränsartecknen som faktiska data, och inte som kolumnavgränsare.

Exempel (där @ är citattecknet):

Escape-tecken för citattecken

Tecknet som används för att undfly ett citattecken i den faktiska datan. Standard är dubbelt citattecken (").

Exempel (där " är citattecknet och \ är escape-tecknet):

Parquet-version

Välj vilken version som ska användas beroende på vilken version målplattformen stöder. Observera att Parquet-version 1.0 endast stöder tidsmarkörsenheten MICRO, medan Parquet-version 2.6 stöder både tidsmarkörsenheterna MICRO och NANO.

Parquet-tidsmarkörsenhet

När Parquet-versionen är inställd på 2.6, välj MICRO eller NANO. När Parquet-versionen är inställd på 1.0 stöds endast MICRO.

Parquet maximal LOB-storlek (KB)

Standard maximal LOB-storlek är 64 KB och det maximala värdet du kan ange i detta fält är 10 000 KB. Hantering av LOB-kolumner kräver större resurser, vilket i sin tur påverkar prestandan. Öka endast detta värde om du replikerar LOB-data som är större än 64 KB och du kräver att all LOB-data replikeras till målet.

Maximal filstorlek

Den maximala storlek 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 eller NONE (standard) för att lämna dem okomprimerade. Observera att de tillgängliga komprimeringsalternativen bestäms av det valda filformatet.

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"

...

Ändringsbearbetning

Detta delavsnitt beskriver villkorliga inställningar i Ändringsbearbetning.

Tillämpa/lagra ändringar när

• Filstorleken når: Ange den maximala storleken på ändringsdata som ska ackumuleras innan filen laddas upp till målet.
• Förfluten tid når: Förfluten tid når x.

Metadatafiler

När alternativet Skapa metadatafiler i målmappen är valt, kommer en matchande metadatafil med tillägget .dfm att skapas under den angivna målmappen för varje datafil. Metadatafilerna ger ytterligare information om uppgiften/datan, såsom typ av källkoppling, källtabellens namn, antalet poster i datafilen, och så vidare.

För en fullständig beskrivning av metadatafilen samt möjliga användningsområden, se Metadatafilbeskrivning

Metadata

LOB-kolumner

Inkludera LOB-kolumner och begränsa kolumnstorlek till (KB)

Du kan välja att inkludera LOB-kolumner i uppgiften och ange den maximala LOB-storleken. LOB-objekt som är större än den maximala storleken kommer att trunkeras.

JSON-kolumnmappning

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:

• Replikeringsstatus: Ger detaljer om den aktuella mellanlagringsuppgiften, inklusive uppgiftsstatus, mängden minne som förbrukas av uppgiften, antal ändringar som ännu inte tillämpats på dataplattformen och positionen i datakällan från vilken datan för närvarande läses.
• Suspenderade tabeller: Ger en lista över suspenderade tabeller och orsaken till att de suspenderades.
• Replikeringshistorik: Ger information om uppgiftshistoriken, inklusive antal och volym av poster som bearbetats under en mellanlagringsuppgift, latens i slutet av en CDC-uppgift, med mera.
• Ändringsdatapartitioner: Ger register över partitioner som skapats på måldatabasen på grund av Ändra datapartitionering. Du kan använda denna information för att identifiera partitionerad data som behöver bearbetas ytterligare.

För en detaljerad beskrivning av var och en av kontrolltabellerna, se Kontrolltabeller

Fullständig laddning

Prestandajustering

• Maximalt antal tabeller att ladda parallellt: Ange det maximala antalet tabeller som ska laddas in i målet samtidigt. Standardvärdet är 5.

• Timeout för transaktionskonsekvens (sekunder): Ange antalet sekunder att vänta på att öppna transaktioner ska stängas innan operationen för fullständig laddning påbörjas. Standardvärdet är 600 (10 minuter). Den fullständiga laddningen startar efter att timeout-värdet har uppnåtts, även om det finns transaktioner som fortfarande är öppna.

  Anteckning om informationFör att replikera transaktioner som var öppna när fullständig laddning startade men som endast bekräftades efter att timeout-värdet uppnåddes, måste du ladda om måltabellerna.
• Bekräftelsefrekvens under fullständig laddning: Det maximala antalet händelser som kan överföras tillsammans. Standardvärdet är 10000.

Efter att fullständig laddning slutförts

Skapa primärnyckel eller unik: Välj detta alternativ om du vill fördröja skapandet av primärnyckeln eller det unika indexet på dataplattformen tills efter att den fullständiga laddningen har slutförts.

För initial laddning

När data flyttas från en SaaS-programkälla kan du ställa in hur den initiala fullständiga laddningen ska utföras.

Bearbetning av lagringsändringar

Rubrikkolumnerna för ändringstabellen ger information om ändringsbearbetningen, såsom typ av operation (till exempel INSERT), bekräftelsetid, och så vidare. Om du inte behöver denna information kan du konfigurera datauppgiften att skapa ändringstabellerna utan vissa eller alla rubrikkolumner, vilket minskar deras avtryck i måldatabasen. För att göra detta, radera kryssrutorna för de rubrikkolumner som du vill utesluta.

Observera att du inte kan ta bort ytterligare kolumner eller återställa kolumner medan en uppgift körs. För att ändra ditt initiala val måste du först stoppa uppgiften, sedan ändra ditt val och slutligen ladda om måltabellerna.

För en beskrivning av rubrikkolumnerna, se Använda Ändringstabeller.

Felhantering

Datafel

Fel vid datatrunkering

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.

Andra 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.

Eskalerande hantering av datafel

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

Antal försök innan ett tabellfel returneras

Det här alternativet låter dig styra när principen för hantering av tabellfel ska utlösas. Som standard, efter att ett tabellfel uppstått, kommer tabellen att pausas eller uppgiften att stoppas (enligt den valda åtgärden) efter tre försök. Ibland uppstår ett tabellfel på grund av planerat underhåll av SaaS-applikationen. I dessa fall kanske standardantalet försök inte räcker för att underhållet ska slutföras innan principen för hantering av tabellfel utlöses. Detta beror också på uppgiftens schemaläggningsintervall, eftersom ett nytt försök kommer att utföras varje gång uppgiften körs. Så, till exempel, om du schemalägger en uppgift att köras varje timme och SaaS-applikationen tas offline för underhåll precis när uppgiften börjar köras, kommer standardinställningen med tre försök att tillåta att SaaS-applikationen är offline i upp till tre timmar utan att principen för hantering av tabellfel utlöses. Ett längre underhållsfönster skulle kräva att du ökar antalet försök (eller ändrar schemaläggningen) för att förhindra att principen för hantering av tabellfel utlöses.

Sammanfattningsvis, om du är medveten om att din SaaS-applikation genomgår periodiskt underhåll, är bästa praxis att öka antalet försök enligt schemaläggningen så att underhållet kan slutföras utan att principen för hantering av tabellfel utlöses.

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örelaterade

• 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.

Justering av ändringsbearbetning

Justering av transaktionell avlastning

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

  Transaktionsdata hålls vanligtvis i minnet tills de är helt bekräftade till källan eller målet. Transaktioner som är större än det allokerade minnet eller som inte bekräftas inom den angivna tidsgränsen kommer dock att avlastas till disk.

  • Total minnesstorlek för alla transaktioner överstiger (MB): Den maximala storlek som alla transaktioner kan uppta i minnet innan de avlastas till disk. Standardvärdet är 1024.
  • Transaktionsvaraktighet överstiger (sekunder): Den maximala tid som varje transaktion kan stanna i minnet innan den avlastas till disk. Varaktigheten beräknas från den tidpunkt då Qlik Talend Data Integration började fånga upp transaktionen. Standardvärdet är 60.

Justering 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.

Intervall

Inställningar vid användning av SAP ODP- och SaaS (Lite)-applikationskopplingar

• 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 när dataarbetsuppgiften definieras med:

  • Gateway för dataflytt
  • Någon av följande källor:
    • SaaS-applikation endast via Lite-kopplingar
    • SAP ODP
  • Uppdateringsmetoden Sammanställning av ändringsdata (CDC).

Inställningar vid användning av SAP OData-kopplingen

Kontrollera om det finns ändringar

• I enlighet med intervallet för deltaextraheringNä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.

  • Intervall för deltaextrahering: 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ägga CDC för uppgifter för mellanlagring i datalake

Diverse justering

• Storlek på cache för satser (antal satser): Det maximala antalet förberedda satser som ska lagras på servern för senare exekvering (vid tillämpning av ändringar på målet). Standard är 50. Maxvärdet är 200.

• DELETE och INSERT vid uppdatering av en primärnyckelkolumn: Detta alternativ kräver att fullständig kompletterande loggning är aktiverad i källdatabasen.

  Anteckning om informationDen här inställningen är inte tillgänglig för kopplingar för förhandsgranskning av SaaS-applikationer. Kopplingar för förhandsgranskning anges med en -knapp, både i dialogrutan Skapa koppling och i onlinehjälpen.

Schemautveckling

Välj hur följande typer av DDL-ändringar i schemat ska hanteras. När du har ändrat inställningar för schemautveckling måste du förbereda uppgiften igen. Tabellen nedan beskriver vilka åtgärder som är tillgängliga för de DDL-ändringar som stöds.

Teckenersättning

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.

Ladda datasetsegment parallellt

Under fullständig laddning kan du påskynda laddningen av stora dataset genom att dela upp datasetet i segment, som kommer att laddas parallellt. Tabeller kan delas upp efter dataintervall, alla partitioner, alla underpartitioner eller specifika partitioner.

För mer information, se 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ägga CDC för uppgifter för mellanlagring i datalake

I följande användningsfall måste du definiera ett schemaläggningsintervall för att hålla mål-datan uppdaterad:

• Åtkomst till en datakälla utan Gateway för dataflytt
• Användning av en SaaS-applikation förhandsgranskningskoppling. För att ta reda på om din koppling är i förhandsgranskning, se kopplingshjälpen.
• Vid infångning av ändringar från en SAP OData-källa med alternativet Som schemalagt.

Schemat bestämmer hur ofta måldataseten kommer att uppdateras med ändringar i källdataseten. Medan schemat bestämmer uppdateringsfrekvensen, bestämmer datasettypen uppdateringsmetoden. Om källdatauppsättningarna stöder CDC (Change Data Capture) kommer endast ändringarna i källdata att replikeras och tillämpas på motsvarande måltabeller. Om källdatauppsättningarna inte har stöd för CDC (till exempel Vyer) kommer ändringar att tillämpas genom att ladda alla källdata till motsvarande måltabeller. Om vissa av källdatauppsättningarna har stöd för CDC och andra inte, skapas två separata deluppgifter (förutsatt att uppdateringsmetoden förCDC (Change data capture) är eller att replikeringsalternativet Lagra ändringar har valts): en för att ladda om de datauppsättningar som inte stöder CDC, och den andra för att fånga ändringarna till datauppsättningar som stöder CDC. I detta fall, för att säkerställa datakonsekvens, rekommenderas det starkt att inte behålla samma schemaläggningsintervall för båda uppgifterna (om du bestämmer dig för att ändra uppdateringsfrekvensen i framtiden).

För att ändra schemaläggningen:

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

   • I uppgiftsvyn, klicka på på en datauppgift och välj Schemaläggning.
   • I pipeline-vyn, klicka på på en datauppgift och välj Schemaläggning.
   • Öppna replikeringsuppgiften och klicka på verktygsfältsknappen Schemaläggning.
2. Ändra schemaläggningsinställningarna efter behov och klicka sedan på OK.

Exekvera en missad körning för en uppgift baserad 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 dataflytt är definierade i aktivitetscentret Administration. Du kan åsidosätta dessa inställningar för enskilda uppgifter enligt beskrivningen nedan.

För att göra detta

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

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

   • I pipeline-vyn, klicka på på datauppgiften och välj Schemaläggning.

   • Öppna datauppgiften och klicka på verktygsfältsknappen Schemaläggning.

   Dialogrutan Schemaläggning - uppgift öppnas.

2. Aktivera Använd anpassade inställningar för denna uppgift.

3. Längst ner i dialogrutan, välj ett 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

   • Som schemalagt för 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.