Anzahl Dokumente in DB-Eigenschaften richtig?

[botschi]

Hallo,

ich habe eine DB mit ca 280.000 Dokumenten, die ca 13 GB Plattenplatz verbrauchen.
Jetzt wurde mit den Bordmitteln archiviert und alles ist super. Die archivierten Doks wurden aus der Quelle gelöscht und ein Log wurde auch angelegt.

Allerdings zeigt das Archiv 68.000 Doks und die DB 40.000 Doks an. Das sind insgesamt ja ca 100.000, aber wo sind die anderen Doks hin?
Es waren ja mal 280.000- laut der Anzeige in den DB-Eigenschaften jedenfalls. Also irgendwer lügt 

Kann mir jemand sagen, was da passiert ist? Ich muss mich natürlich rechtfertigen, weil sehr viele Doks (angeblich) weg sind...!

Matthias

[ata]

... hört sich komisch an - hast du denn ein Backup deines Originals - oder hast du das Produktiv so umgeschossen?

Wie hast du archiviert? Ansonsten wird es zu einem Rätselraten...

Toni

[botschi]

Tja, das mit dem Backup frag ich mich auch  . Es gibt sicher eins, aber wie aktuell das ist, weiss ich nicht.

Ich hab gestern die relevanten Doks mit dem Feld "ExpireDate" gefüllt und der Admin sollte die Archivierung aktivieren. Das hat er dann glaube ich per Programmdokument gemacht und mit compact -a (jedenfalls wurde um 03:09h archiviert).

Die Archivierungseinstellungen kann ich mangels Berechtigung nicht sehen. Ich habe aber darum gebeten, alle Doks zu archivieren, deren Ablaufdatum älter als 6 Monate ist.

Wie ich das sehe, werden aber NIEMALS Dokumente gelöscht, wenn sie nicht archiviert wurden. Also können die eigentlich nicht gelöscht sein. Deswegen fragte ich ja auch, ob die Anzeige in den DB-Eigenschaften stimmt.

Matthias

[botschi]

Tja, also wenn mir dazu irgendwer seine Erfahrungen berichten könnte, würde es mir vielleicht besser gehen... 

Können Doks gelöscht werden, obwohl sie nicht archiviert wurden?

Matthias

[guesswho]

würde es mir vielleicht besser gehen... 

vielleicht auch schlechter....

ja, Doks können natürlich gelöscht werden, auch wenn sie nicht archiviert sind...

ich hatte schonmal den Fall, dass bei der Archivierung aber so richtig alles in die Hose gegangen ist. Maildatenbank war hinterher fast leer und Archiv war auch fast leer.....

For those we have Backup-Systems. Ich bin dem Problem deshalb nicht weiter nachgegangen.

Jo

[botschi]

Und ich lehn mich vorher noch ausm Fenster "die Bordmittel sind garantiert sicher und erprobt. Die gibt es schon seit Jahren und man hat auch ein Log usw". Warum soll ich sowas nachbauen- dachte ich mir.

Toll, ich bin begeistert! 

Ein Backup haben wir auch, aber das löst mein Problem dann nur zur bedingt. Heute haben die User ja in der DB schon wieder gearbeitet, deswegen kann ich ja nicht einfach die Sicherung einspielen...

Man meint, man hat irgendwann alle Klippen schon mal gesehen und alle Häkchen gesetzt/nicht gesetzt, aber es gibt immer wieder neue Fallen...!

Matthias

[guesswho]

Hallo Matthias,

das sind keine Fallen, sondern Herausforderungen. Backup-DB und Produktiv-DB kannst du ja zusammenführen. Archivierung musst dann eben nochmals testen oder anders einrichten.

Jo

[koehlerbv]

Ich folge Jo: Sowas macht man nicht. Da kann dermassen viel schief gehen (egal, wie das System heisst) - kopieren, prüfen, löschen, und dann noch dermassen viele Dokumente ...
Bei sowas heisst es (nochmals: Egal, welche Software):
- Zugriff auf DB verhindern (bis auf am Archivierungsprozess Beteiligte)
- DB sichern
- Archivierung starten
- kontrollieren, kontrollieren, kontrollieren.

Was ich noch lieber mache: Die gesicherte DB archivieren und erst nach allen Kontrollen diese statt des bisherigen Originals einfügen.
Weiters: Ich habe bisher nur in äusserst schrägen Ausnahmesituationen erlebt, dass die DB-Properties eine falsche Anzahl von Dokumenten angegeben haben. Dem kannst Du in diesem Falle also trauen - Eure Archivierung ging ganz gründlich in die Hose.

Bernhard

[ata]

... das vermute ich auch...

Toni

[botschi]

Dann muss es ja an den Archivierungseinstellung liegen, die wir gemacht haben.
Ich gehe stark davon aus, dass die Archivierung mit den Bordmitteln (normalerweise) richtig tut? Wenn man es richtig konfiguriert... 

Wenn man archivieren möchte, dann will ich ja archivieren und nicht löschen! Warum werden die Dinger denn gelöscht? Dafür brauch ich doch die Archivierung dann nicht einzustellen...

Also so richtig traue ich dem Bordmittel nicht mehr.

Matthias

[Driri]

Kleine Anekdote zum Thema Archivierung :

Ein Kollege hatte zwei lokale Archivdatenbanken und wollte die zusammenführen. Also hab ich mir gedacht, ich mach das über die Archivierungsfunktion, dann brauch ich mich um Ordnerstruktur, etc. pp. nicht zu kümmern.

Also haben wir für DB A die Archivfunktion eingerichtet und DB B als Archiv angegeben. Die Archivierung hat dann auch einige Zeit gedauert und DB A war leer. Also haben wir fröhlich DB B geöffnet und waren etwas erstaunt, weil da auf den ersten Blick keine zusätzlichen Dokumente zu sehen waren. Meine Befürchtungen wurden dann von den DB-Eigenschaften bestätigt. Die ca. 10.000 Dokumente aus DB A waren defintiv nicht in DB B angekommen, aber wunderbar aus DB A gelöscht worden.

Offenbar war DB B korrupt. Die Datenbank ließ sich zwar öffnen, aber jeglicher Schreibversuch scheiterte (ACL korrekt, kein Schreibschutz auf OS-Ebene, etc.).

Tja, und wie wir EDVler so sind, gabs natürlich von DB A keine Kopie als Sicherung 

[botschi]

Ihr habt ja eine relativ grosse Anzahl von Usern, wie ich in Deiner Signatur sehe.
Wie archiviert ihr jetzt produktive Datenbanken und in welchen Abständen?

Bernhard hat durchblicken lassen, dass meine Anzahl an Dokumenten wohl nicht optimal ist. Die DB wurde noch nie archiviert, dies sollte die erste Archivierung seit Bestehen der DB sein...

Matthias

[Driri]

Da gibt es kein einheitliches Konzept.

Maildatenbanken werden z.Zt. noch gar nicht archiviert, außer die Benutzer arbeiten mit lokalen Archivdatenbanken. Wir sind gerade am Anfang der Planungsphase für eine serverbasierte Archivierung in dem Umfeld.

Bei den Anwendungsdatenbanken gibt es alles zwischen einem Volumen von unter 100 Dokumenten bis zu 100.000 Dokumenten. Von den großen Datenbanken haben wir schätzungsweise um die 20-30, nur diese betrachten wir auch für eine Archivierung.
Davon sind wiederum über die Hälfte zugekaufte oder im Auftrag entwickelte Anwendungen, die bereits einen Archivierungsmechanismus enthalten (Agents, die nach definierten Regeln "alte" Dokumente in eine Archivdatenbank verschieben). Die Archivierung findet hier i.d.R. einmal die Woche über das Wochenende statt.
Für die restlichen haben wir eigene Archivfunktionen geschrieben und wir starten diese zumeist auf Zuruf und nicht in festen Intervallen.

In den kleinen Applikationen arbeiten wir teilweise mit einer internen "Archivierung". D.h. "alte" Dokumente werden mit einem Archivflag versehen und verschwinden aus den regulären Ansichten.

[ata]

... wir archivieren nur mit eigens gestrickten Routinen - im Stile Dokument in die zweite DB schieben (CopyToDatabase), zur Sicherheit eventuell die ursprüngliche DocID des Dokumentes mitnehmen und dann erst das Originaldoc löschen  - und dabei auf die Responses achten...

Toni

[botschi]

Hätten wir mal auch machen sollen.
Ich hab mich aber explizit für die Bordmittel eingesetzt, was ich jetzt nicht mehr tun würde...

Danke für eure Erfahrungsberichte!


Matthias

[ata]

... good luck... 

Toni

[diali]

die Archivierung per Bordmittel funktioniert bei uns tadellos. Allerdings sichern wir jede Nacht die Mail- und Archiv-DB.

In eigenen DBs wird allerdings auch per Agent archiviert. Dabei gehen wir noch einen Schritt weiter wie Toni. Zuerst werden über eine Routine die Dokumente ins Archiv kopiert und in den archivierten Dokumenten die UniversalID des Original-Dokumentes hinterlegt. Eine 2. Routine geht dann nochmal über alle neu archivierten Dokumente und sucht in der Quell-DB die Original-Dokumente und erst dann werden diese gelöscht. Damit habe ich die Garantie, dass nur Dokumente gelöscht werden, die auch wirklich in der Archiv-DB sind.

[koehlerbv]

By the way: Bei CopyToDatabase bleibt die originale UNID erhalten (ausser, diese gäbe es schon in der DB).

Bernhard

[ata]

... und das kann durchaus passieren, denn wenn das Dokument schon mal drin war und nochmals reinkommen soll wird's eng - daher die Vorsichtsmaßnahmen - lieber auf Nummer sicher gehen...

Toni

[koehlerbv]

Vollkommene Zustimmung, Toni - lieber zehn Sicherheitsebenen mehr. als eine zu wenig. In meinen Archivierungsroutinen ist aber der Zustand "UNID wurde verändert" schon ein Warnsignal, was weitere Aktionen nach sich zieht. Aber auch wenn der Zustand "UNID erneuert" auftritt - das Dokument wird archiviert und dann der besonderen Aufmerksamkeit der Zuständigen zugeführt.

Bernhard