Momentan sunteți offline, așteptați să vă reconectați la internet

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

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
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.
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.
STARE
Microsoft a confirmat că aceasta este o problemă asociată cu produsele Microsoft enumerate în secţiunea „se aplică la".
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 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 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.
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.mdfrename Test_RO_FG_File1.ndf original_Test_RO_FG_File1.ndfrename Test_RW_FG_File1.ndf original_Test_RW_FG_File1.ndfrename 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 OFFLINEGO
  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.mdfrename Test_RO_FG_File1.ndf new_Test_RO_FG_File1.ndfrename Test_RW_FG_File1.ndf new_Test_RW_FG_File1.ndfrename 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 ONLINEGO
  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.mdfdel /P new_Test_RO_FG_File1.ndfdel /P new_Test_RW_FG_File1.ndfdel /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 ATTACHGO
    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.mdfrename Test_RO_FG_File1.ndf original_Test_RO_FG_File1.ndfrename Test_RW_FG_File1.ndf original_Test_RW_FG_File1.ndfrename 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 OFFLINEGO
  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.mdfrename Test_RO_FG_File1.ndf new_Test_RO_FG_File1.ndfrename Test_RW_FG_File1.ndf new_Test_RW_FG_File1.ndfrename 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 EMERGENCYGOALTER DATABASE Test_RO_FG_DB SET SINGLE_USERGODBCC CHECKDB (Test_RO_FG_DB, repair_allow_data_loss) WITH ALL_ERRORMSGSGOALTER DATABASE Test_RO_FG_DB SET MULTI_USERGO
  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.mdfdel /P new_Test_RO_FG_File1.ndfdel /P new_Test_RW_FG_File1.ndfdel /P new_Test_RO_FG_log.ldf
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.



Avertisment: acest articol a fost tradus automat

Proprietăți

ID articol: 2710782 - Ultima examinare: 06/18/2012 22:02:00 - Revizie: 2.0

Microsoft SQL Server 2012 Enterprise

  • kbsurveynew kbprb kbtshoot kbmt KB2710782 KbMtro
Feedback
html>tml>