Jump to content

Store.exe kann nicht gestartet werden


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Diese beiden Fehler habe ich im EventLog, sonst sind keine von heute zu finden. Die erste im Anwendungsprotokoll und die zweite im Protokoll Dateireplikationsdienst.

 

Nein, die Platte ist nicht voll. Und die Datenbank ist auch nur 7GB gross....

 

*****************************************************************.

 

Ereignistyp: Fehler

Ereignisquelle: MSExchangeSA

Ereigniskategorie: MAPI-Sitzung

Ereigniskennung: 9175

Datum: 05.01.2006

Zeit: 12:47:12

Benutzer: Nicht zutreffend

Computer: EXCHANGE

Beschreibung:

Der MAPI-Aufruf 'OpenMsgStore' ist mit dem folgenden Fehler fehlgeschlagen:

Der Microsoft Exchange Server-Computer steht nicht zur Verfügung. Das Netzwerk antwortet nicht, oder der Server wurde für Wartungsarbeiten heruntergefahren.

Der MAPI-Provider ist fehlgeschlagen.

Microsoft Exchange Server-Informationsspeicher

ID no: 8004011d-0526-00000000

 

***************************************************************

Ereignistyp: Fehler

Ereignisquelle: NtFrs

Ereigniskategorie: Keine

Ereigniskennung: 13568

Datum: 05.01.2006

Zeit: 10:52:53

Benutzer: Nicht zutreffend

Computer: EXCHANGE

Beschreibung:

Der Dateireplikationsdienst hat ermittelt, dass sich der Replikatsatz "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" sich in JRNL_WRAP_ERROR befindet.

 

Name des Replikatsatzes : "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)"

Replikatstammpfad : "c:\windows\sysvol\domain"

Replikatstammvolume : "\\.\C:" n%

Ein Replikatsatz stößt auf JRNL_WRAP_ERROR, wenn der Eintrag, von dem gelesen werden soll, nicht vom NTFS-USN-Journal gefunden wird. Mögliche Ursachen hierfür sind: n%

 

[1] Volume "\\.\C:" wurde formatiert.

[2] Das NTFS-USN-Journal auf Volume "\\.\C:" wurde gelöscht.

[3] Das NTFS-USN-Journal auf Volume "\\.\C:" wurde abgeschnitten. Chkdsk kann das Journal abschneiden, falls es beschädigte Einträge am Ende des Journals vorfindet.

[4] Der Dateireplikationsdienst wurde seit längerer Zeit auf diesem Computer nicht mehr ausgeführt.

[5] Die Rate der Laufwerks-E/A-Aktivität auf "\\.\C:" war zu schnell für den Dateireplikationsdienst.

Das Festlegen des Registrierungsparameters "Enable Journal Wrap Automatic Restore" auf 1 führt dazu, dass folgende Maßnahmen zum automatischen Beheben des Fehlerzustands vorgenommen werden.

[1] Beim ersten Poll, der in 5 Minuten durchgeführt wird, wird dieser Computer vom Replikatsatz entfernt. Wenn Sie nicht 5 Minuten warten möchten, führen Sie "net stop ntfrs" aus, gefolgt von "net start ntfrs", um den Dateireplikationsdienst neu zu starten.

[2] Beim auf die Löschung folgenden Poll wird der Computer erneut zum Replikatsatz hinzugefügt. Durch das erneute Hinzufügen wird eine vollständige Struktursynchronisierung für den Replikatsatz ausgelöst.

 

WARNUNG: Während des Wiederherstellungsvorgangs sind Daten in der Replikatstruktur möglicherweise nicht verfügbar. Sie sollten den oben beschriebenen Registrierungsparameter auf 0 festlegen, um eine unerwartete Nichtverfügbarkeit von Daten durch die automatische Wiederherstellung zu verhindern, wenn dieser Fehlerzustand erneut auftritt.

 

Führen Sie regedit aus, um diesen Registrierungsparameter zu ändern.

 

Klicken Sie auf "Start", dann auf "Ausführen", und geben Sie dann "regedit" ein.

 

Erweitern HKEY_LOCAL_MACHINE.

Folgen Sie folgendem Pfad:

"System\CurrentControlSet\Services\NtFrs\Parameters"

Doppelklicken Sie auf den Namen des Wertes

"Enable Journal Wrap Automatic Restore"

und aktualisieren Sie den Wert.

 

Ist der Name des Wertes nicht vorhanden, können Sie ihn mit dem Befehl "Neu" und dann "DWORD-Wert " im Menü "Bearbeiten" hinzufügen. Geben Sie den Wert genauso ein wie oben gezeigt.

Link zu diesem Kommentar

Nachdem du eseutil verwendet hast, ist das vermutlich dein Problem:

Cause 3

This issue may occur if the eseutil /p command was run on the affected databases and if the log files were not removed. To resolve this issue, see the "Resolution 3" section.

• Cause 4

This issue may occur if you run the following command with an incorrect logfile base name, as in the following example:

eseutil /r three-character logfile base name

To resolve this issue, see the "Resolution 4" section.

 

Lösung siehe:

http://support.microsoft.com/kb/896143/en-us

Link zu diesem Kommentar

Wir haben inzwischen wieder die originale Datenbank mit den originalen Logfiles genommen, da wir mit der anderen nicht auf einen grünen Zweig gekommen sind.

 

Die Datenbank ist auch hier auf Dirty Shutdown. Wie bringe ich es fertig, dass ich die Logs nachführen kann? Damit die Datenbank wieder konsitent ist???

 

**********************************************************************

 

 

C:\Programme\Exchsrvr\bin>eseutil /mh "C:\Programme\Exchsrvr\MDBDATA\priv1.edb"

 

Microsoft® Exchange Server Database Utilities

Version 6.5

Copyright © Microsoft Corporation. All Rights Reserved.

 

Initiating FILE DUMP mode...

Database: C:\Programme\Exchsrvr\MDBDATA\priv1.edb

 

File Type: Database

Format ulMagic: 0x89abcdef

Engine ulMagic: 0x89abcdef

Format ulVersion: 0x620,11

Engine ulVersion: 0x620,11

Created ulVersion: 0x620,9

DB Signature: Create time:10/13/2005 11:55:46 Rand:2193094 Computer:

cbDbPage: 4096

dbtime: 19393267 (0x127eaf3)

State: Dirty Shutdown

Log Required: 3726-3962 (0xe8e-0xf7a)

Streaming File: Yes

Shadowed: Yes

Last Objid: 7907

Scrub Dbtime: 0 (0x0)

Scrub Date: 00/00/1900 00:00:00

Repair Count: 0

Repair Date: 00/00/1900 00:00:00

Last Consistent: (0xA89,B88,D0) 12/20/2005 17:57:00

Last Attach: (0xA89,B8A,1F) 12/20/2005 17:57:01

Last Detach: (0x0,0,0) 00/00/1900 00:00:00

Dbid: 1

Log Signature: Create time:10/13/2005 11:55:45 Rand:2198025 Computer:

OS Version: (5.2.3790 SP 1)

 

Previous Full Backup:

Log Gen: 3626-3627 (0xe2a-0xe2b)

Mark: (0xE2A,E2F,5)

Mark: 01/04/2006 01:32:58

 

Previous Incremental Backup:

Log Gen: 0-0 (0x0-0x0)

Mark: (0x0,0,0)

Mark: 00/00/1900 00:00:00

 

Current Full Backup:

Log Gen: 0-0 (0x0-0x0)

Mark: (0x0,0,0)

Mark: 00/00/1900 00:00:00

 

Current Shadow copy backup:

Log Gen: 0-0 (0x0-0x0)

Mark: (0x0,0,0)

Mark: 00/00/1900 00:00:00

 

cpgUpgrade55Format: 0

cpgUpgradeFreePages: 0

cpgUpgradeSpaceMapPages: 0

 

Operation completed successfully in 3.15 seconds.

Link zu diesem Kommentar

eseutil mit recovery.... Vorher db wegsichern!

RECOVERY:

DESCRIPTION: Performs recovery, bringing all databases to a consistent state.

SYNTAX: ESEUTIL /r (3 character logfile base name)[options]

OPTIONS: zero or more of the following switches, separated by a space:

/l<path> - location of log files (default: current directory)

/s<path> - location of system files (e.g., checkpoint file)

(default: current directory)

/i - ignore mismatched/missing database attachments

/o - suppress logo

Link zu diesem Kommentar

Langsam aber sicher bekomme ich ne Krise!!!! Jetzt habe ich es endlich fertiggebracht, dass er mir eseutil /r e00 ausführt. Aber ich bekomme am Ende trotzdem wieder eine Fehlermeldung:

 

Operation terminated with error -1216 (JET_errAttachedDatabaseMismatch, An outst

anding database attachment has been detected at the start or end of recovery, bu

t database is missing or does not match attachment info) after 56.16 seconds.

 

Was bedeutet das jetzt schon wieder?

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...