Inställningar för mellanlagring

Du kan konfigurera inställningar för datauppgiften för mellanlagring.

• Öppna mellanlagringsuppgiften och klicka på Inställningar i verktygsfältet.

Dialogrutan Inställningar: <Task-Name> öppnas. De tillgängliga inställningarna beskrivs nedan.

Allmänt

• Databas

  Databas att använda i målet.

  Anteckning om informationDet här alternativet är inte tillgängligt vid mellanlagring av data till Qlik Cloud (via Amazon S3).

• Uppgiftsschema

  Du kan ändra namnet på schemat för datauppgiften för mellanlagring. Standardnamnet är landing.

  Anteckning om informationDet här alternativet är inte tillgängligt vid mellanlagring av data till Qlik Cloud (via Amazon S3).

• Standardanvändning av versaler för schemanamn

  Du kan ställa in standardanvändning av versaler för alla schemanamn. Om din databas är konfigurerad för att tvinga fram versaler kommer det här alternativet inte att ha någon effekt.

• Prefix för alla tabeller och vyer

  Du kan ställa in ett prefix för alla tabeller och vyer som skapas med den här uppgiften.

  Anteckning om informationDet här alternativet är inte tillgängligt vid mellanlagring av data till Qlik Cloud (via Amazon S3).
  Anteckning om informationDu måste använda ett unikt prefix när du vill använda ett databasschema i flera datauppgifter.

• Uppdateringsmetod

  Mellanlagringsuppgiften börjar alltid med en Fullständig laddning. När den Fullständiga laddningen har slutförts kan du hålla mellanlagrade data uppdaterad med någon av följande metoder:

  Anteckning om informationDet går inte att ändra uppdateringsmetod när förberedelseåtgärden för mellanlagringsdatauppgiften har slutförts.

  • Sammanställning av ändringsdata (CDC)

    Mellanlagrade data hålls uppdaterade med hjälp av tekniken CDC (Change Data Capture). CDC kanske inte stöds av alla datakällor. CDC samlar inte in DDL-åtgärder, till exempel namnbyte för kolumner eller ändringar av metadata.

    Om dina data även innehåller vyer eller tabeller som inte stöder CDC kommer två datapipelines att skapas. En pipeline med alla tabeller som stöder CDC, och en annan pipeline med alla andra tabeller och vyer som använder Ladda om och jämför som uppdateringsmetod.

  • Ladda och jämför

    Alla mellanlagrade data laddas från källan. Det här är användbart om din källa inte har stöd för CDC men kan användas med alla datakällor som stöds.

    Du kan schemalägga regelbundna laddningar.

• Laddningsmetod

  När du replikerar till ett Snowflake-mål kan du välja en av följande laddningsmetoder:

  • Massinläsning (standard)

    Om du väljer Massinläsning kan du, , ställa in laddningsparametrarna på fliken Datainläsning i .

  • Snowpipe Streaming

    Anteckning om information

    Snowpipe Streaming kommer endast att vara tillgänglig för urval om följande villkor är uppfyllda:

    • Uppdateringsmetoden Sammanställning av ändringsdata (CDC) är aktiverad.
    • Autentiseringsmekanismen i Snowflake-kopplingen är inställd på Nyckelpar.
    • Om du använder Gateway för dataflytt krävs version 2024.11.45 eller senare.

    Om du väljer Snowpipe Streaming, se till att du känner till begränsningarna och beaktanden när du använder den här metoden. Om du dessutom väljer Snowpipe Streaming och sedan byter till uppdateringsmetoden Reload and compare update, kommer laddningsmetoden automatiskt att växla tillbaka till Massinläsning.

  De främsta anledningarna till att välja Snowpipe Ström framför Massinläsning är

  • Mindre kostsamt: Eftersom Snowpipe Streaming inte använder Snowflake-lagret bör driftskostnaderna vara betydligt billigare, även om detta beror på ditt specifika användningsfall.

  • Minskad latenstid: Eftersom data strömmas direkt till måltabellerna (utan mellanlagring) bör replikering från datakällan till målet vara snabbare.

  Anteckning om tipsVid användning av Snowpipe Streaming kommer den första fullständiga laddningen att vara signifikant långsammare än Massinläsning. För att optimera inläsningen, i synnerhet för större datauppsättningar, är det bäst att använda Snowpipe Streaming tillsammans med parallellinläsningsfunktionen.

• Mapp att använda i iscensättningsområdet

  För dataplattformar som kräver ett iscensättningsområde (till exempel Databricks och Azure Synapse Analytics) kan du välja vilken mapp som ska användas vid mellanlagring av data.

  • Standardmapp

    Detta skapar en mapp med standardnamnet: <project name>/<data task name>.

  • Rotmapp

    Lagra data i lagringens rotmapp.

    Anteckning om informationDet här alternativet är endast tillgängligt vid mellanlagring av data till Qlik Cloud (via Amazon S3).

  • Mapp

    Ange ett mappnamn att använda.

• Intervall för ändringsbearbetning

  Du kan ställa in intervallet mellan bearbetning av ändringar från källan.

  Anteckning om informationDet här alternativet är endast tillgängligt vid mellanlagring av data till Qlik Cloud (via Amazon S3).

• Proxyserver vid användning av Data Movement gateway

  Anteckning om informationDet här alternativet är endast tillgängligt vid åtkomst till mål via Data Movement gateway.

  Du kan välja att använda en proxyserver när Data Movement-gatewayen ansluter till molndatalagret och lagringsområdet.

  För mer information om hur du konfigurerar Data Movement-gatewayen för att använda en proxyserver, se Ställa in Qlik Cloud-klientorganisationen och en proxyserver.

  • Använd proxy för att ansluta till molndatalager

    Anteckning om informationTillgängligt vid användning av Snowflake, Google BigQuery och Databricks.

  • Använd proxy för att ansluta till lagring

    Anteckning om informationTillgängligt vid användning av Azure Synapse Analytics, Amazon Redshift och Databricks.

Datauppladdning

Vissa av inställningarna på den här fliken är endast relevanta för specifika målplattformar.

Relevant för alla dataplattformar utom Qlik Cloud och Snowflake

Maximal filstorlek (MB)

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.

Endast relevant för Google BigQuery

Använd komprimering

När detta är valt kommer CSV-filerna att komprimeras (med gzip) innan de laddas upp till Google BigQuery.

Endast relevant för Snowflake

På fliken Allmänt kan du välja om du vill ladda data till Snowflake med Massladdning eller Snowpipe-strömning. När Snowpipe-strömning är valt visas inte fliken Datauppladdning. När Massladdning är valt är följande inställningar tillgängliga:

• Maximal filstorlek (MB): Relevant för den initiala fullständiga laddningen och CDC. Den maximala storlek en fil kan nå innan den laddas till målet. Om du stöter på prestandaproblem kan du försöka justera den här parametern.

• Antal filer att ladda i en batch: Endast relevant för den initiala fullständiga laddningen. Antalet filer som ska laddas i en enda batch. Om du stöter på prestandaproblem kan du försöka justera den här parametern.

För en beskrivning av laddningsmetoderna Massladdning och Snowpipe-strömning, se Allmänt.

Metadata

LOB-kolumner

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

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

Kontrolltabeller

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

• Mellanlagringsstatus: Ger information om den aktuella mellanlagringsuppgiften, inklusive uppgiftsstatus, mängd minne som förbrukas av uppgiften, antal ändringar som ännu inte har tillämpats på dataplattformen och positionen i källslutpunkten från vilken Gateway för dataflytt för närvarande läser.
• Pausade tabeller: Ger en lista över pausade tabeller och anledningen till att de pausades.
• Mellanlagringshistorik: Ger information om uppgiftshistoriken, inklusive antal och volym av poster som bearbetats under en mellanlagringsuppgift, latens i slutet av en CDC-uppgift med mera.

• DDL-historik: Innehåller en historik över alla DDL-ändringar som stöds och som inträffade under en uppgift.

  DDL-historiktabellen stöds endast på följande målplattformar:

  • Databricks

  • Microsoft Fabric
  • Amazon Redshift
  • Om du använder Gateway för dataflytt, behöver följande mål version 2024.11.14 eller senare:
    • Amazon S3
    • Google Cloud-lagring
    • Snowflake
  • Kafka - Om du använder Gateway för dataflytt krävs version 2025.5.42 eller senare.
  • Om du använder Gateway för dataflytt, behöver följande mål version 2025.11.1 eller senare:
    • Google BigQuery
    • Google Cloud Alloy DB for PostgreSQL (via PostgreSQL-kopplingen)
    • Google Cloud SQL for PostgreSQL (via PostgreSQL-kopplingen)
    • Microsoft Azure Database for PostgreSQL (via PostgreSQL-kopplingen)
    • PostgreSQL

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 till målet samtidigt. Standardvärdet är 5.

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

  Anteckning om informationFör att replikera transaktioner som var öppna när den fullständiga laddningen startade men som endast bekräftades efter att tidsgränsen nå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.

När fullständig laddning har slutförts

Skapa primärnyckel eller unik: Välj det här alternativet 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.

Felhantering

Datafel

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.

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

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

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

  Transaktionsdata lagras 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.
  • Transaktionens varaktighet ö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 transaktionen. Standardvärdet är 60.

Batchjustering

Vissa av inställningarna på den här fliken kanske inte är tillämpliga på alla mål eller metoder för målladdning.

Inställningar som är tillämpliga på alla mål utom Qlik Cloud och Snowflake när "Laddningsmetod" är "Snowpipe-strömning"

• Tillämpa batchade ändringar i intervaller:

• Mer än: Den minsta tid att vänta mellan varje tillämpning av batchändringar. Standardvärdet är 1.

  Om du ökar värdet för Mer än minskar frekvensen med vilken ändringar tillämpas på målet, samtidigt som batcharnas storlek ökar. Detta kan förbättra prestandan när du tillämpar ändringar på måldatabaser som är optimerade för att bearbeta stora batchar.

• Mindre än: Den maximala tid att vänta mellan varje tillämpning av batchändringar (innan en tidsgräns deklareras). Med andra ord, den maximala acceptabla latensen. Standardvärdet är 30. Det här värdet bestämmer den maximala tid att vänta innan ändringarna tillämpas, efter att värdet för Större än har nåtts.

• Tvinga tillämpning av en batch när bearbetningsminnet överstiger (MB): Den maximala mängd minne som ska användas för förbearbetning. Standardvärdet är 500 MB.

  För maximal batchstorlek ställer du in det här värdet på den högsta mängd minne du kan allokera till datauppgiften. Detta kan förbättra prestandan när du tillämpar ändringar på måldatabaser som är optimerade för att bearbeta stora batchar.

• Tillämpa batchade ändringar på flera tabeller samtidigt: Om du väljer det här alternativet bör prestandan förbättras när du tillämpar ändringar från flera källtabeller.

  • Maximalt antal tabeller: Det maximala antalet tabeller att tillämpa batchade ändringar på samtidigt. Standard är fem.

  Anteckning om informationDet här alternativet stöds inte när du använder Google BigQuery som din dataplattform.

• Begränsa antalet ändringar som tillämpas per ändringsbearbetningssats till: Välj det här alternativet för att begränsa antalet ändringar som tillämpas i en enda ändringsbearbetningssats. Standardvärdet är 10 000.

  Anteckning om informationDet här alternativet stöds endast när du använder Google BigQuery som din dataplattform.

Inställningar som endast är tillämpliga på Qlik Cloud och Snowflake när "Laddningsmetod" är "Snowpipe-strömning"

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

  • Mellanlagringsuppgifter i ett datapipelineprojekt, se Schemalägga uppgifter

Diverse justeringar

• Cachestorlek för satser (antal satser): Det maximala antalet förberedda satser att lagra på servern för senare körning (när ändringar tillämpas på målet). Standard är 50. Max är 200.

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

Schemautveckling

Välj hur du vill 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 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.

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.

Ladda datauppsättningssegment parallellt

Under fullständig laddning kan du påskynda laddningen av stora datauppsättningar genom att dela upp datauppsättningen 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 mellanlagring av datauppsättningssegment.

Schemalägga uppgifter

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

• Åtkomst till en datakälla utan Gateway för dataflytt
• Användning av en SaaS-applikationskoppling som inte stöder inställningen Läs ändringar varje
• När du fångar ändringar från en SAP OData-källa med alternativet Enligt schema.

Schemat bestämmer hur ofta måldatauppsättningarna ska uppdateras med ändringar i källdatauppsättningarna. Medan schemat bestämmer uppdateringsfrekvensen, bestämmer datauppsättningstypen 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 stöder CDC (till exempel vyer) kommer ändringar att tillämpas genom omladdning av alla källdata till motsvarande måltabeller. Om vissa av källdatauppsättningarna stöder CDC och andra inte, skapas två separata underuppgifter: en för att ladda om de datauppsättningar som inte stöder CDC, och den andra för att fånga ändringarna i datauppsättningar som stöder CDC. I det här fallet, 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).

Information om minsta schemaläggningsintervall beroende på typ av datakälla och prenumerationsnivå finns i Minsta tillåtna schemaläggningsintervall.

För att ändra schemaläggningen:

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

   • I uppgiftsvyn klickar du på på datauppgiften och väljer Schemaläggning.
   • I pipeline-vyn klickar du på på datauppgiften och väljer Schemaläggning.
   • Öppna mellanlagringsuppgiften och klicka på verktygsfältsknappen Schemaläggning .
2. Ändra schemaläggningsinställningarna efter behov och klicka sedan på OK.

Köra 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 dataflytts är definierade i aktivitetscentret Administration. Du kan åsidosätta dessa inställningar för enskilda uppgifter enligt beskrivningen nedan.

Gör så här

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

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

   • I pipeline-vyn klickar du på på datauppgiften och väljer Schemaläggning.

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

   Dialogrutan Schemaläggning - <task> öppnas.

2. Slå på Använd anpassade inställningar för den här uppgiften.

3. Längst ner i dialogrutan väljer du 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

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