“ ข้อขัดแย้งในการล็อคเมื่อดำเนินธุรกรรม: เกินเวลารอสูงสุดในการให้การล็อค” เป็นข้อผิดพลาดที่พบบ่อยใน 1C 8.3 และ 8.2 ที่เกี่ยวข้องกับการแข่งขันสำหรับการใช้ทรัพยากรในระบบ

ระบบ 1C ช่วยให้ผู้ใช้จำนวนมากสามารถทำงานแบบขนานได้ ตามที่การทดสอบโหลดแสดงให้เห็น ปัจจุบันจำนวนนี้ไม่ได้จำกัดอยู่ที่ผู้ใช้ห้าพันคนที่ทำงานพร้อมกันในระบบ อย่างไรก็ตาม เพื่อให้ฐานข้อมูล 1C 8 สามารถรองรับผู้ใช้จำนวนมากพร้อมกันได้ การกำหนดค่าจะต้องได้รับการออกแบบอย่างเหมาะสม

รับบทเรียนวิดีโอ 267 บทเรียนบน 1C ฟรี:

ดำเนินการจำนวนมาก

มีแนวโน้มว่าผู้ใช้บางรายเปิดตัว เช่น เป็นระยะเวลานานในธุรกรรมเดียว สถาปัตยกรรมของ 1C 8.3 ถือว่าระบบไม่อนุญาตให้เปลี่ยนแปลงข้อมูลที่ใช้ในธุรกรรมหนึ่งโดยผู้ใช้รายอื่นและบล็อกข้อมูลเหล่านั้น

นี่อาจเป็นข้อผิดพลาดชั่วคราวที่จะหยุดเกิดขึ้นเมื่อผู้ใช้รายอื่นใช้งานระบบเสร็จแล้ว หากข้อผิดพลาดนี้เกิดขึ้นบ่อยครั้ง ปัญหาน่าจะเกิดจากสาเหตุอื่น

ข้อผิดพลาดในการกำหนดค่า

นอกจากข้อผิดพลาดในโค้ดแล้ว ยังมีการตัดสินใจที่ไม่ถูกต้องตามระเบียบวิธีอีกด้วย ตัวอย่างเช่น ในตัวมันเองหมายถึงการประมวลผลเอกสารตามลำดับ การบัญชีแบบกลุ่มสามารถแทนที่ด้วย RAUZ ซึ่งจะเพิ่มประสิทธิภาพการทำงานของระบบอย่างจริงจัง

จะแก้ไขข้อผิดพลาดนี้ใน 1C 8.3 ได้อย่างไร

ไม่ว่าในกรณีใด การปรากฏตัวของข้อผิดพลาด "ล็อกข้อขัดแย้งเมื่อดำเนินธุรกรรม" บ่งชี้ถึงความจำเป็นในการตรวจสอบระบบ โดยเฉพาะอย่างยิ่งสำหรับระบบข้อมูลขนาดกลางและขนาดใหญ่ในโหมดไคลเอนต์เซิร์ฟเวอร์ (MS SQL, PostgreSQL ฯลฯ ) หากละเลยสิ่งนี้ตั้งแต่ระยะแรก ผลที่ตามมาที่ไม่สามารถย้อนกลับได้จะเกิดขึ้นในภายหลัง เมื่อการทำงานของระบบมีความสำคัญเป็นพิเศษ (ในช่วงระยะเวลาการรายงาน)

สำหรับการตรวจสอบและแก้ไขข้อผิดพลาด วิธีที่ดีที่สุดคือเลือกพันธมิตรที่เชื่อถือได้ เพียงโทรหาเรา เราจะแก้ไขปัญหาของคุณโดยเร็วที่สุด รายละเอียดในหน้าเพจ

ฉันไม่สามารถเขียนการเปลี่ยนแปลงเพื่อถ่ายโอนไปยังฐานข้อมูลแบบกระจายได้ ดังนั้นฉันจึงติดต่อฝ่ายสนับสนุน 1C และเสนอสิ่งต่อไปนี้ ฉันแก้ไขมันได้ง่ายๆ ด้วยการรีบูตแอปพลิเคชันเซิร์ฟเวอร์และเซิร์ฟเวอร์ SQL โดยทั่วไป คุณสามารถเลือกช่อง “การบล็อกกฎระเบียบได้
รวมงาน"
นอกจากนี้ยังช่วยได้โดยไม่ต้องรีบูตเครื่อง

การดำเนินงานประจำในระดับ DBMS สำหรับ MS SQL Server

คำแนะนำในการดำเนินการตามปกติในระดับ DBMS

ข้อมูลนี้ใช้กับ 1C:Enterprise 8 เวอร์ชันไคลเอ็นต์-เซิร์ฟเวอร์ เมื่อใช้ MS SQL Server DBMS

ข้อมูลทั่วไป

สาเหตุที่พบบ่อยที่สุดประการหนึ่งสำหรับการทำงานของระบบที่ไม่เหมาะสมคือการดำเนินการตามปกติที่ระดับ 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 N "อัปเดตสถิติหรือไม่ ด้วย FULLSCAN"

การอัปเดตสถิติไม่นำไปสู่การล็อกตารางและจะไม่รบกวนการทำงานของผู้ใช้รายอื่น สามารถอัพเดตสถิติได้บ่อยเท่าที่จำเป็น ควรคำนึงว่าภาระบนเซิร์ฟเวอร์ DBMS จะเพิ่มขึ้นขณะอัปเดตสถิติซึ่งอาจส่งผลเสียต่อประสิทธิภาพโดยรวมของระบบ

ความถี่ที่เหมาะสมที่สุดสำหรับการอัปเดตสถิติขึ้นอยู่กับขนาดและลักษณะของโหลดบนระบบ และถูกกำหนดโดยการทดลอง แนะนำให้อัพเดตสถิติ อย่างน้อยวันละครั้ง.

แบบสอบถามด้านบนจะอัปเดตสถิติสำหรับตารางทั้งหมดในฐานข้อมูล ในระบบในชีวิตจริง ตารางที่ต่างกันต้องการอัตราการอัปเดตสถิติที่แตกต่างกัน ด้วยการวิเคราะห์แผนการสืบค้น คุณสามารถระบุได้ว่าตารางใดที่ต้องการการอัปเดตสถิติบ่อยครั้งที่สุด และตั้งค่าขั้นตอนประจำที่แตกต่างกันสองขั้นตอน (หรือมากกว่า) ได้แก่ สำหรับตารางที่อัปเดตบ่อยครั้งและสำหรับตารางอื่นๆ ทั้งหมด วิธีการนี้จะช่วยลดเวลาในการอัปเดตสถิติและผลกระทบของกระบวนการอัปเดตสถิติต่อการทำงานของระบบโดยรวมได้อย่างมาก

การตั้งค่าการอัพเดตสถิติอัตโนมัติ (MS SQL 2005)

เรียกใช้ MS SQL Server Management Studio และเชื่อมต่อกับเซิร์ฟเวอร์ DBMS เปิดโฟลเดอร์การจัดการและสร้างแผนการบำรุงรักษาใหม่:

สร้างแผนย่อย (เพิ่มแผนย่อย) และตั้งชื่อว่า “การอัปเดตสถิติ” เพิ่มงาน Update Statistics จากทาสก์บาร์:

กำหนดตารางการอัพเดตสถิติ แนะนำให้อัพเดตสถิติอย่างน้อยวันละครั้ง หากจำเป็น สามารถเพิ่มความถี่ในการอัปเดตสถิติได้

กำหนดการตั้งค่างาน โดยดับเบิลคลิกที่งานที่มุมล่างขวาของหน้าต่าง ในแบบฟอร์มที่ปรากฏขึ้น ให้ระบุชื่อของฐานข้อมูล (หรือหลายฐานข้อมูล) ที่จะอัปเดตสถิติ นอกจากนี้ คุณยังสามารถระบุได้ว่าควรอัปเดตสถิติของตารางใด (หากคุณไม่ทราบว่าต้องระบุตารางใดอย่างแน่ชัด ให้ตั้งค่าเป็นทั้งหมด)

สถิติจะต้องได้รับการอัปเดตโดยเปิดใช้งานตัวเลือกการสแกนแบบเต็ม

บันทึกแผนที่สร้างขึ้น เมื่อถึงเวลาที่ระบุในกำหนดการ การอัปเดตสถิติจะเริ่มขึ้นโดยอัตโนมัติ

การล้างแคชขั้นตอน

เครื่องมือเพิ่มประสิทธิภาพ MS SQL Server แคชแผนการสอบถามสำหรับการดำเนินการใหม่ การทำเช่นนี้เพื่อประหยัดเวลาที่ใช้ในการคอมไพล์แบบสอบถาม หากมีการดำเนินการแบบสอบถามเดียวกันและทราบแผนของแบบสอบถามแล้ว

เป็นไปได้ว่า MS SQL Server จะสร้างแผนการสืบค้นที่ไม่เหมาะสมซึ่งใช้ข้อมูลทางสถิติที่ล้าสมัย แผนนี้จะถูกจัดเก็บไว้ในแคชขั้นตอนและใช้เมื่อมีการเรียกแบบสอบถามเดียวกันอีกครั้ง ถ้าคุณอัปเดตสถิติแต่ไม่ได้ล้างแคชของขั้นตอน SQL Server อาจเลือกแผนแบบสอบถามเก่า (ต่ำกว่า) จากแคชแทนที่จะสร้างแผนใหม่ (เหมาะสมที่สุด)

เมื่อต้องการล้างแคชขั้นตอนของ MS SQL Server คุณจำเป็นต้องเรียกใช้แบบสอบถาม SQL ต่อไปนี้:

ควรเรียกใช้แบบสอบถามนี้ทันทีหลังจากอัปเดตสถิติ ดังนั้นความถี่ของการดำเนินการควรตรงกับความถี่ของการอัปเดตสถิติ

การตั้งค่าการล้างแคชตามขั้นตอน (MS SQL 2005)

เนื่องจากต้องล้างแคชขั้นตอนทุกครั้งที่อัปเดตสถิติ จึงแนะนำให้เพิ่มการดำเนินการนี้ลงในแผนย่อย "การอัปเดตสถิติ" ที่สร้างไว้แล้ว เมื่อต้องการทำเช่นนี้ ให้เปิดแผนย่อยและเพิ่มงาน Execute T-SQL Statement ไปยังสคีมา จากนั้นคุณควรเชื่อมต่อ Update Statistics Task ด้วยลูกศรเข้ากับงานใหม่

ในข้อความของงาน Execute T-SQL Statement ที่สร้างขึ้น คุณควรระบุคำขอ “DBCC FREEPROCCACHE”:

การจัดเรียงข้อมูลดัชนี

เมื่อทำงานอย่างเข้มข้นกับตารางฐานข้อมูล ผลกระทบของการกระจายตัวของดัชนีจะเกิดขึ้น ซึ่งอาจส่งผลให้ประสิทธิภาพของคิวรีลดลง

sp_msforeachtable N "ดัชนี DBCC DEFRAG (<имя базы данных>, ""?"")"

ดัชนีการจัดเรียงข้อมูลไม่ล็อคตารางและจะไม่รบกวนการทำงานของผู้ใช้รายอื่น แต่จะสร้างภาระเพิ่มเติมบน SQL Server ควรเลือกความถี่ที่เหมาะสมที่สุดในการดำเนินการขั้นตอนประจำนี้ตามโหลดบนระบบและผลที่ได้รับจากการจัดเรียงข้อมูล ขอแนะนำให้คุณจัดเรียงข้อมูลดัชนีอย่างน้อยสัปดาห์ละครั้ง

คุณสามารถจัดเรียงตารางตั้งแต่หนึ่งตารางขึ้นไป แทนที่จะจัดเรียงตารางทั้งหมดในฐานข้อมูล

การตั้งค่าการจัดเรียงข้อมูลดัชนี (MS SQL 2005)

ในแผนการบำรุงรักษาที่สร้างไว้ก่อนหน้านี้ ให้สร้างแผนย่อยใหม่ชื่อ "การทำดัชนีใหม่" เพิ่มงานสร้างดัชนีใหม่ลงไป:

กำหนดตารางการดำเนินการสำหรับงานจัดเรียงข้อมูลดัชนี ขอแนะนำให้ดำเนินการอย่างน้อยสัปดาห์ละครั้ง และหากข้อมูลในฐานข้อมูลมีความผันแปรสูง บ่อยครั้งมากขึ้น - มากถึงวันละครั้ง

การจัดทำดัชนีตารางฐานข้อมูลใหม่

การทำดัชนีตารางใหม่เกี่ยวข้องกับการสร้างดัชนีตารางฐานข้อมูลใหม่ทั้งหมด ซึ่งนำไปสู่การเพิ่มประสิทธิภาพการทำงานอย่างมีนัยสำคัญ ขอแนะนำให้จัดทำดัชนีตารางฐานข้อมูลของคุณใหม่เป็นประจำ หากต้องการสร้างดัชนีตารางฐานข้อมูลทั้งหมดใหม่ คุณต้องเรียกใช้แบบสอบถาม SQL ต่อไปนี้:

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

การจัดทำดัชนีตารางใหม่จะล็อกตารางไว้ตลอดระยะเวลาการดำเนินการ ซึ่งอาจส่งผลต่อประสบการณ์ผู้ใช้อย่างมาก ในเรื่องนี้ ขอแนะนำให้ทำการจัดทำดัชนีใหม่ระหว่างโหลดระบบขั้นต่ำ

หลังจากการจัดทำดัชนีใหม่เสร็จสิ้นแล้ว ไม่จำเป็นต้องจัดเรียงข้อมูลดัชนีอีกต่อไป

การตั้งค่าการจัดทำดัชนีตารางใหม่ (MS SQL 2005)

ในแผนการบำรุงรักษาที่สร้างขึ้นก่อนหน้านี้ ให้สร้างแผนย่อยใหม่ชื่อ Index Defragmentation เพิ่มงาน Rebuild Index เข้าไป:

กำหนดตารางการดำเนินการสำหรับงานจัดทำดัชนีตารางใหม่ ขอแนะนำให้ดำเนินการนี้ระหว่างโหลดระบบขั้นต่ำ อย่างน้อยสัปดาห์ละครั้ง

ตั้งค่างานโดยระบุฐานข้อมูล (หรือหลายฐานข้อมูล) และเลือกตารางที่ต้องการ หากคุณไม่ทราบว่าควรระบุตารางใดอย่างแน่ชัด ให้ตั้งค่าเป็นทั้งหมด

เมื่อผู้ใช้หลายร้อยคนทำงานกับโปรแกรมและข้อมูลพร้อมกัน ปัญหาก็เกิดขึ้นซึ่งเป็นลักษณะเฉพาะของโซลูชันขนาดใหญ่เท่านั้น เรากำลังพูดถึงปัญหาที่เกิดจากการบล็อกข้อมูล

บางครั้งผู้ใช้เรียนรู้เกี่ยวกับการบล็อกจากข้อความที่ระบุว่าไม่สามารถเขียนข้อมูลหรือดำเนินการอื่นได้ บางครั้งเนื่องจากประสิทธิภาพของโปรแกรมลดลงอย่างมาก (เช่น เมื่อเวลาที่ต้องใช้ในการดำเนินการเพิ่มขึ้นหลายสิบหรือหลายร้อยครั้ง)

ปัญหาที่เกิดจากการบล็อคไม่มีวิธีแก้ปัญหาทั่วไป ดังนั้นเราจะพยายามวิเคราะห์สาเหตุของปัญหาดังกล่าวและจัดระบบทางเลือกในการแก้ไขปัญหาเหล่านั้น

เหตุผลในการบล็อกธุรกรรม

ก่อนอื่นมาจำกันก่อนว่าล็อคคืออะไรและในขณะเดียวกันก็พิจารณาว่าจำเป็นหรือไม่ เรามาดูตัวอย่างคลาสสิกของการอุดตันที่เราพบในชีวิตกันดีกว่า

ตัวอย่างที่ 1: การซื้อตั๋วเครื่องบินหรือรถไฟ สมมติว่าเราแสดงความปรารถนาของเราต่อแคชเชียร์ แคชเชียร์แจ้งที่นั่งว่างให้เราทราบ ซึ่งเราจะสามารถเลือกที่นั่งที่เราชอบที่สุดได้ (แน่นอนว่ามีหลายที่นั่ง) แม้ว่าเราจะเลือกและยืนยันข้อตกลงกับตัวเลือกที่เสนอ ที่นั่งเหล่านี้จะไม่สามารถขายให้กับบุคคลอื่นได้ กล่าวคือ ถูก “บล็อค” ชั่วคราว หากไม่ถูกบล็อก เมื่อถึงเวลายืนยัน อาจมีสถานการณ์ที่ตั๋วที่เราเลือกถูกขายไปแล้ว และในกรณีนี้รอบการคัดเลือกอาจมีจำนวนซ้ำที่ไม่สามารถคาดเดาได้ ระหว่างเลือกสถานที่ก็ขายไปแล้ว!.. ขณะที่เราเลือกที่อื่นก็ไม่มีแล้ว...

ตัวอย่างที่ 2: การซื้อของในร้านค้าหรือที่ตลาดสด เราเดินไปที่เคาน์เตอร์และเลือกแอปเปิ้ลที่สวยที่สุดจากที่มีอยู่หลายร้อยผล พวกเขาเลือกมันและล้วงเข้าไปในกระเป๋าเพื่อเงิน จะเป็นอย่างไรหากในขณะนั้นเรากำลังนับเงินแอปเปิ้ลที่เราเลือกไว้จะถูกขายให้กับผู้ซื้อที่เข้ามาช้ากว่าเรา?

ดังนั้นการปิดกั้นตัวเองจึงเป็นปรากฏการณ์ที่จำเป็นและมีประโยชน์ ต้องขอบคุณการบล็อกที่เรารับประกันว่าการดำเนินการจะเสร็จสิ้นในขั้นตอนเดียว และสิ่งที่มักนำไปสู่การปฏิเสธไม่ใช่การใช้งานซอฟต์แวร์ที่ประสบความสำเร็จมากที่สุด ตัวอย่างเช่น:

• วัตถุจำนวนมากเกินไป (ตั๋ว, แอปเปิ้ล) ถูกบล็อก
• เวลาในการบล็อกถูกขยายออกไปอย่างไม่สมเหตุสมผล

การบล็อกมากเกินไปในการกำหนดค่า 1C ทั่วไป

ในโครงการขนาดใหญ่ ตามกฎแล้วเราใช้ 1C:Enterprise ดังนั้นเราจะพยายามอธิบายคำแนะนำเชิงปฏิบัติสำหรับการแก้ปัญหาการบล็อกโดยใช้ตัวอย่างของชุดค่าผสม 1C:Enterprise + MS-SQL

1C:Enterprise รุ่นที่ 8 มอบการใช้งานแบบขนานที่ดีมาก ผู้ใช้จำนวนมากสามารถทำงานพร้อมกันด้วยการกำหนดค่าเดียว (นั่นคือบนฐานเดียว) กับเซิร์ฟเวอร์และช่องทางการสื่อสารปกติ ตัวอย่างเช่น เจ้าของร้านหลายร้อยคนดำเนินการออกหรือรับสินค้า นักเศรษฐศาสตร์คำนวณค่าแรงสำหรับแผนกต่างๆ ไปพร้อมๆ กัน นักบัญชีดำเนินการคำนวณและจ่ายเงินเดือน ฯลฯ

แต่มีเหตุผลว่าทำไมจึงมีความคิดเห็นที่ตรงกันข้าม - ตำนานที่ว่าด้วยการใช้งานพร้อมกันอย่างเข้มข้นการทำงานกับโซลูชันที่ใช้ 1C:Enterprise นั้นอึดอัดหรือเป็นไปไม่ได้ ท้ายที่สุดทันทีที่โซลูชันมาตรฐานสำหรับ 1C:Enterprise เริ่มมีการใช้งานโดยผู้ใช้หลายร้อยคนในระดับอุตสาหกรรม หน้าต่างจะปรากฏขึ้นบนหน้าจอมากขึ้นเรื่อย ๆ พร้อมข้อความที่น่าภาคภูมิใจ: "เกิดข้อผิดพลาดเมื่อเรียกวิธีบริบท (เขียน) : การล็อกข้อขัดแย้งเมื่อดำเนินธุรกรรม: ..." และอื่นๆ ขึ้นอยู่กับประเภทของเซิร์ฟเวอร์ SQL ที่ใช้ บางอย่างเช่น "Microsoft OLE DB Provider for SQL Server: เกินระยะเวลาหมดเวลาการร้องขอการล็อก …”.

โซลูชันมาตรฐานเกือบทั้งหมดในการใช้งานแบบสำเร็จรูปที่เสนอได้รับการกำหนดค่าสำหรับการจัดการล็อคอัตโนมัติ “อัตโนมัติ” ในที่นี้อาจถูกมองว่าเป็น “หวาดระแวง” ในกรณีที่เมื่อประมวลผลเอกสารใด ๆ เราจะบล็อกทุกสิ่งที่อาจเชื่อมโยงกับเอกสารนั้น ปรากฎว่าเมื่อผู้ใช้คนหนึ่งทำอะไรบางอย่าง (และบางครั้งก็แค่เขียนลงไป) ส่วนที่เหลือก็ได้แต่รอเท่านั้น

ฉันจะแสดงความคิดเห็นว่าทำไม 1C ตัดสินใจไม่กำหนดค่าโซลูชันมาตรฐานสำหรับการใช้งานแบบขนานในระดับสูง ต้นทุนค่าแรงสำหรับการปรับเปลี่ยนดังกล่าวไม่สูง - หลาย "เดือนคน" ซึ่งไม่สำคัญในระดับ 1C สำหรับฉันดูเหมือนว่าเหตุผลนั้นแตกต่างออกไป

ประการแรกการปรับเปลี่ยนดังกล่าวทำให้การประมวลผลเอกสารทั้งหมดมีความซับซ้อนอย่างมาก ซึ่งหมายความว่าสำหรับผู้บริโภคที่ใช้ 1C สำหรับงานเล็ก ๆ จะมีเพียงข้อเสียเปรียบโดยไม่ได้รับผลประโยชน์ใด ๆ - ความยากในการปรับเปลี่ยนการกำหนดค่ามาตรฐานจะซับซ้อนมากขึ้น สถิติในเวลาเดียวกันแนะนำว่าลูกค้าประเภทใดที่เป็นช่องทางการให้อาหารหลักสำหรับ 1C...

เหตุผลที่สองฝังอยู่ในการตั้งค่าพื้นฐานทั่วไปของเซิร์ฟเวอร์ SQL เช่น MS-SQL ซึ่งยังคงใช้บ่อยกว่าผู้อื่น มันเพิ่งเกิดขึ้นที่ลำดับความสำคัญในการตั้งค่าถูกมอบให้กับการบันทึก RAM ของเซิร์ฟเวอร์ แทนที่จะลดการบล็อก สิ่งนี้นำไปสู่ความจริงที่ว่าหากจำเป็นต้องล็อคหลายแถวเซิร์ฟเวอร์ SQL จะทำการตัดสินใจ "ประหยัดหน่วยความจำและโปรเซสเซอร์" - เพื่อล็อคทั้งตารางในครั้งเดียว!..

ข้อบกพร่องเหล่านี้ในโซลูชันมาตรฐานหรือข้อมูลเฉพาะของการตั้งค่าเซิร์ฟเวอร์ฐานข้อมูลที่ใช้ มักถูกระบุด้วยปัญหาที่เกิดจากการบล็อก เป็นผลให้ข้อบกพร่องทางเทคนิคนำไปสู่ปัญหาองค์กรที่สำคัญมาก ท้ายที่สุดแล้ว หากพนักงานได้รับเหตุผลให้ถูกรบกวนจากงานหรือให้เหตุผลว่าทำไมงานถึงไม่สำเร็จ คนกลุ่มน้อยก็จะทำงานได้อย่างมีประสิทธิภาพ ข้อความเกี่ยวกับการบล็อกธุรกรรมหรือโปรแกรม "เบรก" นั้นเป็นเหตุผลในอุดมคติว่าทำไมบางสิ่งถึงไม่สามารถทำได้

คำแนะนำสำหรับการกำจัดการบล็อกที่มากเกินไปสำหรับ 1C: ENTERPRISE

จะทำอย่างไรถ้าการแก้ปัญหาการล็อคมากเกินไปเป็นเรื่องสำคัญ?

ในขั้นตอนสุดท้ายของการใช้งานคอมเพล็กซ์ขนาดใหญ่ทั้งหมด จำเป็นต้องดำเนินการปรับแต่งอย่างละเอียดเพื่อกำจัดการบล็อกธุรกรรมที่ไม่จำเป็น เป็นสิ่งสำคัญในการแก้ไขปัญหาที่อาจเกิดขึ้นเนื่องจากเงื่อนไขการบล็อกหรือเทคนิคการใช้งานที่พัฒนาไม่เพียงพอ

เพราะ การดำเนินการนี้มีความสำคัญอย่างยิ่งและต้องทำอย่างต่อเนื่อง ดังนั้น เพื่อให้การปรับเปลี่ยนดังกล่าวง่ายขึ้น เราได้จัดทำคำแนะนำพื้นฐานจำนวนหนึ่งที่เราพยายามปฏิบัติตาม คำแนะนำที่ได้รับและทดสอบผ่านประสบการณ์การใช้งานขนาดใหญ่จำนวนมาก

1. หาก DBMS หรือระบบการพัฒนาที่คุณใช้ (เช่น 1C:Enterprise) ใช้โหมดการล็อคข้อมูลอัตโนมัติตามค่าเริ่มต้น ให้ปฏิเสธการจัดการการล็อคอัตโนมัติ กำหนดค่ากฎการบล็อกด้วยตนเอง อธิบายเกณฑ์ในการบล็อกทั้งตารางหรือแต่ละแถว
2. เมื่อพัฒนาโปรแกรม ทุกครั้งที่เป็นไปได้ ให้เข้าถึงตารางในลำดับเดียวกัน
3. พยายามอย่าเขียนลงในตารางเดียวกันหลายครั้งภายในธุรกรรมเดียวกัน หากเป็นเรื่องยาก อย่างน้อยก็ลดช่วงเวลาระหว่างการดำเนินการเขียนครั้งแรกและครั้งสุดท้ายให้เหลือน้อยที่สุด
4. วิเคราะห์ความเป็นไปได้ของการปิดใช้งานการเลื่อนระดับการล็อกในระดับเซิร์ฟเวอร์ SQL
5. แจ้งให้ผู้ใช้ทราบอย่างชัดเจนถึงสาเหตุที่ไม่สามารถดำเนินการใดๆ ได้หากเกิดจากการบล็อก ให้คำแนะนำที่เข้าถึงได้และเข้าใจได้เกี่ยวกับสิ่งที่ต้องทำต่อไป

หากคุณดูคำแนะนำอย่างละเอียดก็จะชัดเจนว่า การทดสอบดังกล่าวมีความเหมาะสมไม่เพียงแต่สำหรับ 1C:Enterprise เท่านั้น แต่ยังสำหรับระบบอื่นๆ ด้วย. ไม่สำคัญเลยว่าพวกเขาเขียนด้วยภาษาใดและทำงานกับเซิร์ฟเวอร์ฐานข้อมูลใด คำแนะนำส่วนใหญ่มีลักษณะเป็นสากล ดังนั้นจึงใช้ได้เท่าเทียมกันเมื่อใช้ 1C:Enterprise และสำหรับโปรแกรม "ที่เขียนเองที่บ้าน" หรือระบบ ERP "ชนิดบรรจุกล่อง" อื่นๆ

ป.ล. คุณรู้ไหมว่าเราให้ความช่วยเหลืออย่างมืออาชีพในการอัปเดต 1C ในราคาที่ดีที่สุด

แท็กที่จะค้นหา:

• ล็อคธุรกรรม
• ขจัดสิ่งอุดตัน
• ล็อค 1C
• ล็อค
• ล็อคข้อขัดแย้ง
• ล็อคการโต้แย้งระหว่างการทำธุรกรรม

ไม่ใช่เรื่องแปลกเมื่อทำงานใน 1C ที่จะได้รับข้อผิดพลาด "ล็อกข้อขัดแย้งเมื่อดำเนินการธุรกรรม: เกินเวลารอสูงสุดในการให้ล็อก" สาระสำคัญอยู่ที่ความจริงที่ว่าหลายเซสชันพยายามดำเนินการที่คล้ายกันพร้อมกันซึ่งส่งผลกระทบต่อทรัพยากรเดียวกัน วันนี้เราจะมาดูวิธีแก้ไขข้อผิดพลาดนี้

มีการดำเนินการจำนวนมาก

ขั้นตอนแรกในการหาเหตุผลคือการชี้แจงจำนวนผู้ใช้ที่เกิดขึ้นพร้อมกันในฐานข้อมูลที่เกิดข้อผิดพลาดดังกล่าว ดังที่เราทราบ จำนวนสูงสุดอาจมีค่อนข้างมาก นี่ทั้งหนึ่งพันและห้าพัน

กลไกของการล็อคและการทำธุรกรรมอธิบายไว้ในคู่มือของนักพัฒนา ใช้เมื่อหลายเซสชันเข้าถึงข้อมูลเดียวกันพร้อมกัน เป็นเหตุผลที่ผู้ใช้รายอื่นไม่สามารถเปลี่ยนแปลงข้อมูลเดียวกันในเวลาเดียวกันได้

คุณควรตรวจสอบด้วยว่ามีผู้ใช้รายใดกำลังประมวลผลการเปลี่ยนแปลงข้อมูลจำนวนมากหรือไม่ อาจจะเป็นประมาณปลายเดือนและอื่นๆ ในกรณีนี้ หลังจากการประมวลผลเสร็จสิ้น ข้อผิดพลาดจะหายไปเอง

งานที่กำหนดเวลาไว้

ไม่ใช่เรื่องแปลกที่สาเหตุของข้อผิดพลาดจะอยู่ในระบบที่ประมวลผลข้อมูลจำนวนมาก ขอแนะนำให้ทำสิ่งนี้ในเวลากลางคืน กำหนดตารางเวลาการปฏิบัติงานประจำดังกล่าวนอกเวลาทำงาน

ด้วยวิธีนี้ ผู้ใช้จะทำงานในระบบที่เสถียร และงานประจำเองก็จะสำเร็จลุล่วงได้สำเร็จ เนื่องจากโอกาสที่จะเกิดข้อขัดแย้งกับเซสชันผู้ใช้จะลดลง

"เซสชันที่หยุดทำงาน"

ปัญหา "เซสชันที่ค้าง" ของผู้ใช้เป็นเรื่องที่คุ้นเคยสำหรับเกือบทุกคนที่พบกับการบำรุงรักษา 1C ผู้ใช้อาจออกจากโปรแกรมไปนานแล้วหรือปิดเอกสาร แต่เซสชันของเขายังคงอยู่ในระบบ ปัญหาส่วนใหญ่มักถูกแยกออกจากกันและเพียงพอที่จะยุติเซสชันดังกล่าวผ่านคอนโซลผู้ดูแลระบบ ปัญหาเดียวกันนี้อาจเกิดขึ้นได้กับงานเบื้องหลัง

ตามความคิดเห็นมากมายบนอินเทอร์เน็ต สถานการณ์ดังกล่าวพบได้บ่อยมากขึ้นเมื่อใช้คีย์ความปลอดภัยเครือข่าย หากสถานการณ์ที่มี "เซสชันค้าง" เกิดขึ้นซ้ำอย่างเป็นระบบ นี่เป็นเหตุผลในการตรวจสอบและบำรุงรักษาระบบและเซิร์ฟเวอร์อย่างละเอียด (หากฐานข้อมูลเป็นไคลเอนต์ - เซิร์ฟเวอร์)

ข้อผิดพลาดเมื่อเขียนการกำหนดค่า

การกำหนดค่ามาตรฐานทั้งหมดได้รับการพัฒนาโดยผู้เชี่ยวชาญและผู้เชี่ยวชาญที่มีคุณสมบัติเหมาะสม แต่ละระบบได้รับการทดสอบอย่างละเอียดและปรับให้เหมาะสมเพื่อการทำงานที่รวดเร็วและถูกต้องมากขึ้น

ในเรื่องนี้สาเหตุของข้อผิดพลาดอาจอยู่ในโค้ดที่ไม่ดีซึ่งเขียนโดยนักพัฒนาบุคคลที่สาม นี่อาจเป็นคำขอ "จำนวนมาก" ที่จะบล็อกข้อมูลเป็นระยะเวลานาน นอกจากนี้ยังมีกรณีของการสร้างอัลกอริธึมที่มีประสิทธิภาพต่ำและมีการละเมิดตรรกะอยู่บ่อยครั้ง

มีความเป็นไปได้สูงที่ข้อขัดแย้งในการล็อคเกิดขึ้นอย่างแน่นอนเนื่องจากข้อผิดพลาดของนักพัฒนาหากเกิดขึ้นหลังจากการอัพเดตโปรแกรม หากต้องการตรวจสอบ คุณสามารถ "ย้อนกลับ" การปรับปรุงหรือปรับโครงสร้างโค้ดใหม่ได้

ในระบบที่มีผู้ใช้หลายคน การจัดโครงสร้างที่ถูกต้องและการตั้งค่าการล็อคมีบทบาทสำคัญ หากไม่มี ผู้ใช้มักจะต้องจัดการกับข้อผิดพลาดที่เกิดจากการแข่งขันแย่งชิงทรัพยากรระบบบางอย่าง แต่มีปัญหาข้อขัดแย้งในการล็อคที่ผู้ใช้หลายคนคุ้นเคย เหตุใดข้อขัดแย้งในการล็อค 1C จึงเกิดขึ้นและจะแก้ไขได้อย่างไร

ล็อคข้อขัดแย้งใน 1C 8.3 และความหมาย

สำหรับผู้ใช้ส่วนใหญ่ ข้อความเกี่ยวกับข้อขัดแย้งในการล็อค 1C หมายถึงข้อผิดพลาดที่ทำให้พวกเขาไม่สามารถทำงานได้ พวกเขาต้องการกำจัดปัญหานี้โดยเร็วที่สุดและปิดล้อมแผนกไอทีด้วยการร้องเรียนว่า "1C ใช้งานไม่ได้"

แต่สำหรับผู้ดูแลระบบและนักพัฒนาข้อความดังกล่าวระบุว่าอาจมีปัญหาในโครงสร้างการกำหนดค่า ก่อนที่คุณจะพยายามทำให้ผู้ใช้พอใจและกำจัดการอุดตันคุณต้องวิเคราะห์สถานการณ์และทำความเข้าใจสาเหตุของข้อความแสดงข้อผิดพลาด

เหตุผลในการบล็อกข้อผิดพลาดใน 1C

การทดสอบโหลดสาธิตแสดงให้เห็นว่าเซิร์ฟเวอร์ 1C สามารถทนต่อการทำงานแบบขนานของผู้ใช้มากกว่าห้าพันคน แต่สภาวะในอุดมคติสำหรับการทดลองดังกล่าวนั้นไม่สามารถบรรลุได้ในสภาพแวดล้อมประจำวันของบริษัทขนาดใหญ่และขนาดกลาง เพื่อให้บรรลุประสิทธิภาพที่คล้ายคลึงกันและการดำเนินงานที่ปราศจากข้อผิดพลาด การกำหนดค่าจะต้องได้รับการออกแบบอย่างเหมาะสมและปรับแต่งให้เหมาะกับกระบวนการทางธุรกิจเฉพาะขององค์กร

หากเราไม่ใช้ตัวเลือกในอุดมคติ ข้อขัดแย้งในการล็อค 1C จะเกิดขึ้นด้วยเหตุผลดังต่อไปนี้:

การทำงานพร้อมกันของผู้ใช้ที่มีข้อมูลจำนวนมากสาเหตุที่แท้จริงนี้กำหนดโดยกลไกภายในของ 1C พวกเขาเกี่ยวข้องกับการห้ามการเปลี่ยนแปลงข้อมูลที่เกี่ยวข้องกับธุรกรรมที่เปิดตัวในนามของผู้ใช้รายอื่น

ข้อผิดพลาดและการละเว้นในการกำหนดค่าโครงสร้างของโซลูชันมาตรฐานจากบริษัท 1C คำนึงถึงคำแนะนำเพื่อเพิ่มผลผลิตสูงสุด แต่นักพัฒนาบุคคลที่สามไม่ได้ปฏิบัติตามมาตรฐานระดับสูงเสมอไป และมักพบข้อบกพร่องต่อไปนี้ในโค้ดของพวกเขา:

• ข้อความค้นหาที่ไม่เหมาะสม;
• ขอยอดคงเหลือเมื่อเริ่มดำเนินการ
• ความเข้าใจผิดเกี่ยวกับวัตถุประสงค์ของออบเจ็กต์การกำหนดค่าและการใช้งานที่ไม่ถูกต้อง
• ความซ้ำซ้อนของอินเตอร์ล็อคที่สร้างขึ้นในระบบหรือการพัฒนาเพิ่มเติม

วิธีแก้ไขข้อขัดแย้งในการล็อคใน 1C 8.3

ข้อความของระบบ "การล็อกข้อขัดแย้งเมื่อดำเนินการธุรกรรม 1C 8.3" ไม่ได้ระบุลักษณะของการกำหนดค่าตามการออกแบบที่ไม่ถูกต้อง แต่หากละเลยสัญญาณดังกล่าว ก็มีโอกาสที่จะประสบปัญหาใหญ่ในช่วงเวลาที่สำคัญที่สุด เช่น เมื่อส่งรายงานรายไตรมาสหรือประจำปี ที่ดีที่สุดคือระบบที่เชื่องช้าและผู้ใช้ไม่พอใจ ที่แย่ที่สุด ข้อมูลเอาต์พุตไม่ถูกต้อง ซึ่งอาจนำไปสู่บทลงโทษจากหน่วยงานกำกับดูแล

วิธีแก้ปัญหาข้อขัดแย้งในการล็อคใน 1C 8.3 คือการถ่ายโอนการกำหนดค่าไปยังโหมดการจัดการล็อคที่ได้รับการจัดการ (ด้วยตนเอง) ใช้งานในเวอร์ชัน 8.1 กลไกที่อยู่ในมือของผู้เชี่ยวชาญที่มีความสามารถช่วยแก้ปัญหาข้อขัดแย้งในการล็อคระหว่างธุรกรรมใน 1C

แต่ควรจำไว้ว่าการกระทำนี้จะลดระดับการปกป้องข้อมูลจากการเปลี่ยนแปลงในขณะที่ผู้ใช้รายอื่นอ่าน ดังนั้นหากคุณไม่พร้อมที่จะควบคุมการล็อคทั้งหมดในระบบอย่างอิสระอย่ารีบเร่งที่จะเปลี่ยนการตั้งค่ากำหนด

วิธีแก้ปัญหาข้อขัดแย้งในการล็อค 1C อย่างรวดเร็ว

ในการทำงานของผู้ดูแลระบบหรือนักพัฒนา สถานการณ์อาจเกิดขึ้นเมื่อไม่มีเวลาตรวจสอบข้อผิดพลาดและค้นหาสาเหตุที่แท้จริงของปัญหา ตัวอย่างเช่น จำเป็นต้องส่งรายงานหรือส่งข้อมูลภายในระยะเวลาหนึ่ง แต่ข้อผิดพลาดในการบล็อก 1C จะป้องกันสิ่งนี้

มีสองวิธีในการแก้ปัญหาอย่างรวดเร็ว:

• ค้นหาและสิ้นสุดเซสชันที่บล็อกข้อมูลที่จำเป็น ในบริษัทขนาดเล็กที่จำนวนผู้ใช้ 1C ไม่เกินสองสามโหล นี่เป็นทางออกที่ดีที่สุด
• หากคุณควบคุมระบบที่มีพนักงานหลายร้อยคน การค้นหาเซสชันที่เหมาะสมโดยไม่ต้องใช้ซอฟต์แวร์พิเศษอาจใช้เวลานาน ในกรณีนี้ การรีสตาร์ทเซิร์ฟเวอร์จะมีประสิทธิภาพมากกว่ามาก

โซลูชันเหล่านี้มีความรุนแรงและมุ่งเป้าไปที่การแก้ปัญหาอย่างรวดเร็วและเพิ่มข้อมูลว่างสำหรับการรายงานเร่งด่วนเท่านั้น สามารถกำจัดให้หมดสิ้นได้โดยการทำความเข้าใจเหตุผลว่าทำไมข้อขัดแย้งในการล็อคจึงเกิดขึ้นเมื่อดำเนินการธุรกรรม 1C หลังจากดำเนินการดังกล่าว จำเป็นต้องค้นหาช่องโหว่ในระบบ เพิ่มประสิทธิภาพการกำหนดค่าหรือการทำงานของพนักงาน ไม่แนะนำให้ใช้มาตรการดังกล่าวอย่างต่อเนื่องในกรณีที่มีข้อขัดแย้งในการล็อคธุรกรรมเป็นประจำ