ปัญหาด้านประสิทธิภาพ 3 อันดับแรกที่คุณพบกับเซิร์ฟเวอร์ SQL ของคุณคืออะไร

ฉันเป็นนักเรียนจากมหาวิทยาลัย Fontys ใน Eindhoven และขณะนี้ฉันกำลังดำเนินการสัมภาษณ์หลายชุดเพื่อช่วยในการพัฒนาเครื่องมือ SQL Server และฉันต้องการรับคำติชมจากผู้เชี่ยวชาญในสาขานี้

หนึ่งในคำถามของฉันคือ:

ปัญหาด้านประสิทธิภาพ 3 อันดับแรกที่คุณพบกับอินสแตนซ์ของเซิร์ฟเวอร์ SQL ของคุณคืออะไรและคุณระบุปัญหาเหล่านั้นได้อย่างไร

โดยเฉพาะฉันสนใจสคริปต์และเครื่องมือที่ใช้วัดสิ่งนี้

จากด้านบนของหัวของฉัน - ปัญหาแบบสอบถาม 3 อันดับแรก

• การแปลงโดยนัย
• กลยุทธ์การจัดทำดัชนีไม่ดี (มากเกินไปหรือไม่เพียงพอหรือผิดประเภท)
• ใช้ SELECT * แทนการตั้งชื่อเฉพาะฟิลด์ที่คุณต้องการ

มีปัญหาเกี่ยวกับการกำหนดค่าระดับเซิร์ฟเวอร์ปัญหาสคีมาฐานข้อมูลปัญหาฮาร์ดแวร์และอื่น ๆ อีกมากมายฉันเขียนสคริปต์เพื่อวิเคราะห์เซิร์ฟเวอร์อย่างรวดเร็วเพื่อค้นหาปัญหาประเภทนี้:

http://www.brentozar.com/blitz/

• การออกแบบ / คิวรี / ดัชนีที่แย่
• ไม่อนุญาตให้ซื้อฮาร์ดแวร์ที่ถูกต้อง
• Braindead ORMs (aka "SQL is dead")

ไม่ใช่อันดับ 3 แต่คิดว่าฉันจะพูดถึงสิ่งที่ยังไม่ได้กล่าวถึง:

1. SQL วางเครื่องเสมือนโดยไม่มีรายละเอียด / ความโปร่งใสให้แก่ DBA เซิร์ฟเวอร์โฮสต์จะเปลี่ยนการตั้งค่าเครื่องแขกแบบไดนามิกที่ทำให้ประสิทธิภาพลดลงและออกจาก DBA โดยไม่มีเงื่อนงำ คุณลักษณะต่างๆเช่นการขยายตัวสูงเกินไปการสร้างทีมงานเครือข่ายและการเพิ่มหน่วยความจำทำให้ประสิทธิภาพการทำงานกลายเป็นเป้าหมายในการตรวจสอบTools: sysmon/perfmon, DMVs, maintaining a history of performance counters in tables.
2. ในทำนองเดียวกันไม่มีความโปร่งใส / ตรวจสอบได้ในการตั้งค่า SAN ที่ให้ไว้กับ DBA ฉันมี LUN ที่มีการตั้งค่าแคชการอ่าน / เขียนที่แตกต่างกัน แต่บอกว่ามันเหมือนกันหมดTools: IO DMVs, SQLIO.
3. สถาปัตยกรรม Bad DB: เช่นการปรับขนาดและการจัดวางข้อมูลและไฟล์บันทึกและ tempdb การใช้งานคู่ขนานที่ไม่เหมาะสม การสร้างกลุ่มไฟล์หลายกลุ่มบนฟิสิคัลดิสก์เดียวกันTools: experience.

เป็นอีกเครื่องมือหนึ่งที่ผมกำลังตรวจสอบออกในขณะนี้คือโครงการลูซี่ ดูเหมือนว่าเรียบร้อย

• ขาดดัชนีที่เหมาะสม
• มีใครบางคนใช้กับ nolock ในรหัสการผลิตเพื่อพยายามแก้ไขปัญหาด้านประสิทธิภาพ โดยเฉพาะอย่างยิ่งถ้ารหัสแก้ไขข้อมูลในตาราง
• แอปพลิเคชันเลือกข้อมูลมากกว่าที่จำเป็นในเวลามากกว่าที่จำเป็น Ex มีเลขฐานสองคืนทุกครั้งแม้ว่าคุณต้องการ textdata ของตารางเดียวกัน

ข้อความค้นหาที่ปรับขนาดได้ไม่ดี (รับคำสั่งซื้อทั้งหมดเป็นเวลา X ปีสำหรับลูกค้าทั้งหมด ฯลฯ รวมถึงคำสั่งซื้อทั้งหมดรวมถึงข้อมูลที่สรุปและข้อมูลเฉลี่ยอื่น ๆ ที่คำนวณได้ไม่ดี)

เพียงสอบถามทุกอย่างในครั้งเดียว

ตารางที่มีเขตข้อมูล 'descript' varchar / text ที่ต้องค้นหาผ่านทุกแบบสอบถาม

• การบำรุงรักษาที่ไม่เหมาะสมเช่นไม่มีดัชนี reorgs, สถิติ, ไม่มีการสำรองข้อมูลบันทึก
• ไม่มีดัชนี
• ข้อความค้นหาที่เขียนไม่ดี

• การออกแบบฐานข้อมูลและแอปพลิเคชันไม่ดี
• การใช้ประโยชน์จากแพลตฟอร์มที่ไม่ดี (นักพัฒนาต้องการให้มีรหัสการเข้าถึงฐานข้อมูลที่เน้นแพลตฟอร์มไม่มี SPs ไม่มีฟังก์ชั่นอื่น ๆ )
• การจัดทำดัชนีไม่ดีแน่นอน

• ad-hoc query บน prod data - อ๋อนักพัฒนาเชื่อว่ามันเป็นสิ่งที่จำเป็นและบางคนอาจเข้าถึง :-)
• การออกแบบแอพที่ไม่ดีซึ่งใช้ฐานข้อมูล - เช่น: เพิ่มข้อมูลมากเกินไปและไม่เคยลบออกแม้ว่าจะไม่จำเป็นอีกต่อไป (ซึ่งนำไปสู่ปัญหาด้านประสิทธิภาพเนื่องจากการสำรองข้อมูลมีขนาดใหญ่ขึ้นงานบำรุงรักษาใช้เวลานานขึ้น
• ไฟล์ฐานข้อมูลทั้งหมดในการโจมตีเดียวกันหรือแย่กว่านั้นในไดรฟ์เดียวกัน (เช่น: ระบบ dbs, tempdb, ผู้ใช้ dbs ทั้งหมดเข้าด้วยกันบนไดรฟ์ / การโจมตีเดียวกัน)

• การออกแบบฐานข้อมูลไม่ดี
• กลยุทธ์การจัดทำดัชนีไม่ดี (รวมถึงดัชนีมากเกินไปดัชนีหายไปและขาดการบำรุงรักษาดัชนี)
• การตัดสินใจสถาปัตยกรรมฮาร์ดแวร์ไม่ดี

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

1. มี DB ไปกลับมากเกินไป Chattiness เป็นหนึ่งในปัญหาประสิทธิภาพหลักที่ฉันเห็น
2. รับขอบเขตการทำธุรกรรมที่เหมาะสม การทำธุรกรรม INSERT / UPDATE / DELETE ทุกครั้งสามารถเป็นนักฆ่าประสิทธิภาพที่ยิ่งใหญ่
3. ความล้มเหลวในการเพิ่มประสิทธิภาพด้านฮาร์ดแวร์; โดยเฉพาะอย่างยิ่งการใส่บันทึก DB ในปริมาณที่แตกต่างจากข้อมูล DB

ถ้าฉันสามารถเพิ่มรายการที่สี่ในรายการมันจะเป็นการใช้ทริกเกอร์และ / หรือเคอร์เซอร์มากเกินไปและไม่เหมาะสม ดูเหมือนจะไม่เกิดขึ้นมากเกินไปในวันนี้ แต่เมื่อมันเกิดขึ้นมันเจ็บปวดจากมุมมองของการแสดง