Na višekorisničkim sistemima važnu ulogu igra pravilnu organizaciju konstrukcije i postavljanje brava. U suprotnom, korisnici će često naići na greške uzrokovane konkurencijom za određene sistemske resurse. Ali postoji problem sukoba zaključavanja s kojim su mnogi korisnici upoznati. Zašto dolazi do sukoba zaključavanja 1C i kako ga popraviti?
Sukob zaključavanja u 1C 8.3 i njegovo značenje
Za većinu korisnika, poruka o sukobu 1C zaključavanja znači samo grešku koja ih sprečava da rade svoj posao. Žele se što prije riješiti ovog problema i opsjedati IT odjel pritužbama da "1C ne radi".
Ali za administratori sistema i programerima, takva poruka ukazuje na mogući problem u strukturi konfiguracije. Prije nego pokušate zadovoljiti korisnike i ukloniti blokove, morate analizirati situaciju i razumjeti uzrok poruke o grešci.
Uzroci grešaka u blokiranju u 1C
Demonstrativni testovi opterećenja pokazuju da 1C server može izdržati paralelni rad više od pet hiljada korisnika. Ali idealni uslovi za ovakve eksperimente nedostižni su u svakodnevnim uslovima velikih i srednjih kompanija. Da bi se postigle slične performanse i performanse bez grešaka, konfiguracija mora biti idealno dizajnirana i prilagođena specifičnim poslovnim procesima preduzeća.
Ako ne uzmete idealne opcije, tada dolazi do sukoba zaključavanja 1C iz sljedećih razloga:
Istovremeni rad korisnika sa velikom količinom podataka. Ovaj osnovni uzrok je diktiran unutrašnjim mehanizmima 1C. Oni podrazumijevaju zabranu promjene podataka uključenih u transakciju pokrenutu u ime drugog korisnika;
Greške i nedostaci u konfiguraciji. Struktura standardnih rješenja kompanije "1C" uzima u obzir preporuke za maksimiziranje produktivnosti. Ali programeri trećih strana ne pridržavaju se uvijek visokih standarda i često možete pronaći sljedeće nedostatke u njihovom kodu:
- Suboptimalni upiti;
- Zahtjev za stanje na početku akcija;
- Nerazumijevanje svrhe konfiguracijskih objekata i njihove nepravilne upotrebe;
- Redundantnost svojstvena sistemu ili dodatno razvijene brave.
Kako popraviti sukob zaključavanja u 1C 8.3
Sistemska poruka "konflikt zaključavanja tokom izvršavanja transakcije 1C 8.3" ne karakteriše konfiguraciju kao pogrešno dizajniranu. Ali ako se takvi signali zanemare, postoji mogućnost da u najbitnijem trenutku, na primjer, pri podnošenju kvartalnih ili godišnjih izvještaja, dođe do velikih problema. U najboljem slučaju, sistem koji usporava i nezadovoljni korisnici. U najgorem slučaju, netačni izlazni podaci, što može dovesti do kazni od strane regulatornih tijela.
Rješenje problema sukoba brava u 1C 8.3 može biti prijenos konfiguracije u upravljani (ručni) način upravljanja bravama. Implementiran u verziji 8.1, mehanizam u rukama kompetentnih stručnjaka rješava problem sukoba zaključavanja tokom transakcija u 1C.
Ali treba imati na umu da će ova akcija smanjiti nivo zaštite podataka od promjena u procesu čitanja od strane drugih korisnika. Stoga, ako niste spremni samostalno kontrolirati sve brave u sistemu, nemojte žuriti s promjenom postavki konfiguracije.
Brzo rješavanje konflikta 1C zaključavanja
U radu administratora ili programera može doći do situacije u kojoj nema vremena za provjeru greške i pronalaženje osnovnih uzroka problema. Na primjer, morate podnijeti izvještaj ili dostaviti podatke do određenog vremena, a greške blokiranja 1C to sprečavaju.
Postoje dva načina za brzo rješavanje problema:
- Pronađite i završite sesiju koja je zaključala potrebne podatke. IN mala preduzeća, gdje broj korisnika 1C ne prelazi nekoliko desetina ljudi, ovo je najbolje rješenje;
- Ako kontrolišete sistem koji ima stotine zaposlenih, pronađite pravu sesiju bez specijalizacije softver može dugo trajati. U ovom slučaju biće mnogo efikasnije ponovo pokrenuti server.
Ova rješenja su radikalna i usmjerena samo na brzo rješavanje problema i puštanje podataka za hitno izvještavanje. Može se iskorijeniti samo razumijevanjem razloga zbog kojih je došlo do sukoba zaključavanja tokom izvršenja 1C transakcije. Nakon ovakvih radnji potrebno je pronaći ranjivosti u sistemu, optimizirati konfiguraciju ili rad zaposlenih. Ne preporučuje se korištenje takvih mjera na stalnoj osnovi s redovnim sukobima zaključavanja transakcija.
Zdravo svima!
Pre neki dan na poslu sam naišao na problem sa zaključavanjem, naime počela je da se pojavljuje poruka "Konflikt zaključavanja prilikom izvršavanja transakcije. Prekoračen je maksimalni timeout za odobravanje zaključavanja".
Očigledno, ovdje nema problema sa zastojem, samo je neka sesija stavila zaključavanje i "zaboravila" ga ukloniti. Istovremeno, problem je prijetio ozbiljnim posljedicama - dokument Prodaja robe i usluga nije izvršen. U bazi podataka istovremeno radi oko 100 ljudi i nemoguće je izvesti tipičnu i čestu operaciju!
Postojala su dva rješenja - ponovno pokretanje servera ili traženje neuspjele sesije. Prvo rešenje je jednostavno i brzo, ali, kao što je neko ovde već napisao, možete ponovo pokrenuti server dok ne dobijete otkaz. Odlučio sam krenuti drugim putem.
Prvi dan - problem se pojavio popodne, isprva se činilo da je problem u udaljenom korisniku koji je zaglavio u konfiguratoru. Izgledalo je kao da je pogubljenje u jednom trenutku stalo, 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 oni radili u njemu. Nakon toga, Google je preuzeo. Našao sam članak na ovoj stranici, koji kaže kako pronaći brave u MS SQL DBMS-u, provjerio, nije bilo brava na nivou DBMS-a. Čudno. Dalje je bilo pokušaja da se oni prilagode. časopis. Postavite, šta je sljedeće? Za 15 minuta par svirki balvana! Kako ih čitati, šta tražiti? Nepoznato.
Našao sam članak o tome kako vidjeti što je blokirano kroz SQL Trace. Čak i ako ga nađem, šta onda? Treba mi sesija!
Bliže 16:00, kada sam shvatio da ne mogu dalje, napravio sam restart. U nadi da se ovo više neće ponoviti (a ovo je bio prvi slučaj u šest mjeseci rada), odahnuo sam, sve je uspjelo. Ali uzalud... Drugi dan - ista situacija. Kopao sam sat i po, opet neshvatljivi pokušaji guglanja i tako dalje. Nema rezultata. Ponovo pokreni. Na kraju dana to se ponovilo. 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 sam gledao webinar, pričao o zanimljivom i efikasan metod tražiti problem. Zapamtio, ali problem više nije nastao. Prošla je sedmica i evo - opet blokada! Trljam ruke i počinjem djelovati.
Prvi je postavljanje dnevnika. Da, ne mogu bez njega, ali sada mogu da ga čitam. Postavljamo dva događaja: prvi je TLOCK, drugi je TTIMEOUT. Prvi prikazuje sve događaje blokiranja, drugi prikazuje blokade koje nije bilo moguće uspostaviti u zadanom vremenu. U stvari, najvjerovatnije je samo TTIMEOUT dovoljan.
Kopiramo datoteku tehničkog dnevnika na dodijeljeno mjesto, letimo do programa, pozivamo bravu, primamo poruku i uklanjamo ili preimenujemo datoteku tehničkog dnevnika. Ne trebaju nam tone informacija o drugim blokiranjima!
Idite u folder 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=8239Usput, može postojati nekoliko foldera rphost_PID, sve ovisi o tome koliko radnih procesa se pokreće na serveru.
A onda je sve jednostavno: pogledajte na kraju reda - WaitConnections = 8239, ovo je naš CONNECTION broj. Idemo na konzolu servera, idemo na Connections, pronalazimo ovaj broj i gledamo broj sesije. U mom slučaju su bile dvije sesije po korisniku - jedna neuspješna i još neka. Srušila sesiju naznačenu tehničkim dnevnikom. I o čudu! Sve je uspjelo, radosti nema granice! Ali, kako se kasnije ispostavilo, sesija nije okačena :), oni su radili u njoj. Stoga je ubuduće preporučljivo kontaktirati korisnika i upozoriti.
dosta po mom mišljenju standardno rješenje dosta uobičajenog problema. Ne zna se zašto nisam naišao, možda zbog činjenice da sam ga morao tražiti na alarmu, a kada korisnici nisu pritisnuli, onda nije bilo moguće provesti testove - nije bilo greške.
„Konflikt zaključavanja tokom izvršenja transakcije: Maksimalno vremensko ograničenje za odobravanje zaključavanja je prekoračeno“ je prilično česta greška u 1C 8.3 i 8.2 povezana sa konkurencijom za korišćenje resursa u sistemu.
1C sistem omogućava da veliki broj korisnika radi paralelno: kako pokazuju testovi opterećenja, danas ovaj broj nije ograničen na pet hiljada korisnika koji istovremeno rade u sistemu. Međutim, tako da 1C 8 baza podataka može istovremeno podržavati velike količine o korisnicima, konfiguracija mora biti pravilno dizajnirana.
Nabavite 267 1C video lekcija besplatno:
Izvođenje velikog broja operacija
Vjerovatno je da je neki korisnik započeo, na primjer, duži period u jednoj transakciji. Arhitektura 1C 8.3 pretpostavlja da sistem ne dozvoljava promjenu podataka koje drugi korisnik koristi u jednoj transakciji i blokira ih.
Možda je ovo privremena greška koja će se prestati javljati kada drugi korisnik završi radnje na sistemu. Ako se ova greška često pojavljuje, onda je najvjerovatnije nešto drugo.
Greška u konfiguraciji
Pored grešaka u kodu, često postoje metodički pogrešna rješenja. Na primjer, - to samo po sebi podrazumijeva sekvencijalno držanje dokumenata. Batch računovodstvo može biti zamijenjeno RAUS-om - na taj način ćete ozbiljno povećati performanse sistema.
Kako popraviti ovu grešku u 1C 8.3?
U svakom slučaju, pojava greške „Konflikt zaključavanja prilikom izvršavanja transakcije“ ukazuje na potrebu pregleda sistema, posebno za srednje i velike informacioni sistemi u klijent-server modu (MS SQL, PostgreSQL, itd.). Ako se ovo zanemari u ranoj fazi, može doći do nepovratnih posljedica kasnije, kada je rad sistema posebno važan (u izvještajnom periodu).
Za reviziju i ispravljanje grešaka najbolje je izabrati pouzdanog partnera. Samo nas pozovite i mi ćemo riješiti svaki vaš problem što je brže moguće. Detalji na stranici.
Nerijetko se prilikom rada u 1C javlja greška "Konflikt zaključavanja prilikom izvršavanja transakcija: prekoračeno je maksimalno vrijeme čekanja za odobravanje zaključavanja". Njegova suština 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, trebate razjasniti koliko korisnika istovremeno radi u infobazi u kojoj je takva greška generirana. Kao što znamo, njihov maksimalni broj može biti prilično velik. To je hiljadu i pet hiljada.
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 da li je neko 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 neuobičajeno da uzrok greške leži u tome što obrađuje veliku količinu podataka. Preporučljivo je raditi takve stvari noću. Zakažite izvršenje takvih zakazanih zadataka u neradno vrijeme.
Tako će oba korisnika raditi u stabilnom sistemu, a sami zakazani zadaci će biti uspješno završeni, jer će se smanjiti vjerovatnoća sukoba sa korisničkim sesijama.
"Zaglavljene sesije"
Problem "obješenih sesija" korisnika poznat je gotovo svima koji su se susreli s 1C uslugom. Korisnik je mogao odavno izaći iz programa ili zatvoriti dokument, ali njegova sesija i dalje ostaje u sistemu. Problem je najčešće pojedinačni i dovoljno je da prekinete takvu sesiju preko administratorske konzole. Isti problemi se mogu pojaviti i sa poslovima u pozadini.
Prema brojnim komentarima na Internetu, takve situacije su češće kada se koriste mrežni sigurnosni ključevi. Ako se situacija sa "zakačenim sesijama" sistematski ponavlja, to je razlog za temeljnu proveru i održavanje sistema i servera (ako je baza klijent-server).
Greške prilikom pisanja konfiguracije
Dizajnirane su sve tipične konfiguracije kvalifikovanih specijalista i stručnjaci. Svaki sistem je pažljivo testiran i optimizovan za brži i ispravniji rad u njemu.
S tim u vezi, uzrok greške može biti u neoptimalnom kodu koji je napisao programer treće strane. Ovo može biti "težak" zahtjev koji će blokirati podatke na duži vremenski period. Takođe nije neuobičajeno da se grade algoritmi sa niskim performansama i kršenjem logike.
Velika je vjerovatnoća da je sukob zaključavanja nastao upravo zbog grešaka programera ako je nastao nakon ažuriranja programa. Da biste provjerili, možete jednostavno "vratiti" poboljšanja ili refaktorirati kod.
Pitanje: UT11.1. Batch kreiranje implementacija. Lock Conflict
Dobar dan UT11.1 konfiguracija. Klijent-server opcija. Zadane postavke za 1C Server i SQL Server. Programski formiramo implementacije. U fazi pisanja dokumenata periodično dolazi do sukoba zaključavanja. Možete li mi reći kako se takvi problemi rješavaju? Koriste li se transakcije s upravljanim bravama? Hvala unapred.
odgovor:
nemojte ga isključivati) prebacite ih na noć - može doći do obračuna troškova i uzimaju se u obzir indeksi pretraživanja.
Pitanje: Konflikt zaključavanja tokom izvršavanja transakcije
Svaki dan, gotovo u isto vrijeme, kada držite dokument, iskoči na 5-10 minuta data greška 1S 8.3.10.26.99 UT11(11.4.1.261):
Sukob zaključavanja prilikom izvršavanja transakcije:
Microsoft Sql Server Native Client 11.0: Isteklo je vrijeme zahtjeva za zaključavanje.
OVDJE=80040E31, SqlServer: SQLSTATE=HYT00, stanje=38, ozbiljnost=10, izvorno=1222, red=1
Reci mi gdje da počnem kopati?
odgovor:() Omogućite profiler u ovom trenutku na događajima Lock:Acquired i Lock:Escalation. Onda javite šta ste dobili.
Pitanje: Oporavak baze podataka (konflikt zaključavanja)
Dobar dan. Baza umire. Server.
Ispostavilo se ne odmah, jer. sve je radilo osim izdatog dokumenta sf. I ne pravi se često. Dakle, backup nije relevantan (očigledno je prošlo nekoliko dana), pokušali su postaviti kopiju prije 2 dana - bilo je normalno pola dana, a onda je isti problem izašao.
Simptomi: kada pokušamo da otkažemo SF, dobijamo konflikt zaključavanja, čak i ako postoji jedan korisnik u bazi podataka. TII (provjera logičkog i referencijalnog integriteta) ne uspijeva s sukobom zaključavanja, stvarajući sigurnosnu kopiju kroz sql management studio - isto ("Isteklo je vrijeme čekanja za zatvaranje bafera tipa 3 za stranicu").
Želimo da pokušamo da popunimo cf pre nedelju dana, ali malo je nade za nešto.
odgovor: postoje problemi sa serverom baze podataka, a ne 1C, verzije konfiguracije itd. nemaju veze sa tim.
Možda je nenadzirana jagodična kost živjela najbolje što je mogla sve dok je bilo dovoljno sredstava, a sada autor započinje novu fazu u razvoju znanja.
Ako veličina dozvoljava - prenesite u datoteku i počnite učiti sql dublje.
Pitanje: UT10. Lock Conflict
Dobar dan Klijent-server opcija. Naslijedio sam jako izmijenjenu BitAuto konfiguraciju (auto servis baziran na UT10). U rukovaocu dokumenta "narudžba-narudžba", glavnom za prijem majstora i rukovodioca, formiranje pratećih dokumenata (realizacija, faktura, fakturni zahtev), obračun plate mehaničara, rezervacija robe, ako je novi dokument , zatim kreiranje naloga - kupac i još neke funkcionalnosti. Baza podataka je rasla i često su se počeli javljati sukobi zaključavanja. Vikendom, kada je manje ljudi, nema sukoba.
Pretpostavljam da je sa ovom količinom analize, tokom dokumenta, dugo vrijeme blokira neki dnevnik dokumenata, iako se čini da je dnevnik naloga potpuno blokiran.
Ako napravite sopstvenu proceduru kao rukovalac dugmeta "OK", gde uzastopno pokrećete "Obrada", a zatim proceduru, na primer, Generiraj podređene dokumente, zatim Izračunaj platu, itd. Nisam siguran da li bi ovo pomoglo. Dodavanje dugmadi na koje se okači formiranje dokumenata neće raditi, jer. korisnici će zaboraviti na to.
odgovor:
| Zero |
|---|
| vde69, Patko, to je vjerovatno neka vrsta Raru sranja |
Ne, ovo nije Rarus, ovo je BitAuto
Pitanje: 1c sukob zaključavanja prilikom otvaranja obrasca dokumenta
SCP
Nedavno, jednom u 2-3 dana, dolazi do blokade na dokumentu reklamacija-faktura. One. nijedan dokument ove vrste nije otvoren. Stalno
Ostali dokumenti rade dobro.
Nisam pronašao probleme u debageru, nemam vremena da se zaustavim ni u jednom modulu - odmah dolazi do sukoba zaključavanja.
Sumnjam na neki problem u SQL-u.
odgovor: Problem je bio posao održavanja indeksa koji nije dovršen.
Pitanje: SQL2000 greška za vrijeme izvršenja transakcije u 1C77
u MSSQL bazi 1C77 (izdanje 27) TiS. Redovno prilikom objavljivanja iskače greška:
Došlo je do greške prilikom izvršavanja transakcije!
SQL stanje: HYT00
Izvorno:0 Poruka: Vremensko ograničenje je isteklo.
Kao rezultat toga, dokument ne uspijeva. Može trajati 20 minuta, ili možda 1 sat.
Kako se nositi s tim, gdje kopati?
S poštovanjem,
Steve242
Fajl je priložen poruci. Veličina - 21Kb
odgovor:
Običan Windows perfmonitor je pokazao da Terminal pakleno učitava C:\ sistemski disk.
Sve ostalo: Memorija, CPU - na oba servera (terminal i whine) gotovo da se ne prikazuju anomalni rafali.
Napravio sam 2Gb RAMdrive (od 12Gb fizički dostupnih na terminal serveru) i pokušavam tamo preusmjeriti privremene sistemske direktorije profila korisnika terminala.
do tako nesto.
Pitanje: Još jednom o sukobu zaključavanja prilikom izvršavanja transakcije
odgovor:
Pitanje: Blokiranje prilikom pretplate na RTiU
odgovor:
Pitanje: Linux, Postgres, Retail 2.0.5.1 Ukrajina RIB u prodavnici - greška blokiranja...
Može li mi neko reći? Postavljam mjenjačnicu. Sve radi dobro, ispostavilo se da se vrši razmjena rukama. Prosleđuje se 4-5 poruka. Onda postavim scenario prema rasporedu i počinje ljuljačka... Prva greška:
"Greška pri pisanju podataka za razmjenu datoteke poruke: (Processing.ConvertingDistributedInfobaseObjects.ObjectModule()): Greška pri pozivanju metode konteksta (WriteChanges): Konflikt zaključavanja tijekom transakcije:
Maksimalno vrijeme mirovanja za pristup zaključavanju je prekoračeno zbog čekanja na sesiju"
sve sljedeće:
"Greška pri pisanju podataka u datoteku poruke za razmjenu: (Processing.ConvertingDistributedInfoBaseObjects.ObjectModule()): Greška prilikom pozivanja metode konteksta (WriteChanges): Konflikt zaključavanja tijekom izvršavanja transakcije:
Maksimalno vremensko ograničenje za odobravanje zaključavanja je prekoračeno"
Ni ponovno indeksiranje ni zatvaranje sesija ne pomažu. Blokiranje u 1C se ne isplati. Pomaže samo uklanjanje osnove i ponovno stvaranje.
Kako sam shvatio blokiranje tranzita u DBMS-u? Koristim Postgress na Linuxu, 1 baza podataka, 4GB RAM-a. Ako sam u pravu, pitanje je Postgress pogrešno konfigurisan ili nemate memoriju? Ili možda to uopšte nije problem?
odgovor:() Dakle svježe je 8.3.10.2375
Pitanje: Greška blokiranja prilikom brisanja registra informacija
Odaberem RS zapise upitom, zatim:
RecordSet.Load(QueryResult.Unload()); RecordSet.Clear(); RecordSet.Write();
Kada pokušam da pišem, dobijam grešku:
"Konflikt zaključavanja tokom izvršavanja transakcije."
Registar nije periodičan, nije podređen matičaru.
Šta je razlog greške?
odgovor:() "Iz nekog razloga sam bio siguran da se odabir primjenjuje samo u vrijeme čitanja, a ono što je uključeno u izbor je napisano u skladu s tim." - Gdje koristite riječ "selekcija" barem jednom u svom kodu?
