HCL Notes / Domino / Diverses > Administration & Userprobleme

Dokumente aus der Zukunft

(1/2) > >>

FrankLU:
Hallo!

Ist es ein Omen, dass ich heute an einem Freitag, den 13. folgendes Phänomen habe?

Nach dem Compact einer Datenbank über die Erstellung einer neuen Replik tritt das Phänomen auf, dass neue Dokumente ein Erstellungs- und Änderungsdatum haben, das 26 Stunden und ein paar Minuten in der Zukunft liegt.

Bild 1 zeigt ein Dokument nach seiner Erstellung und Speicherung in der Datenbank, Bild 2 zeigt das Änderungsdatum von zwei Agenten , die ich am Nachmittag des 12. Mai geändert habe. Merkwürdigerweise stimmen die Zeiten bis auf die Sekunde überein, obwohl zwischen beiden Speicherungen 5 min liegen!

Das Phänomen tritt auch nur in dieser einen Datenbank auf. Auf dem Server stimmen Datum und Uhrzeit. Werden Dokumente in anderen Datenbanken auf diesem Server erstellt, so stimmen die Zeiten auch.

Was ist da faul? Und wie bekomme ich das weg?

Schönes Wochenende!
Frank

Tode:
Works as designed.... Wie Du vielleicht weisst, ist die Document Unique ID tatsächlich nur ein Zeitstempel. Und dieser Zeitstempel enthält die Erstellzeit des Dokuments. Die Dialoge lesen also den Erstell- Zeitpunkt aus der Document Unique ID ab.

Jetzt hat dieser Zeitstempel nur eine maximal mögliche Granularität von ... ich müsste Lügen ... irgendwas zwischen 1/1000 und 1 Sekunde.

Wenn Du also programmatisch mehr Dokumente in sehr kurzer Zeit erstellst, als "Unique Timeslots" in der selben Zeit vorhanden sind, dann wandern die Document Unique IDs und damit auch die Erstell- Zeitstempel in die Zukunft.
Diese "Zukunfts- Zeitstempel" sind dann gültige Werte, die natürlich auch bei  einer Replikation berücksichtigt werden.

Unique IDs / bzw. Dokumente in der Gegenwart können dann erst wieder erstellt werden, wenn die "Realzeit" den maximal vergebenen Zeitstempel aus den UNIDs eingeholt hat...

FrankLU:
Hallo Tode,

Danke für die Erklärung! Das leuchtet mir erst mal ein. Aber:

Wenn sich die Document Unique IDs der einzelnen Dokumente bei der Replik-Erstellung während des Compacts ändern würden, würde doch aber nichts mehr zusammenpassen, nicht mal die Repliken der Dokumente untereinander, wenn eine Datenbank auf mehreren Servern als Replik vorhanden ist, ganz zu schweigen von den Abhängigkeiten (vorgegebenen ($Ref) und programmierten).

Und was ist dann mit dem Umgang von "Zukunftsdokumenten" bei Abfragen und Weiterverarbeitung? Eine Abfrage, die das Erststellungsdatum abfragt (@Created), würde nach dem Compact falsche Ergebnisse liefern. Das wäre sehr beunruhigend...

Ich muss also nach einem Replica-Compact eventuell mehrere Tage warten, ehe ich mit der Datenbank wieder arbeiten kann? Auch unbefriedigend, erst recht, wenn ich vielleicht keine weitere Replik dieser Datenbank auf einem anderen Server habe.

Oder habe ich es nicht verstanden?

CarstenH:
Torsten hat vermutlich nicht genau auf deinen Screenshot geschaut - die UNID ändert sich natürlich nicht beim Compact, das wäre tödlich.

Um zum Thema zurück zu kommen - in allen Fällen, die ich bisher näher untersucht habe war tatsächlich eine falsche Server- (oder Client-) Zeit die Ursache, initial verursacht in allen (mir bekannten) Fällen durch einen Zeitsprung eines Zeitservers und in zwei Fällen außerdem durch eine anschließende Aktion eines Admins, die Zeit händisch zu "korrigieren".

Da die Zeit nicht rückwärts laufen kann gibt es keine (mir ad hoc einfallende) Methode das in den DB's/Dok's zu "korrigieren" außer durch neu Anlegen (oder Warten bis die falsche Zeit überschritten wurde). Bei 1 Tag Differenz würde ich das hier tatsächlich bis morgen aussitzen - alles andere hat hier kein vernünftiges Aufwand/Nutzen-Verhältnis.

HTH
Carsten

Ralf_B:
Hallo Frank

ich habe hier Datenbanken bei denen ich täglich mehrere Tausend Dokumente per Agent erstelle/ändere und diese zeigen dann auch oft ein Zukunftsdatum in den Eigenschaften.
Grund: https://support.hcltechsw.com/csm?id=community_question&sys_id=784a65811bca8d50a67e9759bc4bcb5a&view_source=searchResult


--- Zitat ---Ich muss also nach einem Replica-Compact eventuell mehrere Tage warten, ehe ich mit der Datenbank wieder arbeiten kann?
--- Ende Zitat ---
Für die 'normale' Repliierung macht das keine Probleme. Neue und geänderte Dokumente werden aktialisiert.
Für die selektive Replizierung sollten diese Werte eigenlich nicht benutzt werden.
Platz für ein Feld wie "Erstelldatum" und "Änderungsdaum" ......   sollte in der Maske doch vorhanden sein.
Diese werden auch korrekt gefüllt.
PS: Das ist schon seit Jahren (immer ??) so.


Ich sehe nur den Nachteil dass, zum Beispiel, ein Löschagent diese Werte benutzt.
Dann bleibt das Dok halt etwas länger in der DB.
Bishe hat das noch keine Probleme bereitet und für Abfragen oder Agenten nutze ich diese Werte nicht. 

Gruss
Ralf

Navigation

[0] Themen-Index

[#] Nächste Seite