Si të rregulloni konfliktin e bllokimit 1s 8.3. Si i diagnostikova problemet e bllokimit. Një numër i madh i operacioneve të kryera

Nuk është e pazakontë kur punoni në 1C të merrni gabimin "Konflikti i bllokimit gjatë ekzekutimit të transaksioneve: Koha maksimale e pritjes për dhënien e një bllokimi është tejkaluar". Thelbi i tij qëndron në faktin se disa seanca po përpiqen të kryejnë njëkohësisht veprime të ngjashme, duke ndikuar në të njëjtin burim. Sot do të kuptojmë se si ta rregullojmë këtë gabim.

Një numër i madh i operacioneve të kryera

Hapi i parë kur kërkohen arsyet është të sqarohet se sa përdorues të njëkohshëm janë në bazën e informacionit në të cilën krijohet një gabim i tillë. Siç e dimë, numri maksimal i tyre mund të jetë mjaft i madh. Kjo është një mijë dhe pesë mijë.

Mekanizmi i mbylljes dhe transaksioneve përshkruhet në udhëzuesin e zhvilluesit. Ato përdoren kur seanca të shumta aksesojnë të njëjtat të dhëna njëkohësisht. Është logjike që të njëjtat të dhëna nuk mund të ndryshohen nga përdorues të ndryshëm në të njëjtën kohë.

Ju gjithashtu duhet të kontrolloni nëse ndonjë nga përdoruesit ka filluar përpunimin nga ndryshim masiv të dhëna. Kjo mund të jetë si, fundi i muajit dhe të ngjashme. Në këtë rast, pas përfundimit të përpunimit, gabimi do të zhduket vetë.

Detyrat e planifikuara

Nuk është e pazakontë që shkaku i një gabimi të qëndrojë në një sistem që përpunon sasi të mëdha të dhënash. Rekomandohet të bëni gjëra të tilla gjatë natës. Vendosni një orar për kryerjen e detyrave të tilla rutinë jashtë orarit të punës.

Në këtë mënyrë, përdoruesit do të punojnë në një sistem të qëndrueshëm dhe vetë detyrat rutinë do të përfundojnë me sukses, pasi gjasat e konflikteve me seancat e përdoruesve do të reduktohen.

"Seanca të varura"

Problemi i "seancave të mbërthyera" të përdoruesve është i njohur për pothuajse të gjithë ata që kanë hasur në shërbimin 1C. Përdoruesi mund të ishte larguar nga programi shumë kohë më parë, ose të mbyllte një dokument, por sesioni i tij mbetet ende në sistem. Problemi është më së shpeshti i izoluar dhe mjafton të përfundoni një seancë të tillë përmes tastierës së administratorit. Të njëjtat probleme mund të lindin me punët në sfond.

Sipas komenteve të shumta në internet, situata të tilla janë më të zakonshme kur përdoren çelësat e sigurisë së rrjetit. Nëse situata me "sesionet e ngrirjes" përsëritet sistematikisht, kjo është një arsye për të kontrolluar dhe mirëmbajtur plotësisht sistemin dhe serverët (nëse baza e të dhënave është klient-server).

Gabime gjatë shkrimit të konfigurimit

Të gjitha konfigurimet standarde zhvillohen nga specialistë dhe ekspertë të kualifikuar. Çdo sistem është testuar dhe optimizuar tërësisht për funksionim më të shpejtë dhe më korrekt.

Në këtë drejtim, shkaku i gabimit mund të qëndrojë në kodin jooptimal të shkruar nga një zhvillues i palës së tretë. Kjo mund të jetë një kërkesë "e rëndë" që do të bllokojë të dhënat për një periudhë të gjatë kohore. Janë të shpeshta edhe raste të ndërtimit të algoritmeve me performancë të ulët dhe shkelje të logjikës.

Ekziston një probabilitet i lartë që konflikti i bllokimit të lindi pikërisht për shkak të gabimeve të zhvilluesit nëse ai u ngrit pas një përditësimi të programit. Për të kontrolluar, thjesht mund të "riktheheni" përmirësimet ose të rifaktoni kodin.

Cilat janë bravat në 1C, pse nevojiten dhe si të shmangni problemet kur punoni me to

Me siguri shumë prej jush kur përdorni sistemet e informacionit Ndërmarrja 1C (1C 7.7, 1C 8.1, 1C 8.2, 1C 8.3) u ndesh me një fenomen të tillë si bllokimi. Për më tepër, si rregull, të gjithë e quajnë këtë fenomen ndryshe: "Bllokimi 1C", "Konflikti i bllokimit 1C", "Gabimet e bllokimit 1C", "Bllokimi i transaksionit 1C" dhe emra të tjerë. Le të hedhim një vështrim të shpejtë se çfarë janë bravat (jo bllokimet), pse janë të nevojshme dhe si të shmangni problemet kur punoni me to.

Vetë bravat (përfshirë në 1C dhe sisteme të tjera) janë një mjet i dobishëm që ofron aftësinë për të punuar vazhdimisht me burime të përbashkëta. Për shembull, koncepti i "burimeve të përbashkëta" na rrethon gjatë gjithë jetës, për shembull, ndërsa jeni duke drejtuar një makinë, askush tjetër nuk mund ta drejtojë atë. Prandaj, makina është një burim i përbashkët. Dhe shoferi i dytë pret derisa të mbërrini, për shembull, gruaja/burri juaj. Ju të dy konkurroni për një burim të përbashkët - një makinë. Kush do të futë makinën momenti aktual Ju përcaktoni në nivel konceptual se si duhet të jemi sisteme të automatizuara??? Kjo është arsyeja pse ne dolëm me një mjet duke bllokuar, të cilat ofrojnë organizim për procesin e aksesit në një burim të përbashkët dhe përcaktojnë një radhë. Si rregull, në jetë, si në sistemet e informacionit (1C 7.7, 1C 8.1, 1C 8.2, 1C 8.3), ka shumë burime të përbashkëta, kështu që ka edhe shumë bllokime. Tani e dyta pikë e rëndësishme– Sa kohë do të presë gruaja/burri juaj që të lëshohet makina juaj Është logjike të supozoni se nuk do të zgjasë përgjithmonë? Prandaj, bravave u jepet një kufi i skadimit - i njohur ndryshe si një kohë e skadimit. Kohëzgjatja është koha maksimale që një pjesëmarrës konkurrues (gruaja/burri juaj) pret që burimi i përbashkët të lirohet. Pastaj ose vazhdon të presë për të njëjtën kohë, ose ecën. Në sistemet e informacionit 1C, skadimi i afatit përfundon me mesazhin "Konflikti i bllokimit 1C", "Gabimet e bllokimit 1C", "Bllokimet e transaksionit 1C", "Përfundimi i kohës kur mbyllet".

Një detaj i rëndësishëm që duhet mbajtur mend gjithashtu është se bravat (veçanërisht në 1C) mund të jenë eksplicite (të vendosura nga përdoruesi) dhe të nënkuptuar (të vendosura nga platforma SQL). Në artikull po flasim për bravë eksplicite, kështu që ato përdoren gjithmonë në një transaksion, kështu që rezulton se "Bllokimi 1C" dhe "Bllokimi i transaksioneve 1C" janë sinonime.

Ne kemi vendosur që nëse koha e skadimit tejkalohet, përdoruesi do të marrë një mesazh gabimi për të, vetë procesi i pritjes duket sikur ekrani i sistemit të informacionit 1C është i mbërthyer. Mundësia e shfaqjes së një mesazhi të skadimit (gabim i përdoruesit 1C) ndikohet nga treguesit e mëposhtëm:

• Shumë bllokime 1C në një transaksion;
• Kohëzgjatja e transaksionit.

Për të minimizuar mesazhet që lidhen me gabimet e bllokimit, është e nevojshme ose të zvogëlohet numri i bllokimeve (të optimizohet selektiviteti) ose të zvogëlohet kohëzgjatja e transaksioneve.
Tani le të përcaktojmë se si mund të ndikohen këta tregues në një sistem të vërtetë informacioni 1C.

Për të reduktuar shumë bllokime:

Në 1C: Ndërmarrja 7.7:

Sistemi i informacionit 1C 7.7. Për mbyllje përdoren brava tavoline, të cilat paralizojnë punën e përdoruesve. Si rregull, më shumë se 50 persona në një bazë të dhënash nuk mund të punojnë pa gabime, dhe problemet mund të shfaqen gjithashtu në bazat e të dhënave të 20 përdoruesve.
Zgjidhja:

• Brava fleksibël 1C nga kompania Softpoint. Me ndihmën e tyre, ju jo vetëm që do të optimizoni shumë bravë (duke zëvendësuar bravat e tavolinës me kyçet e përdoruesve), por gjithashtu do të shpejtoni zgjedhjet, kërkimet dhe raportet.

Në 1C: Ndërmarrja 8.x:
Sistemi i informacionit 1C 8.1., 1C 8.2., 1C 8.3. në modalitetin automatik përdor bravë të tepërt të tipit (REPEATABLEREAD, SERIALIZABLE). Kjo rezulton në një përvojë të degraduar të përdoruesit prej 100 ose më shumë.
Zgjidhja:

• Flokët e menaxhuar 1C - një mjet i integruar i platformës 1C për konfigurim më selektiv të bravave. Për ta përdorur atë, programuesi duhet të shkruajë operatorë specialë në vendet e duhura në kod për të bllokuar ato të nevojshme ( sipas mendimit të tij!) regjistrimet në tabelat e sistemit të informacionit;
• Flokë fleksibël 1C - Teknologji Softpoint për zëvendësimin e bravave standarde me ato me porosi.

Për të reduktuar kohën e transaksionit:

Për çdo sistem informacioni 1C (1C 7.7., 1C 8.1, 1C 8.2, 1C 8.3) si për sistemet e tjera të informacionit, përdoren qasje të ngjashme:

Kontrolloni dhe vendosjen e saktë mirëmbajtje rutinore e bazës së të dhënave (mirëmbajtja e skedarëve, indekseve, statistikave, bazave të të dhënave të tabelave të përkohshme, konfigurimi i Windows dhe SQLServer);

Analiza dhe optimizimi i pyetjeve të rënda 1C dhe SQL (akordimi i indeksit, rishkrimi i pyetjeve);

Kontrolli i tepricës së transaksionit. Në shumë raste, operacionet përfshihen në mënyrë të paarsyeshme në një transaksion pa e kuptuar se si kjo do të ndikojë në kohëzgjatjen, dhe bashkë me të edhe në performancën.

1. Nëse dëshironi të merreni në mënyrë të pavarur me problemet e performancës teknike të 1C (1C 7.7, 1C 8.1, 1C 8.2, 1C 8.3) dhe sistemeve të tjera të informacionit , atëherë për ju ekziston një listë unike e artikujve teknikë në Almanakun tonë (Bllokimi dhe bllokimet, ngarkesa e madhe në CPU dhe disqe, mirëmbajtja e bazës së të dhënave dhe akordimi i indeksit janë vetëm një pjesë e vogël e materialeve teknike që do të gjeni atje).
2. Nëse dëshironi të diskutoni çështjet e performancës me ekspertin tonë ose të porosisni një zgjidhje të monitorimit të performancës PerfExpert, më pas lini një kërkesë dhe ne do t'ju kontaktojmë sa më shpejt të jetë e mundur.

Përshëndetje të gjithëve!

Një ditë tjetër në punë hasa një problem kyçjeje, përkatësisht, mesazhi "Ka një konflikt bllokimi gjatë ekzekutimit të një transaksioni Koha maksimale e pritjes për dhënien e një bllokimi është tejkaluar".

Natyrisht, këtu nuk ka asnjë problem bllokimi, vetëm disa seanca vendosën një bllokim dhe "harruan" ta hiqnin atë. Në të njëjtën kohë, problemi kërcënoi me pasoja të rënda - dokumenti Shitjet e mallrave dhe shërbimeve nuk u krye. Rreth 100 persona punojnë në bazën e të dhënave në të njëjtën kohë dhe është e pamundur të kryhet një operacion tipik dhe i shpeshtë!

Kishte dy zgjidhje - rinisni serverin ose kërkoni për një seancë të dështuar. Zgjidhja e parë është e thjeshtë dhe e shpejtë, por, siç ka shkruar tashmë dikush këtu, ju mund të rindizni serverin derisa të pushoheni. Vendosa të marr rrugën e dytë.

Ditën e parë - problemi u shfaq gjatë ditës në fillim u duk se problemi ishte me një përdorues të largët i cili ishte regjistruar në Konfigurator; Dukej sikur ekzekutimi thjesht u ndal në një pikë dhe bllokimi, natyrisht, nuk u hoq. Pas nja dy orësh, arritëm të lëshonim konfiguruesin, por problemi nuk u largua. Ishte jashtëzakonisht e padëshirueshme të vrisnin me forcë konfiguruesin, ndoshta ata po punonin në të. Pas kësaj, Google hyri në lojë. Gjeta një artikull në këtë faqe që thotë se si të gjeni bravë në një DBMS MS SQL, i kontrolluar, nuk kishte bravë në nivelin DBMS. E çuditshme. Më pas pati përpjekje për të ngritur teknologjinë. revistë. Vendoseni atë, çfarë më pas? Në 15 minuta, disa koncerte me trungje! Si t'i lexoni ato, çfarë të kërkoni? E panjohur.

Gjeta një artikull se si të shoh se çfarë është bllokuar duke përdorur SQL Trace. Edhe nëse e gjej, çfarë më pas? Më duhet një seancë!

Afër orës 16:00, kur kuptova se nuk mund të prisja më, bëra një rindezje. Duke shpresuar se kjo nuk do të ndodhte më (dhe kjo ishte hera e parë në gjashtë muaj punë), mora një psherëtimë të lehtësuar, gjithçka funksionoi. Por më kot... Ditën e dytë - e njëjta situatë. Gërmova për një orë e gjysmë, përsëri përpjekje të pakuptueshme për të kërkuar në google etj. Nuk ka rezultate. Rindizni. Në fund të ditës ndodhi përsëri. Epo, mendoj se është mirë, do të kthehem me qetësi në shtëpi dhe do të ulem dhe do të gërmoj më thellë. Unë kthehem në shtëpi, gjithçka është në rregull. Mjerisht.

Në ditën e tretë pashë webinarin, ata folën për një dhe interesante mënyrë efektive duke kërkuar për një problem. M'u kujtua, por problemi nuk u shfaq më. Ka kaluar një javë dhe ja ku është - përsëri bllokime! Fërkoj duart dhe filloj të veproj.

Së pari, konfiguroni ditarin. Po, nuk mundem pa të, por tani di ta lexoj. Ne vendosëm dy ngjarje: e para është TLOCK, e dyta është TTIMEOUT. E para shfaq të gjitha ngjarjet bllokuese, e dyta tregon ngjarje bllokuese që nuk mund të instaloheshin brenda kohës së caktuar. Në fakt, ka shumë të ngjarë që vetëm TTIMEOUT është e mjaftueshme.

Ne kopjojmë skedarin e regjistrit teknik në vendin e caktuar, fluturojmë në program, telefonojmë bllokimin, marrim një mesazh dhe heqim ose riemërtojmë skedarin e regjistrit teknik. Nuk kemi nevojë për shumë informacione për bllokime të tjera!

Shkoni te dosja rphost_PID, gjeni skedarët e tekstit dhe kërkoni fjalën TTIMEOUT. Ne shohim rreshtin:

53:16.789126-0,TTIMEOUT,5,proces=rphost,p:processName=*****,t:clientID=16536,t:applicationName=1CV8,t:ComputerName=ASUSM,t:connectID=17272,SessionID= 2242,Usr=********,WaitConnections=8239

Nga rruga, mund të ketë disa dosje rphost_PID, gjithçka varet nga sa procese të punëtorëve po ekzekutohen në server.

Dhe pastaj gjithçka është e thjeshtë: shikoni në fund të rreshtit - WaitConnections = 8239, ky është numri ynë i LIDHJES. Shkojmë në tastierën e serverit, shkojmë te Connections, gjejmë këtë numër dhe shikojmë numrin e sesionit. Në rastin tim, kishte dy seanca për përdorues - ai i dështuar dhe disa të tjera. Seanca që tregonte revista teknike u rrëzua. Dhe ja dhe ja! Gjithçka funksionoi, gëzimi nuk njeh kufi! Por, siç doli më vonë, seanca nuk ishte e ngrirë :), ata po punonin në të. Prandaj, në të ardhmen, këshillohet të kontaktoni përdoruesin dhe të paralajmëroni.

Sipas mendimit tim, një zgjidhje mjaft standarde për një problem mjaft standard. Nuk dihet pse nuk e hasa, mbase sepse më duhej ta kërkoja nga alarmi, dhe kur përdoruesit nuk e shtypnin, nuk ishte e mundur të kryheshin teste - nuk kishte asnjë gabim.

Kur qindra përdorues punojnë njëkohësisht me programe dhe të dhëna, lindin probleme që janë karakteristike vetëm për zgjidhjet në shkallë të gjerë. Po flasim për probleme të shkaktuara nga bllokimi i të dhënave.

Ndonjëherë përdoruesit mësojnë rreth bllokimit nga mesazhet që tregojnë se nuk mund të shkruajnë të dhëna ose të kryejnë ndonjë operacion tjetër. Ndonjëherë për shkak të një rënie shumë të konsiderueshme të performancës së programit (për shembull, kur koha e nevojshme për të kryer një operacion rritet dhjetëra ose qindra herë).

Problemet e shkaktuara nga bllokimi nuk kanë zgjidhje e përgjithshme. Prandaj, ne do të përpiqemi të analizojmë shkaqet e problemeve të tilla dhe të sistemojmë opsionet për zgjidhjen e tyre.

ARSYET E BLLOKIMIT TË TRANSAKSIONIT

Le të kujtojmë së pari se çfarë janë flokët, dhe në të njëjtën kohë të kuptojmë nëse ato janë të nevojshme. Le të shohim disa shembuj klasikë të bllokimeve që hasim në jetë.

Shembulli 1: blerja e një bilete avioni ose treni. Supozoni se i shprehëm dëshirat tona arkëtarit. Arkëtari na tregon disponueshmërinë e vendeve të disponueshme, nga të cilat ne mund të zgjedhim atë që na pëlqen më shumë (nëse ka disa prej tyre, sigurisht). Ndërsa ne zgjedhim dhe konfirmojmë marrëveshjen tonë me opsionin e propozuar, këto vende nuk mund t'i shiten askujt tjetër, d.m.th. janë “bllokuar” përkohësisht. Nëse ato nuk do të bllokoheshin, atëherë deri në kohën e konfirmimit mund të ketë një situatë ku biletat që kemi zgjedhur tashmë ishin shitur. Dhe në këtë rast, cikli i përzgjedhjes mund të ketë një numër të paparashikueshëm përsëritjesh. Ndërsa ne po zgjedhim vendet, ato tashmë janë shitur!.. Ndërsa ne zgjedhim të tjerët, dhe ata nuk janë më atje...

Shembulli 2: blerja e diçkaje në një dyqan ose në një pazar. Ne iu afruam banakut dhe zgjodhëm mollën më të bukur nga qindra të disponueshme. Ata e zgjodhën dhe futën në xhepat e tyre për paratë. Si do të duket nëse në atë moment, ndërsa po numërojmë paratë, molla që zgjodhëm do t'i shitet një blerësi që doli më vonë se ne?

Kështu, bllokimi në vetvete është një fenomen i domosdoshëm dhe i dobishëm. Falë bllokimit ne garantojmë që veprimet të përfundojnë në një hap. Dhe më shpesh nuk është zbatimi më i suksesshëm që çon në negativitet. software kur, për shembull:

• një numër i tepërt objektesh (bileta, mollë) janë bllokuar;
• Koha e bllokimit zgjatet në mënyrë të paarsyeshme.

BLLOKIM I TEPER NË KONFIGURIMET TIPIKE 1C

Aktiv projekte madhore, si rregull, ne përdorim 1C: Enterprise. Kjo është arsyeja pse rekomandime praktike Ne do të përpiqemi të përshkruajmë zgjidhje për problemet e bllokimit duke përdorur shembullin e kombinimit 1C:Enterprise + MS-SQL.

Gjenerata e 8-të e 1C: Enterprise ofron paralelizëm shumë, shumë të mirë të përdorimit. Mund të punojë njëkohësisht me një konfigurim (d.m.th., në një bazë) me serverë normalë dhe kanale komunikimi sasi e madhe përdoruesit. Për shembull, qindra magazinierë përpunojnë lëshimin ose marrjen e mallrave, ekonomistët llogaritin njëkohësisht kostot e punës për departamente të ndryshme, kontabilistët kryejnë llogaritjet dhe listën e pagave, etj.

Por ka një arsye pse ekziston një mendim për të kundërtën - miti që me përdorim intensiv të njëkohshëm, të punosh me zgjidhje të bazuara në 1C: Enterprise është e pakëndshme ose e pamundur. Në fund të fundit, sapo zgjidhjet standarde për 1C: Enterprise fillojnë të përdoren nga qindra përdorues në shkallë industriale, gjithnjë e më shpesh shfaqet një dritare në ekran me një mbishkrim krenar: "Gabim gjatë thirrjes së metodës së kontekstit (Shkruaj): Konflikti i kyçjes kur ekzekutohet një transaksion: ..." dhe më pas, në varësi të llojit të serverit SQL të përdorur, diçka si “Ofruesi i Microsoft OLE DB për SQL Server: Periudha e skadimit të kërkesës së bllokimit është tejkaluar. ...".

Pothuajse të gjitha zgjidhjet standarde në zbatimin e propozuar jashtë kutisë janë konfiguruar për menaxhimin automatik të bllokimit. "Automatik" këtu mund të perceptohet si "paranojak". Në çdo rast, kur përpunojmë ndonjë dokument, ne bllokojmë gjithçka që mund të jetë disi e lidhur me të. Pra, rezulton se kur një përdorues bën diçka (dhe ndonjëherë thjesht e shkruan atë), pjesa tjetër mund të presë vetëm.

Unë do të shpreh mendimin tim pse 1C vendosi të mos konfigurojë zgjidhjet e tij standarde për përdorim të lartë paralel. Kostot e punës për një modifikim të tillë nuk janë të larta - disa "muaj njeriu", gjë që nuk është e rëndësishme në shkallën 1C. Më duket se arsyeja është e ndryshme.

Së pari, një modifikim i tillë ndërlikon ndjeshëm përpunimin e të gjitha dokumenteve. Kjo do të thotë që për ata konsumatorë që përdorin 1C për detyra të vogla, pa asnjë përfitim do të ketë vetëm një pengesë - vështirësia e modifikimit të konfigurimit standard do të bëhet më e ndërlikuar. Statistikat në të njëjtën kohë sugjerojnë se cila kategori e klientëve është baza kryesore e ushqimit për 1C...

Arsyeja e dytë është varrosur në cilësimet tipike bazë të serverëve SQL, për shembull, MS-SQL, i cili ende përdoret më shpesh se të tjerët. Thjesht ndodh që përparësitë në cilësimet i jepen ruajtjes RAM serverët në vend që të zvogëlojnë bllokimin. Kjo çon në faktin se, nëse është e nevojshme të bllokoni disa rreshta, serveri SQL merr një vendim "të kursimit të kujtesës dhe procesorit" - të bllokojë të gjithë tabelën menjëherë!..

Këto janë mangësitë zgjidhje standarde ose specifikat e konfigurimit të serverit të bazës së të dhënave të përdorura shpesh identifikohen me probleme të shkaktuara nga kyçja. Si rezultat, mangësitë teknike çojnë në shumë të rëndësishme problemet organizative. Në fund të fundit, nëse një punonjësi i jepet një arsye për t'u shpërqendruar nga puna ose për të justifikuar pse puna nuk mund të bëhej, një pakicë do të funksionojë në mënyrë efektive. Epo, një mesazh për bllokimin e transaksioneve ose një program "frenimi" është një justifikim ideal për arsyen pse diçka nuk mund të bëhej.

REKOMANDIME PËR ELINIMIN E BLLOKIMIT TË TEPERTË PËR 1C: INTERPRISE

Çfarë duhet të bëni nëse zgjidhja e problemeve të mbylljes së tepërt është kaq e rëndësishme?

Në fazën përfundimtare të zbatimit të të gjitha komplekse të mëdhaështë e nevojshme të kryhet rregullimi i imët për të eliminuar bllokimin e panevojshëm të transaksioneve. Është thelbësore të zgjidhen problemet që mund të lindin për shkak të kushteve të bllokimit ose teknikave të zbatimit të pamjaftueshëm të zhvilluara.

Sepse Ky operacion është jashtëzakonisht i rëndësishëm dhe duhet të kryhet vazhdimisht. Prandaj, për të thjeshtuar modifikime të tilla, ne kemi zhvilluar një sërë rekomandimesh bazë të cilave ne përpiqemi t'u përmbahemi. Rekomandime të marra dhe të testuara nga përvoja e një numri të konsiderueshëm zbatimesh në shkallë të gjerë.

1. Nëse DBMS ose sistemi i zhvillimit që po përdorni (për shembull, 1C: Enterprise) përdor si parazgjedhje modalitetin automatik të kyçjes së të dhënave, refuzoni menaxhimin automatik të kyçjes. Konfiguro vetë rregullat e bllokimit, përshkruani kriteret për bllokimin e tabelave të tëra ose rreshtave individualë.
2. Kur zhvilloni një program, sa herë që është e mundur, aksesoni tabelat në të njëjtin rend.
3. Mundohuni të mos shkruani në të njëjtën tabelë disa herë brenda të njëjtit transaksion. Nëse kjo është e vështirë, atëherë të paktën minimizoni intervalin kohor midis operacionit të parë dhe të fundit të shkrimit.
4. Analizoni mundësinë e çaktivizimit të përshkallëzimit të bllokimit në nivelin e serverit SQL.
5. Informoni qartë përdoruesit për arsyet pse ata nuk mund të kryejnë asnjë veprim nëse janë për shkak të bllokimit. Jepni rekomandime të arritshme dhe të kuptueshme se çfarë të bëni më pas.

Nëse shikoni me kujdes rekomandimet, bëhet e qartë se një testim i tillë është i përshtatshëm jo vetëm për 1C: Enterprise, por për çdo sistem. Nuk ka fare rëndësi se në cilën gjuhë janë shkruar dhe me cilin server të bazës së të dhënave punojnë. Shumica e rekomandimeve janë universale në natyrë, dhe për këtë arsye janë po aq të vlefshme kur përdorni 1C:Enterprise dhe për programe "të shkruara në shtëpi" ose sisteme të tjera ERP "të kuti".

P.S. A e dini se ne ofrojmë ndihmë profesionale me përditësimin e softuerit 1C? çmimi më i mirë?

Etiketat për të kërkuar:

• Bllokimet e transaksioneve
• Heqja e bllokimeve
• Brava 1C
• Kyç
• Konflikti i bllokimit
• Bllokoni grindjet gjatë transaksionit

Në sistemet me shumë përdorues luan një rol të rëndësishëm organizimin e duhur strukturat dhe vendosja e bravave. Nëse nuk është aty, përdoruesit shpesh do të duhet të merren me gabime të shkaktuara nga konkurrenca për burime të caktuara të sistemit. Por ekziston një problem i konfliktit të bllokimit që është i njohur për shumë përdorues. Pse ndodh një konflikt bllokimi 1C dhe si ta zgjidhim atë?

Konflikti i bllokimit në 1C 8.3 dhe kuptimi i tij

Për shumicën e përdoruesve, një mesazh në lidhje me një konflikt bllokimi 1C nënkupton vetëm një gabim që i pengon ata të kryejnë punën e tyre. Ata duan të heqin qafe këtë problem sa më shpejt të jetë e mundur dhe të rrethojnë departamentin e IT me ankesat se "1C nuk funksionon".

Por për administratorët dhe zhvilluesit e sistemit, një mesazh i tillë tregon se mund të ketë probleme në strukturën e konfigurimit. Para se të përpiqeni të kënaqni përdoruesit dhe të hiqni bllokimet, duhet të analizoni situatën dhe të kuptoni arsyen e mesazhit të gabimit.

Arsyet e bllokimit të gabimeve në 1C

Testimi i ngarkesës demonstrative tregon se serveri 1C mund të përballojë funksionimin paralel të më shumë se pesë mijë përdoruesve. Por kushtet ideale për eksperimente të tilla janë të paarritshme në kushtet e përditshme të kompanive të mëdha dhe të mesme. Për të arritur performancë të ngjashme dhe funksionim pa gabime, konfigurimi duhet të jetë i dizajnuar dhe përshtatur në mënyrë ideale për proceset specifike të biznesit të ndërmarrjes.

Nëse nuk marrim opsione ideale, atëherë konfliktet e kyçjes 1C ndodhin për arsyet e mëposhtme:

Puna e njëkohshme e përdoruesve me një sasi të madhe të dhënash. Ky shkak rrënjësor diktohet nga mekanizmat e brendshëm të 1C. Ato përfshijnë ndalimin e ndryshimeve në të dhënat e përfshira në një transaksion të nisur në emër të një përdoruesi tjetër;

Gabimet dhe lëshimet në konfigurim. Struktura e zgjidhjeve standarde nga kompania 1C merr parasysh rekomandimet për maksimizimin e produktivitetit. Por zhvilluesit e palëve të treta jo gjithmonë i përmbahen standardeve të larta, dhe gabimet e mëposhtme shpesh mund të gjenden në kodin e tyre:

• Pyetje jo optimale;
• Kërkesa për bilanc në fillim të veprimeve;
• Keqkuptimi i qëllimit të objekteve të konfigurimit dhe përdorimi i gabuar i tyre;
• Teprica e ndërthurjeve të integruara në sistem ose të zhvilluara shtesë.

Si të rregulloni një konflikt bllokimi në 1C 8.3

Mesazhi i sistemit "konflikti i bllokimit kur ekzekutohet një transaksion 1C 8.3" nuk e karakterizon konfigurimin si të projektuar gabimisht. Por nëse sinjale të tilla shpërfillen, atëherë ekziston mundësia që në momentin më vendimtar, për shembull, kur kalon një tremujor ose raportimi vjetor futeni në telashe të mëdha. Në rastin më të mirë, një sistem i ngadaltë dhe përdorues të pakënaqur. Në rastin më të keq, të dhënat e daljes janë të pasakta, gjë që mund të çojë në ndëshkime nga autoritetet rregullatore.

Zgjidhja e problemit të konflikteve të bllokimit në 1C 8.3 mund të jetë transferimi i konfigurimit në një mënyrë të menaxhimit të bllokimit të menaxhuar (manual). Zbatuar në versionin 8.1, mekanizmi në duart e specialistëve kompetent zgjidh problemin e konflikteve të bllokimit gjatë një transaksioni në 1C.

Por ia vlen të kihet parasysh se ky veprim do të ulë nivelin e mbrojtjes së të dhënave nga ndryshimet gjatë leximit nga përdoruesit e tjerë. Prandaj, nëse nuk jeni gati të kontrolloni në mënyrë të pavarur të gjitha bravat në sistem, mos nxitoni të ndryshoni cilësimet e konfigurimit.

Zgjidhje e shpejtë për konfliktin e kyçjes 1C

Në punën e një administratori ose zhvilluesi, mund të lindë një situatë kur nuk ka kohë për të kontrolluar një gabim dhe për të kërkuar shkaqet rrënjësore të problemit. Për shembull, është e nevojshme të paraqisni një raport ose të dorëzoni të dhëna brenda një kohe të caktuar, por gabimet e bllokimit 1C e parandalojnë këtë.

Ekzistojnë dy mënyra për të zgjidhur shpejt problemin:

• Gjeni dhe përfundoni seancën që bllokon të dhënat e kërkuara. NË kompanitë e vogla, ku numri i përdoruesve 1C nuk i kalon nja dy duzina njerëz, kjo është zgjidhja optimale;
• Nëse kontrolloni një sistem me qindra punonjës, gjetja e seancës së duhur pa softuer të specializuar mund të marrë shumë kohë. Në këtë rast, do të jetë shumë më efektive rinisja e serverit.

Këto zgjidhje janë radikale dhe synojnë vetëm zgjidhjen e shpejtë të problemit dhe lirimin e të dhënave për raportim urgjent. Mund të çrrënjoset vetëm duke kuptuar arsyen pse lindi një konflikt bllokimi gjatë kryerjes së një transaksioni 1C. Pas veprimeve të tilla, është e nevojshme të gjeni dobësi në sistem, të optimizoni konfigurimin ose punën e punonjësve. Nuk rekomandohet përdorimi i masave të tilla në mënyrë të vazhdueshme në rast të konflikteve të rregullta të bllokimit të transaksioneve.