คำถามติดแท็ก waits

เมื่อได้รับการรอสักครู่คุณจะค้นหาแบบสอบถามที่ทำให้เกิดการรออย่างปลอดภัยบนเซิร์ฟเวอร์ SQL 2008 R2 ที่ผลิตได้อย่างไร async_network_ioเฉพาะในกรณีนี้ผมกำลังสงสัยเกี่ยวกับ

34 sql-server-2008  waits 

เมื่อฉันกำลังติดตามด้วย sp_BlitzFirst ฉันจะได้รับรายละเอียดนี้: <?ClickToSeeDetails -- For 20 seconds over the last 5 seconds, SQL Server was waiting on this particular bottleneck. -- ?> ควรที่จะอ่าน "20 ครั้งในช่วง 5 วินาทีที่ผ่านมา?" การค้นหาคือ CLR_SEMAPHORE

15 sql-server  sql-server-2012  waits  sp-blitzfirst 

เราเริ่มALTER TABLEคำถามเมื่อหลายชั่วโมงก่อนและเพิ่งรู้ว่าเพิ่งผ่านpg_stat_activityการล็อค เราค้นพบแบบสอบถามอื่น ๆ ที่ถือล็อคบนตารางที่เราต้องการแก้ไขและไม่ปล่อยให้มันไป แบบสอบถามของเราคือแบบสอบถามแบบ "ง่าย" (การเปลี่ยนชนิดข้อมูลคอลัมน์) แต่กำลังทำงานบนตารางขนาดใหญ่ ALTER TABLEแทนที่จะฆ่ากระบวนการที่จะถือไว้ล็อคเราได้ตัดสินใจว่าเราอยากจะฆ่า เราไม่ได้ห่อALTER TABLEในการทำธุรกรรม เท่าที่ฉันเข้าใจความจริงที่ว่าแบบสอบถามของเรากำลังรอการล็อกหมายความว่ามันกำลังรอการล็อคอยู่เสมอและมันไม่เคยเปลี่ยนแปลงอะไรเลย มันเป็นเรื่องจริงเหรอ? ปลอดภัยALTER TABLEหรือไม่ที่เราจะยกเลิกการสอบถามของเราทันที หรือเป็นไปได้ว่าแบบสอบถามได้แก้ไขบางสิ่งบางอย่างแล้วและการยกเลิกจะทำให้ฐานข้อมูลของเราอยู่ในสถานะกึ่งกลางหรือไม่ PS: SELECT pg_cancel_backend(pid);แผนคือการยกเลิกการใช้ หากนี่เป็นความคิดที่ไม่ดีโปรดแจ้งให้เราทราบ

10 postgresql  locking  alter-table  waits 

เมื่อเราย้ายจากแฟลชอาร์เรย์ทั้งหมดที่เก่ากว่าไปเป็นแฟลชอาร์เรย์ทั้งหมดที่ใหม่กว่า (ต่างกัน แต่เป็นผู้จำหน่ายที่ได้รับการยอมรับ) เราเริ่มเห็นการรอคอยเพิ่มขึ้นใน SQL Sentry ระหว่างจุดตรวจ เวอร์ชัน: SQL Server 2012 Sp4 ในที่เก็บข้อมูลเก่าของเราการรอคอยของเราอยู่ที่ประมาณ 2k ด้วย "spikes" ถึง 2,500 ในระหว่างการตรวจสอบกับที่เก็บข้อมูลใหม่ spikes มักจะ 10k กับยอดใกล้ 50k ยามชี้ให้เราเห็นว่ามีความPAGEIOLATCHสุขมากขึ้น ทำการวิเคราะห์ของเราเองดูเหมือนว่าจะเป็นการรวมกันของPAGEIOLATCH and PAGELATCHรอ การใช้ Perfmon โดยทั่วไปเราสามารถพูดได้ว่ายิ่งมีด่านมากขึ้นเท่าไรเราก็ยิ่งได้รับมากขึ้นเท่านั้น ภาระงานของเราส่วนใหญ่จะเขียน (แทรก / ปรับปรุงเป็นหลัก) ผู้จำหน่ายอุปกรณ์จัดเก็บได้พิสูจน์ให้เราเห็นแล้วว่าอาร์เรย์ที่ต่อตรงกับ Fibre Channel นั้นตอบสนองย่อย 1 ms ในระหว่างเหตุการณ์จุดตรวจสอบเหล่านี้ HBA ยังยืนยันหมายเลขของอาเรย์ด้วย เรายังไม่เชื่อว่าเป็นปัญหาการเข้าคิว HBA เนื่องจากความลึกของคิวไม่เคยสูงกว่า 8 เราได้ลองใช้ HBA …

9 sql-server  sql-server-2012  storage  waits  checkpoint