Un blocaj este un lanț închis de blocare în care două sau mai multe fire se blochează reciproc, astfel încât nici unul dintre ele să nu poată continua execuția. În cazul în care fluxul de urmărire impas în SQL Server detectează un lanț bloc închis, unul dintre participanți într-un impas, el alege ca victimă, anulează pachetul actual de SPID, și role înapoi tranzacția sa, pentru a permite un alt SPID continua. Victima în impas va primi un mesaj de eroare 1205:
Tranzacția (ID-ul procesului 52) a fost blocată de resursele de blocare cu un alt proces și a fost aleasă ca victimă a blocajului. Renunțați la tranzacție.
Un blocaj este un tip special de script de blocare, dar blocarea și blocarea nu sunt același lucru. Uneori oamenii vorbesc despre un impas, deși, de fapt, văd că blochează.
Cu câteva excepții, blocările de blocare apar ca un efect secundar natural al blocării și nu pot fi considerate erori în funcționarea serverului SQL. O soluție tipică pentru a preveni blocarea este configurarea procedurilor stocate / codului aplicației sau modificarea schemei / indexării.
Citiți informațiile primite cu pavilionul -T1222 activat. Această informație va fi prezentă în jurnalul de erori al serverului SQL după ce se produce un blocaj.
Arata cam asa:
"Decodarea" informațiilor primite pentru a înțelege mai bine scenariul de blocare.
Informațiile despre blocaj sunt reprezentate de secțiunile "process-list" (listă de procese) și "resource-list" (lista de resurse). Un "proces" este un spid sau un flux de lucru care participă la un impas. Fiecare proces are propriul său identificator, cum ar fi "processdceda8". O resursă este o resursă ocupată (de regulă blocată) și eliberarea acesteia așteaptă unul dintre participanți. Îmi place să utilizez formatul de mai jos pentru a rezuma informațiile despre blocaj. Dacă vrei, poți sări peste acest pas, dar nu o fac; mă ajută să înțeleg mai clar situația impasului. Am evidențiat în galben datele din setul de rezultate când folosești 1222, astfel încât să poți restabili singur fotografia următoare.
Rulați solicitările implicate în blocarea blocării prin intermediul Advisorului de reglare a bazelor de date. Introduceți textul interogării în fereastra de interogare a Management Studio, selectați baza de date în contextul căreia ar trebui executată interogarea, faceți clic dreapta pe textul interogării și selectați "Analizați interogarea în DTA". Nu ratați acest pas; mai mult de jumătate din problemele care duc la blocarea blocajului sunt rezolvate pur și simplu prin adăugarea unui index adecvat, astfel încât una dintre solicitări să fie executată mai repede și să blocheze mai puține resurse. Dacă DTA recomandă indexarea clădirilor, creați-le și vedeți dacă blocajul este încă stocat.
Asigurați-vă că tranzacțiile dvs. sunt la fel de scurte ca și normele de afaceri. Evitați tranzacțiile implicite, deoarece acest model de gestionare a tranzacțiilor generează tranzacții inutile îndelungate.
Căutați alte modalități de îmbunătățire a performanței interogării. implicat într-un blocaj de blocare: fie prin schimbarea cererii, fie prin indexare. O interogare care blochează un număr minim de resurse este mai puțin probabil să ducă la un impas. Dacă există o scanare de tabel, o scanare index, un hashing caps sau o sortare a unei cantități mari de date în planul de interogare, acestea sunt indicatorii necesității îmbunătățirilor.
Dacă unul sau ambii spidori execută o tranzacție cu mai mulți operatori. poate fi necesar să configurați urmărirea profilului pentru a obține informații despre blocajul și pentru a identifica întregul set de interogări care determină blocarea. Din păcate, -T1204 și -T1222 arată doar două cereri, care sunt „înfundate ciclu“, dar este posibil ca una dintre încuietorile sa impus cereri anterioare făcute în cadrul aceleiași tranzacții.
Următoarele sunt recomandări generale care se aplică oricărui blocaj. Dacă după implementarea acestor recomandări problema nu este rezolvată, va trebui să vă plimbați mai mult problema și găsiți o soluție folosind un scenariu special. Mai jos este o scurtă listă de metode tipice, din care puteți alege cea mai potrivită metodă pentru a face față unui blocaj:
Accesați obiectele într-o singură ordine. Luați în considerare următoarele două pachete.
1. Începeți tranzacția
4. Angajați tranzacția
Aceste două pachete, cu o mare probabilitate, pot provoca un blocaj. Dacă ambele vor efectua pasul 3, fiecare dintre ele poate fi blocat de altul, deoarece ambele accesează o resursă pe care cealaltă conexiune a blocat-o în pasul 2.
Dacă ambele blocatoare utilizează același index, trebuie să creați un index care să ofere o cale de acces suplimentară pentru unul dintre spidente. De exemplu, adăugând un indice de grup acoperit la un SELECT implicat într-un blocaj, puteți preveni problema (cu condiția ca niciuna dintre cheile indexului de acoperire să nu fie modificată de un alt membru al blocajului).
Pe de altă parte, în cazul în care SPID devin părți impas din cauza faptului că calea alternativă (indecși) au fost folosite pentru a accesa linia de date necesare sau pagina, ia în considerare eliminarea unuia dintre indicii, sau utilizarea de carduri de index pentru ambele cereri utilizate în comun o cale de acces. Fiți precaut, rezultatul acestei abordări poate fi o scădere a productivității.
Blocările de blocare sunt un tip special de blocare în cazul în care două spids se blochează reciproc. Uneori, cel mai bun mod de a preveni apariția unui blocaj este blocarea forțată a unei tranzacții într-un punct anterior. De exemplu, dacă blocați în avans SPID A într-o tranzacție cu pat și SPID, apoi de la începutul SDID tranzacției și să nu fie în măsură de a obține resursele necesare pentru a pune capăt blocaj impus SPID B. Aceasta înseamnă că în mod intenționat iniția blocarea? Da, din moment ce resursele sunt deja blocate, nu va exista o situație de blocaj, și în acest sens, blocarea simplă este o soluție optimă pentru blocare. De asemenea, puteți continua să blocați cu indicii HOLDLOCK și UPDLOCK până la sfârșitul tranzacției spid B.
Dacă doriți să selectați un proces cu o prioritate mai mare ca victimă atunci când rezolvați un blocaj, pentru un proces cu o prioritate mai mică, puteți utiliza setarea SET DEADLOCK_PRIORITY LOW. Spid, pentru care este utilizată această setare, va fi întotdeauna selectată ca victimă atunci când apare un blocaj, la care va deveni membru.
Evitați utilizarea indexurilor grupate pe coloanele care se schimbă adesea. componente Modificări cheie coloane index de cluster va impune un sistem de blocare într-un indice de cluster (pentru a muta linia) și poate provoca blocarea tuturor indicele non-cluster (deoarece linia de pe foaia de la un index non-cluster asupra valorii de referință a cheii index al cluster).
În unele cazuri, poate fi util să folosiți sugestia NOLOCK dacă una dintre interogări este o instrucțiune SELECT. Deși acest mod este cel mai atractiv, pentru că este o soluție rapidă și ușoară în multe situații de blocare, folosiți această abordare cu atenție, deoarece aceasta aduce probleme care apar atunci când nivelul de izolare a tranzacției este citit neangajat (interogarea poate returna o reprezentare conflictuală a datelor). Dacă nu sunteți familiarizați cu problemele legate de utilizarea acestui nivel de izolare, consultați secțiunea "SET NIVELUL DE IZOLARE A TRANSACȚIEI" din SQL Books Online sau consultați experții cunoscuți înainte de a utiliza această opțiune.
Trimiteți-le prietenilor: