1s 8.3 blokirovkasi mojarosini qanday tuzatish mumkin. Bloklash muammolarini qanday aniqladim. Ko'p sonli operatsiyalar bajarildi

1C da ishlaganda "Tranzaksiyalarni amalga oshirishda blokirovka to'qnashuvi: Qulfni berish uchun maksimal kutish vaqti oshib ketdi" xatosi paydo bo'lishi odatiy holdir. Uning mohiyati shundaki, bir nechta seanslar bir vaqtning o'zida bir xil resursga ta'sir qiladigan o'xshash harakatlarni bajarishga harakat qilmoqda. Bugun biz ushbu xatoni qanday tuzatishni aniqlaymiz.

Ko'p sonli operatsiyalar bajarildi

Sabablarni izlashda birinchi qadam, bunday xatolik yuzaga kelgan axborot bazasida bir vaqtning o'zida qancha foydalanuvchi borligini aniqlashdir. Ma'lumki, ularning maksimal soni juda katta bo'lishi mumkin. Bu ham ming, ham besh ming.

Bloklash va tranzaktsiyalar mexanizmi ishlab chiquvchining qo'llanmasida tasvirlangan. Ular bir vaqtning o'zida bir nechta seanslar bir xil ma'lumotlarga kirishda foydalaniladi. Bir xil ma'lumotlarni bir vaqtning o'zida turli foydalanuvchilar tomonidan o'zgartira olmasligi mantiqan.

Shuningdek, foydalanuvchilardan birortasi tomonidan ishlov berishni boshlagan yoki yo'qligini tekshirishingiz kerak katta o'zgarish ma'lumotlar. Bu oy oxiri va shunga o'xshash bo'lishi mumkin. Bunday holda, ishlov berish tugagandan so'ng, xato o'z-o'zidan yo'qoladi.

Rejalashtirilgan vazifalar

Katta hajmdagi ma'lumotlarni qayta ishlaydigan tizimda xatolik sababi yotishi odatiy hol emas. Kechasi bunday narsalarni qilish tavsiya etiladi. Bunday muntazam ishlarni ish vaqtidan tashqari bajarish uchun jadval tuzing.

Shunday qilib, foydalanuvchilar barqaror tizimda ishlaydi va odatiy vazifalarning o'zi muvaffaqiyatli bajariladi, chunki foydalanuvchi seanslari bilan ziddiyat ehtimoli kamayadi.

"Osilgan seanslar"

Foydalanuvchilarning "tiqilib qolgan seanslari" muammosi 1C xizmatiga duch kelgan deyarli har bir kishiga tanish. Foydalanuvchi dasturni ancha oldin tark etishi yoki hujjatni yopishi mumkin edi, lekin uning sessiyasi hali ham tizimda qolmoqda. Muammo ko'pincha izolyatsiya qilinadi va bunday seansni administrator konsoli orqali tugatish kifoya. Xuddi shu muammolar fon ishlarida paydo bo'lishi mumkin.

Internetdagi ko'plab sharhlarga ko'ra, bunday holatlar tarmoq xavfsizlik kalitlaridan foydalanganda tez-tez uchraydi. Agar "sessiyalarni muzlatish" bilan bog'liq vaziyat muntazam ravishda takrorlansa, bu tizim va serverlarni (agar ma'lumotlar bazasi mijoz-server bo'lsa) yaxshilab tekshirish va saqlash uchun sababdir.

Konfiguratsiyani yozishda xatolar

Barcha standart konfiguratsiyalar malakali mutaxassislar va mutaxassislar tomonidan ishlab chiqilgan. Har bir tizim to'liq sinovdan o'tgan va tezroq va to'g'ri ishlashi uchun optimallashtirilgan.

Shu munosabat bilan, xatoning sababi uchinchi tomon ishlab chiquvchisi tomonidan yozilgan suboptimal kodda bo'lishi mumkin. Bu uzoq vaqt davomida ma'lumotlarni bloklaydigan "og'ir" so'rov bo'lishi mumkin. Bundan tashqari, past unumdorlik va mantiq buzilishi bilan algoritmlarni qurish holatlari tez-tez uchrab turadi.

Qulflash mojarosi dasturni yangilagandan so'ng paydo bo'lgan ishlab chiquvchi xatolari tufayli yuzaga kelishi ehtimoli yuqori. Tekshirish uchun siz shunchaki yaxshilanishlarni "orqaga qaytarishingiz" yoki kodni qayta tiklashingiz mumkin.

1C-da qulflar nima, ular nima uchun kerak va ular bilan ishlashda muammolardan qanday qochish kerak

Albatta, ko'pchiligingiz foydalanayotganingizda axborot tizimlari 1C Enterprise (1C 7.7, 1C 8.1, 1C 8.2, 1C 8.3) blokirovka qilish kabi hodisaga duch keldi. Bundan tashqari, qoida tariqasida, har bir kishi bu hodisani boshqacha chaqiradi: "1C blokirovkasi", "1C blokirovkasi to'qnashuvi", "1C blokirovkasi xatolari", "1C tranzaksiyani blokirovka qilish" va boshqa nomlar. Keling, qulflar nima ekanligini (o'lik emas), nima uchun kerakligini va ular bilan ishlashda muammolardan qanday qochish kerakligini ko'rib chiqaylik.


Qulflarning o'zi (shu jumladan 1C va boshqa tizimlarda) umumiy resurslar bilan doimiy ishlash qobiliyatini ta'minlaydigan foydali vositadir. Misol uchun, "umumiy resurslar" tushunchasi bizni hayot davomida o'rab oladi, masalan, siz mashinani boshqarayotganingizda, uni boshqa hech kim boshqara olmaydi. Shuning uchun, mashina umumiy manba hisoblanadi. Va ikkinchi haydovchi siz kelguningizcha kutadi, masalan, xotiningiz / eringiz. Ikkalangiz ham umumiy resurs - avtomobil uchun raqobatlashasiz. Mashinani kim boshqaradi hozirgi moment Siz kontseptual darajada aniqlaysiz, biz qanday bo'lishimiz kerak avtomatlashtirilgan tizimlar??? Shuning uchun biz vositani o'ylab topdik blokirovka qilish, ular umumiy manbaga kirish jarayonini tashkil qilishni ta'minlaydi va navbatni belgilaydi. Qoida tariqasida, hayotda, axborot tizimlarida bo'lgani kabi (1C 7.7, 1C 8.1, 1C 8.2, 1C 8.3) juda ko'p umumiy resurslar mavjud, shuning uchun blokirovkalar ham ko'p. Endi ikkinchisi muhim nuqta- xotiningiz / eringiz mashinangizning chiqarilishini qancha vaqt kutadi, bu abadiy davom etmaydi deb taxmin qilish mantiqan? Shuning uchun qulflarga vaqt tugashi chegarasi beriladi - aks holda vaqt tugashi vaqti deb nomlanadi. Taymout - raqobatchi ishtirokchi (xotiningiz/eringiz) umumiy resurs bo'shatilguncha kutishning maksimal vaqti. Keyin yoki u bir xil vaqtni kutishda davom etadi, yoki u yuradi. 1C axborot tizimlarida kutish vaqtining tugashi "1C blokirovkasi to'qnashuvi", "1C blokirovkasidagi xatolar", "1C tranzaksiya blokirovkalari", "Qulflashda vaqt tugashi" xabari bilan tugaydi.

Esda tutish kerak bo'lgan muhim tafsilot shundaki, qulflar (xususan, 1C-da) aniq (foydalanuvchi tomonidan o'rnatiladi) va yashirin (SQL platformasi tomonidan o'rnatiladi) bo'lishi mumkin. Maqolada biz aniq qulflar haqida gapiramiz, shuning uchun ular har doim tranzaksiyada qo'llaniladi, shuning uchun "1C Bloklash" va "1C Tranzaksiyani Bloklash" sinonimlar ekanligi ma'lum bo'ldi.

Biz qaror qildikki, agar kutish vaqti oshib ketgan bo'lsa, foydalanuvchi u uchun xato xabari oladi, kutish jarayonining o'zi 1C axborot tizimining ekrani tiqilib qolganga o'xshaydi. Vaqt tugashi haqida xabar paydo bo'lish ehtimoli (1C foydalanuvchi xatosi) quyidagi ko'rsatkichlarga ta'sir qiladi:

  • Tranzaksiyada ko'plab 1C qulflari;
  • Tranzaktsiya muddati.

Bloklash xatolari bilan bog'liq xabarlarni minimallashtirish uchun qulflar sonini kamaytirish (tanlab olishni optimallashtirish) yoki tranzaktsiyalar davomiyligini qisqartirish kerak.
Keling, ushbu ko'rsatkichlarga haqiqiy 1C axborot tizimida qanday ta'sir qilish mumkinligini aniqlaylik.

Ko'p blokirovkalarni kamaytirish uchun:

1C: Enterprise 7.7 da:

Axborot tizimi 1C 7.7. Qulflash uchun stol qulflari qo'llaniladi, bu esa foydalanuvchilarning ishini falaj qiladi. Qoidaga ko'ra, bitta ma'lumotlar bazasida 50 dan ortiq odam xatosiz ishlay olmaydi va muammolar 20 foydalanuvchining ma'lumotlar bazalarida ham paydo bo'lishi mumkin.
Yechim:

  • Softpoint kompaniyasidan 1C moslashuvchan qulflar. Ularning yordami bilan siz nafaqat ko'plab qulflarni optimallashtirasiz (stol qulflarini foydalanuvchi qulflari bilan almashtirish), balki tanlovlar, qidiruvlar va hisobotlarni tezlashtirasiz.
1C: Enterprise 8.x da:
Axborot tizimi 1C 8.1., 1C 8.2., 1C 8.3. avtomatik rejimda u turdagi ortiqcha qulflardan foydalanadi (REPEATABLEREAD, SERIALIZABLE). Bu 100 yoki undan ortiq foydalanuvchi tajribasining yomonlashishiga olib keladi.
Yechim:
  • Boshqariladigan qulflar 1C - qulflarni yanada tanlab konfiguratsiya qilish uchun 1C platformasining o'rnatilgan vositasi. Undan foydalanish uchun dasturchi kodning kerakli joylariga kerakli operatorlarni bloklash uchun maxsus operatorlarni yozishi kerak ( uning fikricha!) axborot tizimi jadvallaridagi yozuvlar;
  • Moslashuvchan qulflar 1C - Standart qulflarni maxsus qulflarga almashtirish uchun Softpoint texnologiyasi.

Tranzaksiya vaqtini qisqartirish uchun:

Har qanday 1C axborot tizimlari uchun (1C 7.7., 1C 8.1, 1C 8.2, 1C 8.3) boshqa axborot tizimlarida bo'lgani kabi, shunga o'xshash yondashuvlar qo'llaniladi:

    Tekshiring va to'g'ri sozlash ma'lumotlar bazasiga muntazam texnik xizmat ko'rsatish (fayllar, indekslar, statistik ma'lumotlar, vaqtinchalik jadval ma'lumotlar bazalari, Windows va SQLServerni sozlash);

    Og'ir 1C va SQL so'rovlarini tahlil qilish va optimallashtirish (indeksni sozlash, so'rovlarni qayta yozish);

    Tranzaksiyaning ortiqchaligini tekshirish. Ko'pgina hollarda, bu muddatga va u bilan birga ishlashga qanday ta'sir qilishini tushunmasdan, operatsiyalar bitimga asossiz ravishda kiritiladi.

  1. Agar siz 1C (1C 7.7, 1C 8.1, 1C 8.2, 1C 8.3) va boshqa axborot tizimlarining texnik ishlashi bilan bog'liq muammolarni mustaqil ravishda hal qilmoqchi bo'lsangiz. , keyin siz uchun bizning Almanakimizdagi texnik maqolalarning noyob ro'yxati mavjud (Blokirovka va blokirovkalar, protsessor va disklardagi og'ir yuk, ma'lumotlar bazasiga texnik xizmat ko'rsatish va indekslarni sozlash - bu siz u erda topadigan texnik materiallarning kichik bir qismi).
  2. Agar siz bizning mutaxassisimiz bilan ishlash masalalarini muhokama qilmoqchi bo'lsangiz yoki PerfExpert ish faoliyatini nazorat qilish yechimiga buyurtma bermoqchi bo'lsangiz, keyin so'rov qoldiring va biz imkon qadar tezroq siz bilan bog'lanamiz.

Hammaga salom!

Boshqa kuni ish joyida men qulflash muammosiga duch keldim, ya'ni "Tranzaksiyani amalga oshirishda blokirovka mavjud. Qulfni berish uchun maksimal kutish vaqti oshib ketdi".

Shubhasiz, bu erda hech qanday o'lik muammosi yo'q, faqat ba'zi bir seans qulfni qo'ydi va uni olib tashlashni "unutdi". Shu bilan birga, muammo jiddiy oqibatlarga olib kelishi bilan tahdid qildi - hujjat Tovar va xizmatlarni sotish amalga oshirilmadi. Ma'lumotlar bazasida bir vaqtning o'zida 100 ga yaqin odam ishlaydi va odatiy va tez-tez operatsiyani bajarish mumkin emas!

Ikkita yechim bor edi - serverni qayta ishga tushiring yoki muvaffaqiyatsiz seansni qidiring. Birinchi yechim oddiy va tez, lekin kimdir bu yerda yozganidek, siz ishdan bo'shatilguningizcha serverni qayta ishga tushirishingiz mumkin. Men ikkinchi yo'lni tanlashga qaror qildim.

Birinchi kun - muammo kun davomida paydo bo'ldi, dastlab muammo Konfiguratorga kirgan masofaviy foydalanuvchi bilan bog'liq edi. Qatl shunchaki bir nuqtada to'xtaganga o'xshaydi va blokirovka, albatta, olib tashlanmadi. Bir necha soatdan keyin biz konfiguratorni bo'shatishga muvaffaq bo'ldik, ammo muammo hal qilinmadi. Konfiguratorni majburan o'ldirish juda istalmagan edi, ehtimol ular unda ishlagan. Shundan so'ng Google o'yinga kirdi. Men ushbu saytda MS SQL DBMSda qulflarni qanday topish mumkinligi haqida maqola topdim, tekshirildi, DBMS darajasida hech qanday qulf yo'q edi. G'alati. Keyinchalik texnologiyani o'rnatishga urinishlar bo'ldi. jurnali. Sozlang, keyin nima bo'ladi? 15 daqiqadan so'ng, bir nechta gig loglar! Ularni qanday o'qish kerak, nimani izlash kerak? Noma'lum.

Men SQL Trace yordamida nima bloklanganligini qanday ko'rish haqida maqola topdim. Agar topsam ham, keyin nima bo'ladi? Menga seans kerak!

Soat 16:00 ga yaqinroq, endi kuta olmasligimni anglab, qayta ishga tushirdim. Bu boshqa takrorlanmasligiga umid qilib (va bu olti oylik ishda birinchi marta edi), men yengil nafas oldim, hammasi ishladi. Lekin behuda... Ikkinchi kun - xuddi shunday holat. Men bir yarim soat qazdim, yana googlega tushunarsiz urinishlar va hokazo. Natija yoʻq. Qayta ishga tushirish. Kun oxirida bu yana sodir bo'ldi. Xo'sh, menimcha, bu juda yaxshi, men xotirjamlik bilan uyga kelaman va o'tiraman va chuqurroq qazaman. Men uyga keldim, hammasi yaxshi. Afsuski.

Uchinchi kuni men vebinarni tomosha qildim, ular qiziqarli va haqida gaplashdilar samarali usul muammo izlash. Men esladim, lekin muammo yana paydo bo'lmadi. Bir hafta o'tdi va mana - yana blokirovkalar! Men qo'llarimni ishqalayman va harakat qilishni boshlayman.

Birinchidan, jurnalni o'rnating. Ha, men usiz qilolmayman, lekin endi uni qanday o'qishni bilaman. Biz ikkita hodisani o'rnatdik: birinchisi - TLOCK, ikkinchisi - TTIMEOUT. Birinchisi barcha bloklash hodisalarini ko'rsatadi, ikkinchisi ajratilgan vaqt ichida o'rnatib bo'lmaydigan blokirovkalash hodisalarini ko'rsatadi. Aslida, TTIMEOUT kifoya qiladi.



















Biz texnik jurnal faylini belgilangan joyga ko'chiramiz, dasturga uchamiz, qulfni chaqiramiz, xabar olamiz va texnik jurnal faylini olib tashlaymiz yoki nomini o'zgartiramiz. Bizga boshqa blokirovkalar haqida ko'p ma'lumot kerak emas!

Rphost_PID jildiga o'ting, matnli fayllarni toping va TTIMEOUT so'zini qidiring. Biz chiziqni ko'ramiz:

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=*********,Kutish ulanishlari=8239

Aytgancha, bir nechta rphost_PID papkalari bo'lishi mumkin, barchasi serverda qancha ishchi jarayonlar ishlayotganiga bog'liq.

Va keyin hamma narsa oddiy: chiziqning oxiriga qarang - WaitConnections = 8239, bu bizning CONNECTION raqamimiz. Biz server konsoliga o'tamiz, Connections-ga o'tamiz, ushbu raqamni topamiz va sessiya raqamiga qaraymiz. Mening holatimda, har bir foydalanuvchi uchun ikkita seans bor edi - muvaffaqiyatsiz va boshqasi. Texnik jurnal ko'rsatayotgan sessiya ishlamay qoldi. Va mana, qarang! Hammasi ishladi, quvonch chegara bilmaydi! Ammo, keyinroq ma'lum bo'lishicha, sessiya muzlatilmagan :), ular unda ishlashgan. Shuning uchun kelajakda foydalanuvchi bilan bog'lanish va ogohlantirish tavsiya etiladi.

Menimcha, juda standart muammoga nisbatan standart yechim. Nega men buni uchratmaganim noma'lum, ehtimol men uni xavotirdan izlashim kerak edi va foydalanuvchilar uni bosmaganida, testlarni o'tkazishning iloji bo'lmadi - hech qanday xatolik yo'q edi.

Yuzlab foydalanuvchilar bir vaqtning o'zida dasturlar va ma'lumotlar bilan ishlaganda, faqat keng ko'lamli echimlarga xos bo'lgan muammolar paydo bo'ladi. Biz ma'lumotlarni blokirovka qilishdan kelib chiqadigan muammolar haqida gapiramiz.

Ba'zan foydalanuvchilar ma'lumotlarni yoza olmasligi yoki boshqa amallarni bajara olmasligini bildiruvchi xabarlardan blokirovka qilish haqida bilib oladi. Ba'zan dastur ishlashining juda sezilarli pasayishi tufayli (masalan, operatsiyani bajarish uchun zarur bo'lgan vaqt o'nlab yoki yuzlab marta oshganida).

Bloklashdan kelib chiqadigan muammolar mavjud emas umumiy yechim. Shuning uchun biz bunday muammolarning sabablarini tahlil qilishga va ularni hal qilish variantlarini tizimlashtirishga harakat qilamiz.

OMONLARNI BLOKLASH SABABLARI

Keling, avval qulflar nima ekanligini eslaylik va shu bilan birga ular kerak yoki yo'qligini aniqlaylik. Keling, hayotda duch keladigan blokirovkalarning bir nechta klassik misollarini ko'rib chiqaylik.

1-misol: samolyot yoki poezd chiptasini sotib olish. Aytaylik, biz o'z tilaklarimizni kassirga aytdik. Kassir bizga mavjud o'rindiqlar mavjudligini aytadi, ular orasidan o'zimizga yoqqanini tanlashimiz mumkin (agar ular bir nechta bo'lsa, albatta). Biz taklif qilingan variant bilan kelishuvimizni tanlab, tasdiqlasak ham, bu o'rindiqlarni boshqa hech kimga sotish mumkin emas, ya'ni. vaqtinchalik "bloklangan". Agar ular bloklanmagan bo'lsa, tasdiqlash vaqtida biz tanlagan chiptalar allaqachon sotilgan bo'lishi mumkin. Va bu holda, tanlov tsikli oldindan aytib bo'lmaydigan takroriy songa ega bo'lishi mumkin. Biz joylarni tanlayotganimizda, ular allaqachon sotilgan!.. Biz boshqalarni tanlayotganimizda, ular endi yo‘q...

2-misol: do'konda yoki bozorda biror narsa sotib olish. Biz peshtaxtaga yaqinlashdik va mavjud bo'lgan yuzlab olma orasidan eng chiroyli olmani tanladik. Ular buni tanladilar va pul olish uchun cho'ntaklariga qo'llarini qo'yishdi. Agar o'sha paytda biz pul sanab o'tirganimizda, tanlagan olma bizdan kech kelgan xaridorga sotilsa, qanday ko'rinishga ega bo'ladi?

Shunday qilib, blokirovkaning o'zi zarur va foydali hodisadir. Bloklash tufayli biz harakatlar bir bosqichda bajarilishini kafolatlaymiz. Va ko'pincha bu salbiyga olib keladigan eng muvaffaqiyatli amalga oshirish emas. dasturiy ta'minot qachon, masalan:

  • haddan tashqari ko'p miqdordagi ob'ektlar (chiptalar, olmalar) bloklangan;
  • Bloklash muddati asossiz ravishda uzaytirilgan.

ODAM 1C KONFIGURASYONLARIDA ORTA BLOKLASH

Yoniq yirik loyihalar, qoida tariqasida, biz 1C: Enterprise dan foydalanamiz. Shunung uchun amaliy tavsiyalar Biz 1C: Enterprise + MS-SQL kombinatsiyasi misolidan foydalanib, muammolarni blokirovka qilishning echimlarini tasvirlashga harakat qilamiz.

8-avlod 1C: Enterprise foydalanishning juda va juda yaxshi parallelligini ta'minlaydi. Oddiy serverlar va aloqa kanallari bilan bir vaqtning o'zida bitta konfiguratsiya (ya'ni bitta bazada) bilan ishlashi mumkin katta miqdor foydalanuvchilar. Masalan, yuzlab do'kondorlar tovarlarni berish yoki qabul qilishni qayta ishlaydilar, iqtisodchilar bir vaqtning o'zida turli bo'limlar uchun mehnat xarajatlarini hisoblab chiqadilar, buxgalterlar hisob-kitoblarni va ish haqini to'lashni amalga oshiradilar va hokazo.

Ammo buning teskari fikrining sababi bor - bir vaqtning o'zida intensiv foydalanish bilan 1C: Enterprise asosidagi echimlar bilan ishlash noqulay yoki imkonsiz degan afsona. Axir, 1C: Enterprise uchun standart echimlar yuzlab foydalanuvchilar tomonidan qo'llanila boshlaganda. sanoat miqyosi, tez-tez ekranda g'ururli yozuv bilan oyna paydo bo'ladi: "Kontekst usulini chaqirishda xatolik (Yozish): Tranzaktsiyani bajarishda blokirovkalash ziddiyatlari: ..." va keyin ishlatiladigan SQL server turiga qarab, “SQL Server uchun Microsoft OLE maʼlumotlar bazasi provayderi: blokirovka soʻrovi muddatidan oshib ketdi. ...".

Taklif etilayotgan dasturda deyarli barcha standart echimlar avtomatik qulfni boshqarish uchun tuzilgan. Bu erda "avtomatik" "paranoyak" sifatida qabul qilinishi mumkin. Har qanday hujjatni qayta ishlashda biz u bilan qandaydir bog'liq bo'lishi mumkin bo'lgan hamma narsani blokirovka qilamiz. Shunday qilib, ma'lum bo'lishicha, bitta foydalanuvchi biror narsa qilganda (va ba'zan shunchaki yozsa), qolganlari faqat kutishlari mumkin.

Nima uchun 1C yuqori parallel foydalanish uchun standart echimlarini sozlamaslikka qaror qilganligi haqida o'z fikrimni bildiraman. Bunday o'zgartirish uchun ish haqi unchalik yuqori emas - bir necha "odam oyi", bu 1C shkalasida ahamiyatli emas. Menimcha, buning sababi boshqacha.

Birinchidan, bunday o'zgartirish barcha hujjatlarni qayta ishlashni sezilarli darajada murakkablashtiradi. Bu shuni anglatadiki, 1C-ni kichik vazifalar uchun ishlatadigan iste'molchilar uchun hech qanday foydasiz faqat kamchilik bo'ladi - standart konfiguratsiyani o'zgartirish qiyinligi yanada murakkablashadi. Statistik ma'lumotlar bir vaqtning o'zida mijozlarning qaysi toifasi 1C uchun asosiy oziqlantirishni taklif qiladi ...

Ikkinchi sabab SQL serverlarining odatiy asosiy sozlamalarida ko'milgan, masalan, MS-SQL, hali ham boshqalarga qaraganda tez-tez ishlatiladi. Shunday bo'ladiki, sozlamalardagi ustuvorliklar saqlashga beriladi Ram bloklashni kamaytirish o'rniga serverlar. Bu shuni anglatadiki, agar bir nechta qatorlarni blokirovka qilish kerak bo'lsa, SQL server "xotira va protsessorni tejash" qarorini qabul qiladi - bir vaqtning o'zida butun jadvalni blokirovka qilish!..

Bu kamchiliklar standart echimlar yoki ishlatiladigan ma'lumotlar bazasi serverini o'rnatishning o'ziga xos xususiyatlari ko'pincha blokirovkadan kelib chiqadigan muammolar bilan aniqlanadi. Natijada, texnik kamchiliklar juda sezilarli darajada olib keladi tashkiliy muammolar. Axir, agar xodimga ishdan chalg'itishi yoki nima uchun ish bajarilmasligini oqlash uchun sabab berilsa, ozchilik samarali ishlaydi. Xo'sh, tranzaktsiyalarni blokirovka qilish yoki "tormozlash" dasturi haqidagi xabar nima uchun biror narsa qilish mumkin emasligi uchun ideal asosdir.

1C: ENTERPRISE UCHUN ORTA TO'LOVLARNI KECHISH BO'YICHA TAVSIYALAR

Haddan tashqari qulflash muammolarini hal qilish juda muhim bo'lsa, nima qilish kerak?

Hammasini amalga oshirishning yakuniy bosqichida katta komplekslar keraksiz tranzaksiya blokirovkasini bartaraf etish uchun nozik sozlashni amalga oshirish kerak. Bloklash shartlari yoki amalga oshirish usullari yetarlicha ishlab chiqilmaganligi sababli yuzaga kelishi mumkin bo'lgan muammolarni hal qilish juda muhimdir.

Chunki Ushbu operatsiya juda muhim va doimiy ravishda bajarilishi kerak. Shuning uchun, bunday o'zgartirishlarni soddalashtirish uchun biz bir qator asosiy tavsiyalarni ishlab chiqdik, ularga rioya qilishga harakat qilamiz. Tavsiyalar ko'p sonli keng ko'lamli amalga oshirish tajribasidan olingan va sinovdan o'tgan.

  1. Agar siz foydalanayotgan DBMS yoki ishlab chiqish tizimi (masalan, 1C: Enterprise) sukut bo'yicha ma'lumotlarni avtomatik blokirovka qilish rejimidan foydalansa, avtomatik blokirovkani boshqarishni rad eting. Bloklash qoidalarini o'zingiz sozlang, butun jadvallar yoki alohida satrlarni blokirovka qilish mezonlarini tavsiflang.
  2. Dasturni ishlab chiqishda, iloji bo'lsa, jadvallarga bir xil tartibda kiring.
  3. Bitta tranzaksiya doirasida bir jadvalga bir necha marta yozmaslikka harakat qiling. Agar bu qiyin bo'lsa, hech bo'lmaganda birinchi va oxirgi yozish jarayoni orasidagi vaqt oralig'ini minimallashtiring.
  4. SQL server darajasida blokirovkaning kuchayishini o'chirib qo'yish imkoniyatini tahlil qiling.
  5. Foydalanuvchilarga, agar ular blokirovka qilingan bo'lsa, nima uchun hech qanday harakat qila olmasligi sabablari haqida aniq ma'lumot bering. Keyinchalik nima qilish kerakligi haqida tushunarli va tushunarli tavsiyalar bering.

Agar siz tavsiyalarga diqqat bilan qarasangiz, bu aniq bo'ladi bunday test nafaqat 1C: Enterprise, balki har qanday tizimlar uchun mos keladi. Ular qaysi tilda yozilganligi va qaysi ma'lumotlar bazasi serveri bilan ishlashi muhim emas. Tavsiyalarning aksariyati tabiatan universaldir va shuning uchun 1C: Enterprise-dan foydalanganda va "uyda yozilgan" dasturlar yoki boshqa "qutili" ERP tizimlari uchun bir xil darajada amal qiladi.

P.S. 1C dasturiy ta'minotini yangilash bo'yicha professional yordam taklif qilishimizni bilasizmi? eng yaxshi narx?

Qidiriladigan teglar:
  • Tranzaksiya bloklari
  • Bloklarni olib tashlash
  • 1C qulflari
  • Qulflash
  • Mojaroni qulflash
  • Tranzaksiya paytida bahsni bloklash

Ko'p foydalanuvchili tizimlarda muhim rol o'ynaydi to'g'ri tashkil etish tuzilmalar va qulflarni o'rnatish. Agar u mavjud bo'lmasa, foydalanuvchilar ko'pincha ma'lum tizim resurslari uchun raqobat tufayli yuzaga kelgan xatolar bilan shug'ullanishlari kerak. Ammo ko'plab foydalanuvchilarga tanish bo'lgan qulflash to'qnashuvi muammosi mavjud. Nima uchun 1C blokirovkasi mojarosi paydo bo'ladi va uni qanday hal qilish kerak?

1C 8.3 da qulflash ziddiyati va uning ma'nosi

Aksariyat foydalanuvchilar uchun 1C blokirovkasi to'qnashuvi haqidagi xabar faqat o'z ishlarini bajarishga to'sqinlik qiladigan xatoni anglatadi. Ular imkon qadar tezroq bu muammodan xalos bo'lishni va IT bo'limini "1C ishlamayapti" degan shikoyatlar bilan qamal qilishni xohlashadi.

Ammo tizim ma'murlari va ishlab chiquvchilari uchun bunday xabar konfiguratsiya tuzilishida muammolar bo'lishi mumkinligini ko'rsatadi. Foydalanuvchilarni xursand qilishga va blokirovkalarni olib tashlashga harakat qilishdan oldin, siz vaziyatni tahlil qilishingiz va xato xabari sababini tushunishingiz kerak.

1C da xatolarni blokirovka qilish sabablari

Ko'rgazmali yuk testi 1C serveri besh mingdan ortiq foydalanuvchilarning parallel ishlashiga bardosh bera olishini ko'rsatadi. Ammo bunday tajribalar uchun ideal sharoitlar yirik va o'rta kompaniyalarning kundalik sharoitida erishib bo'lmaydi. Xuddi shunday ishlash va xatosiz ishlashga erishish uchun konfiguratsiya ideal tarzda ishlab chiqilgan va korxonaning o'ziga xos biznes jarayonlariga moslashtirilgan bo'lishi kerak.

Agar siz ideal variantlarni qabul qilmasangiz, 1C blokirovkasi quyidagi sabablarga ko'ra yuzaga keladi:

Foydalanuvchilarning katta hajmdagi ma'lumotlar bilan bir vaqtda ishlashi. Ushbu asosiy sabab 1C ning ichki mexanizmlari bilan belgilanadi. Ular boshqa foydalanuvchi nomidan boshlangan tranzaksiyaga aloqador ma'lumotlarni o'zgartirishni taqiqlashni o'z ichiga oladi;

Konfiguratsiyadagi xatolar va kamchiliklar. 1C kompaniyasining standart echimlari tarkibi samaradorlikni oshirish bo'yicha tavsiyalarni hisobga oladi. Ammo uchinchi tomon ishlab chiquvchilari har doim ham yuqori standartlarga rioya qilmaydilar va ko'pincha ularning kodlarida quyidagi kamchiliklarni topish mumkin:

  • Suboptimal so'rovlar;
  • Harakatlar boshida balansni so'rash;
  • Konfiguratsiya ob'ektlarining maqsadini noto'g'ri tushunish va ulardan noto'g'ri foydalanish;
  • Tizimga o'rnatilgan yoki qo'shimcha ravishda ishlab chiqilgan blokirovkalarning ortiqcha.

1C 8.3 da blokirovka mojarosini qanday tuzatish mumkin

Tizim xabari "1C 8.3 tranzaksiyasini bajarishda blokirovkalash ziddiyati" konfiguratsiyani noto'g'ri ishlab chiqilgan deb tavsiflamaydi. Ammo agar bunday signallarga e'tibor berilmasa, unda eng muhim daqiqada, masalan, har chorakda yoki yillik hisobotlar katta muammoga duch keling. Eng yaxshi holatda, sust tizim va norozi foydalanuvchilar. Eng yomoni, chiqish ma'lumotlari noto'g'ri, bu esa nazorat qiluvchi organlar tomonidan jarimaga olib kelishi mumkin.

1C 8.3-da blokirovkalar to'qnashuvi muammosini hal qilish konfiguratsiyani boshqariladigan (qo'lda) qulfni boshqarish rejimiga o'tkazish bo'lishi mumkin. 8.1 versiyasida amalga oshirilgan, vakolatli mutaxassislar qo'lidagi mexanizm 1C-da tranzaksiya paytida blokirovkalash to'qnashuvlari muammosini hal qiladi.


Ammo shuni yodda tutish kerakki, ushbu harakat boshqa foydalanuvchilar tomonidan o'qilishi paytida ma'lumotlarni o'zgarishlardan himoya qilish darajasini pasaytiradi. Shuning uchun, agar siz tizimdagi barcha qulflarni mustaqil ravishda boshqarishga tayyor bo'lmasangiz, konfiguratsiya sozlamalarini o'zgartirishga shoshilmang.

1C qulflash mojarosiga tezkor yechim

Administrator yoki ishlab chiquvchining ishida xatoni tekshirish va muammoning asosiy sabablarini izlash uchun vaqt yo'q bo'lganda vaziyat yuzaga kelishi mumkin. Masalan, ma'lum bir vaqtga qadar hisobot topshirish yoki ma'lumotlarni taqdim etish kerak, ammo 1C blokirovkalash xatolar bunga to'sqinlik qiladi.

Muammoni tezda hal qilishning ikki yo'li mavjud:

  • Kerakli ma'lumotlarni bloklaydigan seansni toping va tugating. IN kichik kompaniyalar, bu erda 1C foydalanuvchilari soni bir necha o'nlab odamlardan oshmasa, bu eng maqbul echimdir;
  • Agar siz yuzlab xodimlarga ega tizimni boshqarsangiz, maxsus dasturiy ta'minotsiz to'g'ri sessiyani topish uzoq vaqt talab qilishi mumkin. Bunday holda, serverni qayta ishga tushirish ancha samarali bo'ladi.

Ushbu echimlar radikaldir va faqat muammoni tezda hal qilishga va shoshilinch hisobot uchun ma'lumotlarni bo'shatishga qaratilgan. Buni faqat 1C tranzaktsiyasini amalga oshirishda qulflash mojarosining sababini tushunish orqali yo'q qilish mumkin. Bunday harakatlardan so'ng tizimdagi zaifliklarni topish, konfiguratsiyani yoki xodimlarning ishini optimallashtirish kerak. Tranzaktsiyalar bo'yicha muntazam ravishda blokirovkalash to'qnashuvlari bo'lsa, bunday choralarni doimiy ravishda qo'llash tavsiya etilmaydi.




Yuqori