Nisam mogao zapisati promjene za prijenos u distribuiranu bazu podataka, pa sam kontaktirao podršku 1C i ponudio sljedeće. Riješio sam to jednostavnim ponovnim pokretanjem aplikacijskog poslužitelja i SQL poslužitelja. Općenito, možete potvrditi okvir "Blokiranje regulatornih
uključeni zadaci"
Pomoglo je i bez ponovnog pokretanja.

Rutinske operacije na razini DBMS za MS SQL Server

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

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

Opće informacije

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

Ako se uoče bilo kakvi simptomi problema s performansama u sustavu koji radi, trebali biste provjeriti je li sustav ispravno konfiguriran i redovito izvodi sve preporučene rutinske operacije na razini DBMS-a.

Provedba regulatornih postupaka mora biti automatizirana. Za automatizaciju ovih operacija preporučuje se korištenje ugrađenog MS SQL Server alata: Plan održavanja. Postoje i drugi načini automatizacije ovih postupaka. Za svaki regulatorni postupak ovaj članak daje primjer kako ga konfigurirati pomoću plana održavanja za MS SQL Server 2005.

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

Ažurirajte statistiku

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 može doći do problema s izvedbom upita. U isto vrijeme planovi upita pokazuju karakteristične znakove neoptimalnog rada (neoptimalne operacije).

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

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

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

Ažuriranje statistike ne dovodi do zaključavanja tablice i neće ometati rad drugih korisnika. Statistika se može ažurirati onoliko često koliko je potrebno. Treba uzeti u obzir da će se opterećenje DBMS poslužitelja povećati tijekom ažuriranja statistike, š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ča se 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 najviše trebaju česta ažuriranja statistike 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.

Postavljanje 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 (Dodaj podplan) i nazovite ga “Ažuriranje statistike”. 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.

Konfigurirajte 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 statistika ažurirati. Osim toga, možete odrediti za koje tablice treba ažurirati statistiku (ako ne znate točno koje tablice trebate navesti, tada postavite vrijednost na Sve).

Statistika se mora ažurirati s uključenom opcijom Full Scan.

Spremite izrađeni plan. Kada dođe vrijeme navedeno u rasporedu, ažuriranje statistike započet će automatski.

Brisanje proceduralne predmemorije

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

Moguće je da će MS SQL Server, na temelju zastarjelih statističkih podataka, izgraditi neoptimalan plan upita. Ovaj plan će biti pohranjen u proceduralnu predmemoriju i korišten kada se isti upit ponovno pozove. Ako ažurirate statistiku, ali ne izbrišete predmemoriju procedura, SQL Server može odabrati stari (neoptimalan) plan upita iz predmemorije umjesto izgradnje novog (optimalnijeg) plana.

Da biste očistili proceduralnu predmemoriju MS SQL Servera, trebate pokrenuti sljedeći SQL upit:

Ovaj upit treba pokrenuti odmah nakon ažuriranja statistike. U skladu s tim, učestalost njegovog izvršenja mora se podudarati s učestalošću ažuriranja statistike.

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

Budući da se proceduralna predmemorija mora obrisati svaki put kada se statistika ažurira, preporuča se dodati ovu operaciju u već kreirani podplan “Ažuriranje statistike”. 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 zadatka Izvrši T-SQL naredbu trebate navesti zahtjev “DBCC FREEPROCCACHE”:

Defragmentacija indeksa

Prilikom intenzivnog rada s tablicama baze podataka dolazi do fragmentacije indeksa, što može dovesti do smanjene izvedbe upita.

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

Defragmentacija indeksa ne zaključava tablice i neće ometati rad drugih korisnika, ali 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ča se da defragmentirate indekse barem jednom tjedno.

Možete defragmentirati jednu ili više tablica, umjesto svih tablica u bazi podataka.

Postavljanje defragmentacije indeksa (MS SQL 2005)

U prethodno stvorenom planu održavanja, stvorite novi podplan pod nazivom "Reindexing" u njega.

Postavite raspored izvršenja za zadatak defragmentacije indeksa. Zadatak se preporuča obavljati barem jednom tjedno, a ako su podaci u bazi vrlo varijabilni, i češće - do jednom dnevno.

Ponovno indeksiranje tablica baze podataka

Ponovno indeksiranje tablice uključuje potpunu ponovnu izgradnju indeksa tablice baze podataka, što dovodi do značajne optimizacije njihove izvedbe. Preporuča se redovito ponovno indeksirati tablice baze podataka. Da biste ponovno indeksirali sve tablice baze podataka, trebate pokrenuti sljedeći SQL upit:

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

Reindeksiranje tablica ih zaključava za cijelo vrijeme njihovog rada, što može značajno utjecati na korisničko iskustvo. U tom smislu, preporuča se ponovno indeksiranje tijekom minimalnog opterećenja sustava.

Nakon dovršetka ponovnog indeksiranja nema potrebe za defragmentacijom indeksa.

Postavljanje ponovnog indeksiranja tablice (MS SQL 2005)

U prethodno stvorenom planu održavanja stvorite novi podplan pod nazivom Defragmentacija indeksa. Dodajte mu zadatak Rebuild Index:

Postavite raspored izvršenja za zadatak ponovnog indeksiranja tablice. Preporuča se izvršiti zadatak tijekom minimalnog opterećenja sustava, barem jednom tjedno.

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

U višekorisničkim sustavima pravilna organizacija strukture i postavljanje brava igra važnu ulogu. Ako ga nema, korisnici će se često morati nositi s pogreškama uzrokovanim konkurencijom za određene resurse sustava. Ali postoji problem sukoba zaključavanja koji je poznat mnogim korisnicima. Zašto dolazi do sukoba zaključavanja 1C i kako ga riješiti?

Sukob zaključavanja u 1C 8.3 i njegovo značenje

Za većinu korisnika poruka o sukobu zaključavanja 1C znači samo pogrešku koja ih sprječava u obavljanju posla. Žele se riješiti ovog problema što je prije moguće i opsjedaju IT odjel pritužbama da "1C ne radi."

Ali za administratore sustava i programere, takva poruka ukazuje da možda postoje problemi u strukturi konfiguracije. Prije nego što pokušate zadovoljiti korisnike i ukloniti blokade, morate analizirati situaciju i razumjeti razlog poruke o pogrešci.

Razlozi za blokiranje pogrešaka u 1C

Demonstrativno testiranje opterećenja pokazuje da 1C poslužitelj može izdržati paralelni rad više od pet tisuća korisnika. Ali idealni uvjeti za takve eksperimente nedostižni su u svakodnevnim uvjetima velikih i srednjih poduzeća. Za postizanje sličnih performansi i rada bez grešaka, konfiguracija mora biti idealno dizajnirana i prilagođena specifičnim poslovnim procesima poduzeća.

Ako ne uzmemo idealne opcije, tada dolazi do sukoba zaključavanja 1C iz sljedećih razloga:

Istovremeni rad korisnika s velikom količinom podataka. Ovaj temeljni uzrok diktiraju unutarnji mehanizmi 1C. One uključuju zabranu promjena podataka uključenih u transakciju pokrenutu u ime drugog korisnika;

Greške i propusti u konfiguraciji. Struktura standardnih rješenja tvrtke 1C uzima u obzir preporuke za maksimiziranje produktivnosti. Ali programeri trećih strana ne pridržavaju se uvijek visokih standarda, au njihovom se kodu često mogu pronaći sljedeći nedostaci:

• Suboptimalni upiti;
• Zahtjev za stanja na početku akcija;
• Nerazumijevanje namjene konfiguracijskih objekata i njihova nepravilna uporaba;
• Redundancija blokada ugrađenih u sustav ili dodatno razvijenih.

Kako popraviti sukob zaključavanja u 1C 8.3

Poruka sustava "sukob zaključavanja prilikom izvršavanja transakcije 1C 8.3" ne karakterizira konfiguraciju kao pogrešno dizajniranu. Ali ako se takvi signali ignoriraju, postoji mogućnost upadanja u velike probleme u najvažnijem trenutku, na primjer, pri podnošenju tromjesečnih ili godišnjih izvješća. U najboljem slučaju, trom sustav i nezadovoljni korisnici. U najgorem slučaju, izlazni podaci su netočni, što može dovesti do kazni od strane regulatornih tijela.

Rješenje problema sukoba zaključavanja u 1C 8.3 može biti prijenos konfiguracije u upravljani (ručni) način upravljanja zaključavanjem. Implementiran u verziji 8.1, mehanizam u rukama kompetentnih stručnjaka rješava problem sukoba zaključavanja tijekom transakcije u 1C.

Ali vrijedi imati na umu da će ova radnja smanjiti razinu zaštite podataka od promjena dok ih čitaju drugi korisnici. Stoga, ako niste spremni samostalno kontrolirati sve brave u sustavu, nemojte žuriti s promjenom konfiguracijskih postavki.

Brzo rješenje za sukob zaključavanja 1C

U radu administratora ili programera može doći do situacije kada nema vremena za provjeru pogreške i traženje uzroka problema. Na primjer, potrebno je podnijeti izvješće ili dostaviti podatke do određenog vremena, ali pogreške blokiranja 1C to sprječavaju.

Postoje dva načina za brzo rješavanje problema:

• Pronađite i završite sesiju koja blokira potrebne podatke. U malim tvrtkama gdje broj korisnika 1C ne prelazi nekoliko desetaka ljudi, ovo je optimalno rješenje;
• Ako kontrolirate sustav sa stotinama zaposlenika, pronalaženje prave sesije bez specijaliziranog softvera može potrajati dugo. U ovom slučaju bit će puno učinkovitije ponovno pokrenuti poslužitelj.

Ova rješenja su radikalna i usmjerena su samo na brzo rješavanje problema i oslobađanje podataka za hitnu prijavu. Može se iskorijeniti samo razumijevanjem razloga zašto je došlo do sukoba zaključavanja prilikom izvršavanja 1C transakcije. Nakon takvih radnji potrebno je pronaći ranjivosti u sustavu, optimizirati konfiguraciju ili rad zaposlenika. Ne preporučuje se kontinuirano korištenje takvih mjera u slučaju redovitih sukoba zaključavanja transakcija.

Kada stotine korisnika istovremeno rade s programima i podacima, javljaju se problemi koji su karakteristični samo za velika rješenja. Govorimo o problemima uzrokovanim blokiranjem podataka.

Ponekad korisnici saznaju o blokiranju iz poruka koje pokazuju da ne mogu pisati podatke ili obavljati neku drugu radnju. Ponekad zbog vrlo značajnog pada performansi programa (na primjer, kada se vrijeme potrebno za izvođenje operacije poveća desetke ili stotine puta).

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

RAZLOZI ZA BLOKIRANJE TRANSAKCIJA

Prvo se prisjetimo što su brave, a istovremeno shvatimo jesu li potrebne. Pogledajmo nekoliko klasičnih primjera blokada 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 slobodnih mjesta, od kojih možemo odabrati ono koje nam se najviše sviđa (ako ih je više, naravno). Dok odabiremo i potvrđujemo našu suglasnost s predloženom opcijom, ta se mjesta ne mogu prodati nikome drugome, tj. su privremeno "blokirani". Ako nisu blokirani, tada bi do trenutka potvrde moglo doći do situacije da su ulaznice koje smo odabrali već bile prodane. I u ovom slučaju ciklus odabira može imati nepredvidiv broj ponavljanja. Dok biramo mjesta, ona su već prodana!.. Dok biramo druga, a njih više nema...

Primjer 2: kupnja nečega u trgovini ili na bazaru. Prišli smo pultu i od stotina dostupnih jabuka odabrali najljepšu. Odabrali su ga i posegnuli u džep po novac. Kako će izgledati ako u tom trenutku, 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 da su akcije dovršene u jednom koraku. A ono što najčešće dovodi do negativnosti nije najuspješnija implementacija softvera, kada npr.

• prevelik broj objekata (ulaznice, jabuke) je blokiran;
• Vrijeme blokade se neopravdano produljuje.

PREKOMJERNO BLOKIRANJE 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 kombinacije 1C:Enterprise + MS-SQL.

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

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

Gotovo sva standardna rješenja u predloženoj gotovoj implementaciji konfigurirana su za automatsko upravljanje zaključavanjem. “Automatsko” se ovdje može shvatiti kao “paranoično”. Za svaki slučaj, prilikom obrade bilo kojeg dokumenta blokiramo sve što bi moglo biti na neki način povezano s njim. Tako ispada da kada jedan korisnik nešto napravi (a ponekad samo zapiše), ostali mogu samo čekati.

Izrazit ću svoje mišljenje zašto je 1C odlučio ne konfigurirati svoja standardna rješenja za visoku paralelnu upotrebu. Troškovi rada za takvu modifikaciju nisu visoki - nekoliko "mjeseci čovjeka", što nije značajno na ljestvici 1C. Čini mi se da je razlog drugačiji.

Prvo, takva izmjena značajno komplicira obradu svih dokumenata. To znači da će za one potrošače koji koriste 1C za male zadatke, bez ikakvog dobitka, postojati samo nedostatak - poteškoće u modificiranju standardne konfiguracije postat će kompliciranije. Statistika nam ujedno govori koja je kategorija klijenata 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. Slučajno se dogodilo 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 odluku o "uštedi memorije i procesora" - da zaključa cijelu tablicu odjednom!..

Ovi nedostaci u standardnim rješenjima ili specifičnosti korištenog postavljanja poslužitelja baze podataka često se identificiraju s problemima uzrokovanim blokiranjem. Kao rezultat toga, tehnički nedostaci dovode do vrlo značajnih organizacijskih problema. Uostalom, ako se zaposleniku da razlog da ga se odvrati od posla ili da se opravda zašto posao nije mogao biti obavljen, manjina će raditi učinkovito. Pa poruka o blokiranju transakcija ili “kočenju” programa je idealno opravdanje zašto se nešto nije moglo napraviti.

PREPORUKE ZA UKLANJANJE PREKOMJERNIH BLOKIRANJA ZA 1C:ENTERPRISE

Što učiniti ako je rješavanje problema pretjeranog zaključavanja toliko važno?

U završnoj fazi implementacije svih velikih kompleksa potrebno je izvršiti fino podešavanje kako bi se uklonilo nepotrebno blokiranje transakcija. Ključno je riješiti probleme koji mogu nastati zbog nedovoljno razvijenih uvjeta blokiranja ili tehnika implementacije.

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

1. Ako DBMS ili razvojni sustav koji koristite (na primjer, 1C:Enterprise) prema zadanim postavkama koristi način automatskog zaključavanja podataka, odbijte automatsko upravljanje zaključavanjem. Sami konfigurirajte pravila blokiranja, opišite kriterije za blokiranje cijelih tablica ili pojedinačnih redaka.
2. Kada razvijate program, kad god je to moguće, pristupite tablicama istim redoslijedom.
3. Pokušajte ne pisati u istu tablicu više puta unutar iste transakcije. Ako je to teško, onda barem minimizirajte vremenski interval između prve i zadnje operacije pisanja.
4. Analizirati mogućnost onemogućavanja eskalacije zaključavanja na razini SQL poslužitelja.
5. Jasno obavijestite korisnike o razlozima zašto ne mogu izvršiti bilo kakve radnje ako su one zbog blokade. Dajte pristupačne i razumljive preporuke o tome što učiniti sljedeće.

Ako pažljivo pogledate preporuke, postaje jasno da takvo testiranje prikladno je ne samo za 1C:Enterprise, već i za sve sustave. Uopće nije važno na kojem su jeziku napisani i s kojim poslužiteljem baze podataka rade. Većina preporuka je univerzalne prirode, te su stoga jednako valjane kada koristite 1C:Enterprise i za „kućno pisane“ programe ili druge „kutijaste“ ERP sustave.

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

• Zaključavanja transakcija
• Uklanjanje blokada
• 1C brave
• brava
• Sukob zaključavanja
• Zaključaj sukob tijekom transakcije

"Sukob zaključavanja prilikom izvršavanja transakcije: premašeno je maksimalno vrijeme čekanja za dodjelu zaključavanja" prilično je uobičajena pogreška u 1C 8.3 i 8.2 povezana s natjecanjem za korištenje resursa u sustavu.

Sustav 1C omogućuje paralelni rad velikog broja korisnika: kao što pokazuje testiranje opterećenja, danas taj broj nije ograničen na pet tisuća korisnika koji istovremeno rade u sustavu. Međutim, kako bi baza podataka 1C 8 mogla istovremeno podržati veliki broj korisnika, konfiguracija mora biti pravilno dizajnirana.

Besplatno nabavite 267 video lekcija o 1C:

Izvođenje velikog broja operacija

Vjerojatno je neki korisnik pokrenuo npr. tijekom dugog razdoblja u jednoj transakciji. Arhitektura 1C 8.3 pretpostavlja da sustav ne dopušta promjenu podataka koje u jednoj transakciji koristi drugi korisnik i blokira ih.

Ovo može biti privremena pogreška koja će se prestati javljati kada drugi korisnik završi s radom na sustavu. Ako se ova pogreška često pojavljuje, najvjerojatnije se događa nešto drugo.

Greška u konfiguraciji

Osim grešaka u kodu, često postoje i metodološki pogrešne odluke. Na primjer, on sam po sebi podrazumijeva sekvencijalnu obradu dokumenata. Skupno računovodstvo može se zamijeniti s RAUZ - to će ozbiljno povećati produktivnost sustava.

Kako popraviti ovu grešku u 1C 8.3?

U svakom slučaju, pojava greške “Konflikt zaključavanja pri izvršavanju transakcije” ukazuje na potrebu pregleda sustava, posebno za srednje i velike informacijske sustave u načinu rada klijent-poslužitelj (MS SQL, PostgreSQL, itd.). Ako se to zanemari u ranoj fazi, moguće su nepopravljive posljedice kasnije, kada je rad sustava posebno važan (tijekom izvještajnog razdoblja).

Za reviziju i ispravljanje pogrešaka najbolje je izabrati pouzdanog partnera. Samo nas nazovite i svaki Vaš problem ćemo riješiti u najkraćem mogućem roku. Detalji na stranici.

Bok svima!

Neki dan sam na poslu naišao na problem s zaključavanjem, odnosno poruku "Postoji sukob zaključavanja tijekom izvršavanja transakcije. Maksimalno vrijeme čekanja za dodjelu zaključavanja je premašeno."

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 restartovati server dok vas ne otpuste. Odlučio sam krenuti drugim putem.

Prvi dan - problem se pojavio tijekom dana, u početku se činilo da je problem s udaljenim korisnikom koji se ulogirao u konfigurator. Izgledalo je kao da je izvršenje jednostavno stalo na jednom mjestu, a blokada, naravno, nije uklonjena. 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 u igru ​​je ušao Google. Našao sam članak na ovoj stranici koji govori kako pronaći zaključavanja u MS SQL DBMS-u, provjereno, nije bilo zaključavanja na razini DBMS-a. Čudno. Zatim je bilo pokušaja postavljanja tehn. časopis. Postavio sam, što sad? Za 15 minuta par giga balvana! Kako ih čitati, što tražiti? Nepoznato.

Pronašao sam članak o tome kako vidjeti što je blokirano pomoću SQL Tracea. Čak i ako ga pronađem, što dalje? Trebam sesiju!

Bliže 16:00, kada sam shvatio da više ne mogu čekati, napravio sam ponovno pokretanje. U nadi da se to neće ponoviti (a bilo je to prvi put 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 i kopati dublje. Dođem doma, sve je u redu. Nažalost.

Treći dan sam gledao webinar, govorili su o zanimljivom i učinkovitom načinu pronalaženja problema. Sjetio sam se, ali problem se više nije pojavio. Prošao je tjedan dana i evo ga - ponovno zaključavanje! Trljam ruke i počinjem djelovati.

Prvo, postavite dnevnik. Da, ne mogu bez njega, ali sada znam kako ga čitati. Postavili smo dva događaja: prvi je TLOCK, drugi je TTIMEOUT. Prvi prikazuje sve blokirajuće događaje, drugi prikazuje blokirajuće događaje koji se nisu mogli instalirati unutar dodijeljenog vremena. Zapravo, najvjerojatnije je dovoljan samo TTIMEOUT.

Kopiramo datoteku tehničkog dnevnika na za to predviđeno mjesto, uletimo u program, pozovemo blokadu, primimo poruku i uklonimo 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:

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 - neuspjela i neka druga. Sesija na koju je upućivao tehnički časopis se srušila. I gle čuda! Sve je radilo, radost nema granica! Ali, kako se kasnije ispostavilo, sesija nije bila zamrznuta :), radili su u njoj. Stoga je ubuduće poželjno kontaktirati korisnika i upozoriti ga.

Po mom mišljenju, prilično standardno rješenje za prilično standardni problem. Ne zna se zašto nisam naišao na njega, možda zato što sam ga morao tražiti zbog alarma, a kada ga korisnici nisu pritisnuli, nije bilo moguće provesti testove - nije bilo greške.