isinteg meldet Fehler im Postfachspeicher

[Pipeline 11]

Hallo!

 

Ich habe per isinteg den Postfachspeicher überprüft (Aufgrund von einer

unerklärlich großen DB...) und dabei festgestellt, dass es einige Fehler

gibt.

 

Leider habe ich zu wenig Erfahrung mit Exchange, dass ich nun einfach n

isinteg -fix hinterher schicke.

 

Der Hinweis in der Isinteg.pri, dass der Shut down vom Information Store

nicht clean war, ist für mich sehr erschreckend!

Denn es gab keinen Ausfall, der das hätte verursachen können. Ich habe über

den ESM einfach nur die Bereitstellung des Postfachspeichers aufgehoben.

 

Unten hänge ich mal die Ausgabe von isinteg und die entsprechende

isinteg.pri Inhalte an.

Wäre klasse, wenn mir jemand die Bedeutung der Fehler erklären könnte und

mir mögliche Lösungen empfohlen würden.

 

<<< ISINTEG AUSGABE>

 

C:\Programme\Exchsrvr\bin>isinteg -s server01 -test alltests

 

Test Folder result: 0 error(s); 5 warning(s); 0 fix(es); 3410 row(s); time: 0h:18m:44s

Test reference count verification result: 0 error(s); 3 warning(s); 0 fix(es); 0 row(s); time: 0h:7m:19s

Now in test 19(Row Count/Dumpster Count) of total 19 tests; 100%complete.

 

> ISINTEG AUSGABE >>>>>

 

<<<<< ISINTEG.PRI INHALT>

Database name: Erste Speichergruppe\Postfachspeicher (Server01)

 

The Information Store has not been shut down clean.

Hence enabling the Row Count/Dumpster Count test.

You may also specify -test rowcounts (or) -test dumpsterref to run these

tests

Starting test 1 of 19, 'Search Folder Links'

. Time: 0h:0m:7s

Starting test 2 of 19, 'Global'

, number of rows = 1. Time: 0h:0m:0s

Starting test 3 of 19, 'Delivered To'

, number of rows = 20. Time: 0h:0m:0s

Starting test 4 of 19, 'Repl Schedule'

. Time: 0h:0m:0s

Starting test 5 of 19, 'Timed Events'

Timed event are : Expiration = 24,

, number of rows = 24. Time: 0h:0m:0s

Starting test 6 of 19, 'reference table construction'

. Time: 0h:5m:6s

Starting test 7 of 19, 'Folder'

Warning: MsgFolder 1 (Fid=0001-000000649B17, Mid=0001-00000003CD99,

Inid=0001-000000754185): Error JET_errRecordNotFound seeking to INID for

this MsgFolder Row

Warning: MsgFolder 38 (Fid=0001-000000649B17, Mid=0001-00000003CE26,

Inid=0001-0000007469C3): Error JET_errRecordNotFound seeking to INID for

this MsgFolder Row

Warning: MsgFolder 523 (Fid=0003-000000EB0005, Mid=0001-0000002C3517,

Inid=0001-00000031C5F9): Message has mismatched URLCompNameHashValue in

Database: HashValue calculated = 2069159198, value from Database

= -1219984451

Warning: MsgFolder 17331 (Fid=0003-000000EB0007, Mid=0001-000000682E85,

Inid=0001-0000006FAB9E): Message has mismatched URLCompNameHashValue in

Database: HashValue calculated = -1946497656, value from Database

= -1914417429

Warning: MsgFolder 1167 (Fid=0003-000000EB0041, Mid=0001-000000549B80,

Inid=0001-000000607028): Message has mismatched URLCompNameHashValue in

Database: HashValue calculated = -1112800483, value from Database

= -49354411

, number of rows = 2265. Time: 0h:18m:44s, number of warnings = 5

Starting test 18 of 19, 'reference count verification'

Warning: Attachment[0001-0000005F4840].AttachRefCt: Bad count - Prop(-1) <>

Calc(0)

Warning: Attachment[0001-0000005F4878].AttachRefCt: Bad count - Prop(1) <>

Calc(0)

Warning: Mailbox[0001-0000000062CE].MailboxContentCount: Bad count -

Prop(578) <> Calc(590)

. Time: 0h:7m:19s, number of warnings = 3

Starting test 19 of 19, 'Row Count/Dumpster Count'

Warning: table MsgFolder row count: Calc(302064) <> Prop(353266)

Warning: table Categ row count: Calc(213) <> Prop(21)

Warning: table Mailbox row count: Calc(35) <> Prop(38)

Warning: table ReplidMap row count: Calc(6) <> Prop(5)

Warning: DumpsterSize Calc(15889361501) <> Prop(15831373009)

. Time: 0h:0m:0s, number of warnings = 5

 

. . . . . SUMMARY . . . . .

Total number of tests : 19

Total number of warnings : 13

Total number of errors : 0

Total number of fixes : 0

Total time : 0h:49m:26s

< ISINTEG.PRI INHALT >>>>

 

Grüße, Pipeline

[Esta 114]

Hallo Pipeline,

 

vielleichthilft dir dieses hier weiter http://www.msexchangefaq.de/notfall/default.htm

 

So ohne das ich den Server vor Augen habe, kann ich dir schlecht was dazu sagen. Nach dem Protokoll sind es Warnungen und keine Fehler, was da angezeigt wird. Hast du eine aktuelle Sicherung? Solltest du haben, bevor du etwas wie isinteg -fix ausführst.

[schroeder750 10]

Esta hat absolut Recht, ohne Sicherung mache ich solche Fix-Vorgänge generell nicht.

Die einfachste und schnellste Lösung ist es, sich von der *.edb eine Kopie auf der lokalen Platte (sofern Platz) zu machen und diese umzubenennen in *.xxx oder so...

 

Die ist dann im Falle eines Falles superschnell wieder umbenannt und die vom isinteg zerpankte DB kann gelöscht werden.

 

Ich würde, auch wenn bisher nur Warnungen ausgegeben werden, auf jeden Fall den isinteg drüberlaufen lassen.

Dann hast Du eine saubere Datenbank und falls danach Meldungen kommen sollten, daß Mails o.ä fehlen, kannst Du diese notfalls aus der vorher wegkopierten DB wieder herstellen. Wenn Du ganz sicher gehen willst, ziehst Du, je nach Größe und Useranzahl, vorher mit dem Exmerge Kopien der einzelnen Postfächer in *.pst-Dateien...

Die sind dann dem jeweiligen User mit Datenverlust schnell zur Verfügung gestellt.

 

Eine Alternative wäre auch folgendes:

 

Wenn Du der jetzigen DB nicht mehr traust, dann erstelle eine zweite DB in der gleichen Speichergruppe und verschiebe alle User in aller Ruhe in diese neue DB. Beim Verschieben wirst Du dann evtl. Fehler bekommen, bei den Usern, deren Daten in einem korrupten Teil der DB liegen. Die anderen Postfächer sind dann aber zumindest mal auf der sicheren Seite. Danach kannst Du immer noch den isinteg über den "Rest" der originalen DB laufen lassen.

 

Grüsse

 

schroeder750

[Pipeline 11]

Hallo!

Danke für die Antworten.

 

Also eine tagesaktuelle Sicherung haben wir natürlich!

Gestern haben nwir die Warnigs mit "-fix" beseitigt. Und eseutil /mh meldete einen Clean Shutdown der DB.

Also sind dahingehend meine Sorgen gelöst.

 

Nur bin ich halt immernoch verwundert über eine DB größe von 16GB (edb + stm),

obwohl die Postfächer weniger als 2GB einnehmen.

 

Online Defrag meldet nur 400MB freien platz. Eseutil /ms immerhin 1GB in der STM.

Hat jemand einen Vorschlag, wie ich die DB kleiner bekomme?

Das übliche (Unnötiges löschen, Aufbewarhungzeit runter...) ist getan.

 

 

@Schroeder750

Wahrlich traue ich der DB nicht ganz. Und zwar weil dieser extreme Größenunterschied besteht.

 

Kann man den von dir beschriebenen Vorgang, also das Verschieben der Postfächer in eine neue DB gefahrlos machen?

Hast du einen Link auf eine Anleitung dafür?

 

Grüße, Pipeline

[Tallasar 10]

Hallo,

 

hattest Du viel Datenbewegung in dieser Datenbank?

Abhilfe würde eine Offline Defragmentierung helfen, die ich an einem Wartungstag nach einer aktuellen Datensicherung ausführen würde.

 

Gruß Tallasar

[Pipeline 11]

Hallo Tallasar!

 

Datenbewegung, gab es denke ich nicht mehr als gewöhnlich.

Kann ich das irgendwie überprüfen, oder nur in der Nachrichtenverfolgung.

 

Die DB wächst seit März eigentlich immer stätig, obwohl die Postfächer die ca auf gleichem Niveau bleiben (zusammen unter 2GB!!).

 

Die DB füllt sich etwa mit 300MB die Woche! (EDB+ STM, und freier Speicher Wert der Online-Defrag: ID1221)

 

Grüße aus Hamburg

Pipeline

[Tallasar 10]

Mit Datenbewegung meinte ich zum Beispiel ob viele Benutzer entfernt wurden! Das habe ich zu schlecht ausgedrückt!

Wie ist das Verhältnis der Größe der EDB zur STM Datei?

Die 16GB beziehen die sich nur auf die erste Speichergruppe oder rechnest Du den öffentlichen Ordner hinzu?

 

Gruß Tallasar

[Pipeline 11]

Okay nun hab ichs verstanden, Benutzer wurden keine entfernt.

 

EDB ist ca 14,9

STM ist ca 1,9

 

Es bezieht sich alles auf den Postfachspeicher der erste Speichergruppe.

 

Grüße aus Hamburg

Pipeline

[Tallasar 10]

Das Verhältnis ist auch ok!

 

Also mein nächster Schritt wäre die Offline Defragmentierung. Wie gesagt würde ich Dies aber erst nach einer funktionierenden Datensicherung und an einem Offlinetag machen.

 

Oder die andere Möglichkeit wäre das was schröder750 meinte, einen zweiten Datenspeicher aufmachen und alle Postfächer verschieben, dann wäre es auch bereinigt.

 

Gruß Tallasar

[Pipeline 11]

Jup, Offline Defrag ist am WE dran.

 

Nochmal zu dem anderen Vorschlag ist mir noch ein kleines Detail aufgefallen:

wir haben die Standard Edition, das heisst doch, dass man nur einen Postfachspeicher je Speichergruppe nutzen kann.

Könnte ich also auch eine zweite Speichergruppe mit neuem Postfachspeicher erstellen und die Daten dahin schieben?

[Tallasar 10]

Nein, da in der Standardversion gibt es nur eine Speichergruppe mit einem Informationstore und einem publicstore!

 

Also bleibts dann bei der offline defrag!

 

Gruß Tallasar

[Pipeline 11]

Hallo!

 

Wollte euch ja wenigstens das Ergebnis noch mal mitteilen.

Offline Defrag hab ich erst in der Woche gemacht, hatte erst noch das SP1 für Exchange installiert.

 

Nun ist die DB um ca 1,5GB kleiner.

Da das immernoch viiiiiel zu groß ist werde ich per exmerge mal die Postfächer in PST Dateien exportieren um erstmal zu sehen wie groß die werden.

Dann werde ich evtl eine neue DB aufbauen.

 

Kann mir dazu vielleicht noch jemand wichtige Tipps, Hinweise oder gut Anleitungen nennen?

Habe das noch nie gemacht! (Werde es natürlich erstmal auf einem Testsystem durchfürhen...)

[GuentherH 61]

HI.

 

Gib einfach bei der Boardsuche einmal Exmerge ein, und du bekommt genügend Beiträge.

 

LG Günther

[Pipeline 11]

Okay, darauf hätte ich auch selbst kommen können... :-)

 

Noch ein wichtiger Nachtrag:

Wir haben einen Adaptec 2010S Ultra320 SCSI Raid Controller. In dem Tool dazu ist der Schreibcache deaktiviert.

Kucke ich aber in den Gerätemanager so sehe ich beim virtuellen "Raid SCSI Disk Device" das der Scheibcache aktiv ist!

Und ich kann dort den Haken auch nicht entfernen!!

 

Kennt zufällig jemand diesen Kontroller, oder kann mir sonst einen Tipp geben?

Denn das soll ja recht tötlich für die DB sein, auch meckert der Server beim booten diverse Male das er den Schreibcache nicht deaktivieren kann

und das evtl. Daten verlorengehen bzw beschädigt werden.

 

Dies mal habe ich übrigens erst anderweitig recherchiert (google und Adaptec Seite) aber leider nichts finden können!!

[weg5st0 10]

Hi,

 

Thema Schreibcache: Mit Batteriemodul kannst du den Cache aktiv schalten.

 

Ausserdem würde ich mich auf die Controller-Konfig verlassen!