Ko več sto uporabnikov hkrati dela s programi in podatki, se pojavijo težave, ki so značilne le za obsežne rešitve. Govorimo o težavah, ki nastanejo zaradi blokiranja podatkov.

Včasih uporabniki izvejo za blokado iz sporočil, ki nakazujejo, da ne morejo pisati podatkov ali izvajati kakšne druge operacije. Včasih zaradi zelo velikega padca zmogljivosti programa (na primer, ko se čas, potreben za izvedbo operacije, poveča več deset ali stokrat).

Težave, ki nastanejo zaradi blokade, nimajo splošne rešitve. Zato bomo poskušali analizirati vzroke takšnih težav in sistematizirati možnosti za njihovo rešitev.

RAZLOGI ZA BLOKIRANJE TRANSAKCIJ

Najprej se spomnimo, kaj so ključavnice, in hkrati ugotovimo, ali so potrebne. Poglejmo si nekaj klasičnih primerov blokad, s katerimi se srečujemo v življenju.

Primer 1: nakup letalske ali železniške vozovnice. Recimo, da smo svoje želje izrazili blagajni. Blagajničarka nam sporoči razpoložljivost prostih mest, med katerimi lahko izberemo tistega, ki nam je najbolj všeč (če jih je seveda več). Čeprav izberemo in potrdimo svoje strinjanje s predlagano možnostjo, teh sedežev ni mogoče prodati nikomur drugemu, tj. so začasno "blokirani". Če ne bi bili blokirani, bi do trenutka potrditve lahko prišlo do situacije, ko bi bile vstopnice, ki smo jih izbrali, že prodane. In v tem primeru ima lahko izbirni cikel nepredvidljivo število ponovitev. Dokler izbiramo mesta, so že prodana!.. Medtem ko izbiramo druge, pa jih ni več...

Primer 2: nakup nečesa v trgovini ali na bazarju. Pristopili smo do pulta in izmed stotih razpoložljivih jabolk izbrali najlepše. Izbrali so ga in segli v žep po denar. Kako bo videti, če bo v tistem trenutku, ko preštevamo denar, jabolko, ki smo ga izbrali, prodano kupcu, ki je prišel pozneje kot mi?

Tako je blokada sama po sebi nujen in koristen pojav. Zahvaljujoč blokiranju zagotavljamo, da so dejanja dokončana v enem koraku. In kar največkrat vodi v negativnost, ni najbolj uspešna programska implementacija, ko npr.

• preveliko število predmetov (vstopnice, jabolka) je blokiranih;
• Čas blokade se neutemeljeno podaljšuje.

PRETIRANO BLOKIRANJE V TIPIČNIH KONFIGURACIJAH 1C

Pri velikih projektih praviloma uporabljamo 1C:Enterprise. Zato bomo poskušali opisati praktična priporočila za reševanje težav z blokiranjem na primeru kombinacije 1C:Enterprise + MS-SQL.

8. generacija 1C:Enterprise zagotavlja zelo, zelo dobro vzporednost uporabe. Ogromno število uporabnikov lahko hkrati dela z eno konfiguracijo (torej na eni bazi) z običajnimi strežniki in komunikacijskimi kanali. Na primer, na stotine skladiščnikov obdeluje izdajo ali prejem blaga, ekonomisti hkrati izračunavajo stroške dela za različne oddelke, računovodje izvajajo izračune in obračun plač itd.

Vendar obstaja razlog, zakaj obstaja nasprotno mnenje - mit, da je ob intenzivni hkratni uporabi delo z rešitvami, ki temeljijo na 1C:Enterprise, neprijetno ali nemogoče. Konec koncev, takoj ko standardne rešitve za 1C:Enterprise začnejo uporabljati stotine uporabnikov v industrijskem obsegu, se na zaslonu vse pogosteje pojavi okno s ponosnim napisom: »Napaka pri klicu kontekstne metode (Write) : Konflikt zaklepanja pri izvajanju transakcije: ..." in naprej, odvisno od vrste uporabljenega strežnika SQL, nekaj takega kot "Ponudnik Microsoft OLE DB za SQL Server: preseženo obdobje časovne omejitve zahteve za zaklepanje. ...".

Skoraj vse standardne rešitve v predlagani izvedbi, ki je že pripravljena, so konfigurirane za samodejno upravljanje zaklepanja. "Samodejno" tukaj lahko dojemamo kot "paranoično". Za vsak slučaj pri obdelavi katerega koli dokumenta blokiramo vse, kar je lahko kakor koli povezano z njim. Tako se izkaže, da ko en uporabnik nekaj naredi (in včasih samo zapiše), ostali lahko samo čakajo.

Izrazil bom svoje mnenje, zakaj se je 1C odločil, da svojih standardnih rešitev ne bo konfiguriral za visoko vzporedno uporabo. Stroški dela za takšno modifikacijo niso visoki - nekaj "človeških mesecev", kar na lestvici 1C ni pomembno. Zdi se mi, da je razlog drugje.

Prvič, takšna sprememba bistveno oteži obdelavo vseh dokumentov. To pomeni, da bo za tiste potrošnike, ki uporabljajo 1C za majhne naloge, brez kakršnega koli dobička le slabost - težava pri spreminjanju standardne konfiguracije bo postala bolj zapletena. Statistični podatki hkrati kažejo, katera kategorija strank je glavno korito za 1C ...

Drugi razlog je zakopan v tipičnih osnovnih nastavitvah strežnikov SQL, na primer MS-SQL, ki se še vedno uporablja pogosteje kot drugi. Tako se je zgodilo, da so bile prednostne nastavitve v nastavitvah dane varčevanju z RAM-om strežnika, namesto zmanjšanju blokad. To vodi do dejstva, da če je treba zakleniti več vrstic, strežnik SQL sprejme odločitev o "varčevanju s pomnilnikom in procesorjem" - da zaklene celotno tabelo hkrati!..

Te pomanjkljivosti v standardnih rešitvah ali posebnosti uporabljene nastavitve strežnika baz podatkov se pogosto identificirajo s težavami, ki jih povzroči blokiranje. Posledično tehnične pomanjkljivosti povzročajo zelo velike organizacijske težave. Konec koncev, če zaposleni dobi razlog, da ga odvrnejo od dela ali da upravičijo, zakaj dela ni bilo mogoče opraviti, bo manjšina delala učinkovito. No, sporočilo o blokiranju transakcij ali "zaviranju" programa je idealna utemeljitev, zakaj nekaj ni bilo mogoče narediti.

PRIPOROČILA ZA ODPRAVO PREKOMERNIH BLOKIR ZA 1C: PODJETJE

Kaj storiti, če je reševanje težav s pretiranim zaklepanjem tako pomembno?

V končni fazi izvajanja vseh velikih kompleksov je treba izvesti fino nastavitev, da se odpravi nepotrebno blokiranje transakcij. Ključnega pomena je reševanje težav, ki lahko nastanejo zaradi nezadostno razvitih pogojev blokiranja ali izvedbenih tehnik.

Ker Ta operacija je izjemno pomembna in jo je treba nenehno izvajati. Zato smo za poenostavitev takšnih sprememb razvili številna osnovna priporočila, ki se jih poskušamo držati. Prejeta in preizkušena priporočila z izkušnjami velikega števila obsežnih implementacij.

1. Če DBMS ali razvojni sistem, ki ga uporabljate (na primer 1C:Enterprise), privzeto uporablja način samodejnega zaklepanja podatkov, zavrnite samodejno upravljanje zaklepanja. Sami konfigurirajte pravila za blokiranje, opišite kriterije za blokiranje celih tabel ali posameznih vrstic.
2. Ko razvijate program, kadar koli je to mogoče, dostopajte do tabel v enakem vrstnem redu.
3. Poskusite ne pisati v isto tabelo večkrat znotraj iste transakcije. Če je to težko, potem vsaj zmanjšajte časovni interval med prvim in zadnjim zapisovanjem.
4. Analizirajte možnost onemogočanja stopnjevanja zaklepanja na ravni strežnika SQL.
5. Jasno obvestite uporabnike o razlogih, zakaj ne morejo izvesti nobenih dejanj, če so ta posledica blokade. Dajte dostopna in razumljiva priporočila, kaj storiti naprej.

Če natančno pogledate priporočila, postane jasno, da takšno testiranje ni primerno le za 1C:Enterprise, ampak za vse sisteme. Sploh ni pomembno, v katerem jeziku so napisani in s katerim strežnikom baze podatkov delajo. Večina priporočil je univerzalne narave, zato so enako veljavna pri uporabi 1C:Enterprise in za »domače« programe ali druge »škatlaste« sisteme ERP.

P.S. Ali ste vedeli, da nudimo strokovno pomoč pri posodobitvi 1C po najboljši ceni?

Oznake za iskanje:

• Transakcijske ključavnice
• Odstranjevanje blokad
• 1C ključavnice
• Zaklepanje
• Konflikt ključavnic
• Zakleni spor med transakcijo

Nisem mogel zapisati sprememb za prenos v porazdeljeno bazo podatkov, zato sem stopil v stik s podporo 1C in ponudil naslednje. Rešil sem ga preprosto tako, da sem znova zagnal aplikacijski strežnik in SQL strežnik. Na splošno lahko potrdite polje »Blokiranje regulativnih
vključene naloge"
Pomagalo je tudi brez ponovnega zagona.

Rutinske operacije na ravni DBMS za MS SQL Server

Navodila za izvajanje rutinskih operacij na ravni DBMS.

Informacije veljajo za različico odjemalec-strežnik 1C:Enterprise 8 pri uporabi DBMS MS SQL Server.

Splošne informacije

Eden najpogostejših razlogov za neoptimalno delovanje sistema je nepravilno ali nepravočasno izvajanje rutinskih operacij na ravni DBMS. Še posebej pomembno je, da se ti regulatorni postopki izvajajo v velikih informacijskih sistemih, ki delujejo pod velikimi obremenitvami in služijo velikemu številu uporabnikov hkrati. Posebnost takšnih sistemov je, da običajna dejanja, ki jih DBMS izvede samodejno (na podlagi nastavitev), ne zadostujejo za učinkovito delovanje.

Če v delujočem sistemu opazite kakršne koli simptome težav z zmogljivostjo, morate preveriti, ali je sistem pravilno konfiguriran in redno izvaja vse priporočene rutinske operacije na ravni DBMS.

Izvajanje regulativnih postopkov bi moralo biti avtomatizirano. Za avtomatizacijo teh operacij je priporočljivo uporabiti vgrajeno orodje MS SQL Server: Maintenance Plan. Obstajajo tudi drugi načini za avtomatizacijo teh postopkov. V tem članku je za vsak regulativni postopek podan primer njegove konfiguracije z uporabo načrta vzdrževanja za MS SQL Server 2005.

Priporočljivo je redno spremljanje pravočasnosti in pravilnosti teh regulativnih postopkov.

Posodobite statistiko

MS SQL Server gradi načrt poizvedbe na podlagi statističnih informacij o porazdelitvi vrednosti v indeksih in tabelah. Statistične informacije se zbirajo na podlagi dela (vzorca) podatkov in se samodejno ažurirajo, ko se ti podatki spremenijo. Včasih to ni dovolj, da bi MS SQL Server dosledno zgradil najbolj optimalen načrt za izvajanje vseh poizvedb.

V tem primeru lahko pride do težav z zmogljivostjo poizvedbe. Hkrati se na poizvedovalnih načrtih kažejo značilni znaki neoptimalnega delovanja (neoptimalne operacije).

Da bi zagotovili čim bolj pravilno delovanje optimizatorja MS SQL Server, je priporočljivo redno posodabljati statistiko baze podatkov MS SQL.

Če želite posodobiti statistiko za vse tabele baze podatkov, morate zagnati naslednjo poizvedbo SQL:

exec sp_msforeachtable N"POSODOBITEV STATISTIKE? S FULLSCAN"

Posodabljanje statistike ne vodi do zaklepanja tabele in ne bo motilo dela drugih uporabnikov. Statistiko je mogoče posodobiti tako pogosto, kot je potrebno. Upoštevati je treba, da se bo med posodabljanjem statistik povečala obremenitev strežnika DBMS, kar lahko negativno vpliva na splošno delovanje sistema.

Optimalna pogostost posodabljanja statistike je odvisna od velikosti in narave obremenitve sistema in se določi eksperimentalno. Priporočljivo je posodobiti statistiko vsaj enkrat na dan.

Zgornja poizvedba posodobi statistiko za vse tabele v bazi podatkov. V resničnem sistemu različne tabele zahtevajo različne stopnje posodabljanja statističnih podatkov. Z analizo načrtov poizvedb lahko ugotovite, katere tabele najbolj potrebujejo pogoste posodobitve statističnih podatkov, in nastavite dva (ali več) različna rutinska postopka: za pogosto posodobljene tabele in za vse druge tabele. Ta pristop bo znatno skrajšal čas posodabljanja statistike in vpliv procesa posodabljanja statistike na delovanje sistema kot celote.

Nastavitev samodejnih posodobitev statistike (MS SQL 2005)

Zaženite MS SQL Server Management Studio in se povežite s strežnikom DBMS. Odprite mapo Management in ustvarite nov načrt vzdrževanja:

Ustvarite podnačrt (Dodaj podnačrt) in ga poimenujte »Posodobitev statistike«. V opravilno vrstico mu dodajte nalogo Posodobi statistiko:

Nastavite razpored posodabljanja statistike. Statistiko je priporočljivo posodobiti vsaj enkrat na dan. Po potrebi se lahko poveča pogostost posodabljanja statistike.

Konfigurirajte nastavitve opravila. Če želite to narediti, dvokliknite nalogo v spodnjem desnem kotu okna. V obrazcu, ki se prikaže, določite ime baze (ali več baz), za katero se bodo statistike ažurirale. Poleg tega lahko določite, za katere tabele naj se statistika posodobi (če ne veste točno, katere tabele morate določiti, nastavite vrednost na Vse).

Statistika mora biti posodobljena z omogočeno možnostjo Full Scan.

Shranite izdelan načrt. Ko pride čas, naveden v urniku, se samodejno začne posodabljanje statistike.

Čiščenje proceduralnega predpomnilnika

Optimizator MS SQL Server predpomni načrte poizvedb za ponovno izvedbo. To naredimo zato, da prihranimo čas, porabljen za sestavljanje poizvedbe, če je bila ista poizvedba že izvedena in je njen načrt znan.

Možno je, da bo MS SQL Server na podlagi zastarelih statističnih podatkov zgradil neoptimalen načrt poizvedbe. Ta načrt bo shranjen v proceduralnem predpomnilniku in uporabljen pri ponovnem klicu iste poizvedbe. Če posodobite statistiko, vendar ne počistite predpomnilnika postopkov, lahko SQL Server iz predpomnilnika izbere stari (neoptimalen) načrt poizvedbe, namesto da bi zgradil nov (bolj optimalen) načrt.

Če želite počistiti proceduralni predpomnilnik strežnika MS SQL, morate zagnati naslednjo poizvedbo SQL:

To poizvedbo je treba zagnati takoj po posodobitvi statistike. Zato mora pogostost njegovega izvajanja sovpadati s pogostostjo posodobitev statistike.

Nastavitev postopkovnega čiščenja predpomnilnika (MS SQL 2005)

Ker je treba proceduralni predpomnilnik počistiti vsakič, ko se statistika posodobi, je priporočljivo, da to operacijo dodate že ustvarjenemu podnačrtu “Posodobitev statistike”. To naredite tako, da odprete podnačrt in v njegovo shemo dodate nalogo Execute T-SQL Statement Task. Nato morate nalogo Posodobi statistiko s puščico povezati z novo nalogo.

V besedilu ustvarjene naloge Execute T-SQL Statement morate podati zahtevo »DBCC FREEPROCCACHE«:

Defragmentacija indeksov

Pri intenzivnem delu s tabelami baze podatkov se pojavi učinek fragmentacije indeksa, kar lahko privede do zmanjšane zmogljivosti poizvedbe.

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

Defragmentiranje indeksov ne zaklene tabel in ne bo motilo dela drugih uporabnikov, povzroča pa dodatno obremenitev SQL Serverja. Optimalno pogostost izvajanja tega rutinskega postopka je treba izbrati v skladu z obremenitvijo sistema in učinkom defragmentacije. Priporočljivo je, da defragmentirate indekse vsaj enkrat na teden.

Namesto vseh tabel v bazi podatkov lahko defragmentirate eno ali več tabel.

Nastavitev defragmentacije indeksa (MS SQL 2005)

V predhodno ustvarjenem vzdrževalnem načrtu ustvarite nov podnačrt z imenom "Reindexing". Dodajte mu opravilo Rebuild Index Task:

Nastavite urnik izvajanja za nalogo defragmentacije indeksa. Nalogo je priporočljivo izvajati vsaj enkrat tedensko, če so podatki v bazi zelo spremenljivi, pa še pogosteje – do enkrat dnevno.

Ponovno indeksiranje tabel baze podatkov

Ponovno indeksiranje tabel vključuje popolno ponovno izgradnjo indeksov tabel baze podatkov, kar vodi do znatne optimizacije njihovega delovanja. Priporočljivo je, da redno ponovno indeksirate tabele svoje zbirke podatkov. Če želite ponovno indeksirati vse tabele zbirke podatkov, morate zagnati naslednjo poizvedbo SQL:

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

Ponovno indeksiranje tabel jih zaklene za ves čas njihovega delovanja, kar lahko bistveno vpliva na uporabniško izkušnjo. V zvezi s tem je priporočljivo izvesti ponovno indeksiranje med minimalno obremenitvijo sistema.

Ko je ponovno indeksiranje končano, indeksov ni treba defragmentirati.

Nastavitev ponovnega indeksiranja tabele (MS SQL 2005)

V predhodno ustvarjenem načrtu vzdrževanja ustvarite nov podnačrt z imenom Defragmentacija indeksa. Dodajte mu nalogo Rebuild Index:

Nastavite urnik izvajanja za nalogo ponovnega indeksiranja tabele. Priporočljivo je, da nalogo izvajate med minimalno obremenitvijo sistema, vsaj enkrat na teden.

Nalogo nastavite tako, da določite bazo podatkov (ali več baz podatkov) in izberete zahtevane tabele. Če ne veste točno, katere tabele je treba določiti, nastavite vrednost na Vse.

Pozdravljeni vsi skupaj!

Prejšnji dan sem v službi naletel na težavo z zaklepanjem, in sicer na sporočilo "Med izvajanjem transakcije je prišlo do konflikta zaklepanja. Največji čakalni čas za odobritev zaklepanja je bil presežen."

Očitno tukaj ni problema z zastojem, le neka seja je zaklenila in jo »pozabila« odstraniti. Hkrati je problem grozil z resnimi posledicami - dokument Prodaja blaga in storitev ni bil izveden. V bazi podatkov dela približno 100 ljudi naenkrat in nemogoče je izvesti tipično in pogosto operacijo!

Rešitvi sta bili dve - ponovni zagon strežnika ali iskanje neuspele seje. Prva rešitev je enostavna in hitra, vendar, kot je že nekdo tukaj napisal, lahko strežnik ponovno zaganjaš, dokler te ne odpustijo. Odločil sem se za drugo pot.

Prvi dan - težava se je pojavila čez dan, sprva se je zdelo, da je težava pri oddaljenem uporabniku, ki se je prijavil v konfigurator. Videti je bilo, kot da se je izvedba preprosto ustavila na točki, blokada pa seveda ni bila odpravljena. Po nekaj urah nam je uspelo sprostiti konfigurator, a težava ni izginila. Zelo nezaželeno je bilo na silo ubiti konfigurator, morda so delali v njem. Po tem je v igro prišel Google. Na tem spletnem mestu sem našel članek, ki pravi, kako najti ključavnice v DBMS MS SQL, preverjeno, na ravni DBMS ni bilo nobenih ključavnic. Čudno. Sledili so poskusi vzpostavitve tehn. revija. Nastavite, kaj potem? V 15 minutah par gigov polen! Kako jih brati, na kaj iskati? Neznano.

Našel sem članek o tem, kako videti, kaj je blokirano s SQL Trace. Tudi če ga najdem, kaj potem? Potrebujem sejo!

Bližje do 16:00, ko sem ugotovil, da ne morem več čakati, sem znova zagnal. V upanju, da se to ne bo ponovilo (in to je bilo prvič v šestih mesecih dela), sem si oddahnila, vse je delovalo. A zaman... Drugi dan - ista situacija. Kopal sem uro in pol, spet nerazumljivi poskusi googlanja in tako naprej. Brez rezultatov. Znova zaženite. Na koncu dneva se je ponovilo. No, mislim, da je super, bom mirno prišel domov in se usedel in kopal. Pridem domov, vse je v redu. Žalostno.

Tretji dan sem si ogledal webinar, govorili so o zanimivem in učinkovitem načinu iskanja težave. Spomnil sem se, vendar se problem ni več pojavil. Teden dni je minil in tukaj je - spet zapore! Pomejem si roke in začnem delovati.

Najprej nastavite dnevnik. Ja, ne morem brez tega, zdaj pa znam brati. Nastavimo dva dogodka: prvi je TLOCK, drugi je TTIMEOUT. Prvi prikazuje vse blokirane dogodke, drugi prikazuje blokirane dogodke, ki jih ni bilo mogoče namestiti v dodeljenem času. Pravzaprav najverjetneje zadostuje samo TTIMEOUT.

Datoteko tehničnega dnevnika kopiramo na določeno mesto, odletimo v program, pokličemo blokado, prejmemo sporočilo in odstranimo ali preimenujemo datoteko tehničnega dnevnika. Ne potrebujemo kopice informacij o drugih blokadah!

Pojdite v mapo rphost_PID, poiščite besedilne datoteke in poiščite besedo TTIMEOUT. Vidimo vrstico:

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=********,Počakaj na povezave=8239

Mimogrede, map rphost_PID je lahko več, vse je odvisno od tega, koliko delovnih procesov se izvaja na strežniku.

In potem je vse preprosto: poglejte na konec vrstice - WaitConnections = 8239, to je naša številka CONNECTION. Gremo na strežniško konzolo, gremo na Connections, poiščemo to številko in pogledamo številko seje. V mojem primeru sta bili dve seji na uporabnika - neuspela in še ena. Seja, na katero je kazal tehnični dnevnik, je padla. In glej ga zlomka! Vse je delovalo, veselje ne pozna meja! Toda, kot se je kasneje izkazalo, seja ni bila zamrznjena :), delali so v njej. Zato je v prihodnje priporočljivo kontaktirati uporabnika in ga opozoriti.

Po mojem mnenju dokaj standardna rešitev dokaj standardnega problema. Ni znano, zakaj nisem naletel nanj, morda zato, ker sem ga moral iskati zaradi alarma, in ko ga uporabniki niso pritisnili, ni bilo mogoče izvesti testov - napake ni bilo.

V večuporabniških sistemih ima pomembno vlogo pravilna organizacija strukture in nastavitev ključavnic. Če ga ni, se bodo morali uporabniki pogosto ukvarjati z napakami, ki jih povzroča konkurenca za določene sistemske vire. Obstaja pa težava s konfliktom zaklepanja, ki je znana mnogim uporabnikom. Zakaj pride do konflikta zaklepanja 1C in kako ga rešiti?

Konflikt ključavnice v 1C 8.3 in njegov pomen

Za večino uporabnikov sporočilo o konfliktu zaklepanja 1C pomeni le napako, ki jim preprečuje opravljanje dela. Te težave se želijo čim prej znebiti in oblegajo IT oddelek s pritožbami, da "1C ne deluje."

Toda za sistemske skrbnike in razvijalce takšno sporočilo pomeni, da lahko pride do težav v konfiguracijski strukturi. Preden poskušate zadovoljiti uporabnike in odstraniti blokade, morate analizirati situacijo in razumeti razlog za sporočilo o napaki.

Razlogi za blokiranje napak v 1C

Demonstrativno testiranje obremenitve dokazuje, da lahko strežnik 1C prenese vzporedno delovanje več kot pet tisoč uporabnikov. Toda idealni pogoji za takšne eksperimente so v vsakdanjih razmerah velikih in srednje velikih podjetij nedosegljivi. Da bi dosegli podobno zmogljivost in delovanje brez napak, mora biti konfiguracija idealno zasnovana in prilagojena specifičnim poslovnim procesom podjetja.

Če ne vzamemo idealnih možnosti, pride do konfliktov pri zaklepanju 1C iz naslednjih razlogov:

Sočasno delo uporabnikov z veliko količino podatkov. Ta temeljni vzrok narekujejo notranji mehanizmi 1C. Vključujejo prepoved spreminjanja podatkov, vključenih v transakcijo, sproženo v imenu drugega uporabnika;

Napake in opustitve v konfiguraciji. Struktura standardnih rešitev podjetja 1C upošteva priporočila za povečanje produktivnosti. Toda zunanji razvijalci se ne držijo vedno visokih standardov in v njihovi kodi je pogosto mogoče najti naslednje pomanjkljivosti:

• Neoptimalne poizvedbe;
• Zahteva za stanja na začetku dejanj;
• Nerazumevanje namena konfiguracijskih objektov in njihova nepravilna uporaba;
• Redundanca zapor, vgrajenih v sistem ali dodatno razvitih.

Kako odpraviti konflikt zaklepanja v 1C 8.3

Sistemsko sporočilo "konflikt zaklepanja pri izvajanju transakcije 1C 8.3" ne označuje konfiguracije kot nepravilno zasnovane. Če pa se takšni signali ignorirajo, potem obstaja možnost, da se v najbolj ključnem trenutku znajdemo v velikih težavah, na primer pri oddaji četrtletnih ali letnih poročil. V najboljšem primeru počasen sistem in nezadovoljni uporabniki. V najslabšem primeru so izhodni podatki napačni, kar lahko privede do kazni regulativnih organov.

Rešitev problema konflikta zaklepanja v 1C 8.3 je lahko prenos konfiguracije v upravljani (ročni) način upravljanja zaklepanja. Izveden v različici 8.1, mehanizem v rokah pristojnih strokovnjakov rešuje problem konfliktov zaklepanja med transakcijo v 1C.

Vendar je vredno upoštevati, da bo to dejanje zmanjšalo raven zaščite podatkov pred spremembami, medtem ko jih berejo drugi uporabniki. Če torej niste pripravljeni samostojno nadzorovati vseh ključavnic v sistemu, ne hitite s spreminjanjem konfiguracijskih nastavitev.

Hitra rešitev spora pri zaklepanju 1C

Pri delu skrbnika ali razvijalca lahko pride do situacije, ko ni časa za preverjanje napake in iskanje temeljnih vzrokov težave. Na primer, do določenega časa je treba oddati poročilo ali oddati podatke, vendar napake pri blokiranju 1C to preprečujejo.

Težavo lahko hitro rešite na dva načina:

• Poiščite in končajte sejo, ki blokira zahtevane podatke. V majhnih podjetjih, kjer število uporabnikov 1C ne presega nekaj deset ljudi, je to optimalna rešitev;
• Če nadzirate sistem s stotinami zaposlenih, lahko iskanje prave seje brez posebne programske opreme traja dolgo časa. V tem primeru bo veliko bolj učinkovito znova zagnati strežnik.

Te rešitve so radikalne in so namenjene le hitri rešitvi problema in sprostitvi podatkov za nujno poročanje. Izkoreniniti ga je mogoče le z razumevanjem razloga, zakaj je prišlo do konflikta pri zaklepanju pri izvajanju transakcije 1C. Po takih dejanjih je treba najti ranljivosti v sistemu, optimizirati konfiguracijo ali delo zaposlenih. Takšnih ukrepov ni priporočljivo stalno uporabljati v primeru rednih konfliktov pri zaklepanju transakcij.