Би блоклох асуудлыг хэрхэн оношлосон. Би цоожны асуудлыг хэрхэн оношилсон бэ? Гүйлгээ хийх үед цоожны зөрчлийн алдаа

Би тархсан мэдээллийн сан руу шилжүүлэх өөрчлөлтийг бичиж чадаагүй тул 1c дэмжлэгтэй холбогдож дараахь зүйлийг санал болгов. Би зүгээр л SQL програмын сервер болон серверийг дахин эхлүүлэхээр шийдсэн. Ерөнхийдөө та "Блоклох хуваарьтай
даалгаврууд багтсан"
Энэ нь бас дахин ачаалахгүйгээр тусалсан.

MS SQL серверт зориулсан DBMS түвшний хуваарьт үйлдлүүд

DBMS түвшинд ердийн үйлдлүүдийг гүйцэтгэх заавар.

Мэдээлэл нь MS SQL Server DBMS-ийг ашиглах үед 1C: Enterprise 8-ийн клиент-сервер хувилбарт хамаарна.

Ерөнхий мэдээлэл

Системийн оновчтой бус үйл ажиллагааны хамгийн түгээмэл шалтгаануудын нэг нь DBMS түвшинд ердийн үйлдлүүдийг буруу эсвэл цаг тухайд нь гүйцэтгээгүй явдал юм. Маш их ачаалалтай ажиллаж, олон тооны хэрэглэгчдэд нэгэн зэрэг үйлчилдэг томоохон мэдээллийн системд эдгээр ердийн процедурыг гүйцэтгэх нь онцгой чухал юм. Ийм системүүдийн онцлог нь DBMS-ийн автоматаар гүйцэтгэдэг ердийн үйлдлүүд (тохиргоон дээр үндэслэн) үр ашигтай ажиллахад хангалтгүй байдаг.

Хэрэв ажиллаж байгаа системд гүйцэтгэлийн асуудлын шинж тэмдэг илэрвэл та систем зөв тохируулагдсан эсэх, DBMS түвшинд санал болгож буй бүх ердийн засвар үйлчилгээг тогтмол хийж байгаа эсэхийг шалгах хэрэгтэй.

Ердийн журмын гүйцэтгэлийг автоматжуулах хэрэгтэй. Эдгээр үйлдлийг автоматжуулахын тулд MS SQL Server-ийн суулгасан хэрэгслүүдийг ашиглахыг зөвлөж байна: Засвар үйлчилгээний төлөвлөгөө. Эдгээр процедурыг автоматжуулах өөр аргууд бас бий. Энэ нийтлэлд хуваарьт процедур бүрийн хувьд MS SQL Server 2005-ийн засвар үйлчилгээний төлөвлөгөөг ашиглан түүний тохиргооны жишээг өгсөн болно.

Эдгээр ердийн журмын хэрэгжилтийг цаг тухайд нь, зөв ​​эсэхийг тогтмол хянахыг зөвлөж байна.

Статистикийн шинэчлэл

MS SQL Server нь индекс, хүснэгт дэх утгын тархалтын талаарх статистик мэдээлэлд үндэслэн асуулгын төлөвлөгөөг боловсруулдаг. Статистикийн мэдээллийг өгөгдлийн хэсэг (дээж) дээр үндэслэн цуглуулдаг бөгөөд энэ өгөгдөл өөрчлөгдөхөд автоматаар шинэчлэгддэг. Заримдаа энэ нь MS SQL Server-д бүх асуулгыг гүйцэтгэх хамгийн оновчтой төлөвлөгөөг тууштай бүтээхэд хангалтгүй байдаг.

Энэ тохиолдолд асуулгын гүйцэтгэлийн асуудал гарч болзошгүй. Үүний зэрэгцээ асуулгын төлөвлөгөөнд оновчтой бус ажлын (оновчтой бус ажиллагаа) шинж тэмдгүүд ажиглагдаж байна.

MS SQL Server оновчтой болгохын тулд хамгийн зөв ажиллагааг хангахын тулд MS SQL мэдээллийн сангийн статистик мэдээллийг тогтмол шинэчлэхийг зөвлөж байна.

Өгөгдлийн сангийн бүх хүснэгтийн статистикийг шинэчлэхийн тулд та дараах SQL хайлтыг гүйцэтгэх ёстой.

exec sp_msforeachtable "СТАТИСТИКИЙГ ШИНЭЧЛЭХ ҮҮ? БҮТЭН SCAN"-той

Статистикийг шинэчлэх нь хүснэгтийг түгжихэд хүргэдэггүй бөгөөд бусад хэрэглэгчдийн ажилд саад болохгүй. Статистикийг шаардлагатай бол байнга шинэчилж болно. Статистикийг шинэчлэх явцад DBMS серверийн ачаалал нэмэгдэх бөгөөд энэ нь системийн ерөнхий гүйцэтгэлд сөргөөр нөлөөлж болзошгүйг санаарай.

Статистикийг шинэчлэх оновчтой давтамж нь системийн ачааллын хэмжээ, шинж чанараас хамаардаг бөгөөд туршилтаар тодорхойлогддог. Статистик мэдээллийг шинэчлэхийг зөвлөж байна өдөрт дор хаяж нэг удаа.

Дээрх асуулга нь мэдээллийн сангийн бүх хүснэгтийн статистикийг шинэчилдэг. Бодит амьдралын системд өөр өөр хүснэгтүүд нь өөр өөр статистик шинэчлэлтийн хурдыг шаарддаг. Асуулгын төлөвлөгөөнд дүн шинжилгээ хийснээр та аль хүснэгтэд статистикийн мэдээллийг хамгийн их шинэчлэх шаардлагатайг тодорхойлж, байнга шинэчлэгддэг хүснэгтүүд болон бусад бүх хүснэгтүүдийн хувьд хоёр (эсвэл түүнээс дээш) өөр ердийн горимуудыг тохируулах боломжтой. Энэ арга нь статистик мэдээг шинэчлэх хугацаа болон статистикийн шинэчлэлтийн үйл явцын системийн үйл ажиллагаанд үзүүлэх нөлөөллийг эрс багасгах болно.

Статистикийн автомат шинэчлэлтийг тохируулах (MS SQL 2005)

MS SQL Server Management Studio-г эхлүүлж, DBMS серверт холбогдоно уу. Удирдлагын хавтсыг нээгээд шинэ засвар үйлчилгээний төлөвлөгөө үүсгэнэ үү:

Дэд төлөвлөгөөг (Дэд төлөвлөгөө нэмэх) үүсгээд "Статистикийн шинэчлэл" гэж нэрлэнэ үү. Даалгаврын самбараас Статистик шинэчлэх даалгаврыг нэмнэ үү:

Статистикийг шинэчлэх хуваарийг тохируулна уу. Өдөрт дор хаяж нэг удаа статистик мэдээллийг шинэчлэхийг зөвлөж байна. Шаардлагатай бол статистикийн шинэчлэлтийн давтамжийг нэмэгдүүлэх боломжтой.

Ажлын тохиргоог тохируулна уу. Үүнийг хийхийн тулд цонхны баруун доод буланд байгаа даалгавар дээр давхар товшино уу. Гарч ирэх маягт дээр статистикийг шинэчлэх мэдээллийн сангийн нэрийг (эсвэл хэд хэдэн мэдээллийн сан) зааж өгнө үү. Нэмж дурдахад та аль хүснэгтэд статистикийг шинэчлэхийг зааж өгч болно (хэрэв та яг ямар хүснэгтүүдийг зааж өгөх ёстойгоо мэдэхгүй байгаа бол бүх утгыг тохируулна уу).

Бүрэн хайлтыг идэвхжүүлсэн үед статистик мэдээллийг шинэчлэх шаардлагатай.

Үүсгэсэн төлөвлөгөөг хадгалах. Хуваарьт заасан цаг ирэхэд статистик мэдээ автоматаар шинэчлэгдэх болно.

Процедурын кэшийг цэвэрлэж байна

MS SQL Серверийн оновчтой болгогч нь дахин гүйцэтгэх хүсэлтийн төлөвлөгөөг кэш болгодог. Хэрэв ижил асуулга аль хэдийн биелэгдсэн, төлөвлөгөө нь мэдэгдэж байгаа бол асуулга бүрдүүлэхэд зарцуулсан цагийг хэмнэхийн тулд үүнийг хийдэг.

MS SQL Server нь хуучирсан статистик мэдээлэлд тулгуурлан оновчтой бус асуулгын төлөвлөгөөг бий болгож магадгүй юм. Энэ төлөвлөгөө нь процедурын кэшэд хадгалагдах бөгөөд ижил асуулга дахин дуудагдах үед ашиглагдана. Хэрэв та статистик мэдээллийг шинэчилсэн боловч процедурын кэшийг цэвэрлээгүй бол SQL Server шинэ (илүү сайн) төлөвлөгөө үүсгэхийн оронд кэшээс хуучин (оновчтой бус) асуулгын төлөвлөгөөг сонгож болно.

MS SQL серверийн процедурын кэшийг цэвэрлэхийн тулд та дараах SQL хайлтыг гүйцэтгэх ёстой.

Статистикийг шинэчилсний дараа энэ асуулга нэн даруй ажиллах ёстой. Үүний дагуу түүний гүйцэтгэлийн давтамж нь статистикийг шинэчлэх давтамжтай тохирч байх ёстой.

Процедурын кэш цэвэрлэх тохиргоог хийж байна (MS SQL 2005)

Статистикийг шинэчлэх бүрт процедурын кэшийг цэвэрлэх шаардлагатай байдаг тул энэ үйлдлийг аль хэдийн үүсгэсэн "Статистикийг шинэчлэх" дэд төлөвлөгөөнд нэмэхийг зөвлөж байна. Үүнийг хийхийн тулд дэд төлөвлөгөөг нээгээд түүний схемд T-SQL мэдэгдлийн даалгавар гүйцэтгэхийг нэмнэ үү. Дараа нь та Статистикийг шинэчлэх ажлыг шинэ даалгавартай сумаар холбох хэрэгтэй.

Үүсгэсэн T-SQL мэдэгдлийн даалгаврын текстэнд та "DBCC FREEPROCCACHE" хайлтыг зааж өгөх ёстой.

Индекс дефрагментаци

Өгөгдлийн сангийн хүснэгтүүдтэй эрчимтэй ажиллах үед индексийг хуваах үр дагавар гарч ирдэг бөгөөд энэ нь асуулгын үр ашгийг бууруулахад хүргэдэг.

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

Индекс дефрагментаци нь хүснэгтүүдийг блоклохгүй бөгөөд бусад хэрэглэгчдийн ажилд саад учруулахгүй боловч SQL Server дээр нэмэлт ачааллыг бий болгодог. Энэхүү ердийн процедурыг гүйцэтгэх оновчтой давтамжийг системийн ачаалал, дефрагментацийн үр дүнд үндэслэн сонгох хэрэгтэй. Долоо хоногт ядаж нэг удаа индексээ задлахыг зөвлөж байна.

Өгөгдлийн сангийн бүх хүснэгтийг биш нэг буюу хэд хэдэн хүснэгтийг defragment хийх боломжтой.

Индекс дефрагментацийг тохируулах (MS SQL 2005)

Өмнө нь үүсгэсэн засвар үйлчилгээний төлөвлөгөөнд "Дахин индекс" нэртэй шинэ дэд төлөвлөгөө үүсгэнэ үү. Түүнд дахин бүтээх индексийн ажлыг нэмнэ үү:

Индекс дефрагментацийн ажлыг гүйцэтгэх хуваарийг тохируулна уу. Даалгаврыг долоо хоногт ядаж нэг удаа ажиллуулахыг зөвлөж байна, хэрэв мэдээллийн сан дахь өгөгдөл маш их хэлбэлзэлтэй бол бүр илүү олон удаа - өдөрт нэг удаа хүртэл.

Өгөгдлийн сангийн хүснэгтүүдийг дахин индексжүүлэх

Хүснэгтийг дахин индексжүүлэх нь мэдээллийн баазын хүснэгтийн индексийг бүрэн сэргээн засварлах ажлыг багтаасан бөгөөд энэ нь тэдний ажлыг ихээхэн оновчтой болгоход хүргэдэг. Өгөгдлийн сангийн хүснэгтүүдийг тогтмол дахин индексжүүлэхийг зөвлөж байна. Өгөгдлийн сангийн бүх хүснэгтийг дахин индексжүүлэхийн тулд та дараах SQL хайлтыг гүйцэтгэх ёстой.

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

Хүснэгтүүдийг дахин индексжүүлэх нь тэдний ажлын туршид блоклодог бөгөөд энэ нь хэрэглэгчдийн ажилд ихээхэн нөлөөлдөг. Үүнтэй холбогдуулан системийн хамгийн бага ачааллын үед дахин индексжүүлэхийг зөвлөж байна.

Дахин индексжүүлсний дараа индексүүдийг задлах шаардлагагүй болно.

Хүснэгтийг дахин индексжүүлэх (MS SQL 2005)

Өмнө нь үүсгэсэн засвар үйлчилгээний төлөвлөгөөнд "Индекс дефрагментаци" нэртэй шинэ дэд төлөвлөгөө үүсгэ. Дахин бүтээх индексийн даалгаврыг түүнд нэмнэ үү:

Хүснэгтийг дахин индексжүүлэх ажлыг гүйцэтгэх хуваарийг тохируулна уу. Системийн хамгийн бага ачаалалтай үед долоо хоногт ядаж нэг удаа ажлыг гүйцэтгэхийг зөвлөж байна.

Өгөгдлийн санг (эсвэл олон мэдээллийн сан) зааж, шаардлагатай хүснэгтүүдийг сонгох замаар даалгавраа тохируулна уу. Хэрэв та яг аль хүснэгтийг зааж өгөхөө мэдэхгүй байгаа бол утгыг Бүгд гэж тохируулна уу.

Хэдэн зуун хэрэглэгчид программ болон өгөгдөлтэй нэгэн зэрэг ажиллахад зөвхөн том хэмжээний шийдлээс үүдэлтэй асуудал гардаг. Бид өгөгдлийн түгжээтэй холбоотой асуудлуудын талаар ярьж байна.

Заримдаа хэрэглэгчид өгөгдөл бичих эсвэл бусад үйлдлийг хийх боломжгүй гэсэн мессежээс түгжээний талаар олж мэддэг. Заримдаа програмын гүйцэтгэл маш их буурсантай холбоотой (жишээлбэл, үйл ажиллагааг гүйцэтгэхэд шаардагдах хугацаа хэдэн арван эсвэл хэдэн зуу дахин өсөх үед).

Блоклохоос үүдэлтэй асуудлууд нь ерөнхий шийдэлгүй байдаг. Тиймээс бид ийм асуудлын шалтгааныг шинжлэх, тэдгээрийг шийдвэрлэх хувилбаруудыг системчлэхийг хичээх болно.

ГҮЙЛГЭЭГ ХААГДСАН ШАЛТГААН

Эхлээд цоож гэж юу болохыг санацгаая, тэр үед шаардлагатай эсэхийг олж мэдье. Амьдралд тулгардаг хаалтын хэд хэдэн сонгодог жишээг харцгаая.

Жишээ 1: Онгоц эсвэл галт тэрэгний билет худалдаж авах. Бид кассчинд хүслээ хэлсэн гэж бодъё. Кассчин бидэнд суудал байгаа эсэхийг хэлж өгдөг бөгөөд үүнээс бид хамгийн дуртайг нь сонгох боломжтой (мэдээж хэд хэдэн байгаа бол). Бид санал болгож буй хувилбарыг сонгож, баталгаажуулах хүртэл эдгээр суудлыг өөр хүнд зарах боломжгүй, жишээлбэл. түр хаасан. Хэрэв тэдгээрийг хаагаагүй бол баталгаажуулах үед бидний сонгосон тасалбарууд аль хэдийн зарагдсан байх нөхцөл байдал үүсч магадгүй юм. Мөн энэ тохиолдолд сонгох мөчлөг нь урьдчилан таамаглах аргагүй олон тооны давталт байж болно. Бид газрыг сонгож байхад тэд аль хэдийн зарагдсан! .. Бид бусдыг сонгож байхад тэд байхгүй болсон ...

Жишээ 2: дэлгүүр эсвэл захаас ямар нэгэн зүйл худалдаж авах. Бид лангуун дээр очоод бэлэн байгаа зуун алимнаас хамгийн үзэсгэлэнтэйг нь сонгов. Тэд сонголт хийж, мөнгө авахын тулд халаасандаа гараа сунгав. Мөнгөө тоолж байхад бидний сонгосон алим биднээс хожуу гарч ирсэн худалдан авагчид зарагдах юм бол ямар харагдах бол?

Тиймээс блоклох нь өөрөө зайлшгүй бөгөөд хэрэгтэй үзэгдэл юм. Блоклосны ачаар бид үйлдлүүдийг нэг үе шаттайгаар гүйцэтгэх баталгаа болдог. Ихэнх тохиолдолд програм хангамжийг амжилттай хэрэгжүүлэх нь сөрөг үр дагаварт хүргэдэггүй, жишээлбэл:

• хэт олон тооны объект (тасалбар, алим) хаагдсан;
• хаах хугацааг үндэслэлгүйгээр сунгасан.

1С-ИЙН ЕРИЙН ТОХИРУУЛАЛТ ДЭЭР ИЛҮҮ ХАМТ ОЛОН.

Томоохон төслүүд дээр бид дүрмээр бол 1C: Enterprise ашигладаг. Тиймээс бид 1C: Enterprise + MS-SQL багцын жишээг ашиглан хаах асуудлыг шийдвэрлэх практик зөвлөмжийг тайлбарлахыг хичээх болно.

1С: Enterprise-ийн 8-р үе нь ашиглалтын маш, маш сайн зэрэгцээ байдлыг хангадаг. Нэг тохиргоотой (өөрөөр хэлбэл нэг суурь дээр), ердийн сервер, холбооны сувгуудтай зэрэгцэн асар олон тооны хэрэглэгчид ажиллах боломжтой. Жишээлбэл, олон зуун хадгалагч нар бараа бүтээгдэхүүн гаргах, хүлээн авах үйл явцыг боловсруулдаг, эдийн засагчид янз бүрийн хэлтсийн цалингийн зардлыг нэгэн зэрэг тооцдог, нягтлан бодогчид цалингаа тооцоолж, тооцдог гэх мэт.

Гэхдээ эсрэгээр нь нэг шалтгаан бий - нэгэн зэрэг эрчимтэй ашиглах нь 1С: Enterprise дээр суурилсан шийдлүүдтэй ажиллахад эвгүй эсвэл боломжгүй гэсэн домог байдаг. Эцсийн эцэст, олон зуун хэрэглэгчид 1C: Enterprise-ийн стандарт шийдлүүдийг үйлдвэрлэлийн хэмжээнд ашиглаж эхлэхэд дэлгэцэн дээр "контекст аргыг дуудах үед гарсан алдаа (Бичлэг): Түгжих" гэсэн бардам бичээс бүхий цонх гарч ирэх нь олонтаа. гүйлгээг гүйцэтгэх явцад гарсан зөрчил: ...” ба цаашид ашигласан SQL серверийн төрлөөс хамааран “SQL серверт зориулсан Microsoft OLE DB Provider: Түгжих хүсэлтийн хугацаа хэтэрсэн. ...".

Санал болгож буй "хайрцагнаас гадуур" хэрэгжилтийн бараг бүх стандарт шийдлүүд нь автомат түгжээг удирдахаар тохируулагдсан байдаг. Энд байгаа "автомат" гэдгийг "параноид" гэж ойлгож болно. Ямар нэгэн баримт бичиг хөтлөхдөө бид үүнтэй холбоотой байж болох бүх зүйлийг хаадаг. Тэгэхээр нэг хэрэглэгч ямар нэгэн зүйл зарцуулж (заримдаа зүгээр л бичдэг) бусад нь хүлээх л үлддэг болох нь харагдаж байна.

1С яагаад стандарт шийдлүүдийг өндөр зэрэглэлийн хэрэглээний хувьд өөрчлөхгүй байхаар шийдсэн гэж би бодлоо илэрхийлэх болно. Ийм боловсронгуй болгох хөдөлмөрийн зардал өндөр биш - цөөн хэдэн "хүн-сар" нь 1С масштабын хувьд тийм ч чухал биш юм. Шалтгаан нь өөр гэж бодож байна.

Нэгдүгээрт, ийм сайжруулалт нь бүх баримт бичгийг байршуулах процессоруудыг ихээхэн хүндрүүлдэг. Энэ нь 1С-ийг жижиг ажлуудад ашигладаг хэрэглэгчдийн хувьд ямар ч ашиггүй зөвхөн сул тал байх болно гэсэн үг юм - ердийн тохиргоог дуусгах нь илүү төвөгтэй болно. Үүний зэрэгцээ статистик тоо баримтаас харахад аль ангиллын үйлчлүүлэгчид 1С-ийн гол тэжээл болохыг харуулж байна ...

Хоёрдахь шалтгаан нь SQL серверүүдийн ердийн үндсэн тохиргоонд оршдог, жишээлбэл, MS-SQL нь бусдаас илүү олон удаа ашиглагддаг хэвээр байна. Тохиргооны тэргүүлэх чиглэлүүд нь блоклохыг багасгах биш харин серверийн RAM-г хэмнэх явдал юм. Энэ нь хэд хэдэн мөрийг түгжих шаардлагатай бол SQL сервер санах ой болон процессорын хувьд "эдийн засгийн" шийдвэр гаргаж, бүх хүснэгтийг нэг дор түгжих болно!..

Стандарт шийдлүүдийн эдгээр дутагдал эсвэл ашигласан мэдээллийн баазын серверийн тохиргооны онцлог нь блоклохоос үүдэлтэй асуудлуудтай ихэвчлэн тодорхойлогддог. Үүний үр дүнд техникийн дутагдал нь зохион байгуулалтын маш чухал асуудалд хүргэдэг. Эцсийн эцэст, хэрэв ажилтныг ажлаасаа сатааруулах, яагаад ажлаа хийж чадаагүйг нь зөвтгөх шалтгаан өгвөл цөөнх үр дүнтэй ажиллах болно. Гүйлгээг хаах тухай мессеж эсвэл "удаашруулах" хөтөлбөр нь яагаад юу ч хийж болохгүйг хамгийн тохиромжтой үндэслэл юм.

1C:ENTERPRISE-ийн ХЭТ ХААЛТЫГ АРИЛГАХ ЗӨВЛӨМЖ.

Хэт их түгжрэлийн асуудлыг шийдэх нь маш чухал бол яах вэ?

Бүх томоохон цогцолборуудыг хэрэгжүүлэх эцсийн шатанд шаардлагагүй гүйлгээний түгжээг арилгахын тулд нарийн боловсронгуй болгох шаардлагатай. Блоклох нөхцөл, хэрэгжүүлэх арга зүй хангалтгүй хөгжсөнөөс үүдэн гарч болох асуудлуудыг шийдвэрлэх нь чухал юм.

Учир нь Энэ үйлдэл нь маш чухал бөгөөд үүнийг байнга хийх ёстой. Тиймээс ийм сайжруулалтыг хэрэгжүүлэх ажлыг хялбарчлахын тулд бид дагаж мөрдөхийг хичээдэг хэд хэдэн үндсэн зөвлөмжийг боловсруулсан. Зөвлөмжийг хүлээн авч, олон тооны томоохон хэмжээний хэрэгжилтийн туршлага дээр туршиж үзсэн.

1. Хэрэв таны DBMS эсвэл хөгжүүлэлтийн систем (жишээ нь, 1C: Enterprise) өгөгдмөлөөр өгөгдлийг автоматаар түгжихийг ашигладаг бол автомат түгжээний удирдлагыг идэвхгүй болго. Блоклох дүрмийг өөрөө тохируулж, бүхэл бүтэн хүснэгт эсвэл тусдаа мөрүүдийг блоклох шалгуурыг тайлбарлана уу.
2. Хөтөлбөрийг боловсруулахдаа аль болох ижил дарааллаар хүснэгтүүдийг харна уу.
3. Нэг гүйлгээний хүрээнд нэг хүснэгтэд олон удаа бичихгүй байхыг хичээгээрэй. Хэрэв энэ нь хэцүү байвал эхний болон сүүлчийн бичих үйлдлүүдийн хоорондох хугацааг хамгийн багадаа багасгах хэрэгтэй.
4. SQL серверийн түвшинд түгжээний өсөлтийг идэвхгүй болгох боломжид дүн шинжилгээ хийнэ үү.
5. Хэрэглэгчид хаагдсаны улмаас ямар нэгэн үйлдэл хийх боломжгүй болсон шалтгааныг тодорхой мэдээлнэ үү. Цаашид юу хийх талаар хүртээмжтэй, ойлгомжтой зөвлөмж өг.

Хэрэв та зөвлөмжийг анхааралтай ажиглавал энэ нь тодорхой болно Ийм хөгжүүлэлт нь зөвхөн 1C: Enterprise-д төдийгүй аливаа системд тохиромжтой. Тэд ямар хэл дээр бичигдсэн, ямар мэдээллийн баазын сервертэй ажилладаг нь хамаагүй. Ихэнх зөвлөмжүүд нь бүх нийтийн шинж чанартай байдаг тул 1C: Enterprise болон "өөрөө бичсэн" програмууд эсвэл бусад "хайрцагтай" ERP системийг ашиглахад адил хүчинтэй байдаг.

P.S. Бид 1С-ийг хамгийн сайн үнээр шинэчлэхэд мэргэжлийн туслалцаа үзүүлж байгааг та мэдэх үү?

Хайлтын шошго:

• Гүйлгээний түгжээ
• Бөглөрлийг арилгах
• 1С-ийг хаах
• блоклох
• Түгжээний зөрчил
• Гүйлгээ хийх явцад зөрчилдөөнийг түгжих

Сайн уу!

Нөгөө өдөр ажил дээрээ би түгжээтэй холбоотой асуудалтай тулгарсан, тухайлбал "Гүйлгээ хийх явцад түгжигдсэн зөрчил гарлаа. Түгжээ өгөх хамгийн дээд хугацаа хэтэрсэн" гэсэн мессеж гарч ирэв.

Энд ямар ч гацсан асуудал байхгүй нь тодорхой, зүгээр л зарим нэг сесс түгжээ тавиад түүнийг арилгах гэж "мартсан" л байна. Үүний зэрэгцээ, асуудал ноцтой үр дагаварт заналхийлж байсан - баримт бичиг Бараа, үйлчилгээний борлуулалт хийгдээгүй. Мэдээллийн санд нэг дор 100 орчим хүн ажилладаг бөгөөд ердийн, байнгын ажиллагаа явуулах боломжгүй юм!

Серверийг дахин ачаалах эсвэл бүтэлгүйтсэн сесс хайх гэсэн хоёр шийдэл байсан. Эхний шийдэл нь энгийн бөгөөд хурдан боловч хэн нэгэн энд бичсэнчлэн халагдах хүртлээ серверээ дахин ачаалж болно. Хоёрдахь замаар явахаар шийдсэн.

Эхний өдөр - асуудал үдээс хойш гарч ирсэн бөгөөд эхлээд асуудал нь Тохируулагчид гацсан алсын хэрэглэгчтэй холбоотой юм шиг санагдсан. Зүгээр л нэг цэгт цаазаар авах ажиллагаа зогссон бололтой, цоож нь мэдээж суллагдаагүй. Хэдэн цагийн дараа бид тохируулагчийг суллаж чадсан ч асуудал арилаагүй. Тохируулагчийг хүчээр алах нь туйлын хүсээгүй зүйл байсан, магадгүй тэд үүнд ажиллаж байсан байх. Үүний дараа Google энэ ажлыг гартаа авлаа. Би энэ сайтаас MS SQL DBMS-ийн түгжээг хэрхэн олох талаар бичсэн нийтлэлийг олсон, шалгасан, DBMS түвшинд ямар ч түгжээ байхгүй байсан. Хачирхалтай. Цаашид тэдгээрийг тохируулах оролдлого байсан. сэтгүүл. Тохируулах, дараа нь яах вэ? 15 минутын дотор хэд хэдэн тоглолт хийх болно! Тэдгээрийг хэрхэн унших, юу хайх вэ? Тодорхойгүй.

Би SQL Trace-ээр дамжуулан юу хаагдсаныг хэрхэн харах тухай нийтлэл олсон. Би олсон ч яах вэ? Надад сесс хэрэгтэй байна!

16:00 дөхөхөд би үүнийг цааш татаж чадахгүйгээ мэдээд дахин ачааллаа. Дахин ийм зүйл болохгүй гэж найдаж (энэ нь зургаан сарын ажилдаа анхны тохиолдол байсан) санаа зовсон, бүх зүйл үр дүнтэй болсон. Гэвч дэмий хоосон ... Хоёр дахь өдөр - ижил нөхцөл байдал. Би нэг цаг хагасын турш ухаж, дахин ойлгомжгүй оролдлого google гэх мэт. Үр дүнгүй. Дахин ачаална уу. Өдрийн төгсгөлд дахин ийм зүйл болов. За, би үнэхээр сайхан байна гэж бодож байна, би гэртээ тайвширч ирээд суугаад илүү гүн ухна. Би гэртээ ирлээ, бүх зүйл сайхан байна. Харамсалтай нь.

Гурав дахь өдөр нь би вебинар үзэж, асуудлыг олох сонирхолтой, үр дүнтэй аргын талаар ярилцав. Санаж байна, гэхдээ асуудал дахин үүссэнгүй. Долоо хоног өнгөрч, дахиад л хааж байна! Би гараа илж, үйлдэл хийж эхлэв.

Эхнийх нь бүртгэлийг тохируулах явдал юм. Тийм ээ, би түүнгүйгээр хийж чадахгүй, гэхдээ би үүнийг уншиж чадна. Бид хоёр үйл явдлыг тохируулсан: эхнийх нь TLOCK, хоёр дахь нь TTIMEOUT. Эхнийх нь бүх блоклох үйл явдлуудыг харуулах бол хоёр дахь нь хуваарилагдсан хугацаанд тогтоож чадаагүй бөглөрөлүүдийг харуулдаг. Үнэн хэрэгтээ зөвхөн TTIMEOUT л хангалттай байх магадлалтай.

Бид техникийн бүртгэлийн файлыг хуваарилагдсан газар хуулж, програм руу нисч, түгжээг дуудаж, мессеж хүлээн авч, техникийн бүртгэлийн файлыг устгаж эсвэл нэрийг нь өөрчилдөг. Бидэнд бусад хоригийн талаар олон тонн мэдээлэл хэрэггүй!

Rphost_PID хавтас руу орж, текст файлуудыг олоод TTIMEOUT гэсэн үгийг олоорой. Бид шугамыг харж байна:

53:16.789126-0,ЦАГДААСАН,5,процесс=rphost,p:processName=*****,t:clientID=16536,t:applicationName=1CV8,t:computerName=ASUSM,t:connectID=17272,SessionID= 2242,Уср=*********,Хүлээлт=8239

Дашрамд хэлэхэд, хэд хэдэн rphost_PID хавтас байж болох бөгөөд энэ нь сервер дээр хэдэн ажилчны процесс ажиллаж байгаагаас хамаарна.

Тэгээд бүх зүйл энгийн: мөрийн төгсгөлийг харна уу - WaitConnections = 8239, энэ бол бидний ХОЛБОГДОЛЫН дугаар юм. Бид серверийн консол руу очиж, холболтууд руу орж, энэ дугаарыг олоод сессийн дугаарыг харна. Миний хувьд нэг хэрэглэгч бүрт хоёр сесс байсан - амжилтгүй болсон, өөр нэг сесс. Техникийн бүртгэлд заасан сесс гацсан. Мөн гайхамшгийн тухай! Бүх зүйл ажилласан, баяр баясгалангийн хязгаар байхгүй! Гэхдээ дараа нь тодорхой болсон тул хуралдаан өлгөгдөөгүй :), тэд үүнд ажилласан. Тиймээс цаашид хэрэглэгчтэй холбогдож анхааруулахыг зөвлөж байна.

Миний бодлоор нэлээд ердийн асуудлын нэлээд ердийн шийдэл. Яагаад би үүнтэй тааралдаагүй нь тодорхойгүй байна, магадгүй би үүнийг дохиоллын үед хайх шаардлагатай болсон, хэрэглэгчид дараагүй үед туршилт хийх боломжгүй болсон - алдаа гараагүй.

1С-д ажиллах үед "Гүйлгээ хийх үед түгжигдэх зөрчил: Түгжээ өгөх хамгийн дээд хугацаа хэтэрсэн" гэсэн алдаа гардаг. Үүний мөн чанар нь хэд хэдэн сессүүд ижил нөөцөд нөлөөлж, ижил төстэй үйлдлүүдийг нэгэн зэрэг хийхийг оролддогт оршино. Өнөөдөр бид энэ алдааг хэрхэн засах талаар олж мэдэх болно.

Маш олон тооны үйл ажиллагаа

Юуны өмнө шалтгааныг хайхдаа ийм алдаа гарсан мэдээллийн санд нэгэн зэрэг ажиллаж байгаа хэдэн хэрэглэгч байгааг тодруулах хэрэгтэй. Бидний мэдэж байгаагаар тэдний хамгийн их тоо нэлээд их байж болно. Энэ нь мянга таван мянга юм.

Түгжих, гүйлгээ хийх механизмыг хөгжүүлэгчийн гарын авлагад тайлбарласан болно. Эдгээр нь олон сессүүд ижил өгөгдөлд нэгэн зэрэг хандах үед ашиглагддаг. Нэг өгөгдлийг өөр өөр хэрэглэгчид нэгэн зэрэг өөрчлөх боломжгүй гэдэг нь логик юм.

Та мөн хэрэглэгчдийн аль нэг нь өгөгдлийг их хэмжээгээр өөрчлөхөөр боловсруулж эхэлсэн эсэхийг шалгах хэрэгтэй. Энэ нь сарын хаалт гэх мэт байж болно. Энэ тохиолдолд боловсруулалт дууссаны дараа алдаа өөрөө алга болно.

Төлөвлөсөн даалгавар

Их хэмжээний өгөгдлийг боловсруулдаг алдааны шалтгаан нь ихэвчлэн тохиолддог. Шөнийн цагаар ийм зүйл хийхийг зөвлөж байна. Ийм хуваарьт ажлыг ажлын бус цагаар гүйцэтгэх хуваарь гарга.

Ингэснээр хэрэглэгчид хоёулаа тогтвортой системд ажиллах бөгөөд хэрэглэгчийн сесстэй зөрчилдөх магадлал буурах тул төлөвлөсөн ажлууд өөрсдөө амжилттай дуусах болно.

"Гадуурсан хуралдаанууд"

Хэрэглэгчдийн "өлгөгдсөн сесс" -ийн асуудал нь 1С үйлчилгээтэй тулгарсан бараг бүх хүмүүст мэддэг. Хэрэглэгч програмаас аль эрт гарах эсвэл баримтыг хааж болох байсан ч түүний сесс системд хэвээр байна. Асуудал нь ихэвчлэн ганц бие байдаг бөгөөд администраторын консолоор дамжуулан ийм сессийг дуусгахад хангалттай. Суурь ажилтай ижил асуудал үүсч болно.

Интернет дэх олон тооны сэтгэгдлээс харахад сүлжээний аюулгүй байдлын түлхүүрийг ашиглах үед ийм нөхцөл байдал илүү их тохиолддог. Хэрэв "өлгөгдсөн сесс" -тэй холбоотой нөхцөл байдал системтэйгээр давтагддаг бол энэ нь систем болон серверүүдийг сайтар шалгаж, засвар үйлчилгээ хийх шалтгаан болдог (хэрэв суурь нь үйлчлүүлэгч-сервер бол).

Тохиргоо бичих явцад гарсан алдаа

Бүх ердийн тохиргоог мэргэшсэн мэргэжилтэн, мэргэжилтнүүд боловсруулдаг. Систем бүрийг сайтар шалгаж, илүү хурдан бөгөөд зөв ажиллахын тулд оновчтой болгосон.

Үүнтэй холбогдуулан алдааны шалтгаан нь гуравдагч талын хөгжүүлэгчийн бичсэн оновчтой бус код байж магадгүй юм. Энэ нь удаан хугацааны туршид өгөгдлийг хаах "хүнд" хүсэлт байж магадгүй юм. Гүйцэтгэл багатай, логикийг зөрчсөн алгоритмуудыг бүтээх нь бас түгээмэл биш юм.

Хэрэв програмыг шинэчилсний дараа үүссэн бол хөгжүүлэгчийн алдаанаас болж түгжээний зөрчил үүссэн байх магадлалтай. Шалгахын тулд та сайжруулалтыг "буцааж" эсвэл кодыг дахин засах боломжтой.