Zum Inhalt springen

mdf Datei auf den Server importieren oder auslesen


Musor

Empfohlene Beiträge

Hallo zusamen,

ich habe ein kleines Problem beim Anfügen einer mdf-Datenbank auf den SQL Server. Nach der Neuinstalation des SQL Servers wollte ich die alte Datenbank in den Server laden. Ich bekomme dabei folgende Fehlermeldung:

Fehler: 3624

Location: rexbase.cpp:1357

Expression: False

SPID: 51

ProcessID: 144

Description: Invalid switch value

Ich habe SBS Premium 2003 mit SQL server 2000

Den SP4 habe ich installiert.

Der Server wurde nach einem crash neuinstalliert und ich habe nur die alten mdf Dateien. Normalerweise ist es doch kein Problem diese wieder anzuhängen.

Der Server wurde aber etwas anders konfiguriert.

Der Data-Verzeichnis ist ein anderer und der Benutzername für Serverdienste (früher System, jetzt extra Betutzer mit Adminrechten und Deligierungsoption für Dienststart)

Die Seite von Bernd Jungbluth kenne ich schon, war nichts zu finden.

Wenn ich wenigstens die Daten exportieren könnte, wären fast alle Probleme weg. Wollte die Daten von der DB importieren, aber von einer mdf Datei geht das irgentwie nicht, keine Auswahl für mdf Dateien. :(

Hat vieleich einer eine Idee was das sein könnte?

Das ist ein Notfall bei mir und ich hoffe ihr könnt mir helfen.

Vielen Dank

Link zu diesem Kommentar
Auf anderen Seiten teilen

Hallo und Vielen Dank,

die Mdf- und Log-Datei habe ich und die sind soweit OK. (Kann mit Editor öffnen und auslesen)

Einen Backup habe ich nicht, nur die DB Dateien.

Ich habe schon folgendes probiert:

1. DB Anhängen - geht nicht Fehler 3624

2. ein Gleichnamigen DB zu erstellen, Server abschalten, mdf- und ldf-Dateien ersetzen und Server wiederstarten - Der Server sagt, dass die DB nich in Ordnung ist.

Im EnterpriseManager ist die DB dann Grau und ich kann nichts mehr damit machen.

Und wie kann ich die im Forum beschribene Kommandos eingeben? :confused:

    EXEC sp_attach_db @dbname = N'pubs', 

       @filename1 = N'c:\Program Files\Microsoft SQL Server\MSSQL\Data\pubs.mdf', 

       @filename2 = N'c:\Program Files\Microsoft SQL Server\MSSQL\Data\pubs_log.ldf'

Das war der Vorschlag. Ist der auch für mich OK?

Link zu diesem Kommentar
Auf anderen Seiten teilen

die Mdf- und Log-Datei habe ich und die sind soweit OK. (Kann mit Editor öffnen und auslesen)

Ömm, kleine Frage: mit welchem Editor liest du die Datei aus?

2. ein Gleichnamigen DB zu erstellen, Server abschalten, mdf- und ldf-Dateien ersetzen und Server wiederstarten - Der Server sagt, dass die DB nich in Ordnung ist.

Im EnterpriseManager ist die DB dann Grau und ich kann nichts mehr damit machen.

Das die "grau" also "suspect" ist, ist in diesem Falle normal weil sie nicht deckungsgleich mit der Datei ist, die an den angehängt war bevor du den Server gestoppt hast. Probiere dann einfach den beschriebenen Ansatz via Emergency mode. Sicher dir die mdf aber vorher bitte nochmal. (File copy nicht via Backup). Nach der Reparatur (DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS) sollte sie nicht mehr suspect sein.

Und wie kann ich die im Forum beschribene Kommandos eingeben? :confused:

    EXEC sp_attach_db @dbname = N'pubs', 

       @filename1 = N'c:\Program Files\Microsoft SQL Server\MSSQL\Data\pubs.mdf', 

       @filename2 = N'c:\Program Files\Microsoft SQL Server\MSSQL\Data\pubs_log.ldf'

Das war der Vorschlag. Ist der auch für mich OK?

Ja, dieser T-SQL-Befehl zum Restore bewirkt letztendlich dasselbe wie ein Restore über die entsprechenden Dialoge im Enterprise Manager.

T-SQL-Befehle führst du am Besten über den Query Analyzer aus in dem du dich auf die master-Datenbank verbindest.

Wenn du die oben angeführten Pfade und Dateinamen auf deine Bedürfnisse anpasst, kannst du es ja mal auch damit probieren. Bezweifele aber dass das Ergebnis anders ausschaut.

Gruß,

Honky

Link zu diesem Kommentar
Auf anderen Seiten teilen

mit welchem Editor liest du die Datei aus?

Mit dem ganz normalem Editor von MS der in jedem XP zu finden ist.

Probiere dann einfach den beschriebenen Ansatz via Emergency mode.

Soll ich den Emergency mode extra einschalten, dann Wie?

Oder ist der Emergency mode dieses graue Datenbank? :confused:

(DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS)

Habe probiert über EMS SQL Lite auszuführen - geht auch nicht (Falscher Syntax)

Da fehl was bei mir, oder? :confused:

Und der EXEC Befehl sagt mir das die DB schon existiert und alles bleibt wie es war. :(

Ausserdem habe ich das hier gefunden, kann aber leider dicht anwenden, da zu kurz beschrieben ist. :( Der Link.

Sorry für die vielen Fragen. Das ist mein erster Crash. Und Danke für die tollen Erklärungen. Ich hoffe mit deiner Hilfe rette ich meine Daten. :e@sy

Gruß

Musor

Link zu diesem Kommentar
Auf anderen Seiten teilen

Sorry, hatte ein wenig mehr zu tun in letzter Zeit.

Mit dem ganz normalem Editor von MS der in jedem XP zu finden ist.

Öhm, eine Daten- (.mdf) oder Log (.ldf)-Datei sind binäre Dateien, sie in dem Windows-Editor anzeigen zu können sagt nichts über ihre Funktionalität aus.... :rolleyes:

Soll ich den Emergency mode extra einschalten, dann Wie?

Oder ist der Emergency mode dieses graue Datenbank? :confused:

[...]

Habe probiert über EMS SQL Lite auszuführen - geht auch nicht (Falscher Syntax)

Da fehl was bei mir, oder? :confused:

Und der EXEC Befehl sagt mir das die DB schon existiert und alles bleibt wie es war. :(

Nochmals sorry, habe jetzt erst erkannt, dass ich den Befehl auf nem 2005er getestet habe. Auf nem SQL 2000 Server gibt es den Modus noch gar nicht.

Ansonsten wäre die Antwort "ja" und "nein" gewesen. Eine solche Eigenschaft müsstest du extra setzen, die graue Datenbank sagt nur aus, dass die Datenbank als suspekt, also fehlerhaft markiert ist.

Ausserdem habe ich das hier gefunden, kann aber leider dicht anwenden, da zu kurz beschrieben ist. :( Der Link.

Ah, da kommen wir schon zu einer 2000er-kompatiblen Lösung...

Der Status der Datenbanken im Server wird bekanntlich u.a. in der Tabelle sysdatabases in der master-Datenbank vermerkt. Normalerweise sollten Veränderungen an Sytemdatenbanken ohne eine System-Prozedur zu verwenden ein absolutes NO-GO sein. (!)

Angenommen die Datebank "EXAMPLE" befindet sich im "suspect"-Mode (ist also grau). Mit dem Befehl

UPDATE SYSDATABASES SET STATUS = 32768 WHERE NAME='EXAMPLE' 
empfiehlt "fritzo" nichts anderes als diesen Wert einfach zurückzusetzen. Besser wäre an dieser Stelle die System-Prozedur sp_resetstatus dafür zu nutzen. Also
EXEC sp_resetstatus 'EXAMPLE'
im Query Analyzer auszuführen. Dies entfernt aber nur die suspect-Eigenschaft aus der Tabelle, löst aber nicht dein eigentliches Problem, das die DB sich in einem inkonsistenten Modus befindet. Sei es drum. Wenn die DB nicht mehr suspekt ist, kann man auf ihr wieder Befehle ausführen, also können wir auch dir Reparatur anstossen mit
DBCC CHECKDB ('EXAMPLE', REPAIR_ALLOW_DATA_LOSS) 

Mit Glück kann noch etwas gerettet werden.

Sorry für die vielen Fragen. Das ist mein erster Crash. Und Danke für die tollen Erklärungen. Ich hoffe mit deiner Hilfe rette ich meine Daten. :e@sy

Uargs, nicht knuddeln.

Keine Angst, bei den meisten Sachen muss man sich immer zuerst durchhangeln. Allerdings lehrt es einen auch mal über Backup und Recovery-Konzepte nachzudenken. ;)

Gruß,

Honky

Link zu diesem Kommentar
Auf anderen Seiten teilen

Hallo Honkytonk,

vielen Dank für deine Erklärungen, ich konnte aber noch nicht richtig ausprobieren (wegen ein paar Fehlermeldungen).

Uargs, nicht knuddeln.
:hells: :)

Keine Angst, bei den meisten Sachen muss man sich immer zuerst durchhangeln. Allerdings lehrt es einen auch mal über Backup und Recovery-Konzepte nachzudenken.

Oooh jaa. Jetzt wird alles drei, vierfach, intern, extern, alles was nötig und nicht nötig ist gespeichert :)

Aber wieder zum Problem. Als erstes nach dem austauschen der alten und neuern DB, habe ich Reset gemacht.

EXEC sp_resetstatus 'EXAMPLE'

Die DB war danach nicht mehr grau, aber immer noch als suspekt markiert. Ich konnte also kein checkdb ausführen, wegen diesem Grund. Ich habe zwar die Struktur gesehen, also Tabellen, Funktionen, aber zugreifen auf die Daten konnte ich auch nicht :(

Ich habe auch versucht den Script auszuführen, ...

UPDATE SYSDATABASES SET STATUS = 32768 WHERE NAME='EXAMPLE'

... aber der Querry Analyser sagt mir, dass ich den Server neu konfigurieren muss um den Befehl auszuführen. Ich dachte, das mir die Rechte fehlen und versuchte mich auch als sa anzumelden - geht aber auch nicht.

:confused: Was habe denn jetzt wieder vergessen??? :confused:

Link zu diesem Kommentar
Auf anderen Seiten teilen

Nach ewigem Suchen habe ich die Einstellung zur Konfiguration (um direkt die master db zu verändern) gefunden.

Jetzt habe ich aber ein Problem beim SingleUser Modus um checkdb ausführen zu können.

Ich habe den Behfehl für SingleUser gefunden


exec sp_dboption 'Example','single user','TRUE'

Der wird auch erfolgreich ausgeführt. Aber ich kann immer noch kein checkdb starten. Beim ausführen habe ich immer noch die Meldung, dass der Befehl kann nicht ausgeführt werden, weil die DB im Einzelbenutzermodus sich befinden soll. :(

WAS MACHE ICH FALSCH? :confused: :(

Link zu diesem Kommentar
Auf anderen Seiten teilen

Ich habe jetzt ein Problem im Einzelbenutzermodus CHECKDB auszuführen.

Ich habe mit Enterprise Manager -m Option in Startoptionen engefügt.

Mit dem DienstManager alle Dienste beendet und nur SQLServer wieder gestartet. Enterprise Manager meldet dass ich mich nicht anmelden kann, weil der Server im EBmodus ist (ist auch richtig). Und ab jetzt habe ich Probleme:

1.

Obwohl ich als einziger Admin am Server bin, kann ich keine Verbindung zum Server mit QuerryAnalyser herstellen. :(

Beim Versuch bekomme ich immer den Fehler 18461

Fehler bei der Anmeldung für Benutzer Dom/Administrator. Nur ein Admin kann blabla

2.

Ich habe auch versucht den SQLServer beenden, Anmeldung für QueryAnalyzer starten, und gleich SQLServer starten - mit dem Erfolg(QueryAnalyser hat sich mit dem Server verbunden), ABER ich kann kein CHECKDB ausführen

Fehler 7919 REPAIR-Anwesung nicht verarbeitet. Datenbank muss sich im Einzelbenutzermodus befinden.

Den Script...

exec sp_dboption 'Example','single user','TRUE'

führt er erfolgreich aus.

Aber ich habe immer noch den Fehler beim Checkdb

Wo liegt denn das Problem?

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 3 Jahre später...

Dein Kommentar

Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung wiederherstellen

  Nur 75 Emojis sind erlaubt.

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

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor leeren

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

Fachinformatiker.de, 2024 by SE Internet Services

fidelogo_small.png

Schicke uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App

Download on the App Store
Get it on Google Play

Kontakt

Hier werben?
Oder sende eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...