SQL Server veritabanı geri yükleme hatası: belirtilen atama geçerli değil. (SqlManagerUI)


91

Üretim web sitem için SQL Server 2008 R2 Standard (sürüm 10.50.1600.1) ve bir veritabanı olarak localhost için Gelişmiş Hizmetler içeren SQL Server Express sürümü (v10.50.1600.1) kullanıyorum.

Birkaç gün önce SQL Sunucum çöktü ve yerel ana makineme yeni bir 2008 R2 Express sürümü yüklemek zorunda kaldım. Express sürümünden alınan bazı eski sürümleri geri yüklediğimde iyi çalıştı, ancak veritabanını .baküretim sunucusundan alınan dosyadan geri yüklemeye çalıştığımda aşağıdaki hataya neden oluyor:

Hata: Belirtilen atama geçerli değil. (SqlManagerUI)

ve komut kullanarak veritabanını geri yüklemeye çalıştığımda

Use Master
Go
RESTORE DATABASE Publications
FROM DISK = 'C:\Publications.bak'
WITH MOVE 'Publications' TO 'C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQLEXPRESS2008R2\MSSQL\DATA\Publications.mdf',--adjust path
MOVE 'AlPublications_log' TO 'C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQLEXPRESS2008R2\MSSQL\DATA\Publications.ldf'

Farklı bir hata oluşturur

Msg 3154, Seviye 16, Durum 4, Satır 1
Yedekleme seti, mevcut 'Yayınlar' veritabanı dışındaki bir veritabanının yedeğini tutar.
Msg 3013, Düzey 16, Durum 1, Satır 1
VERİTABANI GERİ YÜKLE anormal olarak sona eriyor.

Sürümleri çapraz kontrol ettim. Aşağıdaki resimde gösterildiği gibi hepsi benimle eşleşiyor gibi görünüyor

Önceden bir veritabanını standart sürümden ekspres sürüme geri yükleyebiliyordum ama şimdi başarısız oluyor. Veritabanını sildim ve yeniden oluşturmaya çalıştım. Bu da başarısız olur.

Neyi yanlış yaptığımdan emin değilim. Bununla ilgili yardım için minnettar olurum

.Bak dosyası bozuk göründüğü için sorun çözüldü . Farklı bir dosya ile denediğimde işe yaradı.


Bu konuda profesyonel değilim, ama hızlı bir soru, x86 ve x64 mimarisi veritabanında uyumlu mu?
Gustav Klimt

O zamanlar önceki geri yükleme veritabanım vardı, böyle bir sorunla karşılaşmadım. nedense şimdi ben veritabanı sunucusu harmanlama herhangi bir sorun yaratıyor değilim emin eğer hata oluşturmadan
Öğrenim

,REPLACEMevcut AlHabtoorPublications veritabanının üzerine yazmak için T-SQL komutuna eklemeyi deneyin .
SchmitzIT

Bugün işte aynı sorunu çarptım .. FTP aktarımı yaparken dosya boyutunu kontrol etmek yeterli değil gibi görünüyor. Görünüşe göre dosya çok hassas. Aktarımı gerçekleştirmeden önce dosyayı sıkıştırarak sorunu çözdü.
rofans91

Senaryo SQL SERVER 2008'de veritabanı yedeğini aldım ve SQL SERVER 2008 R2'de geri yüklemeyi denedim. İdeal olarak, iyi çalışması gerekir, ancak yedekleme dosyasını seçerken SQL Management Studio 2208 R2 "Belirtilen yayın belirtilmedi. (SqlManagerUI)" hatası veriyordu. Neden ve Sorun Giderme Bunun nedeni FTP aktarımı sırasında .BAK dosyasının bozulmasıdır (aktarım modu ASCII olarak ayarlanmıştır). Veritabanı .BAK dosyasını aktarırken, her zaman FTP aktarım modunu BINARY olarak ayarlamayı unutmayın.
Rohan Sarkar

Yanıtlar:


40

GUI zaman zaman kararsız olabilir. T-SQL kullanırken aldığınız hata, mevcut bir veritabanının üzerine yazmaya çalışmanız, ancak mevcut veritabanının üzerine yazmayı / değiştirmeyi belirtmemiş olmanızdır. Aşağıdakiler işe yarayabilir:

Use Master
Go
RESTORE DATABASE Publications
  FROM DISK = 'C:\Publications_backup_2012_10_15_010004_5648316.bak'
  WITH 
    MOVE 'Publications' TO 'C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQLEXPRESS2008R2\MSSQL\DATA\Publications.mdf',--adjust path
    MOVE 'Publications_log' TO 'C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQLEXPRESS2008R2\MSSQL\DATA\Publications.ldf'
, REPLACE -- Add REPLACE to specify the existing database which should be overwritten.

Garip, orijinal ifadenizi tekrar kullandım. Her durumda, eklediğim tek şey son , REPLACE
satırdı

1
Aslında, Failed: 38belirtiler reached end of the file. (Bir komut penceresinde çalıştırın NET HELPMSG 38). Bu genellikle bozuk bir yedeklemeyi gösterir: stackoverflow.com/questions/5656363/…
SchmitzIT

Herhangi bir sorun olmadan geri yüklenen biraz daha eski .bak dosyasıyla geri yüklemeyi test ettim. Bu özellikle .bak dosyası bozuk görünüyor
Öğrenim

Kazanın bir sonucu olabilir. Sürücünün bazı kısımlarını bozmuş olabilir. Yine de farklı bir yedeklemeyle sorunu çözmeyi başardığınıza sevindim :)
SchmitzIT

Komut dosyası aşağıdaki hata Msg 3203, Düzey 16, Durum 1, Satır 1 "C: \ Publications.bak" üzerinde okuma başarısız oldu: 38 (bu hata için metin alınamadı. Neden: 15105) Msg 3013, Düzey 16, Durum 1 , Satır 1 RESTORE DATABASE anormal şekilde sona eriyor.
Öğrenme

163

SQL Server 2012 sürüm yedekleme dosyasını SQL Server 2008 R2'ye veya daha azına geri yüklemek nedeniyle olabilir.


4
Bunun yerine "Komut Dosyası Oluştur" kullanılması gerekir.
kroiz

4
Bu benim sorunumdu. Bu vakalardan bazıları için MS için daha yararlı bir mesaj vermek çok zor olmayacak gibi görünüyor.
John Gilmer

Pinal Dave burada nedenleri açıklıyor - blog.sqlauthority.com/2015/06/01/…
shrivb

15

Sonunda bir geri yüklemede bu hatayı aldım. Hayal kırıklığı nedeniyle SQL2012'ye geçtim, ancak sanırım bu muhtemelen 2008R2'de çalışacaktı. Mantıksal isimleri kullanmak zorundaydım:

RESTORE FILELISTONLY
FROM DISK = ‘location of your.bak file

Ve oradan MOVEmantıksal isimler kullanarak bir geri yükleme ifadesi çalıştırdım .

RESTORE DATABASE database1
FROM DISK = '\\database path\database.bak'
WITH
MOVE 'File_Data' TO 'E:\location\database.mdf',
MOVE 'File_DOCS' TO 'E:\location\database_1.ndf',
MOVE 'file' TO 'E:\location\database_2.ndf',
MOVE 'file' TO 'E:\location\database_3.ndf',
MOVE 'file_Log' TO 'E:\location\database.ldf'

Onarımı tamamladığında neredeyse neşeyle ağlıyordum.

İyi şanslar!


4

Aşağıda bu sorunun 2 nedeni olabilir:

  1. SQL 2012'de alınan yedekleme ve Geri Yükleme Başlığı SQL 2008 R2'de yapıldı

  2. Yedekleme ortamı bozuk.

Aşağıdaki komutu çalıştırırsak, her zaman gerçek hatayı bulabiliriz:

restore headeronly
from disk = 'C:\Users\Public\Database.bak'

Teklifte veritabanı dosyanızın tam konumunu verin

Umarım yardımcı olur

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.