Das Notes Forum
Domino 9 und frühere Versionen => Administration & Userprobleme => Thema gestartet von: AC am 24.11.04 - 10:22:23
-
Hilfe !!!!!! Und nochmal Hilfe
Heute nacht (früh morgen) wurden mir zig Tausende Dokumente gelöscht bei einer DB auf dem Server.
Was problematisch ist, die DB wird auch vom Aussendienst via Telefonleitung repliziert.
(via Leserfelder kriegt jeder nur aber die Dokumente aus seinem Gebiet)
Nachdem es für jeden ADLer zig Tausende Dokumente sind, ist es von den Telefonkosten sehr heikel.
Bis auf einem hat noch keiner meiner Kollegen heute früh repliziert.
Einer hat jetzt eine leere Datenbank, die anderen haben alle den Stand von gestern.
Ich hab aber eine alte Replik Stand gestern vom Vertriebsleiter, da sind noch alle Dokumente drin (steht überall im Leserfeld).
Er hat heute noch nicht repliziert.
Bin jetzt am Überlegen, ob ich folgendes machen kann bzw. ob das eine vernünftige Lösung ist..
Ich lösche die Datenbank am Server.
Anschliessend lege ich mit der lokalen DB des Verkaufsleiters eine neue Replik am Server an.
Hauptfrage: Was passiert dann, wenn der Aussendienst heute abend repliziert ?
Kriegen die was mit, daß sich etwas geändert hat ?
Spielen die Lesefelder eine Rolle (ich hatte mal komische Effekte als ich eine DB mit Leserfeldern von lokal auf den Server legte)
Und was passiert mit dem Kollegen, der die leere DB hat.
Er selbst hat kein Löschrecht auf der DB insofern könnten keine Löschungen hochrepliziert werden.
Aber kriegt er dann wieder die alten Dokumente? Oder bleibt seine DB leer?
Sonst noch jemand ein Idee?
Ein lauter Hilfeschrei von mir und dankbar für jede Antwort.
Gruß Holcomb
PS Wenn jemand interessiert, dann verrate ich auch wie es passiert ist. Mea Culpa.
-
Hallo,
wenn ich das richtig sehe, hast Du mit der Replik Deines Vertriebsleiters ja quasi eine 1:1 Replik des Servers, oder?
Falls ja, sollte es tatsächlich machbar sein, diese Replik auf den Server zu legen und danach eben alle Replizieren zu lassen. Wenn dann alle repliziert haben, hast Du wieder ungefähr den Stand von gestern.
Was mir dazu noch einfällt:- Was ist mit der Datensicherung? Gibt es keine?
- Dokumente, die nach der letzten Replizierung des Vertriebsleiters direkt auf dem Server erstellt wurden (Innendienst, Schnittstelle, ...) sind dadurch dann aber weg!
- Für gewöhnlich sind genau in solchen Momenten die lokalen Datenbanken auf den Notebooks der Aussendienstler auch kaputt. Das muß wohl Murphys Law sein :'(
Dann bekommst Du leider niemals wieder den Stand von gestern auf die Reihe - Zumindest der Kollege mit der leeren DB sollte nach meiner Meinung eine komplett neue Replik bekommen
- Eventuell solltest Du, nachdem Du die Replik des Vertriebsleiters auf den Server gelegt hast, das Replizierprotokoll und das Cut-Off-Date löschen, bevor Du die anderen replizieren lässt.
Das bedeutet zwar, daß die Replikation bei den einzelnen Außendienstlern länger dauert, ist aber, denke ich, der sicherere Weg.
Mal überlegen, was ich noch vergessen habe. Ich bin mir sicher, den anderen hier im Forum fällt dazu noch was ein, oder?
Viele Grüße
Andreas
P.S.: Sch... Situation. Deshalb, wie immer, alle Antworten ohne Gewähr.
P.P.S.: Achte darauf, daß in der Zeit, in der Du Dir eine Vorgehensweise zurechtlegst, keiner neue Dokumente auf dem Server in der "leeren" DB anlegt. Sperr die Benutzer eben solange aus (ACL - NoAccess)
-
Hallo fritandr,
Dokumente werden in dieser DB nur abends erzeugt durch einen Agenten, kein User kann da was reinstellen. Die DB gibt Verkaufsaufträge wieder.
Die Sache mit dem Replizierprotokoll und dem CutOffDate.
Da bin ich etwas unsicher, das weiß ich nicht so genau. Hmm.
Gruß Holcomb
-
ALs Ergänzung:
Ich hab konsistente ACL auf der DB.
Der Verkaufsleiter ist Autor und steht auch im Serverdokument des NABs in einer Gruppe die neue Repliken auf den Sever legen darf.
Wenn ich mich zu obiger Methode entscheide.
Was ist besser ?
Vom Client des Verkaufsleiter mit dessen ID die Replik dann hochzuladen ?
Oder mir auf Dateiebene die Datenbank mir aufs Notebook zu kopieren und mit meinen Managerrechten dann die selbst die neue Replik hochzuladen.
Aber ich hab da etwass Bammel bei beiden Methoden.
Gruß Holcomb
-
Wenn Du das mit deiner ID machst, mußt Du natürlich auch auf alle Dokumente Zugriff haben. Sonst mach das vorsichtshalber lieber mit der ID des Verkaufsleiters, wenn der alle Rechte hat.
Du kannst das ja evtl. auch einfach mal testen. Zieh eine Noteskopie der Datenbank auf dem Server und erstell dir mit nem Testuser eine lokale Replik und sieh nach, ob die Dokumente passen. Wäre dann quasi eine Generalprobe.
-
Wenn Du das mit deiner ID machst, mußt Du natürlich auch auf alle Dokumente Zugriff haben. Sonst mach das vorsichtshalber lieber mit der ID des Verkaufsleiters, wenn der alle Rechte hat.
Du kannst das ja evtl. auch einfach mal testen. Zieh eine Noteskopie der Datenbank auf dem Server und erstell dir mit nem Testuser eine lokale Replik und sieh nach, ob die Dokumente passen. Wäre dann quasi eine Generalprobe.
Hi Driri,
ich hab auch Leserechte auf sämtliche Dokumente.
Bin aber im gegensatz zum Verkaufsleiter Manager auf der DB.
Er selbst ist nur Autor .
Aber ich bin mir unsicher ob das keine Tücken hat, wenn ich auf
Betriebssystemebene mir die Datenbank hier aufs Notebook kopiere und dann mit meienr ID dann hochlade.
ABer eigentlich sollte es keinen Unterschied machen.
Das mit den Kopien (via Notes also eine Noteskopi eienr DB) ziehen bei DBs mit Ledefeldern und konsistenter ACL , da habe ich schlechte Erfahrungen. Obwohl ich dann Dokumente hätte sehen müssen, waren die dann nicht zu sehen.
Insofern stehe ich dem Vorschlag mit dem Testen etwa skeptisch gegenüber.
Gruß Holcomb
-
Wir haben hier z.B. ein System für unseren Außendienst im Einsatz, in dem auch mit Leserfeldern gearbeitet wird.
Für Testzwecke ziehen wir da regelmäßig Noteskopien und ich bin dabei noch nie auf Probleme gestoßen.
Auf jeden Fall kann man mit ner Noteskopie ja keinen Schaden anrichten, also wäre das evtl. einen Versuch wert.
-
Driri:
Die Noteskopien am Server oder lokal ?
Ich krieg da Probelem, wenn ich lokal am Client mit von einer lokalen DB (konsistente ACL) eine neue Kopie (auch lokal ziehe).
Gruß, Holcomb.
-
Ich meinte jetzt am Server. Lokal nach Lokal hab ich noch nicht getestet.
-
wie auch immer. Aber mache die Kopie auf jeden Fall mit Notes und nicht auf OS-ebene. Bei mehreren 1000 Dokumenten kriegst du sonst mehr Probleme, als dir lieb sind (Ansichtenindex etc)
PS: Die Ursache dieser Löschung tät mich schon interessieren täten ;)
-
wie auch immer. Aber mache die Kopie auf jeden Fall mit Notes und nicht auf OS-ebene. Bei mehreren 1000 Dokumenten kriegst du sonst mehr Probleme, als dir lieb sind (Ansichtenindex etc)
PS: Die Ursache dieser Löschung tät mich schon interessieren täten ;)
Hi HRaq,
aus Zeitgründen habe ich den Test wie Driri ihn vorgschlagen hat mal sein lassen.
Hab die Serverreplik mit den 0 Dokumenten gelöscht.
ich replizier grade mal die die Replik des Verkaufsleiter hoch.
Zuvor habe ich mir die DB auch mal lokal gezippt.
Wenn die oben ist sehe ich weiter.
Doch wie gehts dann weiter?
Soll ich etwas an dem CuttOff Date machen wie Fitandr vorgeschlagen hat ?
Welche Konsequenzen hat das?
Wie es passiert ist?
Eigene Dummheit, Hektik usw.
Hab gestern eine Noteskopie ohne Dokumente einer bestehenden Datenbank auf den Server gelegt.
In dieser Datenbank ist ein periodischer Agent geschaltet.
Und dieser gleicht Dokumente mit einer anderen Datenbank (die hat es dann erwischt mit den Löschungen) ab.
Ich vergaß, daß da ein Agent drin ist und dieser periodisch läuft und so
ist er auch heute nacht auch aus dieser Testdatenbank heraus gelaufen.
Da diese Testdatenbank leer war, hat der Agent eben die Dokumente in meiner anderen produktiven Datenbank rausgelöscht (130.000).
Holcomb
-
Wenn Du das CutOff-Date löschst, werden bei der Replikation alle Dokumente geprüft und ggf. repliziert. Bei gesetzten CutOff-Date berücksichtigt der Replikator nur Dokumente, die seit dem gesetzten Datum verändert wurden.
-
Wenn Du das CutOff-Date löschst, werden bei der Replikation alle Dokumente geprüft und ggf. repliziert. Bei gesetzten CutOff-Date berücksichtigt der Replikator nur Dokumente, die seit dem gesetzten Datum verändert wurden.
Danke, das ist das Datum bei den Replizierparamter - Andere -.
Klar.
Ist nicht mein Tag heute.
Ich bin jetzt am testen wie es hier weiter geht, wenn dann mal die Ansichten am Server aufgebaut sind.
Gruß Holcomb
-
Wie weit bist Du denn jetzt?
Meine Strategie wäre hier: DB auf dem Server löschen, mit der ID des Verkaufsleiters eine NEUE Replik auf dem Server erstellen.
Und dann, wie Henning erwähnt hat, untersuchen, woher denn die Löschungen gekommen sind ....
-
Wie weit bist Du denn jetzt?
Meine Strategie wäre hier: DB auf dem Server löschen, mit der ID des Verkaufsleiters eine NEUE Replik auf dem Server erstellen.
Und dann, wie Henning erwähnt hat, untersuchen, woher denn die Löschungen gekommen sind ....
Moin Semea,
habs letzte Woche auch so gemacht.
Die DB auf dem Server gelöscht.
Dann die neue Replik auf dem Server mitd er ID des Verkaufsleiters angelegt.
Murphy schlug dann natürlich nochmal zu (natürlich typisch, wie hätte es auch anders sein können in so einem Fall), aber es hat dann im Endeffekt dann doch nichts ausgemacht.
Das mit dem Replizierprotokoll bzw den Replizierzeiten für den AD.
Es war zwar etwas länger als sonst, aber hielt sich im Rahmen.
Ein Aussendienstler hatte sich damals am Morgen die Löschungen bereits repliziert, aber der war am Freitah wegen Urlaub eh am Weg in den Süden und konnte hier vorbeifahren so daß ich ihm eine neue Replik aufs Notebook legen konnte.
Weshalb die DB vollkommen geleert war, das war mir schon klar (siehe auch weiter oben in der Antwort an HRaq)
Für mich:
Merke 1: Nicht in Hektik machen.
Merke 2: Keine DB Kopien einer existierenden auf dem Server zu Testzwecken.
Merke 3: Ich bau in meine sämtlichen Agenten eine Prüfung ein , aus welcher Datenbank heraus die laufen dürfen, damit wäre das Problem auch verhindert worden. Bin noch am überlegen ob ich das "hart" im Code einbaue oder über ein Einstllungsdokument dann auslese.
Gruß Holcomb
-
Zu Merke 2, sollte das nicht heissen, keine Repliken zu Testzwecken? Echte Kopien (andere RepID und damit andere Identität) dürften kein Problem darstellen.
-
Zu Merke 2, sollte das nicht heissen, keine Repliken zu Testzwecken? Echte Kopien (andere RepID und damit andere Identität) dürften kein Problem darstellen.
Hi Semea,
No, habe ich nicht gemeint.
Stimmt schon wie ich es geschrieben habe. Es war eine echte Kopie (via Notes - Datenbank neue Kopie dann mit Option nur Gestaltung ohne Dokumente) ohne Dokumente wie beschrieben eben zu Testzwecken. Und eben leider am Server.
Normalerweise sind in der Datenbank (A) Dokumente die via LEi aus DB2 kommen, alle stark normalisiert.
Diverse Agenten erstellen dann Dokumente in einer Datenbank B in dem sie die normalisierten Daten aussendiensttauglich zusammenfassen. (Und diese Datenbak B wurde mir eben über Nacht durch einen Agenten geleert. )
Aber irgendwie muß ich ja auch Löschungen auf DB2 EBene mitbekommen (wir ddurch LEi auch übermittelt). Hierzu läuft in Datenbank A ein Agent, der nachsieht ob Dokumente die in Datenbank B vorhanden sind, auch noch in Datenbank A vorhanden sind (oder via LEI wieder aus A rausflogen).
Wenn das nicht der Fall ist, muß der Agent das jeweilige Dokument auch in Datenbank B löschen (damit A und B konsistent sind).
Jetzt ahnst DU sicher was passiert ist.
Ich hatte eine Kopie meiner produktiven A Datenbank gemacht, allerdings ohne Dokumente (weil ich die DB leer wollte).
Fatalerweise habe ich den Agenten vergessen der eben für das Löschen zuständig ist .
Nachdem der aber durch das DB Kopieren geschaltet war in meiner Testdatenbank, hat er fleissig das vergleichen angefangen und so sämtliche Dokumente aus meiner Datenbank B rausgelöscht (weil ja die Testdatenbank keine Dokumente enthielt).
Verhindern worden wäre es eben, wenn ich die Agenten so programmiert hätte, daß sie auch checken auf welcher DB sie laufen(z.B. anhand des Pfades, Dateinamens)
Gruß Holcomb
-
Ah, das ist jetzt klar. Stimmt, da müsste man den Agenten absichern, so dass er festsellten kann, ob die DBs zusammengehören, oder ob das ein anderes Set von Datenbanken ist.
-
Ah, das ist jetzt klar. Stimmt, da müsste man den Agenten absichern, so dass er festsellten kann, ob die DBs zusammengehören, oder ob das ein anderes Set von Datenbanken ist.
Jou. Sollte eigentlich guter Programmierstil sein, solche periodischen Agenten auch so abzusichern.
Könnte ja auch mal vorkommen, daß ein Kollege auf die Idee kommt eine Sever Kopie oder auch Replik anzulegen und nicht ahnt, welche periodischen Agenten damit auch betroffen sind die dann nachts los donnern.
Gruß Holcomb
-
Genau so ist es, kann man nicht genug betonen, vor allem, wenn die Applikation aus einem Set besteht.