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

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

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

เหตุผลในการปิดกั้นธุรกรรม

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

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

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

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

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

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

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

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

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

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

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

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

การอัปเดตสถิติต้องทำเมื่อเปิดใช้งานตัวเลือกการสแกนแบบเต็ม

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

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

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

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

หากต้องการล้างแคชขั้นตอนของ MS SQL Server คุณต้องดำเนินการค้นหา SQL ต่อไปนี้:

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

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

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

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

การจัดระเบียบดัชนี

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

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

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

เป็นไปได้ที่จะจัดระเบียบตารางอย่างน้อยหนึ่งตาราง ไม่ใช่ทุกตารางในฐานข้อมูล

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

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

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

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

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

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

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

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

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

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

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

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

สวัสดีทุกคน!

เมื่อวันก่อนที่ทำงาน ฉันพบปัญหาเกี่ยวกับการล็อก กล่าวคือ ข้อความ "ล็อกขัดแย้งขณะดำเนินการธุรกรรม เกินระยะหมดเวลาสูงสุดสำหรับการอนุญาตล็อกแล้ว" เริ่มปรากฏขึ้น

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

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

วันแรก - ปัญหาปรากฏในตอนบ่าย ในตอนแรกดูเหมือนว่าปัญหาจะอยู่ที่ผู้ใช้ระยะไกลที่ติดอยู่ใน Configurator ดูเหมือนว่าการประหารชีวิตจะหยุดลง ณ จุดหนึ่ง และแน่นอนว่าไม่มีการปลดล็อค หลังจากผ่านไปสองสามชั่วโมง เราก็สามารถปล่อยตัวกำหนดค่าได้ แต่ปัญหาก็ยังไม่หายไป มันไม่พึงปรารถนาอย่างยิ่งที่จะฆ่าตัวกำหนดค่าโดยการบังคับบางทีพวกเขาอาจทำงานในนั้น หลังจากนั้น Google ก็เข้ามาแทนที่ ฉันพบบทความในไซต์นี้ ซึ่งระบุวิธีค้นหาการล็อกใน MS SQL DBMS ตรวจสอบแล้ว ไม่มีการล็อกที่ระดับ DBMS แปลก. นอกจากนี้ยังมีความพยายามที่จะปรับเปลี่ยนสิ่งเหล่านั้น นิตยสาร. ตั้งค่า จะทำอย่างไรต่อไป ใน 15 นาที บันทึกสองกิ๊ก! จะอ่านได้อย่างไร มองหาอะไร? ไม่ทราบ

ฉันพบบทความเกี่ยวกับวิธีดูสิ่งที่ถูกบล็อกผ่าน SQL Trace ถึงจะเจอแล้วไง ฉันต้องการเซสชั่น!

เมื่อใกล้ถึงเวลา 16:00 น. เมื่อฉันรู้ว่าไม่สามารถดึงต่อไปได้อีก ฉันจึงทำการรีบูต ด้วยความหวังว่าสิ่งนี้จะไม่เกิดขึ้นอีก (และนี่เป็นกรณีแรกในรอบหกเดือนของการทำงาน) ฉันถอนหายใจด้วยความโล่งอก ทุกอย่างดำเนินไปได้ด้วยดี แต่เปล่าประโยชน์ ... วันที่สอง - สถานการณ์เดียวกัน ฉันขุดเป็นเวลาหนึ่งชั่วโมงครึ่งพยายาม google และอื่น ๆ ที่เข้าใจยากอีกครั้ง ไม่มีผลลัพธ์. รีบูต สุดท้ายก็เกิดขึ้นอีกครั้ง ฉันคิดว่ามันเยี่ยมมาก ฉันจะกลับบ้านอย่างใจเย็นและนั่งลง เจาะลึกลงไป ฉันกลับบ้าน ทุกอย่างเรียบร้อยดี เศร้า.

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

อย่างแรกคือการตั้งค่าบันทึก ใช่ ฉันไม่สามารถทำได้หากไม่มีมัน แต่ตอนนี้ฉันสามารถอ่านได้ เราตั้งค่าสองเหตุการณ์: ครั้งแรกคือ TLOCK ครั้งที่สองคือ TTIMEOUT รายการแรกแสดงเหตุการณ์การบล็อกทั้งหมด รายการที่สองแสดงการบล็อกที่ไม่สามารถสร้างได้ในเวลาที่กำหนด ในความเป็นจริง TTIMEOUT เท่านั้นก็เพียงพอแล้ว

เราคัดลอกไฟล์บันทึกทางเทคนิคไปยังตำแหน่งที่กำหนด บินไปที่โปรแกรม โทรล็อค รับข้อความ และลบหรือเปลี่ยนชื่อไฟล์บันทึกทางเทคนิค เราไม่ต้องการข้อมูลมากมายเกี่ยวกับการปิดกั้นอื่นๆ!

ไปที่โฟลเดอร์ rphost_PID ค้นหาไฟล์ข้อความและค้นหาคำว่า TTIMEOUT เราเห็นบรรทัด:

53:16.789126-0,TTIMEOUT,5,process=rphost,p:processName=*****,t:clientID=16536,t:applicationName=1CV8,t:computerName=ASUSM,t:connectID=17272,SessionID=2242,Usr=*******,WaitConnections=8239

อย่างไรก็ตาม อาจมีโฟลเดอร์ rphost_PID ได้หลายโฟลเดอร์ ทุกอย่างขึ้นอยู่กับจำนวนกระบวนการของผู้ปฏิบัติงานที่กำลังทำงานบนเซิร์ฟเวอร์

จากนั้นทุกอย่างก็ง่าย: ดูที่ท้ายบรรทัด - WaitConnections = 8239 นี่คือหมายเลข CONNECTION ของเรา เราไปที่คอนโซลเซิร์ฟเวอร์ ไปที่ Connections ค้นหาหมายเลขนี้และดูหมายเลขเซสชัน ในกรณีของฉัน มีสองเซสชันต่อผู้ใช้หนึ่งราย - เซสชันหนึ่งล้มเหลวและอีกเซสชันอื่น เซสชันที่ระบุโดยบันทึกทางเทคนิคขัดข้อง และเกี่ยวกับปาฏิหาริย์! ทุกอย่างทำงานได้ไม่มีขีด จำกัด ของความสุข! แต่เมื่อปรากฎในภายหลังเซสชันไม่ได้หยุดทำงาน :) พวกเขาทำงานในนั้น ดังนั้นในอนาคตขอแนะนำให้ติดต่อผู้ใช้และเตือน

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

การแก้ไขข้อขัดแย้งการล็อก 1C อย่างรวดเร็ว

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

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

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

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