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

29

ฉันรู้ว่า INSERT ในตาราง SQL อาจช้าด้วยเหตุผลหลายประการ:

การมีอยู่ของ INSERT TRIGGERs บนโต๊ะ
ข้อ จำกัด ที่บังคับใช้จำนวนมากที่ต้องตรวจสอบ (โดยปกติคือกุญแจต่างประเทศ)
หน้าแยกในดัชนีคลัสเตอร์เมื่อแถวถูกแทรกในกลางตาราง
การอัพเดตดัชนีที่ไม่ใช่คลัสเตอร์ทั้งหมดที่เกี่ยวข้อง
การบล็อกจากกิจกรรมอื่น ๆ บนโต๊ะ
เวลาตอบสนองการเขียน IO แย่
... ทุกอย่างที่ฉันพลาดไป?

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

ฉันมี proc ที่เก็บไว้ซึ่งแทรกประมาณ 10,000 แถวต่อครั้ง (จากตารางชั่วคราว) ซึ่งใช้เวลาประมาณ 90 วินาทีต่อแถว 10k นั่นเป็นสิ่งที่ยอมรับไม่ได้ช้าเพราะจะทำให้เกิดการหมดเวลาอื่น ๆ

ฉันได้ดูแผนการดำเนินการและฉันเห็นงาน INSERT CLUSTERED INDEX และ INDEX SEEKS ทั้งหมดจากการค้นหา FK แต่ก็ยังไม่ได้บอกฉันว่าทำไมมันถึงใช้เวลานาน ไม่มีทริกเกอร์ แต่ตารางมี FKeys จำนวนหนึ่ง (ซึ่งดูเหมือนว่าจะได้รับการจัดทำดัชนีอย่างเหมาะสม)

นี่คือฐานข้อมูล SQL 2000

— BradC
แหล่งที่มา

คุณเปิดใช้งาน autoexpand ในไฟล์ข้อมูลของคุณหรือไม่ ที่สามารถทำให้เกิดปัญหาประสิทธิภาพการทำงานกับการกำหนดค่าเริ่มต้น

— Larry Coleman

เรากำลังพูดถึงการใช้ profiler หรือไม่? msdn.microsoft.com/en-us/library/ms187929.aspx

— ไม่ระบุตัวตน

@ Larry: ไฟล์ข้อมูลมีพื้นที่ว่างที่สำคัญดังนั้นฉันไม่เชื่อว่าการเติบโตของไฟล์ข้อมูลเป็นปัญหา ดีอย่างหนึ่งที่จะเพิ่มในรายการ "สิ่งที่ต้องตรวจสอบ"

— BradC

@ user210: การทำโปรไฟล์คำสั่งให้สมบูรณ์แสดงให้ฉันเห็นว่าใช้เวลา 90 วินาทีมันไม่ได้บอกฉันว่าทำไม ถ้าไม่มีเหตุการณ์อื่นที่คุณคิดว่าจะบอกได้มากกว่านี้

— BradC

10

บางสิ่งที่คุณสามารถดู ...

ลดขนาดแบตช์จาก 10,000 เป็นอะไรที่เล็กลงเช่น 2000 หรือ 1,000 (คุณไม่ได้บอกว่าขนาดแถวของคุณใหญ่แค่ไหน)

ลองเปิด IO Stats เพื่อดูว่าการค้นหา FK ของ IO นั้นมีจำนวนเท่าใด

การรอเกิดจากเมื่อการแทรกเกิดขึ้น (master.dbo.sysprocesses) คืออะไร

มาเริ่มกันที่นี่และดูว่าเราไปไหน

— mrdenny
แหล่งที่มา

2

การลดขนาดแบทช์จะช่วยได้ (บันทึก 1,000 รายการใช้เวลาประมาณ 25 วินาที) นั่นน่าจะเป็น "วิธีแก้ปัญหา" ในปัจจุบันของเรา ฉันจะดูว่าฉันสามารถกำหนด IO Stats และรอ (ลูกค้าทำงานตามความต้องการของลูกค้าเมื่อพวกเขามีไฟล์ที่จะประมวลผลหรือไม่ดังนั้นฉันจึงไม่สามารถคาดการณ์ได้ว่าเมื่อใดที่งานจะทำงานจริง)

— BradC

7

แบรด

คุณควรตรวจสอบสถิติการรอคอยสำหรับการค้นหาของคุณ ด้วย SQL2000 คุณสามารถใช้ไวยากรณ์ DBCC SQLPERF ("waitstats") เพื่อรับรายละเอียดเหล่านั้น

— SQLRockstar
แหล่งที่มา

6

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

วิเคราะห์แผนการดำเนินการแบบสอบถามและตรวจสอบการสแกนดัชนีสแกนตารางการใช้งานฟังก์ชั่น convert_implicit สำหรับประเภทข้อมูล sql, ความเท่าเทียม
เรียกใช้แบบสอบถามด้วย SET STATISTICS IO ON และ SET STATISTICS TIME ON เพื่อดูเวลาดำเนินการและอ่าน / เขียน io สำหรับแต่ละส่วนแทรก
ตรวจสอบช่วงเวลาจาก sysprocesses สำหรับเซสชันของคุณ
เรียกใช้ profiler และเลือกเทมเพลตมาตรฐาน เลือกต่อไปนี้: สถิติประสิทธิภาพ (ถ้าทำซ้ำแผนของคุณจะถูกรวบรวมหลายครั้ง - ไม่ดี), RPC: เสร็จสมบูรณ์, SQL: batchcompleted และ SQL: การเริ่มต้นแบบแบตช์ เพิ่มไปที่คอลัมน์rowcountsเพื่อดูจำนวนแถวในแบทช์ กรองผลลัพธ์เพื่อดูเฉพาะแบบสอบถามของคุณ
ในที่สุดรวบรวมตัว นับอายุการใช้งาน Page Life Expectancyจาก windows perfmon และถ้าต่ำกว่า 300 (5 นาที) SQL จะมีหน่วยความจำเหลือน้อย รวบรวมเคาน์เตอร์ดิสก์ด้วย: ความยาวคิวดิสก์ , เวลาดิสก์ (ไดรฟ์ไฟล์ข้อมูลของคุณ), เวลาดิสก์ (ไดรฟ์ไฟล์บันทึกของคุณ)เพื่อดูว่ามีแรงกดดันต่อดิสก์หรือไม่

— yrushka
แหล่งที่มา

5

ลองใช้:

SET STATISTICS IO ON

และ

SET STATISTICS PROFILE ON

ข้อมูลสถิติ IO

มีประโยชน์ในการบอกให้คุณทราบว่าตารางใดที่ทำการสแกนตารางจำนวนมากที่สุดการอ่านเชิงตรรกะ & การอ่านทางกายภาพ (ฉันใช้ทั้งสามข้อนี้เพื่อมุ่งเน้นว่าส่วนใดของแผนแบบสอบถามต้องการปรับแต่งมากที่สุด)

ข้อมูลสถิติ

จะส่งคืนแผนคิวรีเป็นหลักในรูปแบบตารางจากนั้นคุณสามารถดูคอลัมน์ IO และ CPU สำหรับสิ่งที่คิดต้นทุนจำนวนมากที่สุดในแบบสอบถาม (คือการสแกนตารางในตาราง temp ของคุณเทียบกับการเรียงลำดับที่จะแทรกลงใน รหัสกุญแจ ฯลฯ ... )

— Andrew Bickerton
แหล่งที่มา