Un mesaj informativ 9017 este conectat atunci când începe o instanță de SQL Server sau restabili sau atașați o bază acoperire de date

Traduceri articole Traduceri articole
ID articol: 2882905 - View products that this article applies to.
Măriți totul | Reduceți totul

În această pagină

Simptome

Când începe o instanță a Microsoft SQL Server sau restabili sau atașați o bază acoperire de date, un mesaj informativ 9017, care seamănă cu următorul text este înregistrată în Jurnalul de erori SQL Server:

Baza acoperire de date dbName a mai mult n Virtual fișierele jurnal care este excesivă. Prea multe fișierele jurnal virtual poate provoca pornire lung și rezervă ori. Ia în considerare atenuarea jurnal și folosind un increment de diferite de creștere pentru a reduce numărul de fișiere de jurnal virtual.

Prea multe fișierele jurnal virtual poate afecta negativ timpul de recuperare acoperire de date.

În plus, dacă utiliza?i tehnologii de replicare sau Mirroring acoperire de date din mediul dumneavoastră, este posibil să observați probleme de performanță cu aceste tehnologii.

Cauză

Această problemă apare când specificați valori mici pentru VĂ parametru pentru fișierul jurnal.

Motorul de baze acoperire de date SQL Server imparte fiecare fizice log dosar intern în fișierele jurnal mai multe virtuală (VLFs). SQL Server 2008 R2 pachet Service Pack 2 și versiunile ulterioare a introdus un nou mesaj (9017) care este conectat atunci când o bază acoperire de date începe (din cauza incepand de o instanță de SQL Server sau atașarea sau restaurarea bazei de date) și are mai mult de 1000 VLFs în SQL Server 2008 R2 sau are mai mult de 10.000 de VLFS în SQL Server 2012.

NotăÎn SQL Server 2012, deși acest mesaj este conectat la baza acoperire de date a 10.000 de VLFs, mesajul efectiv care este raportată în Jurnalul de eroare incorect afirmă "1000 VLF." Practic, avertismentul apare după 10.000 VLFs. Cu toate acestea, mesajul rapoarte 1.000 VLFs. Această problemă va fi corectat într-o versiune viitoare.

Pentru mai multe informații despre modul în care numărul crescut de VLFs ar putea duce la probleme de performanță într-reproducerea sau oglindire configurații acoperire de date, consultați secțiunea "Mai multe informații".

Rezoluție

Pentru a rezolva această problemă, urmați acești pași:
  1. Reducerea dumneavoastră Jurnalul de tranzacții utilizând DBCC SHRINKDB sau folosind SQL Server Management Studio.
  2. Crește dimensiunea de fișier jurnal de tranzacții la o valoare mai mare pentru a evita creșteri auto frecvente. Pentru mai multe informații, consultați următorul subiect pe site-ul SQL Server Books Online:

    http://MSDN.Microsoft.com/en-us/library/ms365418.aspx#AddOrEnlarge
  3. Crește VĂ parametru la o valoare mai mare decât ceea ce este configurat în prezent. Acest lucru se bazează pe activitate de firmă de baza acoperire de date și cât de des vă fișier jurnal este în creștere.

În plus, vă recomandăm să luați în considerare instalarea stabilește următoarele, în funcție de versiunea de SQL Server care se execută în prezent:


Informații suplimentare

Cum pentru a verifica numărul de segmente VLF într-o bază acoperire de date

Puteți găsi numărul de segmente VLF într-o bază acoperire de date de către găsirea diferența dintre cele mai vechi și mai recente jurnal de numere de secvență (LSNs) de tranzacție jurnal de backup pentru baza acoperire de date.

Puteți găsi LSN de tranzacție jurnal rezervă prin verificarea dumneavoastră Jurnalul de erori SQL Server pentru un mesaj care seamănă cu următorul:

{Jurnal a fost susținută. Baza de date: mydbname, creation_date_(time): data(marcă de timp), prima LSN: 1: 5068:70, ultima LSN: 1: 5108:1, număr de dispozitive de memorie: 1, dispozitiv de informații: (FILE = 1, tip = disc: {C:\folder\logbackup1.trn}). Acesta este un mesaj informativ numai. Nici un utilizator de acțiune este necesară.

NotăÎn acest mesaj, LSN de Jurnalul de tranzacții este1. (Acesta este primul număr înainte de colon prima în "LSN: 1:5068:70.")

Pentru aceasta, urmați acești pași:
  1. Găsi LSN earliesttransaction Jurnalul de rezervă pentru baza acoperire de date în dumneavoastră eroare SQL (de exemplu, LSN: 1:5108:1).
  2. Găsi cele mai recente LSN pentru tranzacție jurnal de backup în eroare SQL (de exemplu, LSN:10, 235: 5108: 1).
  3. Numărul de segmente VLF este diferența dintre LSN mai recente și mai devreme LSN (în acest caz, este 10,235-1 = 10,234).

Efectul de o mulțime de VLFs pe replicarea

Prea multe fișiere log pot afecta replicare, deoarece procesul de cititor de jurnal trebuie să scaneze fiecare fișier jurnal virtual pentru tranzacții care sunt marcate pentru replicare. Puteți vedea acest comportament prin urmărirea performanța de sp_replcmds stocate procedură. Jurnalul cititorului procesul utilizările sp_replcmds stocate procedură pentru a scana fișierele jurnal virtual și a citi tranzacțiile care sunt marcate pentru replicare. 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:

949523 Latenta de o replicare tranzacțională este ridicat în SQL Server 2005, atunci când valoarea proprietății "Dimensiunea inițială" și valoarea proprietății Autogrowth sunt mici

Efectul de o mulțime de VLFs pe baza acoperire de date de oglindire

Prea multe fișierele jurnal poate afecta oglindirea bazei acoperire de date. 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:

2455009FIX: Performanță lentă atunci când vă recupera o bază acoperire de date în cazul în care există multe VLFs în interiorul Jurnalul de tranzacții în SQL Server 2005, SQL Server 2008, SQL Server 2008 R2 sau

Referințe

Pentru informații suplimentare, consultați următoarele subiecte de pe site web Rețea Microsoft pentru dezvoltatori (MSDN):

Scădere Jurnalul de tranzacții

Factori care poate întârzia jurnal trunchiere

Tranzacție jurnal trunchiere

Tranzacție jurnal arhitectura logică

Tranzacție jurnal arhitecturii fizice


Proprietă?i

ID articol: 2882905 - Ultima examinare: 12 septembrie 2013 - Revizie: 1.0
Se aplică la:
  • Microsoft SQL Server 2012 Developer
  • Microsoft SQL Server 2012 Enterprise
  • Microsoft SQL Server 2012 Standard
  • Microsoft SQL Server 2008 R2 Datacenter
  • Microsoft SQL Server 2008 R2 Developer
  • Microsoft SQL Server 2008 R2 Enterprise
  • Microsoft SQL Server 2008 R2 Standard
  • Microsoft SQL Server 2008 Developer
  • Microsoft SQL Server 2008 Enterprise
  • Microsoft SQL Server 2008 Standard
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Standard Edition
Cuvinte cheie: 
kbexpertiseinter kbprb kbsurveynew kbmt KB2882905 KbMtro
Traducere automată
IMPORTANT: Acest articol este tradus cu ajutorul software-ului Microsoft de traducere automată ?i poate fi corectat prin intermediul tehnologiei Community Translation Framework (CTF). Microsoft oferă articole traduse automat, post-editate de comunitate ?i articole traduse de oameni, pentru a permite accesul la toate articolele din Baza noastră de cuno?tin?e în mai multe limbi. Articolele traduse automat ?i post-editate pot con?ine gre?eli de vocabular, sintaxă ?i/sau gramatică. Microsoft nu este responsabil de inexactită?ile, erorile sau daunele cauzate de traducerea gre?ită a con?inutului sau de utilizarea acestuia de către clien?i. Găsi?i mai multe informa?ii despre traducerea în colaborare la http://support.microsoft.com/gp/machine-translation-corrections/ro.
Face?i clic aici pentru a vizualiza versiunea în limba engleză a acestui articol: 2882905

Trimite?i feedback

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com