Probleme mit DB Files und ISINTEG

  • Hi @ all
    Wir haben ein Problem mit unserer Datenbank.
    Es handelt sich um Exchange 2003 SP2 auf Windows Server 2003, beides Enterpriese. Exchange läuft in einem Active-Passive Cluster mit zwei Nodes.


    Durch einen Controlercrash in unserem Raidsystem sind die Postfach- und öffentlichen Ordner Datenbanken des Exchangeservers beschädigt worden.
    Die öffentlichen Ordner haben sich mit ESEUTIL soweit reparieren lassen, dass wir mit PowerControls von Ontrack alle Daten aktuell auf einen neuen Server kopieren konnten.


    Bei den Postfächern haben wir das Problem, dass ESEUTIL nach einem Reparaturdurchlauf anzeigt, die Datei wäre "clean", aber weder ein mounten der DB im Informationspeicher, noch ein Durchlauf mit ISINTEG funktionieren. Auch der Zugriff mittels PowerControls funktioniert nicht.
    Beim Mounten kommt im Systemmanager eine Fehlermeldung mit der ID C1041724.


    Die Fehlermeldung im Eventlog:
    Quelle: MSExchangeIS
    Kennung: 9518
    Beschreibugn:
    Fehler 0xfffffbf8 beim Starten von Speichergruppe
    [.....] Initialization of Jet failed.


    Beim Versuch ISINTEG zu starten, kommt die Auswahl, Welche Datenbank (die sind auch alle Offline, der Iformationsspeicherdienst ist gestartet) überprüft werden soll, die Bestätungung und Sicherheitsabfrage und dann nach ein paar Sekunden folgender Fehler:
    "Isinteg cannot initiate verification process.
    Please review the log file for more Information"


    Ich finde aber keine logs.


    Ich habe die DB sowohl im Cluster, als auch auf einem Standalone mit ISINTEG prüfen wollen.
    Kurios ist, dass der Durchlauf auf jedem Server, bei jedem Informationsspeicher und bei jeder Datenbank den Gleichen Fehler bringt,´auch bei DB's, die eigentlich laufen.


    Kann ir da jemand weiterhelfen?
    Ich hoffe immer noch, die PostfachDB nach einem erfolgreichen Isinteg Durchlauf wieder nutzen, oder zumindest auslesen zu können


    Gruss


    Oliver Neis

    • Offizieller Beitrag

    Hi,


    Wenn Du die Datenbanken aus dem Backup zurück geholt hast, so musst Du noch


    eseutil /cc [Pfad zu dem Verzeichnis, das "Restore.env" enthält]


    aufrufen! Hast Du denn ein Restore gemacht?


    Ich gehe mal davon aus, dass Der Server und Exchange nicht neu installiert wurde, oder?!


    Sollte das auch nichts helfen, poste bitte die Ergebisse von:


    ESEUTIL /mh Datenbank
    ISINTEG -s Servername -fix -test alltests


    Gruss
    Heinz

  • Hallo
    Der Restore ist abgeschlossen. Es wurde ein neuer Exchange installiert. Wir haben jetzt aktuell 2 Exchange laufen. Beide gleiche Version, beide auf W2KServer, einer im Cluster, einer auf einer einzelnen Maschiene.



    C:\Programme\Exchsrvr\bin>isinteg -s hmbackup -fix -test alltests
    Databases for server hmbackup:
    Only databases marked as Offline can be checked


    Index Status Database-Name
    Storage Group Name: Erste Speichergruppe
    1 Online Informationsspeicher f³r Íffentliche Ordner (HMBACKUP)
    2 Offline Postfachspeicher (HMBACKUP)
    Storage Group Name: SpeichergruppeTemp
    3 Online PostfachTemp
    Enter a number to select a database or press Return to exit.
    2
    You have selected Erste Speichergruppe / Postfachspeicher (HMBACKUP).
    Continue?(Y/N)y
    Isinteg cannot initiate verification process.
    Please review the log file for more information.



    C:\Programme\Exchsrvr\bin>eseutil /mh "f:\Postfächer1\priv1.edb"


    Microsoft(R) Exchange Server Database Utilities
    Version 6.5
    Copyright (C) Microsoft Corporation. All Rights Reserved.


    Initiating FILE DUMP mode...
    Database: f:\Postfõcher1\priv1.edb


    File Type: Database
    Format ulMagic: 0x89abcdef
    Engine ulMagic: 0x89abcdef
    Format ulVersion: 0x620,9
    Engine ulVersion: 0x620,9
    Created ulVersion: 0x620,11
    DB Signature: Create time:09/22/2006 19:17:58 Rand:437326514 Computer:
    cbDbPage: 4096
    dbtime: 1507597 (0-1507597)
    State: Clean Shutdown
    Log Required: 0-0
    Streaming File: Yes
    Shadowed: Yes
    Last Objid: 8
    Scrub Dbtime: 0 (0-0)
    Scrub Date: 00/00/1900 00:00:00
    Repair Count: 2
    Repair Date: 09/22/2006 19:17:58
    Last Consistent: (0xC68,6FC,2D) 09/22/2006 20:04:40
    Last Attach: (0xC68,6FB,16A) 09/22/2006 20:04:40
    Last Detach: (0xC68,6FC,2D) 09/22/2006 20:04:40
    Dbid: 2
    Log Signature: Create time:09/21/2006 10:53:29 Rand:320640047 Computer:
    OS Version: (5.2.3790 SP 1)


    Previous Full Backup:
    Log Gen: 0-0 (0x0-0x0)
    Mark: (0x0,0,0)
    Mark: 00/00/1900 00:00:00


    Current 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 snapshot 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 1.31 seconds.


    Ich weiss mir momentan keinen Rat mehr.


    Gruss

    • Offizieller Beitrag

    Hi,


    leider sind Deine Infos recht sperlich...


    Jetzt ist ja schon mal durch gekommen, das du einen neuen Server aufgesetzt hast und diesem die DB vom Cluster unterschieben wolltest. Ist ja schon eine ganz andere Gegebenheit als beim ersten Thread mit der Aussage, DB defekt im Cluster!


    Du kannst nicht einfach eine DB nehmen und die einen anderen Exchange Server unterschieben. Dies geht nur, wenn der neue Exchange Server die selbe IP, den gleichen Namen und auch den gleichen Patchstand hat. Innerhalb eine Exchange Organisation geht das aber nicht. Nun ist die Frage, sind beide Server in einer Organisation? Du kannst so nur die DB mit Ontrack in PST Dateien exportieren oder die DB dem Cluster wieder unterschieben.


    Ich finde aber das Vorgehen nicht so ganz perfekt!


    Das Problem ist klar... Controller defekt und somit die DB auch, allerdings läuft der Cluster oder zumindest ein Knoten noch! Nun sollte das Ziel sein, den Server wieder ans laufen zu bringen und zwar mit dem geringsten Aufwand und dem schnellsten Weg. Also warum der neue Server und das durcheinander?


    Gruss
    Heinz

  • Hallo
    Der Cluster und somit der Server ist wieder am Laufen. Mit dem Recovery der DB, einer Kopie der DB vor dem Crash und beiden DB's nach dem ESEUTIL ist der Informationsspeicher auf dem Originalserver nicht zu starten. Die Fehler habe ich im ersten Post drin. Der neue Server wurde aufgesetzt, um die Daten, die mit Ontrack restauriert wurden, wieder aufzunehmen. Das hat auch mit den öffentlichen Ordnern sauber geklappt.
    Die PostfachDB kriege ich weder auf dem Original Server, noch auf dem neuen Server zu Laufen. Auch ein Zugriff mit Ontrack scheitert.
    Ich konnte die DB allerdings bisher nicht mit Isinteg überprüfen, da das Tool nirgends läuft. Ich erhalte auf jedem Server und für jede DB (auch für laufende, die ich zu Testzwecken offline geschaltet habe) das Gleiche Ergebniss (s.o.).


    Zur Herstellung eines Standalone Servers: Ich habe keinerlei Literatur oder Hilfen gefunden, die mir das Vorgehen bei einem Crash im Cluster beschreiben. Welche Art von Server muss ich herstellen? reicht ein Server, der den Namen des virtuellen Servers und dessen IP hat oder muss ich den Cluster nachbauen?


    Gruss

    • Offizieller Beitrag

    Ok...


    Wie schon gesagt muss der Servername, IP und Patchdang gleich mit dem Quellserver sein.


    Zum Thema Cluster... Dies ist auch nur ein Server mit einer Virtuellen IP und Namen, worüber die Benutzer diesen im Zugriff hat. Nun musst Du als erstes sicher stellen, das ein Node wieder geht. Wenn der andere defekt ist, so kann dieser ohne Probkleme neu aufgebaut werden. Somit musst du schauen, dass ein Node wieder geht und wie ich Dich verstanden habe ist das auch der Fall.


    Wechsel nun auf den aktiven Konten. Mach eine Kopie aller Datenbanken und Log zur Sicherung. Führe "ESEUTIL /P DB.edb"zur Reparatur durch und auch noch "ISINTEG -s Servername -fix -test alltests"


    Wenn eines von beiden nicht geht bitte den Fehler aus dem CMD posten. Nun die DB auf den Cluster mounten.


    Falls Die Transaktionsprotokolle defekt sind müssen diese noch bereinigt werden.


    Erweiterte Reparatur der Datenbank mit ?eseutil /p datenbank.edb /i?


    Überprüfung des Headers mit ?eseutil /MH datenbank.edb?


    Der Status bei der Header - Überprüfung sollte ?clean Shutdown? sein


    Löschung noch vorhandener Transactionlogs der betroffenen Speichergruppe. (Einfach in die Eigenschaften der Speicherguppe schauen um den Pfad einzusehen.)


    Jetzt sollten sich die Datenbanken wieder mounten lassen. Allerdings empfiehlt es sich die Datenbanken noch mit ?eseutil /d datenbank.edb? zu defragmentieren und ein anschliessendes Vollbackup zu erstellen.



    Gruss
    Heinz

  • >Wie schon gesagt muss der Servername, IP und >Patchdang gleich mit dem Quellserver sein.
    Die Wiederherstellung euf einem komplöett neuen Server, der kein Domainmitglied ist, habe ich noch nicht versucht, werde dies aber tun.


    >Nun musst Du als erstes sicher stellen, das ein Node >wieder geht. Wenn der andere defekt ist, so kann >dieser ohne Probkleme neu aufgebaut werden. Somit >musst du schauen, dass ein Node wieder geht und >wie ich Dich verstanden habe ist das auch der Fall.
    stimmt. Beide Nodes sind wieder online, die korrekte Konfig wiederhergestellt und es ist alles am laufen (mit Aussnahme einer EXchange Speichergruppe) :(


    Kopie der DB und der Logs ist erfolgt


    >Führe "ESEUTIL /P DB.edb"zur Reparatur durch und >auch noch "ISINTEG -s Servername -fix -test alltests"


    ESEUTIL /p und ESEUTL /d erfolgreich abgeschlossen



    >Wenn eines von beiden nicht geht bitte den Fehler >aus dem CMD posten. Nun die DB auf den Cluster >mounten.


    ISINTEG lässt sich nicht durchführen


    F:\exchange\tempbin>isinteg -s hmexchange -fix -test alltests
    Databases for server hmexchange:
    Only databases marked as Offline can be checked


    Index Status Database-Name
    Storage Group Name: Dritte Speichergruppe
    1 Offline PFSpeicherdrei
    Storage Group Name: Erste Speichergruppe
    2 Offline Informationsspeicher f³r Íffentliche Ordner (HMEXCHANGE)
    3 Offline Postfachspeicher (HMEXCHANGE)
    Storage Group Name: Zweite Speichergruppe
    4 Offline Íffentliche Ordner 2
    Enter a number to select a database or press Return to exit.


    Falls Die Transaktionsprotokolle defekt sind müssen diese noch bereinigt werden.


    Erweiterte Reparatur der Datenbank mit ?eseutil /p datenbank.edb /i?


    >Überprüfung des Headers mit ?eseutil /MH >datenbank.edb?
    >
    >Der Status bei der Header - Überprüfung sollte ?clean >Shutdown? sein


    ist er:


    Initiating FILE DUMP mode...
    Database: f:\exchange\mdbdata\priv1.edb


    File Type: Database
    Format ulMagic: 0x89abcdef
    Engine ulMagic: 0x89abcdef
    Format ulVersion: 0x620,11
    Engine ulVersion: 0x620,11
    Created ulVersion: 0x620,11
    DB Signature: Create time:09/22/2006 18:02:07 Rand:135005017 Computer:
    cbDbPage: 4096
    dbtime: 20657300 (0x13b3494)
    State: Clean Shutdown
    Log Required: 0-0 (0x0-0x0)
    Streaming File: Yes



    >Löschung noch vorhandener Transactionlogs der >betroffenen Speichergruppe.


    Ist erfoglt. Es sind nur noch die .edb bzw. .stm Files vorhanden.


    >Jetzt sollten sich die Datenbanken wieder mounten l>assen. Allerdings empfiehlt es sich die Datenbanken >noch mit ?eseutil /d datenbank.edb? zu >defragmentieren und ein anschliessendes Vollbackup >zu erstellen.


    Defrag ist erfoglt, leif erfolgreich durch.


    Was mich hauptsächlich stört: Warum kann ich von keinem Rechner uas, mit keiner DB ein ISINTEG machen? das muss doch auch einen Grund haben. oder?


    Gruss
    Oli

    • Offizieller Beitrag

    Hi,


    verstehe ich es richtig, dass Du nun die DB mounten kannst?


    Die einbindung einer DB auf einen anderen Server brauchst Du nicht, da du ja auch ontrack hast... dieser Weg ist viel besser und auch schneller.


    Zum ISINTEG:
    Du sollstes den inaktiven Knoten im Cluster Manager auf Pause stellen und dann den Informationsspeicher beenden. Nun wieder ISINTEG starten und dann die DB wählen.... Kopiere ruhig mal alles was im CMD zu sehen ist. Kannst es auch als Anhang beifügen.


    Gruss
    Heinz

  • Hi
    Ich bin anstrengend. oder?
    Ich kann die DB NICHT mounten, sonst wäre alles grün und ich auch glücklich.


    Beim Versuch die DB zu mounten bringt mir der ESM folgende Fehlermeldung:
    <snap>
    Interner Verarbeitungsfehler. Starten Sie Exchange-Systemmanager oder den Exchange-.Informationsspeicherdienst oder beide Programme neu. Überprüfen Sie das Anwendungsprotokoll auf mit diesem Fehler zusammenhängende Ereignisse....


    ID-NR: c1041724
    Exchange System Manager
    </snap>


    Die Ereignissanzeige enhält folgendes in gleicher Reihenfolge:


    Ereignistyp: Informationen
    Ereignisquelle: ESE
    Ereigniskategorie: Allgemein
    Ereigniskennung: 100
    Datum: 22.09.2006
    Zeit: 23:47:06
    Benutzer: Nicht zutreffend
    Computer: CLUSTER1
    Beschreibung:
    Information Store (7132) Das Datenbankmodul 6.05.7638.0002 ist gestartet.


    Weitere Informationen erhalten Sie unter http://www.microsoft.com/contentredirect.asp.



    Ereignistyp: Informationen
    Ereignisquelle: ESE
    Ereigniskategorie: Allgemein
    Ereigniskennung: 102
    Datum: 22.09.2006
    Zeit: 23:47:07
    Benutzer: Nicht zutreffend
    Computer: CLUSTER1
    Beschreibung:
    Information Store (7132) Erste Speichergruppe: Die Datenbank hat eine neue Instanz (0) gestartet.


    Weitere Informationen erhalten Sie unter http://www.microsoft.com/contentredirect.asp.



    Ereignistyp: Fehler
    Ereignisquelle: MSExchangeIS
    Ereigniskategorie: Allgemein
    Ereigniskennung: 9519
    Datum: 22.09.2006
    Zeit: 23:47:35
    Benutzer: Nicht zutreffend
    Computer: CLUSTER1
    Beschreibung:
    Fehler 0xfffffbf8 beim Starten von Datenbank "Erste Speichergruppe\Postfachspeicher (HMEXCHANGE)" im Microsoft Exchange-Informationsspeicher.


    Weitere Informationen erhalten Sie unter http://www.microsoft.com/contentredirect.asp.
    Daten:
    0000: 46 61 69 6c 65 64 20 74 Failed t
    0008: 6f 20 61 74 74 61 63 68 o attach
    0010: 20 74 6f 20 4a 65 74 20 to Jet
    0018: 44 42 00 DB.



    Ereignistyp: Fehler
    Ereignisquelle: MSExchangeIS
    Ereigniskategorie: Allgemein
    Ereigniskennung: 9518
    Datum: 22.09.2006
    Zeit: 23:47:35
    Benutzer: Nicht zutreffend
    Computer: CLUSTER1
    Beschreibung:
    Fehler 0xfffffbf8 beim Starten von Speichergruppe /DC=local/DC=Handyman/CN=Configuration/CN=Services/CN=Microsoft Exchange/CN=Handyman/CN=Administrative Groups/CN=Erste administrative Gruppe/CN=Servers/CN=HMEXCHANGE/CN=InformationStore/CN=Erste Speichergruppe im Microsoft Exchange Server-Informationsspeicher.
    MDB failed to start.


    Weitere Informationen erhalten Sie unter http://www.microsoft.com/contentredirect.asp.



    und dann beneden der Instaz.



    ISINTEG bringt folgendes:
    <snap>
    C:\Programme\Exchsrvr\bin>isinteg -s hmexchange -fix -test alltests
    Databases for server hmexchange:
    Only databases marked as Offline can be checked


    Index Status Database-Name
    Storage Group Name: Dritte Speichergruppe
    1 Offline PFSpeicherdrei
    Storage Group Name: Erste Speichergruppe
    2 Offline Informationsspeicher f³r Íffentliche Ordner (HMEXCHANGE)
    3 Offline Postfachspeicher (HMEXCHANGE)
    Storage Group Name: Zweite Speichergruppe
    4 Offline Íffentliche Ordner 2
    Enter a number to select a database or press Return to exit.
    3
    You have selected Erste Speichergruppe / Postfachspeicher (HMEXCHANGE).
    Continue?(Y/N)y
    Isinteg cannot initiate verification process.
    Please review the log file for more information.


    </snap>


    Hierbei hadelt es sich um die ganze Bilschirmausgabe.



    Hier auch noch das Ergebniss einer ESEUTIL /p Operation auf der DB:


    Repair completed. Database corruption has been repaired!


    Note:
    It is recommended that you immediately perform a full backup
    of this database. If you restore a backup made before the
    repair, the database will be rolled back to the state
    it was in at the time of that backup.



    Operation completed successfully with 595 (JET_wrnDatabaseRepaired, Database cor
    ruption has been repaired) after 3951.125 seconds.



    Das heisst: die Original DB liegt auf dem Originalserver, im Originalverzeichniss, ist laut ESEUTIL ok.
    Trotzdem kann ich sie nicht mounten oder mit Ontrak öffnen.