Archiv-DB noch zu retten?

[schroederk]

Hallo,

ich habe die Archiv-DB eines Mitarbeiters, die sich nicht mehr öffnen lässt.
Fehlermeldung des Clients:

Datenbank ist zu groß geworden. Komprimieren Sie oder Replizieren Sie...

Ich habe bisher versucht (in der Reheinfolge):
Lokal:
- lokales nfixup, ncompact (-c), nupdall
- Anzeige DB-Eigenschaften
- neue Replik erstellen
- Datei auf den Server kopiert
Server:
- fixup, compact (-c), updall, convert, dbmt
- Anzeige DB-Eigenschaften, Zugriffsberechtigungen

Alle versuche hatten dieselbe Meldung zur Folge: "Datenbank zu groß..." bzw. auf der Console:
"Database compactor error: Database (.nsf) has grown too large; use compact to reduce the file size or use File New Replica to recreate your file with larger capacity."

Lokal:
- Über einen Agent alle Dokumente in eine neue kopieren

Code

     Sub Initialize
        Dim s As New notessession
        Dim srcdb As New notesdatabase("","badfile.nsf") 'replace "badfile.nsf" with the name of the corrupted db
        Dim newdb As New notesdatabase("","newfile.nsf") 'replace "newfile.nsf" with the name of the new db
        Dim coll As notesdocumentcollection
        Dim doc As notesdocument
        Set coll=srcdb.alldocuments
            Dim i As Integer
            For i = 1 To coll.count
                Set doc=coll.getnthdocument(i)
                Call doc.copytodatabase(newdb) 
            Next 
End Sub 

Fehlermeldung: "database has not been opened yet"

Hat noch jemand eine Idee, wie ich die DB retten kann?

[Glombi]

Welches ODS hat die DB denn?

Von IBM gibts die folgenden Tipps:
http://www-01.ibm.com/support/docview.wss?uid=swg21102305

Ich hatte das Problem bei einer DB und habe es nicht mehr hinbekommen...


Andreas

[schroederk]

ODS ist laut Anzeige auf dem Server 43.
Wobei wir aber eigentlich schon auf 8.x waren, als der Mitarbeiter angefangen hat (und damit die DB erstellt wurde) und Create_R8_Databases=1 mit Sicherheit gesetzt war.
ODS müsste also eigentlich mind. 48 sein, daher weiß ich nicht, ob ich der Anzeige vertrauen soll.

Die Tipps auf derm IBM-Seite entsprechen ja grundsätzlich dem, was ich schon gemacht habe.

Die Dateigröße wird im Dateisystem übrigens mit 3,5GB angegeben.

Auf der Console wird noch etwas mehr angezeigt, das nicht im Log gespeichert wird:

[1A84:0002-1B10] --- extending well beyond 64 gig: high 0x6F Low 0x3C0A3E00 DB D:\Domino\data\test\badfile.nsf ---
[1A84:0002-1B10] [01]: 00000000F49803B8 [load addr 0x0000000067f30000]   nnotes! FileSeekOSFD +0x1a8
[1A84:0002-1B10] [02]: 00000000F498484F [load addr 0x0000000067f30000]   nnotes! NSFFileSeekReadC +0x2af
[1A84:0002-1B10] [03]: 00000000F4CC8AB6 [load addr 0x0000000067f30000]   nnotes! BITMAPReadPage +0x696
[1A84:0002-1B10] [04]: 00000000F4BBCB76 [load addr 0x0000000067f30000]   nnotes! UBMSetupPage +0x676
[1A84:0002-1B10] [05]: 00000000F4BBE568 [load addr 0x0000000067f30000]   nnotes! UBMReplaceBuffer +0x518
[1A84:0002-1B10] [06]: 00000000F4BBF3C3 [load addr 0x0000000067f30000]   nnotes! UBMClock +0x873
[1A84:0002-1B10] [07]: 00000000F4BBFEFC [load addr 0x0000000067f30000]   nnotes! UBMPinExtended +0x4ac
[1A84:0002-1B10] [08]: 00000000F4BC0FE2 [load addr 0x0000000067f30000]   nnotes! UBMPinA +0x82
[1A84:0002-1B10] [09]: 00000000F4CCAD57 [load addr 0x0000000067f30000]   nnotes! DbPinBitmap +0x4f7
[1A84:0002-1B10] [10]: 00000000F4AEA89B [load addr 0x0000000067f30000]   nnotes! RebuildBDT +0x5fb
[1A84:0002-1B10] [11]: 00000000F4B09AE4 [load addr 0x0000000067f30000]   nnotes! DbFixup +0xcf4
[1A84:0002-1B10] [12]: 00000000F4C999E6 [load addr 0x0000000067f30000]   nnotes! DoFixup +0x886
[1A84:0002-1B10] [13]: 00000000F4C9DEED [load addr 0x0000000067f30000]   nnotes! DbLoad +0x351d
[1A84:0002-1B10] [14]: 00000000F49B5449 [load addr 0x0000000067f30000]   nnotes! NSFDbOpenExtended6 +0x7cf9
[1A84:0002-1B10] [15]: 00000000F49B8BBB [load addr 0x0000000067f30000]   nnotes! NSFDbOpenExtended3 +0x9b
[1A84:0002-1B10] [16]: 00000000F49B995E [load addr 0x0000000067f30000]   nnotes! NSFDbOpenExtended +0x5e
[1A84:0002-1B10] [17]: 00000000F4A119B3 [load addr 0x0000000067f30000]   nnotes! NSFDbOpen +0x23
[1A84:0002-1B10] [18]: 000000003FB351BE [load addr 0x00000000021a0000]    ndbmt! unknown +0x3d9951be
[1A84:0002-1B10] [19]: 000000003FB35EE7 [load addr 0x00000000021a0000]    ndbmt! unknown +0x3d995ee7
[1A84:0002-1B10] [20]: 000000003FB3607C [load addr 0x00000000021a0000]    ndbmt! unknown +0x3d99607c
[1A84:0002-1B10] [21]: 000000003FB35F18 [load addr 0x00000000021a0000]    ndbmt! unknown +0x3d995f18
[1A84:0002-1B10] [22]: 000000003FB365F6 [load addr 0x00000000021a0000]    ndbmt! unknown +0x3d9965f6
[1A84:0002-1B10] [23]: 000000007781652D [load addr 0x0000000069f20000] kernel32! BaseThreadInitThunk +0xd
[1A84:0002-1B10] [24]: 000000007794C521 [load addr 0x000000006a040000]    ntdll! RtlUserThreadStart +0x21

Vielleicht kann man mit einem Hexeditor etwas tricksen, dass Domino glaubt, die Datei ist wirklich kleiner als 64GB?

[Ralf_M_Petter]

Ist das ein 64 bit oder ein 32 bit Domino?

[schroederk]

Ein 64bit Domino.

[Ralf_M_Petter]

Nein leider weiß ich auch keine Lösung dazu. Vor allem wenn die Datenbank gar nicht groß ist. Musst du wohl oder übel restoren.

[schroederk]

Ein Restore gibts leider nicht, da der Kollege das Archiv lokal erstellt hat. (Alles älter als 45 Tage  )
Ich versuche seit einer Ewigkeit eine firmenweite einheitliche Archiv-Lösung zu bekommen, aber da sind die Taschen wie zugenäht.

Ob es Sinn macht, hierfür einen PMR aufzumachen? Wahrscheinlich bekomme ich dann nur die bekannten Standard-IBM-Seiten zugeschickt. 

[alexhe]

compact -replica schonmal probiert?

[Pyewacket]

ich würde es mal mit einem compact -D versuchen, eventuell kannst du danach die Dokumente rüberkopieren.
Falls beim 'Anfassen' der DB gleich ein fixup loslegen sollte, dafür hatte einer unserer Kunden ein Tool von der IBM
welches das Dirty-Bit zurücksetzt so dass für Notes die DB ordentlich geschlossen scheint.

[schroederk]

Ich hab mal ein Ticket bei IBM aufgemacht und hoffe auf professionelle Hilfe mit Wuderwerkzeugen und magischen Tricks 

[schroederk]

IBM hat natürlich erstmal gesagt, dass ein DB-Recovery vom Support nicht abgedeckt ist, aber sie haben sich die DB dennoch mal angeschaut.
Leider können die wohl auch nichts tun, um die DB zu reparieren, aber sie haben auf ein externes Tool verwiesen, dass das können soll.

Kennt jemand das Tool von www.nsf.repair ?

[hallo.dirk]

IBM hat natürlich erstmal gesagt, dass ein DB-Recovery vom Support nicht abgedeckt ist, aber sie haben sich die DB dennoch mal angeschaut.
Leider können die wohl auch nichts tun, um die DB zu reparieren, aber sie haben auf ein externes Tool verwiesen, dass das können soll.

Kennt jemand das Tool von www.nsf.repair ?

Hast du das mittlerweile getestet?
Wir stolpern gerade über einen identischen Fall.

[schroederk]

Ja, wir haben das Tool gekauft und ausprobiert.
Grundsätzlich funktionierte das Tool wohl soweit, auch wenn es eine Ewigkeit dauert.
(Für die 3,6GB über 6 Stunden)
Es hat dann den größten Teil der Dokumente gefunden und angezeigt (Größtenteils, da einige nicht lesbar und mit Sonderzeichen)

Allerdings ist mein Notes-Client dann jedesmal kurz vorm Ende (7300 von 7600 Dokumente) gecrashed, wenn ich die neue DB schreiben wollte.

Ich habe daraufhin den Support angeschrieben, die auch schnell geantwortet haben.
Ich habe das Archiv zusenden sollen und sie haben wir dann die reparierte Version einige Tage später zurückgeschickt.

Danach habe ich das Tool aber nicht mehr benötigt, somit keine weiteren Erfahrungen.

[eno_040]

... moin!

ich hatte ein ähnliches Problem, (unsere iQ.Suite Datenbank (Spam-Quarantäne) wurde übers Wochenende über 64 GB groß)) allerdings ist es nun zwei Jahre her, ich versuche mich zu erinnern:

Versuche für diese Datenbank eine Serverarchivierung einzurichten, wichtig ist, dass Du eine Regel einstellst, die dafür sorgt, dass nicht der gesamte Inhalt archiviert wird, sondern nur so viele Mails, dass Du wieder auf die Datenbank zugreifen kannst.

Seit dem setze ich auf jede Datenbank, die wachsen kann, eine entsprechende Quota!!

Gruß

Engin