Der gefährlichste Fehler der CDC bei der Wiederherstellung des Gesundheitszustands passiert nach dem Scheitern.

Wenn eine CDC-Pipeline ausfällt, ist der erste Impuls automatisch: Sie muss schnellstmöglich wieder funktionieren.

Währenddessen verarbeitet die Quelle möglicherweise noch Transaktionen. Der Rückstand kann weiter anwachsen. Berichte, Anwendungen und nachgelagerte Prozesse arbeiten möglicherweise bereits mit veralteten Daten.

Und früher oder später stellt jemand die Frage: Können wir es nicht einfach neu starten?

Das ist in der Regel der Zeitpunkt, an dem die Genesung schwieriger wird.

Denn das eigentliche Problem ist oft nicht der Fehler selbst, sondern alles, was geschah, während die Replikation nicht lief.

• Was geschah in der Zwischenzeit?
• Können wir gefahrlos dort weitermachen, wo wir aufgehört haben?
• Ist eine Resynchronisierung oder ein vollständiger Neustart erforderlich?
• Woher wissen wir, dass nichts übersehen wurde?

Ein erfolgreicher Neustart beweist nur eines: Die Replikation funktioniert wieder.

Es beweist nicht, dass das Ziel vollständig, aktuell oder korrekt ist.

Die gefährlichsten Ausfälle von CDC-Systemen sind nicht immer diejenigen, bei denen die Replikation stoppt. Sie sind diejenigen, bei denen die Replikation wieder anläuft und niemand erklären kann, was während des Ausfalls passiert ist oder beweisen kann, dass die wiederhergestellten Daten vertrauenswürdig sind.

Ziel ist nicht einfach nur ein möglichst schneller Neustart. Vielmehr geht es darum, zu vermeiden, dass ein einzelner Fehler zu einer aufwendigeren Wiederherstellung führt. Ein gestoppter Replikationsauftrag bedeutet nicht automatisch, dass Transaktionen verloren gegangen sind. Und ein erfolgreicher Neustart bedeutet nicht automatisch, dass das Zielsystem korrekt ist.

Wie Sie überprüfen können, ob ein Fehler in der CDC-Pipeline zu Datenverlust geführt hat und ob ein sicherer Neustart möglich ist

Der erste Schritt besteht darin, nicht auf Neustart zu drücken.

Die aktuellen Richtlinien des NIST zur Reaktion auf Sicherheitsvorfälle unterscheiden zwischen Erkennung, Reaktion, Wiederherstellung und kontinuierlicher Verbesserung. Diese umfassendere Vorgehensweise unterstützt die Ermittlung des Vorfalls und die Sicherung ausreichenden Kontextes, um vor Änderungen an der Umgebung eine fundierte Entscheidung zur Wiederherstellung treffen zu können.*

Es dient dazu festzustellen, wo die Verarbeitung unterbrochen wurde, was an der Quelle weiterging, welcher Zustand für die Wiederherstellung vorliegt und welche Beweise Sie anschließend benötigen.

Die folgenden sieben Fragen, der Reihe nach beantwortet, helfen Ihnen dabei, diesen Prozess zu durchlaufen.

Was genau ist schiefgelaufen und wann?

„Replikation gestoppt“ ist nicht spezifisch genug, um einen Wiederherstellungspfad auszuwählen.

Zuerst muss ermittelt werden, wo das Problem aufgetreten ist. War es eine Replikation?

• vollständig gestoppt?
• Er läuft noch, fällt aber zurück?
• Veränderungen werden zwar erfasst, aber nicht umgesetzt?
• Änderungen können am Zielsystem nicht angewendet werden?
• Von einem Ereignis im Quellsystem betroffen?
• Beeinflusst durch das Zielsystem, das Netzwerk oder einen anderen Teil der Umgebung?

Erstellen Sie anschließend eine Zeitleiste. Der Zeitpunkt, zu dem jemand das Problem bemerkt hat, muss nicht der Zeitpunkt sein, zu dem das Problem begonnen hat.

Überprüfen

• Wann fand die letzte bestätigte erfolgreiche Replikationsaktivität statt?
• Wird die Quellcodeerfassung noch fortgesetzt?
• Kommt die Weiterverarbeitung voran?
• Wird die Zielanwendung bearbeitet?
• Wurden von der Quelle weiterhin Transaktionen verarbeitet?
• Ist das Ziel verfügbar?
• Hat sich etwa zur gleichen Zeit etwas geändert – Schema, Konfiguration, Sicherheit, Infrastruktur, Wartung oder Arbeitslast?

Warum es wichtig ist

Ein Erfassungsfehler, ein Anwendungsfehler, ein wachsender Rückstand und ein Zielausfall sind unterschiedliche Probleme. Sie erfordern möglicherweise unterschiedliche Teams und unterschiedliche Wiederherstellungsmaßnahmen. Sie können fortfahren, wenn Sie sagen können: Hier wurde die Verarbeitung gestoppt, hier ist es passiert und dies ist betroffen. Nicht einfach: „Die Replikation ist irgendwo defekt.“

Wo kann die Replikation sicher fortgesetzt werden?

Dies ist eine der wichtigsten Fragen bei der Wiederherstellung. Replikationsplattformen können Prozess- oder Neustartzustände speichern, die dabei helfen, festzustellen, wo die Verarbeitung nach einer Unterbrechung fortgesetzt werden kann.

Je nach Quelle und Plattform können Ihnen Begriffe wie die folgenden begegnen:

• Neustartzustand
• Kontrollpunkt
• Lesezeichen
• Log Position
• Stellenbeschreibung
• Eine weitere quellenspezifische Wiederherstellungskoordinate

Gehen Sie nicht davon aus, dass diese Begriffe auf allen Plattformen exakt dieselbe Bedeutung haben. Entscheidend ist, ob Sie feststellen können, wo die Verarbeitung zuletzt unterbrochen wurde und ob diese Information zuverlässig genug ist, um eine Wiederherstellung zu ermöglichen.

Mainframe-CDC-Wiederherstellungsmarkierungen: Neustartstatus, Protokollpositionen und Db2 für z/OS RBA/LRSN

Je nach Quell- und Replikationsplattform können Teams auf unterschiedliche Wiederherstellungsmarkierungen und Bezeichnungen für die Verarbeitungsposition stoßen. In Db2 für z/OS-Umgebungen können diese Konzepte beispielsweise RBA oder LRSN umfassen.

Die entscheidende Frage ist, ob gültige gespeicherte Wiederherstellungsinformationen vorliegen und ob das Team deren Bedeutung versteht. Bei unterstützten RDRS-Change-Data-Capture-Prozessen ermöglichen gespeicherte Statusinformationen die Fortsetzung der Verarbeitung an der korrekten, quellenspezifischen Position nach einem Neustart. Position und Terminologie hängen von der Quelltechnologie ab.

Überprüfen

• Ist der gespeicherte Neustart-/Prozessstatus verfügbar?
• Was genau repräsentiert dieser Zustand?
• Wann wurde es zuletzt aktualisiert?
• Entspricht es dem von Ihnen erwarteten Verarbeitungsstatus?
• Ist der entsprechende Quellcodeverlauf noch verfügbar?
• Hat sich am Zielort etwas ereignet, das die Annahmen zur Wiederherstellung verändert?

Warum es wichtig ist

Eine bekannte Position im Lebenslauf unterscheidet sich grundlegend von der Rekonstruktion des Pipeline-Ablaufs während eines Vorfalls. Sie können fortfahren, sobald das Team einen eindeutigen Neustart-/Prozessstatus hat und dessen Bedeutung für Quelle und Ziel versteht.

Was geschah während der Replikationsunterbrechung, und ist der benötigte Quellverlauf noch verfügbar?

Wenn die Quelle weiterlief, konnten Transaktionen möglicherweise fortgesetzt werden, während das Zielsystem keine Änderungen mehr empfing. Daher muss das Team sowohl die Replikationslücke als auch die Auswirkungen auf nachgelagerte Systeme verstehen.

Überprüfen Sie die Lücke

• Wie lange ist das Ziel schon im Rückstand?
• Wie groß ist der Auftragsrückstand?
• Wächst der Auftragsbestand, bleibt er stabil oder schrumpft er?
• Welche Quellenhistorie ist für den betroffenen Zeitraum noch verfügbar?
• Wurden Einfügungen, Aktualisierungen, Löschungen oder Änderungen am unterstützten Schema vorgenommen?
• Bietet die Plattform einen unterstützten Aufholpfad für diese Quell- und Zielkombination?

Bei protokollbasierter CDC sollten Sie die Aufbewahrungsdauer der Quellprotokolle und den archivierten Verlauf prüfen. In manchen protokollbasierten CDC-Umgebungen können aufbewahrte oder archivierte Quellprotokolle relevant sein, um Änderungen zu verarbeiten, die sich während einer Unterbrechung angesammelt haben. Die genauen Voraussetzungen variieren je nach:

• Quelle
• Plattform
• Konfiguration
• bewahrte Geschichte
• Topologie
• Dauer und Art der Unterbrechung

Gehen Sie nicht davon aus, dass das Vorhandensein archivierter Protokolle automatisch bedeutet, dass jeder Wiederherstellungspfad weiterhin verfügbar ist. Prüfen Sie, welche Funktionen die Plattform für die jeweilige Umgebung unterstützt. Überprüfen Sie, wer das Zielsystem bereits verwendet.

• Welche Anwendungen, Berichte, Analysen, APIs oder Betriebsprozesse sind davon abhängig?
• Werden die Daten noch immer genutzt?
• Ist diesen Teams bewusst, dass es möglicherweise abgestanden ist?
• Steht ein Abrechnungs-, Berichts-, Stapel-, Kunden- oder sonstiger Geschäftsabschluss bevor?

Warum es wichtig ist

Eine Pipeline kann technisch noch wiederhergestellt werden, während veraltete Daten im nachgelagerten Bereich bereits zu einem geschäftlichen Problem werden. Sie können weitermachen, wenn Sie verstehen, was während der Lücke passiert ist, wie weit Sie im Rückstand sind und wer möglicherweise bereits betroffen ist.

Neustart des Checkpoints oder vollständige Resynchronisierung: Welcher Wiederherstellungspfad ist anzuwenden?

Hier geraten Teams oft unter Druck, schnell eine Entscheidung zu treffen. Je nach Plattform kann der gespeicherte Wiederherstellungszustand als Prüfpunkt, Lesezeichen, Neustartzustand, Verarbeitungsposition oder ähnlich bezeichnet werden.

Entscheidend ist, ob für das konkrete Fehlerszenario ein unterstützter Wiederherstellungspfad existiert. Manchmal kann die Replikation vom gespeicherten Zustand fortgesetzt und den Rückstand aufgeholt werden. Manchmal ist ein gezielterer Vergleich oder eine Resynchronisierung erforderlich. Und manchmal ist ein umfassenderer Neustart angebracht.

Abhängig von Quelle, Ziel, Konfiguration, gespeichertem Verlauf und Fehlerszenario können die verfügbaren Pfade Folgendes umfassen:

• Neustart aus dem gespeicherten Prozesszustand
• Der Prozess behielt historische Veränderungen bei
• Vergleichen Sie Quelle und Ziel, um Unterschiede zu identifizieren.
• Reparieren oder resynchronisieren Sie die betroffenen Daten mithilfe einer geeigneten Methode.
• Betroffene Datensätze teilweise neu synchronisieren
• Führen Sie eine umfassendere Resynchronisierung oder einen vollständigen Neuladen durch.

Wie man eine CDC-Pipeline nach einem Ausfall ohne vollständige Anfangslast neu startet

In manchen Umgebungen ist eine vollständige Erstlastung möglicherweise nicht erforderlich. Ob die Wiederherstellung ohne eine solche erfolgen kann, hängt von Bedingungen wie den folgenden ab:

• Nutzbarer Neustart-/Prozessstatus
• Erforderlicher Quellverlauf verfügbar
• Der Zustand des Ziels
• Unterstütztes Quell- und Zielverhalten
• Die Art des Versagens
• die dokumentierten Wiederherstellungsmechanismen der Replikationsplattform

Ziel ist es nicht, einen Neustart um jeden Preis zu vermeiden. Vielmehr soll ermittelt werden, ob ein unterstützter Neustart oder ein Aufholvorgang für diesen Vorfall angemessen ist.

Überprüfen

• Ist der gespeicherte Neustart-/Prozessstatus verfügbar und verständlich?
• Ist der für die vorgeschlagene Wiederherstellung benötigte Quellcodeverlauf noch verfügbar?
• Befindet sich das Ziel in einem Zustand, der eine weitere Erholung unterstützt?
• Gab es am Quell- oder Zielort Ereignisse, die die Annahmen zur Wiederherstellung verändern?
• Kann ein Vergleich helfen festzustellen, ob nur ein Teil der Daten betroffen ist?
• Wie lange wird es voraussichtlich dauern, den Rückstand aufzuholen?
• Können nachgelagerte Systeme diese Phase der Stagnation tolerieren?
• Welche Wiederherstellungspfade unterstützt die Plattform für diese genaue Quell-/Zielkonfiguration?

Warum es wichtig ist

Experten beschreiben die schmerzhafte Alternative sehr deutlich: „Komplettes Neuladen“ oder sogar „Neusynchronisierung von Grund auf“. Die entscheidende Frage lautet: Wann können wir ohne Neustart eine Wiederherstellung erreichen und wann nicht? Sie können fortfahren, sobald das Team erklären kann, warum der gewählte Wiederherstellungsweg für diesen speziellen Vorfall geeignet ist.

Was könnte fehlen, doppelt vorhanden, gelöscht, veraltet oder in falscher Reihenfolge sein?

Ein erfolgreicher Neustart beweist nicht automatisch, dass das Ziel korrekt ist. Abhängig von den Daten und der Architektur sollten Teams Folgendes prüfen:

• Fehlende Änderungen
• Doppelte oder erneut verarbeitete Änderungen
• Fehlende Löschungen
• Veraltete Werte
• Teilweise oder zusammenhängende Inkonsistenzen in Datensätzen
• Ordnungsprobleme, bei denen die Reihenfolge wichtig ist
• Unterstützte Schemaänderungen, die im Zusammenhang mit dem Vorfall auftraten.

Ein besonders leicht zu übersehendes Problem ist das Löschen. Eine Pipeline kann fehlerfrei erscheinen, obwohl ein Datensatz, der in der Quelle gelöscht wurde, immer noch im Ziel vorhanden ist.

Überprüfen

• Welches Transaktions-/Änderungsverhalten dokumentiert die Plattform für diese Quelle und dieses Ziel?
• Was geschieht bei einem Wiederholungsversuch oder einer erneuten Verarbeitung?
• Wie werden Quellcodelöschungen gehandhabt?
• Welche Schemaänderungsszenarien werden unterstützt?
• Welche Bestellvorgänge sind für Ihr Arbeitsaufkommen relevant?
• Was könnte bei einer normalen Statusprüfung übersehen werden?

Warum es wichtig ist

Die Aussage „Alles läuft wieder“ verrät Ihnen nicht, ob unterwegs etwas übersehen wurde. Sie können erst dann weitermachen, wenn Sie wissen, welche Fehlermodi in Ihrem Umfeld relevant sind und welche Beweise diese aufdecken könnten.

Wie werden wir beweisen, dass nichts verloren ging?

Warten Sie nicht bis nach der Wiederherstellung, um zu entscheiden, wie Sie die Validierung durchführen. Definieren Sie vor dem Neustart, welche Nachweise erforderlich sind, bevor nachgelagerte Teams darüber informiert werden, dass das Zielsystem wieder einsatzbereit ist. Je nach Umgebung kann die Validierung Folgendes umfassen:

• Unterstützter Quell-Ziel-Vergleich
• Aufzeichnungen oder Geschäftsschlüssel
• Zählt
• Hashwerte oder Prüfsummen, wo angebracht
• Zeitstempel oder Verarbeitungspositionen
• Replikationsplattform-Diagnostik
• Beispiele für geschäftskritische Transaktionen
• Downstream-Validierung

Keine einzelne Methode beweist alles. Die entscheidende Frage bei jeder Validierungsprüfung lautet:

Was beweist das – und was beweist es nicht?

Fragen

• Welcher Wiederherstellungszeitraum ist relevant?
• Welche Daten müssen überprüft werden?
• Welche Prüfungen decken die in Frage 5 genannten Risiken ab?
• Welche Unstimmigkeiten würden weitere Untersuchungen erfordern?
• Wer muss das Ergebnis überprüfen?
• Welche Beweismittel sollten aufbewahrt werden?

Warum es wichtig ist

Ein Fehler, den Wiederherstellungsteams oft begehen, ist die Annahme, dass „Die Replikation läuft wieder“ und „Dem Ziel kann wieder vertraut werden“ dasselbe bedeuten.

Das sind sie nicht.

Das eine betrifft die Systemstabilität, das andere die Datenintegrität. Die Wiederherstellung ist erst abgeschlossen, wenn Sie für beides Nachweise erbringen. Sie können fortfahren, sobald das Team einen Validierungsansatz entwickelt hat, der der Quelle, dem Ziel, dem Vorfall und dem Geschäftsrisiko angemessen ist.

Woran erkennen wir, dass die Genesung tatsächlich abgeschlossen ist?

Eine Pipeline kann laufen, obwohl noch Daten im Rückstand sind. Sie kann Daten aufholen, während nachgelagerte Daten veraltet sind. Und sie kann einen einwandfreien Prozessstatus anzeigen, während Fragen zu den wiederhergestellten Daten ungeklärt bleiben. Überprüfen Sie vor dem Schließen des Vorfalls sowohl den Prozess als auch das Ergebnis.

Überprüfen

• Kehrt die Verzögerung in den erwarteten Bereich zurück?
• Schrumpft der Auftragsbestand tatsächlich?
• Schreitet die Replikation weiter voran?
• Treten weiterhin Fehler oder Wiederholungsversuche auf?
• Wurden die relevanten Zieldaten validiert?
• Wurden die betroffenen Anlieger darüber informiert, welche Produkte sicher verwendet werden können?
• Sind noch Unstimmigkeiten oder Ausnahmen offen?
• Wurde der Vorfall dokumentiert?
• Verstehen wir genug über das Geschehene, um im Falle eines erneuten Auftretens besser reagieren zu können?

Warum es wichtig ist

Wird ein Vorfall zu früh geschlossen, können ungeklärte Fragen zu Daten, Validierung oder Auswirkungen auf nachgelagerte Prozesse hinter einem scheinbar einwandfreien Prozessstatus verborgen bleiben. Der Vorfall kann erst dann geschlossen werden, wenn das Team bestätigen kann, dass die Replikation stabil ist, die relevanten Daten validiert wurden, nachgelagerte Teams den aktuellen Stand verstehen und wir den Vorfall erklären können.

Wiederherstellungsplanung vs. Wiederherstellungsvalidierung

Die sieben Fragen in diesem Artikel helfen dabei, mögliche Fehlerquellen zu identifizieren und die Voraussetzungen für eine erfolgreiche Wiederherstellung zu bestimmen. Sie beweisen jedoch nicht, dass das wiederhergestellte Ziel korrekt ist. Nach der Wiederherstellung gilt es zu prüfen, ob eines dieser Risiken tatsächlich eingetreten ist und ob dem Ziel vertraut werden kann.

Verwandte Ressource: Die Pipeline läuft wieder. Kann man den Daten trauen?

Die Entscheidung, die Sie tatsächlich treffen

Bei diesen sieben Fragen geht es nicht darum, ob man auf „Neustart“ drücken kann. Es geht darum, ob man folgende Fragen beantworten kann: Wo können wir weitermachen? Was ist in der Zwischenzeit passiert? Können wir den Vorgang ohne einen kompletten Neustart wiederherstellen? Und wie können wir beweisen, dass nichts verloren gegangen ist?

Das ist der Unterschied zwischen der Wiederherstellung der Pipeline und der Wiederherstellung eines Zustands, dem man vertrauen kann.

Checkliste der CDC für Wiederherstellungsentscheidungen

Wenn ein Wiederherstellungsproblem zu einem Plattformproblem wird

Jede CDC-Plattform wird irgendwann Ausfälle, Unterbrechungen oder Wiederherstellungsvorgänge erleben.

Die Frage ist nicht, ob Zwischenfälle passieren. Die Frage ist, wie viel Aufwand, Unsicherheit und Risiko damit verbunden sind.

Ein einzelner negativer Vorfall bedeutet nicht automatisch, dass Sie eine andere CDC-Plattform benötigen. Wiederholte Beschwerden im Zusammenhang mit der Genesung erfordern jedoch eine gesonderte Betrachtung.

Fragen Sie sich, ob Sie Folgendes wiederholt sehen:

• Ein wachsender Rückstand bei der Quelle
• Vollständige Neuinstallationen oder umfassende Resynchronisierungen, da kein anderer Wiederherstellungspfad als vertrauenswürdig gilt.
• Eine Genesung, die davon abhängt, dass ein oder zwei Personen die richtigen Schritte kennen
• Stundenlang wurde damit verbracht, herauszufinden, ob das Problem an der Quelle, der Replikationsschicht oder am Ziel liegt.
• Manuelle oder inkonsistente Quell-Ziel-Validierung
• Unsicherheit darüber, ob Änderungen oder Löschungen übersehen wurden.
• Mangelnde Transparenz des Pipeline- oder Wiederherstellungszustands
• Auswirkungen auf das Quellsystem während der normalen Verarbeitung oder des Aufholprozesses
• Immer wieder stellen sich im weiteren Verlauf Fragen zur Vertrauenswürdigkeit der Daten.

In Mainframe-Umgebungen, in denen Db2 for z/OS, VSAM, IMS oder ADABAS die führenden Systeme sind, sollte das Wiederherstellungsverhalten für die jeweilige Quelle bewertet werden – und nicht aufgrund einer allgemeinen Aussage zur „Mainframe-Unterstützung“ angenommen werden.

An diesem Punkt ändert sich die Frage von „Wie beheben wir diesen Vorfall?“ zu „Bietet uns unser aktueller Replikationsansatz die Wiederherstellungsfähigkeit und Transparenz, die wir tatsächlich benötigen?“

Wo Rocket Data Replicate & Sync passt

Die Wiederherstellung ist eine der wichtigsten Fähigkeiten, die bei jeder CDC-Plattform bewertet werden müssen.

Rocket Data Replicate & Sync (RDRS) verwaltet die Unternehmensreplikation zwischen Mainframe-Umgebungen und modernen verteilten und Cloud-Plattformen.

Wenn Sie RDRS für eine Umgebung wie die oben beschriebene evaluieren, wenden Sie denselben Maßstab an, den Sie auch für jede andere Replikationsplattform anwenden würden.

Die sieben Fragen in diesem Artikel – was ist schiefgelaufen, wo können wir wieder ansetzen, was ist während der Unterbrechung passiert, welcher Wiederherstellungspfad ist anwendbar, was könnte falsch sein, wie werden wir es beweisen und woran erkennen wir, dass wir fertig sind – sind die gleichen Fragen, die für jede Plattform, einschließlich RDRS, beantwortet werden müssen, bevor man einem wiederhergestellten Ziel vertraut.

Bitten Sie um eine Demonstration, wie die Wiederherstellung in Ihrer spezifischen Quell- und Zielkonfiguration funktioniert:

• Wo die Verarbeitung nach einer Unterbrechung wieder aufgenommen werden kann
• Was geschieht mit den Veränderungen, die sich während der Lücke ansammeln?
• Was die Betreiber während der Wiederherstellungs- und Aufholprozesse sehen können
• Welche Möglichkeiten gibt es, wenn ein normaler Neustart nicht ausreicht?
• Welche Vergleichs- und Validierungsfunktionen für Quelle und Ziel stehen zur Verfügung?
• Was geschieht mit den Auswirkungen auf das Quellsystem während des Normalbetriebs und beim Aufholvorgang?
• Welche Beweise kann das Team verwenden, bevor es den nachgelagerten Nutzern mitteilt, dass die Daten wieder verfügbar sind?

Ob ein bestimmter Fehler ohne umfassendere Resynchronisierung oder vollständigen Neustart behoben werden kann, hängt von der Quelle, dem Ziel, der Topologie, dem gespeicherten Verlauf, der Konfiguration und der Art des Fehlers ab.

Die wichtigste Frage lautet nicht: „Unterstützt die Plattform die Wiederherstellung?“

Es lautet: „Zeigen Sie uns, wie die Wiederherstellung in den Ausfallszenarien funktioniert, denen unsere Umwelt tatsächlich ausgesetzt ist.“

*NIST SP 800-61 Rev. 3: Empfehlungen und Überlegungen zur Reaktion auf Sicherheitsvorfälle

Nächster Schritt: Die Genesung nachweisen

Die Replikation wieder in Gang zu bringen, ist nur ein Teil der Aufgabe. Die nächste Frage lautet:

Wie beweisen wir, dass die wiederhergestellten Daten vollständig sind?

Lernen Sie, wie Sie das Wiederherstellungsfenster definieren, feststellen, welche Beweise verfügbar sind, Unstimmigkeiten untersuchen und ermitteln, wann das Ziel für die weitere Verwendung bereit ist.