เรามีเซิร์ฟเวอร์การผลิต SQL สองเครื่องที่รัน SQL Server 2005 SP4 พร้อมการอัพเดท 3 เซิร์ฟเวอร์ทั้งสองทำงานบนเครื่องจริงที่เหมือนกัน DELL PowerEdge R815 พร้อมซีพียู 4 x 12 คอร์และ 512GB (ใช่ GB) ของ ram พร้อมไดรฟ์ที่เชื่อมต่อ iSCSI SAN ขนาด 10GB สำหรับฐานข้อมูลและบันทึก SQL ทั้งหมด ระบบปฏิบัติการเป็น Microsoft Windows Server 2008 R2 Enterprise ที่มีการอัพเดท SP และ windows ทั้งหมด ไดรฟ์ระบบปฏิบัติการคืออาร์เรย์ RAID 5 ของไดรฟ์ 3 x 72GB 2.5 "15k SAS SAN เป็น Dell EqualLogic 6510 พร้อมไดรฟ์ 48 x 10K SAS 3.5" กำหนดค่าใน RAID 50 แบ่งเป็น LUN ต่างๆสำหรับเซิร์ฟเวอร์ SQL 2 ตัวและยังแชร์ ด้วยเครื่องแลกเปลี่ยนและเซิร์ฟเวอร์ VMWare หลายเครื่อง
เรามีฐานข้อมูลมากกว่า 20 รายการโดย 11 ฐานข้อมูลสะท้อนจากความพร้อมใช้งานสูงโดยใช้เซิร์ฟเวอร์พยาน เซิร์ฟเวอร์พยานเป็นเครื่องที่ใช้พลังงานต่ำกว่าที่ใช้งานอินสแตนซ์ของ SQL Server ซึ่งไม่ได้ใช้เพื่อการอื่นนอกเหนือจากการให้บริการพยาน ฐานข้อมูลที่มิเรอร์ที่ใหญ่ที่สุดคือ 450GB และสร้างประมาณ 100-300 iops การตรวจสอบฐานข้อมูลการมิเรอร์รายงานอัตราการส่งปัจจุบันประมาณ 100kb ถึง 10mb ต่อวินาทีและมิรเรอร์ใช้โอเวอร์เฮดของ (โดยทั่วไป) 0 มิลลิวินาที เซิร์ฟเวอร์มิรเรอร์ไม่มีปัญหาในการติดต่อกับตัวการ
เรากำลังประสบกับความล้มเหลวในการทำมิเรอร์อย่างสม่ำเสมอ บางครั้งฐานข้อมูลเดียวจะล้มเหลวในบางครั้งฐานข้อมูลเกือบทั้งหมดจะล้มเหลวพร้อมกัน ตัวอย่างเช่นเมื่อคืนเรามี 10 ของ 11 ฐานข้อมูลล้มเหลวฐานข้อมูลที่เหลืออยู่สามารถเข้าถึงได้จนกว่าฉันจะล้มเหลวด้วยตนเอง
ฉันได้ทำตามขั้นตอนการแก้ไขปัญหาต่าง ๆ เพื่อพยายามระบุปัญหา แต่ยังไม่สามารถแก้ไขปัญหาได้:
1) เครื่องมาพร้อมกับอะแดปเตอร์เครือข่าย Gigabit Broadcom BCM5709C NetXtreme II 4 ซึ่งตอนแรกเราใช้เป็นการเชื่อมต่อเครือข่ายหลัก เราได้ติดตั้งอะแดปเตอร์เซิร์ฟเวอร์คู่พอร์ต Intel (R) PRO / 1000 PT ไว้บนทั้งสองเครื่องเพื่อกำจัด NIC ตามปัญหา
2) ฐานข้อมูลทั้งหมดมีการสำรองข้อมูลอัตโนมัติเต็มรูปแบบทุกคืนพร้อมกับการสำรองข้อมูลบันทึกสำหรับฐานข้อมูลที่เกี่ยวข้องในการมิเรอร์ การใช้งานไฟล์บันทึกนั้นได้รับการตรวจสอบและใช้งานน้อยกว่า 15% ล็อกไฟล์สำหรับฐานข้อมูลหลักคือ 125GB ประกอบด้วยไฟล์บันทึกเสมือน 159 ไฟล์ที่มีขนาดตั้งแต่ 511MB ถึง 1GB TempDB อยู่ใน LUN ของตัวเองและประกอบด้วยไฟล์ 24 x 2GB
3) การบันทึก SQL Server บนพยานแสดงว่าไม่มีข้อผิดพลาดนอกเหนือจาก: การเชื่อมต่อมิเรอร์กับ "TCP: //SQL02.DOMAIN.INET: 5022" หมดเวลาสำหรับฐานข้อมูล "ข้อมูล" หลังจาก 30 วินาทีโดยไม่มีการตอบสนอง ตรวจสอบบริการและการเชื่อมต่อเครือข่าย
บันทึก SQL Server บนเซิร์ฟเวอร์หลักและเซิร์ฟเวอร์รองแสดงข้อความที่เกี่ยวข้องกับการมิเรอร์:
การเชื่อมต่อมิร์เรอร์กับ "TCP: //SQL01.DOMAIN.INET: 5022" หมดเวลาสำหรับฐานข้อมูล "Data" หลังจาก 30 วินาทีโดยไม่มีการตอบสนอง ตรวจสอบบริการและการเชื่อมต่อเครือข่าย
ฐานข้อมูล "Data" ที่มิร์เรอร์กำลังเปลี่ยนบทบาทจาก "PRINCIPAL" เป็น "MIRROR" เนื่องจาก Role Syncronization (การซิงโครไนซ์ถูกสะกดผิดที่นี่โดยมีจุดประสงค์เนื่องจากเป็นสิ่งที่แสดงถึงข้อความที่แท้จริง)
ฐานข้อมูล "Data" ที่มิร์เรอร์กำลังเปลี่ยนบทบาทจาก "PRINCIPAL" เป็น "MIRROR" เนื่องจาก Failover
ฐานข้อมูล "Data" ที่มิร์เรอร์กำลังเปลี่ยนบทบาทจาก "MIRROR" เป็น "PRINCIPAL" เนื่องจาก Failover from partner
บริการ SQL Server ยังคงทำงานต่อไปและการเชื่อมต่อเครือข่ายดูเหมือนจะยังคงอยู่ เรามีการเชื่อมต่อระหว่างเซสชัน 500 ถึง 2500 อย่างสม่ำเสมอกับเซิร์ฟเวอร์แต่ละตัว (โดยส่วนใหญ่แล้วแอปพลิเคชั่นหุ่นยนต์ที่เชื่อมต่อกับคิวนายหน้าบริการในฐานข้อมูลเดียว)
4) TCP Chimney และ RSS etc ถูกปิดใช้งานโดยใช้ไวยากรณ์ NET SH
5) ฉันได้รันตัววิเคราะห์วิธีปฏิบัติที่ดีที่สุดของ SQL Server 2005 กับทั้งสองเครื่องและไม่พบสิ่งใดนอกจากข้อผิดพลาดบันทึกเหตุการณ์แอปพลิเคชันเป็นครั้งคราวมาก 833 ไม่มีเหตุการณ์ใดที่เกิดขึ้นพร้อมกันกับเหตุการณ์ล้มเหลว:
SQL Server พบคำขอ I / O ที่เกิดขึ้น 1 ครั้งใช้เวลานานกว่า 15 วินาทีในการดำเนินการกับไฟล์ [F: \ Data.MDF] ในฐานข้อมูล [ข้อมูล] (9) หมายเลขอ้างอิงไฟล์ระบบปฏิบัติการคือ 0x00000000000010A0 ออฟเซ็ตของ I / O ที่ยาวล่าสุดคือ: 0x000007d4b10000)
6) บางครั้งเราเห็น "ไคลเอนต์ไม่สามารถใช้เซสชันด้วย SPID XXX ซึ่งถูกรีเซ็ตสำหรับการรวมการเชื่อมต่อข้อผิดพลาดนี้อาจเกิดจากการดำเนินการก่อนหน้านี้ล้มเหลวตรวจสอบบันทึกข้อผิดพลาดสำหรับการดำเนินการล้มเหลวทันทีก่อนข้อความแสดงข้อผิดพลาดนี้ ." สร้างโดยเซิร์ฟเวอร์ทั้งสอง ดูเหมือนจะไม่มีข้อความ "ก่อนหน้า" ที่ระบุปัญหาใด ๆ
7) จดหมายฐานข้อมูลเป็นครั้งคราวเขียนข้อผิดพลาดลงในบันทึกเหตุการณ์ของแอปพลิเคชัน:
ประเภทข้อยกเว้น: Microsoft.SqlServer.Management.SqlIMail.Server.Common.BaseException ข้อความ: มีข้อผิดพลาดในการเชื่อมต่อ สาเหตุ: หมดเวลาหมดอายุแล้ว รอบระยะเวลาการหมดเวลาผ่านไปก่อนที่การดำเนินการจะเสร็จสิ้นหรือเซิร์ฟเวอร์ไม่ตอบสนองพารามิเตอร์การเชื่อมต่อ: ชื่อเซิร์ฟเวอร์: MGSQL02 ชื่อฐานข้อมูล: msdb ข้อมูล: System.Collections.ListDictionaryInternal TargetSite: Void OpenConnection (Microsoft.SqlServer.Management.Common SqlConnectionInfo) HelpLink: NULL ที่มา: DatabaseMailEngine
ข้อมูล StackTrace ที่ Microsoft.SqlServer.Management.SqlIMail.Server.DataAccess.ConnectionManager.OpenConnection (SqlConnectionInfo ci) ที่ Microsoft.SqlServer.Management.SqlIMail.Server.DataAccess.DataAccess.DataAccess ) ที่ Microsoft.SqlServer.Management.SqlIMail.IMailProcess.QueueItemProcesser.ProcessQueueItems (สตริง dbName, สตริง dbServerName, Int32 อายุการใช้งานขั้นต่ำ, LogLevel loggingLevel)
ฉันเชื่อว่าการหมดเวลาเป็นสาเหตุของความล้มเหลว สิ่งที่อาจทำให้หมดเวลาเหล่านี้ เห็นได้ชัดว่าหากมีปัญหาเครือข่ายจริงเช่นสายเคเบิลที่ไม่ดีหรือสวิตช์ที่ไม่ดีซึ่งอาจทำให้แพ็กเก็ตสูญหายและหมดเวลาดังนั้นสิ่งอื่นใดที่อาจทำให้หมดเวลาได้ การปิดกั้น? หาก MSDB หรือฐานข้อมูลระบบอื่น ๆ มีการหมดเวลาของ I / O ที่อาจทำให้เกิดความล้มเหลวในการทำมิเรอร์?
ขอบคุณสำหรับคำแนะนำใด ๆ !
MSDN มีดังต่อไปนี้ที่จะพูดเกี่ยวกับกลไกการหมดเวลา :
กลไกการหมดเวลาของการมิเรอร์
เนื่องจากข้อผิดพลาดที่ไม่สามารถตรวจพบได้โดยตรงจากอินสแตนซ์ของเซิร์ฟเวอร์ข้อผิดพลาดที่ไม่คาดคิดอาจทำให้อินสแตนซ์ของเซิร์ฟเวอร์รออย่างไม่มีกำหนด เพื่อป้องกันสิ่งนี้การทำมิเรอร์ฐานข้อมูลจะใช้กลไกการหมดเวลาของตัวเองโดยอ้างอิงตามแต่ละเซิร์ฟเวอร์อินสแตนซ์ในเซสชันการทำมิรเรอร์ที่ส่งปิงไปยังแต่ละการเชื่อมต่อที่เปิดในช่วงเวลาคงที่
เมื่อต้องการให้การเชื่อมต่อเปิดอยู่อินสแตนซ์ของเซิร์ฟเวอร์จะต้องได้รับการ ping บนการเชื่อมต่อนั้นในช่วงเวลาการหมดเวลาที่กำหนดรวมถึงเวลาที่ต้องใช้ในการส่ง ping อีกครั้ง การรับ ping ในช่วงระยะหมดเวลาระบุว่าการเชื่อมต่อยังคงเปิดอยู่และอินสแตนซ์ของเซิร์ฟเวอร์กำลังสื่อสารอยู่ ในการรับ ping อินสแตนซ์ของเซิร์ฟเวอร์จะรีเซ็ตตัวนับการหมดเวลาบนการเชื่อมต่อนั้น
หากไม่ได้รับการ ping ในการเชื่อมต่อในช่วงระยะหมดเวลาอินสแตนซ์ของเซิร์ฟเวอร์จะพิจารณาว่าการเชื่อมต่อนั้นหมดเวลาแล้ว อินสแตนซ์ของเซิร์ฟเวอร์ปิดการเชื่อมต่อหมดเวลาและจัดการเหตุการณ์การหมดเวลาตามสถานะและโหมดการทำงานของเซสชัน
netsh interface tcp show global แสดงให้เห็นว่า:
Receive-Side Scaling State : disabled
Chimney Offload State : disabled
NetDMA State : enabled
Direct Cache Acess (DCA) : disabled
Receive Window Auto-Tuning Level : disabled
Add-On Congestion Control Provider : ctcp
ECN Capability : disabled
RFC 1323 Timestamps : disablednetsh interface ipv4 show dynamicportrange tcp
Protocol tcp Dynamic Port Range
Start Port : 1025
Number of Ports : 64510SELECT name, value_in_use FROM sys.configurations
Ad Hoc แบบกระจายข้อความค้นหา 0
affinity I / O mask 0
มาสก์ที่เกี่ยวข้อง 0
affinity64 I / O mask 0
affinity64 mask 0
เอเจนต์ XPs 1
อนุญาตการอัปเดต 0
awe เปิดใช้งาน 0
เกณฑ์กระบวนการที่ถูกบล็อก 5
โหมดการตรวจสอบ c2 0
clr เปิดใช้งาน 1
เปิดใช้งานการปฏิบัติตามเกณฑ์ทั่วไป 0
เกณฑ์ค่าใช้จ่ายสำหรับการขนาน 4
การเป็นเจ้าของ cross db 0
เกณฑ์เคอร์เซอร์ -1
ฐานข้อมูล Mail XPs 1
ภาษาข้อความเริ่มต้น 1033
ภาษาเริ่มต้น 0
เปิดใช้งานการติดตามเริ่มต้น 1
ไม่อนุญาตผลลัพธ์จากทริกเกอร์ 0
เติมปัจจัย (%) 0
ft crawl bandwidth (สูงสุด) 100
ft crawl bandwidth (ขั้นต่ำ) 0
ft แจ้งแบนด์วิดท์ (สูงสุด) 100
ft แจ้งแบนด์วิดท์ (ขั้นต่ำ) 0
ดัชนีสร้างหน่วยความจำ (KB) 0
ข้อสงสัย xact ความละเอียด 0
รวมกำไรเบา 0
ล็อค 0
ระดับสูงสุดของความขนาน 6
ช่วงการตระเวนข้อความเต็มสูงสุด 4
หน่วยความจำเซิร์ฟเวอร์สูงสุด (MB) 393216
ขนาดการจำลองข้อความสูงสุด (B) 65536
จำนวนคนงานสูงสุด 0
การเก็บรักษาสื่อ 0
หน่วยความจำขั้นต่ำต่อแบบสอบถาม (KB) 2048
หน่วยความจำเซิร์ฟเวอร์ขั้นต่ำ (MB) 52427
ทริกเกอร์ซ้อนกัน 1
ขนาดแพ็คเก็ตเครือข่าย (B) 1400
กระบวนการอัตโนมัติ Ole 1
วัตถุเปิด 0
ค่าหมดเวลาใช้งานของ PH 60
precompute อันดับ 0
เพิ่มระดับความสำคัญ 0
ขีด จำกัด ต้นทุนผู้ว่าการสอบถาม 0
การค้นหาที่รอ -1
ช่วงเวลาการกู้คืน (ขั้นต่ำ) 0
การเข้าถึงระยะไกล 1
การเชื่อมต่อผู้ดูแลระบบระยะไกล 0
หมดเวลาการเข้าสู่ระบบระยะไกล 20
remote proc trans 0
หมดเวลาของแบบสอบถามระยะไกล 600
การจำลองแบบ XPs 0
สแกนหา procs เริ่มต้น 0
การเรียกทริกเกอร์เซิร์ฟเวอร์ซ้ำ 1
ชุดทำงานขนาดชุด 0
แสดงตัวเลือกขั้นสูง 1
SMO และ DMO XP 1
SQL Mail XPs 0
แปลงคำที่มีเสียงรบกวน 0
ตัดสองหลักปี 2049
การเชื่อมต่อผู้ใช้ 0
ตัวเลือกผู้ใช้ 4216
ขั้นตอนผู้ช่วยเว็บ 0
xp_cmdshell 1
ไม่นานมานี้ฉันแก้ไขmirroring_connection_timeoutค่าสำหรับฐานข้อมูลที่มิเรอร์ทั้งหมดเป็น 30 วินาทีเพื่อพยายามแก้ไขปัญหา สิ่งนี้เพิ่มระยะเวลาระหว่างเหตุการณ์ failover ด้วยmirroring_connection_timeoutชุดการตั้งค่าที่เริ่มต้นของ 10 วินาทีที่เราเห็นมาก failovers มากขึ้น
ความคิดเห็นขอให้ฉันตรวจสอบให้แน่ใจว่า IPSec ถูกปิดใช้งานดังนั้นฉันโพสต์เนื้อหาของnetshคำสั่งต่าง ๆที่แสดงการกำหนดค่า IPSec ของระบบปฏิบัติการ:
C: \> netsh ipsec dynamic แสดงทั้งหมด ไม่มีนโยบายที่ได้รับมอบหมายในขณะนี้ นโยบายของเมนโหมดไม่พร้อมใช้งาน นโยบาย Quickmode ไม่พร้อมใช้งาน ไม่มีตัวกรองโหมดหลักทั่วไป ไม่มีโหมดตัวกรองหลักที่เฉพาะเจาะจง ไม่มีตัวกรอง Quickmode ทั่วไป ไม่มีตัวกรอง Quickmode ที่เฉพาะเจาะจง IPsec MainMode Security Associations ไม่พร้อมใช้งาน IPsec QuickMode Security Associations ไม่พร้อมใช้งาน พารามิเตอร์การกำหนดค่า IPsec ------------------------------ StrongCRLCheck: 1 IPsecexempt: 3 สถิติ IPsec ---------------- Active Assoc: 0 Offs SA: 0 คีย์ที่ค้างอยู่: 0 เพิ่มคีย์: 0 การลบคีย์: 0 ReKeys: 0 อุโมงค์ที่ใช้งาน: 0 SPI ไม่ดี Pkts: 0 Pkts ไม่ได้ถอดรหัส: 0 Pkts ไม่ได้รับการรับรองความถูกต้อง: 0 Pkts พร้อมการตรวจจับการเล่นซ้ำ: 0 ส่งไบต์ที่เป็นความลับ: 0 ไบต์ที่เป็นความลับที่ได้รับ: 0 ไบต์ที่ผ่านการตรวจสอบความถูกต้องแล้วส่ง: 0 ได้รับการรับรองความถูกต้องของไบต์: 0 Transport Bytes ส่งแล้ว: 0 ได้รับ Transport Transport: 0 จำนวนไบต์ที่ส่งในอุโมงค์: 0 จำนวนไบต์ที่ได้รับในอุโมงค์: 0 Offloaded Bytes ถูกส่ง: 0 ได้รับ Offloaded Bytes: 0 C: \> netsh ipsec คงที่แสดงทั้งหมด ERR IPsec [05072]: ไม่มีนโยบายในที่เก็บนโยบาย
ปรับปรุง: 2012-12-20
ตอนนี้เราได้ย้ายระบบการผลิตของเราไปยัง SQL Server 2012 เราเริ่มดำเนินการตั้งแต่เช้าวันที่ 17 ธันวาคมจนถึงตอนนี้ไม่มีข้อผิดพลาด อย่างไรก็ตามสองสามวันเป็นอย่างดีภายในสิ่งที่เราเห็นด้วยระบบที่ใช้ปี 2005
ในความพยายามที่จะบันทึกประสิทธิภาพของระบบใหม่ของเราฉันได้ดูsys.dm_os_wait_statsอย่างละเอียดมากขึ้น และสังเกตDBMIRROR_DBM_EVENTว่าเป็นประเภทการรอที่ไม่มีเอกสาร Graham Kent ที่ Microsoft มีบทความที่น่าสนใจเกี่ยวกับการแก้ไขปัญหาความล้มเหลวที่ไม่คาดคิดและประเภทการรอนี้ ฉันจะสรุปการค้นพบของเขาที่นี่:
ลูกค้ากำลังประสบกับการบล็อกลูกโซ่ขนาดใหญ่ที่สร้างขึ้นบนฐานข้อมูล OLTP ที่มีปริมาณมากซึ่งตัวบล็อกหัวทั้งหมดกำลังรอ DBMIRROR_DBM_EVENT นี่คือลำดับเหตุการณ์ที่ฉันได้อ่าน:
ตรวจสอบห่วงโซ่การปิดกั้นตัวเอง - โฮช่วยที่นี่เท่าที่เราเห็นคือเรากำลังรอ DBMIRROR_DBM_EVENT
ตรวจสอบแหล่งที่มาสำหรับประเภทการรอที่ไม่มีเอกสาร เห็นได้ชัดว่าคุณไม่สามารถทำสิ่งนี้นอก MS แต่ฉันสามารถพูดได้ว่าในขณะที่เขียนประเภทการรอนี้แสดงให้เห็นถึงการรอที่ใช้เมื่ออาจารย์ใหญ่กำลังรอให้กระจกแข็ง LSN ซึ่งหมายความว่าธุรกรรมที่เป็นส่วนหนึ่งของไม่สามารถกระทำ . สิ่งนี้ชี้ให้เห็นถึงปัญหาที่ครูใหญ่ไม่สามารถทำธุรกรรมได้ทันทีเนื่องจากมันกำลังรอมิเรอร์ ตอนนี้เราต้องตรวจสอบสาเหตุที่มิเรอร์ไม่ทำธุรกรรมหรือทำไมครูใหญ่ไม่รู้ว่ามันคืออะไร
ตรวจสอบตารางระบบ msdb
(a) ดูที่ตาราง [backupset] เพื่อดูว่าขนาดของบันทึกที่สร้างขึ้นในเวลาที่เกิดปัญหานั้นสูงกว่าปกติหรือไม่ หากพวกเขามีขนาดใหญ่เป็นพิเศษอาจเป็นได้ว่ากระจกเต็มไปด้วยธุรกรรมและไม่สามารถติดตามปริมาณได้ นี่คือสาเหตุที่หนังสือออนไลน์จะบอกให้คุณปิดการใช้งานการทำมิเรอร์ถ้าคุณต้องการทำการบันทึกที่มีขนาดใหญ่เป็นพิเศษเช่นการสร้างดัชนีใหม่ (การอ้างอิงถึงสาเหตุที่เกิดขึ้นที่http://technet.microsoft.com/en-us/library/cc917681.aspx ) ที่นี่ฉันใช้ TSQL ต่อไปนี้
SELECT backup_set_id,backup_start_date,database_name,has_bulk_logged_data,backup_size / 1000
FROM [backupset]
where backup_start_date between '2011-01-05 14:00:00' and '2011-01-05 19:30:00'
go
select round((AVG(backup_size)/1000),0)
FROM [backupset]
where database_name = 'mydatabase'(b) อันดับที่สองฉันดูข้อมูลในตาราง [dbm_monitor_data] กุญแจสำคัญในที่นี้คือการค้นหากรอบเวลาที่เรามีปัญหาแล้วดูว่าเราประสบปัญหาการเปลี่ยนแปลงที่สำคัญอย่างใดอย่างหนึ่งต่อไปนี้หรือไม่:
log_flush_rate
send_queue_size
send_rate
redo_queue_size
redo_rateสิ่งเหล่านี้เป็นตัวบ่งชี้ทั้งหมดที่คล้ายกับส่วน (a) ซึ่งอาจแสดงส่วนประกอบหรือชิ้นส่วนของสถาปัตยกรรมที่ไม่ตอบสนอง ตัวอย่างเช่นถ้า send_queue เริ่มขึ้น แต่จู่ ๆ re_do คิวก็ไม่ได้หมายความว่าครูใหญ่ไม่สามารถส่งบันทึกบันทึกไปยังมิเรอร์ดังนั้นคุณอาจต้องการดูการเชื่อมต่อหรือคิวตัวแทนบริการ การจัดการกับการส่งสัญญาณจริง
ในสถานการณ์เฉพาะนี้เราสังเกตว่าตัวนับทั้งหมดดูเหมือนว่ามีค่าแปลก ๆ ในนั้นมีการสำรองข้อมูลบันทึกที่เกิดขึ้นในขนาดปกติ แต่ไม่มีการเปลี่ยนแปลงสถานะ 0 คิวส่ง, 0 คิวทำซ้ำ, อัตราส่งแบนและแบน ทำซ้ำอัตรา นี่เป็นเรื่องแปลกมากเพราะมันบอกเป็นนัยว่า DBM Monitor ไม่สามารถบันทึกค่าใด ๆ จากที่ใดก็ได้ในช่วงเวลาที่เกิดปัญหา
ตรวจสอบบันทึกข้อผิดพลาด SQL Server ในกรณีนี้ไม่มีข้อผิดพลาดหรือข้อความข้อมูลใด ๆ แต่ในสถานการณ์อื่น ๆ เช่นนี้เป็นเรื่องปกติมากที่จะรายงานข้อผิดพลาดในช่วง 1,400 ช่วงตัวอย่างที่คุณสามารถหาได้จากที่อื่นในบล็อกการทำมิเรอร์อื่น ๆ ของฉันเช่น ข้อผิดพลาดนี้ 1413 ตัวอย่าง
ตรวจสอบไฟล์การติดตามเริ่มต้น - ในสถานการณ์สมมตินี้ฉันไม่ได้ระบุการติดตามเริ่มต้น แต่เป็นแหล่งข้อมูลที่ยอดเยี่ยมของข้อมูลปัญหา DBM เนื่องจากบันทึกเหตุการณ์การเปลี่ยนแปลงสถานะในพันธมิตรทั้งหมดนี่คือเอกสารที่นี่:
สถานะการทำมิเรอร์ฐานข้อมูลเปลี่ยนคลาสเหตุการณ์
สิ่งนี้มักจะให้ภาพรวมของสถานการณ์ที่ดีเช่นเมื่อการเชื่อมต่อเครือข่ายล้มเหลวระหว่างพันธมิตรหนึ่งรายหรือทั้งหมดแล้วสถานะของการเป็นหุ้นส่วนจะเกิดขึ้นในภายหลัง
โดยสรุปแล้ว
ในสถานการณ์เฉพาะขณะนี้ฉันขาดข้อมูลสำคัญ 2 ประเด็น แต่นอกเหนือจากนี้ฉันยังสามารถตั้งสมมติฐานที่สมเหตุสมผลในข้อมูลข้างต้น เราสามารถพูดได้อย่างแน่นอนว่าการบล็อกมีสาเหตุมาจากความจริงที่ว่า DBM ถูกเปิดใช้งานเนื่องจากผู้บล็อคทั้งหมดกำลังรอ DBMIRROR_DBM_EVENT ประเภทการรอคอย เนื่องจากเรารู้ว่าเราไม่ได้สะท้อนกระจกเงาด้วยการบันทึกขนาดใหญ่และการปรับใช้นี้ตามปกติจะทำงานอย่างมีความสุขในโหมดนี้เราจึงสามารถยกเว้นการทำงานขนาดใหญ่ที่ผิดปกติได้ ซึ่งหมายความว่าเรามีผู้สมัครที่มีศักยภาพ 2 คนในช่วงนี้
ปัญหาฮาร์ดแวร์เกี่ยวกับการเชื่อมต่อระหว่างคู่ค้าบางรายหรือทั้งหมด
CPU exhaustion บนเซิร์ฟเวอร์มิรเรอร์ - ไม่สามารถติดตาม redos ได้ - การหมดแรง CPU อาจมาจากกระบวนการภายนอกของ SQL Server หรือนอกการเป็นหุ้นส่วนของ mirror นี้
มีปัญหากับรหัสการมิเรอร์ (เราต้องการหน่วยความจำทิ้งเพื่อยืนยันสิ่งนี้)
จากประสบการณ์ที่ฉันสงสัยว่า 1 หรือ 2 แต่ฉันก็ยังเปิดใจเสมอเกี่ยวกับ 3 เช่นกันเรากำลังพยายามรวบรวมข้อมูลเพิ่มเติมเพื่อดูปัญหานี้โดยละเอียด