Negalėjau užsirašyti pakeitimų perkėlimui į paskirstytą duomenų bazę, susisiekiau su 1c palaikymo tarnyba ir pasiūliau štai ką. Nusprendžiau tiesiog iš naujo paleisti programų serverį ir serverį su SQL. Paprastai galite pažymėti langelį „Blokavimas suplanuotas
įtrauktos užduotys"
Tai taip pat padėjo be perkrovimo.

Suplanuotos operacijos DBVS lygiu MS SQL Server

Įprastų operacijų DBVS lygiu atlikimo instrukcijos.

Informacija taikoma 1C:Enterprise 8 kliento-serverio versijai, kai naudojama MS SQL Server DBVS.

Bendra informacija

Viena dažniausių neoptimalaus sistemos veikimo priežasčių yra neteisingas arba nesavalaikis įprastų operacijų vykdymas DBVS lygmeniu. Ypač svarbu laikytis šių įprastinių procedūrų Informacinės sistemos ah, kurios dirba esant didelei apkrovai ir vienu metu aptarnauja daug vartotojų. Tokių sistemų specifika ta, kad efektyviam darbui neužtenka įprastų DBVS automatiškai atliekamų veiksmų (pagal nustatymus).

Jei veikiančioje sistemoje atsiranda kokių nors našumo problemų požymių, turėtumėte patikrinti, ar sistema tinkamai sukonfigūruota ir reguliariai atlieka visą rekomenduojamą įprastinę priežiūrą DBVS lygiu.

Įprastų procedūrų vykdymas turėtų būti automatizuotas. Norint automatizuoti šias operacijas, rekomenduojama naudoti MS SQL Server: Maintenance Plan integruotus įrankius. Yra ir kitų būdų, kaip automatizuoti šias procedūras. Šiame straipsnyje kiekvienai suplanuotai procedūrai pateikiamas jos konfigūracijos pavyzdys naudojant MS SQL Server 2005 priežiūros planą.

Rekomenduojama reguliariai stebėti šių įprastų procedūrų atlikimo savalaikiškumą ir teisingumą.

Statistikos atnaujinimas

MS SQL Server sukuria užklausų planą, pagrįstą statistine informacija apie reikšmių pasiskirstymą indeksuose ir lentelėse. Statistinė informacija renkama pagal duomenų dalį (imtį) ir automatiškai atnaujinama, kai šie duomenys pasikeičia. Kartais to nepakanka, kad MS SQL Server nuosekliai sudarytų optimaliausią visų užklausų vykdymo planą.

Tokiu atveju gali kilti užklausos našumo problemų. Tuo pačiu metu užklausų planuose pastebimi būdingi neoptimalaus darbo požymiai (neoptimalios operacijos).

Siekiant garantuoti maksimaliai teisingas darbas MS SQL Server optimizavimo priemonė rekomenduoja reguliariai atnaujinti MS SQL duomenų bazės statistiką.

Norėdami atnaujinti visų duomenų bazės lentelių statistiką, turite vykdyti šią SQL užklausą:

exec sp_msforeachtable N"ATNAUJINTI STATISTIKĄ? SU FULLSCAN"

Atnaujinus statistiką lentelės neužrakinamos ir netrukdys kitų vartotojų darbui. Statistika gali būti atnaujinama tiek kartų, kiek reikia. Reikėtų atsižvelgti į tai, kad statistikos atnaujinimo metu padidės DBVS serverio apkrova, o tai gali neigiamai paveikti bendrą našumą sistemos.

Optimalus statistikos atnaujinimo dažnis priklauso nuo sistemos apkrovos dydžio ir pobūdžio ir nustatomas eksperimentiniu būdu. Rekomenduojama atnaujinti statistiką bent kartą per dieną.

Aukščiau pateikta užklausa atnaujina visų duomenų bazės lentelių statistiką. Realioje sistemoje skirtingoms lentelėms reikalingi skirtingi statistikos atnaujinimo rodikliai. Analizuodami užklausų planus, galite nustatyti, kurioms lentelėms statistiką reikia atnaujinti dažniausiai, ir nustatyti dvi (ar daugiau) skirtingas įprastas procedūras: dažnai atnaujinamoms ir visoms kitoms lentelėms. Toks požiūris žymiai sumažins statistikos atnaujinimo laiką ir statistikos atnaujinimo proceso įtaką visos sistemos veikimui.

Automatinio statistikos atnaujinimo konfigūravimas (MS SQL 2005)

Paleiskite MS SQL Server Management Studio ir prisijunkite prie DBVS serverio. Atidarykite valdymo aplanką ir sukurkite naujas planas paslauga:

Sukurkite poplaną (Pridėti subplaną) ir pavadinkite jį „Statistikos atnaujinimas“. Pridėkite statistikos atnaujinimo užduotį iš užduočių juostos:

Nustatykite statistikos atnaujinimo tvarkaraštį. Rekomenduojama statistiką atnaujinti bent kartą per dieną. Jei reikia, statistikos atnaujinimo dažnis gali būti padidintas.

Nustatykite užduoties nustatymus. Norėdami tai padaryti, dukart spustelėkite užduotį apatiniame dešiniajame lango kampe. Pasirodžiusioje formoje nurodykite duomenų bazės (arba kelių duomenų bazių), kurios statistika bus atnaujinta, pavadinimą. Be to, galite nurodyti, kurioms lentelėms atnaujinti statistiką (jei tiksliai nežinote, kurias lenteles reikia nurodyti, tada nustatykite reikšmę Visi).

Atnaujinti statistiką turi būti įjungta Full Scan parinktis.

Išsaugokite sukurtą planą. Atėjus tvarkaraštyje nurodytam laikui, statistika bus atnaujinta automatiškai.

Procedūrinės talpyklos išvalymas

MS SQL Server optimizavimo priemonė talpykloje saugo užklausų planus, kad būtų galima juos vykdyti iš naujo. Tai daroma siekiant sutaupyti laiko sugaištą užklausai sudaryti, jei ta pati užklausa jau buvo įvykdyta ir žinomas jos planas.

Gali būti, kad MS SQL Server, remdamasi pasenusia statistine informacija, sukurs neoptimalų užklausų planą. Šis planas bus saugomas procedūrinėje talpykloje ir naudojamas, kai vėl bus iškviesta ta pati užklausa. Jei atnaujinote statistiką, bet neišvalėte procedūrinės talpyklos, SQL serveris gali pasirinkti seną (neoptimalų) užklausos planą iš talpyklos, o ne sukurti naują (geresnį) planą.

Norėdami išvalyti MS SQL Server procedūrinę talpyklą, turite vykdyti šią SQL užklausą:

Šią užklausą reikia paleisti iš karto po statistikos atnaujinimo. Atitinkamai, jos vykdymo dažnis turėtų atitikti statistikos atnaujinimo dažnumą.

Procedūrinės talpyklos išvalymo konfigūravimas (MS SQL 2005)

Kadangi kiekvieną kartą atnaujinant statistiką reikia išvalyti procedūrinę talpyklą, rekomenduojama šią operaciją įtraukti į jau sukurtą „Atnaujinti statistiką“ poplanį. Norėdami tai padaryti, atidarykite poplaną ir į jo schemą įtraukite T-SQL pareiškimo užduotį. Tada turėtumėte prijungti statistikos atnaujinimo užduotį su rodykle prie naujos užduoties.

Sukurtos Execute T-SQL pareiškimo užduoties tekste turėtumėte nurodyti užklausą „DBCC FREEPROCCACHE“:

Indekso defragmentavimas

Intensyviai dirbant su duomenų bazių lentelėmis, atsiranda indeksų suskaidymo efektas, dėl kurio gali sumažėti užklausų efektyvumas.

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

Indekso defragmentavimas neblokuoja lentelių ir netrukdys kitų vartotojų darbui, tačiau sukuria papildomą apkrovą SQL serveriui. Optimalus šios įprastinės procedūros atlikimo dažnis turėtų būti parinktas atsižvelgiant į sistemos apkrovą ir defragmentavimo efektą. Rekomenduojame defragmentuoti indeksus bent kartą per savaitę.

Galima defragmentuoti vieną ar kelias lenteles, o ne visas lenteles duomenų bazėje.

Indekso defragmentavimo konfigūravimas (MS SQL 2005)

Anksčiau sukurtame priežiūros plane sukurkite naują poplaną pavadinimu „Reindex“. Pridėkite prie jo „Rebuild Index Task“:

Nustatykite indekso defragmentavimo užduoties vykdymo grafiką. Užduotį rekomenduojama vykdyti bent kartą per savaitę, o jei duomenų bazėje esantys duomenys labai nepastovūs, dar dažniau – iki vieno karto per dieną.

Duomenų bazių lentelių perindeksavimas

Lentelių pakartotinis indeksavimas apima visišką duomenų bazės lentelių indeksų atkūrimą, o tai leidžia žymiai optimizuoti jų darbą. Rekomenduojama reguliariai atlikti duomenų bazių lentelių perindeksavimą. Norėdami iš naujo indeksuoti visas duomenų bazės lenteles, turite vykdyti šią SQL užklausą:

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

Perindeksuojant lenteles jos užblokuojamos jų darbo metu, o tai gali labai paveikti vartotojų darbą. Šiuo atžvilgiu pakartotinį indeksavimą rekomenduojama atlikti esant minimaliai sistemos apkrovai.

Po pakartotinio indeksavimo indeksų defragmentuoti nereikia.

Lentelės pakartotinio indeksavimo nustatymas (MS SQL 2005)

Anksčiau sukurtame priežiūros plane sukurkite naują poplaną pavadinimu „Indekso defragmentavimas“. Pridėkite prie jos atkūrimo indekso užduotį:

Nustatykite lentelės pakartotinio indeksavimo užduoties vykdymo grafiką. Užduotį rekomenduojama vykdyti esant minimaliai apkrovai sistemai, bent kartą per savaitę.

Tinkinkite užduotį nurodydami duomenų bazę (arba kelias duomenų bazes) ir pasirinkdami reikiamas lenteles. Jei tiksliai nežinote, kurias lenteles nurodyti, nustatykite reikšmę į Visos.

Kas yra 1C spynos, kodėl jos reikalingos ir kaip išvengti problemų dirbant su jais

Tikrai daugelis iš jūsų, naudodamiesi informacinėmis sistemomis 1C Enterprise (1C 7.7, 1C 8.1, 1C 8.2, 1C 8.3), susidūrėte su tokiu reiškiniu kaip blokavimas. Be to, paprastai visi šį reiškinį vadina skirtingai: „1C užraktai“, „1C užrakto konfliktas“, „1C užrakto klaidos“, „1C operacijų užraktai“ ir kiti pavadinimai. Trumpai išsiaiškinkime, kas yra spynos (ne aklavietės), kam jos reikalingos ir kaip išvengti problemų dirbant su jomis.

Pačios spynos (įskaitant 1C ir kitose sistemose) naudinga priemonė, kuri suteikia galimybę nuosekliai dirbti su bendrais ištekliais. Pavyzdžiui, gyvenime mus supa sąvoka „bendrieji ištekliai“, pavyzdžiui, kol jūs vairuojate automobilį, niekas kitas negali jo vairuoti. Todėl automobilis yra bendras išteklius. Ir antrasis vairuotojas laukia jūsų atvykstant, pavyzdžiui, jūsų žmona / vyras. Jūs abu konkuruojate dėl bendro resurso – automobilio. Kas vairuos mašiną Šis momentas Jūs apibrėžiate konceptualiu lygmeniu, bet kaip turėtume būti automatizuotos sistemos??? Norėdami tai padaryti, jie sugalvojo įrankį blokavimas, kurios organizuoja prieigos prie bendrinamo šaltinio procesą ir apibrėžia eilę. Paprastai gyvenime, kaip ir informacinėse sistemose (1C 7.7, 1C 8.1, 1C 8.2, 1C 8.3), yra daug bendrų išteklių, todėl yra ir daug spynų. Dabar antras svarbus momentas – kiek ilgai jūsų žmona/vyras lauks jūsų automobilio išleidimo, logiška manyti, kad jis netruks amžinai. Todėl užraktams yra nustatytas laiko limitas – kitu atveju skirtasis laikas. Skirtasis laikas yra didžiausias laikas, per kurį varžovas (jūsų žmona / vyras) gali laukti, kol bus išleistas bendras išteklius. Tada arba jis toliau laukia tiek pat laiko, arba eina pėsčiomis. 1C informacinėse sistemose skirtasis laikas baigiasi pranešimu „1C užrakto konfliktas“, „1C užrakto klaidos“, „1C operacijų užraktai“, „Timeout on lock“.

Svarbi detalė, kurią taip pat reikia atsiminti, yra ta, kad užraktai (ypač 1C) yra aiškūs (nustato vartotojas) ir numanomi (nustato SQL platforma). Straipsnyje kalbame apie aiškius užraktus, todėl jie visada naudojami atliekant operaciją, todėl paaiškėja, kad „1C užraktas“ ir „1C sandorio užraktas“ yra sinonimai.

Nusprendėme, kad viršijus skirtąjį laiką vartotojui rodomas klaidos pranešimas, pats laukimo procesas jam atrodo kaip lipnus 1C informacinės sistemos ekranas. Šie indikatoriai turi įtakos laiko pabaigos pranešimo tikimybei (1C klaidos vartotojui):

• Daugelis 1C užrakina sandorį;
• Sandorio trukmė.

Norint sumažinti pranešimų, susijusių su užrakinimo klaidomis, skaičių, reikia arba sumažinti užraktų rinkinį (optimizuoti selektyvumą), arba sumažinti operacijų trukmę.
Dabar nuspręskime, kaip šie rodikliai gali būti paveikti tikroje 1C informacinėje sistemoje.

Norėdami sumažinti daug blokavimo:

1C: Enterprise 7.7:

Informacinė sistema 1C 7.7. spynoms naudojamos stalinės spynos, kurios paralyžiuoja vartotojų darbą. Paprastai daugiau nei 50 žmonių vienoje duomenų bazėje negali dirbti be klaidų, o problemų gali atsirasti ir 20 vartotojų duomenų bazėse.
Sprendimas:

• Lanksčios spynos 1C iš firmos "Softpoint". Jų pagalba jūs ne tik optimizuojate daugybę spynų (pakeičiate stalines spynas į individualias), bet ir pagreitinate pasirinkimą, paieškas ir ataskaitas.

1C:Enterprise 8.x:
Informacinė sistema 1C 8.1., 1C 8.2., 1C 8.3. automatiškai naudoja perteklinio tipo užraktus (REPEATABLEREAD, SERIALIZABLE). Dėl to vartotojo patirtis pablogėja nuo 100.
Sprendimas:

• Valdomos spynos 1C yra integruotas 1C platformos įrankis, skirtas atrankesniems užrakto nustatymams. Norėdamas juo naudotis, programuotojas turi parašyti specialius operatorius tinkamose kodo vietose, kad užblokuotų reikiamus ( jo nuomone!) įrašai informacinės sistemos lentelėse;
• Lanksčios spynos 1C – Softpoint technologija, skirta standartinėms spynoms pakeisti įprastomis.

Norėdami sutrumpinti operacijų trukmę:

Bet kurioms informacinėms sistemoms 1C (1C 7.7., 1C 8.1, 1C 8.2, 1C 8.3), taip pat kitoms informacinėms sistemoms naudojami panašūs metodai:

Patikrinkite ir pataisykite nustatymą įprastinė priežiūra duomenų bazės (failų, indeksų, statistikos, laikinų lentelių duomenų bazių priežiūra, Windows ir SQLServer sąranka);

Sunkių 1C ir SQL užklausų analizė ir optimizavimas (indekso derinimas, užklausų perrašymas);

Sandorio atleidimo patikrinimas. Daugeliu atvejų neprotinga įtraukti operacijas į sandorį nesuvokiant, kaip tai paveiks trukmę, o kartu ir našumą.

1. Jei norite savarankiškai spręsti 1C (1C 7.7, 1C 8.1, 1C 8.2, 1C 8.3) ir kitų informacinių sistemų techninio veikimo problemas , tada jums unikalus techninių straipsnių sąrašas mūsų almanache (užraktai ir aklavietės, didelė procesoriaus ir disko apkrova, duomenų bazių priežiūra ir indeksų derinimas yra tik maža dalis techninės medžiagos, kurią rasite ten).
2. Jei norite aptarti našumo problemas su mūsų ekspertu arba užsisakyti PerfExpert našumo stebėjimo sprendimątada palikite užklausą ir mes kuo greičiau su jumis susisieksime.

Sveiki visi!

Kitą dieną darbe susidūriau su problema su užraktais, būtent, pradėjo rodytis pranešimas "Užraktas konfliktas vykdant operaciją. Viršytas maksimalus užrakto suteikimo laikas".

Akivaizdu, kad čia nėra aklavietės problemos, tiesiog kažkoks seansas uždėjo užraktą ir „pamiršo“ jį pašalinti. Tuo pačiu metu problemai grėsė rimtos pasekmės - nebuvo atliktas dokumentas Prekių ir paslaugų pardavimas. Vienu metu duomenų bazėje dirba apie 100 žmonių, o atlikti tipinės ir dažnos operacijos neįmanoma!

Buvo du sprendimai – perkrauti serverį arba ieškoti nepavykusios sesijos. Pirmasis sprendimas yra paprastas ir greitas, bet, kaip kažkas jau rašė čia, galite perkrauti serverį, kol būsite atleisti. Nusprendė eiti antruoju keliu.

Pirma diena - problema atsirado po pietų, iš pradžių atrodė, kad problema yra nuotoliniame vartotoje, kuris įstrigo konfigūratoriuje. Atrodė, kad egzekucija tiesiog sustojo tam tikrame taške, o užraktas, žinoma, nebuvo atleistas. Po poros valandų pavyko atleisti konfigūratorių, tačiau problema neišnyko. Buvo labai nepageidautina priverstinai nužudyti konfigūratorių, galbūt jie jame dirbo. Po to „Google“ perėmė. Šioje svetainėje radau straipsnį, kuriame rašoma, kaip rasti užraktus MS SQL DBVS, patikrinau, DBVS lygiu spynų nebuvo. Keista. Toliau buvo bandoma juos koreguoti. žurnalas. Nustatyti, kas toliau? Per 15 minučių pora rąstų! Kaip juos skaityti, į ką atkreipti dėmesį? Nežinoma.

Radau straipsnį apie tai, kaip sužinoti, kas užblokuota naudojant SQL Trace. Net jei rasiu, kas tada? Man reikia sesijos!

Arčiau 16:00, kai supratau, kad nebegaliu to patraukti, perkroviau. Tikėdamasis, kad tai nepasikartos (o tai buvo pirmas atvejis per šešis darbo mėnesius), lengviau atsikvėpiau, viskas pavyko. Bet veltui... Antrą dieną – ta pati situacija. Kasinėjau pusantros valandos, vėl nesuprantami bandymai googlinti ir pan. Jokių rezultatų. Perkraukite. Dienos pabaigoje tai pasikartojo. Na, manau, puiku, ramiai grįšiu namo ir sėdėsiu, pasigilinsiu. Grįžtu namo, viskas gerai. Liūdna.

Trečią dieną žiūrėjau webinarą, kalbėjau apie įdomų ir efektyvus metodas ieškoti problemos. Prisiminė, bet problemos daugiau nekilo. Praėjo savaitė ir štai – vėl blokavimas! Pasitrinu rankas ir pradedu veikti.

Pirmasis yra žurnalo nustatymas. Taip, aš negaliu be jo, bet dabar galiu jį skaityti. Nustatėme du įvykius: pirmasis yra TLOCK, antrasis - TTIMEOUT. Pirmasis rodo visus blokavimo įvykius, antrasis rodo blokavimus, kurių nepavyko nustatyti per skirtą laiką. Tiesą sakant, greičiausiai pakanka tik TTIMEOUT.

Nukopijuojame techninio žurnalo failą į paskirtą vietą, skrendame į programą, iškviečiame užraktą, gauname pranešimą ir pašaliname arba pervardijame techninio žurnalo failą. Mums nereikia daugybės informacijos apie kitus blokavimus!

Eikite į aplanką rphost_PID, suraskite tekstinius failus ir ieškokite žodžio TTIMEOUT. Mes matome eilutę:

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

Beje, rphost_PID aplankų gali būti keli, viskas priklauso nuo to, kiek serveryje veikia darbininkų procesų.

Ir tada viskas paprasta: pažiūrėkite į eilutės pabaigą - WaitConnections = 8239, tai yra mūsų CONNECTION numeris. Einame į serverio konsolę, einame į Connections, randame šį numerį ir žiūrime į seanso numerį. Mano atveju vienam vartotojui buvo du seansai – nesėkmingas ir dar vienas. Sugriuvo techniniame žurnale nurodyta sesija. Ir apie stebuklą! Viskas pavyko, džiaugsmui ribų nėra! Bet, kaip vėliau paaiškėjo, seansas nebuvo pakabintas :), joje dirbo. Todėl ateičiai patartina susisiekti su vartotoju ir perspėti.

Mano nuomone, gana tipiškas gana tipiškos problemos sprendimas. Nežinia, kodėl aš su tuo nesusidūriau, galbūt dėl ​​to, kad turėjau jo ieškoti aliarmo metu, o kai vartotojai nepaspaudė, tada nebuvo įmanoma atlikti bandymų - nebuvo jokios klaidos.

Kai šimtai vartotojų vienu metu dirba su programomis ir duomenimis, kyla problemų, būdingų tik didelio masto sprendimams. Kalbame apie problemas, kurias sukelia duomenų užraktai.

Kartais vartotojai apie užraktus sužino iš pranešimų, kurie rodo negalėjimą įrašyti duomenų ar atlikti kokios nors kitos operacijos. Kartais dėl labai reikšmingo programos našumo kritimo (pavyzdžiui, kai operacijos atlikimo laikas išauga dešimtis ar šimtus kartų).

Blokavimo sukeltos problemos neturi bendro sprendimo. Todėl pabandysime išanalizuoti tokių problemų priežastis ir susisteminti jų sprendimo variantus.

SANDORIŲ BLOKAVIMO PRIEŽASTYS

Pirmiausia prisiminkime, kas yra spynos, ir tuo pačiu išsiaiškinsime, ar jų reikia. Pažvelkime į keletą klasikinių blokavimo pavyzdžių, su kuriais susiduriame gyvenime.

1 pavyzdys: lėktuvo arba traukinio bilieto pirkimas. Tarkime, išsakėme savo pageidavimus kasininkei. Kasininkė pasako apie laisvas vietas, iš kurių galime išsirinkti labiausiai patikusią (jeigu yra keletas, žinoma). Kol nepasirinksime ir nepatvirtinsime savo sutikimo su siūlomu variantu, šios vietos negali būti parduodamos niekam kitam, t.y. laikinai užblokuotas. Jeigu jie nebuvo užblokuoti, tai iki patvirtinimo gali susidaryti situacija, kai mūsų pasirinkti bilietai jau parduoti. Ir šiuo atveju atrankos ciklas gali būti nenuspėjamas pakartojimų skaičius. Kol renkamės vietas, bet jos jau parduotos!.. Kol renkamės kitas, o jų nebėra...

2 pavyzdys: ko nors pirkimas parduotuvėje ar turguje. Priėjome prie prekystalio, išsirinkome gražiausią obuolį iš šimto turimų. Jie pasirinko ir įsikišo į kišenę pinigų. Kaip atrodys, jei kol skaičiuosime pinigus, būtent mūsų pasirinktas obuolys bus parduotas vėliau už mus atėjusiam pirkėjui?

Taigi pats blokavimas yra būtinas ir naudingas reiškinys. Būtent blokavimo dėka garantuojame veiksmų atlikimą viename etape. Ir dažniausiai ne pats sėkmingiausias įgyvendinimas veda į neigiamą programinė įranga kai pvz.:

• užblokuotas per didelis objektų (bilietų, obuolių) skaičius;
• blokavimo laikas nepagrįstai pratęsiamas.

PERNEŠAI SUJUNGTI TIPINĖSE 1C KONFIGŪRACIJOSE

Įjungta didelių projektų Paprastai mes naudojame 1C:Enterprise. Štai kodėl praktinių patarimų Pabandysime aprašyti blokavimo problemų sprendimus naudodami paketo 1C: Enterprise + MS-SQL pavyzdį.

8-oji 1C:Enterprise karta užtikrina labai, labai gerą naudojimo lygiagretumą. Vienu metu su viena konfigūracija (tai yra ant vienos bazės), naudojant įprastus serverius ir ryšio kanalus, jis gali veikti puiki suma vartotojų. Pavyzdžiui, šimtai sandėlininkų apdoroja prekių išdavimą ar gavimą, ekonomistai vienu metu skaičiuoja darbo užmokesčio kainą pagal įvairūs skyriai, skaičiuotuvai atlieka atlyginimų apskaičiavimą ir skaičiavimą ir kt.

Tačiau yra priežastis, kodėl yra priešinga nuomonė - mitas, kad intensyviai naudojant tuo pačiu metu yra nepatogu arba neįmanoma dirbti su sprendimais, pagrįstais 1C: Enterprise. Galų gale, kai tik šimtai vartotojų pradeda naudoti standartinius „1C: Enterprise“ sprendimus pramoniniu mastu, vis dažniau ekrane pasirodo langas su išdidžiu užrašu: „Klaida skambinant konteksto metodu (įrašyti): užrakinti. konfliktas vykdant operaciją: ...“ ir toliau, atsižvelgiant į naudojamo SQL serverio tipą, kažkas panašaus į „Microsoft OLE DB Provider for SQL Server: Užrakinimo užklausos skirtasis laikas viršytas. ...".

Beveik visi standartiniai sprendimai siūlomoje „iš dėžutės“ įgyvendinimo yra sukonfigūruoti automatiniam spynų valdymui. „Automatinis“ čia gali būti laikomas „paranojišku“. Tik tuo atveju, vykdydami bet kurį dokumentą, blokuojame viską, kas gali būti kaip nors su juo susijusi. Taigi išeina, kad vienam vartotojui kažkam išleidus (o kartais tiesiog parašius), likusiems belieka laukti.

Išreikšiu savo nuomonę, kodėl 1C nusprendė nepritaikyti savo standartinių sprendimų, kad būtų užtikrintas didelis naudojimo lygiagretumas. Darbo sąnaudos tokiam išgryninimui nėra didelės – keli „žmogiškieji mėnesiai“, kas 1C masteliu nėra reikšminga. Manau, kad priežastis kita.

Pirma, toks patobulinimas labai apsunkina visų dokumentų tvarkytojus. Tai reiškia, kad tiems vartotojams, kurie naudoja 1C mažoms užduotims, be jokio naudos bus tik trūkumas - tipinės konfigūracijos užbaigimo sudėtingumas taps sudėtingesnis. Tuo pačiu metu statistika rodo, kuri klientų kategorija yra pagrindinis 1C tiekėjas ...

Antroji priežastis yra palaidota tipiškoje pagrindiniai nustatymai SQL serveriai, tokie kaip MS-SQL, kuris vis dar naudojamas dažniau nei kiti. Taip atsitiko, kad nustatymuose prioritetai teikiami serverio RAM taupymui, o ne blokavimo mažinimui. Tai lemia tai, kad jei reikia užrakinti kelias eilutes, SQL serveris priima „ekonomišką“ sprendimą dėl atminties ir procesoriaus – užrakinti visą lentelę vienu metu!..

Čia yra trūkumai standartiniai sprendimai arba naudojamos duomenų bazės serverio sąrankos specifikos dažnai painiojamos su problemomis, kurias sukelia užraktai. Dėl to techniniai trūkumai sukelia labai didelių organizacinių problemų. Juk jei darbuotojui bus pateikta priežastis atitraukti dėmesį nuo darbo arba pateisinama, kodėl darbas negalėjo būti atliktas, mažuma dirbs efektyviai. Na, o žinutė apie operacijų blokavimą ar „lėtinimo“ programą yra idealus pateisinimas, kodėl nieko negalima padaryti.

REKOMENDACIJOS DĖL PERTEIKLIO BLOKAVIMO PAŠALINTI 1C:ENTERPRISE

Ką daryti, jei pernelyg didelio blokavimo problemų sprendimas yra toks svarbus?

Paskutiniame visų didelių kompleksų įgyvendinimo etape būtina atlikti išsamų patobulinimą, kad būtų pašalinti nereikalingi sandorių užraktai. Labai svarbu išspręsti problemas, kurios gali kilti dėl nepakankamai išvystytų blokavimo sąlygų ar įgyvendinimo metodikos.

Nes šią operaciją labai svarbu, tai turi būti vykdoma nuolat. Todėl, norėdami supaprastinti tokio patobulinimo įgyvendinimą, sukūrėme keletą pagrindinių rekomendacijų, kurių stengiamės laikytis. Rekomendacijos buvo gautos ir išbandytos remiantis daugelio didelio masto diegimų patirtimi.

1. Jei jūsų DBVS arba kūrimo sistema (pvz., 1C:Enterprise) pagal numatytuosius nustatymus naudoja automatinio duomenų užrakinimo režimą, išmeskite automatinis valdymas spynos. Pats nustatykite blokavimo taisykles, apibūdinkite visų lentelių ar atskirų eilučių blokavimo kriterijus.
2. Kurdami programą, kai tik įmanoma, žiūrėkite lenteles ta pačia tvarka.
3. Stenkitės nerašyti į tą pačią lentelę kelis kartus per tą pačią operaciją. Jei tai sunku, bent jau sumažinkite laiką tarp pirmosios ir paskutinės rašymo operacijos.
4. Išanalizuokite galimybę išjungti užrakto eskalavimą SQL serverio lygiu.
5. Aiškiai informuokite vartotojus apie priežastis, kodėl neįmanoma atlikti jokių veiksmų, jei jie atsiranda dėl blokavimo. Pateikite prieinamas ir suprantamas rekomendacijas, ką daryti toliau.

Jei atidžiai pažvelgsite į rekomendacijas, tai paaiškės tokia plėtra tinka ne tik 1C:Enterprise, bet ir bet kuriai sistemai. Nesvarbu, kokia kalba jie parašyti ir su kokiu duomenų bazės serveriu dirba. Dauguma rekomendacijų yra universalaus pobūdžio, todėl vienodai galioja ir naudojant 1C: Enterprise, ir „savarankiškai parašytoms“ programoms ar kitoms „dėžutinėms“ ERP sistemoms.

P.S. Ar žinojote, kad siūlome profesionalią pagalbą atnaujinant 1C programinę įrangą geriausia kaina?

Ieškoti žymų:

• Sandorių užraktai
• Užsikimšimų šalinimas
• 1C blokavimas
• blokavimas
• Užrakto konfliktas
• Užrakinti konfliktą vykdant operaciją

Kelių vartotojų sistemose svarbus vaidmuo vaidina tinkama organizacija konstrukcijos ir nustatymo spynos. Jei ne, vartotojai dažnai susidurs su klaidomis, kurias sukelia konkurencija dėl tam tikrų sistemos išteklių. Tačiau yra užrakto konflikto problema, su kuria daugelis vartotojų yra susipažinę. Kodėl kyla 1C užrakto konfliktas ir kaip jį išspręsti?

Užrakinti konfliktą 1C 8.3 ir jo reikšmę

Daugumai vartotojų 1C užrakto konflikto pranešimas reiškia tik klaidą, kuri neleidžia jiems atlikti savo darbo. Jie nori kuo greičiau atsikratyti šios problemos ir apgulti IT skyrių skundais, kad „1C neveikia“.

Bet už sistemos administratoriai ir kūrėjams, toks pranešimas rodo galimą konfigūracijos struktūros problemą. Prieš bandydami įtikti vartotojams ir pašalinti blokus, turite išanalizuoti situaciją ir suprasti klaidos pranešimo priežastį.

Blokavimo klaidų priežastys 1C

Demonstraciniai apkrovos testai rodo, kad 1C serveris gali atlaikyti lygiagretų daugiau nei penkių tūkstančių vartotojų veikimą. Tačiau idealios sąlygos tokiems eksperimentams yra nepasiekiamos kasdienėmis didelių ir vidutinių įmonių sąlygomis. Norint pasiekti panašų našumą ir našumą be klaidų, konfigūracija turi būti idealiai suprojektuota ir pritaikyta konkretiems įmonės verslo procesams.

Jei nesiimsite idealių variantų, 1C užrakto konfliktai kyla dėl šių priežasčių:

Vienalaikis vartotojų darbas su dideliu duomenų kiekiu.Šią pagrindinę priežastį lemia vidiniai 1C mechanizmai. Jie reiškia draudimą keisti duomenis, susijusius su kito vartotojo vardu vykdoma operacija;

Konfigūracijos klaidos ir trūkumai.Įmonės „1C“ standartinių sprendimų struktūroje atsižvelgiama į rekomendacijas, kaip padidinti produktyvumą. Tačiau trečiųjų šalių kūrėjai ne visada laikosi aukštų standartų, todėl jų kode dažnai galite rasti šiuos trūkumus:

• Neoptimalios užklausos;
• Prašymas dėl likučių veiksmų pradžioje;
• Neteisingas konfigūracijos objektų paskirties supratimas ir netinkamas jų naudojimas;
• Sistemai būdingas perteklius arba papildomai sukurtos spynos.

Kaip išspręsti užrakto konfliktą 1C 8.3

Sistemos pranešimas „užrakto konfliktas vykdant operaciją 1C 8.3“ neapibūdina konfigūracijos kaip netinkamai suplanuotos. Bet jei tokie signalai bus ignoruojami, tuomet yra tikimybė, kad pačiu svarbiausiu momentu, pavyzdžiui, teikdami ketvirtines ar metines ataskaitas, susidursite su didelėmis problemomis. Geriausiu atveju lėtėjanti sistema ir nepatenkinti vartotojai. Blogiausiu atveju neteisingi išvesties duomenys, dėl kurių reguliavimo institucijos gali skirti baudas.

Spynų konflikto 1C 8.3 problemos sprendimas gali būti konfigūracijos perkėlimas į valdomo (rankinio) užrakto valdymo režimą. Įdiegtas 8.1 versijoje, kompetentingų specialistų rankose esantis mechanizmas išsprendžia užrakto konfliktų problemą atliekant operacijas 1C.

Tačiau reikia nepamiršti, kad šis veiksmas sumažins duomenų apsaugos lygį nuo pokyčių, kai kiti vartotojai juos nuskaito. Todėl, jei nesate pasiruošę savarankiškai valdyti visų sistemos spynų, neskubėkite keisti konfigūracijos nustatymų.

Greitas 1C užrakto konflikto sprendimas

Administratoriaus ar kūrėjo darbe gali susiklostyti situacija, kai nėra laiko patikrinti klaidos ir surasti pagrindines problemos priežastis. Pavyzdžiui, iki tam tikro laiko reikia pateikti ataskaitą arba duomenis, o 1C blokavimo klaidos to neleidžia.

Yra du būdai greitai išspręsti problemą:

• Raskite ir užbaikite sesiją, kurios metu buvo užrakinti reikalingi duomenys. IN mažos įmonės, kur 1C vartotojų skaičius neviršija poros dešimčių žmonių, tai geriausias sprendimas;
• Jei valdote sistemą, kurioje dirba šimtai darbuotojų, tinkamo seanso paieška be specializuotos programinės įrangos gali užtrukti ilgai. Tokiu atveju daug efektyviau bus paleisti serverį iš naujo.

Šie sprendimai yra radikalūs ir skirti tik greitam problemos sprendimui ir duomenų paskelbimui skubiai pranešti. Jį galima panaikinti tik supratus priežastį, dėl kurios vykdant 1C operaciją kilo užrakto konfliktas. Po tokių veiksmų būtina rasti sistemos spragas, optimizuoti konfigūraciją ar darbuotojų darbą. Tokių priemonių nerekomenduojama naudoti nuolat, esant nuolatiniams sandorių blokavimo konfliktams.