Bei Exchange ist nur die "pub1.edb" da

[frisch 10]

Hallo Gemeinde,

ich habe schon brav die Suche benutzt, aber leider keinen Eintrag zu meinem Problem gefunden. Deswegen frage ich jetzt mal.

 

Bei einem Kunden ist in der Exchange Datenbank die pub1.stm "verschwunden" und in der DaSi wurde die Datenbank immer schön übersprungen (kein Zugriff... vielleicht, weil offen). Das heisst, die Datei ist wirklich weg.

 

Noch vorhanden ist allerdings die pub1.edb !

 

Besteht irgendwie die Chanche an die Daten der pub1.edb heranzukommen?

Dort liegen nämlich (logischerweise) die ganzen Kundenadressen und Termine, die natürlich sehr wichtig sind.

 

OS=Win2000, SP4 und Exchange2000 (ich glaube noch ohne SP)

 

einen schönen Gruss

Jens

[GuentherH 61]

Hi.

 

Auch wenn die stm Datei fehlt, kannst du den Postfachspeicher bereitstellen. Es kommt dann eine Meldung, ob eine neue Stream Datei erstellt werden soll.

 

Wenn sich der Postfachspeicher nicht bereitstellen läßt, dann mit eseutil einmal auf Konistenz überprüfen.

 

Lg Günther

[Tspeed 10]

Habe leider nur folgendes gefunden:

 

Der Informationsspeicher besteht aber immer aus beiden Daten. Die EDB und STM Datei gehören untrennbar zusammen und können weder getrennt genutzt noch von unterschiedlichen Versionsständen gestartet werden.

 

:shock: :(

[frisch 10]

Danke ersteinmal für die schnelle Antwort.

 

Das mit der Untrennbarkeit "fühlte" sich für mich zunächst auch so an.

 

@ Guenther: bisher konnte ich die DB erst wieder starten als beide Dateien (edb. und stm.) verschwunden waren. Dann kommt die Abfrage ob die öffentliche DB neu erstellt werden soll. Wenn ich dann ja klicke ist die DB auch da und natürlich leer.

Hast Du das schon einmal nur mit der .edb hinbekommen?

 

Gruss

Jens

[Rainer Smetan 10]

Fühle mich nicht wirklich "fit" genug um hier Tipps zu geben, aber vielleicht hilft Dir ja dieser Link: http://www.msexchangefaq.de/notfall/desaster2k.htm

 

Hope this helps....

[GuentherH 61]

Hi.

 

Versuche einmal folgendes:

 

Als Beispiel - Name deiner DB sei priv1.edb, Servername = Exchange

 

eseutil /p priv1.edb /createstm

dann unbedingt ausführen

isinteg -s Exchange -fix -test alltests

 

Lg Günther

[frisch 10]

Hallo Guenther,

werde ich heute Abend auf jeden Fall probieren. Danke für den Tip.

Sollten die Exchange-Dienste angehalten werden oder geht das alles im laufenden Betrieb?

 

Gruss

Jens

[Rainer Smetan 10]

ESEUTIL

 

Dieses Programm ist Bestandteil von Exchange 5.5 und Exchange 2000 und dient dazu, eine bestehende Datenbank zu prüfen, zu reparieren, zu defragmentieren und vieles mehr. Beim Aufruf von ESEUTIL ohne Parameter wird eine Hilfe ausgegeben. ESEUTIL liegt im BIN-Verzeichnis des Exchange Programmpfades und arbeitet zeichenorientiert.

 

ESEUTIL arbeitet auf einer recht tiefen Ebene (seitenorientiert) der Datenbank und ist ein letztes Mittel, wenn alle andere versagen.

 

Ich rate niemanden dieses Programm ohne triftigen Grund aufzurufen. Bei einigen Aktionen braucht ESEUTIL nicht nur viel Hauptspeicher, sondern auch sehr viel Platz auf der Festplatte. Die CPU-Last ist ebenso sehr hoch, d.h. auf Servern die nicht "nur" Exchange machen, kann es sinnvoll sein, den Aufruf in die Abendstunden zu verlegen. Die Laufzeiten können je nach Größe der Datenbank mehrere Stunden betragen.

 

ISINTEG

 

ISINTEG ist bei Exchange 5.5. das Programm um die logische Konsistenz zu prüfen. Hierbei wird nicht die Datenbank auf Basis der einzelnen Datenbankseiten kontrolliert, sondern der logische Aufbau der Daten. ISINTEG erkennt daher also Nachrichten, die nicht mehr verknüpft sind oder verweise auf Anlagen, die nicht mehr existieren und einige andere Fehler, die sich im laufenden Betrieb durch Softwarebugs einschleichen aber meist nicht auffallen oder stören.

 

ISINTEG ist daher nicht so "scharf" wir ESEUTIL, da es keine Seiten löscht. ISINTEG geht aber davon aus, dass die Datenbanken konsistent sind, d.h. bei einem -1018 Fehler oder ähnlich gravierenden Problemen muss die Datenbank erst konsistent gemacht werden.

 

ISINTEG korrigiert mit der Option "-FIX" alle vorgefundenen Fehler. Dies sollte in der Regel keine Probleme darstellen, aber eine Sicherung der Datenbank ist ebenso anzuraten wie der erste Durchlauf ohne FIX und eine genaue Analyse der erkannten Fehler.

 

Häufig wird behauptet. ISINTEG wäre in Exchange 2000 nicht mehr vorhanden oder integriert, aber das stimmt so nicht. Mit Exchange 5.5 war ISINTEG noch notwendig, um eine Datenbank von einem Restore mit dem Befehl "ISINTEG -patch" zu patchen. Diese Funktion ist in Exchange 2000 nun mit eingebaut. Aber die Diagnose und Reparaturfunktion von ISINTEG ist weiterhin per Kommandozeile verfügbar. Im Gegensatz zu ESEUTIL muss bei ISINTEG und Exchange 2000 der Informationsspeicher gestartet sein. Nur die betroffene Datenbank muss "offline" sein.

 

....

[frisch 10]

wow, geht ja schnell bei Euch :)

 

am Freitag Abend werde ich noch einmal zu dem Kunden fahren und einiges probieren. Seit gestern habe ich auch ein Image auf einer HDD. So kann nichts schlimmes passieren.

 

Gruss

Jens

[frisch 10]

Hi.

 

Versuche einmal folgendes:

 

Als Beispiel - Name deiner DB sei priv1.edb, Servername = Exchange

 

eseutil /p priv1.edb /createstm

dann unbedingt ausführen

isinteg -s Exchange -fix -test alltests

 

Lg Günther

 

Millionenfacher Dank von mir und meinem Kunden!

Das wars!

Tolles Forum!

 

ich hoffe, ich kann auch mal jemanden so schnell helfen.

 

Gruss

Jens