KB2653893-remediere: durează mult timp pentru a restaura o bază de date în SQL Server 2008 R2 sau în SQL Server 2008 sau în SQL 2012

Simptome

Poate dura mult timp pentru a restaura o bază de date în Microsoft SQL Server 2008 R2 sau în Microsoft SQL Server 2008 sau în Microsoft SQL Server 2012.

Cauză

Această problemă apare deoarece durează mult timp pentru a construi lista de fișiere jurnal virtuale (VLF) atunci când există mai multe VLFs în baza de date.

Rezolvare

Stare

Microsoft a confirmat că aceasta este o problemă în produsele Microsoft enumerate în secțiunea „Se aplică la”.

Mai multe informații

Puteți să verificați numărul de segmente VLF revizuind fișierul jurnal de erori SQL, apoi găsind numărul secvenței jurnal (LSN) în fiecare fișier backup jurnal de tranzacții. Primele cifre înainte de simbolul de colon din LSNs corespund numărului de LSN. De exemplu, primul număr din primul mesaj informativ pentru LSN este 1. Cu toate acestea, primul număr din al doilea mesaj informativ pentru LSN este 100001. În acest scenariu, există 100.000 VLFs care sunt utilizate între timpul primului mesaj informativ și al celui de-al doilea mesaj informativ. Prin urmare, Jurnalul de tranzacții fragmentate conectat care are mai multe fișiere jurnal virtuale (VLFs) seamănă cu următorul:

{Log s-a făcut backup. Bază de date: mydbname, data creării (oră): 2010/07/08 (12:36:46), prima LSN: 1:5068:70, Ultima LSN: 1:5108:1, numărul de dispozitive dump: 1, informații dispozitiv: (fișier = 1, tastați = disc: {' C:\folder\logbackup1.trn '}). Acesta este doar un mesaj informational. Nu este necesară nicio acțiune de utilizator. Log s-a făcut backup. Bază de date: mydbname, data creării (oră): 2010/07/08 (15:36:46), prima LSN: 100001:5108:1, Ultima LSN: 100002:5108:1, numărul de dispozitive dump: 1, informații dispozitiv: (fișier = 2, tastați = disc: {' C:\folder\logbackup2.trn '}). Acesta este doar un mesaj informational. Nu este necesară nicio acțiune de utilizator.}

Referințe

Pentru mai multe informații despre numerele de secvență de jurnal (LSN), vizitați următorul site Web MSDN:

Informații generale despre numerele de secvență de jurnal

Pentru mai multe informații despre modul în care o structură de fișier jurnal poate afecta timpul de recuperare a bazei de date, vizitați următorul site Web MSDN:

Cum o structură de fișier jurnal poate afecta timpul de recuperare a bazei de datePentru mai multe informații despre VLFs jurnal de tranzacții, vizitați următorul site Web MSDN:

Informații generale despre fișierul jurnal de tranzacții

Soluție de evitare

• Așteptați finalizarea operațiunii de restaurare sau recuperareDacă aveți o bază de date nerecuperată care se confruntă cu o performanță lentă atunci când restaurați sau recuperați baza de date, poate fi necesar să așteptați finalizarea operațiunii de restaurare sau de recuperare. De exemplu, este posibil să vedeți starea offline sau starea de recuperare în SQL Server Management Studio (SSMS) pentru o bază de date non-recuperată. Oprirea SQL Server nu oferă, de obicei, nicio ușurare pentru o recuperare lentă și poate dura mai mult timp pentru a repeta aceeași fază de analiză a recuperării, faza de refacere sau anulare.

• Evitați restaurarea secvenței jurnalului de tranzacții care conține mii de VLFsDacă vă confruntați cu o performanță lentă în timp ce restaurați și recuperați o bază de date utilizând un fișier backup, puteți evita restaurarea secvențelor jurnalului de tranzacții care conțin mii de VLFs. Pentru a identifica fișierul copie de rezervă care are cele mai multe fișiere jurnal virtuale înregistrate, utilizați următoarea instrucțiune pentru a vedea coloanele FirstLSN și LastLSN din fișierele backup din jurnal: restaurarea HEADERONLY de pe disc = ' C:\folder\file.trn ' puteți decide să evitați restaurarea fișierelor jurnal de backup. Sau puteți utiliza instrucțiunea oprire la în comenzile de restaurare pentru a evita părțile extrem de fragmentate ale jurnalelor de tranzacții. Dacă nu restaurați complet secvențele de jurnal până la cel mai recent punct din timpul unui scenariu de recuperare a erorilor, pierderea de date apare în baza de date SQL Server. Această pierdere de date apare deoarece nu sunt păstrate toate tranzacțiile. Prin urmare, există o decizie de compromis pentru firme. Puteți restaura complet un jurnal de tranzacții foarte fragmentat. Cu toate acestea, operațiunea poate dura mai multe ore. Sau puteți utiliza instrucțiunea oprire la din recuperare pentru a opri recuperarea înainte de partea extrem de fragmentată a jurnalului. Cu toate acestea, orice tranzacții lipsă omise sunt pierdute.Notă Fără a instala această remediere rapidă, de obicei nu există recurs sigur pentru recuperarea accelerată după ce reporniți SQL Server. SQL Server trebuie să localizeze lista de VLFs pentru a analiza fișierele jurnal, pentru a reface tranzacțiile finalizate, apoi pentru a anula tranzacții incomplete pentru a termina recuperarea pentru a aduce baza de date online în siguranță. Nu puteți omite în siguranță tranzacțiile în timpul recuperării.