it-swarm.com.de

Wie kopiere ich die SQL Server 2012-Datenbank in die localdb-Instanz?

Ich möchte eine SQL Server 2012 Standard-Datenbank in meine localdb-Instanz kopieren. Ich habe den Assistenten ausprobiert, der sich darüber beschwert, dass localdb kein SQL Server 2005 oder eine spätere Express-Instanz ist. Ich habe auch ein Backup/Restore, sondern auf die in meinem localdb wiederherstellen bekomme ich folgende Fehler ...

Laufen diese ...

RESTORE DATABASE CSODev
FROM DISK = 'C:\MyBckDir\CSODev.bak'
WITH MOVE 'CSOdev_Data' TO 'C:\Users\cblair\CSOdev_Data.mdf',
MOVE 'CSOdev_Log' TO 'C:\Users\cblair\CSOdev_Log.ldf',
REPLACE

Fehlermeldung, die ich erhalte ...

Verarbeitete 8752 Seiten für die Datenbank 'CSODev', Datei 'CSOdev_Data' in Datei 1.
Verarbeitet 5 Seiten für die Datenbank 'CSODev', Datei 'CSOdev_Log' in Datei 1.

Nachricht 1853, Ebene 16, Status 1, Zeile 1
Die logische Datenbankdatei 'CSOdev_Log' wurde nicht gefunden. Geben Sie den vollständigen Pfad für die Datei an.
Nachricht 3167, Ebene 16, Status 1, Zeile 1
RESTORE konnte die Datenbank 'CSODev' nicht starten.
Nachricht 3013, Ebene 16, Status 1, Zeile 1
RESTORE DATABASE wird abnormal beendet.

Die Datenbank endet in „Recovery Pending“ -Modus auf. Es scheint Probleme mit der Protokolldatei zu geben. Ich habe versucht, zwei verschiedene Sicherungen im Fall einer wurde nur beschädigt.

23
Corey Blair

Es gibt bekannte Einschränkung (tatsächlich ein wirklicher Fehler) für localDB. Es wird kein RESTORE mit MOVE ausgeführt, wenn sich Ihre Datenbankdateien in verschiedenen Ordnern befinden. 

Sie müssen in den ursprünglichen Ordnern wiederherstellen (kein MOVE). Verwenden Sie das Cmd-Tool wie SUBST, wenn Sie ein Laufwerk:/Pfad vorgeben möchten.

15
BernardV

Ich hatte das gleiche Problem. Was schließlich funktioniert hat, war folgendes:

  1. Wiederherstellen der Datenbank versucht (Fehler im OP abrufen)
  2. Trennen der Datenbank
  3. Erneutes Anfügen der Datenbank

Was im letzten Schritt passierte, war, dass SSDT ein Upgrade der Datendateien durchführte, die sich offenbar in einem älteren Format befanden. Danach war die Datenbank problemlos funktionsfähig!

5
MEMark

Ich hatte das gleiche Problem, und nachdem ich ein wenig online recherchiert hatte, fand ich einen genialen Weg, um es zum Laufen zu bringen (wenn auch ziemlich hackig). Grundsätzlich Sie:

  1. Erstellen Sie eine SqlLocalDb-Instanz (SqlLocalDb c tmp -s).
  2. Stellen Sie die Datenbank wie oben beschrieben wieder her (z. B. SqlCmd -E -S <localdb connection string> -Q "RESTORE DATABASE ...").
  3. Stoppen Sie die SqlLocalDb-Instanz (SqlLocalDb p tmp).
  4. Löschen Sie die SqlLocalDb-Instanz (SqlLocalDb d tmp).
  5. Erstellen Sie eine neue SqlLocalDb-Instanz (SqlLocalDb c persistent -s).
  6. Erstellen Sie die Datenbank in der neuen Instanz, indem Sie sie anhängen (SqlCmd -E -S <persistent connection string> -Q "Create Database <dbname> On (Filename = '<Mdf file location'), (Filename = '<Ldf Filename'>) For Attach".

Und hoffentlich sollte es funktionieren. hier für originelle Idee.

Edit: Added Jason Brady s Korrektur des Erstellungsbefehls.

4
ktr

Versuchen Sie, Ihre Datenbank als Schema und als Daten zu erstellen, und führen Sie das Skript dann lokal aus.

3
Srb1313711
RESTORE FILELISTONLY
FROM DISK = 'D:\SQLBackups\yourdatabase.BAK'


ALTER DATABASE yourdatabasename
SET SINGLE_USER WITH
ROLLBACK IMMEDIATE

RESTORE DATABASE yourdatabasename
FROM DISK = 'D:\SQLBackups\yourdatabase.BAK'
with replace,
move 'logical name from file stream' to
'C:\yourdatabase.mdf',
move 'logical name from file stream' to 'C:\Yourdatabase.ldf'
ALTER DATABASE Qatar_DB SET MULTI_USER
2
Kiran M R

Ich hatte das gleiche Problem. Führen Sie Visual Studio als Administrator aus und führen Sie den folgenden Befehl aus

RESTORE DATABASE CSODev
FROM DISK = 'C:\MyBckDir\CSODev.bak'
WITH NORECOVERY, MOVE 'CSOdev_Data' TO 'C:\Users\cblair\CSOdev_Data.mdf',
MOVE 'CSOdev_Log' TO 'C:\Users\cblair\CSOdev_Log.ldf',

UPDATE: Das hat nicht genau funktioniert! 

Obwohl die obige Anweisung keine Fehler erzeugt und erfolgreich abgeschlossen wurde, verbleibt die Datenbank im Status "PENDING RECOVERY" und kann in keiner Weise darauf zugegriffen werden. Als ich versuchte, die Datenbank online zu "RESTORE WITH RECOVER" zu bringen, bekam ich dieselbe Fehlermeldung wie in der obigen Frage.

In meinem Fall habe ich also das Backup auf einem DEV-Server wiederhergestellt, den ich mit MSSQL 2008 R2 ausgeführt habe, und dann Folgendes ausgewählt: Aufgaben -> Skripts generieren -> Objekte für Skript auswählen & Weiter -> auf die Schaltfläche "Erweitert" klicken -> Auswählen " Datentypen für das Skript ": Schema & Daten. Führen Sie nun das generierte Skript für die lokale Datenbank aus.

1
cleftheris

Dasselbe Problem, danke für die Hilfe. Meine lokale Datenbank ist MS SQL 2014. Öffnen Sie "SQL Server 2014 Management Studio".

  1. Klicken Sie mit der rechten Maustaste auf die Datenbank, gehen Sie zu "Aufgaben" und klicken Sie auf "Offline schalten".
  2. Trennen Sie die Datenbank
  3. Hängen Sie die Datenbank an

Es funktioniert für mich. Nachdem Sie die Datenbank gesichert haben, können Sie die Datenbank ohne Fehler wiederherstellen. Vielen Dank.

1
Stephen

Probieren Sie diese Skripte aus (Beispiel mit Adventureworks2012, das ich persönlich getestet habe):

RESTORE FILELISTONLY
FROM DISK = 'c:\temp\adv2012.bak'

Dadurch werden die Dateinamen wie folgt angezeigt:

AdventureWorks2012      C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQL2012RTM\MSSQL\DATA\AdventureWorks2012.mdf
AdventureWorks2012_log  C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQL2012RTM\MSSQL\DATA\AdventureWorks2012_log.ldf

Verwenden Sie diese Dateinamen, um das endgültige Skript folgendermaßen zu strukturieren:

RESTORE DATABASE AdventureWorks2012
FROM DISK = 'C:\temp\adv2012.bak'

WITH MOVE 'AdventureWorks2012' TO 'C:\cnom_WS\Local-Databases\AdventureWorks\AdventureWorks2012.mdf',
MOVE 'AdventureWorks2012_log' TO 'C:\cnom_WS\Local-Databases\AdventureWorks\AdventureWorks2012_log.ldf',
REPLACE;

Übrigens: Ich führe diese über Visual Studio (SQL Server Object Explorer) aus, aber ich vermute stark, dass dies problemlos unter SSMS ausgeführt werden kann ;-)

0
cnom