Kako sam dijagnosticirao probleme s blokiranjem. Kako sam dijagnosticirao probleme zaključavanja 1c greška sukob zaključavanja prilikom izvršavanja transakcije

Nisam mogao zapisati promjene za prijenos u distribuiranu bazu podataka, kontaktirao sam 1c podršku i ponudio sljedeće. Odlučio sam jednostavno ponovno pokrenuti aplikacijski poslužitelj i poslužitelj sa SQL-om. Općenito, možete označiti okvir "Blokiranje zakazano
uključeni zadaci"
Pomoglo je i bez ponovnog pokretanja.

Planirane operacije na razini DBMS za MS SQL Server

Upute za izvođenje rutinskih operacija na razini DBMS-a.

Informacije su primjenjive na verziju klijent-poslužitelj 1C:Enterprise 8 kada se koristi MS SQL Server DBMS.

Opće informacije

Jedan od najčešćih uzroka neoptimalnog rada sustava je nepravilno ili nepravovremeno izvršavanje rutinskih operacija na razini DBMS-a. Posebno je važno obavljati ove rutinske postupke u velikim informacijskim sustavima koji rade pod značajnim opterećenjem i istovremeno opslužuju veliki broj korisnika. Specifičnost ovakvih sustava je da uobičajene radnje koje DBMS izvršava automatski (na temelju postavki) nisu dovoljne za učinkovit rad.

Ako sustav koji radi pokazuje bilo kakve simptome problema s performansama, trebali biste provjeriti je li sustav ispravno konfiguriran i redovito izvodi sva preporučena rutinska održavanja na razini DBMS-a.

Izvršenje rutinskih postupaka treba biti automatizirano. Za automatizaciju ovih operacija preporučuje se korištenje ugrađenih alata MS SQL Servera: Plan održavanja. Postoje i drugi načini automatizacije ovih postupaka. U ovom članku, za svaki zakazani postupak, dan je primjer njegove konfiguracije korištenjem plana održavanja za MS SQL Server 2005.

Preporuča se redovito pratiti pravodobnost i ispravnost provedbe ovih rutinskih postupaka.

Ažuriranje statistike

MS SQL Server gradi plan upita na temelju statističkih podataka o distribuciji vrijednosti u indeksima i tablicama. Statistički podaci prikupljaju se na temelju dijela (uzorka) podataka i automatski se ažuriraju kada se ti podaci promijene. Ponekad to nije dovoljno da MS SQL Server dosljedno izgradi najoptimalniji plan za izvršavanje svih upita.

U tom slučaju mogu se pojaviti problemi s izvedbom upita. Istodobno se u planovima upita uočavaju karakteristični znakovi neoptimalnog rada (neoptimalne operacije).

Kako bi se zajamčio najispravniji rad MS SQL Server optimizatora, preporučuje se redovito ažuriranje statistike MS SQL baze podataka.

Za ažuriranje statistike za sve tablice baze podataka, morate izvršiti sljedeći SQL upit:

exec sp_msforeachtable N"AŽURIRAJ STATISTIKU? S FULLSCAN-OM"

Ažuriranje statistike ne dovodi do zaključavanja tablica i neće ometati rad drugih korisnika. Statistika se može ažurirati onoliko često koliko je potrebno. Imajte na umu da će se opterećenje DBMS poslužitelja tijekom ažuriranja statistike povećati, što može negativno utjecati na ukupne performanse sustava.

Optimalna učestalost ažuriranja statistike ovisi o veličini i prirodi opterećenja sustava i određuje se eksperimentalno. Preporučljivo je ažurirati statistiku barem jednom dnevno.

Gornji upit ažurira statistiku za sve tablice u bazi podataka. U stvarnom sustavu, različite tablice zahtijevaju različite stope ažuriranja statistike. Analizom planova upita možete odrediti koje tablice trebaju najčešće ažurirati statistiku i postaviti dvije (ili više) različite rutinske procedure: za tablice koje se često ažuriraju i za sve ostale tablice. Ovakav pristup značajno će smanjiti vrijeme ažuriranja statistike i utjecaj procesa ažuriranja statistike na rad sustava u cjelini.

Konfiguriranje automatskog ažuriranja statistike (MS SQL 2005)

Pokrenite MS SQL Server Management Studio i spojite se na DBMS poslužitelj. Otvorite mapu Management i izradite novi plan održavanja:

Napravite podplan (Add Subplan) i nazovite ga "Statistics Update". Dodajte zadatak ažuriranja statistike na programsku traku:

Postavite raspored ažuriranja statistike. Preporuča se ažurirati statistiku barem jednom dnevno. Ako je potrebno, učestalost ažuriranja statistike može se povećati.

Postavite postavke zadatka. Da biste to učinili, dvaput kliknite na zadatak u donjem desnom kutu prozora. U obrascu koji se pojavi navedite naziv baze (ili više baza) za koju će se ažurirati statistika. Osim toga, možete odrediti za koje tablice ažurirati statistiku (ako ne znate točno koje tablice trebate navesti, postavite vrijednost na Sve).

Ažuriranje statistike mora se izvršiti s uključenom opcijom Full Scan.

Spremite izrađeni plan. Kada dođe vrijeme navedeno u rasporedu, statistika će se automatski ažurirati.

Brisanje proceduralne predmemorije

MS SQL Server optimizator sprema planove upita za ponovno izvršenje. Ovo se radi kako bi se uštedjelo vrijeme utrošeno na sastavljanje upita ako je isti upit već izvršen i njegov plan je poznat.

Moguće je da će MS SQL Server, oslanjajući se na zastarjele statističke podatke, izgraditi neoptimalan plan upita. Ovaj plan će biti pohranjen u proceduralnu predmemoriju i korišten kada se isti upit ponovo pozove. Ako ste ažurirali statistiku, ali niste očistili proceduralnu predmemoriju, tada SQL Server može odabrati stari (neoptimalan) plan upita iz predmemorije umjesto izgradnje novog (boljeg) plana.

Da biste očistili proceduralnu predmemoriju MS SQL Servera, morate izvršiti sljedeći SQL upit:

Ovaj upit treba pokrenuti odmah nakon ažuriranja statistike. Sukladno tome, učestalost njegovog izvršavanja trebala bi odgovarati učestalosti ažuriranja statistike.

Konfiguriranje proceduralnog čišćenja predmemorije (MS SQL 2005)

Budući da se proceduralna predmemorija mora obrisati svaki put kada se statistika ažurira, preporučuje se dodati ovu operaciju u već kreirani podplan "Ažuriraj statistiku". Da biste to učinili, otvorite podplan i dodajte zadatak Izvrši T-SQL naredbu njegovoj shemi. Zatim biste trebali strelicom povezati Zadatak ažuriranja statistike s novim zadatkom.

U tekstu kreiranog Execute T-SQL Statement Task trebate navesti upit "DBCC FREEPROCCACHE":

Defragmentacija indeksa

Kada intenzivno radite s tablicama baze podataka, dolazi do efekta fragmentacije indeksa, što može dovesti do smanjenja učinkovitosti upita.

sp_msforeachtable N"DBCC INDEXDEFRAG (<имя базы данных>, ""?"")"

Defragmentacija indeksa ne blokira tablice i neće ometati rad drugih korisnika, no dodatno opterećuje SQL Server. Optimalna učestalost izvođenja ove rutinske procedure treba biti odabrana u skladu s opterećenjem sustava i učinkom defragmentacije. Preporučujemo da defragmentirate svoje indekse barem jednom tjedno.

Moguće je defragmentirati jednu ili više tablica, a ne sve tablice u bazi podataka.

Konfiguriranje defragmentacije indeksa (MS SQL 2005)

U prethodno stvorenom planu održavanja, stvorite novi podplan pod nazivom "Reindex". Dodajte mu zadatak Rebuild Index:

Postavite raspored izvršenja za zadatak defragmentacije indeksa. Preporuča se izvršavanje zadatka barem jednom tjedno, a ako su podaci u bazi vrlo nestabilni, i češće - do jednom dnevno.

Ponovno indeksiranje tablica baze podataka

Reindeksiranje tablica uključuje potpunu ponovnu izgradnju indeksa tablica baze podataka, što dovodi do značajne optimizacije njihovog rada. Preporuča se redovito ponovno indeksiranje tablica baze podataka. Da biste ponovno indeksirali sve tablice baze podataka, morate izvršiti sljedeći SQL upit:

sp_msforeachtable N"DBCC DBREINDEX(""?")"

Reindeksiranje tablica ih blokira za vrijeme trajanja njihovog rada, što može značajno utjecati na rad korisnika. U tom smislu, preporuča se ponovno indeksiranje tijekom minimalnog opterećenja sustava.

Nakon ponovnog indeksiranja, nema potrebe defragmentirati indekse.

Postavljanje ponovnog indeksiranja tablice (MS SQL 2005)

U prethodno izrađenom planu održavanja izradite novi podplan pod nazivom "Defragmentacija indeksa". Dodajte mu zadatak Rebuild Index:

Postavite raspored izvršenja za zadatak reindeksiranja tablice. Preporuča se pokretanje zadatka tijekom minimalnog opterećenja sustava, barem jednom tjedno.

Prilagodite zadatak navođenjem baze podataka (ili više baza podataka) i odabirom potrebnih tablica. Ako ne znate točno koje tablice navesti, postavite vrijednost na Sve.

Kada stotine korisnika rade s programima i podacima u isto vrijeme, javljaju se problemi svojstveni samo velikim rješenjima. Govorimo o problemima uzrokovanim zaključavanjem podataka.

Ponekad korisnici doznaju za zaključavanje iz poruka koje ukazuju na nemogućnost upisa podataka ili izvođenja neke druge operacije. Ponekad zbog vrlo značajnog pada performansi programa (na primjer, kada vrijeme potrebno za izvođenje operacije raste desetke ili stotine puta).

Problemi uzrokovani blokiranjem nemaju opće rješenje. Stoga ćemo pokušati analizirati uzroke takvih problema i sistematizirati opcije za njihovo rješavanje.

RAZLOZI BLOKADE TRANSAKCIJE

Prvo se sjetimo što su brave, a istodobno ćemo shvatiti jesu li potrebne. Pogledajmo nekoliko klasičnih primjera blokiranja s kojima se susrećemo u životu.

Primjer 1: Kupnja karte za avion ili vlak. Pretpostavimo da smo svoje želje izrazili blagajniku. Blagajnik nam javlja dostupnost mjesta, od kojih možemo odabrati ono koje nam se najviše sviđa (ako ih je više, naravno). Sve dok ne izaberemo i potvrdimo da se slažemo s predloženom opcijom, ova mjesta se ne mogu prodati nikome drugome, tj. privremeno blokiran. Ako nisu blokirani, tada bi do trenutka potvrde moglo doći do situacije da su ulaznice koje smo odabrali već prodane. I u ovom slučaju ciklus odabira može biti nepredvidiv broj ponavljanja. Dok biramo mjesta, ali ona su već prodana! .. Dok biramo druga, a njih više nema ...

Primjer 2: kupnja nečega u trgovini ili na tržnici. Popeli smo se do pulta, odabrali najljepšu jabuku od stotinu dostupnih. Birali su i posegnuli u džep za novcem. Kako će izgledati ako, dok brojimo novac, jabuku koju smo odabrali prodamo kupcu koji je došao kasnije od nas?

Dakle, blokiranje je samo po sebi nužna i korisna pojava. Upravo zahvaljujući blokiranju jamčimo izvršenje radnji u jednoj fazi. I najčešće, ne najuspješnija implementacija softvera dovodi do negativnosti, kada, na primjer:

• prevelik broj objekata (ulaznice, jabuke) je blokiran;
• vrijeme blokade neopravdano produljeno.

PREVJEŠNE BLOKADE U TIPIČNIM 1C KONFIGURACIJAMA

Na velikim projektima, u pravilu, koristimo 1C:Enterprise. Stoga ćemo pokušati opisati praktične preporuke za rješavanje problema blokiranja na primjeru paketa 1C:Enterprise + MS-SQL.

Osma generacija 1C:Enterprise pruža vrlo, vrlo dobar paralelizam korištenja. Istovremeno s jednom konfiguracijom (odnosno na jednoj bazi), s normalnim poslužiteljima i komunikacijskim kanalima, može raditi ogroman broj korisnika. Na primjer, stotine skladištara obrađuju izdavanje ili primitak robe, ekonomisti istovremeno obračunavaju troškove plaća za različite odjele, računovođe obračunavaju i obračunavaju plaće itd.

Ali postoji razlog zašto postoji suprotno mišljenje - mit da je, uz intenzivnu istovremenu upotrebu, neugodno ili nemoguće raditi s rješenjima temeljenim na 1C: Enterprise. Uostalom, čim stotine korisnika počnu koristiti standardna rješenja za 1C:Enterprise u industrijskim razmjerima, sve češće se na ekranu pojavljuje prozor s ponosnim natpisom: "Pogreška pri pozivanju metode konteksta (Record): Zaključaj sukob prilikom izvršavanja transakcije: ...” i dalje u ovisno o vrsti korištenog SQL poslužitelja, nešto poput “Microsoft OLE DB Provider za SQL Server: premašeno razdoblje čekanja zahtjeva za zaključavanje. ...".

Gotovo sva standardna rješenja u predloženoj "out of the box" izvedbi konfigurirana su za automatsko upravljanje bravama. "Automatski" se ovdje može shvatiti kao "paranoičan". Za svaki slučaj, kada vodimo bilo koji dokument, blokiramo sve što se može nekako povezati s njim. Tako ispada da kada jedan korisnik nešto potroši (a ponekad samo napiše), ostali mogu samo čekati.

Izrazit ću svoje mišljenje zašto je 1C odlučio ne prilagoditi svoja standardna rješenja visokom paralelizmu korištenja. Troškovi rada za takvo usavršavanje nisu visoki - nekoliko "osoba-mjeseci", što nije značajno u smislu 1C ljestvice. Mislim da je razlog drugačiji.

Prvo, takva dorada značajno komplicira procesore za knjiženje svih dokumenata. To znači da će za one potrošače koji koriste 1C za male zadatke, bez ikakvog dobitka, postojati samo nedostatak - složenost finalizacije tipične konfiguracije postat će kompliciranija. Istodobno, statistike sugeriraju koja je kategorija kupaca glavni izvor za 1C ...

Drugi razlog je zakopan u tipičnim osnovnim postavkama SQL poslužitelja, na primjer, MS-SQL, koji se još uvijek koristi češće od ostalih. Dogodilo se da su prioriteti u postavkama dani uštedi RAM-a poslužitelja, a ne smanjenju blokiranja. To dovodi do činjenice da, ako je potrebno zaključati nekoliko redaka, SQL poslužitelj donosi "ekonomičnu" odluku za memoriju i procesor - zaključati cijelu tablicu odjednom!..

Upravo se ovi nedostaci standardnih rješenja ili specifičnosti korištenih postavki poslužitelja baze podataka često poistovjećuju s problemima uzrokovanim blokiranjem. Kao rezultat toga, tehnički nedostaci dovode do vrlo značajnih organizacijskih problema. Uostalom, ako se zaposleniku navede razlog za odvraćanje pažnje od posla ili opravdanje zašto se posao ne može obaviti, manjina će raditi učinkovito. Pa, poruka o blokiranju transakcija ili "usporavanje" programa je idealno opravdanje zašto se ništa ne može učiniti.

PREPORUKE ZA UKLANJANJE PREKOMJERNOG BLOKIRANJA ZA 1C:ENTERPRISE

Što učiniti ako je rješenje problema prekomjernog blokiranja toliko važno?

U završnoj fazi implementacije svih velikih kompleksa potrebno je provesti finu doradu kako bi se uklonila nepotrebna zaključavanja transakcija. Ključno je riješiti probleme koji mogu nastati zbog nedovoljno razvijenih uvjeta blokiranja ili metodologije implementacije.

Jer Ova operacija je izuzetno važna, mora se stalno izvoditi. Stoga smo, kako bismo pojednostavili provedbu takve dorade, razvili niz osnovnih preporuka kojih se nastojimo pridržavati. Preporuke primljene i testirane na iskustvu značajnog broja velikih implementacija.

1. Ako vaš DBMS ili razvojni sustav (na primjer, 1C:Enterprise) prema zadanim postavkama koristi automatsko zaključavanje podataka, onemogućite automatsko upravljanje zaključavanjem. Sami postavite pravila blokiranja, opišite kriterije blokiranja za cijele tablice ili pojedinačne retke.
2. Kada razvijate program, kad god je to moguće, pogledajte tablice istim redoslijedom.
3. Pokušajte ne pisati u istu tablicu više puta unutar iste transakcije. Ako je ovo teško, onda barem minimizirajte količinu vremena između prve i zadnje operacije pisanja.
4. Analizirati mogućnost onemogućavanja eskalacije zaključavanja na razini SQL poslužitelja.
5. Jasno informirajte korisnike o razlozima nemogućnosti izvođenja bilo kakvih radnji ako su one uzrokovane blokiranjem. Dajte pristupačne i razumljive preporuke o tome što učiniti sljedeće.

Ako pažljivo pogledate preporuke, postaje jasno da takav razvoj prikladan je ne samo za 1C:Enterprise, već i za sve sustave. Nije važno na kojem su jeziku napisani i s kojim poslužiteljem baze podataka rade. Većina preporuka je univerzalne prirode, te stoga jednako vrijede za korištenje 1C: Enterprise, kao i za "samonapisane" programe ili druge "kutijaste" ERP sustave.

p.s. Jeste li znali da nudimo stručnu pomoć pri ažuriranju 1C po najpovoljnijoj cijeni?

Oznake pretraživanja:

• Zaključavanja transakcija
• Uklanjanje blokada
• Blokiranje 1C
• blokiranje
• Sukob zaključavanja
• Sukob zaključavanja tijekom izvođenja transakcije

Bok svima!

Neki dan sam na poslu naišao na problem s zaključavanjima, naime počela mi se pojavljivati ​​poruka "Konflikt zaključavanja tijekom izvođenja transakcije. Prekoračeno je maksimalno vrijeme čekanja za dodjelu zaključavanja".

Očito, ovdje nema problema sa zastojem, samo je neka sesija stavila zaključavanje i "zaboravila" ga ukloniti. Istodobno, problem je prijetio ozbiljnim posljedicama - dokument Prodaja roba i usluga nije proveden. U bazi podataka radi oko 100 ljudi odjednom, a tipičnu i čestu operaciju nemoguće je izvesti!

Postojala su dva rješenja - ponovno pokretanje poslužitelja ili traženje neuspjele sesije. Prvo rješenje je jednostavno i brzo, ali, kao što je netko već napisao ovdje, možete restartati server dok ne dobijete otkaz. Odlučio je ići drugim putem.

Prvi dan - problem se pojavio popodne, prvo se činilo da je problem u udaljenom korisniku koji je zapeo u konfiguratoru. Izgledalo je kao da je izvršenje stalo na jednom mjestu, a brava, naravno, nije otpuštena. Nakon par sati uspjeli smo pustiti konfigurator, ali problem nije nestao. Bilo je krajnje nepoželjno nasilno ubiti konfigurator, možda su radili u njemu. Nakon toga preuzeo je Google. Pronašao sam članak na ovoj stranici, koji govori kako pronaći brave u MS SQL DBMS-u, provjerio, nije bilo zaključavanja na razini DBMS-a. Čudan. Dalje je bilo pokušaja da se to prilagodi. časopis. Postavite, što je sljedeće? Za 15 minuta par giga balvana! Kako ih čitati, što tražiti? Nepoznato.

Pronašao sam članak o tome kako vidjeti što je blokirano putem SQL Tracea. Čak i ako ga nađem, što onda? Trebam sesiju!

Bliže 16:00, kada sam shvatio da ne mogu dalje, napravio sam ponovno pokretanje. U nadi da se to više neće dogoditi (a ovo je bio prvi slučaj u šest mjeseci rada), odahnuo sam, sve je radilo. Ali uzalud... Drugi dan - ista situacija. Kopao sam sat i pol, opet neshvatljivi pokušaji guglanja i tako dalje. Nema rezultata. Ponovno podizanje sustava. Na kraju dana opet se dogodilo. Pa, mislim da je super, mirno ću doći kući i sjediti, kopati dublje. Dođem kući, sve je u redu. Nažalost.

Trećeg dana gledao sam webinar i govorio o zanimljivom i učinkovitom načinu pronalaženja problema. Zapamtio, ali problem se više nije pojavio. Prošlo je tjedan dana i evo ga - opet blokada! Trljam ruke i počinjem djelovati.

Prvi je postavljanje dnevnika. Da, ne mogu bez njega, ali sada ga mogu čitati. Postavili smo dva događaja: prvi je TLOCK, drugi je TTIMEOUT. Prvi prikazuje sve blokade, drugi prikazuje blokade koje se nisu mogle uspostaviti u zadanom vremenu. Zapravo, najvjerojatnije je dovoljan samo TTIMEOUT.

Kopiramo datoteku tehničkog dnevnika na dodijeljeno mjesto, letimo do programa, pozivamo bravu, primamo poruku i uklanjamo ili preimenujemo datoteku tehničkog dnevnika. Ne treba nam gomila informacija o drugim blokadama!

Idite u mapu rphost_PID, pronađite tekstualne datoteke i potražite riječ TTIMEOUT. Vidimo liniju:

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=8239

Usput, može postojati nekoliko mapa rphost_PID, sve ovisi o tome koliko se radnih procesa izvodi na poslužitelju.

A onda je sve jednostavno: pogledajte kraj retka - WaitConnections = 8239, ovo je naš CONNECTION broj. Idemo na konzolu poslužitelja, idemo na Veze, pronalazimo ovaj broj i gledamo broj sesije. U mom slučaju, bile su dvije sesije po korisniku - jedna neuspjela i neka druga. Srušio se sesiju naznačenu tehničkim zapisnikom. I o čudu! Sve je radilo, radosti nema granica! Ali, kako se kasnije ispostavilo, sesija nije bila obješena :), radili su u njoj. Stoga je za ubuduće preporučljivo kontaktirati korisnika i upozoriti ga.

Po mom mišljenju, prilično tipično rješenje za prilično tipičan problem. Nije poznato zašto nisam naišao na njega, možda zbog činjenice da sam ga morao tražiti na alarmu, a kada korisnici nisu pritisnuli, tada nije bilo moguće provesti testove - nije bilo pogreške.

Nerijetko se pri radu u 1C pojavljuje pogreška "Sukob zaključavanja pri izvršavanju transakcija: prekoračeno je maksimalno vrijeme čekanja za dodjelu zaključavanja". Njegova bit leži u činjenici da nekoliko sesija pokušava istovremeno izvršiti slične radnje, utječući na isti resurs. Danas ćemo shvatiti kako popraviti ovu grešku.

Veliki broj operacija

Prije svega, kada tražite razloge, trebali biste razjasniti koliko je istovremeno aktivnih korisnika u informacijskoj bazi u kojoj se generira takva pogreška. Kao što znamo, njihov najveći broj može biti prilično velik. To je tisuću i pet tisuća.

Mehanizam zaključavanja i transakcija opisan je u vodiču za programere. Koriste se kada više sesija pristupa istim podacima u isto vrijeme. Logično je da iste podatke ne mogu mijenjati različiti korisnici u istom trenutku.

Također biste trebali provjeriti je li netko od korisnika započeo obradu za masovnu promjenu podataka. Može biti kao , zatvaranje mjeseca i slično. U tom slučaju, nakon završetka obrade, greška će nestati sama od sebe.

Planirani zadaci

Nije rijetkost da uzrok greške leži u, koji obrađuje veliku količinu podataka. Preporuča se takve stvari raditi noću. Zakažite izvršenje tako planiranih zadataka u neradno vrijeme.

Tako će oba korisnika raditi u stabilnom sustavu, a sami planirani zadaci bit će uspješno dovršeni, jer će se smanjiti vjerojatnost sukoba s korisničkim sesijama.

"Zaglavljene sesije"

Problem "zaustavljenih sesija" korisnika poznat je gotovo svima koji su se susreli s uslugom 1C. Korisnik je mogao davno izaći iz programa ili zatvoriti dokument, ali njegova sesija i dalje ostaje u sustavu. Problem je najčešće pojedinačni i dovoljno je prekinuti takvu sesiju preko administratorske konzole. Isti se problemi mogu pojaviti s pozadinskim poslovima.

Prema brojnim komentarima na internetu, ovakve situacije su češće kod korištenja mrežnih sigurnosnih ključeva. Ako se sustavno ponavlja situacija s "zaustavljenim sesijama", to je razlog za temeljitu provjeru i održavanje sustava i poslužitelja (ako je baza klijent-poslužitelj).

Greške prilikom pisanja konfiguracije

Sve tipične konfiguracije razvijaju kvalificirani stručnjaci i stručnjaci. Svaki sustav je pažljivo ispitan i optimiziran za brži i ispravniji rad u njemu.

U tom smislu, uzrok pogreške može ležati u neoptimalnom kodu koji je napisao programer treće strane. Ovo može biti "težak" zahtjev koji će blokirati podatke na dulje vrijeme. Također nije neuobičajeno izgraditi algoritme s niskim performansama i kršenjem logike.

Vrlo je vjerojatno da je do sukoba zaključavanja došlo upravo zbog programerskih pogrešaka ako je do njega došlo nakon ažuriranja programa. Da biste provjerili, možete jednostavno "vratiti" poboljšanja ili refaktorirati kod.