คำถามติดแท็ก service-broker

1
นายหน้าบริการได้รับการสำรองข้อมูลตอนนี้ได้รับแล้ว แต่ดูเหมือนว่าจะไม่ได้รับการประมวลผล
คำถามนี้ถูกโยกย้ายจาก Stack Overflow เพราะสามารถตอบได้ใน Exchange Administrators Stack Exchange อพยพ 4 ปีที่แล้ว มีปัญหากับการแจ้งเตือนกิจกรรม บนเครื่อง / ไดรฟ์ / ฐานข้อมูลที่ข้อความถูกส่งไปยัง (ตัวรับสัญญาณ) หมายถึงไดรฟ์เต็มเมื่อไม่มีใครค้นหาดังนั้นจึงถูกสำรองตลอดทั้งวัน ตอนนี้เราเพิ่มพื้นที่ว่างในไดรฟ์ก็ยอมรับข้อความในคิว แต่ดูเหมือนว่าจะไม่ประมวลผล - ไม่มีระเบียนใหม่แทรกแม้ว่าคิวจะมี 22 ล้านข้อความและเพิ่มขึ้น (!) เปิดใช้งานคิว IS: is_activation_enabled = 1 is_receive_enabled = 1 is_enqueue_enabled = 1 ฉันเห็น SP ที่เปิดใช้งานอยู่activation_procedureแต่เมื่อฉันดูSP_WHOISACTIVEฉันไม่เห็นผู้อ่านที่ใช้งานอยู่ ก่อนที่ฉันจะระเบิดออกอีกครั้งฉันทำอะไรผิด ฉันจะนำไปดำเนินการหรือล้างข้อความได้อย่างไร ขอบคุณล่วงหน้า. ปรับปรุง One thought - ตั้งแต่ฉันมีis_enqueue_enabledบางทีมันเก็บข้อความทั้งหมดจนกว่ามันจะสามารถประมวลผลได้ทั้งหมด? ถ้าเป็นเช่นนั้นฉันสามารถปิดเครื่องได้อย่างปลอดภัยหรือไม่ CREATE …

2
การปิด WAITFOR ที่ไม่ จำกัด เพิ่มขนาดไฟล์บันทึกหรือไม่
ในแอปรุ่นล่าสุดของฉันฉันเพิ่มคำสั่งที่บอกให้รอเมื่อมีบางสิ่งเข้ามาในคิว Service Broker: WAITFOR (RECEIVE CONVERT(int, message_body) AS Message FROM MyQueue) DBA บอกฉันว่าตั้งแต่การเพิ่มขนาดบันทึกได้ผ่านหลังคา สิ่งนี้ถูกต้องไหม หรือฉันควรจะมองหาที่อื่น?


1
Sch-M WAIT บล็อก Sch-S ใน SQL Server 2014 แต่ไม่ใช่ SQL Server 2008 R2?
เราเพิ่งโอนย้ายอินสแตนซ์การผลิตของเราจาก SQL 2008 R2 ไปเป็นเซิร์ฟเวอร์ SQL 2014 ใหม่ล่าสุด นี่เป็นสถานการณ์ที่น่าสนใจที่เราค้นพบกับการใช้บริการของเรา พิจารณาฐานข้อมูลที่มีBroker Enabled = trueด้วยและMyService MyQueueการจัดการข้อความพิษถูกปิดใช้งานในคิวนี้ มีการสนทนาอย่างน้อย 2 ครั้งที่มีข้อความในคิว ในหนึ่งกระบวนการ (SPID 100) ดำเนินการ: BEGIN TRANSACTION; DECLARE @conversation_group_id UNIQUEIDENTIFIER; RECEIVE TOP (1) @conversation_group_id = conversation_handle FROM MyQueue; โปรดทราบว่าเราปล่อยให้ธุรกรรมเปิดอยู่ ลองนึกภาพว่ามันเป็นโปรแกรม. NET ที่กำลังรอทรัพยากรภายนอกอยู่นาน ผ่านทางsys.dm_tran_locksเราเห็นว่า SPID นี้ได้รับการล็อคทรงเครื่องบนคิว | type | resource_id | mode | status | …

1
ล้างแคชของเซิร์ฟเวอร์ SQL และดิสก์ I / O
เรากำลังยุ่งกับการทดสอบระบบ OLTP ที่เราพัฒนาขึ้นใน. NET 4.0 และรัน SQL Server 2008 R2 ที่ด้านหลัง ระบบใช้คิวตัวแทนการบริการเซิร์ฟเวอร์ SQL ซึ่งมีประสิทธิภาพมาก แต่เรากำลังประสบกับแนวโน้มที่แปลกประหลาดขณะประมวลผล การร้องขอการประมวลผลของ SQL Server ที่อัตราการพองตัวเป็นเวลา 1 นาทีตามด้วยกิจกรรมการเขียนดิสก์ที่เพิ่มขึ้น ~ 20 วินาที กราฟต่อไปนี้แสดงให้เห็นถึงปัญหา Yellow = Transactions per second Blue = Total CPU usage Red = Sqlsrv Disk Write Bytes/s Green = Sqlsrv Disk Read Bytes/s ในระหว่างการแก้ไขปัญหาเราลองทำสิ่งต่อไปนี้โดยไม่มีการเปลี่ยนแปลงที่สำคัญในรูปแบบ: บริษัท ตัวแทนการเซิร์ฟเวอร์ …

1
นายหน้าบริการ - อายุการสนทนาหรือไม่
เราพยายามให้ Service Broker ทำงานในสภาพแวดล้อมของเราเพื่อแก้ไขปัญหาทางธุรกิจ ฉันไม่รู้ว่าชื่อข้อความนั้นดีหรือไม่ แต่คำถามของฉันอยู่ด้านล่าง แต่มันอาจไม่ใช่คำถามที่ดีดังนั้นหลังจากนั้นคือสิ่งที่เรากำลังทำอยู่และทำไมฉันจึงคิดว่ามันเป็นคำถามที่ถูกต้อง ควรส่งข้อความในการสนทนากี่ข้อความก่อนที่จะสิ้นสุดการสนทนา เราต้องการใช้ Service Broker เพื่ออัพเดทตารางผลลัพธ์แบบอะซิงโครนัส ตารางผลลัพธ์แบนและรวดเร็ว เรามีทริกเกอร์ในตารางฐานที่ส่งข้อความพร้อมกับตารางและคีย์หลัก เรามีสามคิว: เวลาตอบสนองต่ำ - เป้าหมายคือ 15 วินาทีในการประมวลผล มันจัดการรายการที่เปลี่ยนแปลงที่เกี่ยวข้องกับรายการที่เฉพาะเจาะจง คิวจำนวนมาก - วัตถุประสงค์คือ 5 นาทีในการดำเนินการ มันจัดการเมื่อมีการเปลี่ยนแปลงบางอย่างที่มีผลต่อหลายร้อย (หรือหลายพัน) รายการ มันแบ่งรายชื่อของรายการที่ได้รับผลกระทบและฟีดพวกเขาไปยังคิวเวลาแฝงต่ำรอการตัดบัญชี เวลารอตอบสนองต่ำรอการตัดบัญชี - วัตถุประสงค์คือ 30 นาทีในการดำเนินการ สิ่งนี้จะประมวลผลรายการ แต่จากคิวจำนวนมากเท่านั้น โดยทั่วไปหากข้อมูลของลูกค้าอัพเดท ที่มีผลต่อผลิตภัณฑ์จำนวนมากเพื่อให้ส่งไปยังคิวจำนวนมากเพื่อการประมวลผลที่ช้าลง อย่างไรก็ตามหากผลิตภัณฑ์ได้รับการอัพเดตผลิตภัณฑ์นั้นจะถูกส่งไปยังคิวเวลาแฝงต่ำ เราใช้การสนทนาที่คล้ายกับบล็อกของ Remus Rusanu อีกครั้งhttp://rusanu.com/2007/04/25/reusing-conversations/ยกเว้นว่าเราดำเนินการตามโมดูลัสของคีย์หลัก สิ่งนี้มีประโยชน์ด้านการช่วยเหลือในการทำซ้ำของคีย์หลัก ดังนั้นเราจึงใช้การสนทนาอีกครั้งและอยู่ในหลักเกณฑ์ของเรา ด้วยสองเธรดฉันสามารถเขียนข้อความถึง 125 ข้อความ / …
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.