Pe sisteme multi-utilizator rol important joacă organizare adecvată structuri şi înfiinţarea ecluzelor. Dacă nu există, utilizatorii vor trebui adesea să facă față erorilor cauzate de concurența pentru anumite resurse de sistem. Dar există o problemă de conflict de blocare care este familiară pentru mulți utilizatori. De ce apare un conflict de blocare 1C și cum să-l rezolvi?
Blocați conflictul în 1C 8.3 și semnificația acestuia
Pentru majoritatea utilizatorilor, un mesaj despre un conflict de blocare 1C înseamnă doar o eroare care îi împiedică să-și facă treaba. Vor să scape de această problemă cât mai repede posibil și să asedieze departamentul IT cu plângeri că „1C nu funcționează”.
Dar pentru administratorii de sistemși dezvoltatori, un astfel de mesaj indică posibila prezență a problemelor în structura de configurare. Înainte de a încerca să mulțumiți utilizatorii și să eliminați blocajele, trebuie să analizați situația și să înțelegeți motivul mesajului de eroare.
Motive pentru blocarea erorilor în 1C
Testarea de încărcare demonstrativă demonstrează că serverul 1C poate rezista la operarea în paralel a peste cinci mii de utilizatori. Dar condițiile ideale pentru astfel de experimente sunt de neatins în condițiile de zi cu zi ale companiilor mari și mijlocii. Pentru a obține performanțe similare și funcționare fără erori, configurația trebuie să fie proiectată și adaptată în mod ideal la procesele de afaceri specifice ale întreprinderii.
Dacă nu luăm opțiunile ideale, atunci apar conflicte de blocare 1C din următoarele motive:
Munca simultană a utilizatorilor cu o cantitate mare de date. Această cauză fundamentală este dictată de mecanismele interne ale 1C. Acestea presupun interzicerea modificărilor datelor implicate într-o tranzacție lansată în numele altui utilizator;
Erori și omisiuni în configurație. Structura soluțiilor standard de la compania 1C ține cont de recomandări pentru maximizarea productivității. Dar dezvoltatorii terți nu respectă întotdeauna standarde înalte, iar următoarele defecte pot fi adesea găsite în codul lor:
- Interogări suboptimale;
- Solicitare de solduri la inceputul actiunilor;
- Înțelegerea greșită a scopului obiectelor de configurare și utilizarea lor incorectă;
- Redundanța interblocărilor încorporate în sistem sau dezvoltate suplimentar.
Cum să remediați un conflict de blocare în 1C 8.3
Mesajul de sistem „conflict de blocare la executarea unei tranzacții 1C 8.3” nu caracterizează configurația ca fiind proiectată incorect. Dar dacă astfel de semnale sunt ignorate, atunci există posibilitatea de a intra în probleme mari în cel mai crucial moment, de exemplu, la depunerea rapoartelor trimestriale sau anuale. În cel mai bun caz, un sistem lent și utilizatori nemulțumiți. În cel mai rău caz, datele de ieșire sunt incorecte, ceea ce poate duce la sancțiuni din partea autorităților de reglementare.
Soluția la problema conflictelor de blocare din 1C 8.3 poate fi transferarea configurației într-un mod de gestionare a blocării gestionat (manual). Implementat în versiunea 8.1, mecanismul aflat în mâinile specialiștilor competenți rezolvă problema conflictelor de blocare în timpul unei tranzacții în 1C.
Dar merită să rețineți că această acțiune va reduce nivelul de protecție a datelor împotriva modificărilor în timp ce sunt citite de alți utilizatori. Prin urmare, dacă nu sunteți pregătit să controlați în mod independent toate încuietorile din sistem, nu vă grăbiți să modificați setările de configurare.
Soluție rapidă la conflictul de blocare 1C
În munca unui administrator sau dezvoltator, poate apărea o situație când nu există timp pentru a verifica o eroare și a căuta cauzele principale ale problemei. De exemplu, este necesar să trimiteți un raport sau să trimiteți date până la un anumit timp, dar erorile de blocare 1C împiedică acest lucru.
Există două moduri de a rezolva rapid problema:
- Găsiți și încheiați sesiunea care blochează datele necesare. ÎN firme mici, unde numărul de utilizatori 1C nu depășește câteva zeci de persoane, aceasta este soluția optimă;
- Dacă controlați un sistem cu sute de angajați, găsiți sesiunea potrivită fără specializare software poate dura mult timp. În acest caz, va fi mult mai eficient să reporniți serverul.
Aceste soluții sunt radicale și vizează doar rezolvarea rapidă a problemei și eliberarea datelor pentru raportare urgentă. Poate fi eradicată doar prin înțelegerea motivului pentru care a apărut un conflict de blocare la efectuarea unei tranzacții 1C. După astfel de acțiuni, este necesar să găsiți vulnerabilități în sistem, să optimizați configurația sau munca angajaților. Nu este recomandat să folosiți astfel de măsuri în mod continuu în cazul unor conflicte regulate de blocare a tranzacțiilor.
Salutare tuturor!
Zilele trecute la serviciu am întâlnit o problemă cu blocarea, și anume mesajul „Există un conflict de blocare în timpul executării unei tranzacții. Timpul maxim de așteptare pentru acordarea unei blocări a fost depășit”.
Evident, nu există nicio problemă de blocaj aici, doar o sesiune a pus o blocare și a „uitat” să o elimine. În același timp, problema amenința cu consecințe grave - documentul Vânzări de bunuri și servicii nu a fost efectuată. Aproximativ 100 de persoane lucrează în baza de date simultan și este imposibil să efectuați o operațiune tipică și frecventă!
Au existat două soluții - reporniți serverul sau căutați o sesiune eșuată. Prima soluție este simplă și rapidă, dar, așa cum a scris cineva deja aici, puteți reporni serverul până când sunteți concediat. Am hotărât să merg pe a doua cale.
Prima zi - problema a apărut în timpul zilei la început părea că problema era cu un utilizator de la distanță care se autentificase în Configurator. Părea că execuția pur și simplu s-a oprit la un moment dat, iar blocarea, desigur, nu a fost eliminată. După câteva ore, am reușit să lansăm configuratorul, dar problema nu a dispărut. Era extrem de nedorit să ucizi forțat configuratorul, poate că lucrau în el. După aceea, Google a intrat în joc. Am găsit un articol pe acest site care spune cum să găsești încuietori într-un SGBD MS SQL, verificat, nu existau încuietori la nivel de SGBD. Ciudat. În continuare, au fost încercări de a configura tehnologie. revistă. Configurați-o, ce urmează? În 15 minute, câteva concerte de bușteni! Cum să le citești, ce să cauți? Necunoscut.
Am găsit un articol despre cum să vezi ce este blocat folosind SQL Trace. Chiar dacă îl găsesc, ce urmează? Am nevoie de o sesiune!
Mai aproape de ora 16:00, când mi-am dat seama că nu mai pot aștepta, am făcut un reboot. Sperând că acest lucru nu se va mai întâmpla (și aceasta a fost prima dată în șase luni de muncă), am răsuflat ușurat, totul a funcționat. Dar degeaba... A doua zi - aceeași situație. Am săpat timp de o oră și jumătate, iar încercări de neînțeles de a căuta pe google și așa mai departe. Niciun rezultat. Reporniți. La sfârșitul zilei s-a întâmplat din nou. Ei bine, cred că este grozav, voi veni calm acasă și voi sta și voi săpa mai adânc. Vin acasă, totul este bine. Din nefericire.
În a treia zi am urmărit webinarul, au vorbit despre un interesant și mod eficientîn căutarea unei probleme. Mi-am amintit, dar problema nu a mai apărut. A trecut o săptămână și iată-l - blocaje din nou! Îmi frec mâinile și încep să acționez.
Mai întâi, configurați jurnalul. Da, nu mă pot descurca fără el, dar acum știu să o citesc. Am stabilit două evenimente: primul este TLOCK, al doilea este TTIMEOUT. Primul afișează toate evenimentele de blocare, al doilea arată evenimentele de blocare care nu au putut fi instalate în timpul alocat. De fapt, cel mai probabil doar TTIMEOUT este suficient.
Copiem fișierul jurnal tehnic în locul desemnat, zburăm în program, apelăm blocarea, primim un mesaj și eliminăm sau redenumim fișierul jurnal tehnic. Nu avem nevoie de tone de informații despre alte blocări!
Accesați folderul rphost_PID, găsiți fișierele text și căutați cuvântul TTIMEOUT. Vedem linia:
53:16.789126-0,TTIMEOUT,5,process=rphost,p:processName=*****,t:clientID=16536,t:applicationName=1CV8,t:computerName=ASUSM,t:connectID=17272,SessionID= 2242,Usr=*******,WaitConnections=8239Apropo, pot exista mai multe foldere rphost_PID, totul depinde de câte procese de lucru rulează pe server.
Și apoi totul este simplu: uită-te la sfârșitul liniei - WaitConnections = 8239, acesta este numărul nostru CONNECTION. Mergem la consola serverului, mergem la Conexiuni, găsim acest număr și ne uităm la numărul sesiunii. În cazul meu, au existat două sesiuni per utilizator - cea nereușită și alta. Sesiunea către care a indicat jurnalul tehnic s-a prăbușit. Și iată și iată! Totul a funcționat, bucuria nu are limite! Dar, după cum s-a dovedit mai târziu, sesiunea nu a fost înghețată :), ei lucrau în ea. Prin urmare, pe viitor, este recomandabil să contactați utilizatorul și să avertizați.
După părerea mea, este suficient soluție standard O problemă destul de tipică. Nu se știe de ce nu l-am dat peste el, poate pentru că a trebuit să-l caut din alarmă, iar când utilizatorii nu l-au apăsat, nu a fost posibil să efectuez teste - nu a existat nicio eroare.
„Conflict de blocare la executarea unei tranzacții: a fost depășit timpul maxim de așteptare pentru acordarea unei blocări” este o eroare destul de comună în 1C 8.3 și 8.2 asociată cu competiția pentru utilizarea resurselor din sistem.
Sistemul 1C permite unui număr mare de utilizatori să lucreze în paralel: după cum arată testele de încărcare, astăzi acest număr nu este limitat la cinci mii de utilizatori care lucrează simultan în sistem. Cu toate acestea, pentru ca baza de date 1C 8 să suporte simultan cantitati mari despre utilizatori, configurația trebuie proiectată corect.
Obțineți 267 de lecții video pe 1C gratuit:
Efectuarea unui număr mare de operații
Este probabil ca un utilizator să fi lansat, de exemplu, pe o perioadă lungă de timp într-o singură tranzacție. Arhitectura 1C 8.3 presupune că sistemul nu permite modificarea datelor care sunt utilizate într-o tranzacție de către un alt utilizator și le blochează.
Aceasta poate fi o eroare temporară care va înceta să apară când celălalt utilizator termină de operare a sistemului. Dacă această eroare apare frecvent, atunci cel mai probabil problema este altceva.
Eroare de configurare
Pe lângă erorile din cod, există adesea decizii incorecte metodologic. De exemplu, în sine implică prelucrarea secvenţială a documentelor. Contabilitatea loturilor poate fi înlocuită cu RAUZ - acest lucru va crește serios productivitatea sistemului.
Cum se remediază această eroare în 1C 8.3?
În orice caz, apariția erorii „Blocare conflict în timpul executării unei tranzacții” indică necesitatea inspectării sistemului, în special pentru medii și mari sisteme informaticeîn modul client-server (MS SQL, PostgreSQL etc.). Dacă acest lucru este ignorat într-un stadiu incipient, sunt posibile consecințe ireversibile ulterior, când funcționarea sistemului este deosebit de importantă (în perioada de raportare).
Pentru auditare și corectarea erorilor, cel mai bine este să alegeți un partener de încredere. Doar sunați-ne și vă vom rezolva orice problemă în cât mai repede posibil. Detalii pe pagina.
Nu este neobișnuit când lucrați în 1C să primiți eroarea „Conflict de blocare la executarea tranzacțiilor: timpul maxim de așteptare pentru acordarea unei blocări a fost depășit”. Esența sa constă în faptul că mai multe sesiuni încearcă să efectueze simultan acțiuni similare, afectând aceeași resursă. Astăzi vom afla cum să remediam această eroare.
Un număr mare de operații efectuate
Primul pas în căutarea motivelor este să clarificăm câți utilizatori concurenți sunt în baza de informații în care este generată o astfel de eroare. După cum știm, numărul lor maxim poate fi destul de mare. Aceasta este și o mie și cinci mii.
Mecanismul de blocare și tranzacții este descris în ghidul dezvoltatorului. Ele sunt utilizate atunci când mai multe sesiuni accesează aceleași date simultan. Este logic ca aceleași date să nu poată fi modificate de diferiți utilizatori în același timp.
De asemenea, ar trebui să verificați dacă vreunul dintre utilizatori execută procesare de modificare a datelor în masă. Acesta ar putea fi sfârșitul lunii și altele asemenea. În acest caz, după finalizarea procesării, eroarea va dispărea de la sine.
Sarcini programate
Nu este neobișnuit ca cauza unei erori să se afle într-un sistem care procesează cantități mari de date. Este recomandat să faci astfel de lucruri noaptea. Stabiliți un program pentru efectuarea unor astfel de sarcini de rutină în afara orelor de lucru.
În acest fel, utilizatorii vor lucra într-un sistem stabil, iar sarcinile de rutină în sine vor fi finalizate cu succes, deoarece probabilitatea conflictelor cu sesiunile utilizatorilor va fi redusă.
„Sesiuni de suspendare”
Problema „sesiunilor blocate” ale utilizatorilor este familiară pentru aproape toți cei care au întâlnit întreținerea 1C. Utilizatorul ar fi putut părăsi programul cu mult timp în urmă sau ar fi închis un document, dar sesiunea sa rămâne încă în sistem. Problema este cel mai adesea izolată și este suficient să încheiați o astfel de sesiune prin consola de administrator. Aceleași probleme pot apărea și cu joburile de fundal.
Potrivit numeroaselor comentarii de pe Internet, astfel de situații sunt mai frecvente atunci când se folosesc chei de securitate pentru rețea. Dacă situația cu „înghețarea sesiunilor” se repetă sistematic, acesta este un motiv pentru a verifica și întreține temeinic sistemul și serverele (dacă baza de date este client-server).
Erori la scrierea configurației
Toate configurațiile standard au fost dezvoltate specialisti calificatiși experți. Fiecare sistem este testat temeinic și optimizat pentru o funcționare mai rapidă și mai corectă.
În acest sens, cauza erorii poate sta în codul suboptimal scris de un dezvoltator terță parte. Aceasta ar putea fi o solicitare „grea” care va bloca datele pentru o perioadă lungă de timp. Există, de asemenea, cazuri frecvente de construire a algoritmilor cu performanță scăzută și încălcare a logicii.
Există o mare probabilitate ca conflictul de blocare să apară tocmai din cauza erorilor dezvoltate, dacă a apărut după o actualizare a programului. Pentru a verifica, puteți pur și simplu să „retroduceți” îmbunătățirile sau să refactorizați codul.
Întrebare: UT11.1. Crearea loturilor de implementări. Conflict de blocare
Bună ziua Configurare UT11.1. Opțiune client-server. Setări implicite pentru 1C Server și SQL Server. Creăm implementări programatic. În etapa de scriere a documentului, apare periodic un conflict de blocare. Spune-mi cum se rezolvă astfel de probleme? Sunt utilizate tranzacțiile cu blocări gestionate? Mulţumesc anticipat.
Răspuns:
nu este nevoie să-l dezactivați) comutați-le la noapte - calculele de costuri și indici de căutare pot fi calculate acolo.
Întrebare: Conflict de blocare în timpul tranzacției
În fiecare zi, aproape la aceeași oră, la verificarea unui document, acesta apare timp de 5-10 minute această eroare 1C 8.3.10.26.99 UT11(11.4.1.261):
Conflict de blocare în timpul tranzacției:
Microsoft Sql Server Native Client 11.0: Solicitarea de blocare a expirat.
HERESULT=80040E31, SqlServer: SQLSTATE=HYT00, stare=38, Severitate=10, nativ=1222, linie=1
Spune-mi de unde să încep să sap?
Răspuns:() Porniți profiler în acest moment pentru evenimentele Lock:Acquired și Lock:Escalation. Apoi raportează ce ai prins.
Întrebare: Restaurarea bazei de date (conflict de blocare)
Bună ziua. Baza este pe moarte. Camera serverului.
Nu a devenit clar imediat, pentru că... totul a funcționat cu excepția documentului emis de Consiliul Federației. Și nu este creat foarte des. Prin urmare, backup-ul nu este relevant (au trecut deja câteva zile), am încercat să implementăm o copie de acum 2 zile - a fost bine pentru o jumătate de zi și apoi a apărut aceeași problemă.
Simptome: atunci când încercăm să anulăm o tranzacție, obținem un conflict de blocare, chiar dacă există un singur utilizator în baza de date. TII (verificarea integrității logice și referențiale) eșuează cu un conflict de blocare, crearea unei copii de rezervă prin sql management studio este aceeași („Timpul de expirare a tipului de blocare al bufferului 3 pentru pagină a fost depășit”).
Vrem să încercăm să completăm cf-ul de acum o săptămână, dar există puține speranțe.
Răspuns: sunt probleme cu serverul bazei de date, nu 1C, versiunile de configurare etc. nu au nicio legatura cu asta.
Poate că pomețiul neîntreținut a trăit cât a putut mai bine cât a existat suficiente resurse, iar acum autorul începe o nouă etapă de stăpânire a cunoștințelor.
Dacă dimensiunea permite, încărcați-l într-un fișier și începeți să studiați SQL mai profund.
Întrebare: UT10. Conflict de blocare
Bună ziua Opțiune client-server. Am moștenit o configurație BitAuto foarte modificată (centru de service auto bazat pe UT10). Procesatorul de procesare a documentului „comandă-comandă de lucru”, principalul de primire a maiștrilor și conducătorilor, include formarea documentelor subordonate (vânzări, factură, bon de livrare), calculul salariilor mecanicilor, rezervarea mărfurilor, dacă document nou, apoi creând o comandă de cumpărător și alte funcționalități. Baza de date a crescut și au început să apară frecvent conflicte de blocare. În weekend, când sunt mai puțini oameni, nu există conflicte.
Bănuiesc că cu atâta analiză, în timpul documentului, perioadă lungă de timp blochează un anumit jurnal de documente, deși jurnalul de comenzi pare să fie complet blocat.
Dacă vă faceți propria procedură ca handler pentru butonul „Ok”, unde rulați secvențial „Procesarea procesării”, apoi procedura, de exemplu, Generați documente subordonate, apoi Calculați salariul etc. Nu sunt sigur că această opțiune va ajuta. Adăugarea de butoane pe care să atașați formarea documentelor nu va funcționa, deoarece utilizatorii vor uita de asta.
Răspuns:
| Zero |
|---|
| vde69, Ei bine, acesta este probabil un fel de prostie Raru |
Nu, acesta nu este Rarus, acesta este BitAuto
Întrebare: 1c conflict de blocare la deschiderea unui formular de document
SCP
Recent, la fiecare 2-3 zile apare un blocaj pe documentul Solicitare-factura. Aceste. nu se deschide niciun document de acest tip. Tot timpul
Alte documente merg bine.
Nu am găsit probleme în depanator, nu are timp să se oprească în niciun modul - imediat apare un conflict de blocare.
Bănuiesc că există o problemă în SQL.
Răspuns: Problema a fost o lucrare de întreținere a indexului care nu s-a finalizat.
Întrebare: Eroare SQL2000 în timpul execuției tranzacției în 1C77
în baza de date MSSQL 1C77 (ediția 27) TiS. În mod regulat, atunci când faceți tranzacții, apare o eroare:
A apărut o eroare la executarea tranzacției!
Stare SQL: HYT00
Nativ:0 Mesaj: Timp expirat.
Ca urmare, documentul nu poate fi procesat. Aceasta poate dura 20 de minute, sau poate 1 oră.
Cum să te descurci cu asta, unde să sapi?
Cu stimă,
Steve242
Fișierul este atașat mesajului. Dimensiune - 21Kb
Răspuns:
Monitorul de performanță obișnuit al Windows a arătat că unitatea de sistem C:\ este încărcată din iad pe Terminal.
Orice altceva: memorie, procesor - pe ambele servere (terminal și plâns) practic nu sunt afișate explozii anormale.
Am creat o unitate RAM de 2 Gb (din cele 12 Gb disponibile fizic pe serverul terminal) și încerc să redirecționez directoarele de sistem temporare ale profilurilor de utilizator terminale acolo.
pana acum ceva de genul asta.
Întrebare: Încă o dată, despre conflictul de blocare la executarea unei tranzacții
Răspuns:
Întrebare: Blocare la abonament la RTiU
Răspuns:
Întrebare: Linux, Postgres, Retail 2.0.5.1 Ucraina RIB după magazin - eroare de blocare...
Poate cineva sa-mi spuna? Înființez un schimb în magazin. Totul merge bine, pot face schimbul manual. Sunt redirecționate 4-5 mesaje. Apoi am configurat scriptul conform programului și începe swing-ul... Prima eroare:
„Eroare la scrierea datelor în fișierul de mesaje de schimb: (Processing.ConvertingDistributedInformationBaseObjects.ObjectModule()): Eroare la apelarea metodei contextului (WriteChanges): Conflict de blocare în timpul tranzacției:
Timpul maxim de inactivitate pentru acces la blocare a fost depășit din cauza așteptării sesiunii"
Toate cele ulterioare:
„Eroare la scrierea datelor în fișierul de mesaje de schimb: (Processing.ConvertingDistributedInformationBaseObjects.ObjectModule()): Eroare la apelarea metodei context (WriteChanges): Conflict de blocare la executarea unei tranzacții:
Timpul maxim de așteptare pentru acordarea unei blocări a fost depășit”
Nici reindexarea, nici închiderea sesiunilor nu ajută. Nu există încuietori în 1C. Singurul lucru care ajută este să ștergeți baza de date și să o creați din nou.
După cum am înțeles, blocarea are loc în DBMS? Folosesc Postgress pe Linux, 1 bază de date, 4 GB RAM. Dacă am dreptate, întrebarea este - Postgress este configurat incorect sau nu are memorie? Sau poate nu asta e problema deloc?
Răspuns:() Deci cea proaspătă este 8.3.10.2375
Întrebare: Eroare de blocare la ștergerea registrului de informații
Folosind interogarea, selectez înregistrări RS, apoi:
Recordset.Load(QueryResult.Unload()); Recordset.Clear(); RecordSet.Write();
Cand incerc sa scriu imi apare o eroare:
„Există un conflict de blocare în timpul executării unei tranzacții.”
Registrul nu este periodic și nu este subordonat registratorului.
Care este motivul erorii?
Răspuns:() „Din anumite motive am fost sigur că selecția se aplică numai în momentul lecturii și că ceea ce a fost inclus în selecție este înregistrat în consecință.” - Unde în codul dvs. este folosit cuvântul „selecție” cel puțin o dată?
