Updall forcieren

[PeterD2]

Wir haben eine sehr große Korrespondenz-Datenbank im Einsatz (>30 GB) bei der es jetzt offensichtlich die Ansichtsindizees zerschossen hat, da sich bestimmte Ansichten einfach in endlicher Zeit nicht mehr öffnen lassen. Nun wollte ich mittels "updall -v" die Ansichten wieder neu aufbauen lassen (bzw. nupdall aus der OS Konsole bei gestoptem Server), aber der Prozess dümpelt mit max. 5% CPU Leistung so vor sich hin und wird einfach nicht fertig. Nach der ganzen Nacht sind gerade zwei Ansichten erledigt. Wie kann ich dem Prozess ein wenig Dampf machen, damit er die CPU mal richtig ausnutzt und wir die Datenbank heute mal wieder in Betrieb nehmen können? Ach ja: Domino 6.5.2 unter Windows 2000

Schöne Grüße

Peter

[DigitDani]

Hi Peter,

mit einem updall -v baust Du die Ansichten aber nicht neu auf, sondern bringst sie nur auf den aktuellen Stand. Wenn Du den Index komplett neu aufbauen willst, musst nen updall -r machen.

So ein updall ist meines Wissens aber nicht nur CPU- sondern auch vor allem Plattenlastig. 5% CPU-Last sind allerdings tatsächlich etwas wenig... sollte es tatsächlich die Ansichtsindizes zerschossen haben, solltest Du entweder noch vorher einen fixup drüberlassen oder wie gesagt den ganze Index wegwerfen und neu aufbauen.

Bei einer so großen DB solltet ihr euch auch vor allem mal Gedanken darüber machen, ob die existierenden Ansichten erstens alle benötigt werden und falls ja, zweitens versuchen die Ansichten dann wenigstens so schlank wie möglich zu halten.

Wieviel Dokumente hat denn die DB? Wie groß sind die größten Ansichten in der DB (in KB)?

cu

Daniel

[PeterD2]

Ja klar, Du hast natürlich Recht: updall -r

In der Datenbank sin derzeit ca. 470.000 Dokumente, die Ansichtsindizes belegen von den mittlerweile 35 GB Plattenplatz alleine ca. 9 GB. Dummerweise sind die größten unter Ihnen (eine hat alleine 1,6 GB) die am meisten benötigten, da es sich dabei um versteckte Ansichten handelt, die von Skripten in anderen Datenbanken abgefragt werden.

Ciao
Peter

P.S: Die Datenbank hat eine Art "Überlauf", bei dem alle Dokumente ab einem bestimmten Alter in eine andere DB "überschwappen". Sie hält sich also ungefähr bei der heutigen Größe. Funktioniert, ist aber unglaublich unhandlich.

[DigitDani]

Hi Peter,

heißt das nun, Du hattest Dich nur im Thread verschrieben oder hast Du wirklich nen updall -v gemacht?

Ich kann Dir als Vergleich nur einmal von unserer größten DB berichten (20GB, 3.4 Millionen Docs, größter Index 1GB - insgesamt 2GB). Ein updall -r dauert auf diese DB knapp 4 Stunden (offline, bei heruntergefahrenem Server!) (Server: Compaq DL380, 2x Xeon 3,2GHz HT, 4GB RAM, RAID 1+0, RAID-Controller mit 320MB Lese-/Schreibcache 50/50).
Macht absolut null Probleme das Ding.

P.S: Die Datenbank hat eine Art "Überlauf", bei dem alle Dokumente ab einem bestimmten Alter in eine andere DB "überschwappen". Sie hält sich also ungefähr bei der heutigen Größe. Funktioniert, ist aber unglaublich unhandlich.

Also eine Art Archivierung? Das halte ich bei solch einer DB auch für sehr sinnvoll, meinst Du nicht man kann an dieser Stelle noch etwas optimieren um die eigentliche DB schlanker zu bekommen? Bei einer solchen Größe und der Anzahl von Docs drängt sich mir auch die Vermutung auf, dass die DB viele Attachments und auch evtl. einen Volltextindex hat, oder?

Aber gut, das eigentlich Problem war ja nun der updall. Schonmal mit -r versucht? Evtl. vorher auch mal den Index per Hand weglöschen.

[PeterD2]

Au Mann! 3,4 Mio. Docs! Davon kann ich ja nur träumen! 
In unserer Datenbank sind ganz einfache Briefe und Termine. Die Briefe sind jeweils etwa eine DIN A4 Seite lang und enthalten keinerlei Attachments, allerdings einige  Steuerinformationen (diese unsäglichen All-In-One Felder nach dem Muster "Hans#Müller#Hauptstr.#13#mueller@irgendwas.de#..."). Dadurch entfallen auf jedes Dokument so ca. 70 kB
 
Das mit dem updall -v war kein Schreibfehler, ich wollte zunächst aus Zeitgründen die vorhandenen Indizes einfach aktualisieren, ohne dabei die Volltextindizes zu berücksichtigen. Aber gleich Tabula Rasa zu machen, die alten Indizes wegzuwerfen und alles neu aufzubauen, hat es letztlich nach zwei Nächsten Rumgerödel auf der Windows-Konsole bei ausgeschaltetem Server gebracht. Nun funktionieren die anderen Datenbanken wieder, die auf die versteckten Ansichten dieser DB zugreifen.

Ich würde die Datenbank (und vor allem deren Indizes) ja liebend gerne verkleinern, habe aber keine Ahnung wie. Die Ansichten sind alle 'flat', also keine Kategorien. Sie enthalten allerdings viel Text, Dank der oben genannten "All-In-One" Felder, die hier die Daten für die anderen Datenbanken und deren DBlookups liefern.

Eine 35 GB Datenbank wie die unsere ist einfach bei Störungen viel zu unhandlich. Die Wiederherstellungszeiten, bei ähnlicher Hardware wie bei Euch, absolut inakzeptabel.

Ciao
Peter

[Glombi]

3,4 Mio Dokumente und dann nur 20 GB. Das ist aber erstaunlich wenig.
Ich hätte allerdings ein ungutes Gefühl, soviele Dokumente in einer Notes DB zu haben. Wenn da mal eins wegkommt, geht die Sucherei los 

Andreas

[Semeaphoros]

Wenn dann mal folgendes Stelleninserat auftaucht, dann wissen wir, worum es geht:


Wühlmaus gesucht


 

[DigitDani]

hehe 

Genau! Das könnte dann mit großer Wahrscheinlichkeit eine Stelle von uns sein 

Als purer Betreiber dieser DB muss ich mir zum Glück keine großen Gedanken über den Nutzen machen solange sie einwandfrei läuft. Ich weiß nur, dass es sich um die LogDB einer Webapplikation die wir betreiben, handelt (laut Aussage von IBM wohl die derzeit größte, existierende).