Conflictele de încuietori - poate cea mai răspândită și, în același timp, dificilă problemă la locul de muncă cu o bază de date. Dacă, de exemplu, pentru a accelera codul non-optim, puteți construi pur și simplu hardware "mușchi"
Conflictele de încuietori - poate cea mai răspândită și, în același timp, dificilă problemă la locul de muncă cu o bază de date. Dacă, de exemplu, pentru a accelera codul de sub-optim, vă puteți construi doar hardware-ul „mușchi“ și să uite problema, apoi blocați acest truc nu va funcționa: nu există aproape decizii nechibzuite nu permit întoarce, pentru a remedia situația trebuie să întoarceți capul și căutați rădăcina problemei. În acest articol, vom analiza doar cele mai populare "rădăcini", care se întâlnesc cel mai adesea, dezvăluind cazurile de închidere a utilizatorilor.
Rețineți că blocarea în sine nu este în nici un caz un rău ireconciliabil, care trebuie combătut în toate modurile posibile. Dimpotrivă, blocarea resurselor este un mecanism extrem de important pentru un sistem multi-utilizator, care asigură coerența și integritatea datelor prelucrate. Blocarea impusă de utilizator garantează că datele necesare nu vor fi modificate de o altă tranzacție, ceea ce înseamnă că utilizatorul va primi rezultatul așteptat al operației. Dar când tranzacțiile încep să blocheze resursele redundante care nu sunt necesare pentru sarcina curentă, problemele încep, utilizatorii se blochează, eficiența muncii scade brusc. Este cu astfel de probleme că vom lupta.
Înainte de a începe analiza problemelor, vom discuta câteva puncte importante:
În primul rând. Nu va fi o descriere a artefactelor clasice ale lecturii, modalități de a le trata; nivelurile de izolare a tranzacțiilor vor fi considerate ușor. Toate cele de mai sus - o teorie destul de generală, care este deja cu siguranță cunoscută cititorului. Dacă este necesar, aveți posibilitatea să perie pe aceeași MSDN (nivel de izolare tranzacție), iar în acest articol sa concentrat mai mult pe practică, digresiunea teoretică va fi în mod evident extinse de prisos.
Cu mult timp în urmă, în îndepărtat, îndepărtat ...
Se observă că mai mult de 20 de persoane sunt agățat pe de blocare, de așteptare pentru finalizarea tranzacțiilor de către 449. Căutarea pe MSDN pentru „stand-by de tip“ sugerează că toți acești utilizatori vor să scrie ceva la masă; O descriere a resursei ("TAB") indică faptul că nu este blocată o zonă mică, ci o tabelă întreagă.
O mică anchetă arată că cel mai adesea se întâmplă blocări în tabelul _1SJOURN - un singur jurnal de documente în 1C 7.7. Acest tabel stochează data, numărul și ID-ul fiecărui document scris în program. Problema este că, în momentul oricărui document, o suprapunere exclusivă pe întreaga masă este suprapusă. Așa: chiar dacă utilizatorii efectuează diferite tipuri de documente, la un moment dat poate fi înregistrat un singur document. Având un flux mare de documente (de exemplu, un număr mare de aplicații dintr-un magazin mic), acest comportament devine o problemă serioasă.
. Uneori se întorc
Arborele de blocare arată o imagine obișnuită: așteaptă o blocare exclusivă (LCK_M_IX), iar întreaga masă (TAB) este blocată. Ei bine, cel puțin o masă a unui document separat, nu o singură revistă - și asta e bine! Ce, din nou 1C "prea leneș"? De fapt, vina dezvoltatorului nu este aici. 1C 8.x în cererile lor nu impune încuietori de masă (cu excepția cazului când se lucrează cu tabele temporare - dar există tabele „live“ numai în aceeași sesiune, așa că nu ar trebui să împartă cu nimeni, astfel încât să puteți bloca toate în condiții de siguranță - nimeni nu va fi ofensat). În această situație, intră în joc mecanisme mai profunde - și anume, escaladarea blocărilor la nivelul MS SQL.
Fiecare blocare este în sine un obiect, a cărui service necesită timp CPU și RAM. Da, desigur, o blocare în scara unui server modern nu este mai mult decât o albină într-un hangar uriaș. Dar când astfel de albine ajung un întreg roi ... Aproximativ astfel, motivele DBMS, estimând numărul de încuietori impuse pe masă. Inițial, în cazul în care cererea nu dă indicații explicite (și 1C nu oferă astfel de instrucțiuni!) Pe masa stivuite „punctul“ de blocare a scrie sau la nivel de date de pagini. Dar atunci când un SGBD vede un mare număr de încuietori pe aceeași masă, din aceeași tranzacție sau la fel ca în deficitul de RAM acolo, se ia o decizie: în loc să sape mici încuietori pentru a impune una, dar nu mai mult. Ca rezultat, sarcina asupra resurselor hardware este redusă, totuși, chiar și acele rânduri ale tabelului, care nu au fost necesare în tranzacție, sunt capturate. Utilizatorii încep să se ciocnească mai des din cauza concurenței pentru aceleași mese, însă resursele sunt utilizate mai economic.
Înainte de a vă ocupa de escaladări de încuietori, va fi destul de ușor de înțeles, din cauza faptului că toate acestea apar. Poate că programul utilizează tranzacții prea lungi, schimbând datele în pachete mari. Sau, într-adevăr, sistemul pur și simplu nu are suficientă RAM liberă. În astfel de cazuri, este necesar pentru a trata cauza, mai degrabă decât o consecință - fiecare situație este plină de alte probleme, escaladarea de blocare - nu e cel mai rău dintre ei.
Revenind la 1C, trebuie amintit că orice manipulare a foii de calcul direct în baza de date (schimba opțiunile, adăugarea de indici, etc.) nu sunt stocate configurator și pot fi suprascrise de o altă restructurare. Deci merită pregătit un script care dezactivează escaladarea separată a tabelelor necesare și executați după actualizarea configurației. Din fericire, funcționarea dezactivării escaladării durează o fracțiune de secundă.
Pe de altă parte, nu există soluții "corecte" în administrarea bazelor de date, care sunt aplicabile oriunde și întotdeauna. În cazul în care utilizatorii rareori se confruntă cu încuietori de masă, dominate de tranzacții scurte sau bază de date nu încă crescut la volumul atunci când escaladarea va fi o problemă, deconectați escaladarea nu va contribui la accelerarea experiența utilizatorului, ci, dimpotrivă, duce la un consum excesiv de resurse. Ca întotdeauna în administrarea DB - orice instrument ar trebui să fie utilizat numai dacă există indicații explicite și cu o înțelegere clară a consecințelor.
Toate ilustrațiile date sunt obținute folosind sistemul de monitorizare PerfExpert
Trimiteți-le prietenilor: