Verwenden von Prüfpunkten in Paketen
Aktualisiert: 15. September 2007
In SQL Server 2005 Integration Services (SSIS) können fehlerhafte Pakete an dem Punkt neu gestartet werden, an dem der Fehler aufgetreten ist. Sie brauchen also nicht noch einmal vollständig ausgeführt werden. Wenn ein Paket zum Verwenden von Prüfpunkten konfiguriert ist, werden Informationen zur Ausführung des Pakets in eine Prüfpunktdatei geschrieben. Wenn das fehlerhafte Paket erneut ausgeführt wird, wird die Prüfpunktdatei verwendet, um das Paket von dem Punkt aus, an dem der Fehler aufgetreten ist, auszuführen. Wenn das Paket erfolgreich ausgeführt wird, wird die Prüfpunktdatei gelöscht und beim nächsten Ausführen des Pakets neu erstellt.
Das Verwenden von Prüfpunkten in einem Paket bietet die folgenden Vorteile:
- Vermeiden von wiederholten Download- und Uploadvorgängen für umfangreiche Dateien. Beispielsweise kann ein Paket, das mehrere umfangreiche Dateien mithilfe je eines FTP-Tasks downloadet, nach dem Downloaden einer einzigen fehlerhaften Datei neu gestartet werden und anschließend nur diese eine Datei erneut downloaden.
- Vermeiden, dass große Datenmengen wiederholt geladen werden müssen. Beispielsweise kann ein Paket, das mithilfe von einzelnen Masseneinfügungstasks Masseneinfügungen in Dimensionstabellen in einem Data Warehouse ausführt, neu gestartet werden, wenn eine Einfügung für eine einzige Dimensionstabelle einen Fehler auslöst. Anschließend braucht nur die fehlerhafte Dimension erneut geladen werden.
- Vermeiden wiederholter Wertaggregationen. Beispielsweise kann ein Paket, das mithilfe von einzelnen Datenflusstasks zahlreiche verschiedene Aggregate berechnet, wie z. B. Mittelwerte oder Summen, neu gestartet werden, nachdem die Berechnung einer einzigen Aggregation einen Fehler auslöst. Anschließend braucht nur die fehlerhafte Aggregation neu berechnet werden.
Wenn ein Paket für das Verwenden von Prüfpunkten konfiguriert ist, zeichnet Integration Services den Punkt, an dem neu gestartet werden soll, in der Prüfpunktdatei auf. Der in der Prüfpunktdatei aufgezeichnete Punkt, an dem neu gestartet werden soll, ist vom Typ des fehlerhaften Containers und der Implementierung von Features wie z. B. Transaktionen abhängig. Die aktuellen Werte von Variablen werden ebenfalls in der Prüfpunktdatei erfasst. Die Werte von Variablen mit dem Object-Datentyp werden jedoch nicht in Prüfpunktdateien gespeichert.
Die kleinste atomare Arbeitseinheit, die neu gestartet werden kann, ist der Taskhostcontainer, der einen einzelnen Task kapselt. Der Foreach-Schleifencontainer und der Transaktionscontainer werden ebenfalls als atomare Arbeitseinheiten behandelt.
Wenn ein Paket während des Ausführens eines Transaktionscontainers beendet wird, wird auch die Transaktion beendet, und für alle eventuell durch den Container ausgeführten Vorgänge wird ein Rollback ausgeführt. Beim Neustarten des Pakets wird der fehlerhafte Container erneut ausgeführt. Das Abschließen eventuell vorhandener untergeordneter Container in Transaktionscontainern wird nicht in der Prüfpunktdatei aufgezeichnet. Daher werden beim Neustarten des Pakets sowohl der Transaktionscontainer als auch seine untergeordneten Container erneut ausgeführt.
Hinweis: |
---|
Der Einsatz von Prüfpunkten und Transaktionen im selben Paket könnte unerwartete Ergebnisse zur Folge haben. Wenn z. B. ein Paket fehlschlägt und an einem Prüfpunkt neu gestartet wird, wiederholt das Paket unter Umständen eine Transaktion, für die bereits ein Commit erfolgreich ausgeführt wurde. |
Beim Neustarten eines Pakets werden sowohl die Foreach-Schleifencontainer als auch dessen untergeordnete Container erneut ausgeführt. Wenn ein untergeordneter Container einer Schleife erfolgreich ausgeführt wurde, wird er nicht in der Prüfpunktdatei aufgezeichnet, sondern erneut ausgeführt.
Beim Neustarten des Pakets werden die Paketkonfigurationen nicht erneut geladen; stattdessen verwendet das Paket die Konfigurationsinformationen der Prüfpunktdatei. Auf diese Weise wird sichergestellt, dass das Paket beim erneuten Ausführen wie beim ursprünglichen (fehlerhaften) Ausführen dieselben Konfigurationen verwendet.
Ein Paket kann nur auf der Ablaufsteuerungsebene neu gestartet werden. Sie können ein Paket also nicht mitten in einem Datenfluss neu starten. Um zu vermeiden, dass der gesamte Datenfluss erneut ausgeführt werden muss, können Sie beim Entwerfen des Pakets mehrere Datenflüsse planen, die jeweils einen bestimmten Datenflusstask verwenden. Auf diese Weise kann das Paket neu gestartet werden und dabei nur einen Datenflusstask erneut ausführen.
Die Prüfpunktdatei enthält das Ausführungsergebnis aller abgeschlossenen Container, die aktuellen Werte der benutzerdefinierten und der Systemvariablen, sowie Paketkonfigurationsinformationen. Die Datei enthält außerdem den eindeutigen Bezeichner des Pakets. Der Paketbezeichner in der Prüfpunktdatei muss mit dem des Pakets übereinstimmen, damit das Paket neu gestartet werden kann. Anderenfalls tritt beim Neustarten ein Fehler auf. Auf diese Weise wird vermieden, dass ein Paket eine Prüfpunktdatei verwendet, die von einer anderen Paketversion geschrieben wurde. Wenn das Paket nach dem Neustarten erfolgreich ausgeführt wird, wird die Prüfpunktdatei gelöscht.
In der folgenden Tabelle sind die Paketeigenschaften aufgeführt, die Sie zum Implementieren von Prüfpunkten festlegen können.
Eigenschaft | Beschreibung |
---|---|
CheckpointFileName |
Gibt den Namen der Prüfpunktdatei an. |
CheckpointUsage |
Gibt an, ob Prüfpunkte verwendet werden. |
SaveCheckpoints |
Gibt an, ob das Paket Prüfpunkte speichert. Diese Eigenschaft muss auf True festgelegt sein, damit ein Paket an dem Punkt neu gestartet wird, an dem ein Fehler aufgetreten ist. |
Außerdem müssen Sie für alle Container des Pakets, die das Paket nach einem Fehler neu starten sollen, die FailPackageOnFailure-Eigenschaft auf true festlegen.
Mit der ForceExecutionResult-Eigenschaft können Sie die Verwendung der Prüfpunkte eines Pakets testen. Sie können einen Echtzeitfehler imitieren, indem Sie die ForceExecutionResult-Eigenschaft eines Tasks oder eines Containers auf Failure festlegen. Wenn Sie das Paket erneut ausführen, werden der fehlerhafte Task bzw. die fehlerhaften Container erneut ausgeführt.
Die CheckpointUsage-Eigenschaft kann auf die folgenden Werte festgelegt werden:
Wert | Beschreibung |
---|---|
Never |
Gibt an, dass die Prüfpunktdatei nicht verwendet wird und dass das Paket vom Beginn des Paketworkflows aus ausgeführt wird. |
Always |
Gibt an, dass die Prüfpunktdatei immer verwendet wird und dass das Paket von dem Punkt aus neu gestartet wird, an dem bei der letzten Ausführung ein Fehler aufgetreten ist. Wenn die Prüfpunktdatei nicht gefunden wird, schlägt das Paket fehl. |
IfExists |
Gibt an, dass die Prüfpunktdatei verwendet wird, falls sie vorhanden ist. Wenn die Prüfpunktdatei vorhanden ist, wird das Paket an dem Punkt neu gestartet, an dem bei der letzten Ausführung ein Fehler aufgetreten ist; anderenfalls wird das Paket vom Beginn des Paketworkflows aus ausgeführt. |
Hinweis: |
---|
Die Verwendung von dtexec mit der Option /CheckPointing on entspricht dem Festlegen der Eigenschaften SaveCheckpoints und CheckpointUsage für das Paket auf die Werte True bzw. Always. Weitere Informationen finden Sie unter dtexec (Dienstprogramm). |
Der Schutz auf Paketebene schließt nicht den Schutz von Prüfpunktdateien ein. Daher müssen diese Dateien separat gesichert werden. Prüfpunktdaten können nur im Dateisystem gespeichert werden. Sie sollten daher eine Zugriffssteuerungsliste (ACL, Access Control List) des Betriebssystems verwenden, um den Speicherort der Datei bzw. den Ordner, in dem die Datei gespeichert wird, zu sichern. Prüfpunktdateien sollten unbedingt gesichert werden, da sie Informationen zum Paketstatus enthalten, einschließlich der aktuellen Variablenwerte. Beispielsweise kann eine Variable ein Recordset mit mehreren Zeilen privater Daten, wie z. B. Telefonnummern, enthalten. Weitere Informationen finden Sie unter Schützen von Dateien, die von Paketen verwendet werden.
SQL Server Integration Services (Übersicht)
Erstellen von Paketen im SSIS-Designer
Informationsquellen für SQL Server 2005
Version | Verlauf |
---|---|
15. September 2007 |
|
17. Juli 2006 |
|
14. April 2006 |
|
05. Dezember 2005 |
|