Das Notes Forum
Domino 9 und frühere Versionen => Administration & Userprobleme => Thema gestartet von: Gerhard am 07.06.04 - 09:08:09
-
Hallo zusammen!
Aus dem Urlaub zurück und schon wieder Probleme ! >:(
Folgende Fehlermeldung im Logfile:
07.06.2004 02:12:43 Fehler bei der Aktualisierung der Ansicht 'ToDelete' in funder\Produktion\TCAL_NEU.NSF: B-tree structure is invalid
Habe Fixup versucht, bringt aber nix. Kann alte Dokumente nicht mehr herauslöschen. Fehlermeldung: Hash-Index kann nicht verwendet werden da Index beschädigt !
Was tun ?
Sollte ich Strg-Shift-F9 betätigen um die Ansichten zu aktualisieren ?
Danke für die Hilfe !
-
Strg-Shift-F9 schadet nie - gib' dem eine Chance.
Ansonsten UPDALL. Falls das auch nicht greift, geht es ganz schnell über den Designer: Öffne dort die Ansicht mit dem defekten Index, mach irgendeine kleine Änderung (und nimm sie wieder zurück) und speichere die Ansicht. Der alte Index wird dafür komplett verworfen und ein neuer aufgabut.
HTH,
Bernhard
-
Hallo Bernhard !
Er meldet beim Fixup Ansicht 574 BTree defekt, aber im Designer finde ich keine Ansicht mit dem Namen 574 !
Was meint er damit ?
-
Ich habe was in der KBASE gefunden - welche Notes Version hat der Server?
Enabling Soft Deletions Results in Database Corruption - Typically in Mail Files
Problem:
Database corruption in some Notes/Domino R5 releases has been observed, typically in mail files. The following Fixup errors may be observed:
Database fixup process started
Performing consistency check on mail\filename.nsf...
Document NT00000AAA in database <path\filename.nsf> is damaged: Field length stored in document is incorrect (Field Body, Datatype 0001)
Document NT00000AAA in database <path\filename.nsf> has been deleted
or
Document NT00000AAA in database <path\filename.nsf> is damaged: Document has invalid structure
Document NT00000AAA in database <path\filename.nsf> has been deleted
or
Database is corrupt -- Cannot allocate space
When running Compact the following errors may be observed:
<path\db name> is damaged: Document has invalid structure
**** DbMarkCorrupt(DbFixup: invalid slot found, could not be repaired), DB=<path\db name> TID=[0458:0002-05A8] ***
Error compacting database <path\db name> 03:F5
Once the database is corrupted the following may also be observed:
NIF: DETECTED STORAGE CORRUPTION ERROR 'B-tree structure is invalid'
NIF: DETECTED STORAGE CORRUPTION ERROR 'Attempt to use an invalid database pointer'
Error updating view '($All)' in mail\filename.nsf: B-tree structure is invalid
NSFDbOpen: File '<path\db name>' is CORRUPT - Now Read-Only!
Clustering is not relative to this issue. The issue has appeared in both clustered and non-clustered environments.
Solution:
This issue has been observed on a number of Domino Servers, release 5.0.5 and later. Research has found that the issue occurs when the 'Allow Soft Deletions' option within the 'Advanced Database Properties' InfoBox is enabled. 'Allow Soft Deletions' will corrupt the database if soft deletions are enabled and an inplace compaction moves non-summary data to another location in the database.
This issue was reported to Lotus Quality Engineering, and was resolved in Domino 5.0.9 Server.
Excerpt from the Lotus Notes and Domino Release 5.0.9 MR fix list (available at http://www.notes.net):
Server - Database
SPR# IGOS4W6KD8 - Soft-deletions were causing inplace compaction to corrupt databases. This has been fixed in 5.0.9.
Workaround:
In some cases running Updall -R on the mail database, and then Fixup -F -J, does repair the existing corruption. To prevent the issue from occurring again disable the Soft Deletions feature for the database.
To access the 'Allow Soft Deletions' setting, select File, Database, Properties. When the InfoBox appears, switch to the Advanced tab (the "beanie" icon). The 'Allow Soft Deletions' checkbox is located half way down the list of settings.
In some cases where this issue has occurred the mail database had a background LotusScript agent which deleted documents. Further research is being done to review these agents. The issue may not be limited to cases where a background agent is deleting documents, but knowing whether or not a customer has such an agent may be helpful in troubleshooting this issue.
One example of the debug output when such an agent was running:
AMgr: Agent ('Purge Agent' in 'jdoe.nsf') printing: mail\jdoe.nsf
AMgr: Agent ('Purge Agent' in 'jdoe.nsf') printing: Deleting from mail\jdoe.nsf
**** DbMarkCorrupt(NoteOpenExtended: NoteID 000048EE NS (000033E9) or slot (00002D94) length invalid; Bucket 00000047 Slot 00000002), DB=F:\Lotus\Data\mail\jdoe.nsf TID=[012E:0002-012D] ***
-
Server Notes 5.07a for Windows/32
-
Falls Soft-Deletions in der betreffenden Datenbank aktiv sind, kann das die Ursache sein. Dann hast Du zwei Möglichkeiten:
1. Update auf mind. 5.0.9 oder
2. Soft Deletions ausschalten
Ich tendiere zu 2. Es gibt bessere Mittel, physikalische Löschungen durch User zu verhindern.
Andreas
-
Entsprechen die Soft Deletions dem Parameter
'wiederherstellbare Löschungen zulassen' ?
Der ist nämlich nicht angehakt!
Probiere nun updall und fixup mit den vorgeschlagenen Parametern!
Berichte in Kürze über Misserfolg/Erfolg!
-
Kriege bei Updall und Fixup nur immer wieder folgende Meldung auf der Server-Console:
NFSDBOpen: File TCAL_NEU.NSF is CORRUPT - Now Read-Only !
Es hat sich nix geändert, was kann man noch tun ?
Hilft evtl. ein Neustart des Servers ?
-
Noch mal zu meiner Frage zur Ansicht 547, wie finde ich denn die damit ich sie mit dem Designer bearbeiten kann ?
-
Kann das evtl. auch damit zu tun haben dass die DB knapp an der 1GB Marke liegt ?
Diese ist nämlich eine Kopie und da gibts ja doch irgendwelche Grössenbeschränkungen hab ich mal gehört !
Wo kann ich das denn nachprüfen ?
-
Unter Notes 4 gab es die Beschränkung auf 1 GB (Vorgabe) - 4 GB. Man konnte mit dem Compact Task das Limit von 1 GB auf max. 4 GB hochsetzen.
Da Du einen R5 Server hast, sollte das nicht gelten - ausser die DB hat noch das R4 Format (sieht man im Admin Client unter Dateien).
Die ID von der View kannst Du über den Designer Client ermitteln. Dort in der Gestaltungsübersicht mit der rechten Maustaste auf dem letzten Tab. Die Angaben dort sind hexadezimal, Du musst also Deinen Wert ggf. umrechnen.
Andreas
-
Das Interessante ist dass er die ToDelete-Ansicht bemängelt, diese es aber im Designer nicht gibt ! ???
-
Wenn ich im Designer den Agenten stoppen will indem ich das Hakerl wegtun möchte so kommt folgender Fehler, der kommt allerdings auch wenn ich ein Dokument aus einer Ansicht löschen möchte:
Der erweiterbare Hash-Index ist beschädigt und kann daher nicht verwendet werden !
Ob das nun mit einer Ansicht zu tun hat ist für mich schon fraglich !
Was meint Ihr ?
-
Das Interessante ist dass er die ToDelete-Ansicht bemängelt, diese es aber im Designer nicht gibt ! ???
Ist das evtl. ein Ordner? Irgendwo muss das Ding doch sein ???
-
Zum Hash-Index gibt es folgendes in der KBASE:
Domino R5 Error: "Extendible Hash Index Is Corrupt and Can't Be Used"
Problem:
A Domino 5.x server displays the following error:
"Extendible Hash Index is Corrupt and Can't be Used".
Solution:
This problem can happen when the Extendible Hash Table on any database becomes corrupt. The options to resolve a corrupted Extendible Hash Table are to:
Pull a new replica
Pull a new copy
Do a Copy style Compaction of the database
NOTE: In some cases the MAIL.BOX's Extendible Hash Table can get corrupted. When this happens, a Delivery Failure message is received by the sender of the mail message, such as: "Error transferring to server mail.box; Extendible hash index is corrupt and can't be used". In the case where the MAIL.BOX gets corrupted, do not follow any of the above procedures to repair the corruption. It is best to rename the MAIL.BOX and create a new one.
Supporting Information:
The Extendible Hash Index is a "list" of documents, design elements, etc. In summary, it takes a value (such as the name of a design element), and converts it into a "unique" value. Its value becomes the index into the "list". The reason it is extendible is because the "list" is allowed to grow bigger if need be. The index gets updated when something is added to it (such as adding a new design element).
The Extendible Hash Index does not replicate to other replicas of the database, so when the Extendible Hash Index becomes corrupt, the only known fixes are to make a new replica, new copy, or copy style compaction to force it to get rebuilt. Fixup and Updall will not repair the Extendible Hash Index. The corruption could vary from anything from the index being too large to part of it being overwritten.
-
Hallo Glombi !
Ich hab jetzt mal ne Kopie der DB mit Dokumenten gemacht, einstweilen kommt der Index-Fehler nicht mehr.
Werde nun schauen ob auf der Kopie der Agent läuft und keine Fehler mehr kommen, dann werd ich das Original löschen und die Kopie an die Original-Stelle zurückkopieren mit dem Original-Namen.
Mit etwas Glück funktionierts dann ohnehin wieder !
Danke einstweilen !
-
Ich konnte jetzt für ein paar Stunden diesen Thread nicht verfolgen. Zusammengefasst bedeuten die gesehenen Fehlermeldungen aber: Die DB ist in ihrer Struktur korrupt und kann höchstwahrscheinlich nicht repariert werden (was glücklicherweise bei Notes sehr selten ist). Kopieren ist - so das funktioniert - eine Variante. Vorher sollte aber geprüft werden, ob es von der DB nicht noch eine funktionierende Replik gibt (Backup, anderer Server, lokale Replik). Diese herzunehmen, um die korrupte DB zu ersetzen, wäre natürlich der einfachste Weg.
Ab und an funktioniert es übrigens auch, eine korrupte DB mit den eigentlich für den Server gedachten Programmen (nfixup.exe, ncompact.exe, nupdall.exe - für W32-Server) LOKAL zu reparieren. Einen Versuch istes zumindest wert. Die genannten Programme funktionieren in einer lokalen DOS-Box exakt genauso wie auf dem Domino-Server.
Bernhard
-
Hallo zusammen !
Ich hab es mit Neuer Kopie versucht, und siehe da, es funktionierte.
Habe die Kopie bereits produktiv in Betrieb und einstweilen noch keinen Fehler !
Beim Kopieren scheint Notes diesen Hash-Index neu anzulegen, daher gibts mit der Kopie kein Problem.
Alle anderen Aktionen wie updall,fixup,etc. hatten in diesem Fall nicht geholfen!
Danke an alle für die Hilfe !
-
Noch eine Idee, was vielleicht Probleme macht.
Du hast geschrieben, daß die DB sehr groß ist.
In der Noteshilfe im Designer steht, daß es eine Grenze für den Viewindex gibt.
How many documents are allowed in one view?
Maximum of 130MB for a view index
Du kannst ja mal im Log nachsehen, wie groß die größte Ansicht der betroffenen Datenbank ist.
Ich hab aber auch keine Ahnung was passiert, wenn ein Viewindex größer als 130 wird (ich habs hier auch schon mal ins forum gestellt, aber keine wusste eine Antwort)
Gruß, Holcomb
-
In welchem Log ist die Grösse der View denn zu finden ?
-
In der LOG.NSF unter Datenbank / Grösse.
-
Danke, alles klar.
Jetzt hab ich allerdings die alte Version schon gelöscht und kann nicht mehr nachsehen wie gross die Views waren.
Falls wieder mal Probleme mit dieser DB kommen werd ich hier mal nachsehen wegen der Grösse.
Danke vielmals !
-
Ich nehme an, dass die Maximalgrösse einer View in der DesignerHelp falsch angegeben ist - es sind wohl doch 128 GB statt 128 MB.
Woanders habe ich bislang nur höhere Werte gefunden, hier
http://www.geniisoft.com/showcase.nsf/DominoLimits (http://www.geniisoft.com/showcase.nsf/DominoLimits)
beschreibt Ben Langhinrichs auch die Berechnungsvorschrift:
Maximum of 128 GB for a view index.
(16 M page of B-tree space, 8kB/page)
Also limited by available disk space (2 GB on some UNIX platforms).
View containers in R5 databases (ODS 3.1 up) do not have a container size limit. The view size limit is now determined by the maximum number of pages that can be created which is 16,777,214. A page holds 8 KB so that means the maximum size for a view is 137,438,937,088 bytes (128 GB).
Was mich aber nach wie vor stutzig macht: Auch in der R6 DesignerHelp stehen wieder 130 MB.
Ein defekter Viewindex hätte auch nicht zum Kollaps der kompletten DB geführt - hier war wohl tatsächlich die DB an sich (ihre interne Struktur) im Eimer. Ein seltener Effekt, aber es kommt halt doch vor.
Gab' es eigentlich keine funktionierenden Repliken der DB mehr ? Hat sich der Fehler fortrepliziert ? Das wäre ungewöhnlich ...
Bernhard
-
Hallo Bernhard,
danke für die Info und den link.
Sehr interessant .
Und jetzt kommt dorch die Frage mit meinem Laienwissen.
Was macht dieser Binäre Baum im Zusammenhang mit Views?
Ich denke das hängt mit verschachtelten Arrays zusammen und daß Notes intern so auch die Views verwaltet.
Leider habe ich da zu wenig Wissen.
Doch der Titel hier im Thread ist ja auch, B Tress sturcture ist beschädigt.
Daher eben auch meine "vermutung" (oder eher stochern im Dunkkeln) ;-)
Aber was Notes intern angeht habe ich zuwenig wissen.
Aber in dem gelinkten Dokument wird ja auch bei der Berechnung.
der Viewgröße eben auf einen B Tree abgestellt.
Was jetzt das konkrete Problem angeht, so dürfte die Größe des viewindex dann allerdings hier eigentlich keine Probleme machen.
Gruß Holcomb
-
Was jetzt das konkrete Problem angeht, so dürfte die Größe des viewindex dann allerdings hier eigentlich keine Probleme machen.
Bei der DB-Grösse dürfte die Frage 130 MB oder 130 GB "filiosofisch" sein (heisst das jetzt so nach neuer deutscher Andersschreibung ?).
B-Tree structures werden von Notes (und ganz vielen anderen Apps) sowohl für Views als auch für FTIs verwendet. Da aber auch Hash codes angemeckert wurden, tippe ich weiter darauf, dass die ganze DB einen schweren Schuss weg hatte ...
Bernhard