O bază acoperire de date, la o versiune anterioară a SQL Server devine inutilizabil, atunci când vă atașați-l la o instanță de SQL Server 2012

ID articol: 2710782 - Vizualizați produsele pentru care se aplică acest articol.
Traducere automatăFace?i clic aici pentru a vedea declara?ia privind exonerarea de răspundere a Bazei de cuno?tin?e tradusă automat
Măriți totul | Reduceți totul

În această pagină

SIMPTOME

Luați în considerare următorul scenariu:
  • Instalați o instanță a Microsoft SQL Server 2005, Microsoft SQL Server 2008, sau Microsoft SQL Server 2008 R2.
  • Instanța de SQL Server este numit INST1 ?i găzduiește o bază acoperire de date este numit Test_RO_FG_DB.
  • Baza acoperire de date conține următoarele grupuri de fișier:
    • Primar
    • RO_FG
    • RW_FG
  • Filegroup care este numit RO_FG este marcată ca READ_ONLY.
  • Instalați o nouă instanță a Microsoft SQL Server 2012. Această instanță a SQL Server 2012 este numit INST2.
  • Vă detașați baza acoperire de date Test_RO_FG_DB la INST1.
  • Încercați pentru a atașa baza acoperire de date Test_RO_FG_DB la INST2.
  • Primiți un mesaj de eroare care seamănă cu următorul:
    Msg 3415, nivel 16, stat 2, linia 1
    Baza acoperire de date 'Test_RO_FG_DB' nu poate fi actualizat deoarece este doar în citire, a fișierelor doar-în-citire sau utilizatorul nu are permisiunea de a modifica unele dintre fișiere. Face baza acoperire de date sau fișiere inscriptibil, și executați din nou de recuperare.
  • Încercați să reatașați baza acoperire de date Test_RO_FG_DB INST1.
În acest scenariu, nu Reatașați baza acoperire de date INST1. Și, veți primi următorul mesaj de eroare în Jurnalul de erori SQL Server:

2012-05-03 22:55:45.37 spid52 incepand bazei acoperire de date 'Test_RO_FG_DB'.
2012-05-03 22:55:45.78 spid52 * *******************************************************************************
2012-05-03 22:55:45.78 spid52 * începe STIVĂ DUMP:
2012-05-03 22:55:45.78 spid52 * 05/03/12 22: 55: 45 spid 52
2012-05-03 22:55:45.78 spid52 * locație: logscan.cpp:1490
2012-05-03 22:55:45.78 spid52 * expresie: FALSE
2012-05-03 22:55:45.78 spid52 * SPID: 52
2012-05-03 22:55:45.78 spid52 * proces ID: 9156
2012-05-03 22:55:45.78 spid52 * Descriere: comutator incorect valoarea
2012-05-03 22:55:45.78 spid52 * intrare tampon 98 octeți -
2012-05-03 22:55:45.78 spid52 * alter bază acoperire de date Test_RO_FG_DB set online
2012-05-03 22:55:51.05 spid52 eroare: 17065, gravitatea: 16, stat: 1.
2012-05-03 22:55:51.05 spid52 SQL Server afirmația: fișier: <logscan.cpp>, linia Către = 1490 nu a reușit afirmația = valoarea "FALSE" comutator incorect. Această eroare poate fi legate de calendarul. Dacă eroarea persistă după revedea declarația, utilizați DBCC CHECKDB pentru a verifica bazei acoperire de date pentru integritatea structurală, sau reporniți serverul pentru a asigura structurilor acoperire de date în memorie nu sunt corupte.
2012-05-03 22:55:51.10 spid52 eroare: 3624, gravitatea: 20, stat: 1.
2012-05-03 22:55:51.10 spid52 a sistemului afirmația selectare nu a reușit. Verificați Jurnalul de erori SQL Server pentru detalii. De obicei, un aserțiune nereușită este cauzată de un software de corupție bug sau date. Pentru a verifica pentru corupție acoperire de date, ia în considerare execută DBCC CHECKDB. Dacă aveți de acord pentru a trimite gropilor de la Microsoft în timpul instalării, un mini dump vor fi trimise la Microsoft. O actualizare ar putea fi disponibile de la Microsoft în ultimul pachet de Service sau o QFE de suport tehnic.
2012-05-03 22:56:09.16 spid52 eroare: 3414, gravitatea: 21, stat: 1.
2012-05-03 22:56:09.16 spid52 o eroare a avut loc în timpul recuperării, împiedică repornirea baza acoperire de date 'Test_RO_FG_DB' (date ID 19). Diagnosticarea erorilor de recuperare și le rezolvați, sau restabilire dintr-o copiere de rezervă bine cunoscute. Dacă erorile sunt corectate nu sau de așteptat, contactați asistența tehnică.
2012-05-03 22:56:09.18 spid52 eroare: 928, gravitatea: 20, stat: 1.
2012-05-03 22:56:09.18 spid52 în timpul upgrade-ul, baza acoperire de date a ridicat excepție 926, gravitatea 14, stat 1, adresa 0000000000F6A971. Utilizați numărul de excepție pentru a determina cauza.</logscan.cpp>


Notă Această problemă se produce numai atunci când încercați să atașați o bază acoperire de date care conține un filegroup care este marcat READ_ONLY. Această problemă nu se produce atunci când încercați să mutați o bază acoperire de date READ_ONLY care este marcat toate datele în READ_ONLY.
Înapoi la început | Trimite?i feedback

CAUZĂ

Această problemă apare deoarece SQL Server 2012 nu detectează filegroup doar-în-citire înainte de a începe upgrade-ul bazei acoperire de date. După ce a început upgrade-ul, SQL Server 2012 scrie intrările la fișierul jurnal de tranzacții. Versiunile anterioare nu pot citi noi intrările din jurnalul de tranzacții.
Înapoi la început | Trimite?i feedback

STARE

Microsoft a confirmat că aceasta este o problemă asociată cu produsele Microsoft enumerate în secțiunea „se aplică la".
Înapoi la început | Trimite?i feedback

REZOLUȚIE

Actualizarea cumulativă informații

SQL Server 2012

Fix pentru această problemă a fost lansat în 2 actualizare cumulativă pentru SQL Server 2012. Pentru mai multe informații despre acest pachet de actualizare cumulativ, faceți clic pe următorul număr de articol pentru a vedea articolul în bază de cunoștințe Microsoft:
2703275
(http://support.microsoft.com/kb/2703275/LN/ )
set de actualizări cumulativă 2 pentru SQL Server 2012
Notă Pentru că construiește sunt cumulative, fiecare nouă versiune fix conține toate remedierile rapide și toate remedierile de securitate care au fost incluse în anterioare SQL Server 2012 fix de presă. Microsoft recomandă că vă ia în considerare aplicarea cele mai recente fix de lansare care conține această remediere rapidă. Pentru mai multe informații, faceți clic pe următorul număr de articol pentru a vedea articolul în bază de cunoștințe Microsoft:
2692828
(http://support.microsoft.com/kb/2692828/LN/ )
2012 De Server SQL construiește care au fost lansate după ce a fost lansat SQL Server 2012
Trebuie să aplicați o remediere rapidă de SQL Server 2012 pentru o instalare de SQL Server 2012.
Înapoi la început | Trimite?i feedback

REMEDIERE

Pentru a rezolva această problemă, utilizați una dintre următoarele metode.

Metoda 1

Restaurați o copiere de rezervă a bazei acoperire de date la INST1 pe INST2.

Notă Problema descrisă în secțiunea „Simptome"nu apărea în SQL Server 2012 când restaurați o copiere de rezervă la o versiune anterioară.

Metoda 2

Efectuați un upgrade pe loc de versiunea anterioară a SQL Server SQL Server 2012.

Metoda 3

Muta o bază acoperire de date care conține o filegroup doar-în-citire la o instanță de SQL Server 2012. Pentru aceasta, urmați acești pași.

Notă Efectuați pașii 4-11 pe server care execută SQL Server 2012. De exemplu, efectuați pașii 4-11 pe INST2.
  1. Pe INST1, detașați baza acoperire de date. De exemplu, detașați baza acoperire de date Test_RO_FG_DB.
  2. Mutați fișierele bazei acoperire de date la serverul care găzduiește instanța INST2.
  3. Încercați pentru a atașa baza acoperire de date la INST2. Probă următorul cod arată cum să facă acest lucru:
    CREATE DATABASE [Test_RO_FG_DB] ON PRIMARY ( NAME = N'Test_RO_FG', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL11.SQL2012\MSSQL\DATA\Test_RO_FG.mdf' ), 
FILEGROUP [RO_FG] ( NAME = N'Test_RO_FG_File1', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL11.SQL2012\MSSQL\DATA\Test_RO_FG_File1.ndf' ), 
FILEGROUP [RW_FG] ( NAME = N'Test_RW_FG_File1', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL11.SQL2012\MSSQL\DATA\Test_RW_FG_File1.ndf' )
LOG ON ( NAME = N'Test_RO_FG_log', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL11.SQL2012\MSSQL\DATA\Test_RO_FG_log.ldf' )
FOR ATTACH;
GO
    Notă Primiți mesajul de eroare 3425 menționat în secțiunea „Simptome".
  4. La linia Către de comandă, redenumiți fișierele bazei acoperire de date. Comanda probă arată cum să facă acest lucru:
    rename Test_RO_FG.mdf original_Test_RO_FG.mdf
rename Test_RO_FG_File1.ndf original_Test_RO_FG_File1.ndf
rename Test_RW_FG_File1.ndf original_Test_RW_FG_File1.ndf
rename Test_RO_FG_log.ldf original_Test_RO_FG_log.ldf
  5. În SQL Server Management Studio, creați o bază acoperire de date care are același nume și structura fizică ca baza acoperire de date pe care doriți să atașați. Probă următorul cod arată cum să facă acest lucru:
    CREATE DATABASE [Test_RO_FG_DB] ON PRIMARY ( NAME = N'Test_RO_FG_DB', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL11.SQL2012\MSSQL\DATA\Test_RO_FG_DB.mdf' , SIZE = 4072KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB ), 
FILEGROUP [RO_FG] ( NAME = N'Test_RO_FG_File1', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL11.SQL2012\MSSQL\DATA\Test_RO_FG_File1.ndf' , SIZE = 8192KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB ), 
FILEGROUP [RW_FG] ( NAME = N'Test_RW_FG_File1', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL11.SQL2012\MSSQL\DATA\Test_RW_FG_File1.ndf' , SIZE = 8192KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB )
LOG ON ( NAME = N'Test_RO_FG_log', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL11.SQL2012\MSSQL\DATA\Test_RO_FG_log.ldf' , SIZE = 1024KB , MAXSIZE = 2048GB , FILEGROWTH = 10%)
GO
  6. Setați baza acoperire de date offline. Pentru aceasta, executați următoarea comandă:
    ALTER DATABASE [Test_RO_FG_DB] SET OFFLINE
GO
  7. La linia Către de comandă, redenumiți fișierele în noua bază acoperire de date. Comanda probă arată cum să facă acest lucru:
    rename Test_RO_FG.mdf new_Test_RO_FG.mdf
rename Test_RO_FG_File1.ndf new_Test_RO_FG_File1.ndf
rename Test_RW_FG_File1.ndf new_Test_RW_FG_File1.ndf
rename Test_RO_FG_log.ldf new_Test_RO_FG_log.ldf
  8. La linia Către de comandă, redenumiți fișierele din baza acoperire de date pe care ați mutat-o în pasul 2. Redenumiți fișierele pentru a se potrivi baza acoperire de date care l-ați creat în pasul 4. Comanda probă arată cum să facă acest lucru:
    rename original_Test_RO_FG.mdf Test_RO_FG.mdf 
rename original_Test_RO_FG_File1.ndf Test_RO_FG_File1.ndf 
rename original_Test_RW_FG_File1.ndf Test_RW_FG_File1.ndf 
rename original_Test_RO_FG_log.ldf Test_RO_FG_log.ldf
  9. Setați baza acoperire de date ONLINE. Pentru aceasta, executați următoarea comandă:
    ALTER DATABASE [Test_RO_FG_DB] SET ONLINE
GO
  10. Verificați dacă baza acoperire de date este online, și restabiliți funcționalitatea Broker de serviciu.
  11. Ștergeți fișierele bazei acoperire de date care nu sunt necesare. Comanda probă arată cum să facă acest lucru:
    del /P new_Test_RO_FG.mdf
del /P new_Test_RO_FG_File1.ndf
del /P new_Test_RW_FG_File1.ndf
del /P new_Test_RO_FG_log.ldf
Metoda 4

Reatașați o bază acoperire de date care conține o filegroup doar-în-citire la instanță anterioară a SQL Server. Pentru aceasta, urmați acești pași.

Note
  • Baza acoperire de date, de asemenea, conține noile intrări jurnal tranzacție la upgrade-ul nu a reușit.
  • Efectuați pașii 3 până la 10 pe server care se execută o versiune anterioară a SQL Server. De exemplu, efectuați pașii 3 până la 10 pe INST1.

  1. Mutați fișierele bazei acoperire de date la instanță de SQL Server care este gazduieste INST1.
  2. Încercați pentru a atașa baza acoperire de date la INST1. Probă următorul cod arată cum să facă acest lucru:
    CREATE DATABASE [Test_RO_FG_DB] ON PRIMARY ( NAME = N'Test_RO_FG_DB', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQL2008R2\MSSQL\DATA\Test_RO_FG_DB.mdf' ), 
FILEGROUP [RO_FG] ( NAME = N'Test_RO_FG_File1', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQL2008R2\MSSQL\DATA\Test_RO_FG_File1.ndf' ), 
FILEGROUP [RW_FG] ( NAME = N'Test_RW_FG_File1', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQL2008R2\MSSQL\DATA\Test_RW_FG_File1.ndf' )
LOG ON ( NAME = N'Test_RO_FG_log', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQL2008R2\MSSQL\DATA\Test_RO_FG_log.ldf' )
FOR ATTACH
GO
    Notă Primiți mesajul de eroare 3624 este menționat în secțiunea „Simptome". De asemenea, veți primi un mesaj de eroare 1813.
  3. La linia Către de comandă, redenumiți fișierele bazei acoperire de date pe INST1. Comanda probă arată cum să facă acest lucru:
    rename Test_RO_FG.mdf original_Test_RO_FG.mdf
rename Test_RO_FG_File1.ndf original_Test_RO_FG_File1.ndf
rename Test_RW_FG_File1.ndf original_Test_RW_FG_File1.ndf
rename Test_RO_FG_log.ldf original_Test_RO_FG_log.ldf
  4. În SQL Server Management Studio, creați o bază acoperire de date care are același nume și structura fizică ca baza acoperire de date pe care doriți să atașați. Probă următorul cod arată cum să facă acest lucru:
    CREATE DATABASE [Test_RO_FG_DB] ON PRIMARY ( NAME = N'Test_RO_FG_DB', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQL2008R2\MSSQL\DATA\Test_RO_FG_DB.mdf' , SIZE = 4072KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB ), 
FILEGROUP [RO_FG] ( NAME = N'Test_RO_FG_File1', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQL2008R2\MSSQL\DATA\Test_RO_FG_File1.ndf' , SIZE = 8192KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB ), 
FILEGROUP [RW_FG] ( NAME = N'Test_RW_FG_File1', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQL2008R2\MSSQL\DATA\Test_RW_FG_File1.ndf' , SIZE = 8192KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB )
LOG ON ( NAME = N'Test_RO_FG_log', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQL2008R2\MSSQL\DATA\Test_RO_FG_log.ldf' , SIZE = 1024KB , MAXSIZE = 2048GB , FILEGROWTH = 10%)
GO
  5. Setați baza acoperire de date offline. Pentru aceasta, executați următoarea comandă:
    ALTER DATABASE [Test_RO_FG_DB] SET OFFLINE
GO
  6. La linia Către de comandă, redenumiți fișierele în noua bază acoperire de date. Comanda probă arată cum să facă acest lucru:
    rename Test_RO_FG.mdf new_Test_RO_FG.mdf
rename Test_RO_FG_File1.ndf new_Test_RO_FG_File1.ndf
rename Test_RW_FG_File1.ndf new_Test_RW_FG_File1.ndf
rename Test_RO_FG_log.ldf new_Test_RO_FG_log.ldf
  7. La linia Către de comandă, redenumiți fișierele din baza acoperire de date pe care ați mutat-o în pasul 2. Redenumiți fișierele pentru a se potrivi baza acoperire de date care l-ați creat în pasul 4. Comanda probă arată cum să facă acest lucru:
    rename original_Test_RO_FG.mdf Test_RO_FG.mdf 
rename original_Test_RO_FG_File1.ndf Test_RO_FG_File1.ndf 
rename original_Test_RW_FG_File1.ndf Test_RW_FG_File1.ndf 
rename original_Test_RO_FG_log.ldf Test_RO_FG_log.ldf
  8. Setați baza acoperire de date la modul de urgență și efectuați o reparare. Pentru aceasta, executați următoarea comandă.

    Notă Jurnalele de tranzacție acoperire de date sunt reconstruite în timpul acestei etape. Acest lucru poate duce la pierderi acoperire de date. Prin urmare, se recomandă copierea de rezervă baza acoperire de date înainte de a efectua acest pas. 
    ALTER DATABASE Test_RO_FG_DB SET EMERGENCY
GO
ALTER DATABASE Test_RO_FG_DB SET SINGLE_USER
GO
DBCC CHECKDB (Test_RO_FG_DB, repair_allow_data_loss) WITH ALL_ERRORMSGS
GO
ALTER DATABASE Test_RO_FG_DB SET MULTI_USER
GO
  9. Verificați dacă baza acoperire de date este online, și restabiliți funcționalitatea Broker de serviciu.
  10. Ștergeți fișierele bazei acoperire de date care nu sunt necesare. Comanda probă arată cum să facă acest lucru:
    del /P new_Test_RO_FG.mdf
del /P new_Test_RO_FG_File1.ndf
del /P new_Test_RW_FG_File1.ndf
del /P new_Test_RO_FG_log.ldf
Înapoi la început | Trimite?i feedback

INFORMAȚII SUPLIMENTARE

Există mai multe etape care apar atunci când o bază acoperire de date este atașat la o instanță de SQL Server. Aceste măsuri includ recuperarea acoperire de date și actualizarea fișiere din versiuni anterioare ale SQL Server.

În problema descrisă în secțiunea „Simptome", SQL Server 2012 începe procesul de upgrade sunt detectată fi?ierele doar în citire din baza acoperire de date. Pa?ii includ începând o tranzacție pentru a goli pic "curat shut jos" în pagina de pornire a bazei acoperire de date. Versiunile de SQL Server nu poate citi începe înregistrarea tranzacției. Prin urmare, baza acoperire de date nu este ușor de utilizat în versiunile anterioare de SQL Server, și SQL Server generează eroarea 3624.

Înăuntru-place upgrades atunci când o bază acoperire de date este marcat ca doar-în-citire

Când efectuați un upgrade pe loc de o instanță de SQL Server, care conține un date doar-în-citire, care este numit Test_RO_DB SQL Server 2012, este posibil să primiți mesaje de eroare care seamănă cu următorul în Jurnalul de erori SQL Server:

2012-05-04 21:03:59.23 spid19s incepand bazei acoperire de date 'Test_RO_DB'.
2012-05-04 21:03:59.56 spid19s conversia date 'Test_RO_DB' din versiunea 661 la versiunea curentă 706.
2012-05-04 21:03:59.56 spid19s eroare: 928, gravitatea: 20, stat: 1.
2012-05-04 21:03:59.56 spid19s în timpul upgrade, baza acoperire de date a ridicat excepție 3415, gravitatea 16, statul 1, adresa 000007FEE66D784A. Utilizați numărul de excepție pentru a determina cauza.
2012-05-04 21:03:59.61 eroare spid19s: 3415, gravitatea: 16, stat: 1.
2012-05-04 21:03:59.61 spid19s baza acoperire de date 'Test_RO_DB' nu poate fi actualizat deoarece este doar în citire, a fișierelor doar-în-citire sau utilizatorul nu are permisiunea de a modifica unele dintre fișiere. Face baza acoperire de date sau fișiere inscriptibil, și executați din nou de recuperare.


La sfârșitul de procesul de actualizare, baza acoperire de date Test_RO_DB va fi în statul RECOVERY_PENDING. Trebuie să utilizați comanda ALTER DATABASE să setați baza acoperire de date la READ_WRITE. Apoi utilizați comanda ALTER DATABASE să setați baza acoperire de date la READ_ONLY. Acest lucru permite motorului SQL Server upgrade-ul bazei acoperire de date la versiunea corectă.

Înăuntru-place upgrade-uri atunci când o bază acoperire de date de citire/scriere conține fișierul grupuri care sunt marcate ca doar în citire

Când efectuați un upgrade pe loc pentru SQL Server 2012, este posibil să primiți mesaje care seamănă cu următorul în Jurnalul de erori SQL Server. Această problemă apare când instanță anterioară a SQL Server găzduiește o bază acoperire de date de citire/scriere și conține fișierul grupuri care sunt marcate READ_ONLY. Cu toate acestea, procesul de actualizare se termină cum era de așteptat, și baza acoperire de date începe online.

Notă În următorul mesaj de eroare, baza acoperire de date este numit Test_RO_FG:

2012-05-04 21:03:59.23 spid18s incepand bazei acoperire de date 'Test_RO_FG'.
2012-05-04 21:03:59.71 spid18s conversia date 'Test_RO_FG' din versiunea 661 la versiunea curentă 706.
2012-05-04 21:03:59.71 spid18s 'Test_RO_FG' running la pasul upgrade de la versiunea 661 versiune 668 acoperire de date.



Înapoi la început | Trimite?i feedback

Proprietă?i

ID articol: 2710782 - Ultima examinare: 18 iunie 2012 - Revizie: 2.0
SE APLICĂ LA:
  • Microsoft SQL Server 2012 Enterprise
Cuvinte cheie: 
kbsurveynew kbprb kbtshoot kbmt KB2710782 KbMtro
Traducere automată
IMPORTANT: Acest articol a fost tradus de software-ul de traducere automată Microsoft, si nu de un traducător. Microsoft vă oferă atât articole traduse de persoane, cât și articole traduse automat, astfel incat aveti access la toate articolele din Baza noastră de informatii în limba dvs. materna. Totuși, un articol tradus automat nu este întotdeauna perfect. Acesta poate conține greșeli de vocabular, sintaxă sau gramatică, la fel cum un vorbitor străin poate face greșeli vorbind limba dvs. materna. Compania Microsoft nu este responsabilă pentru nici o inexactitate, eroare sau daună cauzată de traducerea necorespunzătoare a conținutului sau de utilizarea traducerii necorespunzătoare de către clienții nostri. De asemenea, Microsoft actualizează frecvent software-ul de traducere automată.
Face?i clic aici pentru a vizualiza versiunea în limba engleză a acestui articol: 2710782
(http://support.microsoft.com/kb/2710782/en-us/ )
Înapoi la început | Trimite?i feedback

Trimite?i feedback

 
Înapoi la începutÎnapoi la început