Nemohol som si zapísať zmeny na prenos do distribuovanej databázy, tak som kontaktoval podporu 1C a ponúkol som nasledovné. Vyriešil som to jednoducho reštartovaním aplikačného servera a SQL servera. Vo všeobecnosti môžete začiarknuť políčko „Regulačné blokovanie
zahrnuté úlohy"
Pomohlo to aj bez reštartu.

Rutinné operácie na úrovni DBMS pre MS SQL Server

Pokyny na vykonávanie rutinných operácií na úrovni DBMS.

Informácie sa vzťahujú na verziu klient-server 1C:Enterprise 8 pri používaní MS SQL Server DBMS.

Všeobecné informácie

Jednou z najčastejších príčin neoptimálnej prevádzky systému je nesprávne alebo včasné vykonávanie rutinných operácií na úrovni DBMS. Je obzvlášť dôležité vykonávať tieto regulačné postupy vo veľkom informačné systémy ah, ktoré fungujú pod značnou záťažou a slúžia veľkému počtu používateľov súčasne. Špecifikom takýchto systémov je, že bežné úkony vykonávané DBMS automaticky (na základe nastavení) nestačia na efektívnu prevádzku.

Ak spozorujete akékoľvek príznaky problémov s výkonom v spustenom systéme, mali by ste skontrolovať, či je systém správne nakonfigurovaný a pravidelne vykonáva všetky odporúčané rutinné operácie na úrovni DBMS.

Vykonávanie regulačných postupov musí byť automatizované. Na automatizáciu týchto operácií sa odporúča použiť vstavaný nástroj MS SQL Server: Plán údržby. Existujú aj iné spôsoby automatizácie týchto postupov. V tomto článku je pre každý regulačný postup uvedený príklad jeho konfigurácie pomocou plánu údržby pre MS SQL Server 2005.

Odporúča sa pravidelne sledovať aktuálnosť a správnosť týchto regulačných postupov.

Aktualizujte štatistiky

MS SQL Server vytvára plán dotazov na základe štatistických informácií o rozdelení hodnôt v indexoch a tabuľkách. Štatistické informácie sa zhromažďujú na základe časti (vzorky) údajov a automaticky sa aktualizujú, keď sa tieto údaje zmenia. Niekedy to nestačí na to, aby MS SQL Server dôsledne zostavil najoptimálnejší plán na vykonávanie všetkých dotazov.

V tomto prípade sa môžu vyskytnúť problémy s výkonom dotazu. Zároveň plány dotazov vykazujú charakteristické znaky neoptimálnej prevádzky (neoptimálne operácie).

Aby bolo zaručené maximum správna práca Optimalizátor MS SQL Server sa odporúča pravidelne aktualizovať štatistiky databázy MS SQL.

Ak chcete aktualizovať štatistiky pre všetky databázové tabuľky, musíte spustiť nasledujúci dotaz SQL:

exec sp_msforeachtable N"AKTUALIZOVAŤ ŠTATISTIKY ? S FULLSCAN"

Aktualizácia štatistík nevedie k uzamknutiu tabuľky a nebude zasahovať do práce ostatných používateľov. Štatistiky je možné aktualizovať tak často, ako je to potrebné. Je potrebné vziať do úvahy, že zaťaženie servera DBMS sa počas aktualizácie štatistík zvýši, čo môže negatívne ovplyvniť celkový výkon systémov.

Optimálna frekvencia aktualizácie štatistík závisí od veľkosti a charakteru zaťaženia systému a je určená experimentálne. Odporúča sa aktualizovať štatistiky aspoň raz za deň.

Vyššie uvedený dotaz aktualizuje štatistiky pre všetky tabuľky v databáze. V reálnom systéme vyžadujú rôzne tabuľky rôzne rýchlosti aktualizácie štatistík. Analýzou plánov dotazov môžete určiť, ktoré tabuľky najviac potrebujú časté aktualizácie štatistík, a nastaviť dve (alebo viac) rôznych rutinných procedúr: pre často aktualizované tabuľky a pre všetky ostatné tabuľky. Tento prístup výrazne skráti čas aktualizácie štatistík a vplyv procesu aktualizácie štatistík na fungovanie systému ako celku.

Nastavenie automatických aktualizácií štatistík (MS SQL 2005)

Spustite MS SQL Server Management Studio a pripojte sa k serveru DBMS. Otvorte priečinok Správa a vytvorte nový plán služby:

Vytvorte podplán (Add Subplan) a pomenujte ho „Aktualizácia štatistík“. Pridajte k nej úlohu Aktualizovať štatistiku z panela úloh:

Nastavte plán aktualizácie štatistík. Odporúča sa aktualizovať štatistiky aspoň raz denne. V prípade potreby je možné zvýšiť frekvenciu aktualizácií štatistík.

Nakonfigurujte nastavenia úlohy. Ak to chcete urobiť, dvakrát kliknite na úlohu v pravom dolnom rohu okna. V zobrazenom formulári zadajte názov databázy (alebo viacerých databáz), pre ktoré sa budú štatistiky aktualizovať. Okrem toho môžete určiť, pre ktoré tabuľky sa majú štatistiky aktualizovať (ak presne neviete, ktoré tabuľky musíte zadať, nastavte hodnotu na Všetky).

Štatistiky sa musia aktualizovať so zapnutou možnosťou Úplná kontrola.

Uložte vytvorený plán. Keď nastane čas uvedený v pláne, aktualizácia štatistík sa spustí automaticky.

Vymazanie procedurálnej vyrovnávacej pamäte

Optimalizátor MS SQL Server ukladá do vyrovnávacej pamäte plány dotazov na opätovné vykonanie. Robí sa to preto, aby sa ušetril čas strávený kompiláciou dotazu, ak rovnaký dotaz už bol vykonaný a jeho plán je známy.

Je možné, že MS SQL Server na základe zastaraných štatistických informácií vytvorí neoptimálny plán dopytov. Tento plán sa uloží do procedurálnej vyrovnávacej pamäte a použije sa pri opätovnom vyvolaní toho istého dotazu. Ak aktualizujete štatistiky, ale nevymažete vyrovnávaciu pamäť procedúr, SQL Server môže namiesto vytvorenia nového (optimálnejšieho) plánu vybrať starý (suboptimálny) plán dotazov z vyrovnávacej pamäte.

Ak chcete vymazať procedurálnu vyrovnávaciu pamäť MS SQL Server, musíte spustiť nasledujúci SQL dotaz:

Tento dotaz by sa mal spustiť ihneď po aktualizácii štatistiky. Frekvencia jeho vykonávania by sa preto mala zhodovať s frekvenciou aktualizácií štatistík.

Nastavenie procedurálneho vymazania vyrovnávacej pamäte (MS SQL 2005)

Keďže procedurálna vyrovnávacia pamäť musí byť vymazaná pri každej aktualizácii štatistiky, odporúča sa pridať túto operáciu do už vytvoreného podplánu „Aktualizácia štatistík“. Ak to chcete urobiť, otvorte podplán a do jeho schémy pridajte úlohu Vykonať príkaz T-SQL. Potom by ste mali pripojiť úlohu Aktualizovať štatistiku pomocou šípky k novej úlohe.

V texte vytvorenej úlohy Execute T-SQL Statement Task by ste mali zadať požiadavku „DBCC FREEPROCCACHE“:

Defragmentácia indexov

Pri intenzívnej práci s databázovými tabuľkami dochádza k efektu fragmentácie indexov, čo môže viesť k zníženiu výkonu dotazov.

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

Defragmentácia indexov nezamkne tabuľky a nebude zasahovať do práce iných používateľov, ale vytvára dodatočné zaťaženie na SQL Server. Optimálna frekvencia vykonávania tohto rutinného postupu by sa mala zvoliť v súlade so zaťažením systému a účinkom defragmentácie. Odporúča sa defragmentovať indexy aspoň raz týždenne.

Namiesto všetkých tabuliek v databáze môžete defragmentovať jednu alebo viac tabuliek.

Nastavenie defragmentácie indexu (MS SQL 2005)

V predtým vytvorenom pláne údržby vytvorte nový podplán s názvom „Preindexovanie“. Pridajte k nemu úlohu Obnoviť index:

Nastavte plán vykonávania pre úlohu defragmentácie indexu. Úlohu sa odporúča vykonávať aspoň raz týždenne a ak sú údaje v databáze veľmi variabilné, tak aj častejšie – až raz denne.

Preindexovanie databázových tabuliek

Preindexovanie tabuliek zahŕňa úplné prebudovanie indexov databázových tabuliek, čo vedie k významnej optimalizácii ich výkonu. Odporúča sa pravidelne reindexovať databázové tabuľky. Ak chcete preindexovať všetky databázové tabuľky, musíte spustiť nasledujúci dotaz SQL:

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

Preindexovanie tabuliek ich uzamkne na celú dobu ich fungovania, čo môže výrazne ovplyvniť používateľskú skúsenosť. V tejto súvislosti sa odporúča vykonať reindexáciu pri minimálnom zaťažení systému.

Po dokončení opätovného indexovania nie je potrebné indexy defragmentovať.

Nastavenie reindexácie tabuľky (MS SQL 2005)

V predtým vytvorenom pláne údržby vytvorte nový podplán s názvom Defragmentácia indexu. Pridajte k nemu úlohu Obnoviť index:

Nastavte plán vykonávania pre úlohu reindexácie tabuľky. Odporúča sa vykonávať úlohu pri minimálnom zaťažení systému, aspoň raz týždenne.

Nastavte úlohu zadaním databázy (alebo viacerých databáz) a výberom požadovaných tabuliek. Ak presne neviete, ktoré tabuľky by mali byť špecifikované, nastavte hodnotu na Všetky.

Čo sú zámky v 1C, prečo sú potrebné a ako sa vyhnúť problémom pri práci s nimi

Určite sa mnohí z vás pri používaní informačných systémov 1C Enterprise (1C 7.7, 1C 8.1, 1C 8.2, 1C 8.3) stretli s takým javom, akým je blokovanie. Okrem toho každý tento jav spravidla nazýva inak: „blokovanie 1C“, „konflikt blokovania 1C“, „chyby blokovania 1C“, „blokovanie transakcií 1C“ a ďalšie názvy. Poďme sa rýchlo pozrieť na to, čo sú zámky (nie mŕtve body), prečo sú potrebné a ako sa vyhnúť problémom pri práci s nimi.

Samotné blokovanie (vrátane 1C a iných systémov) užitočný nástroj, ktorý poskytuje možnosť pracovať sekvenčne so zdieľanými zdrojmi. Napríklad pojem „zdieľané zdroje“ nás obklopuje po celý život, napríklad keď vy šoférujete auto, nikto iný ho nemôže riadiť. Preto je auto zdieľaným zdrojom. A druhý vodič čaká, kým dorazíte napríklad manželka/manžel. Obaja súťažíte o spoločný zdroj – auto. Kto bude riadiť auto tento moment Definujete na koncepčnej úrovni, ako by sme mali byť in automatizované systémy??? To je dôvod, prečo sme prišli s nástrojom blokovanie, ktoré zabezpečujú organizáciu procesu prístupu k zdieľanému zdroju a definujú front. V živote, ako v informačných systémoch (1C 7.7, 1C 8.1, 1C 8.2, 1C 8.3), je spravidla veľa zdieľaných zdrojov, takže existuje aj veľa blokovaní. Druhým dôležitým bodom je, ako dlho bude vaša manželka/manžel čakať na vydanie vášho auta?Je logické predpokladať, že to nebude trvať večne. Preto majú zámky časový limit – inak známy ako časový limit. Časový limit je maximálny čas, počas ktorého súťažiaci účastník (vaša manželka/manžel) čaká na uvoľnenie zdieľaného zdroja. Potom buď pokračuje v čakaní rovnako dlho, alebo kráča. V informačných systémoch 1C sa uplynutie časového limitu končí správou „Konflikt zámku 1C“, „Chyby zámku 1C“, „Zámky transakcie 1C“, „Časový limit počas uzamknutia“.

Dôležitým detailom, ktorý by sa mal tiež pamätať je, že zámky (najmä v 1C) môžu byť explicitné (nastavené používateľom) a implicitné (nastavené platformou SQL). V článku hovoríme o explicitných zámkoch, takže sa vždy používajú v transakcii, a preto sa ukazuje, že „blokovanie 1C“ a „blokovanie transakcií 1C“ sú synonymá.

Rozhodli sme sa, že pri prekročení časového limitu sa používateľovi zobrazí chybové hlásenie, samotný proces čakania pre neho vyzerá ako zaseknutá obrazovka informačného systému 1C. Pravdepodobnosť zobrazenia správy o časovom limite (chyba používateľa 1C) ovplyvňujú nasledujúce indikátory:

• Mnoho 1C uzamkne transakciu;
• Trvanie transakcie.

Na minimalizáciu správ spojených s chybami uzamykania je potrebné buď znížiť počet zámkov (optimalizovať selektivitu) alebo skrátiť trvanie transakcií.
Teraz určme, ako možno tieto ukazovatele ovplyvniť v skutočnom informačnom systéme 1C.

Ak chcete znížiť množstvo blokovania:

V 1C:Enterprise 7.7:

Informačný systém 1C 7.7. Na uzamykanie sa používajú stolové zámky, ktoré paralyzujú prácu užívateľov. Viac ako 50 ľudí v jednej databáze spravidla nemôže fungovať bezchybne a problémy sa môžu objaviť aj v databázach 20 používateľov.
Riešenie:

• Flexibilné zámky 1C od firmy Softpoint. S ich pomocou nielen zoptimalizujete mnohé zámky (nahradenie zámkov tabuliek používateľskými zámkami), ale aj urýchlite výbery, vyhľadávania a prehľady.

V 1C:Enterprise 8.x:
Informačný systém 1C 8.1., 1C 8.2., 1C 8.3. v automatickom režime využíva redundantné zámky typu (REPEATABLEREAD, SERIALIZABLE). Výsledkom je zhoršená používateľská skúsenosť o 100 alebo viac.
Riešenie:

• Managed locks 1C - vstavaný nástroj platformy 1C pre selektívnejšiu konfiguráciu zámkov. Na jeho použitie musí programátor napísať špeciálne operátory na správne miesta v kóde, aby zablokoval tie potrebné ( podľa jeho názoru!) záznamy v tabuľkách informačného systému;
• Flexibilné zámky 1C - Technológia Softpoint na výmenu štandardných zámkov za zákazkové.

Ak chcete skrátiť čas transakcií:

Pre akékoľvek informačné systémy 1C (1C 7.7., 1C 8.1, 1C 8.2, 1C 8.3), ako aj pre iné informačné systémy, sa používajú podobné prístupy:

Kontrola a správne nastavenie bežná údržba databázy (údržba súborov, indexov, štatistík, dočasných tabuľkových databáz, konfigurácia Windows a SQLServer);

Analýza a optimalizácia ťažkých 1C a SQL dotazov (ladenie indexov, prepisovanie dotazov);

Kontrola nadbytočnosti transakcie. V mnohých prípadoch sú operácie bezdôvodne zahrnuté do transakcie bez toho, aby si uvedomovali, ako to ovplyvní trvanie a tým aj výkonnosť.

1. Ak chcete samostatne riešiť problémy s technickým výkonom 1C (1C 7.7, 1C 8.1, 1C 8.2, 1C 8.3) a iných informačných systémov , potom je tu pre vás jedinečný zoznam technických článkov v našom almanachu (Blokovanie a uviaznutie, veľká záťaž CPU a diskov, údržba databázy a ladenie indexov sú len malou časťou technických materiálov, ktoré tam nájdete).
2. Ak chcete diskutovať o problémoch s výkonom s naším odborníkom alebo si objednať riešenie monitorovania výkonu PerfExpert, potom zanechajte žiadosť a my vás budeme čo najskôr kontaktovať.

Ahojte všetci!

Minule som v práci narazil na problém so zamykaním, konkrétne so správou „Pri vykonávaní transakcie došlo ku konfliktu zámku. Bola prekročená maximálna doba čakania na udelenie zámku.“

Je zrejmé, že tu nie je žiadny problém so zablokovaním, len nejaká relácia uzamkla a „zabudla“ ho odstrániť. Problém zároveň hrozil vážnymi dôsledkami - nevykonal sa dokument Predaj tovarov a služieb. V databáze pracuje naraz asi 100 ľudí a nie je možné vykonať typickú a častú operáciu!

Boli dve riešenia - reštartujte server alebo vyhľadajte neúspešnú reláciu. Prvé riešenie je jednoduché a rýchle, ale ako tu už niekto písal, server môžete reštartovať, kým vás nespustí. Rozhodol som sa pre druhú cestu.

Prvý deň - problém sa objavil počas dňa, najskôr sa zdalo, že problém bol so vzdialeným používateľom, ktorý sa prihlásil do konfigurátora. Vyzeralo to tak, že poprava sa v určitom bode jednoducho zastavila a blokovanie, samozrejme, nebolo odstránené. Po niekoľkých hodinách sa nám podarilo uvoľniť konfigurátor, ale problém nezmizol. Bolo extrémne nežiaduce násilne zabiť konfigurátor, možno v ňom pracovali. Potom vstúpil do hry Google. Na tejto stránke som našiel článok, ktorý hovorí, ako nájsť zámky v MS SQL DBMS, skontroloval som, že na úrovni DBMS neboli žiadne zámky. Zvláštne. Ďalej tam boli pokusy nastaviť tech. časopis. Nastaviť, čo ďalej? Za 15 minút, pár koncertov polená! Ako ich čítať, čo hľadať? Neznámy.

Našiel som článok o tom, ako zistiť, čo je blokované pomocou SQL Trace. Aj keď to nájdem, čo ďalej? Potrebujem reláciu!

Bližšie k 16:00, keď som si uvedomil, že už nemôžem dlhšie čakať, urobil som reštart. V nádeji, že sa to už nebude opakovať (a to bolo prvýkrát za šesť mesiacov práce), som si vydýchol, všetko fungovalo. Ale márne... Druhý deň – rovnaká situácia. Kopal som hodinu a pol, opäť nepochopiteľné pokusy googliť a pod. Žiadne výsledky. Reštartovať. Na konci dňa sa to zopakovalo. No, myslím, že je to skvelé, pokojne prídem domov a posadím sa a budem kopať. Prídem domov, všetko je v poriadku. žiaľ.

Na tretí deň som si pozrel webinár, hovorili o zaujímavom a efektívna metóda hľadanie problému. Spomenul som si, ale problém sa už nevyskytol. Prešiel týždeň a je to tu - opäť blokády! Pošúcham si ruky a začnem konať.

Najprv si založte denník. Áno, bez toho sa nezaobídem, ale teraz už viem, ako to čítať. Nastavili sme dve udalosti: prvá je TLOCK, druhá je TTIMEOUT. Prvý zobrazuje všetky blokujúce udalosti, druhý zobrazuje blokujúce udalosti, ktoré nebolo možné nainštalovať v určenom čase. V skutočnosti s najväčšou pravdepodobnosťou stačí iba TTIMEOUT.

Skopírujeme súbor technického denníka na určené miesto, vletíme do programu, vyvoláme blokovanie, dostaneme správu a súbor technického denníka odstránime alebo premenujeme. Nepotrebujeme veľa informácií o iných blokáciách!

Prejdite do priečinka rphost_PID, nájdite textové súbory a vyhľadajte slovo TTIMEOUT. Vidíme riadok:

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=8239

Mimochodom, môže existovať niekoľko priečinkov rphost_PID, všetko závisí od toho, koľko pracovných procesov beží na serveri.

A potom je všetko jednoduché: pozrite sa na koniec riadku - WaitConnections = 8239, toto je naše číslo PRIPOJENIA. Prejdeme na konzolu servera, prejdeme na Pripojenia, nájdeme toto číslo a pozrieme sa na číslo relácie. V mojom prípade boli dve relácie na používateľa - neúspešná a ďalšia. Relácia, na ktorú poukazoval technický časopis, sa zrútila. A hľa! Všetko fungovalo, radosť nepozná hraníc! Ale ako sa neskôr ukázalo, relácia nebola zmrazená :), pracovali v nej. Preto je v budúcnosti vhodné kontaktovať používateľa a upozorniť ho.

Podľa mňa celkom štandardné riešenie celkom štandardného problému. Nie je známe, prečo som na to nenarazil, možno preto, že som to musel hľadať z poplachu, a keď to používatelia nestlačili, nebolo možné vykonať testy - nedošlo k žiadnej chybe.

Keď stovky používateľov súčasne pracujú s programami a dátami, vznikajú problémy, ktoré sú charakteristické len pre rozsiahle riešenia. Hovoríme o problémoch spôsobených blokovaním údajov.

Niekedy sa používatelia dozvedia o blokovaní zo správ, ktoré naznačujú, že nemôžu zapisovať údaje alebo vykonávať inú operáciu. Niekedy v dôsledku veľmi výrazného poklesu výkonu programu (napríklad, keď sa čas potrebný na vykonanie operácie predĺži desiatky alebo stovky krát).

Problémy spôsobené blokovaním nemajú všeobecné riešenie. Preto sa pokúsime analyzovať príčiny takýchto problémov a systematizovať možnosti ich riešenia.

DÔVODY BLOKOVANIA TRANSAKCIÍ

Najprv si pripomeňme, čo sú zámky, a zároveň zistíme, či sú potrebné. Pozrime sa na pár klasických príkladov blokád, s ktorými sa v živote stretávame.

Príklad 1: Kúpa letenky alebo lístka na vlak. Predpokladajme, že sme pokladníkovi vyjadrili svoje želania. Pokladníčka nám oznámi dostupnosť voľných miest, z ktorých si môžeme vybrať to, ktoré sa nám najviac páči (ak ich je samozrejme viacero). Kým vyberieme a potvrdíme súhlas s navrhovanou možnosťou, tieto miesta nie je možné predať nikomu inému, t.j. sú dočasne „zablokované“. Ak by neboli zablokované, tak v čase potvrdenia môže nastať situácia, že nami vybrané vstupenky sú už predané. A v tomto prípade môže mať cyklus výberu nepredvídateľný počet opakovaní. Kým my vyberáme miesta, sú už predané!... Zatiaľ čo my vyberáme iné a už tam nie sú...

Príklad 2: nákup niečoho v obchode alebo v bazáre. Pristúpili sme k pultu a zo stoviek dostupných jabĺk sme vybrali najkrajšie jablko. Vybrali si to a pre peniaze siahli do vrecka. Ako to bude vyzerať, ak v tej chvíli, keď počítame peniaze, jablko, ktoré sme si vybrali, predá kupujúcemu, ktorý príde neskôr ako my?

Blokovanie samo o sebe je teda nevyhnutným a užitočným javom. Práve vďaka blokovaniu garantujeme, že akcie sú dokončené v jednom kroku. A najčastejšie to nie je najúspešnejšia implementácia, ktorá vedie k negativite. softvér keď napr.:

• je zablokovaný nadmerný počet predmetov (vstupenky, jablká);
• Doba blokovania sa neprimerane predlžuje.

NADMERNÉ BLOKOVANIE V TYPICKÝCH KONFIGURÁCIÁCH 1C

Zapnuté veľkých projektov, spravidla používame 1C:Enterprise. Preto praktické odporúčania Pokúsime sa popísať riešenia problémov s blokovaním na príklade kombinácie 1C:Enterprise + MS-SQL.

8. generácia 1C:Enterprise poskytuje veľmi, veľmi dobrú paralelnosť použitia. Dokáže pracovať súčasne s jednou konfiguráciou (teda na jednej základni) s bežnými servermi a komunikačnými kanálmi veľké množstvo používateľov. Napríklad stovky skladníkov spracovávajú výdaj alebo príjem tovaru, ekonómovia súbežne kalkulujú mzdové náklady podľa rôzne oddelenia, účtovníci vykonávajú výpočty a mzdy a pod.

Existuje však dôvod, prečo existuje opačný názor - mýtus, že pri intenzívnom súčasnom používaní je práca s riešeniami založenými na 1C:Enterprise nepohodlná alebo nemožná. Koniec koncov, akonáhle štandardné riešenia pre 1C:Enterprise začnú používať stovky používateľov v priemyselnom meradle, čoraz častejšie sa na obrazovke objaví okno s hrdým nápisom: „Chyba pri volaní kontextovej metódy (Write) : Konflikt uzamykania pri vykonávaní transakcie: ..." a ďalej v závislosti od typu použitého servera SQL niečo ako „Poskytovateľ Microsoft OLE DB pre SQL Server: Časový limit požiadavky na uzamknutie bol prekročený. ... ".

Takmer všetky štandardné riešenia v navrhovanej predpripravenej implementácii sú nakonfigurované na automatickú správu zámkov. „Automatický“ tu možno vnímať ako „paranoidný“. Pre každý prípad pri vybavovaní akéhokoľvek dokumentu blokujeme všetko, čo s tým môže nejako súvisieť. Ukazuje sa teda, že keď jeden používateľ niečo urobí (a niekedy to len zapíše), zvyšok môže len čakať.

Vyjadrím svoj názor, prečo sa 1C rozhodla nekonfigurovať svoje štandardné riešenia na vysoké paralelné použitie. Náklady na prácu pri takejto úprave nie sú vysoké - niekoľko „mužných mesiacov“, čo nie je významné na stupnici 1C. Zdá sa mi, že dôvod je iný.

Po prvé, takáto úprava výrazne komplikuje spracovanie všetkých dokumentov. To znamená, že pre tých spotrebiteľov, ktorí používajú 1C na malé úlohy, bude bez akéhokoľvek zisku iba nevýhoda - náročnosť úpravy štandardnej konfigurácie sa skomplikuje. Štatistiky zároveň naznačujú, ktorá kategória klientov je hlavným žľabom pre 1C...

Druhý dôvod je pochovaný v typickom základné nastavenia SQL servery, napríklad MS-SQL, ktorý sa stále používa častejšie ako iné. Stalo sa tak, že priority v nastaveniach boli dané skôr šetreniu RAM servera ako znižovaniu blokovania. To vedie k tomu, že ak je potrebné uzamknúť niekoľko riadkov, SQL server urobí rozhodnutie „úspora pamäte a procesora“ – uzamkne celú tabuľku naraz!

Toto sú nedostatky štandardné riešenia alebo špecifiká použitého nastavenia databázového servera sú často identifikované problémami spôsobenými uzamknutím. V dôsledku toho technické nedostatky vedú k veľmi významným organizačné problémy. Ak totiž zamestnanec dostane dôvod na odpútanie sa od práce alebo na zdôvodnenie, prečo prácu nemohol vykonať, menšina bude pracovať efektívne. Správa o blokovaní transakcií alebo „brzdiaci“ program je ideálnym odôvodnením, prečo sa niečo nedalo urobiť.

ODPORÚČANIA NA ODSTRÁNENIE NADMERNÉHO BLOKOVANIA PRE 1C:TERPRISE

Čo robiť, ak je riešenie problémov s nadmerným zamykaním také dôležité?

V záverečnej fáze implementácie všetkých veľkých komplexov je potrebné vykonať jemné doladenie, aby sa odstránilo zbytočné blokovanie transakcií. Je dôležité vyriešiť problémy, ktoré môžu vzniknúť v dôsledku nedostatočne vyvinutých podmienok blokovania alebo implementačných techník.

Pretože túto operáciu je mimoriadne dôležitá a musí sa vykonávať neustále. Preto sme pre zjednodušenie takýchto úprav vypracovali niekoľko základných odporúčaní, ktoré sa snažíme dodržiavať. Odporúčania prijaté a testované na základe skúseností z veľkého počtu implementácií vo veľkom meradle.

1. Ak DBMS alebo vývojový systém, ktorý používate (napríklad 1C:Enterprise) štandardne používa režim automatického blokovania údajov, odmietnite automatické ovládanie blokovanie. Sami si nakonfigurujte pravidlá blokovania, popíšte kritériá blokovania celých tabuliek alebo jednotlivých riadkov.
2. Pri vývoji programu vždy, keď je to možné, pristupujte k tabuľkám v rovnakom poradí.
3. Snažte sa nezapisovať do tej istej tabuľky viackrát v rámci tej istej transakcie. Ak je to ťažké, minimalizujte aspoň časový interval medzi prvým a posledným zápisom.
4. Analyzujte možnosť deaktivácie eskalácie zámkov na úrovni servera SQL.
5. Jasne informujte používateľov o dôvodoch, prečo nemôžu vykonať žiadne akcie, ak sú kvôli zablokovaniu. Poskytnite prístupné a zrozumiteľné odporúčania, čo robiť ďalej.

Ak sa pozorne pozriete na odporúčania, je jasné, že takéto testovanie je vhodné nielen pre 1C:Enterprise, ale pre akékoľvek systémy. Vôbec nezáleží na tom, v akom jazyku sú napísané a s akým databázovým serverom pracujú. Väčšina odporúčaní má univerzálny charakter, a preto sú rovnako platné pri používaní 1C:Enterprise a pre „domáce“ programy alebo iné „krabicové“ systémy ERP.

P.S. Vedeli ste, že ponúkame odbornú pomoc s aktualizáciou softvéru 1C? najlepšia cena?

Značky na vyhľadávanie:

• Zámky transakcií
• Odstránenie blokád
• 1C zámky
• Zamknúť
• Konflikt zámku
• Uzamknutie sporu počas transakcie

Na systémoch s viacerými používateľmi dôležitá úloha hrá správna organizáciaštruktúry a nastavenie zámkov. Ak tam nie je, používatelia sa často budú musieť vysporiadať s chybami spôsobenými súťažou o určité systémové prostriedky. Existuje však problém konfliktu zámkov, ktorý je známy mnohým používateľom. Prečo dochádza ku konfliktu zámku 1C a ako ho vyriešiť?

Konflikt zámkov v 1C 8.3 a jeho význam

Pre väčšinu používateľov znamená správa o konflikte zámku 1C iba chybu, ktorá im bráni vykonávať svoju prácu. Chcú sa tohto problému čo najrýchlejšie zbaviť a obliehať IT oddelenie so sťažnosťami, že „1C nefunguje“.

Ale pre správcov systému a vývojári, takáto správa naznačuje možnú prítomnosť problémov v štruktúre konfigurácie. Predtým, ako sa pokúsite potešiť používateľov a odstrániť blokády, musíte analyzovať situáciu a pochopiť dôvod chybového hlásenia.

Dôvody blokovania chýb v 1C

Ukážkové testovanie záťaže dokazuje, že server 1C vydrží paralelnú prevádzku viac ako päťtisíc používateľov. Ale ideálne podmienky pre takéto experimenty sú v každodenných podmienkach veľkých a stredných firiem nedosiahnuteľné. Na dosiahnutie podobného výkonu a bezchybnej prevádzky musí byť konfigurácia ideálne navrhnutá a prispôsobená špecifickým podnikovým procesom podniku.

Ak nevyberiete ideálne možnosti, dôjde ku konfliktom uzamykania 1C z nasledujúcich dôvodov:

Súčasná práca používateľov s veľkým množstvom dát. Táto hlavná príčina je diktovaná vnútornými mechanizmami 1C. Zahŕňajú zákaz zmien údajov zahrnutých do transakcie spustenej v mene iného používateľa;

Chyby a nedostatky v konfigurácii.Štruktúra štandardných riešení od spoločnosti 1C zohľadňuje odporúčania pre maximalizáciu produktivity. Vývojári tretích strán však nie vždy dodržiavajú vysoké štandardy a v ich kóde možno často nájsť nasledujúce chyby:

• Suboptimálne dopyty;
• Žiadosť o zostatky na začiatku akcií;
• Nepochopenie účelu konfiguračných objektov a ich nesprávne použitie;
• Redundancia blokovacích zariadení zabudovaných do systému alebo dodatočne vyvinutých.

Ako opraviť konflikt zámkov v 1C 8.3

Systémová správa „konflikt uzamknutia pri vykonávaní transakcie 1C 8.3“ necharakterizuje konfiguráciu ako nesprávne navrhnutú. Ak sa však takéto signály ignorujú, existuje možnosť dostať sa v najkritickejšom momente do veľkých problémov, napríklad pri podávaní štvrťročných alebo výročných správ. V lepšom prípade pomalý systém a nespokojní používatelia. V najhoršom prípade sú výstupné údaje nesprávne, čo môže viesť k sankciám zo strany regulačných orgánov.

Riešením problému konfliktu zámkov v 1C 8.3 môže byť prenos konfigurácie do riadeného (manuálneho) režimu správy zámkov. Mechanizmus implementovaný vo verzii 8.1 v rukách kompetentných špecialistov rieši problém konfliktov zámkov počas transakcie v 1C.

Je však potrebné mať na pamäti, že táto akcia zníži úroveň ochrany údajov pred zmenami pri čítaní inými používateľmi. Preto, ak nie ste pripravení nezávisle ovládať všetky zámky v systéme, neponáhľajte sa so zmenou konfiguračných nastavení.

Rýchle riešenie konfliktu uzamykania 1C

V práci administrátora alebo vývojára môže nastať situácia, keď nie je čas na kontrolu chyby a hľadanie základných príčin problému. Napríklad je potrebné podať správu alebo odoslať údaje do určitého času, ale bránia tomu chyby blokovania 1C.

Existujú dva spôsoby, ako rýchlo vyriešiť problém:

• Nájdite a ukončite reláciu, ktorá blokuje požadované údaje. IN malé spoločnosti, kde počet používateľov 1C nepresahuje niekoľko desiatok ľudí, je to optimálne riešenie;
• Ak ovládate systém so stovkami zamestnancov, nájdenie správnej relácie bez špecializovaného softvéru môže trvať dlho. V tomto prípade bude oveľa efektívnejšie reštartovať server.

Tieto riešenia sú radikálne a sú zamerané len na rýchle vyriešenie problému a uvoľnenie dát pre urgentné hlásenia. Dá sa odstrániť iba pochopením dôvodu, prečo pri vykonávaní transakcie 1C vznikol konflikt uzamykania. Po takýchto akciách je potrebné nájsť zraniteľnosti v systéme, optimalizovať konfiguráciu či prácu zamestnancov. Neodporúča sa používať takéto opatrenia priebežne v prípade pravidelných konfliktov uzamykania transakcií.