Többfelhasználós rendszereken fontos szerep játszik megfelelő szervezés szerkezetek és beállítási zárak. Ha nem, akkor a felhasználók gyakran találkoznak hibákkal, amelyeket bizonyos rendszererőforrásokért folytatott verseny okoz. De van egy zárkonfliktus probléma, amelyet sok felhasználó ismer. Miért fordul elő 1C zárkonfliktus, és hogyan lehet kijavítani?
Ütközés zárolása az 1C 8.3-ban és annak jelentésében
A legtöbb felhasználó számára az 1C zárkonfliktus üzenet csak olyan hibát jelent, amely megakadályozza, hogy elvégezzék a munkájukat. Ettől a problémától szeretnének minél hamarabb megszabadulni, és olyan panaszokkal ostromolni az informatikai részleget, hogy "az 1C nem működik".
De érte rendszergazdákés a fejlesztők számára, egy ilyen üzenet a konfigurációs struktúra lehetséges problémáját jelzi. Mielőtt megpróbálna tetszeni a felhasználóknak és eltávolítani a blokkokat, elemeznie kell a helyzetet, és meg kell értenie a hibaüzenet okát.
A blokkolási hibák okai az 1C-ben
Demonstratív terhelési tesztek bizonyítják, hogy az 1C szerver több mint ötezer felhasználó párhuzamos működését is kibírja. Ám az ilyen kísérletek ideális feltételei a nagy- és középvállalatok mindennapi körülményei között elérhetetlenek. A hasonló teljesítmény és hibamentes teljesítmény elérése érdekében a konfigurációt ideálisan kell megtervezni és a vállalat konkrét üzleti folyamataihoz igazítani.
Ha nem választja az ideális lehetőségeket, akkor az 1C zárkonfliktusok a következő okok miatt fordulnak elő:
A felhasználók egyidejű munkája nagy mennyiségű adattal. Ezt a kiváltó okot az 1C belső mechanizmusai diktálják. Ezek magukban foglalják a másik felhasználó nevében indított tranzakcióban szereplő adatok megváltoztatásának tilalmát;
Hibák és hiányosságok a konfigurációban. Az "1C" cég szabványos megoldásainak szerkezete figyelembe veszi a termelékenység maximalizálására vonatkozó ajánlásokat. A harmadik féltől származó fejlesztők azonban nem mindig tartják be a magas szabványokat, és gyakran a következő hiányosságokat találhatja kódjukban:
- Szuboptimális kérések;
- Egyenlegek kérése az akciók kezdetén;
- A konfigurációs objektumok céljának félreértése és helytelen használata;
- A rendszerben rejlő redundancia vagy a kiegészítő fejlesztésű zárak.
A zárolási ütközés kijavítása az 1C 8.3-ban
A "zárkonfliktus az 1C 8.3 tranzakció végrehajtása során" rendszerüzenet nem minősíti a konfigurációt hibásan megtervezettnek. De ha figyelmen kívül hagyják az ilyen jelzéseket, akkor fennáll annak a lehetősége, hogy a legdöntő pillanatban, például a negyedéves vagy éves jelentések benyújtásakor, nagy problémákkal kell szembenéznie. Legjobb esetben lassuló rendszer és elégedetlen felhasználók. A legrosszabb esetben a hibás kimeneti adatok, ami a szabályozó hatóságok szankcióit vonhatja maga után.
Az 1C 8.3-ban a zárak ütközésének problémájának megoldása lehet a konfiguráció átvitele felügyelt (kézi) zárkezelési módba. A 8.1-es verzióban megvalósított mechanizmus az illetékes szakemberek kezében megoldja a zárkonfliktusok problémáját az 1C tranzakciók során.
De szem előtt kell tartani, hogy ez a művelet csökkenti az adatok védelmének szintjét a más felhasználók általi olvasási folyamatban bekövetkezett változásokkal szemben. Ezért, ha nem áll készen a rendszer összes zárának önálló vezérlésére, ne rohanjon a konfigurációs beállítások megváltoztatásával.
Az 1C zárkonfliktus gyors feloldása
Adminisztrátor vagy fejlesztő munkájában előfordulhat olyan helyzet, amikor nincs idő a hiba ellenőrzésére és a probléma kiváltó okainak felkutatására. Például egy jelentést vagy adatokat kell benyújtania egy bizonyos időpontig, és az 1C blokkoló hibák ezt megakadályozzák.
A probléma gyors megoldásának két módja van:
- Keresse meg és fejezze be azt a munkamenetet, amely zárolta a szükséges adatokat. BAN BEN kis cégek, ahol az 1C felhasználók száma nem haladja meg a pár tucat főt, ez a legjobb megoldás;
- Ha olyan rendszert irányít, amely több száz alkalmazottat tartalmaz, megtalálja a megfelelő munkamenetet speciális szakember nélkül szoftver sokáig elhúzódhat. Ebben az esetben sokkal hatékonyabb lesz a szerver újraindítása.
Ezek a megoldások radikálisak, és csak a probléma gyors megoldására, valamint a sürgős bejelentéshez szükséges adatok kiadására irányulnak. Kiküszöbölése csak akkor lehetséges, ha megértjük, hogy az 1C tranzakció végrehajtása során milyen ok miatt keletkezett zárkonfliktus. Az ilyen műveletek után meg kell találni a rendszer sebezhetőségeit, optimalizálni kell az alkalmazottak konfigurációját vagy munkáját. Nem javasolt az ilyen intézkedések tartós alkalmazása a tranzakciók zárolásának rendszeres ütközése esetén.
Sziasztok!
A napokban a munkahelyemen zárolási problémába ütköztem, nevezetesen a "Tranzakció végrehajtása közben zárolási ütközés. Túllépte a zárolás maximális időtúllépése" üzenet kezdett megjelenni.
Itt nyilván nincs holtponti probléma, csak arról van szó, hogy valamelyik session zárolást tett és "elfelejtette" eltávolítani. Ugyanakkor a probléma súlyos következményekkel fenyegetett - az áruk és szolgáltatások értékesítése dokumentumot nem hajtották végre. Egyszerre körülbelül 100 ember dolgozik az adatbázisban, és nem lehet tipikus és gyakori műveletet végrehajtani!
Két megoldás volt – a szerver újraindítása vagy a sikertelen munkamenet keresése. Az első megoldás egyszerű és gyors, de ahogy itt már írta valaki, addig újraindíthatod a szervert, amíg ki nem rúgsz. Úgy döntött, hogy a második utat választja.
Az első nap - a probléma délután jelentkezett, először úgy tűnt, hogy a probléma a távoli felhasználóban van, aki elakadt a konfigurátorban. Úgy tűnt, a végrehajtás egy ponton leállt, és a zárat természetesen nem oldották fel. Pár óra múlva sikerült kiadni a konfigurátort, de a probléma nem szűnt meg. Rendkívül nemkívánatos volt erőszakkal megölni a konfigurátort, talán dolgoztak benne. Ezt követően a Google vette át az irányítást. Találtam egy cikket ezen az oldalon, ami azt írja, hogyan lehet zárakat találni az MS SQL DBMS-ben, ellenőrizve, nem voltak zárolások DBMS szinten. Furcsa. További kísérletek történtek ezek kiigazítására. magazin. Beállítás, mi a következő lépés? 15 perc alatt pár giga rönk! Hogyan kell őket olvasni, mire kell figyelni? Ismeretlen.
Találtam egy cikket arról, hogyan lehet megnézni, mi van blokkolva az SQL Trace-en keresztül. Még ha megtalálom is, akkor mi van? Kell egy foglalkozás!
16:00 felé, amikor rájöttem, hogy nem tudom tovább húzni, újraindítottam. Abban a reményben, hogy ez többé nem fordul elő (és ez volt az első eset a hat hónapos munka során), fellélegeztem, minden működött. De hiába ... A második nap - ugyanaz a helyzet. Másfél órát ástam, megint érthetetlen próbálkozások guglizni stb. Nincs eredmény. Indítsa újra. A nap végén megismétlődött. Nos, szerintem nagyon jó, nyugodtan hazajövök, leülök, mélyebbre ásva. Hazajöttem, minden rendben. Szomorúan.
A harmadik napon megnéztem egy webináriumot, beszélgettem egy érdekes ill hatékony módszer keressen egy problémát. Emlékeztek, de a probléma többé nem merült fel. Eltelt egy hét, és itt van - ismét blokkolás! Megdörzsölöm a kezem, és cselekedni kezdek.
Az első a napló beállítása. Igen, nem bírom nélküle, de most már el tudom olvasni. Két eseményt állítunk be: az első a TLOCK, a második a TTIMEOUT. Az első az összes blokkoló eseményt jeleníti meg, a második pedig azokat a blokkolásokat, amelyeket a megadott időn belül nem sikerült megállapítani. Valójában nagy valószínűséggel csak a TTIMEOUT elég.
A műszaki naplófájlt a kijelölt helyre másoljuk, a programhoz repülünk, felhívjuk a zárat, üzenetet kapunk és eltávolítjuk vagy átnevezzük a műszaki naplófájlt. Nincs szükségünk rengeteg információra más blokkolásokról!
Lépjen az rphost_PID mappába, keressen szöveges fájlokat, és keresse meg a TTIMEOUT szót. Látjuk a sort:
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=8239Egyébként több rphost_PID mappa is lehet, minden attól függ, hogy hány worker process fut a szerveren.
És akkor minden egyszerű: nézd meg a sor végét - WaitConnections = 8239, ez a CONNECTION számunk. A szerverkonzolra lépünk, a Kapcsolatok menüpontra, megkeressük ezt a számot, és megnézzük a munkamenet számát. Az én esetemben felhasználónként két munkamenet volt – egy sikertelen és egy másik. A műszaki napló által jelzett munkamenet összeomlott. És a csodáról! Minden működött, az örömnek nincs határa! De mint utóbb kiderült, a foglalkozást nem akasztották le :), dolgoztak benne. Ezért a jövőre nézve tanácsos felvenni a kapcsolatot a felhasználóval és figyelmeztetni.
szerintem elég átlagos megoldás elég egy gyakori probléma. Nem tudni, miért nem találkoztam vele, talán amiatt, hogy riasztáskor kellett keresnem, és amikor a felhasználók nem nyomták meg, akkor nem lehetett teszteket végezni - nem volt hiba.
„Zárolási ütközés a tranzakció végrehajtása során: A zárolás maximális időtúllépése túllépte” egy meglehetősen gyakori hiba az 1C 8.3-ban és 8.2-ben, amely a rendszerben lévő erőforrások használatáért folytatott versengéshez kapcsolódik.
Az 1C rendszer lehetővé teszi nagyszámú felhasználó párhuzamos munkáját: ahogy a terhelési tesztek mutatják, ez a szám ma már nem korlátozódik ötezer felhasználóra, aki egyszerre dolgozik a rendszerben. Annak érdekében azonban, hogy az 1C 8 adatbázis egyidejűleg támogassa Nagy mennyiségű felhasználókról, a konfigurációt megfelelően kell megtervezni.
Ingyenes 267 1C videóleckéket kaphat:
Nagyszámú művelet végrehajtása
Valószínű, hogy néhány felhasználó például hosszú ideig kezdett el egyetlen tranzakció során. Az 1C 8.3 architektúra feltételezi, hogy a rendszer nem teszi lehetővé az egyik tranzakcióban egy másik felhasználó által használt adatok megváltoztatását, és blokkolja azokat.
Talán ez egy átmeneti hiba, amely megszűnik, amikor egy másik felhasználó műveleteket hajt végre a rendszeren. Ha ez a hiba gyakran megjelenik, akkor valószínűleg valami másról van szó.
Konfigurációs hiba
A kódhibák mellett gyakran vannak módszertanilag hibás megoldások is. Például - ez magában foglalja a dokumentumok egymás utáni tárolását. A kötegelt könyvelést a RAUS helyettesítheti – így komolyan megnöveli a rendszer teljesítményét.
Hogyan javítható ez a hiba az 1C 8.3-ban?
Mindenesetre a „Konfliktus zárolása tranzakció végrehajtása közben” hiba megjelenése azt jelzi, hogy ellenőrizni kell a rendszert, különösen közepes és nagy méreteknél. információs rendszerek kliens-szerver módban (MS SQL, PostgreSQL stb.). Ha ezt a korai szakaszban figyelmen kívül hagyják, annak visszafordíthatatlan következményei lehetnek később, amikor a rendszer működése különösen fontos (a jelentési időszakban).
Az auditáláshoz és a hibajavításhoz a legjobb megbízható partnert választani. Csak hívjon minket, és minden problémáját megoldjuk a lehető leghamarabb. Részletek az oldalon.
Nem ritkán, amikor az 1C-ben dolgozik, megjelenik a „Zárolási ütközés a tranzakciók végrehajtása során: túllépte a zárolás megadásának maximális várakozási idejét” hibaüzenet. Lényege abban rejlik, hogy több munkamenet egyidejűleg próbál meg hasonló műveleteket végrehajtani, ugyanazt az erőforrást érintve. Ma kitaláljuk, hogyan lehet ezt a hibát kijavítani.
A műveletek nagy száma
Az okok keresésekor először is tisztázni kell, hogy hány egyidejűleg dolgozó felhasználó van abban az információs bázisban, amelyben ilyen hiba keletkezik. Mint tudjuk, maximális számuk meglehetősen nagy lehet. Ezer és ötezer.
A zárolások és tranzakciók mechanizmusát a fejlesztői útmutató ismerteti. Akkor használatosak, ha több munkamenet egyszerre éri el ugyanazt az adatot. Logikus, hogy ugyanazt az adatot nem változtathatják meg különböző felhasználók ugyanabban a pillanatban.
Azt is ellenőriznie kell, hogy valamelyik felhasználó elkezdte-e a tömeges adatmódosítás feldolgozását. Ez lehet például , hónapzárás és hasonlók. Ebben az esetben a feldolgozás befejezése után a hiba magától megszűnik.
Ütemezett feladatok
Nem ritka, hogy a hiba oka abban rejlik, amely nagy mennyiségű adatot dolgoz fel. Javasoljuk, hogy ilyen dolgokat éjszaka végezzen. Ütemezze az ilyen ütemezett feladatok végrehajtását munkaidőn kívül.
Így mindkét felhasználó stabil rendszerben fog dolgozni, és maguk az ütemezett feladatok is sikeresen befejeződnek, mivel csökken a felhasználói munkamenetekkel való ütközések valószínűsége.
"Elakadt munkamenetek"
A felhasználók „függesztett munkameneteinek” problémája szinte mindenki számára ismert, aki találkozott az 1C szolgáltatással. A felhasználó már régen kiléphetett volna a programból, vagy bezárhatott volna egy dokumentumot, de a munkamenete továbbra is a rendszerben marad. A probléma leggyakrabban egyetlen, és elegendő egy ilyen munkamenetet a rendszergazdai konzolon keresztül befejezni. Ugyanezek a problémák léphetnek fel a háttérmunkáknál is.
Számos internetes megjegyzés szerint az ilyen helyzetek gyakrabban fordulnak elő hálózati biztonsági kulcsok használatakor. Ha a "lógott munkamenetek" szisztematikusan megismétlődnek, ez az oka a rendszer és a szerverek alapos ellenőrzésének és karbantartásának (ha az alap kliens-szerver).
Hibák a konfiguráció írása közben
Minden tipikus konfiguráció meg van tervezve képzett szakemberekés szakértők. Minden rendszer gondosan tesztelt és optimalizált a gyorsabb és pontosabb munkavégzés érdekében.
Ebben a tekintetben a hiba oka egy külső fejlesztő által írt, szuboptimális kódban keresendő. Ez egy „súlyos” kérés lehet, amely hosszú ideig blokkolja az adatokat. Az sem ritka, hogy alacsony teljesítményű és logikát sértő algoritmusokat készítenek.
Nagy valószínűséggel a zárkonfliktus pontosan a fejlesztői hibák miatt keletkezett, ha a program frissítése után merült fel. Az ellenőrzéshez egyszerűen „visszagörgetheti” a fejlesztéseket, vagy újrafaktorálhatja a kódot.
Kérdés: UT11.1. Megvalósítások kötegelt létrehozása. Lock Conflict
Jó napot UT11.1 konfiguráció. Kliens-szerver opció. Az 1C Server és az SQL Server alapértelmezett beállításai. A megvalósításokat programszerűen alakítjuk ki. A dokumentumok írásának szakaszában időnként zárkonfliktus lép fel. Meg tudná mondani, hogyan oldják meg az ilyen problémákat? Használják a kezelt zárakkal végzett tranzakciókat? Előre is köszönöm.
Válasz:
ne kapcsolja ki) helyezze át őket az éjszakába - előfordulhat, hogy költségkalkulációt végeznek, és a keresési indexeket figyelembe veszik.
Kérdés: Ütközés zárolása tranzakció végrehajtása közben
Minden nap, szinte ugyanabban az időben egy dokumentum kézben tartásakor 5-10 percre felugrik adott hiba 1С 8.3.10.26.99 UT11(11.4.1.261):
Ütközés zárolása tranzakció végrehajtása közben:
Microsoft Sql Server Native Client 11.0: A zárolási kérés időtúllépése.
HERESULT=80040E31, SqlServer: SQLSTATE=HYT00, állapot=38, Súlyosság=10, natív=1222, sor=1
Mondja, hol kezdjem az ásást?
Válasz:() Engedélyezze a profilkészítőt jelenleg a Lock:Acquired és a Lock:Escalation eseményeknél. Majd számolj be, mit kaptál.
Kérdés: Adatbázis helyreállítás (zárolási ütközés)
Jó napot. Az alap haldoklik. Szerver.
Nem azonnal derült ki, mert. minden működött, kivéve az sf dokumentumot. És nem gyakran készül. Ezért a biztonsági mentés nem releváns (nyilván több nap telt el), megpróbálták telepíteni a 2 nappal ezelőtti másolatot - fél napig normális volt, aztán ugyanaz a probléma kitört.
Tünetek: amikor megpróbáljuk törölni az SF-et, akkor is zárkonfliktust kapunk, ha egy felhasználó van az adatbázisban. A TII (logikai és hivatkozási integritás ellenőrzése) meghiúsul egy zárolási ütközés miatt, biztonsági másolatot készít az sql Management Studio-n keresztül - ugyanez ("Időtúllépés az oldal 3-as típusú pufferreteszére várva").
Szeretnénk megpróbálni kitölteni vö. egy hete, de kevés a remény valamire.
Válasz: az adatbázis szerverrel vannak gondok, és nem az 1C-nek, a konfigurációs verzióknak stb. semmi köze hozzá.
Talán a felügyelet nélküli arccsont a lehető legjobban élt, amíg volt elegendő forrás, és most a szerző új szakaszba kezd a tudás fejlődésében.
Ha a méret megengedi - töltse fel a fájlba, és kezdje el az sql mélyebb tanulását.
Kérdés: UT10. Lock Conflict
Jó napot Kliens-szerver opció. Erősen módosított BitAuto konfigurációt örököltem (UT10 alapú autószerviz). A "megrendelés-rendelés" bizonylat kezelőjében a fő a mesterek és vezetők fogadására, az alárendelt bizonylatok kialakítására (realizálás, számla, számla igény), a szerelők bérszámítására, árufoglalásra, ha új dokumentum , majd a megrendelés létrehozása - vevő és néhány egyéb funkció. Az adatbázis nőtt, és gyakran merültek fel zárkonfliktusok. Hétvégén, amikor kevesebb az ember, nincsenek konfliktusok.
Gyanítom, hogy ekkora mennyiségű elemzéssel a dokumentum során hosszú idő blokkol néhány dokumentumnaplót, bár úgy tűnik, hogy a megbízások naplója teljesen le van tiltva.
Ha az "OK" gomb kezelőjeként saját eljárást készít, ahol egymás után elindítja a "Feldolgozást", majd az eljárást, például: Alárendelt dokumentumok generálása, majd Fizetés kiszámítása stb. Nem biztos, hogy ez segítene. Gombok hozzáadása, amelyekre a dokumentumok kialakítását rögzítheti, nem fog működni, mert. a felhasználók elfelejtik.
Válasz:
| Nulla |
|---|
| vde69, Kacsa ez valószínűleg valami Raru baromság |
Nem, ez nem Rarus, ez a BitAuto
Kérdés: 1c zárkonfliktus a dokumentuműrlap megnyitásakor
SCP
Mostanában 2-3 naponta egyszer történik blokkolás a Követelés-Számla bizonylaton. Azok. ilyen típusú dokumentum nincs megnyitva. Mindig
A többi dokumentum jól működik.
Nem találtam problémát a hibakeresőben, nincs időm megállni egyik modulban sem - azonnal ütközés van a zárak között.
Gyanítom, hogy valami probléma van az SQL-ben.
Válasz: A probléma egy index-karbantartási feladat volt, amely nem fejeződött be.
Kérdés: SQL2000 hiba a tranzakció végrehajtása során az 1C77-ben
MSSQL alap 1C77 (27. kiadás) TiS. A bejegyzések végrehajtásakor rendszeresen hibaüzenet jelenik meg:
Hiba történt a tranzakció végrehajtása közben!
SQL állapot: HYT00
Natív:0 Üzenet: Időtúllépés lejárt.
Ennek eredményeként a dokumentum meghiúsul. Eltarthat 20 percig, de akár 1 óráig is.
Hogyan kezeljük, hol ássunk?
Tisztelettel,
Steve242
A fájl csatolva van az üzenethez. Méret - 21Kb
Válasz:
A szokásos Windows perfmonitor azt mutatta, hogy a terminál pokolian betölti a C:\ rendszerlemezt.
Minden más: Memória, CPU - mindkét szerveren (terminálon és whine) szinte nem jelennek meg anomális sorozatok.
Létrehoztam egy 2 Gb-os RAMdrive-ot (a terminálszerveren fizikailag elérhető 12 Gb-ból), és arra próbálom átirányítani a terminál felhasználói profiljainak ideiglenes rendszerkönyvtárait.
amíg valami ilyesmi.
Kérdés: Még egyszer a zárak ütközéséről egy tranzakció végrehajtása során
Válasz:
Kérdés: Letiltás az RTiU-ra való előfizetéskor
Válasz:
Kérdés: Linux, Postgres, Retail 2.0.5.1 Ukraine RIB a boltban - blokkoló hiba...
Valaki meg tudja mondani? Bolti cserét alapítok. Minden jól működik, kiderül, hogy kézzel kell cserélni. 4-5 üzenetet továbbítanak. Aztán felállítom a forgatókönyvet az ütemterv szerint, és kezdődik a swing... Az első hiba:
"Hiba az adatok írása közben a csereüzenetfájlba: (Processing.ConvertingDistributedInfobaseObjects.ObjectModule()): Hiba a kontextus metódusának hívásakor (WriteChanges): Ütközés zárolása a tranzakció során:
A munkamenetre való várakozás miatt túllépték a zárolási hozzáférés maximális üresjárati idejét"
Mind a következők:
"Hiba az adatok írása közben a csereüzenetfájlba: (Processing.ConvertingDistributedInfoBaseObjects.ObjectModule()): Hiba a kontextus metódus hívásakor (WriteChanges): Ütközés zárolása tranzakció végrehajtása közben:
Túllépte a zárolás maximális időtartamát"
Sem az újraindexelés, sem a munkamenetek bezárása nem segít. 1C-ben blokkolni nem éri meg. Csak az alap eltávolítását és az újraalkotást segíti.
Hogyan értettem a tranzitok blokkolását DBMS-ben? Linuxon Postgresst használok, 1 adatbázis, 4 GB RAM. Ha jól gondolom, az a kérdés, hogy a Postgress rosszul van beállítva, vagy nincs memória? Vagy talán egyáltalán nem ez a probléma?
Válasz:() Tehát friss 8.3.10.2375
Kérdés: Blokkolási hiba az információs nyilvántartás törlésekor
Lekérdezéssel kiválasztom az RS rekordokat, majd:
RecordSet.Load(QueryResult.Unload()); RecordSet.Clear(); RecordSet.Write();
Amikor megpróbálok írni, hibaüzenetet kapok:
"Az ütközés zárolása tranzakció végrehajtása közben."
A nyilvántartás nem időszakos, nincs alárendelve az anyakönyvvezetőnek.
Mi a hiba oka?
Válasz:() "Valamiért biztos voltam benne, hogy a válogatást csak az olvasáskor alkalmazzák, és ami a válogatásban szerepel, az ennek megfelelően van megírva." - Hol használja legalább egyszer a „kiválasztás” szót a kódjában?
