Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Gäller för:SQL Server
SSIS Integration Runtime i Azure Data Factory
Integration Services kan starta om misslyckade paket från felpunkten, istället för att köra hela paketet igen. Om ett paket är konfigurerat att använda kontrollpunkter skrivs information om paketexekvering till en kontrollpunktsfil. När det misslyckade paketet körs om används checkpoint-filen för att starta om paketet från felpunkten. Om paketet körs framgångsrikt tas kontrollpunktfilen bort och skapas sedan om nästa gång paketet körs.
Att använda kontrollpunkter i ett paket kan ge följande fördelar.
Undvik att upprepa nedladdning och uppladdning av stora filer. Till exempel kan ett paket som laddar ner flera stora filer genom att använda en FTP-uppgift för varje nedladdning startas om efter att nedladdningen av en enskild fil misslyckats och sedan ladda ner endast den filen.
Undvik att upprepa inladdningen av stora mängder data. Till exempel kan ett paket som utför massinfogningar i dimensionstabeller i ett datalager med en separat Bulk Insert-uppgift för varje dimension startas om om infogningen misslyckas för en dimensionstabell, och endast den dimensionen kommer då att läsas in på nytt.
Undvik att upprepa aggregeringen av värden. Till exempel kan ett paket som beräknar många aggregat, såsom genomsnitt och summor, med en separat Data Flow-uppgift för att utföra varje aggregering, startas om efter att en aggregering misslyckats och endast den aggregeringen kommer att beräknas om.
Om ett paket är konfigurerat att använda kontrollpunkter, registrerar Integration Services omstartspunkten i kontrollpunktsfilen. Typen av container som misslyckas och implementeringen av funktioner som transaktioner påverkar den omstartspunkt som registreras i checkpoint-filen. De aktuella värdena för variabler fångas också i checkpoint-filen. Dock sparas inte värdena för variabler som har objektdatatypen i checkpointfiler.
Definition av omstartspoäng
Task host-containern, som kapslar in en enda uppgift, är den minsta atomära arbetsenheten som kan startas om. Foreach Loop-behållaren och en transakterad behållare behandlas också som atomära arbetsenheter.
Om ett paket stoppas medan en transakterad container körs, avslutas transaktionen och allt arbete som utförts av containern rullas tillbaka. När paketet startas om körs containern som misslyckades om. Kompletteringen av eventuella underbehållare i den transakterade containern registreras inte i checkpoint-filen. Därför körs den transaktionsstyrda containern och dess underordnade containrar igen när paketet startas om.
Anmärkning
Att använda checkpoints och transaktioner i samma paket kan orsaka oväntade resultat. Till exempel, när ett paket misslyckas och startar om från en kontrollpunkt, kan paketet upprepa en transaktion som redan har genomförts framgångsrikt.
Checkpointdata sparas inte för For Loop- och Foreach Loop-containrar. När ett paket startas om körs For Loop- och Foreach Loop-containrarna samt barncontainrarna igen. Om en barncontainer i loopen körs framgångsrikt registreras den inte i checkpoint-filen, utan körs istället om. Mer information och en tillfällig lösning finns i SSIS-kontrollpunkter respekteras inte för objekt i containrarna For Loop eller Foreach Loop.
Om paketet startas om laddas inte paketkonfigurationerna om, istället använder paketet konfigurationsinformationen som skrivits till checkpoint-filen. Detta säkerställer att paketet använder samma konfigurationer när det körs om som vid tidpunkten då det misslyckades.
Ett paket kan endast startas om på kontrollflödesnivå. Du kan inte starta om ett paket mitt i ett dataflöde. För att undvika att hela data flow körs om kan paketet designas för att inkludera flera dataflöden, där varje enhet använder en annan Data Flow-uppgift. På så sätt kan paketet startas om, och endast en Data Flow-uppgift körs igen.
Konfigurera ett paket för att starta om
Checkpoint-filen innehåller exekveringsresultat för alla färdigställda containrar, aktuella värden för system- och användardefinierade variabler samt paketkonfigurationsinformation. Filen innehåller också paketets unika identifierare. För att framgångsrikt starta om ett paket måste paketidentifieraren i checkpoint-filen och paketet matcha; annars misslyckas omstarten. Detta förhindrar att ett paket använder en kontrollpunktsfil skriven av en annan paketversion. Om paketet körs framgångsrikt, raderas checkpoint-filen efter omstart.
Följande tabell listar de paketegenskaper du ställer in för att implementera kontrollpunkter.
| Property | Description |
|---|---|
| Kontrollpunktsfilnamn | Specificerar namnet på checkpoint-filen. |
| Kontrollpunktsanvändning | Specificerar om kontrollpunkter används. |
| Spara kontrollpunkter | Anger om paketet sparar kontrollpunkter. Denna egenskap måste sättas till True för att starta om ett paket från en felpunkt. |
Dessutom måste du sätta egenskapen FailPackageOnFailure till true för alla containrar i paketet som du vill identifiera som omstartspunkter.
Du kan använda egenskapen ForceExecutionResult för att testa användningen av checkpoints i ett paket. Genom att sätta ForceExecutionResult för en uppgift eller container till Failure kan du imitera realtidsfel. När du kör paketet igen kommer den misslyckade uppgiften och containrarna att köras om.
Användning av kontrollpunkter
CheckpointUsage-egenskapen kan sättas till följande värden:
| Value | Description |
|---|---|
| Aldrig | Specificerar att checkpoint-filen inte används och att paketet körs från början av paketarbetsflödet. |
| Alltid | Specificerar att checkpointfilen alltid används och att paketet startar om från punkten för föregående exekveringsfel. Om checkpoint-filen inte hittas misslyckas paketet. |
| IfExistens | Specificerar att checkpoint-filen används om den finns. Om checkpoint-filen existerar startar paketet om från punkten för det föregående exekveringsfelet; annars körs det från början av paketarbetsflödet. |
Anmärkning
/CheckPointing-alternativet i dtexec motsvarar att sätta paketets egenskap SaveCheckpoints till True, och CheckpointUsage-egenskapen till Always. Mer information finns i dtexec-verktyget.
Skydda Checkpoint-filer
Skydd på paketnivå inkluderar inte skydd av checkpoint-filer och du måste säkra dessa filer separat. Kontrollpunktsdata kan endast lagras i filsystemet och du bör använda en operativsystemåtkomstkontrolllista (ACL) för att säkra platsen eller mappen där du lagrar filen. Det är viktigt att säkra checkpoint-filer eftersom de innehåller information om paketets tillstånd, inklusive aktuella variabler. Till exempel kan en variabel innehålla en postuppsättning med många rader privata data, som telefonnummer. Mer information finns i Åtkomst till filer som används av paket.
Konfigurera kontrollpunkter för att starta om ett misslyckat paket
Du konfigurerar Integration Services-paket att starta om från en felpunkt, istället för att köra hela paketet, genom att ställa in egenskaper som gäller för kontrollpunkter.
För att konfigurera ett paket för att starta om
I SQL Server Data Tools (SSDT) öppnar du projektet Integration Services som innehåller det paket som du vill konfigurera.
Dubbelklicka på paketet i Prieskumník riešení för att öppna det.
Klicka på fliken Kontrollflöde .
Högerklicka var som helst i bakgrunden på designytan för kontrollflödet och klicka sedan på Egenskaper.
Sätt egenskapen SaveCheckpoints till True.
Skriv in namnet på checkpoint-filen i CheckpointFileName-egenskapen.
Sätt CheckpointUsage-egenskapen till ett av två värden:
Välj alltid för att alltid starta om paketet från kontrollpunkten.
Important
Ett fel uppstår om checkpoint-filen inte är tillgänglig.
Välj IfExists för att starta om paketet endast om checkpoint-filen är tillgänglig.
Konfigurera de uppgifter och containrar från vilka paketet kan starta om.
Högerklicka på en uppgift eller container och klicka på Egenskaper.
Sätt egenskapen FailPackageOnFailure till True för varje vald uppgift och container.