รหัสข้อผิดพลาด 10054 ซึ่งมีลักษณะร้ายแรงนี้จะปรากฏต่อผู้ใช้ในขณะที่บันทึก มักพบใน 1C 8.2 รุ่นเก่า
ภาพหน้าจอของข้อผิดพลาด 10054:
โดยทั่วไป การปรากฏตัวของข้อผิดพลาดนี้บ่งชี้ว่ามีการกระทำที่ไม่คาดคิดสำหรับผู้พัฒนาเซิร์ฟเวอร์ 1C เกิดขึ้น:
- คำขอที่ไม่ถูกต้องมาถึง
- ข้อมูลไม่ถูกต้อง
- แบบสอบถามที่เรียกตัวอย่างขนาดใหญ่ที่ไม่สามารถตอบสนองได้
- กรณีพิเศษ เลขที่เอกสารยาวเกินความยาวที่กำหนดในตัวเศษ
- ตรวจสอบการทำงานด้วยโปรแกรมป้องกันไวรัสหรือไฟร์วอลล์ที่ถูกปิดใช้งาน
การแก้ไข:
ประกอบด้วยการแปลปัญหาให้มากที่สุด:
- การกำหนดประเภทของเอกสาร
- การลงทะเบียนที่เกิดข้อผิดพลาด
- ผู้ใช้,
- คอมพิวเตอร์.
จากนั้นจะทำสำเนาฐานข้อมูล (โดยใช้ 1C หรือ DBMS)
หากการรีสตาร์ทเซิร์ฟเวอร์ช่วยแก้ปัญหาได้ ให้ตรวจสอบต่อไป เพิ่มสคริปต์การรีสตาร์ทบริการในเวลากลางคืนในช่วงเวลานอกเวลาทำงาน
หากการรีสตาร์ทเป็นแบบวน ให้ตรวจสอบว่าคุณได้กำหนดค่าไว้หรือไม่ รีสตาร์ทอัตโนมัติในคุณสมบัติของคลัสเตอร์:
การทดสอบและแก้ไขจะดำเนินการด้วยการคำนวณผลลัพธ์ใหม่และการจัดทำดัชนีตารางใหม่ 
คัดลอกสำเนาก่อนหน้าของฐานข้อมูลที่มีการสังเกตปัญหา มีการตรวจสอบความแตกต่าง และบางทีนี่อาจนำไปสู่สาเหตุ
หากปัญหาไม่สามารถแก้ไขได้ ขั้นตอนต่อไปคือการกำหนดค่าและวิเคราะห์บันทึกกระบวนการ
สิ่งที่อาจชัดเจนในระหว่างกระบวนการ:
หากโหลดบนเซิร์ฟเวอร์ใกล้จะถึง 100% ให้พิจารณาแยกเซิร์ฟเวอร์ฐานข้อมูลและเซิร์ฟเวอร์ 1C ซึ่งมักจะช้าลง แต่ทำให้งานเสถียร (ใน 8.3 มีกลไก หน่วยความจำที่ใช้ร่วมกันซึ่งช่วยเพิ่มความเร็วในการโต้ตอบของเซิร์ฟเวอร์และ)
- เพิ่มหน่วยความจำให้กับเซิร์ฟเวอร์ถ้าเป็นไปได้
- วิธีแก้ปัญหาที่เป็นไปได้คือการแทนที่เซิร์ฟเวอร์ด้วยเซิร์ฟเวอร์ 64 บิต แต่ก่อนอื่นให้ตรวจสอบฟังก์ชันการทำงานของเพื่อนของคุณที่ตั้งอยู่
- การตรวจสอบแบบเดียวกันบน 32 บิตเพื่อทำความเข้าใจข้อผิดพลาดในข้อมูลหรือเซิร์ฟเวอร์เฉพาะจะไม่เสียหาย
- การขนถ่ายและการขนถ่ายอาจทำให้ไม่แสดงอาการ
- ทางเลือกสุดท้าย ให้พิจารณาถ่ายโอนข้อมูลผ่านการแปลงข้อมูลหรือเพิ่มข้อมูลลงในสำเนาที่ใช้งานได้ (ขั้นตอนที่ยาว)
ตรวจสอบบันทึก Windows เพื่อหาข้อผิดพลาดของระบบ:
- ในการดำเนินงานเครือข่าย
- อุปกรณ์
- การใช้งาน
- รีสตาร์ทเราเตอร์สวิตช์ (ไม่ค่อยพบ แต่มีปัญหา)
หากปัญหาไม่ได้รับการแก้ไขในเวลาอันสั้น คุณอาจต้องการความช่วยเหลือจากผู้ดูแลระบบที่ผ่านการรับรองหรือผู้เชี่ยวชาญ 1C
ข้อผิดพลาดที่พบบ่อยพอสมควรเมื่อใช้ 1C 8.2 ในโหมดไคลเอนต์ - เซิร์ฟเวอร์ - โฮสต์ระยะไกลถูกบังคับให้ตัดการเชื่อมต่อ การเชื่อมต่อที่มีอยู่- ตามกฎแล้ว ผู้ดูแลระบบของลูกค้าจากภาคองค์กรจะนำไปใช้ เช่น ที่มีสถานที่ทำงานตั้งแต่ 20 แห่งขึ้นไป
ใน 98% ของกรณี ข้อผิดพลาดนี้เกี่ยวข้องกับการรีสตาร์ทเวิร์กโฟลว์ อาจมีสาเหตุหลายประการที่ทำให้รีสตาร์ท แต่สาเหตุที่พบบ่อยที่สุดคือการรีสตาร์ทซ้ำๆ ตามกำหนดเวลา เนื่องจากการเติบโตของไฟล์เวิร์กโฟลว์ rphostและการชะลอตัวอย่างรวดเร็วตามมาในการทำงานซึ่งตามการเติบโตนี้ ผู้ดูแลระบบพยายามแก้ไขปัญหาด้วยการรีสตาร์ทกระบวนการทำงาน และเผชิญกับปัญหาอื่นทันที - ตัดการเชื่อมต่อผู้ใช้ที่ทำงาน การสร้างเวิร์กโฟลว์เพิ่มเติมไม่ได้ให้อะไรเลยเพราะ... ตรงกันข้ามกับ เอกสารอย่างเป็นทางการการสลับไคลเอ็นต์แบบหนาเป็นเวิร์กโฟลว์อื่น ไม่เกิดขึ้น- ยิ่งไปกว่านั้น ยังมีภาระบนโปรเซสเซอร์เพิ่มขึ้น - จำเป็นต้องจัดการการสลับบริบท อย่างไรก็ตาม 1C แนะนำเวิร์กโฟลว์เดียวสำหรับผู้ใช้ 50-100 คน
1) เพื่อเพิ่มหน่วยความจำที่กระบวนการทำงาน 1C ใช้การรีสตาร์ทกระบวนการทำงานโดยอัตโนมัติ ขอแนะนำให้รีสตาร์ทเวิร์กโฟลว์วันละครั้ง (ทุกๆ 86400 วินาที) ในกรณีนี้ กระบวนการของผู้ปฏิบัติงานจะถูกปิดก่อน (ไม่สามารถเชื่อมต่อใหม่ได้ กระบวนการเก่ายังคงทำงานต่อไป) และเปิดตัวกระบวนการใหม่ จากนั้น เมื่อการเชื่อมต่อทั้งหมดไปยังกระบวนการเก่าถูกปิด กระบวนการจะยุติลง ในเวลาเดียวกัน โปรดทราบว่าการนับถอยหลังของ 86400 เดียวกันนี้จะเริ่มนับจากช่วงเวลาที่บริการเริ่มต้น ตัวแทนเซิร์ฟเวอร์ 1C Enterprise- เหล่านั้น. ขอแนะนำให้เริ่มในเวลากลางคืน
2) อย่าใช้กระบวนการของผู้ปฏิบัติงานมากกว่าหนึ่งกระบวนการหากคุณมีผู้ใช้มากถึง 100 คน ที่ มากกว่ากระบวนการของผู้ปฏิบัติงานใช้เวลา CPU ในการสลับบริบทระหว่างกัน
3) ล้างหน่วยความจำที่ใช้แล้ว- การเติบโตอย่างรวดเร็วของหน่วยความจำที่ถูกครอบครองโดยกระบวนการ rphost มักเกิดจากการกำหนดค่าที่เขียนอย่างไม่ระมัดระวัง โปรแกรมเมอร์มักจะไม่สนใจที่จะล้างหน่วยความจำที่ถูกครอบครอง โดยเฉพาะภายใต้ ตารางค่าการแจงนับและอาร์เรย์ สิ่งนี้จะเด่นชัดเป็นพิเศษเมื่อมันเกิดขึ้นในงานเบื้องหลัง ดังนั้นเมื่อวิเคราะห์ปัญหาหน่วยความจำรั่ว คุณต้องเริ่มต้นด้วยปัญหาดังกล่าว เช่น ปิดการใช้งานในคุณสมบัติ ฐานข้อมูลชั่วขณะหนึ่ง
4) การใช้งาน เซิร์ฟเวอร์แยกต่างหาก สำหรับ SQL และ 1C อย่างที่คุณทราบ ไม่มีหน่วยความจำสำหรับ SQL มากเกินไป
คุณควรให้ความสนใจกับกรณีที่ระบุไว้ซึ่งมีข้อผิดพลาด “โฮสต์ระยะไกลบังคับให้ปิดการเชื่อมต่อ” ปรากฏขึ้นเนื่องจาก การใช้ประโยชน์สูง อุปกรณ์เครือข่าย - เมื่อเวลาตอบสนองของเซิร์ฟเวอร์เพิ่มขึ้นเป็น 150-300 มิลลิวินาทีขึ้นไป การเชื่อมต่อจะถูกตัดการเชื่อมต่อเนื่องจากการหมดเวลา ตัวอย่างเช่นสิ่งนี้เกิดขึ้นเมื่อผู้ใช้หลายคนโหลดเราเตอร์ที่เซิร์ฟเวอร์ 1C เชื่อมต่อพร้อมกันโดยการคัดลอกไฟล์ ขนาดใหญ่- ผู้ดูแลระบบควรคำนึงถึงความเป็นไปได้ของสถานการณ์ดังกล่าวและเมื่อซื้อเราเตอร์ให้คำนึงถึงความเร็วของเมทริกซ์การสลับ
โดยสรุป ฉันจะเสริมว่าการติดตั้งและกำหนดค่าเซิร์ฟเวอร์เป็นเรื่องที่มีความรับผิดชอบ ซึ่งต้องใช้ความรู้และประสบการณ์ เป็นการดีกว่าที่จะมอบความไว้วางใจให้กับผู้เชี่ยวชาญ ผู้เชี่ยวชาญของเราติดตั้งเซิร์ฟเวอร์แบบครบวงจร สำหรับรายละเอียดเพิ่มเติม โปรดดูในส่วน
คำอธิบายของข้อผิดพลาด
server_addr=tcp://<имясервера>:1562 descr=ข้อผิดพลาดในการเข้าถึงเครือข่ายไปยังเซิร์ฟเวอร์ (Windows Sockets - 10054(0x00002746) โฮสต์ระยะไกลบังคับให้ปิดการเชื่อมต่อที่มีอยู่) line=1031 file=.\src\DataExchangeTcpClientImpl.cpp
วิธีจัดการกับปัญหานี้
ตั้งค่าบันทึกเทคโนโลยีและแยกวิเคราะห์บันทึก
ที่สุด เหตุผลทั่วไปมีการขัดข้องของส่วนเซิร์ฟเวอร์ 1C:Enterprise
คุณสามารถตรวจสอบให้แน่ใจว่ามีการสร้างดัมพ์หรือไม่ (ดูที่พาธ logcfg.xml หากไม่มีการตั้งค่าดัมพ์ จากนั้นในไดเร็กทอรี %USERPROFILE%\Local Settings\Application Data\1C\1Cv81\Dumps เช่น C:\ Documents and Settings\<Имя пользователя>\การตั้งค่าท้องถิ่น\ข้อมูลแอปพลิเคชัน\1C\1Cv81\dumps แพลตฟอร์มล่มมักเกิดขึ้นเนื่องจากการร้องขอที่มีพารามิเตอร์ที่ไม่ได้มาตรฐาน ส่งดัมพ์ไปยังอีเมลสนับสนุนทางเทคนิคของ 1C: [ป้องกันอีเมล].
1. บ่อยครั้งที่ฉันพบปัญหาในบันทึกเอกสารในการเลือก ข้อความค้นหาจะคล้ายกับสิ่งนี้:
เลือกที่อนุญาตสูงสุด 35 R.Date_Time A1,
R.หมายเลข A2,
R.Fld9608 A3,
R.Fld9613 A4,
R.Fld9606 A5,
R.Fld9610 A6,
R.Fld9611 A7,
R.Fld9607 A8,
R.Fld9612 A9,
R.Fld9615 A10,
R.Fld9614 A11,
R.Fld9609 A12,
R.Fld9605 A13,
ร.เอกสาร A14,
ร.ทำเครื่องหมาย A15,
R.โพสต์ A16,CAST(R.Fld9608 AS REF(Reference9)).คำอธิบาย
A17,CAST(R.Fld9606 AS REF(Reference52)).คำอธิบาย A18,CAST(R.Fld9611
AS REF(ข้อมูลอ้างอิง 93)) คำอธิบาย A19 กรณีที่ R.Fld9609 REFS
การอ้างอิง 53 แล้วหล่อ (R.Fld9609 AS REF (อ้างอิง 53)) คำอธิบายเมื่อ
R.Fld9609 REFS Reference150 แล้วส่ง (R.Fld9609 AS
REF(Reference150)).คำอธิบายเมื่อ R.Fld9609 REFS Reference63 แล้ว
นักแสดง(R.Fld9609 AS REF(อ้างอิง 63)) คำอธิบายเมื่อ R.Fld9609 REFS
Reference114 THEN CAST(R.Fld9609 AS REF(Reference114)).คำอธิบาย END
A20,CAST(R.Fld9605 AS REF(Reference79)).คำอธิบาย A21
จาก DocumentJournal9604 R ที่ไหน
((R.Fld9605=79:b63e000bcd6ad80811da7cf12c684266)) และ
(R.Date_Time > DATETIME(2006,12,31,12,0,0) หรือ (R.Date_Time =
DATETIME(2006,12,31,12,0,0) และ (R.Document >=
343:b654000bcd6ad80811dba49c7aabe269)))
เรียงลำดับตาม A1 ASC, A14 ASC'
2. ตัวอย่างของบันทึก TJ ที่แสดงสาเหตุที่เซิร์ฟเวอร์ล่มเมื่ออัปเดตการค้นหาข้อความแบบเต็ม
11:40.9690-0,EXCP,1,กระบวนการ=rphost,p:ชื่อกระบวนการ=<база данных>,t:clientID=3, t:applicationName=BackgroundJob,t:connectID=27,Usr=DefUser,DumpFile=C:\Program Files (x86)\1cv81\dumps\rphost_8.1.13.41_7d4e2366_20090609021136_10236.mdmp,บริบท=’
GeneralModule.Module ของงานปกติ: 46: Full-TextSearch.UpdateIndex (False, True);'
วิธีแก้ปัญหาสุดท้ายในตัวอย่างนี้คือการปิดการใช้งานกระบวนการเบื้องหลังในฐานข้อมูลที่มีปัญหา รอการเปิดตัวแพลตฟอร์มใหม่และอัปเดต
สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการขัดข้องของแพลตฟอร์ม โปรดดูบล็อกของฉัน
3. ตัวอย่างของ TC สำหรับการรีสตาร์ทกระบวนการแบบวนรอบ ในการวิเคราะห์เหตุการณ์นี้บนคอมพิวเตอร์เซิร์ฟเวอร์ 1C:Enterprise คุณต้องเปิดใช้งานรายการในบันทึกเหตุการณ์ทางเทคโนโลยี PROC (ตัวอย่างไฟล์ logcfg.xml)
เมื่อกระบวนการปิดตัวลง เหตุการณ์ PROC จะถูกยกขึ้นโดยมีคุณสมบัติ Txt=Process กลายเป็นปิดใช้งาน
เมื่อกระบวนการถูกยกเลิก เหตุการณ์ PROC จะถูกออกพร้อมกับคุณสมบัติ Txt=Process สิ้นสุดลง ลูกค้าท่านใดที่ทำเสร็จแล้วมีข้อผิดพลาด หากผู้ใช้หยุดทำงานตรงเวลากับเอาต์พุตของเหตุการณ์นี้ สาเหตุคือการบังคับปิดเวิร์กโฟลว์โดยผู้ดูแลระบบ (ผ่านคอนโซลคลัสเตอร์) หรือเนื่องจากการรีสตาร์ทอัตโนมัติ
4. ตรวจสอบให้แน่ใจว่าสาเหตุเป็น/ไม่ใช่การกระทำของผู้ดูแลระบบในคอนโซล
—————————-
ด้านล่างนี้เป็นเวอร์ชันของโซลูชันของเพื่อนร่วมงาน
ทุกคน สนใจในการแก้ไขปัญหาแพลตฟอร์มล่มด้วยข้อผิดพลาด:
10051, 10053, 10054, 10064
ดังที่การซักถามเกี่ยวกับเหตุขัดข้องของแพลตฟอร์มแสดงให้เห็น จากด้านบน ข้อผิดพลาดที่ระบุ:
-การหกล้มส่วนใหญ่เกิดจากการทำงาน งานพื้นหลังตามที่คาดไว้ในหัวข้อ
-ไม่มีด้ามจับ พื้นที่ดิสก์
— ความพร้อมใช้งาน จำนวนมากธุรกรรมที่ยังไม่เสร็จในบันทึก 1C
— ก่อนที่จะแยกวิเคราะห์บันทึกทางเทคโนโลยี ให้วิเคราะห์งานพื้นหลังที่ใช้ในการกำหนดค่าและปิดใช้งานงานที่คุณไม่ต้องการสำหรับงานหรือการกำหนดค่า (ไม่สำคัญ การวิเคราะห์ขยะขนาด 14 GB ถือเป็นงานอดิเรกหากคุณไม่มีอะไรทำดีไปกว่านี้.. . :))))
— วิเคราะห์และแก้ไขงานพื้นหลังที่คุณเพิ่ม ตรวจสอบให้แน่ใจว่างานเหล่านั้นเสร็จสมบูรณ์ด้วยโค้ดการทำงานปกติ (ไม่มีข้อผิดพลาดหรือธุรกรรมที่ปิดแล้ว)
— เพิ่มส่วนของโค้ดให้กับอัลกอริธึมของงานเบื้องหลังที่ทำให้เกิดข้อผิดพลาด บังคับหน่วยความจำที่ใช้ระหว่างการดำเนินการ (คุณไม่ควรหวังว่า 1C จะจัดสรรหน่วยความจำที่ใช้เมื่อเสร็จสิ้น)
— วิเคราะห์และแก้ไขปัญหาประสิทธิภาพการทำงานที่ถูกต้องของงานการกำหนดค่าพื้นหลังทั่วไป
— ปฏิบัติตามขั้นตอนกำกับดูแลกับฐานข้อมูลผ่านรายการเมนู Administration-Testing and Correction อย่าลืม จำเป็น, ทำการบีบอัดฐานข้อมูล
— วิเคราะห์จำนวนพื้นที่ที่ใช้ เซิร์ฟเวอร์ SQLเป็นไปได้ว่าเซิร์ฟเวอร์มีหน่วยความจำไม่เพียงพอ
– ตรวจสอบนโยบาย การตั้งค่าที่ใช้งานอยู่ไดเรกทอรี
- และบีบอัด/ล้างบันทึกด้วย ธุรกรรม SQLด้วยโค้ดต่อไปนี้โดยประมาณ (สำหรับ SQL 2000):
ตัวเลือกที่ 1:DBCC SHRINKFILE(pubs_log, 2)
(ถ้า ขนาดที่เหมาะสมไม่ถึงตัวเลือกลอง 2) ตัวเลือก 2:สำรองข้อมูลบันทึกผับด้วย TRUNCATE_ONLY
DBCC SHRINKFILE(pubs_log,2)
โดยที่ pub_log คือชื่อของฐานข้อมูลของคุณ
ตัวเลือก 3:
sp_detach_db - เราจะตัดการเชื่อมต่อฐานข้อมูลด้วยขั้นตอนนี้ และ sp_attach_db - เราจะเชื่อมต่ออีกครั้ง บันทึกธุรกรรมจะถูกล้าง
(สำหรับข้อมูลเพิ่มเติม โปรดดูหัวข้อ MSDN Q256650 (สำหรับ SQL 7.0) และ Q272318 (สำหรับ SQL 2000))
ตัวเลือก 4: (สำหรับ 7.0)
DBCC SHRINKFILE(ชื่อไฟล์, target_size)
DBCC SHRINKDATABASE (ชื่อฐานข้อมูล, target_percent)
บันทึกการสำรองข้อมูลฐานข้อมูล_ชื่อ ด้วย TRUNCATE_ONLY
หากล้มต่อไปหลังการดำเนินการเหล่านี้ ให้ปฏิบัติตามคำแนะนำต่อไป:
- ลองเปลี่ยนแปลงดู ไฟล์โฮสต์ ระบบปฏิบัติการ(เป็นไปได้มากว่าการลงทะเบียนการเชื่อมโยงเฉพาะในไฟล์ในเครื่องหนึ่งหรือสองเครื่องที่เกิดปัญหาบ่อยที่สุดจะเพียงพอแล้ว)
— ลองแยก 1C Enterprise และเซิร์ฟเวอร์ SQL หากคุณมีไว้ในเครื่องเดียวกัน
— หรือในทางกลับกันให้ติดตั้งไว้ในเครื่องเดียว (หากคุณมีทรัพยากรเพียงพอ) มีหลายกรณีที่การโอนเซิร์ฟเวอร์ไปยังเซิร์ฟเวอร์เดียวช่วยได้ (ในความคิดของฉันมันเป็นที่น่าสงสัยมากและเกี่ยวข้องกับเหตุผลในการเริ่มต้นงานโดยเฉพาะมากขึ้น นี่คือการบีบอัดบันทึกธุรกรรม)
— ตรวจสอบเวลาตอบสนองของเซิร์ฟเวอร์ (ส่วนใหญ่แล้วทุกอย่างจะอยู่ภายในขีดจำกัดปกติ และความล้มเหลวที่เกิดขึ้นได้ยากในเวลาบริการไม่สามารถส่งผลกระทบที่รุนแรงต่อการทำงานของเซิร์ฟเวอร์องค์กรได้)
— ตรวจสอบการทำงานของเราเตอร์บนเครือข่าย (ไม่ค่อยมี แต่เกิดขึ้นว่าเป็นการกำหนดค่าใหม่ที่ส่งผลต่อจำนวนข้อขัดข้อง)
— ตรวจสอบข้อขัดแย้งของอุปกรณ์บนเครือข่าย (เกี่ยวข้องกับคำถามว่าทำไมจึงแนะนำให้มีอุปกรณ์จากซัพพลายเออร์รายหนึ่งบนเครือข่าย ใครก็ตามที่ต้องการตรวจสอบได้ เช่น ในเอกสารทางเทคนิคของ 3COM จะมีเขียนไว้ว่า ถ้า การ์ดเครือข่ายตรวจพบว่ากำลังโต้ตอบกับสิ่งที่คล้ายกัน การ์ดเครือข่ายจากนั้นสามารถเปลี่ยนไปใช้โหมดที่มีประสิทธิผลมากขึ้นได้โดยการสลับไปใช้อัลกอริธึมการประมวลผลที่ปรับให้เหมาะสมที่สุด แพ็กเก็ตเครือข่าย, ผ่านการทดสอบแล้ว ประสบการณ์ส่วนตัวประสิทธิภาพก้าวกระโดดถึง 50%)
— ตรวจสอบระดับสัญญาณของผู้บริโภค/คอมพิวเตอร์ปลายทาง (อาจจะเล็กน้อย ระดับต่ำสัญญาณ, คำขอบล็อกซ้ำอย่างต่อเนื่อง, ความล่าช้าในคิวสำหรับการบริการในเครือข่าย และในที่สุดก็ได้รับข้อความว่าเซิร์ฟเวอร์ปลายทางได้ปิดการเชื่อมต่อเมื่อจำนวนความพยายามเกินเวลาที่รอคอยสำหรับสัญญาณที่จะมาถึง หากคุณต้องการที่จะเข้าใจ ปัญหานี้โปรดดูโปรโตคอลการทำงาน Ethernet/CSMA CD/CSMA จำนวนครั้งที่พยายามส่งแพ็กเก็ตภายใน โปรโตคอลนี้ไม่สิ้นสุด...))) และบัฟเฟอร์ในการ์ดก็ไม่สิ้นสุดเช่นกัน)
— เพิ่มหน่วยความจำให้กับเซิร์ฟเวอร์
— โอนผู้ใช้บางส่วน/ทั้งหมดไปยังโหมดเทอร์มินัล (เช่น ระบุสิ่งที่ผู้ใช้จำนวนมากกำหนดว่าเป็น THIN CLIENT 1C) สำหรับเซิร์ฟเวอร์ดังกล่าว ฉันขอแนะนำ Citrix Metaframe หรือ Terminal Server MS
เป็นไปได้มากว่าเมื่อคุณทำตามคำแนะนำเหล่านี้ ยกเว้นการวิเคราะห์ปัญหากับฮาร์ดแวร์ ความเสถียรของงานจะเพิ่มขึ้นมากจนแพลตฟอร์มล่มจะหายากมาก ซึ่งจะปิดช่องว่างทางเทคโนโลยีสำหรับการบำรุงรักษาฐานข้อมูลซึ่งยังคงจำเป็น ให้ปฏิบัติตามและอย่าคิดว่าคำแนะนำข้างต้นเป็นยาครอบจักรวาลสำหรับทุกปัญหา
พวกเขาจะแก้ปัญหาได้หลายอย่าง แต่ไม่ใช่ทั้งหมด
และคุณมีความสุขถ้าคุณไม่มีปัญหาเช่นนั้นใครก็ตามที่มีปัญหาจะเข้าใจฉัน
———————————
ตรวจสอบบทบาท "ผู้ใช้" ว่ามีเข้ามาหรือไม่ การกำหนดค่าทั่วไปแน่นอน และโดยเฉพาะอย่างยิ่ง หลังจากที่คุณคำนวณแล้ว ปัญหาเอกสารที่ใช้ คุณต้องค้นหาบทบาทที่เป็นปัญหา (ใครกำลังบ่น)
ถัดไป สำหรับบทบาทผู้ใช้ ให้ดูที่เรดาร์ของเอกสาร หาก การตั้งค่าเพิ่มเติมไม่ (บริสุทธิ์) แล้ว คลิกขวาบนนั้น - ค้นหาลิงก์ไปยังวัตถุและดูเรดาร์ตามลำดับสำหรับบทบาท "ผู้ใช้" สำหรับแต่ละวัตถุ
เข้าใจผิดว่าผู้ใช้มีความเข้มข้นสูงในการโจมตีโปรโตคอลในบางกรณี Windows
> เรียกใช้ regedit.exe เพิ่มค่า DWORD ใหม่ที่เรียกว่า SynAttackProtect ให้กับคีย์รีจิสทรี HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ และให้ค่าเป็น 00000000
มันสมเหตุสมผลที่จะทำกับ Windows 2003 SP1 (http://msdn.microsoft.com/ru-ru/library/ms189083.aspx
เซิร์ฟเวอร์ 1C และฐานข้อมูลบนเครื่องเดียวภายใต้ การจัดการเดเบียนบีบ.
วิธีแก้ปัญหา: ตั้งค่าพารามิเตอร์เคอร์เนล tcp_syncookies เป็น 0
root@machine:~# echo "net.ipv4.tcp_syncookies = 0" >> /etc/sysctl.conf && sysctl -p
(ผู้เขียน วาดิม อิวาคิน)
