Autor Thema: Best Practice-Artikel zum Umgang mit zurückreplizierten Löschungen ?  (Gelesen 20813 mal)

Driri

  • Gast
siehe auch : http://atnotes.de/index.php/topic,46494.0.html

Ich biete an, zu der Problemstellung einen kurzen BP-Artikel zu verfassen inkl. eines Agenten, der bei der Bereinigung solcher GAUs helfen kann.

Wenn Interesse besteht, würde ich mich freuen, wenn jemand/mehrere jemande vor allem den technischen Part (also die Entstehungsgeschichte solcher GAUs und deren Ursachen) vor Veröffentlichung einmal querlesen würden.

Offline Axel

  • Moderator
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 8.658
  • Geschlecht: Männlich
  • It's not a bug, it's Notes
Selbstverständlich besteht Interesse. Wir sind dankbar für neue Artikel.

Axel

Ohne Computer wären wir noch lange nicht hinterm Mond!

Offline eknori

  • @Notes Preisträger
  • Moderatoren
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 11.710
  • Geschlecht: Männlich
Her damit ...
Egal wie tief man die Messlatte für den menschlichen Verstand auch ansetzt: jeden Tag kommt jemand und marschiert erhobenen Hauptes drunter her!

Driri

  • Gast
Okay, ich wage mal einen ersten Versuch. Ich werde allerdings die nächsten Tage nicht dazu kommen, Anmerkungen, Korrekturen, etc. umzusetzen (URLAUB !!!  :))


Edit : Ich kriegs nicht hin, die Bilder an den passenden Stellen im Text einzublenden. Wenn das so nicht funktioniert, lade ich die JPGs auf meinen Webspace und verlinke die dann von dort.
« Letzte Änderung: 02.10.09 - 13:33:15 von Driri »

Driri

  • Gast
Daten-GAU: Wo kommen die alten Dokumente wieder her?


Problem

Wie aus heiterem Himmel meldet sich ein Benutzer und beschwert sich, dass in Applikation XYZ plötzlich wieder uralte Dokumente aufgetaucht sind, die schon vor langer Zeit gelöscht wurden.


Die Ursache – Teil 1 : Deletion Stubs

Wird ein Dokument in einer Notes-Applikation gelöscht, bleibt es als sog. Deletion Stub erhalten, der nur noch einige Systeminformationen (z.B. UNID) des gelöschten Dokumentes enthält.

<Bild1>

Mit NotesPeek kann man sich die Deletion Stubs einer Datenbank anschauen.
NotesPeek: X-ray vision into Notes databases (developerWorks Artikel)
NotesPeek 1.53 BETA for ND6 (Lotus Sandbox)

Die Deletion Stubs sind sehr klein, müssen aber trotzdem irgendwann aus der Datenbank entfernt werden. Dies übernimmt i.d.R. der Updall-Task über Nacht mit einem Purge.
Wichtig für den Purge ist in den Replizierparametern hinterlegte Purge Intervall (siehe Abbildung).

<Bild2>

Für das Verständnis ist es wichtig zu wissen, wie Notes mit dem hier eingestellten Intervall umgeht.

Der Purge läuft dabei in einem gesonderten Intervall über die Deletion Stubs. Dieses berechnet sich wie folgt:

Purge Intervall = Anzahl Tage / 3

Bei einem solchen Purge-Lauf werden allerdings nur die Deletion Stubs entfernt, die älter als die eingestellten x Tage sind.

Im abgebildeten Beispiel hieße das, alle 30 Tage würden in der Datenbank die Deletion Stubs entfernt, die älter als 90 Tage sind. Das bedeutet, dass Löschungen zwischen 90 und 120 Tage in der Datenbank mitgeführt werden.

Siehe dazu auch die folgende Technote :
Purging documents in Lotus Notes


Die Ursache – Teil 2 : Replikation

Die Deletion Stubs werden mitrepliziert. Solange ein Deletion Stub in der Applikation existiert weiß Domino, dass das zugehörige Dokument (UNID) gelöscht wurde und entfernt dieses bei einer Replikation aus anderen Repliken (bzw. ersetzt es gegen den Deletion Stub).

Das Problem tritt nun auf, wenn ein Benutzer oder Server seit längerer Zeit nicht repliziert hat, so dass die eigentlich gelöschten Dokumente noch in seiner Replik existieren, die zugehörigen Deletion Stubs aber schon durch den Purge entfernt worden sind.

In so einer Situation sieht Notes die eigentlich schon gelöschten Dokumente als neue Dokumente an, da die UNID in der Datenbank weder als Dokument noch als Deletion Stub existiert. Durch die Replikation gelangen dann diese Dokumente wieder in die Datenbank.

Dieses Verhalten ist auch in einer Technote beschrieben:
Deleted documents are reappearing after replication


Wie lässt sich das Problem identifizieren?

In der Regel sind Meldungen von Anwendern wenig technisch und beschränken sich auf die Aussage, dass plötzlich wieder alte Dokumente in der Applikation aufgetaucht sind.

Bei ausreichend großer Datenmenge erkennt man vermutlich relativ schnell, welche Dokumente eigentlich in der Datenbank nichts zu suchen haben. Andernfalls ist man auf die Mithilfe der Anwender angewiesen und muss sich Beispiele nennen lassen.

Hat man eine Handvoll solcher „Geister“ erkannt, lässt sich relativ einfach an den Dokumenteigenschaften prüfen, ob es sich mit hoher Wahrscheinlichkeit um ein durch Deletion Stubs verursachtes Problem handelt.

<Bild3>

Auffällig ist in diesem Fall, dass die beiden markierten Daten identisch sind und von den anderen beiden Daten abweichen. Würde es sich z.B. um per Copy&Paste eingefügte Dokumente handeln, wären mindestens die beiden Erstellt- und Hinzugefügt-Daten identisch. Hierüber hat man dann schon einmal einen Anhaltspunkt, wann das Problem „verursacht“ wurde.

Wenn man Glück hat und das Problem noch nicht allzu alt ist, kann man nun in den Server-Logs und in der Benutzeraktivität der Datenbank noch nach Bestätigung suchen. Dadurch hat man dann ggf. auch den Verursacher des Problems identifiziert und kann für die Zukunft Gegenmaßnahmen einleiten.

<Bild4>

Man sollte in so einem Fall nicht unbedingt direkt zu „erzieherischen Maßnahmen“ greifen, sondern den Benutzer auf den Sachverhalt ansprechen. Die Erfahrung zeigt, dass die Problematik dem Benutzer selber nicht bekannt ist.


Was kann man tun, um die Daten zu bereinigen?

Eine Datensicherung hilft an der Stelle meistens auch nicht weiter, weil man dann entweder in der Zwischenzeit aufgetretene Änderungen verwerfen würde oder vor dem Problem stünde, eben diese in die zurückgesicherte Version zu übertragen.

Die ersten logischen Ansätze, wie z.B. eine spezielle Ansicht für die „Geister“ zu erstellen, scheitern leider daran, dass es weder über einfache Funktionen, Formelsprache oder LotusScript möglich ist, die „In dieser Datei“-Daten abzufragen.

Glücklicherweise bietet die Notes-API eine Funktion, mit der sich diese Dokumenteigenschaften ermitteln lassen.

Code
Declare Sub W32NSFNoteGetInfo Lib "nnotes" Alias "NSFNoteGetInfo" ( _
Byval hNote As Long , _
Byval member As Integer , _
td As TIMEDATE)

hNote übergibt der Funktionen einen Handle auf das zu untersuchende Notes-Dokument.

member enthält eine Konstante für die zu ermittelnde Dokumenteigenschaft. Für das Datum „Hinzugefügt (In dieser Datei)“ ist dies der Wert 13.

Eine vollständige Beschreibung der API-Funktion gibt es bei OpenNTF.org:
Get the date/time a note was added (i.e., by replication) to its parent database . . .  


Reichert man diese Funktion noch etwas an und verpackt sie in einen Agent, kann man sich die Arbeit erleichtern. Der folgende Script-Code ergibt einen Agent, der über alle markierten Dokumente in einer Ansicht läuft und aus dem Menü heraus aufgerufen werden kann.
Für jedes Dokument wird das relevante Datum ermittelt und mit einem im Beispiel fest verdrahtetem Datum verglichen.
Sind die beiden Daten identisch, wird das Dokument für die spätere Bearbeitung in einen Ordner gestellt.

Hinweis: Der Agent nimmt einem nicht die Prüfung der Dokumente ab. Hierüber ist es lediglich möglich, eine Vorauswahl der zu prüfenden Dokumente zu erzeugen. Gerade bei großen Datenbanken kann man sich so wesentlich schneller durch die „Geister“ arbeiten.


Declarations
Code
Type TIMEDATE
	Innards(1) As Long
End Type

Declare Function W32ConvertTIMEDATEToText Lib "nnotes" Alias "ConvertTIMEDATEToText" ( _
Byval IntlFormat As Long , _
Byval TextFormat As Long , _
InputTime As TIMEDATE , _
Byval retTextBuffer As Lmbcs String , _
Byval TextBufferLength As Integer , _
retTextLength As Integer) As Integer

Declare Sub W32NSFNoteGetInfo Lib "nnotes" Alias "NSFNoteGetInfo" ( _
Byval hNote As Long , _
Byval member As Integer , _
td As TIMEDATE)

Const NOTE_ADDED_TO_FILE = 13
Const MAXALPHATIMEDATE = 80
Const NOERROR = 0

Initialize
Code
Sub Initialize
	Dim session As New NotesSession
	Dim db As NotesDatabase
	Dim coll As NotesDocumentCollection
	Dim doc As NotesDocument
	Dim td As TIMEDATE
	Dim tdStr As String
	Dim cbStr As Integer , bSigned As Integer
	
' --- der Agent darf nur Win32 Platformen durchgeführt werden
	If session.Platform <> "Windows/32" Then
		Msgbox "Dieser Agent kann nur auf Win32 Platformen ausgeführt werden." , 48 , "Platform wird nicht unterstützt"
	Else
		Set db = session.CurrentDatabase
		Set coll = db.UnprocessedDocuments
		If coll.Count > 0 Then
			
			Set doc = coll.GetFirstDocument
			While Not doc Is Nothing
' --- Sicherstellen, daß die Note initialisiert werden kann
				bSigned = doc.IsSigned
				W32NSFNoteGetInfo doc.Handle , NOTE_ADDED_TO_FILE , td
' --- Umwandlung des Datum/Zeit-Wertes in einen String für den späteren Vergleich
				tdStr = String$( MAXALPHATIMEDATE + 1 , 0 )
				If W32ConvertTIMEDATEToText( 0& , 0& , td , tdStr , MAXALPHATIMEDATE , cbStr ) <> NOERROR Then
					Msgbox "Call to ConvertTIMEDATEToText failed.", 48 , "API Call Failure"
				Else
					'Msgbox "Added to File Date: " + Left$( tdStr , cbStr ) , 0 , "API Call Success"
‘--- Vergleich des ermittelten Datums gegen das kritische Datum
					If Left$( tdStr , 10 ) = "02.10.2009" Then
						Call doc.PutInFolder("TEMPCreated",True)
					End If					
				End If
				Set doc = coll.GetNextDocument( doc )
			Wend
			
			Close
			
		End If
	End If
End Sub

Der Ordner wird hier erstellt, wenn er nicht existiert. Sinnvoll ist es, den Ordner vorab selber zu erzeugen und in einer Spalte das Erstelldatum des Dokumentes (@Created) anzeigen zu lassen.

Da der Agent nur eine Prüfung des Datums macht, können auch Dokumente in den Ordner gelangen, die nicht durch eine solche Replikation als „Geist“ wieder in die Datenbank gelangt sind.

Man sollte daher die Dokumente in dem so gefüllten Ordner nicht einfach ungeprüft löschen. Dokumente, die jünger sind als das Purge Intervall, sind z.B. i.d.R. keine „Geister“.


Was kann man vorbeugend unternehmen?

Leider nicht viel.
Das Intervall in den Datenbanken hochzusetzen, um das Problem auf diesem Weg zu verringern, sorgt für ein Wachstum der Deletion Stubs in den Datenbanken. Gerade bei Datenbanken mit sehr vielen Dokumenten und hohem Löschaufkommen sollte man sich das gut überlegen.

Die Benutzer auf Leserrechte einzuschränken, dürfte in den wenigsten Fällen funktionieren. Damit ließe sich ansonsten verhindern, dass Benutzer durch Replikation alte Dokumente zurückspielen könnten.

Auf jeden Fall ist sicherzustellen, dass zumindest die Server untereinander regelmäßig replizieren. Auf gar keinen Fall sollte man längere Zeit brachliegende Clients mit einem Server replizieren lassen, soweit das in der Macht des Administrators steht.


Links

NotesPeek: X-ray vision into Notes databases (developerWorks Artikel)
NotesPeek 1.53 BETA for ND6 (Lotus Sandbox)

Purging documents in Lotus Notes (Technote)
Deleted documents are reappearing after replication (Technote)

Get the date/time a note was added (i.e., by replication) to its parent database . . .(OpenNTF.Org CodeBin)

Lotus C API Toolkit for Lotus Notes and Domino documentation
« Letzte Änderung: 02.10.09 - 13:38:53 von Driri »

Offline Cookie

  • Junior Mitglied
  • **
  • Beiträge: 85
  • Geschlecht: Männlich
  • Ja
Okay, ich wage mal einen ersten Versuch. Ich werde allerdings die nächsten Tage nicht dazu kommen, Anmerkungen, Korrekturen, etc. umzusetzen (URLAUB !!!  :))

Du kannst ganz beruhigt in den Urlaub fahren oder sein, dass Ding funktioniert hervorragend und hat mir viel Arbeit abgenommen.

Vielen Dank.

Gruß

Driri

  • Gast
@Cookie :

Freut mich  :)


@All :

Bin wieder dahaa ! Gibt es Anmerkungen, Verbesserungsvorschläge, Kritik, Gemeckere, etc. ?

Offline LN4ever

  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 505
  • Geschlecht: Männlich
Lieber Driri,

nicht sehr viel umständlicher geht es "zu Fuß" mit einer nicht-hierarchischen (!!) Ansicht, die in der ersten Spalte nach @NoteID sortiert ist und als zusätzliche Spalten mit sekundären Sortierkriterien @Created und @Modified enthält.
Zusätzlich empfehle ich einen DELETE-Button, der das Datenbankscript-Event QUERYDOCUMENTDELETE umgeht, weil er als Agent ausgeführt wird.

In dieser Ansicht stehen die per "Altreplikation" hereingekommenen Dokumente nämlich dicht beieinander, weil Notes die NoteID als Hexadezimalzahl aufsteigend mit jeweils einer Lücke von 4 erstellt.

Wenn man dann die "Verdächtigen" in einen Ordner verschiebt, der seine Gestaltung aus dieser Ansicht übernimmt, kann man mit den sekundären Sortierkriterien die guten von den bösen Geistern trennen.

Normalerweise werden solche Dokumente ja nicht über weitere Serverrepliken gestreut, weil die existierenden Replizierprotokolle das verhindern. Dann hilft oft einfach das Abwarten der nächsten Replikation. Wenn man dann auf dem nicht infizierten Server in den Ordner schaut, so findet man nur die "guten" Geister, die man mit einem Schlag aus dem Ordner löschen kann. Dann noch ein Replikationsintervall abgewartet - und die schlechten bleiben auf dem infizierten Server übrig und können gelöscht werden.

In meinen großen Datenbanken habe ich immer eine solche Ansicht mit drin - und die funktioniert auch plattformunabhängig. Und manuell eingreifen muß man ja auf jeden Fall.

Aber vielen Dank für die ausführlichen Erklärungen. Die helfen vielen bestimmt weiter.

P.S.: Nicht nur alte lokale Repliken machen dort Ärger; ein ganz beliebter Anlaß für das Auftauchen dieser Dokumente ist immer das Nichtvorhandensein eines Replizierprotokolls, sprich: Serverumzüge von Datenbanken mit Initialreplikation oder auch (ohne Serverumzug) das explizite Löschen von Replizierprotokollen. Man darf den Admins vor einem Serverumzug also durchaus dringend ans Herz legen, VOR dem Umzug die Dokumentzahlen von Repliken der Datenbanken miteinander zu vergleichen. Wenn es eine solche Konstellation gibt, dann ist der Pfeil, der die Datenbank treffen wird, immer schon abgeschossen. In vielen Fällen ist er nur in der Luft und hat sein Ziel noch nicht erreicht.

Gruß

Norbert
« Letzte Änderung: 13.10.09 - 17:13:57 von LN4ever »
Situs vilate in isse tabernit.

Driri

  • Gast
Hallo Norbert,

danke für die Anmerkungen. Ich überlege mir mal, wie ich das mit einbauen kann.  :)

Offline dh-paule

  • Aktives Mitglied
  • ***
  • Beiträge: 199
  • Geschlecht: Männlich
  • DNUG Award 2006
@diri @LN4ever

DANKE für die sehr gute Erklärung der Problematik und für das Aufzeigen einer Lösung.
Das hat mir soeben ...zig Stunden gespart. Danke, Danke , Danke

Im vorliegenden Fall waren alle "Geister" in einem klar umrissenen Zeitfenster von ca. 5 Minuten auf dem Server aufgetaucht. Deren Identifikation verlief recht einfach in dem ich das Fenster mit DocumentProperties aufgerufen habe, und mir dort alle 4 Daten anzeigen lies. Dann einfach durch die aufgelisteten NoteID scrollen bis man die Übeltäter findet und ab in den Folder damit. Über die Replikation wurden dann noch die "guten" von den "schlechten" getrennt und schwupps: so plötzlich wie die Geister erschienen waren sie auch wieder verschwunden (entfernt)
« Letzte Änderung: 26.10.09 - 19:34:44 von dh-paule »
Life on earth may be expensive,
but it does include an annual free trip around the sun


_________________________________________________________

Driri

  • Gast
Gerne.

Aufgrund der aktuellen Projektlage komme ich nicht so recht dazu, Norberts Anmerkungen mit einzubauen. Sobald ich ein bißchen Luft habe, poste ich dann eine aktualisierte Fassung.

Offline LN4ever

  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 505
  • Geschlecht: Männlich
Lieber Ingo,

ich habe nach dieser Diskussion einmal einen Agenten geschrieben, der diese Prüfung auf jedem Server periodisch vornehmen kann, und zwar laufzeitoptimiert und abbruchsicher.  Ich würde den Code gerne hier anbieten, wenn ich im Gegenzug Reaktionen bekomme, ob der Agent all das tut, was er soll, denn es ist extrem schwierig, Testfälle für den Agenten zu finden. Und wer das Problem gerade hat, sucht händeringend nach so einer Lösung. Das kann eine Win-Win-Situation geben. A propos Win-Win: im Moment ist der Agent für Windows-Plattform ausgelegt, kann aber durch Ersetzen einer einzigen Zeile auch auf andere Plattformen portiert werden.

Interesse ?

Gruß

Norbert
Situs vilate in isse tabernit.

Driri

  • Gast
Gerne, vor allem die Betriebssystemunabhängigkeit ist natürlich interessant. Ich werde das gerne testen, wenn bei uns mal wieder so ein Fall auftritt und dann eine Rückmeldung geben.

Offline LN4ever

  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 505
  • Geschlecht: Männlich
Lieber Ingo,

anbei der Agent als Attachment.

/edit:
die Zeile, die man ändern muß je nach Betriebssystem ist:

'Liste der API-Module anderer Systeme:
'Const wAPIModule = "anotes.dll" ' Windows/32 (Alpha)
'Const wAPIModule = "Inotes.dll" ' OS/2v1, OS/2v2
'Const wAPIModule = "libnotes_r.a" ' UNIX (AIX)
'Const wAPIModule = "libnotes" ' OS/390
'Const wAPIModule = "libnotes.so" ' UNIX (Solaris, Linux)
'Const wAPIModule = "libnotes.sl" ' UNIX (HP-UX)
'Const wAPIModule = "NotesLib" ' Macintosh
'Const wAPIModule = "/qsys.lib/qnotes.lib/libnotes.svrpgm" ' OS/400

/edit ende

Gruß

Norbert
« Letzte Änderung: 02.11.09 - 12:31:20 von LN4ever »
Situs vilate in isse tabernit.

 

Impressum Atnotes.de  -  Powered by Syslords Solutions  -  Datenschutz