Un jurnal de tranzacţii creste neasteptat sau devine complet în SQL Server

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: 317375
Rezumat
Dacă opţiunea autogrow este stabilit în Microsoft SQL Server 2005 şi ulterioare versiuni, SQL Server 2000, şi SQL Server 7.0, fişierele de log tranzacţia poate extinde automat la dimensiunea de fişier jurnal maximă de 2 terabytes (TB) per fişier jurnal.

De obicei, dimensiunea de fişier jurnal de tranzacţii stabilizează atunci când acesta poate stoca numărul maxim de tranzacții care pot apărea între tranzacţie jurnal truncations care sunt declanşate de punctele de control sau tranzacţie jurnal de backup-uri.

Cu toate acestea, în unele cazuri tranzacţie jurnal mai deveni foarte mari şi a alerga afară de spaţiu sau de a deveni complet. De obicei, primiţi următorul mesaj de eroare atunci când un fişier jurnal de tranzacţii folosește spațiu-disc disponibil şi nu se poate extinde mai:
Eroare: 9002, severitatea: 17, stat: 2
Fişierul jurnal pentru baza acoperire de date ' %. * ls' este plin.
Dacă utilizaţi SQL Server 2005, primiţi un mesaj de eroare asemănător următorului:
Eroare: 9002, severitatea: 17, stat: 2
Jurnalul de tranzacţii pentru baza acoperire de date ' %. * ls' este plin. Pentru a afla de ce nu pot fi refolosite spaţiu în Jurnalul de, a se vedea coloana log_reuse_wait_desc în sys.databases
Pe lângă acest mesaj de eroare, SQL Server poate marca baze acoperire de date ca suspect, din cauza lipsei de spaţiu pentru extinderea de Jurnalul de tranzacţii. Pentru mai multe informaţii despre modul de a recupera de la această situaţie, consultaţi subiectul "Spațiu-disc insuficient" în SQL Server Books Online.

În plus, tranzacţia Jurnalul de expansiune pot apărea pentru unul din următoarele motive sau în unul dintre următoarele scenarii:
  • Un fişier jurnal de tranzacţii foarte mare.
  • Tranzacţiile poate eşua şi pot începe să se rostogolească înapoi.
  • Tranzacţiile poate lua o lungă perioadă de marcă de timp pentru a finaliza.
  • Pot apărea probleme de performanţă.
  • Blocarea pot să apară.
  • Baza acoperire de date este participarea la un grup de disponibilitatea AlwaysOn.
Informaţii suplimentare
Tranzacţia Jurnalul de expansiune pot să apară pentru unul din următoarele motive sau scenarii.


Notă În SQL Server 2005 şi versiunile ulterioare, puteţi revizui coloanele log_reuse_wait şi log_reuse_wait_desc de sys.databases catalog de vedere pentru a determina ce tranzacţie jurnal spaţiu nu este reutilizat şi de ce nu pot fi trunchiate Jurnalul de tranzacţii.


Tranzacţiile nevalidate
Explicită tranzacţii rămân neangajate dacă nu emiteţi o comandă explicită de COMITERE sau ROLLBACK. Acest lucru apare cel mai frecvent atunci când o aplicaţie emite o revocare sau o comandă ucide Transact-SQL fără o comanda corespunzătoare de ROLLBACK. Anularea tranzactiei apare, dar ea nu roll-back. Prin urmare, SQL Server nu pot trunchia fiecare tranzacţie care apare dupa acest lucru, deoarece tranzacţia avortat este încă deschisă. Utilizaţi referinţa DBCC OPENTRAN Transact-SQL pentru a verifica că nu există o tranzacţie activă în baza acoperire de date la un anumit moment. Pentru mai multe informaţii despre acest scenariu special, faceţi clic pe următoarele numere de articol pentru a vedea articolele în bază de cunoştinţe Microsoft:
295108 Tranzacţii incomplete pot deţine numărul mare de blocări şi blocarea caz
171224 Înţelegerea modului în care funcţionează comanda ucide Transact-SQL
În plus, consultaţi subiectul "DBCC OPENTRAN" în SQL Server Books Online.

Scenarii care pot duce la necontractate tranzacţii:
  • Un design de aplicare, care presupune că toate erorile de causerollbacks.
  • Un design de aplicare care nu consideră complet că SQL Server comportamentul atunci când se derulează înapoi numit tranzacţii sau special imbricate numit tranzacţii. Dacă încercaţi să se rostogolească înapoi la o tranzacţie de interior-numit, primiţi următorul mesaj de eroare:
    Server: Msg 6401, nivel 16, stat 1, linia 13 nu poate derula înapoi InnerTran. Notransaction sau savepoint cu acest nume a fost găsit.
    După SQL Servergenerates mesajul de eroare, acesta Urmărire să următoarea declaraţie. Acest lucru este bydesign. Pentru mai multe informaţii, consultaţi subiectul "Tranzacţii imbricate" sau "În interiorul SQLServer" în SQL Server Books Online.

    Vă recomandăm următoarele atunci când proiectaţi cererea dumneavoastră:
    • unitate de doar o singură tranzacţie stilou (ia în considerare posibilitatea ca un alt proces poate suna a ta).
    • Verifica @@TRANCOUNT înainte de a vă elibera o confirmare, o revenire, o ÎNTOARCERE, sau un similar cu comanda sau declaraţie.
    • Scrie codul cu presupunerea că o altă @@TRANCOUNT s-ar putea "Cuibul" a ta şi un plan de @@TRANCOUNT exterior să fie laminate înapoi, atunci când apare o eroare.
    • Revizuire savepoint şi mark opţiuni pentru tranzacţii. (Acestea nu elibera încuietori!)
    • Efectuaţi testarea completă.
  • O aplicaţie care permite pentru interacţiunea cu utilizatorul în interiorul tranzacţii. Acest lucru face ca tranzacţia să rămână deschise pentru o lungă perioadă de marcă de timp, şi această cauzele blocarea şi tranzacţia log creştere deoarece tranzacţia deschise nu pot fi trunchiate şi tranzacţiile noi sunt adăugate la jurnal după tranzacţia deschise.
  • O aplicaţie care nu verifică @@TRANCOUNT la verifythat nu sunt nici tranzacţiile deschis.
  • De reţea sau alte erori care închide applicationconnection client de SQL Server, fără a informându-l.
  • Gruparea de conexiuni. După ce sunt create fire de lucrător, SQL Server le reutilizează dacă acestea nu sunt service o conexiune. În cazul în care o conexiune utilizator începe o tranzacţie şi deconectează înainte de a comite sau derularea înapoi a tranzacţiei, şi o conexiune după care refoloseşte acelaşi fir, tranzacţie anterioară rămâne încă deschisă. Această situaţie rezultate în încuietori care rămâne deschisă din tranzacţie anterioară şi previne trunchierii tranzacţiilor comise în jurnal. Acest lucru duce la mare log dosar sizes. Pentru mai multe informaţii despre gruparea de conexiuni, faceţi clic pe următorul număr de articol pentru a vedea articolul în bază de cunoştinţe Microsoft:
    164221 Cum se activează gruparea de conexiuni într-o aplicație ODBC


Foarte mari tranzacţii
Jurnal de înregistrări în fişierele jurnal de tranzacţii sunt trunchiate pe tranzacţie de tranzacţie. Dacă domeniul de tranzacţii este mare, că tranzacţie şi orice tranzacţii început după ea nu sunt eliminate din jurnalul de tranzacţii excepţia cazului în care este finalizat. Acest lucru poate duce la fişierele mari de jurnal. Dacă tranzacţia este suficient de mare, fişierul jurnal ar putea folosi până spaţiu disponibil pe disc şi cauza "tranzacţie jurnal plin" tipul de mesaj de eroare, cum ar fi eroare 9002. Pentru mai multe informaţii despre ce să fac atunci când primiţi acest tip de mesaj de eroare, consultaţi secţiunea "Informaţii suplimentare" din acest articol. În plus, este nevoie de o mulţime de marcă de timp şi SQL Server globale pentru a derula înapoi mari tranzacţii.

Operaţiuni: DBCC DBREINDEX şi de a crea indicele
Datorită schimbărilor în modelul de recuperare în SQL Server 2000, când utilizaţi în modul de recuperare completă şi executaţi DBCC DBREINDEX, Jurnalul de tranzacţii poate extinde în mod semnificativ mai comparativ de SQL Server 7.0 într-un mod de recuperare echivalente cu utilizarea SELECT INTO sau copie în vrac şi cu "Trunc. Logoff pe chkpt.".

Deşi dimensiunea de Jurnalul de tranzacţii după operaţiunea de DBREINDEX ar putea fi o problemă, această abordare oferă o performanţă mai bună jurnal de restaurare.

La restaurarea la tranzacţie jurnal de backup-uri
Acest lucru este descris în următorul articol din bază de cunoştinţe Microsoft:
232196 Spațiul jurnalului folosite pare să crească după restoring de la spate

Dacă setaţi SQL Server 2000 pentru a utiliza modul de Bulk-Logged şi când emite o declaraţie copiere masivă sau SELECT INTO, fiecare măsură schimbat este marcat şi apoi susţinută când aţi spate sus Jurnalul de tranzacţii. Deşi acest lucru vă permite să înapoi sus jurnalele de tranzacţie şi recupera din esecurile chiar şi după ce efectuaţi operaţii în bloc, aceasta adaugă la dimensiunea de jurnalele de tranzacţie. SQL Server 7.0 include această caracteristică. SQL Server 7.0 numai înregistrările extensii care sunt schimbate, dar nu extensii reale. Prin urmare, logare foloseste în mod semnificativ mai mult spaţiu în SQL Server 2000 decât în SQL Server 7.0 în modul de vrac-Log, dar nu la fel de mult ca o face în mod complet.

Aplicaţiile client nu procesează toate rezultatele
Dacă emiteţi o interogare SQL Server şi nu ocupa rezultatele imediat, puteţi fi exploataţie încuietori şi reducerea concurentei pe server.

De exemplu, să presupunem că aveţi emite o interogare care necesită rânduri de două pagini pentru a popula setul rezultat. SQL Server interpreteaza, compilează şi se execută interogarea. Acest lucru înseamnă că partajate încuietori sunt adăugate pe două pagini care conţin rânduri că trebuie să aveţi pentru a satisface interogare. În plus, presupunem că nu toate rândurile se potrivesc pe un pachet de SQL Server TDS (metoda prin care comunica cu clientul server). TDS pachete sunt pline şi trimis către client. Dacă toate rândurile de pe prima pagina se potrivesc pe pachet TDS, SQL Server eliberează de blocare partajate pe acea pagină, dar lasă o blocare partajate pe pagina a doua. SQL Server apoi asteapta pentru client de a solicita mai multe date (puteţi face acest lucru folosind DBNEXTROW/DBRESULTS, SQLNextRow/SQLResults sau FetchLast/FetchFirst de exemplu).

Acest lucru înseamnă că blocare partajat este ţinut până când clientul solicită restul datelor. Alte procese care solicita datele de la pagina a doua poate fi blocat.

Interogări marcă de timp înainte de o tranzacţie jurnal finisaje extinderea şi primiţi mesaje de eroare "Log complet" false
În această situaţie, deşi nu există suficient spațiu-disc, încă primiţi un "spaţiul" mesaj de eroare.

Această situaţie variază pentru SQL Server 7.0 şi SQL Server 2000.

O interogare poate provoca Jurnalul de tranzacţii pentru a extinde automat dacă jurnalul de tranzacţii este aproape plin. Acest lucru poate dura un marcă de timp suplimentar, iar o interogare poate fi oprit sau poate depăși perioada sa de expirare din acest motiv. SQL Server 7.0 returnează eroare 9002 în această situaţie. Această problemă nu se aplică SQL Server 2000.

În SQL Server 2000, în cazul în care aveţi opţiunea de auto-psihiatru activat pentru o bază acoperire de date, există o foarte mici de marcă de timp în care o tranzacţie jurnal încearcă să se extindă automat. Cu toate acestea, ea nu poate extinde deoarece funcţia de auto-psihiatru se execută în acelaşi marcă de timp. Acest lucru poate provoca, de asemenea, cazuri fals de eroare 9002.

De obicei, extinderea automat fişierele de log tranzacţia apare rapid. Cu toate acestea, în următoarele situaţii, poate dura mai mult decât de obicei:
  • Incremente de creştere sunt prea mici.
  • Serverul este lent din diverse motive.
  • hard disk nu sunt suficient de repede.


Unreplicated tranzacţii
Tranzacţie jurnal dimensiunea bazei acoperire de date distribuitor poate extinde dacă utilizaţi replicare. Tranzacțiile care afecta obiectele care sunt reproduse sunt marcate ca "Pentru replicare." Aceste tranzacţii, precum tranzacţii neangajate, nu se șterg după punct de control sau după tu spate sus Jurnalul de tranzacţii până sarcina de cititor de jurnal copiază tranzacţiilor în baza acoperire de date de distribuţie şi se demarchează le. Dacă o problemă cu sarcina de cititor de jurnal îl împiedică să lectură aceste tranzacţii în baza acoperire de date publica , dimensiunea de Jurnalul de tranzacţii pot continua să se extindă ca numărul de tranzacţii non-reproducere creşte. Utilizaţi referinţa DBCC OPENTRAN Transact-SQL pentru a identifica tranzacţia mai vechi non-reproducere.

Pentru mai multe informaţii despre cum se depanează unreplicated tranzacţii, consultaţi subiectele "sp_replcounters" şi "sp_repldone" din SQL Server Books Online.

Pentru mai multe informaţii, faceţi clic pe următoarele numere de articol pentru a vedea articolele în bază de cunoştinţe Microsoft:
306769 FIX: Jurnal de tranzacţii de instantaneul bazei acoperire de date publicate pot fi trunchiate
240039 FIX: DBCC OPENTRAN raport replicare informaţii
198514 FIX: Restaurare noul server cauzeaza tranzacţii să rămână în jurnal


AlwaysOn 'AVAILABILITY_REPLICA' aplicarea tranzacţie jurnal înregistrări la o bază acoperire de date secundare

În SQL Server 2012 cu grupuri de disponibilitate AlwaysOn activat, este posibil să vedeţi următoarele mesaj în Jurnalul de erori SQL:

Eroare: 9002, severitatea: 17, stat: 9.
Jurnalul de tranzacţii pentru baza acoperire de date ' %. * ls' este plin din cauza "AVAILABILITY_REPLICA"

AVAILABILITY_REPLICA log_reuse_wait indică o replica de grupuri de disponibilitate AlwaysOn secundar este aplicarea tranzacţie jurnal înregistrările acestei baze acoperire de date la o bază acoperire de date secundare corespunzătoare.

Există două scenarii care pot duce la jurnal de creştere într-o bază acoperire de date de disponibilitate şi AVAILABILITY_REPLICA' log_reuse_wait:

Scenariul 1: Furnizarea de latenţă logat modificări secundare

Atunci când o tranzacţie este efectuată la primar, blocuri logat trebuie livrate şi călit în fişierul jurnal acoperire de date la secundar. Orice întârziere va preveni trunchierea modificărilor înregistrate în baza acoperire de date la reproducerea primare.

Scenariul 2: Redo latenţă

După ce călit în fişierul jurnal secundare acoperire de date un thread dedicat redo se aplică înregistrări jurnal.

Dacă operaţiunea de refacere nu este în măsură să ţină pasul cu Jurnalul de tranzacţii generate, se pot duce la jurnal de creştere. Primar va fi în imposibilitatea de a trunchia Jurnalul de tranzacţii în cazul în care operaţiunea de refacere secundar replica este în spatele în aceste modificări se aplică o bază acoperire de date secundare corespunzătoare. Dacă există mai multe secundare, pentru a identifica care baza acoperire de date secundară este amânarea jurnal trunchierii, compară coloana truncation_lsn de vedere management dinamic sys.dm_hadr_database_replica_states în mai multe secundare.

Utilizaţi tabloul de bord AlwaysOn si sys.dm_hadr_database_replica_states management dinamic pentru a vă ajuta monitoriza Jurnalul trimite coadă şi refaceţi coadă. Unele câmpuri cheie sunt:

CâmpDescriere
log_send_queue_sizeSuma de înregistrări jurnal care nu au ajuns la replica secundar
log_send_rateRata la care Jurnalul de înregistrări sunt trimise la bazele acoperire de date secundară
redo_queue_sizeCantitatea de înregistrări jurnal în fişierele jurnal de reproduceri secundar care a nu încă fost refăcut, în kiloocteţi (KO)
redo_rateRata la care înregistrările jurnal sunt fiind refăcut pe o bază acoperire de date secundare dat, în kiloocteţi (KO) / al doilea
last_redone_lsnJurnal real număr de secvenţă al ultimei înregistrări jurnal care a fost refăcut în baza acoperire de date secundare. last_redone_lsn este întotdeauna mai puţin decât last_hardened_lsn
last_received_lsnJurnal bloc ID identificare punctul până la care au fost primite toate blocurile de jurnal de replica secundar care găzduiește baza acoperire de date secundare. Reflectă un ID de log-bloc căptuşit cu zerouri. Nu este un jurnal real număr de secvenţă.

Notă Pentru mai multe informaţii despre sys.dm_hadr_database_replica_states, consultaţi următoarele site-ul TechNet:

http://technet.Microsoft.com/en-us/library/ff877972.aspx



Informaţii avansate
Jurnalul de tranzacţii pentru orice bază acoperire de date este administrat ca un set de fişiere de jurnal virtual (VLFs). SQL Server determină VLF dosar sizes intern bazate pe dimensiunea totală a log dosar şi Incrementul de creştere care este utilizat atunci când log se extinde. Un jurnal întotdeauna se extinde în unităţi de toată VLFs şi se poate comprima doar la limita VLF. O VLF poate exista într-una din trei stări: ACTIVE, RECUPERABILĂ şi REFOLOSIBILE.
  • Activ: O parte activă a jurnal incepe de la minim jurnal număr de secvenţă (LSN) care reprezintă o tranzacţie activă (necontractate). O parte activă a jurnal se termină la LSN ultimul-scris. Orice VLFs care conţin orice parte din jurnalul activă sunt considerate active VLFs. (spaţiu nefolosit în Jurnalul fizic nu este o parte din orice VLF).
  • RECUPERABILĂ: partea de jurnal care vine înainte de tranzacţie activ cel mai vechi numai este necesară pentru a menţine o secvenţă de jurnal de rezervă pentru recuperare.
  • REFOLOSIBILE: dacă tu nu sunt menţinerea tranzacţie jurnal de backup-uri, sau în cazul în care youalready susţinute de jurnal, SQL Server reutilizează VLFs înainte de activetransaction mai vechi.
Când SQL Server ajunge la sfârşitul fişierul jurnal fizice, începe reutilizarea că spaţiul în fişierul fizic prin emiterea de o operaţie de CIRCLING înapoi la începutul de fişiere. În vigoare, SQL Server reciclează spaţiul în fişierul jurnal, care nu mai este necesară pentru scopuri de recuperare sau de rezervă. În cazul în care este întreținut o secvenţă de rezervă jurnal, partea din jurnalul înainte de minim LSN nu se poate suprascrie până când aţi spate sus sau trunchia acele înregistrări jurnal. După ce efectuaţi backup jurnal, SQL Server poate cerc la începutul fişierului. După SQL Server cercurile înapoi pentru a începe să scrie jurnal înregistrări mai devreme în fişierul jurnal, partea reutilizabile de jurnal este apoi între sfârşitul de jurnal logică şi o parte activă a jurnal.

Pentru mai multe informații, consultați subiectul "Tranzacţie jurnal fizice arhitectura" în SQL Server Books Online. În plus, puteţi vedea o diagramă şi discuţii de acest lucru pe pagina 190 din "interior SQL Server 7.0" (Soukup, Ron. Interiorul Microsoft SQL Server 7.0, Microsoft Press, 1999), şi, de asemenea, pe paginile 182 la 186 de "interior SQL Server 2000" (Delaney, deea. In interiorul Microsoft SQL Server 2000, Microsoft Press, 2000). Bazele acoperire de date SQL Server 2000 şi SQL Server 7.0 au opţiuni de a autogrow şi autoshrink. Utilizaţi aceste opţiuni pentru a vă ajuta să comprimaţi sau extinde log-ul tranzacţiei.

Pentru mai multe informaţii despre modul în care aceste opţiuni poate afecta server, faceţi clic pe următorul număr de articol pentru a vedea articolul în bază de cunoştinţe Microsoft:
315512 Considerente de configurare Autogrow şi Autoshrink în SQL Server
Trunchiere de fişier jurnal de tranzacţii diferă de compresie de fişier jurnal de tranzacţii. Când SQL Server trunchiază un fişier jurnal de tranzacţii, aceasta înseamnă că conţinutul de acest fişier (de exemplu, tranzacţiile angajat) se elimină. Cu toate acestea, atunci când vizualizaţi dimensiunea fişierul dintr-o perspectivă de spaţiu disc (de exemplu, în Windows Explorer sau utilizând comanda dir ), dimensiunea rămâne neschimbat. Cu toate acestea, spaţiul din interiorul fişierul .ldf acum pot fi refolosite de noi tranzacţii. Numai atunci când SQL Server se micşorează dimensiunea de fişier jurnal de tranzacţii vedeţi de fapt o schimbare în mărimea fizică din fişierul jurnal.

Pentru mai multe informaţii despre cum la spre crevet jurnalele de tranzacţie, faceţi clic pe următoarele numere de articol pentru a vedea articolele în bază de cunoştinţe Microsoft:
256650 Cum de a micşora Jurnalul de tranzacţii SQL Server 7.0
272318 Scădere Jurnalul de tranzacţii în SQL Server 2000 cu DBCC SHRINKFILE
Pentru mai multe informaţii despre SQL Server 6.5 tranzacţie jurnal de utilizare, faceţi clic pe următorul număr de articol pentru a vedea articolul în bază de cunoştinţe Microsoft:
110139 Cauzele de SQL tranzacţie jurnal de umplere

Cum de a localiza interogările care consuma o cantitate mare de spaţiu de jurnal în SQL Server 2005 şi versiunile ulterioare

În SQL Server 2005 şi versiunile ulterioare, puteţi utiliza vizualizarea sys.dm_tran_database_transactions management dinamic (DMV) a localiza interogări care consumă cantităţi mari de spaţiu de jurnal. Următoarele coloane în sys.dm_tran_database_transactions DMV pot fi utile:
  • database_transaction_log_bytes_used
  • database_transaction_log_bytes_used_system
  • database_transaction_log_bytes_reserved
  • database_transaction_log_bytes_reserved_system
  • database_transaction_log_record_count
Poate interogare în coloana de sql_handle a sys.dm_exec_requests DMV pentru a obţine textul declaraţie reală care consumă cantităţi mari de spaţiu de jurnal. Puteţi face acest lucru prin aderarea sys.dm_tran_database_transactions DMV şi sys.dm_tran_session_transactions DMV pe coloana de transaction_id, şi apoi să adăugaţi o asociere suplimentare cu sys.dm_exec_requests pe coloana session_id.

Pentru mai multe informaţii despre sys.dm_tran_database_transactions DMV, du-te la sys.dm_tran_database_transactions (Transact-SQL) Site-ul Reţea Microsoft pentru dezvoltatori (MSDN).

Pentru mai multe informaţii despre sys.dm_tran_session_transactions DMV, du-te la sys.dm_tran_session_transactions (Transact-SQL) Site-ul MSDN.

Pentru mai multe informaţii despre sys.dm_exec_requests DMV, du-te la sys.dm_exec_requests (Transact-SQL) Site-ul MSDN.

Avertisment: acest articol a fost tradus automat

Propriedades

ID do Artigo: 317375 - Última Revisão: 01/13/2014 17:52:00 - Revisão: 3.0

Microsoft SQL Server 2012 Standard, Microsoft SQL Server 2012 Developer, Microsoft SQL Server 2012 Enterprise, Microsoft SQL Server 2012 Express, Microsoft SQL Server 2008 R2 Standard, Microsoft SQL Server 2008 R2 Developer, Microsoft SQL Server 2008 R2 Enterprise, Microsoft SQL Server 2008 R2 Express, Microsoft SQL Server 2008 Standard, Microsoft SQL Server 2008 Developer, Microsoft SQL Server 2008 Enterprise, Microsoft SQL Server 2008 Express, Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2005 Express Edition, Microsoft SQL Server 2005 Workgroup Edition, Microsoft SQL Server 2000 Standard Edition, Microsoft SQL Server 7.0 Standard Edition

  • kbsqlsetup kbinfo kbmt KB317375 KbMtro
Comentários