Bloklama problemlərini necə diaqnoz etdim. Kilid problemlərini necə diaqnoz etdim 1c əməliyyatı həyata keçirərkən səhv kilidi münaqişəsi

Paylanmış verilənlər bazasına köçürmək üçün dəyişiklikləri yaza bilmədim, 1c dəstəyi ilə əlaqə saxladım və aşağıdakıları təklif etdim. Mən sadəcə proqram serverini və serveri SQL ilə yenidən işə salmaq qərarına gəldim. Ümumiyyətlə, "Bloklama planlaşdırılır
tapşırıqlar daxildir"
Yenidən başlamadan da kömək etdi.

MS SQL Server üçün DBMS səviyyəsində planlaşdırılan əməliyyatlar

DBMS səviyyəsində gündəlik əməliyyatların yerinə yetirilməsi üçün təlimatlar.

Məlumat MS SQL Server DBMS-dən istifadə edərkən 1C: Enterprise 8-in müştəri-server versiyasına şamil edilir.

Ümumi məlumat

Sistemin qeyri-optimal işləməsinin ən ümumi səbəblərindən biri DBMS səviyyəsində rutin əməliyyatların düzgün və ya vaxtında yerinə yetirilməməsidir. Bu rutin prosedurların əhəmiyyətli yük altında işləyən və eyni zamanda çoxlu sayda istifadəçiyə xidmət göstərən böyük informasiya sistemlərində yerinə yetirilməsi xüsusilə vacibdir. Belə sistemlərin spesifikliyi ondan ibarətdir ki, DBMS tərəfindən avtomatik həyata keçirilən adi hərəkətlər (parametrlər əsasında) səmərəli işləmək üçün kifayət deyil.

Çalışan sistemdə performans problemlərinin hər hansı simptomları varsa, sistemin düzgün konfiqurasiya edildiyini və DBMS səviyyəsində müntəzəm olaraq tövsiyə olunan bütün texniki xidməti yerinə yetirdiyini yoxlamalısınız.

Rutin prosedurların icrası avtomatlaşdırılmalıdır. Bu əməliyyatları avtomatlaşdırmaq üçün MS SQL Serverin daxili alətlərindən istifadə etmək tövsiyə olunur: Maintenance Plan. Bu prosedurları avtomatlaşdırmağın başqa yolları da var. Bu məqalədə hər bir planlaşdırılan prosedur üçün MS SQL Server 2005 üçün Baxım Planından istifadə etməklə onun konfiqurasiya nümunəsi verilmişdir.

Bu rutin prosedurların həyata keçirilməsinin vaxtında və düzgünlüyünə mütəmadi olaraq nəzarət etmək tövsiyə olunur.

Statistika yeniləməsi

MS SQL Server indekslərdə və cədvəllərdə dəyərlərin paylanması haqqında statistik məlumatlara əsaslanan sorğu planı qurur. Statistik məlumat verilənlərin bir hissəsi (nümunəsi) əsasında toplanır və bu məlumatlar dəyişdikdə avtomatik olaraq yenilənir. Bəzən bu, MS SQL Serverin bütün sorğuları yerinə yetirmək üçün ardıcıl olaraq ən optimal planı qurmaq üçün kifayət etmir.

Bu halda sorğunun icrası ilə bağlı problemlər yarana bilər. Eyni zamanda, sorğu planlarında qeyri-optimal işin (qeyri-optimal əməliyyatların) xarakterik əlamətləri müşahidə olunur.

MS SQL Server optimallaşdırıcısının ən düzgün işləməsini təmin etmək üçün MS SQL verilənlər bazası statistikasını mütəmadi olaraq yeniləmək tövsiyə olunur.

Bütün verilənlər bazası cədvəlləri üçün statistikanı yeniləmək üçün aşağıdakı SQL sorğusunu yerinə yetirməlisiniz:

exec sp_msforeachtable N"STATİSTİKALARI YENİLƏNİB? FULLSCAN İLƏ"

Statistikanın yenilənməsi masaların kilidlənməsinə səbəb olmur və digər istifadəçilərin işinə mane olmayacaq. Statistika lazım olduğu qədər yenilənə bilər. Nəzərə alın ki, statistik məlumatların yenilənməsi zamanı DBMS serverində yük artacaq və bu, sistemin ümumi işinə mənfi təsir göstərə bilər.

Optimal statistika yeniləmə tezliyi sistemə düşən yükün miqyasından və xarakterindən asılıdır və eksperimental olaraq müəyyən edilir. Statistikanı yeniləmək tövsiyə olunur gündə ən azı bir dəfə.

Yuxarıdakı sorğu verilənlər bazasındakı bütün cədvəllər üçün statistikanı yeniləyir. Real həyat sistemində müxtəlif cədvəllər müxtəlif statistik yeniləmə dərəcələrini tələb edir. Sorğu planlarını təhlil etməklə siz hansı cədvəllərin statistikanın ən tez-tez yenilənməsinə ehtiyac duyduğunu müəyyən edə və iki (və ya daha çox) müxtəlif rutin prosedurlar qura bilərsiniz: tez-tez yenilənən cədvəllər və bütün digər cədvəllər üçün. Bu yanaşma statistikanın yenilənmə vaxtını və statistik məlumatların yenilənməsi prosesinin bütövlükdə sistemin işinə təsirini əhəmiyyətli dərəcədə azaldacaq.

Avtomatik statistika yeniləməsinin konfiqurasiyası (MS SQL 2005)

MS SQL Server Management Studio proqramını işə salın və DBMS serverinə qoşulun. İdarəetmə qovluğunu açın və yeni texniki xidmət planı yaradın:

Alt plan yaradın (Alt plan əlavə et) və onu "Statistika yeniləməsi" adlandırın. Yeniləmə Statistika Tapşırığını ona tapşırıq çubuğundan əlavə edin:

Statistika yeniləmə cədvəli qurun. Statistikanı gündə ən azı bir dəfə yeniləmək tövsiyə olunur. Lazım gələrsə, statistikanın yenilənmə tezliyi artırıla bilər.

Tapşırıq parametrlərini təyin edin. Bunu etmək üçün pəncərənin aşağı sağ küncündə tapşırığın üzərinə iki dəfə klikləyin. Görünən formada statistikanın yenilənəcəyi verilənlər bazasının (və ya bir neçə verilənlər bazasının) adını göstərin. Bundan əlavə, siz hansı cədvəllər üçün statistik məlumatların yenilənməsini təyin edə bilərsiniz (hansı cədvəlləri dəqiqləşdirməli olduğunuzu bilmirsinizsə, dəyəri Hamısı olaraq təyin edin).

Statistikanın yenilənməsi Tam Skan seçimi aktiv edilməklə aparılmalıdır.

Yaradılmış planı yadda saxlayın. Cədvəldə göstərilən vaxt gəldikdə, statistika avtomatik olaraq yenilənəcəkdir.

Prosedur keşinin təmizlənməsi

MS SQL Server optimallaşdırıcısı təkrar icra üçün sorğu planlarını keşləyir. Bu, eyni sorğu artıq yerinə yetirilibsə və onun planı məlumdursa, sorğunun tərtib edilməsinə sərf olunan vaxta qənaət etmək üçün edilir.

Ola bilər ki, MS SQL Server köhnəlmiş statistik məlumatlara əsaslanaraq, qeyri-optimal sorğu planı qursun. Bu plan prosedur keşində saxlanacaq və eyni sorğu yenidən çağırıldıqda istifadə olunacaq. Statistikanı yeniləmisinizsə, lakin prosedur keşini təmizləməmisinizsə, SQL Server yeni (daha yaxşı) plan qurmaq əvəzinə keşdən köhnə (optimal olmayan) sorğu planını seçə bilər.

MS SQL Serverin prosedur keşini təmizləmək üçün aşağıdakı SQL sorğusunu yerinə yetirməlisiniz:

Bu sorğu statistika yeniləndikdən dərhal sonra icra edilməlidir. Müvafiq olaraq, onun icra tezliyi statistik məlumatların yenilənməsi tezliyinə uyğun olmalıdır.

Prosedur Keşinin Təmizlənməsinin Konfiqurasiyası (MS SQL 2005)

Statistikanın hər dəfə yenilənməsi zamanı prosedur keşinin təmizlənməsi tələb olunduğu üçün bu əməliyyatı artıq yaradılmış “Statistikanı yenilə” alt planına əlavə etmək tövsiyə olunur. Bunun üçün alt planı açın və onun sxeminə Execute T-SQL Statement Task-ı əlavə edin. Sonra yeni tapşırığa ox ilə Statistika Yeniləmə Tapşırığını bağlamalısınız.

Yaradılmış Execute T-SQL Statement Task mətnində siz "DBCC FREEPROCCACHE" sorğusunu göstərməlisiniz:

İndeksin defraqmentasiyası

Verilənlər bazası cədvəlləri ilə intensiv işlədiyiniz zaman indekslərin parçalanması effekti baş verir ki, bu da sorğuların effektivliyinin azalmasına səbəb ola bilər.

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

İndekslərin defraqmentasiyası cədvəlləri bloklamır və digər istifadəçilərin işinə mane olmur, lakin SQL Serverdə əlavə yük yaradır. Bu müntəzəm prosedurun yerinə yetirilməsinin optimal tezliyi sistemdəki yükə və defraqmentasiyadan əldə edilən effektə uyğun olaraq seçilməlidir. Ən azı həftədə bir dəfə indekslərinizi defraqmentasiya etməyi tövsiyə edirik.

Verilənlər bazasındakı bütün cədvəlləri deyil, bir və ya bir neçə cədvəli defraqmentasiya etmək mümkündür.

İndeks defraqmentasiyasının konfiqurasiyası (MS SQL 2005)

Əvvəllər yaradılmış texniki xidmət planında "Reindex" adlı yeni alt plan yaradın. Ona Yenidən İndeks Tapşırığını əlavə edin:

İndeksin defraqmentasiyası tapşırığının icra cədvəlini təyin edin. Tapşırığı həftədə ən azı bir dəfə yerinə yetirmək tövsiyə olunur və verilənlər bazasındakı məlumatlar çox dəyişkəndirsə, hətta daha tez-tez - gündə bir dəfəyə qədər.

Verilənlər bazası cədvəllərinin yenidən indeksləşdirilməsi

Cədvəllərin yenidən indeksləşdirilməsi verilənlər bazası cədvəli indekslərinin tam yenidən qurulmasını əhatə edir ki, bu da onların işinin əhəmiyyətli dərəcədə optimallaşdırılmasına gətirib çıxarır. Verilənlər bazası cədvəllərinin müntəzəm olaraq yenidən indeksləşdirilməsini həyata keçirmək tövsiyə olunur. Bütün verilənlər bazası cədvəllərini yenidən indeksləşdirmək üçün aşağıdakı SQL sorğusunu yerinə yetirməlisiniz:

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

Cədvəllərin yenidən indeksləşdirilməsi onları iş müddətində bloklayır, bu da istifadəçilərin işinə əhəmiyyətli dərəcədə təsir göstərə bilər. Bununla əlaqədar olaraq, minimum sistem yükü zamanı yenidən indeksləşdirmənin aparılması tövsiyə olunur.

Yenidən indeksləşdirmədən sonra indeksləri defraqmentləşdirməyə ehtiyac yoxdur.

Cədvəlin yenidən indeksləşdirilməsinin qurulması (MS SQL 2005)

Əvvəllər yaradılmış texniki xidmət planında "İndeks defragmentasiyası" adlı yeni alt plan yaradın. Ona Yenidən İndeks Tapşırığı əlavə edin:

Cədvəl reindex tapşırığı üçün icra cədvəlini təyin edin. Ən azı həftədə bir dəfə sistemin minimum yükü zamanı tapşırığı yerinə yetirmək tövsiyə olunur.

Verilənlər bazasını (və ya bir neçə verilənlər bazasını) göstərərək və tələb olunan cədvəlləri seçərək tapşırığı fərdiləşdirin. Hansı cədvəlləri təyin edəcəyinizi dəqiq bilmirsinizsə, dəyəri Hamısı olaraq təyin edin.

Yüzlərlə istifadəçi eyni vaxtda proqramlar və verilənlərlə işlədikdə, yalnız geniş miqyaslı həllərə xas olan problemlər yaranır. Söhbət məlumatların kilidlənməsi nəticəsində yaranan problemlərdən gedir.

Bəzən istifadəçilər məlumat yazmaq və ya başqa bir əməliyyatı yerinə yetirmək mümkün olmadığını göstərən mesajlardan kilidlər haqqında məlumat əldə edirlər. Bəzən proqram performansının çox əhəmiyyətli dərəcədə azalması səbəbindən (məsələn, bir əməliyyatı yerinə yetirmək üçün tələb olunan vaxt onlarla və ya yüzlərlə dəfə artdıqda).

Bloklama nəticəsində yaranan problemlərin ümumi həlli yoxdur. Buna görə də biz bu cür problemlərin səbəblərini təhlil etməyə və onların həlli variantlarını sistemləşdirməyə çalışacağıq.

ƏMƏLİYYƏNİN BAĞLANMASI SƏBƏBLƏRİ

Əvvəlcə kilidlərin nə olduğunu xatırlayaq və eyni zamanda onlara ehtiyac olub olmadığını anlayacağıq. Həyatda rastlaşdığımız bir neçə klassik bloklama nümunəsinə baxaq.

Misal 1: Təyyarə və ya qatar biletinin alınması. Tutaq ki, kassirə diləklərimizi bildirdik. Kassir bizə oturacaqların mövcudluğunu deyir, onlardan ən çox bəyəndiyimizi seçə bilərik (əlbəttə ki, bir neçə varsa). Biz təklif olunan variantla razılığımızı seçib təsdiq edənə qədər bu oturacaqlar başqa heç kimə satıla bilməz, yəni. müvəqqəti olaraq bloklanıb. Əgər onlar bloklanmasaydı, təsdiqləmə zamanı bizim seçdiyimiz biletlərin artıq satıldığı bir vəziyyət yarana bilər. Və bu halda, seçim dövrü gözlənilməz sayda təkrar ola bilər. Biz yerləri seçərkən, amma onlar artıq satılıb! .. Biz başqalarını seçərkən, onlar artıq yoxdur ...

Misal 2: mağazada və ya bazarda nəsə almaq. Piştaxtaya qalxdıq, mövcud yüz alma içərisindən ən gözəlini seçdik. Seçdilər və pul üçün əllərini ciblərinə atdılar. Əgər biz pulu sayarkən seçdiyimiz alma bizdən sonra gələn alıcıya satılsa, necə görünəcək?

Beləliklə, bloklama özlüyündə zəruri və faydalı bir hadisədir. Məhz bloklama sayəsində hərəkətlərin bir mərhələdə yerinə yetirilməsinə zəmanət veririk. Və əksər hallarda proqram təminatının ən uğurlu tətbiqi mənfiliyə səbəb olmur, məsələn:

• həddindən artıq sayda obyekt (bilet, alma) bloklanır;
• bloklama vaxtı əsassız olaraq uzadılır.

TİPİK 1C KONFİQURASİYALARINDA HƏDDİ QİLİTLƏR

Böyük layihələrdə, bir qayda olaraq, 1C: Enterprise istifadə edirik. Buna görə də, 1C: Enterprise + MS-SQL paketinin nümunəsindən istifadə edərək bloklama problemlərinin həlli üçün praktiki tövsiyələri təsvir etməyə çalışacağıq.

8-ci nəsil 1C: Enterprise istifadənin çox, çox yaxşı paralelliyini təmin edir. Bir konfiqurasiya ilə (yəni bir bazada), normal serverlər və rabitə kanalları ilə eyni vaxtda çox sayda istifadəçi işləyə bilər. Məsələn, yüzlərlə anbardar malların verilməsini və ya qəbulunu emal edir, iqtisadçılar eyni vaxtda müxtəlif şöbələr üçün əmək haqqının dəyərini hesablayır, mühasiblər əmək haqqını hesablayır və hesablayır və s.

Ancaq bunun əksinə bir fikrin olmasının bir səbəbi var - intensiv eyni vaxtda istifadə ilə 1C: Müəssisə əsasında həllər ilə işləmək narahat və ya qeyri-mümkün olan mif. Axı, yüzlərlə istifadəçi sənaye miqyasında 1C: Müəssisə üçün standart həllərdən istifadə etməyə başlayan kimi, getdikcə daha tez-tez ekranda qürurlu bir yazı olan bir pəncərə görünür: “Kontekst metoduna zəng edərkən səhv (Qeyd): Kilid əməliyyatın icrası zamanı qarşıdurma: ...” və daha sonra istifadə edilən SQL serverinin növündən asılı olaraq, “SQL Server üçün Microsoft OLE DB Provayderi: Kilid sorğusunun müddəti keçib. ...".

Təklif olunan "qutudan kənar" tətbiqetmədə demək olar ki, bütün standart həllər avtomatik kilidin idarə edilməsi üçün konfiqurasiya edilmişdir. Buradakı “avtomatik”i “paranoyak” kimi qəbul etmək olar. Hər hansı bir sənədi apararkən, onunla bir şəkildə əlaqəli ola biləcək hər şeyi bloklayırıq. Beləliklə, məlum olur ki, bir istifadəçi nəyisə xərclədikdə (və bəzən sadəcə yazanda), qalanları ancaq gözləyə bilər.

Niyə 1C standart həllərini istifadənin yüksək paralelliyi üçün fərdiləşdirməmək qərarına gəldiyimi bildirəcəyəm. Belə zəriflik üçün əmək xərcləri yüksək deyil - 1C miqyası baxımından əhəmiyyətli olmayan bir neçə "adam-ay". Məncə səbəb başqadır.

Birincisi, belə bir zəriflik bütün sənədləri yerləşdirmək üçün prosessorları əhəmiyyətli dərəcədə çətinləşdirir. Bu o deməkdir ki, 1C-dən kiçik vəzifələr üçün istifadə edən istehlakçılar üçün heç bir qazanc olmadan yalnız bir çatışmazlıq olacaq - tipik bir konfiqurasiyanın tamamlanmasının mürəkkəbliyi daha da mürəkkəbləşəcəkdir. Eyni zamanda, statistika müştərilərin hansı kateqoriyasının 1C üçün əsas qidalandırıcı olduğunu göstərir ...

İkinci səbəb, SQL serverlərinin tipik əsas parametrlərində, məsələn, hələ də digərlərindən daha tez-tez istifadə olunan MS-SQL-də basdırılır. Sadəcə olaraq, parametrlərdə prioritetlər bloklanmağı azaltmağa deyil, server RAM-a qənaət etməyə verilir. Bu ona gətirib çıxarır ki, əgər bir neçə cərgəni kilidləmək lazım gələrsə, SQL server yaddaş və prosessor üçün “iqtisadi” qərar qəbul edir – bütün cədvəli bir anda kilidləmək!..

Məhz standart həllərdəki bu çatışmazlıqlar və ya istifadə olunan verilənlər bazası serverinin parametrlərinin xüsusiyyətləri tez-tez bloklanma nəticəsində yaranan problemlərlə müəyyən edilir. Nəticədə, texniki çatışmazlıqlar çox əhəmiyyətli təşkilati problemlərə səbəb olur. Axı, işçiyə işdən yayındırmaq üçün səbəb verilsə və ya işin görülməməsinin səbəbi əsaslandırılsa, azlıq səmərəli işləyəcəkdir. Yaxşı, əməliyyatların bloklanması və ya "yavaşlama" proqramı ilə bağlı bir mesaj heç bir şeyin edilməməsi üçün ideal bir əsaslandırmadır.

1C:MÜŞƏKİLİ ÜÇÜN HƏDDƏN BAĞLANMANIN LƏD EDİLMƏSİ ÜÇÜN TÖVSİYƏLƏR

Həddindən artıq bloklanma problemlərinin həlli bu qədər vacibdirsə nə etməli?

Bütün böyük komplekslərin həyata keçirilməsinin son mərhələsində, lazımsız əməliyyat kilidlərini aradan qaldırmaq üçün incə bir dəqiqləşdirmə aparmaq lazımdır. Kifayət qədər inkişaf etdirilməmiş bloklama şərtləri və ya icra metodologiyası nəticəsində yarana biləcək problemləri həll etmək vacibdir.

Çünki Bu əməliyyat son dərəcə vacibdir, davamlı olaraq həyata keçirilməlidir. Buna görə də, belə bir təkmilləşdirmənin həyata keçirilməsini asanlaşdırmaq üçün biz riayət etməyə çalışdığımız bir sıra əsas tövsiyələr hazırladıq. Tövsiyələr qəbul edilmiş və xeyli sayda irimiqyaslı tətbiqetmə təcrübəsi əsasında sınaqdan keçirilmişdir.

1. Əgər DBMS və ya inkişaf sisteminiz (məsələn, 1C: Enterprise) defolt olaraq məlumatların avtomatik kilidlənməsindən istifadə edirsə, avtomatik kilid idarəetməsini deaktiv edin. Bloklama qaydalarını özünüz qurun, bütün cədvəllər və ya ayrı-ayrı sıralar üçün bloklama meyarlarını təsvir edin.
2. Proqram hazırlayarkən, mümkün olduqda, eyni ardıcıllıqla cədvəllərə müraciət edin.
3. Eyni əməliyyat çərçivəsində eyni cədvələ bir neçə dəfə yazmamağa çalışın. Əgər bu çətin olarsa, heç olmasa ilk və son yazma əməliyyatı arasındakı vaxtı minimuma endirin.
4. SQL server səviyyəsində kilid eskalasiyasını söndürmək imkanını təhlil edin.
5. İstifadəçilərə bloklama ilə bağlı hər hansı bir hərəkətin həyata keçirilməsinin mümkünsüzlüyünün səbəbləri barədə aydın məlumat verin. Bundan sonra nə edəcəyinizlə bağlı əlçatan və başa düşülən tövsiyələr verin.

Tövsiyələrə diqqətlə baxsanız, aydın olur ki bu cür inkişaf təkcə 1C: Enterprise üçün deyil, istənilən sistemlər üçün uyğundur. Onların hansı dildə yazılması və hansı verilənlər bazası serveri ilə işləməsi önəmli deyil. Tövsiyələrin əksəriyyəti universal xarakter daşıyır və buna görə də 1C: Müəssisədən istifadə edərkən və "öz-özünə yazılmış" proqramlar və ya digər "qutulu" ERP sistemləri üçün eyni dərəcədə etibarlıdır.

P.S. 1C-nin ən yaxşı qiymətə yenilənməsi ilə bağlı peşəkar yardım təklif etdiyimizi bilirdinizmi?

Axtarış Teqləri:

• Əməliyyat kilidləri
• Tıxanmaların aradan qaldırılması
• 1C-nin bloklanması
• bloklama
• Kilid Münaqişəsi
• Əməliyyatı həyata keçirərkən münaqişəni kilidləyin

Hamıya salam!

Keçən gün işdə kilidlərlə bağlı problemlə qarşılaşdım, yəni "Tranzaksiya icra edərkən kilid münaqişəsi. Kilidin verilməsi üçün maksimum vaxt aşıb" mesajı görünməyə başladı.

Aydındır ki, burada dalana dirənmək problemi yoxdur, sadəcə olaraq hansısa seans kilid qoyub, onu aradan qaldırmağı “unudub”. Eyni zamanda, problem ciddi nəticələrlə təhdid etdi - sənəd Malların və xidmətlərin satışı həyata keçirilmədi. Verilənlər bazasında eyni anda 100-ə yaxın insan işləyir və tipik və tez-tez əməliyyat aparmaq mümkün deyil!

İki həll yolu var idi - serveri yenidən yükləmək və ya uğursuz sessiyanı axtarmaq. Birinci həll sadə və sürətlidir, lakin kimsə artıq burada yazdığı kimi, işdən çıxarılana qədər serveri yenidən işə sala bilərsiniz. İkinci yola getməyə qərar verdi.

İlk gün - problem günortadan sonra ortaya çıxdı, əvvəlcə problem Konfiquratorda ilişib qalan uzaq istifadəçidə olduğu görünürdü. Görünürdü ki, edam bir anda dayandı və kilid, əlbəttə ki, açılmadı. Bir neçə saatdan sonra konfiquratoru buraxa bildik, lakin problem aradan qalxmadı. Konfiquratoru zorla öldürmək son dərəcə arzuolunmaz idi, bəlkə də orada işləyirdilər. Bundan sonra Google bu işi öz üzərinə götürdü. Bu saytda MS SQL DBMS-də kilidləri necə tapmaq olar deyə bir məqalə tapdım, yoxlanıldı, DBMS səviyyəsində heç bir kilid yox idi. Qəribə. Daha sonra bunları tənzimləmək cəhdləri oldu. jurnal. Quraşdırın, sonra nə olacaq? 15 dəqiqə ərzində bir neçə konsert proqramı! Onları necə oxumaq, nə axtarmaq lazımdır? Naməlum.

SQL Trace vasitəsilə nəyin bloklandığını görmək haqqında məqalə tapdım. Tapsam da, bəs nə olacaq? Mənə seans lazımdır!

Saat 16:00-a yaxın, daha çox çəkə bilməyəcəyimi başa düşdükdə, yenidən başladım. Bunun bir daha təkrarlanmaması ümidi ilə (və bu, altı aylıq işdə ilk hal idi) rahat nəfəs aldım, hər şey işə yaradı. Ancaq boş yerə ... İkinci gün - eyni vəziyyət. Bir saat yarım qazdım, yenə anlaşılmaz google cəhdləri və s. Nəticə yoxdur. Yenidən başladın. Günün sonunda yenə də oldu. Yaxşı, düşünürəm ki, əladır, mən sakitcə evə gəlib oturacağam, daha dərin qazacağam. Evə gəlirəm, hər şey yaxşıdır. Təəssüf ki.

Üçüncü gün vebinara baxdım və problemi tapmaq üçün maraqlı və təsirli yoldan danışdım. Xatırladım, amma problem daha yaranmadı. Bir həftə keçdi və budur - yenidən bloklayır! Əllərimi ovuşdurub hərəkətə başlayıram.

Birincisi, jurnalın qurulmasıdır. Bəli, onsuz edə bilmərəm, amma indi oxuya bilirəm. Biz iki hadisə təyin etdik: birincisi TLOCK, ikincisi TTIMEOUT. Birincisi bütün bloklama hadisələrini göstərir, ikincisi ayrılmış vaxtda müəyyən edilə bilməyən tıxanmaları göstərir. Əslində, çox güman ki, yalnız TTIMEOUT kifayətdir.

Texniki jurnal faylını ayrılmış yerə kopyalayırıq, proqrama uçuruq, kilidi çağırırıq, mesaj alırıq və texniki jurnal faylını çıxarırıq və ya adını dəyişirik. Bizə başqa bloklamalar haqqında çoxlu məlumat lazım deyil!

Rphost_PID qovluğuna gedin, mətn fayllarını tapın və TTIMEOUT sözünü axtarın. Biz xətti görürük:

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=*********,Gözləmə Əlaqələri=8239

Yeri gəlmişkən, bir neçə rphost_PID qovluğu ola bilər, hamısı serverdə neçə işçi prosesinin işlədiyindən asılıdır.

Və sonra hər şey sadədir: xəttin sonuna baxın - WaitConnections = 8239, bu bizim BAĞLANTI nömrəmizdir. Biz server konsoluna gedirik, Connections-a gedirik, bu nömrəni tapırıq və sessiya nömrəsinə baxırıq. Mənim vəziyyətimdə hər istifadəçiyə iki seans var idi - uğursuz biri və digəri. Texniki qeyddə göstərilən seans pozuldu. Və bir möcüzə haqqında! Hər şey işlədi, sevincin həddi yoxdur! Amma sonradan məlum oldu ki, sessiya asılmayıb :), orada işləyirdilər. Ona görə də gələcək üçün istifadəçi ilə əlaqə saxlayıb xəbərdarlıq etmək məsləhətdir.

Məncə, kifayət qədər tipik bir problemin kifayət qədər tipik həlli. Niyə rast gəlmədiyim məlum deyil, bəlkə də həyəcan siqnalında axtarmalı olduğum üçün və istifadəçilər basmayanda testlər aparmaq mümkün olmadı - heç bir xəta yox idi.

1C-də işləyərkən nadir hallarda "Əməliyyatları yerinə yetirərkən kilid münaqişəsi: Kilidin verilməsi üçün maksimum gözləmə müddəti aşıldı" xətası baş verir. Onun mahiyyəti ondan ibarətdir ki, bir neçə sessiya eyni resursa təsir edərək eyni vaxtda oxşar hərəkətləri yerinə yetirməyə çalışır. Bu gün bu səhvi necə düzəltmək lazım olduğunu anlayacağıq.

Çox sayda əməliyyat

Əvvəla, səbəbləri axtararkən, belə bir səhvin yarandığı infobazada eyni vaxtda işləyən neçə istifadəçinin olduğunu aydınlaşdırmalısınız. Bildiyimiz kimi, onların maksimum sayı kifayət qədər böyük ola bilər. Min beş mindir.

Kilidlərin və əməliyyatların mexanizmi tərtibatçının təlimatında təsvir edilmişdir. Onlar eyni vaxtda bir neçə seans eyni məlumatlara daxil olduqda istifadə olunur. Məntiqlidir ki, eyni verilənlər eyni anda müxtəlif istifadəçilər tərəfindən dəyişdirilə bilməz.

Siz həmçinin istifadəçilərdən hər hansı birinin kütləvi məlumat dəyişikliyi üçün emal etməyə başlayıb olmadığını yoxlamaq lazımdır. Bu, ayın bağlanması və bu kimi ola bilər. Bu halda, emal bitdikdən sonra səhv öz-özünə yox olacaq.

Planlaşdırılmış tapşırıqlar

Çox sayda məlumatı emal edən xətanın səbəbinin olması qeyri-adi deyil. Gecələr belə şeylər etmək tövsiyə olunur. Qeyri-iş saatlarında belə planlaşdırılmış tapşırıqların icrasını planlaşdırın.

Beləliklə, hər iki istifadəçi sabit sistemdə işləyəcək və planlaşdırılan tapşırıqlar özləri uğurla yerinə yetiriləcək, çünki istifadəçi seansları ilə ziddiyyətlərin olma ehtimalı azalacaq.

"Yalışmış sessiyalar"

İstifadəçilərin "asılmış seanslar" problemi 1C xidməti ilə qarşılaşan demək olar ki, hər kəsə tanışdır. İstifadəçi proqramdan çoxdan çıxa, yaxud sənədi bağlaya bilərdi, lakin onun sessiyası hələ də sistemdə qalır. Problem çox vaxt təkdir və belə bir sessiyanı idarəçi konsolu vasitəsilə bitirmək kifayətdir. Eyni problemlər fon işlərində də baş verə bilər.

İnternetdəki çoxsaylı şərhlərə görə, şəbəkə təhlükəsizlik açarlarından istifadə edərkən belə hallara daha çox rast gəlinir. Əgər "asılmış sessiyalar" ilə bağlı vəziyyət sistematik olaraq təkrarlanırsa, bu, sistemin və serverlərin hərtərəfli yoxlanılması və texniki xidmətinin səbəbidir (əgər baza müştəri-serverdirsə).

Konfiqurasiya yazarkən səhvlər

Bütün tipik konfiqurasiyalar ixtisaslı mütəxəssislər və ekspertlər tərəfindən hazırlanır. Hər bir sistem diqqətlə sınaqdan keçirilir və orada daha sürətli və düzgün işləmək üçün optimallaşdırılır.

Bununla əlaqədar olaraq, xətanın səbəbi üçüncü tərəf tərtibatçısının yazdığı suboptimal kodda ola bilər. Bu, məlumatları uzun müddət bloklayacaq "ağır" bir sorğu ola bilər. Aşağı performanslı və məntiqi pozan alqoritmlərin qurulması da qeyri-adi deyil.

Çox güman ki, proqramın yenilənməsindən sonra yaranıbsa, kilid münaqişəsi məhz developer səhvləri səbəbindən yaranıb. Yoxlamaq üçün siz sadəcə olaraq təkmilləşdirmələri "geri qaytara" və ya kodu yenidən düzəldə bilərsiniz.