Inställningar för datareplikeringsuppgifter

Du kan konfigurera inställningar för datareplikeringsuppgiften.

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

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

Allmänt

I den här fliken kan du ändra replikeringsläge, inställningar för mellanlagring (om de är tillgängliga) och läget för att tillämpa ändringar på målet.

Replikeringsläge

Följande replikeringslägen är tillgängliga:

• Fullständig laddning Laddar 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 vid behov.

• Tillämpa ändringar: Håller måltabellerna uppdaterade med de ändringar som görs i källtabellerna.

• Lagra ändringar: Lagrar ändringarna i källtabellerna i Change Tables (en per källtabell).

  Se Lagra ändringar för mer information.

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 (t.ex. med en Qlik Talend Cloud Starter-prenumeration eller när du väljer Inga) registreras ändringar enligt schemaläggarens inställningar. Se Schemalägga uppgifter när du arbetar utan Gateway för dataflytt för mer information.

Om du väljer Lagra ändringar eller Tillämpa ändringar och dina källdata innehåller tabeller som inte stöder CDC eller vyer, skapas två datapipelines. En pipeline för tabeller som stöder CDC, och en annan pipeline för alla andra tabeller och vyer som endast stöder Fullständig laddning.

Koppling till ett mellanlagringsområde

När replikering görs till de datalager som anges nedan behöver du konfigurera ett mellanlagringsområde. Data bearbetas och förbereds i mellanlagringsområdet innan det överförs till lagret.

• Amazon Redshift
• Microsoft Fabric
• Databricks

Välj antingen ett befintligt mellanlagringsområde eller klicka på Skapa ny för att definiera ett nytt mellanlagringsområdet och följ instruktionerna i Ansluta till molnlagring.

Klicka på Redigera för att redigera kopplingsinställningarna. Klicka på Testa koppling för att testa kopplingen (rekommenderas).

Information om vilka mellanlagringsområden som stöds med vilka datalager finns i kolumnen Stöds som ett mellanlagringsområde i Användningsfall och versioner som stöds på målplattformen.

Tillämpa ändringar-läge

Ändringar tillämpas i måltabellerna med en av följande metoder:

• Batchoptimerad: detta är standardvärdet. När det här alternativet väljs tillämpas ändringar i batcher. En förbearbetningsåtgärd inträffar för att gruppera transaktionerna i batcher på det mest effektiva sättet.
• Transaktionell: Välj det här alternativet för att tillämpa varje transaktion individuellt i den ordning den allokeras. I det här fallet är strikt referentiell integritet säkerställd för alla tabeller.

Uppladdning av data

Maximal filstorlek

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.

Metadata

Enkel

• Måltabellschema: det schema på målet som källtabellerna kommer att replikeras till om du inte vill använda källtabellschemat (eller om det inte finns något schema i källdatabasen).

  Anteckning om informationVid replikering till ett Oracle-mål är standardtabellschemat för målet "system". Observera också att om du lämnar detta fält tomt (i så fall kommer källschemat att användas) måste du se till att källschemat redan finns på målet. Annars kommer uppgiften att misslyckas.
  Anteckning om informationDen maximala tillåtna längden för schemanamnet är 128 tecken.

LOB-inställningar

Tillgängliga LOB-inställningar varierar beroende på valt replikeringsmål. Eftersom datalagermål inte har stöd för obegränsade LOB-kolumnstorlekar kommer det här alternativet inte att vara tillgängligt vid replikering till ett datalager.

LOB-inställningar för mål som inte är datalager

• Inkludera inte LOB-kolumner: välj detta om du inte vill att käll-LOB-kolumnerna ska replikeras.

• Begränsa LOB-kolumnstorlek till (KB): Detta är förvalt. Välj det här alternativet om du bara behöver replikera små LOB:ar eller om målplattformen inte har stöd för obegränsad LOB-storlek. Det maximala tillåtna värdet för det här fältet är 102 400 KB (100 MB).

  När små LOB:ar replikeras är det här alternativet effektivare än alternativet Begränsa inte LOB-kolumnstorlek, eftersom LOB:arna replikeras "inline" och inte via sökning från källan. Under ändringsbearbetning replikeras små LOB:er vanligen via sökning från källan.

  Gränsen gäller för antalet LOB-byte som läses från källans slutpunkt. För BLOB-kolumner kommer målstorleken för BLOB att vara exakt enligt den angivna gränsen. För CLOB- och NCLOB-kolumner kan målstorleken för LOB skilja sig från den angivna gränsen om käll- och mål-LOB:en inte har samma teckenuppsättning. I så fall utför datauppgiften en teckenuppsättningskonvertering vilket kan resultera i en avvikelse mellan källans och målets LOB-storlekar.

  Eftersom värdet på Begränsa LOB-storlek till uttrycks i bytes ska storleken beräknas med följande formler:

  • BLOB: längden på den största LOB:en.
  • NCLOB: Längden på den längsta TEXTen i tecken gånger två (eftersom varje tecken behandlas som en dubbel-byte). Om det finns 4-bytetecken i data ska de multipliceras med fyra.
  • CLOB: Längden på den längsta TEXTen i tecken (eftersom varje tecken behandlas som ett UTF8-tecken). Om det finns 4-bytetecken i data ska de multipliceras med två.
  Anteckning om information

  • Alla LOB:er som är större än den angivna storleken kommer att trunkeras.
  • Under ändringsbearbetning från en Oracle-källa replikeras inline-BLOB:ar inline.
  • Ändringar av den här inställningen kommer bara att påverka befintliga tabeller efter att de laddats igen.

• Begränsa inte storleken på LOB-kolumnen När det här alternativet väljs kommer LOB-kolumner att replikeras, oavsett storlek.

  Anteckning om informationAtt replikera LOB-kolumner kan påverka prestandan. Detta gäller framför allt i fråga om stora LOB-kolumner där replikeringsuppgiften behöver utföra en sökning från källtabellen för att hämta käll-LOB-värdet.

  • Optimera när LOB-storleken är mindre än: Välj det här alternativet om du behöver replikera både små och stora LOB:er och de flesta av LOB:erna är små.

    Anteckning om information

    Det här alternativet stöds bara med följande källor och mål:

    • Källor: Oracle, Microsoft SQL server, MySQL, PostgreSQL och IBM DB2 for LUW

    • Mål: Oracle, Microsoft SQL Server, MySQL, PostgreSQL.

    När det här alternativet väljs kommer, under fullständig laddning, små LOB:er att replikeras "inline" (vilket är mer effektivt) och de stora LOB:erna kommer att replikeras genom att en sökning utförs från källtabellen. Men under ändringsbearbetning kommer både små och stora LOB:er att replikeras genom att en sökning utförs från källtabellen.

    Anteckning om information

    När det här alternativet väljs kommer replikeringsuppgiften att kontrollera alla LOB-storlekar för att avgöra vilka som ska överföras "inline". LOB:er som är större än den angivna storleken kommer att replikeras i fullständigt LOB-läge.

    Om du vet att de flesta av LOB:erna är större än den angivna inställningen är det därför lämpligare att använda alternativet Replikera obegränsade LOB-kolumner i stället.

  • Segmentstorlek (KB): Du kan om du vill ändra vilken storlek på LOB-segmenten som ska användas när data replikeras till målet. Standardsegmentstorleken bör vara tillräcklig i de flesta fall, men om du får prestandaproblem kan prestandan förbättras genom att justera storleken.

    Anteckning om information

    Med vissa databaser sker datatypvalideringen när data infogas eller uppdateras. I de här fallen kan replikeringen av strukturerade datatyper (t.ex. XML, JSON, GEOGRAPHY osv.) misslyckas om data är större än den angivna segmentstorleken.

Lob-inställningar för datalagermål som stöds

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

Avancerat

Inställningar för kontrolltabell

• Schema kontrolltabell: Ange målschemat för kontrolltabellerna om du inte vill att de ska skapas i källschemat (standard) eller i målschemat.

  Anteckning om informationDen maximala tillåtna längden för schemanamnet är 128 tecken.
• Skapa målkontrolltabeller i tabellutrymme:​När replikeringsmålet är Oracle anger du det tabellutrymme där du vill att målkontrolltabellerna ska skapas. Om du inte anger någon information i det här fältet kommer tabellerna att skapas i standardtabellutrymmet i måldatabasen.
• Skapa index för målkontrolltabeller i tabellutrymme: När replikeringsmålet är Oracle anger du det tabellutrymme där du vill att kontrolltabellsindexen ska skapas. Om du inte anger någon information i det här fältet skapas indexen i samma tabellutrymme som kontrolltabellerna.
• Tidsfönster replikeringshistorik (minuter): Längden för varje tidsfönster i Replikeringshistorik-kontrolltabellen. Standardvärdet är 5 minuter.

Urval kontrolltabell

Tillämpa ändringar

De här inställningarna är bara tillgängliga när replikeringsläget Tillämpa ändringar är aktiverat.

Enkel

Tillämpa DDL-ändringar på måltabell

Följande alternativ avgör om DDL-åtgärder som utförs på motsvarande källtabell även kommer att utföras på måltabellen.

Avancerat

Se Ändra finjustering av behandling.

Lagra ändringar

De här inställningarna är bara tillgängliga när replikeringsläget Lagra ändringar är aktiverat.

Enkel

DDL-alternativ

Välj ett av följande alternativ för att avgöra hur DDL-åtgärder på källtabellerna ska hanteras:

• Tillämpa på ändringstabell: DDL-åtggärder på källtabellerna (till exempel att en kolumn läggs till) kommer bara att tillämpas på motsvarande Ändringstabeller.
• Ignorera: alla DDL-åtgärder på källtabeller kommer att ignoreras.

Avancerat

Vid uppdatering

Välj Lagra före och efter bild för att lagra både pre-UPDATE-data och post-UPDATE-data. Om det inte väljs kommer bara post-UPDATE-data att lagras.

Skapande av ändringstabell

I följande avsnitt beskrivs de tillgängliga alternativen när ändringar lagras i Ändringstabeller.

• Suffix: Ange en sträng som används 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 rubrikkolumner: 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.

Mer information om Ändringstabeller finns i Använda Ändringstabeller.

Om ändringstabellen finns när fullständig laddning startar: välj något av följande för att avgöra hur Ändringstabellerna ska laddas när den fullständiga laddningsreplikeringen startar:

• Ta bort och skapa ändringstabell: tabellen tas bort och en ny tabell skapas i dess ställe.

• Ta bort gamla ändringar och spara nya ändringar i befintlig ändringstabell: data trunkeras och läggs till utan att tabellens metadata påverkas.

  Anteckning om informationStöds inte när Microsoft Fabric är målplattformen.
• Behåll gamla ändringar och spara nya ändringar i befintlig ändringstabell: data och metadata i den befintliga Ändringstabellen påverkas inte.

Kolumner för tabellrubrik

Ändringstabellens rubrikkolumner ger information om Ändringsbearbetningsåtgärder, till exempel typ av åtgärd (t.ex. INSERT), överföringstidpunkt och så vidare. Om du inte behöver all den här informationen kan du konfigurera flyttar-uppgiften så att Ändringstabeller skapas med valda rubrikkolumner (eller inga kolumner) så att deras fotavtryck i måldatabasen minskar.

En beskrivning av rubrikkolumnerna finns i Ändringstabeller.

Felhantering

Enkel

Tillämpa konflikter

Kopiera nyckel när INSERT tillämpas: Välj vilken åtgärd som ska vidtas när det finns en konflikt med en INSERT-åtgärd.

• Ignorera: uppgiften fortsätter och felet ignoreras.

   

• UPPDATERA den befintliga målposten: målposten med samma primärnyckel som den INSERTED (infogade) källposten uppdateras.

• Logga post till undantagstabellen (standard): uppgiften fortsätter och felet skrivs till undantagstabellen.

• Stänga av 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.

Ingen post hittades för att tillämpa en UPDATE: Välj vilken åtgärd som ska vidtas när det finns en konflikt med en UPDATE-åtgärd

• Ignorera: uppgiften fortsätter och felet ignoreras.

• INSERT den saknade posten:den saknade målposten kommer att infogas i måltabellen. När källändpunkten är Oracle måste ytterligare loggning aktiveras för alla källtabellkolumner.

• Logga post till undantagstabellen (standard): uppgiften fortsätter och felet skrivs till undantagstabellen.

• Stänga av 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.

Avancerat

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.
• Logga post i undantagstabellen (standard): Uppgiften fortsätter och felet skrivs till undantagstabellen.
• 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.
• Logga post i undantagstabellen (standard): Uppgiften fortsätter och felet skrivs till undantagstabellen.
• 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 flyttad inte.

  Anteckning om information

  Beteendet skiljer sig åt beroende på ändringsbearbetningsläge:

  • I Transaktionell tillämpning-läget kommer de senaste ändringarna inte att flyttad.

  • I Batchoptimerad tillämpning kan en situation uppstå där data inte flyttad alls, eller bara delvis flyttad.

• Stoppa uppgift: Uppgiften stoppas och manuellt ingrepp krävs.
• Logga post i undantagstabellen: Uppgiften fortsätter och posten skrivs till undantagstabellen.

Tabellfel

När ett tabellfel hittas: Välj något av följande från listrutan:

• Inaktivera 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 tabellfel (per tabell) når det angivna antalet: Giltiga värden är 1–10 000.

Eskaleringsåtgärd: Eskaleringspolicyn för tabellfel är inställd till Stoppa uppgift och kan inte ändras.

Tillämpa konflikter

Ingen post hittades för att tillämpa en DELETE: välj vilken åtgärd som ska vidtas när det finns en konflikt med en DELETE-åtgärd.

• Ignorera: uppgiften fortsätter och felet ignoreras.
• Logga post till undantagstabellen: uppgiften fortsätter och felet skrivs till undantagstabellen.
• Stänga av 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 tillämpa konflikter 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.

Eskaleringsåtgärd: välj vad som ska hända när felhantering eskaleras:

• Logga post till undantagstabellen (standard): uppgiften fortsätter och felet skrivs till undantagstabellen.

• Stänga av tabell: uppgiften fortsätter men data från tabellen med felposten flyttas till ett feltillstånd och dess data replikeras inte.

  Anteckning om information

  Beteendet skiljer sig åt beroende på ändringsbearbetningsläge:

  • I Transaktionell tillämpning-läget kommer de senaste ändringarna inte att replikeras

  • I det batchoptimerade tillämpningsläget är en situation möjlig där det inte sker någon replikering av data eller datareplikeringen sker delvis.

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

Miljöfel

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

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

  • Transaktionsminnets storlek ö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 då replikeringsuppgiften började registrera transaktionen. Standardvärdet är 60.

Finjustering av batch

Följande inställningar är bara tillgängliga när Tillämpningsläget är inställt till Batchoptimerat.

• Använd grupperade ändringar i intervall:

• Större än: Den kortaste tiden att vänta mellan varje tillämpning av batchändringar. Som standard är värdet 1.

  Om värdet Längre än ökas minskar frekvensen som ändringar tillämpas med på målet samtidigt som storleken på batcherna ökar. Det kan förbättra prestandan när ändringar tillämpas på måldatabaser som är optimerade för bearbetning av stora batcher.

• Mindre än: den längsta tiden att vänta mellan varje tillämpning av batchändringar (innan en tidsgräns överskriden deklareras). Med andra ord, den maximala acceptabla latensen. Som standard är värdet 30. Värdet avgör den maximala tiden att vänta innan ändringarna tillämpas efter att Längre än-värdet har nåtts.

• Framtvinga tillämpning av en batch när bearbetningsminnet överskrider (MB): den maximala mängden minne som ska användas vid förbearbetning i Batchoptimerat tillämpningsläge. Som standard är värdet 500.

  Om du vill ha den maximala batchstorleken ställer du in det här värdet till den maximala mängden minne som du kan allokera till replikeringsuppgiften. Det kan förbättra prestandan när ändringar tillämpas på måldatabaser som är optimerade för bearbetning av stora batcher.

Intervalldata

• 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 bara tillgängligt i när:

  • Använda Gateway för dataflytt
  • Mellanlagring av data från SaaS-applikationskällor
  • Uppgiften definieras med uppdateringsmetoden för Sammanställning av ändringsdata (CDC)

Diverse finjustering

Cachestorlek för satser (antal satser)

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.

Lagra uppgiftsåterställningsdata i måldatabas

Välj det här alternativet för att lagra uppgiftsspecifik återställningsinformation i måldatabasen. När det här alternativet har valts skapar replikeringsuppgiften en tabell benämnd attrep_txn_state i måldatabasen. Den här tabellen innehåller transaktionsdata som kan användas för att återställa en uppgift om att filerna i Gateway för dataflytt-datamappen är skadade eller om lagringsenheten som innehåller Datamappen inte fungerar.

Tillämpa ändringar med SQL MERGE

Om det här alternativet inte väljs kommer replikeringsfunktionen att utföra separata INSERT-, UPDATE- och DELETE-satser i bulk för var och en av de olika ändringstyperna i tabellen Net Changes.

Även om den här metoden är mycket effektiv är det ännu effektivare att aktivera alternativet Tillämpa ändringar med using SQL MERGE när du arbetar med slutpunkter som stöder det här alternativet.

Detta är av följande anledningar:

• Det minskar antalet SQL-satser som körs per tabell från tre till en. De flesta UPDATE-åtgärderna i stora, oåterkalleliga, filbaserade molndatabaser (till exempel Google Cloud BigQuery) omfattar omskrivning av berörda filer. För sådana operationer är minskningen av antalet SQL-satser per tabell från tre till en mycket avsevärd.
• Måldatabasen behöver bara söka genom tabellen Net Changes en gång, vilket innebär en betydande minskning av I/O.

Optimera infogningar

När Tillämpa ändringar med SQL MERGE är valt tillsammans med alternativet Optimera infogningar och ändringarna endast består av INSERTs, kommer replikeringsuppgiften att utföra INSERTs istället för att använda SQL MERGE. Observera att även om detta vanligtvis förbättrar prestandan och därigenom minskar kostnaderna kan det också leda till dubblettposter i måldatabasen.

Transaktionell tillämpning

Följande inställningar är bara tillgängliga när Tillämpningsläget är inställt till Transaktionell.

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

  Anteckning om informationReplikeringsuppgiften tillämpar ändringarna 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 tidsgränsen för batchen nås (se nedan), 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.

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.

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 uppgifter när du arbetar utan Gateway för dataflytt

Gateway för dataflytt stöds inte med en Qlik Talend Cloud Starter-prenumeration och är ett tillval med andra prenumerationsnivåer. Vid arbete utan Gateway för dataflytt stöds inte CDC (Change data capture) i nära realtid. Du håller måldata uppdaterade genom att ställa in ett schemaläggningsintervall. 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 källdatauppsättningarna stöder CDC 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 replikeringsalternativet Tillämpa ändringar eller Lagra ändringar har valts): en för att ladda om de datauppsättningar som inte stöder CDC, och den andra för att registrera ändringarna i datauppsättningar som stöder CDC. I det här fallet rekommenderas det starkt att du ställer in samma schema för båda deluppgifterna för att säkerställa dataenhetlighet.

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

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

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

   • I uppgiftsvyn klickar du på på en replikeringsuppgift och väljer Schemaläggning.
   • I pipeline-vyn klickar du på på en replikeringsuppgift och väljer 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.