SQL Server Performance Monitor: คู่มือฉบับสมบูรณ์ [2026]

SQL Server การตรวจสอบประสิทธิภาพคือกระบวนการติดตาม วิเคราะห์ และจัดการประสิทธิภาพและสุขภาพของคุณ SQL Server ฐานข้อมูล เกี่ยวข้องกับการรวบรวมและตีความข้อมูลเกี่ยวกับแง่มุมต่างๆ ของระบบฐานข้อมูลของคุณ เพื่อให้มั่นใจถึงประสิทธิภาพสูงสุด ป้องกันปัญหา และรักษาความสมบูรณ์ของฐานข้อมูล

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

1.2 ประโยชน์หลักของการติดตามประสิทธิภาพ

มีประสิทธิภาพ SQL Server การตรวจสอบประสิทธิภาพมีข้อดีที่สำคัญหลายประการ:

การตรวจจับปัญหาเชิงรุก: ระบุและแก้ไขปัญหาที่อาจเกิดขึ้นก่อนที่จะส่งผลกระทบต่อผู้ใช้หรือการดำเนินธุรกิจ
การเพิ่มประสิทธิภาพ: ระบุคอขวดและความไม่มีประสิทธิภาพเพื่อปรับปรุงประสิทธิภาพฐานข้อมูลโดยรวม
วางแผนกำลังการผลิต: คาดการณ์ความต้องการทรัพยากรและวางแผนการเติบโตในอนาคตโดยอิงจากข้อมูลในอดีต
การปฏิบัติตามข้อกำหนดและความปลอดภัย: ตรวจสอบให้แน่ใจว่าปฏิบัติตามข้อกำหนดด้านกฎระเบียบและตรวจจับกิจกรรมที่น่าสงสัย

1.3 ความท้าทายด้านประสิทธิภาพทั่วไป

หากไม่มีการตรวจสอบประสิทธิภาพฐานข้อมูล SQL ที่เหมาะสม องค์กรต่างๆ จะต้องเผชิญกับความเสี่ยงหลายประการ ดังนี้:

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

จากการศึกษาของ IDC ในปี 2023 พบว่าปัญหาประสิทธิภาพฐานข้อมูล 65% เกิดจากแนวทางการตรวจสอบหรือการเพิ่มประสิทธิภาพที่ไม่ดี

2. ทำความเข้าใจเกี่ยวกับ Windows Performance Monitor (PerfMon)

2.1 Windows Performance Monitor คืออะไร?

Windows Performance Monitor (PerfMon) เป็นเครื่องมือ Windows ในตัวที่ตรวจสอบทรัพยากรระบบและประสิทธิภาพของแอปพลิเคชัน สำหรับ SQL Server ผู้ดูแลระบบ PerfMon มอบข้อมูลเชิงลึกอันล้ำค่าเกี่ยวกับทั้งระบบปฏิบัติการและ SQL Server เมตริกซึ่งทำให้มีความจำเป็นสำหรับการวิเคราะห์ประสิทธิภาพโดยรวม

PerfMon วัดสถิติประสิทธิภาพเป็นระยะและบันทึกสถิติเหล่านั้นไว้ในไฟล์เพื่อการวิเคราะห์ในภายหลัง ผู้ดูแลระบบฐานข้อมูลสามารถเลือกช่วงเวลา รูปแบบไฟล์ และสถิติที่ต้องการตรวจสอบได้ เครื่องมือนี้ไม่ได้ SQL Serverเฉพาะ—ผู้ดูแลระบบใช้เพื่อตรวจสอบ Windows เอง, Exchange, เซิร์ฟเวอร์ไฟล์ และแอปพลิเคชันใดๆ ที่อาจประสบปัญหาคอขวด

2.2 การเปิดตัว Performance Monitor

คุณสามารถเปิด Performance Monitor ได้โดยใช้หลายวิธี:

คลิก เริ่มต้นพิมพ์ perfmon ในช่องค้นหา ให้คลิกที่ “Performand Monitor” ในผลการค้นหา:
ข่าวประชาสัมพันธ์ ของ Windows + Rพิมพ์ perfmonและกด เข้าสู่
นำทางไปยัง แผงควบคุม -> ระบบและความปลอดภัย -> เครื่องมือการจัดการ -> การตรวจสอบประสิทธิภาพ

3 สำคัญ SQL Server ตัวนับประสิทธิภาพ

3.1 ตัวนับประสิทธิภาพหน่วยความจำ

ตัวนับหน่วยความจำมีความสำคัญต่อการตรวจสอบ SQL Server ประสิทธิภาพการทำงานซึ่งบ่งชี้ว่าฐานข้อมูลของคุณมีทรัพยากรหน่วยความจำเพียงพอหรือไม่

เมกะไบต์ที่พร้อมใช้งาน

ตัวนับนี้แสดงจำนวนหน่วยความจำทางกายภาพที่พร้อมสำหรับการจัดสรรทันที ควรคงที่พอสมควรและไม่ควรต่ำกว่า 4096 MB ค่าที่ต่ำอาจบ่งชี้ว่า SQL Serverการตั้งค่าหน่วยความจำสูงสุดของ 's จะถูกปล่อยทิ้งไว้เป็นค่าเริ่มต้นหรือไม่SQL Server แอปพลิเคชันกำลังใช้หน่วยความจำ

อายุการใช้งานของหน้า

Page Life Expectancy วัดระยะเวลา (เป็นวินาที) ที่เพจจะอยู่ในบัฟเฟอร์พูลโดยไม่มีการอ้างอิง ค่าปกติคือ 300 วินาทีขึ้นไป ค่าที่ต่ำกว่าบ่งชี้ถึงการใช้งานหน่วยความจำและการโอเวอร์โหลดบัฟเฟอร์มากเกินไป ซึ่งลดประสิทธิภาพของแคช

อัตราส่วนการกระทบแคชบัฟเฟอร์

ตัวนับนี้แสดงเปอร์เซ็นต์ของคำขอข้อมูลที่ตอบโดยใช้แคชบัฟเฟอร์ SQL (หน่วยความจำ) แทนที่จะอ่านจากดิสก์ โดยทั่วไปจะตรงตามหรือเกิน 99% ค่าที่ต่ำกว่าบ่งชี้ว่า SQL Server ต้องการหน่วยความจำเพิ่ม หรือยังอยู่ในระหว่างการวอร์มเครื่องหลังจากรีสตาร์ท

หน่วยความจำมอบรอดำเนินการ

นี่แสดงจำนวนกระบวนการที่รอหน่วยความจำภายใน SQL Serverภายใต้สภาวะปกติ ค่านี้ควรเป็น 0 อย่างสม่ำเสมอ ค่าที่สูงกว่าบ่งชี้ว่ามีการจัดสรรหน่วยความจำไม่เพียงพอ SQL Server.

หน่วยความจำเป้าหมายของเซิร์ฟเวอร์ เทียบกับ หน่วยความจำทั้งหมดของเซิร์ฟเวอร์

หน่วยความจำเป้าหมายของเซิร์ฟเวอร์ระบุปริมาณหน่วยความจำที่เหมาะสม SQL Server ต้องการใช้งาน หน่วยความจำเซิร์ฟเวอร์ทั้งหมดแสดงสิ่งที่ SQL Server กำลังใช้อยู่ในปัจจุบัน อัตราส่วนระหว่างค่าเหล่านี้ควรอยู่ที่ประมาณ 1 ความแตกต่างที่สำคัญอาจบ่งชี้ถึงการใช้งานหน่วยความจำมากเกินไปหรือหน่วยความจำไม่เพียงพอ

3.2 ตัวนับประสิทธิภาพของโปรเซสเซอร์

ตัวนับ CPU ช่วยระบุคอขวดของโปรเซสเซอร์และทำความเข้าใจว่า SQL Server ใช้ทรัพยากรคอมพิวเตอร์

% เวลาประมวลผล

วิธีนี้วัดเปอร์เซ็นต์ของเวลาที่โปรเซสเซอร์ใช้ในการรันเธรดที่ไม่ได้ทำงาน บนเซิร์ฟเวอร์ที่ใช้งานอยู่ ค่าอาจพุ่งสูงถึง 100% แต่การใช้งานอย่างต่อเนื่องที่มากกว่า 70-75% มักบ่งชี้ถึงปัญหาด้านประสิทธิภาพสำหรับผู้ใช้ ดัชนีที่ขาดหายไปหรือไม่เพียงพอมักทำให้มีการใช้งาน CPU สูง

% เวลาที่มีสิทธิพิเศษ

เวลาของโปรเซสเซอร์แบ่งออกเป็นโหมดผู้ใช้และโหมดการประมวลผลแบบสิทธิพิเศษ (เคอร์เนล) การเข้าถึงดิสก์และ I/O ทั้งหมดเกิดขึ้นภายใต้โหมดเคอร์เนล หากตัวนับนี้เกิน 25% ระบบอาจดำเนินการ I/O มากเกินไป ค่าปกติจะอยู่ระหว่าง 5% ถึง 10%

ความยาวคิวของโปรเซสเซอร์

ตัวนับนี้แสดงเธรดที่กำลังรอทรัพยากร CPU ค่าจะสูงกว่า 1 อย่างสม่ำเสมอ (ยกเว้นในระหว่าง SQL Server การบีบอัดข้อมูลสำรอง) บ่งชี้ถึงแรงกดดันของ CPU ซึ่งมักหมายถึงมีการติดตั้งแอปพลิเคชันอื่นบน SQL Server เครื่องจักรซึ่งละเมิดหลักปฏิบัติที่ดีที่สุด

การสลับบริบท/วินาที

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

3.3 ตัวนับประสิทธิภาพ I/O ของดิสก์

ตัวนับดิสก์มีความจำเป็นสำหรับการตรวจสอบประสิทธิภาพของ SQL เนื่องจาก I/O ของดิสก์มักกลายเป็นคอขวดหลักในระบบฐานข้อมูล

% เวลาดิสก์

ข้อมูลนี้บันทึกเปอร์เซ็นต์ของเวลาที่ดิสก์กำลังยุ่งอยู่กับการอ่าน/เขียน ค่าที่สูงกว่า 85% อย่างสม่ำเสมอบ่งชี้ถึงปัญหาคอขวดของ I/O เนื่องจากดิสก์ทำงานช้ากว่าหน่วยความจำมาก การลดค่าเมตริกนี้จึงช่วยเพิ่มประสิทธิภาพการทำงาน

ค่าเฉลี่ยของวินาทีดิสก์/การอ่าน และค่าเฉลี่ยของวินาทีดิสก์/การเขียน

ตัวนับเหล่านี้วัดเวลาเฉลี่ย (เป็นวินาที) สำหรับการอ่านและเขียน หากค่าเฉลี่ยเกิน 10-20 มิลลิวินาที แสดงว่าดิสก์ใช้เวลานานเกินไปในการประมวลผลข้อมูล ไดรฟ์บันทึกธุรกรรมต้องการประสิทธิภาพการเขียนที่รวดเร็วเป็นพิเศษ

ความยาวของคิวดิสก์

ข้อความนี้แสดงคำขออ่าน/เขียนลงดิสก์ที่ค้างอยู่ ค่าที่สูงกว่า 2 อย่างสม่ำเสมอ (หรือ 2 ต่อดิสก์สำหรับอาร์เรย์ RAID) บ่งชี้ว่าดิสก์ไม่สามารถรองรับคำขอ I/O ได้

ไบต์ดิสก์/วินาที

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

การถ่ายโอนดิสก์/วินาที

สิ่งนี้จะติดตามจำนวนการอ่าน/เขียนที่ดำเนินการบนดิสก์ SQL Server โดยทั่วไปการเข้าถึงข้อมูลจะเป็นแบบสุ่ม ซึ่งจะช้ากว่าเนื่องจากหัวอ่านไดรฟ์เคลื่อนที่ ตรวจสอบให้แน่ใจว่าค่านี้ต่ำกว่าค่าสูงสุดของไดรฟ์ (โดยทั่วไปคือ 100/วินาทีสำหรับไดรฟ์มาตรฐาน)

3.4 SQL Server เคาน์เตอร์เฉพาะ

3.4.1 ตัวนับบัฟเฟอร์ผู้จัดการ

ตัวนับบัฟเฟอร์ของ Buffer Manager SQL Serverการดำเนินการบัฟเฟอร์หน่วยความจำของ:

อ่านหน้า/วินาที: จำนวนสะสมของการอ่านหน้าฐานข้อมูลทางกายภาพ
หน้าเขียน/วินาที: จำนวนสะสมของการเขียนหน้าฐานข้อมูลทางกายภาพ
ขี้เกียจเขียน/วินาที: จำนวนบัฟเฟอร์ที่เขียนโดยนักเขียนขี้เกียจเพื่อล้างหน่วยความจำ
หน้าจุดตรวจ/วินาที: หน้าที่ถูกล้างโดยจุดตรวจสอบหรือการดำเนินการอื่น ๆ ที่ต้องล้างหน้าที่สกปรกทั้งหมด

3.4.2 ตัวนับสถิติ SQL

เคาน์เตอร์เหล่านี้ให้ข้อมูลเชิงลึกเกี่ยวกับ SQL Server การประมวลผลแบบสอบถาม:

คำขอแบบแบตช์/วินาที: จำนวนคำขอ SQL แบบแบตช์ที่เซิร์ฟเวอร์ได้รับ ซึ่งใช้เป็นเกณฑ์มาตรฐานสำหรับกิจกรรมของเซิร์ฟเวอร์
การรวบรวม SQL/วินาที: จำนวนการคอมไพล์ SQL ควรเป็น 10% หรือน้อยกว่าของจำนวนคำขอ Batch ทั้งหมดต่อวินาที
การรวบรวม SQL ใหม่/วินาที: จำนวนการคอมไพล์ SQL ใหม่ ควรเป็น 10% หรือน้อยกว่าของจำนวนคำขอ Batch ทั้งหมดต่อวินาที

3.4.3 ตัวนับสถิติทั่วไป

การเชื่อมต่อผู้ใช้: จำนวนผู้ใช้ที่เชื่อมต่อกับระบบ ใช้เป็นเกณฑ์มาตรฐานในการติดตามการเติบโตของการเชื่อมต่อเมื่อเวลาผ่านไป
กระบวนการที่ถูกบล็อค: จำนวนกระบวนการที่ถูกบล็อกในปัจจุบัน ควรเป็น 0

3.4.4 ตัวนับตัวจัดการหน่วยความจำ

การมอบหน่วยความจำที่รอดำเนินการ: จำนวนกระบวนการทั้งหมดที่รอการอนุญาตหน่วยความจำพื้นที่ทำงาน ควรเป็น 0 ตามหลักการ

4. การตั้งค่าการตรวจสอบประสิทธิภาพสำหรับ SQL Server(Windows Vista / Server 2008 และใหม่กว่า)

ก่อนอื่นเราต้องสร้างคอนเทนเนอร์เพื่อจัดการเคาน์เตอร์ได้ง่ายขึ้น:

สำหรับ Windows Vista / Server 2008 และรุ่นใหม่กว่า คุณสามารถสร้างชุดตัวรวบรวมข้อมูลได้ในส่วนนี้
สำหรับ Windows XP / Server 2003 และเวอร์ชันก่อนหน้า คุณสามารถสร้าง Counter Logs ได้ใน ส่วนถัดไป.

4.1 ชุดตัวรวบรวมข้อมูลคืออะไร?

ชุดตัวรวบรวมข้อมูลจะจัดระเบียบตัวนับประสิทธิภาพ ข้อมูลการติดตามเหตุการณ์ และข้อมูลการกำหนดค่าระบบไว้ในหน่วยรวบรวมข้อมูลเดียว ชุดตัวรวบรวมข้อมูลเหล่านี้มีความยืดหยุ่นมากกว่าบันทึกตัวนับแบบธรรมดา และช่วยให้สามารถรวบรวมข้อมูลตามกำหนดเวลาโดยอัตโนมัติเพื่อการตรวจสอบประสิทธิภาพฐานข้อมูล SQL ที่ครอบคลุม

4.2 การสร้างชุดตัวรวบรวมข้อมูล

สร้างชุดตัวรวบรวมข้อมูลที่กำหนดเองเพื่อตรวจสอบ SQL Server ตัวนับประสิทธิภาพ:

เปิดการตรวจสอบประสิทธิภาพ
แสดง ชุดรวบรวมข้อมูล
คลิกขวาที่ กำหนดโดยผู้ใช้
เลือก ใหม่ -> ชุดรวบรวมข้อมูล
ระบุชื่อที่อธิบายได้ (เช่น “SQL Server ตัวชี้วัดประสิทธิภาพ”)
เลือก สร้างด้วยตนเอง (ขั้นสูง)
คลิก ถัดไป
ตรวจสอบ สร้างบันทึกข้อมูล -> ตัวนับประสิทธิภาพ
คลิก ถัดไป
คลิก เพิ่ม เพื่อเลือกเคาน์เตอร์
เพิ่ม ที่ต้องการ SQL Server และเคาน์เตอร์ระบบ.
ชุด ช่วงเวลาตัวอย่าง
- สำหรับการตรวจสอบตามปกติ ให้ใช้ 1 นาที (60 วินาที)
- สำหรับการแก้ไขปัญหาเชิงรุก ให้ใช้เวลา 15-30 วินาที
- หลีกเลี่ยงการจับภาพความถี่สูงในระยะยาว เนื่องจากอาจส่งผลกระทบต่อประสิทธิภาพและสร้างข้อมูลมากเกินไป
คลิก ถัดไป
เลือกตำแหน่งที่จะบันทึกข้อมูล
คลิก เสร็จสิ้นชุดตัวรวบรวมข้อมูลใหม่จะถูกสร้างขึ้น
โดยค่าเริ่มต้น ชุดตัวรวบรวมข้อมูลใหม่จะ ไม่ จะเริ่มต้นทำงานโดยอัตโนมัติ คุณต้องค้นหาในแผงด้านซ้าย ใต้ ประสิทธิภาพ -> ชุดรวบรวมข้อมูล -> กำหนดโดยผู้ใช้ -> ตัวรวบรวมข้อมูลของคุณ คลิกขวาแล้วเลือก เริ่มต้น

4.3 ตัวนับหลักที่ต้องเพิ่ม

หน่วยความจำ -> เมกะไบต์ที่พร้อมใช้งาน
ดิสก์ทางกายภาพ -> ค่าเฉลี่ยของดิสก์/การอ่าน (ทุกอินสแตนซ์ ยกเว้น _Total)
ดิสก์ทางกายภาพ -> ค่าเฉลี่ยของดิสก์ วินาที/การเขียน (ทุกอินสแตนซ์ ยกเว้น _Total)
ดิสก์ทางกายภาพ -> การอ่านดิสก์/วินาที (ทุกอินสแตนซ์ ยกเว้น _Total)
ดิสก์ทางกายภาพ -> การเขียนดิสก์/วินาที (ทุกอินสแตนซ์ ยกเว้น _Total)
โปรเซสเซอร์ -> % เวลาโปรเซสเซอร์ (ทุกอินสแตนซ์ ยกเว้น _Total)
SQLServer: สถิติทั่วไป -> การเชื่อมต่อผู้ใช้
SQLServer: ตัวจัดการหน่วยความจำ -> การอนุญาตหน่วยความจำรอดำเนินการ
SQLServer: สถิติ SQL -> คำขอชุด/วินาที
SQLServer: สถิติ SQL -> การรวบรวม SQL/วินาที
SQLServer: สถิติ SQL -> การคอมไพล์ SQL ใหม่/วินาที
ระบบ -> ความยาวคิวของโปรเซสเซอร์

4.4 การตั้งค่าเงื่อนไขการหยุด

กำหนดค่าเงื่อนไขการหยุดเพื่อป้องกันการเติบโตของข้อมูลที่ไม่จำกัด:

หลังจากสร้างชุดตัวรวบรวมข้อมูลแล้ว ให้คลิกขวาและเลือก อสังหาริมทรัพย์
คลิก เงื่อนไขการหยุด แถบ
ทำให้สามารถ ระยะเวลารวม
ตั้งระยะเวลาเป็น 1 วัน (24 ชั่วโมง)
คลิก OK เพื่อประหยัด

วิธีนี้จะช่วยป้องกันไม่ให้ไฟล์บันทึกมีขนาดใหญ่เกินไป และจะเริ่มต้นใหม่โดยอัตโนมัติหากมีการตั้งเวลาไว้

4.5 การกำหนดตารางการรวบรวมข้อมูล

รวบรวมข้อมูลอัตโนมัติเพื่อให้แน่ใจว่ามีการตรวจสอบอย่างสม่ำเสมอ:

คลิกขวาที่ชุดตัวรวบรวมข้อมูลของคุณและเลือก อสังหาริมทรัพย์
คลิก ตารางเวลา แถบ
คลิก เพิ่ม เพื่อสร้างตารางใหม่
ตั้งค่าวันที่และเวลาเริ่มต้น
กำหนดรูปแบบการเกิดซ้ำ (เช่น รายวัน)
คลิก OK เพื่อบันทึกตารางเวลา

สำหรับการเริ่มต้นทำงานอัตโนมัติ ให้กำหนดค่าชุดตัวเก็บรวบรวมข้อมูลให้เริ่มต้นทำงานเมื่อเซิร์ฟเวอร์บูตเครื่อง โดยการสร้างทริกเกอร์การเริ่มต้นใน Windows Task Scheduler

5. การตั้งค่าการตรวจสอบประสิทธิภาพสำหรับ SQL Server(Windows XP / Server 2003 และก่อนหน้า)

สำหรับ Windows XP / Server 2003 และเวอร์ชันก่อนหน้า คุณสามารถสร้าง Counter Logs ซึ่งช่วยให้คุณเลือกชุดตัวนับประสิทธิภาพและบันทึกลงในไฟล์เป็นระยะๆ

5.1 การสร้างบันทึกเคาน์เตอร์

ปฏิบัติตามขั้นตอนเหล่านี้เพื่อสร้างบันทึกเคาน์เตอร์ใหม่:

เปิดการตรวจสอบประสิทธิภาพ
แสดง บันทึกและการแจ้งเตือนประสิทธิภาพการทำงาน ในบานหน้าต่างด้านซ้าย
คลิกขวาที่ บันทึกการนับ
เลือก การตั้งค่าบันทึกใหม่
ตั้งชื่อบันทึกด้วยชื่อเซิร์ฟเวอร์ฐานข้อมูลของคุณ (เช่น “ProductionSQL01”)
คลิก OK เพื่อเริ่มต้นการกำหนดค่า

การสร้างบันทึกเคาน์เตอร์แยกกันสำหรับแต่ละเซิร์ฟเวอร์ทำให้คุณสามารถทดสอบประสิทธิภาพบนเซิร์ฟเวอร์แต่ละเครื่องได้โดยไม่ต้องรวบรวมข้อมูลสำหรับเซิร์ฟเวอร์ทั้งหมดพร้อมกัน

5.2 การเพิ่มตัวนับประสิทธิภาพ

หลังจากสร้างบันทึกเคาน์เตอร์แล้ว ให้เพิ่มเคาน์เตอร์ประสิทธิภาพเฉพาะที่คุณต้องการตรวจสอบ:

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

5.3 การกำหนดค่าช่วงตัวอย่าง

ช่วงตัวอย่างจะกำหนดความถี่ในการรวบรวมข้อมูลของ Performance Monitor กำหนดค่าช่วงเวลาที่เหมาะสมตามความต้องการในการตรวจสอบของคุณ:

ในคุณสมบัติบันทึกเคาน์เตอร์ ให้ค้นหา ตัวอย่างข้อมูลทุกๆ
ตั้งค่าช่วงเวลา (ค่าเริ่มต้นคือ 15 วินาที)
สำหรับการติดตามพื้นฐาน ให้ใช้ช่วงเวลา 1 นาทีสำหรับการรวบรวมข้อมูลรายวัน
สำหรับการแก้ไขปัญหา ให้ใช้ช่วงเวลา 15-30 วินาทีสำหรับช่วงเวลาสั้นๆ
คลิก OK เพื่อนำไปใช้

โปรดจำไว้ว่าช่วงเวลาที่สั้นกว่าจะสร้างข้อมูลได้มากกว่า ซึ่งอาจแสดงผลและวิเคราะห์ได้ยากขึ้น ช่วงเวลาที่ยาวกว่าอาจพลาดช่วงสำคัญๆ ไปได้ ควรสร้างสมดุลระหว่างความละเอียดของข้อมูลกับข้อกำหนดด้านการจัดเก็บและการวิเคราะห์

5.4 การกำหนดค่าไฟล์บันทึก

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

คลิก เข้าสู่ระบบไฟล์ แท็บในคุณสมบัติบันทึกตัวนับ
เปลี่ยนประเภทไฟล์บันทึกเป็น ไฟล์ข้อความ (คั่นด้วยจุลภาค) เพื่อการนำเข้า Excel ได้อย่างง่ายดาย
คลิก กำหนดค่า
ตั้งค่าเส้นทางไฟล์ไปยังตำแหน่งเฉพาะ (เช่น โฟลเดอร์ PerformanceLogs ที่ใช้ร่วมกัน)
คลิก OK เพื่อยืนยัน

ใช้การแชร์ที่สามารถเข้าถึงเครือข่ายได้สำหรับการจัดเก็บบันทึกเพื่อให้คุณสามารถเข้าถึงไฟล์จากระยะไกลและแบ่งปันกับผู้ใช้รายอื่นได้

5.5 การตั้งค่าข้อมูลประจำตัว

กำหนดค่าข้อมูลประจำตัวที่เหมาะสมเพื่อให้ Performance Monitor สามารถเข้าถึงระยะไกลได้ SQL Server ตัวอย่าง:

ในคุณสมบัติบันทึกเคาน์เตอร์ ให้ค้นหา เรียกใช้เป็น
กรอกชื่อผู้ใช้โดเมนของคุณในรูปแบบ: โดเมน\ชื่อผู้ใช้
คลิก การกำหนดรหัสผ่าน
กรอกและยืนยันรหัสผ่านของคุณ
คลิก OK เพื่อประหยัด

สิ่งนี้จะช่วยให้บริการ PerfMon รวบรวมสถิติโดยใช้สิทธิ์อนุญาตโดเมนของคุณแทนที่จะใช้ข้อมูลประจำตัวของตัวมันเอง

6. การวิเคราะห์ข้อมูลการตรวจสอบประสิทธิภาพ

6.1 การดูไฟล์บันทึกใน Performance Monitor

Performance Monitor สามารถแสดงข้อมูลประวัติจากไฟล์บันทึกที่บันทึกไว้ได้:

เปิดการตรวจสอบประสิทธิภาพ
ในบานหน้าต่างด้านซ้ายคลิก เครื่องมือตรวจสอบ -> การตรวจสอบประสิทธิภาพ.
คลิกขวาที่ใดก็ได้ในพื้นที่กราฟ
เลือก อสังหาริมทรัพย์
คลิก แหล่ง แถบ
เลือก ล็อกไฟล์ ปุ่มตัวเลือก
คลิก เพิ่ม
นำทางไปยังไฟล์บันทึกของคุณ (.blg หรือ .csv)
เลือกไฟล์และคลิก จุดเปิด
ใช้ ช่วงเวลา แถบเลื่อนเพื่อเลือกช่วงเวลาที่คุณต้องการวิเคราะห์
คลิก OK เพื่อปิดกล่องโต้ตอบคุณสมบัติ
คลิกไอคอนเครื่องหมายบวกสีเขียวเพื่อเพิ่มตัวนับจากไฟล์บันทึก
เลือกเคาน์เตอร์ที่ต้องการแสดง
คลิก OK

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

6.2 การส่งออกข้อมูลไปยัง Excel

Excel ให้ความสามารถในการวิเคราะห์อันทรงพลังสำหรับข้อมูลนับประสิทธิภาพ:

เปิด Performance Monitor โดยโหลดไฟล์บันทึกของคุณ
คลิกขวาที่ใดก็ได้ในพื้นที่กราฟ
เลือก บันทึกข้อมูลเป็น
เลือกตำแหน่งสำหรับไฟล์
เลือก ไฟล์ข้อความ (คั่นด้วยจุลภาค) (.csv) จากเมนูแบบเลื่อนลง
คลิก ลด
เปิดไฟล์ CSV ใน Excel

จัดรูปแบบข้อมูลที่ส่งออกเพื่อการวิเคราะห์ที่ดีขึ้น:

ลบแถว 2 ที่ว่างครึ่งหนึ่งและล้างเซลล์ A1
จัดรูปแบบคอลัมน์ A เป็นวันที่/เวลา
จัดรูปแบบคอลัมน์ตัวเลขด้วยทศนิยมศูนย์และตัวคั่นหลักพัน
ค้นหาและแทนที่ชื่อเซิร์ฟเวอร์ในส่วนหัว (เช่น แทนที่ “\\SERVERNAME” ด้วยช่องว่าง)
ทำความสะอาดชื่อวัตถุในส่วนหัว (เช่น “หน่วยความจำ”, “ดิสก์ทางกายภาพ”, “โปรเซสเซอร์”)
ลดขนาดตัวอักษรส่วนหัวลงเหลือ 8 พอยต์เพื่อการมองเห็นที่ดีขึ้น

6.3 การตีความค่าเคาน์เตอร์

6.3.1 การวิเคราะห์ตัวนับหน่วยความจำ

เมื่อวิเคราะห์ตัวนับหน่วยความจำ ให้มองหาตัวบ่งชี้เหล่านี้:

เมกะไบต์ที่พร้อมใช้งาน: ควรอยู่เหนือ 4096 MB อย่างสม่ำเสมอ
อายุการใช้งานของหน้า: ค่าที่สูงกว่า 300 วินาทีบ่งชี้ว่าความจำอยู่ในระดับปกติ ค่าที่ต่ำกว่าบ่งชี้ว่าความจำถูกกดดัน
อัตราส่วนการกระทบแคชบัฟเฟอร์: ควรตรงตามหรือเกิน 99% ค่าที่ต่ำกว่าบ่งชี้ว่ามีการอ่านดิสก์มากเกินไป
การมอบหน่วยความจำที่รอดำเนินการ: ค่าควรเป็น 0 เสมอ ค่าบวกใดๆ ก็ตามบ่งชี้ว่าหน่วยความจำไม่เพียงพอ

6.3.2 การวิเคราะห์การนับ CPU

ตัวบ่งชี้ประสิทธิภาพ CPU ประกอบด้วย:

% เวลาประมวลผล: การใช้งานต่อเนื่องเกิน 75% บ่งชี้ถึงปัญหาด้านประสิทธิภาพ การพุ่งขึ้นถึง 100% ถือเป็นเรื่องปกติ แต่ไม่ควรเกิดขึ้นต่อเนื่อง
ความยาวคิวของโปรเซสเซอร์: ค่าที่สูงกว่า 1 แสดงถึงแรงกดดันของ CPU ตรวจสอบตัวจัดการงานเพื่อระบุว่ากระบวนการใดใช้ CPU
% เวลาที่มีสิทธิพิเศษ: ควรอยู่ระหว่าง 5-10% ค่าที่สูงกว่า 25% แสดงถึงการดำเนินการ I/O ที่มากเกินไป

6.3.3 การวิเคราะห์ตัวนับดิสก์

เกณฑ์ประสิทธิภาพของดิสก์:

ค่าเฉลี่ยวินาทีดิสก์/การอ่านและการเขียน: ควรอยู่ต่ำกว่า 10-20ms ค่าที่สูงขึ้นบ่งชี้ว่าระบบย่อยของดิสก์ทำงานช้า
ความยาวคิวดิสก์: ค่าที่สูงกว่า 2 อย่างสม่ำเสมอ (หรือ 2 ต่อดิสก์ใน RAID) บ่งชี้ถึงปัญหาคอขวด I/O
% เวลาดิสก์: ค่าคงที่ที่สูงกว่า 85% บ่งชี้ถึงความอิ่มตัวของดิสก์

6.4 การใช้สูตรและสถิติ

เพิ่มสูตรสถิติลงใน Excel เพื่อการวิเคราะห์อย่างรวดเร็ว:

แทรก 7 แถวว่างที่ด้านบนของสเปรดชีตของคุณ
เพิ่มป้ายกำกับในคอลัมน์ A: ค่าเฉลี่ย ค่ามัธยฐาน ค่าต่ำสุด ค่าสูงสุด ค่าเบี่ยงเบนมาตรฐาน
ในเซลล์ B2 ให้ป้อน: =AVERAGE(B9:B100) (ปรับ B100 ให้เป็นแถวข้อมูลสุดท้ายของคุณ)
ในเซลล์ B3 ให้ป้อน: =MEDIAN(B9:B100)
ในเซลล์ B4 ให้ป้อน: =MIN(B9:B100)
ในเซลล์ B5 ให้ป้อน: =MAX(B9:B100)
ในเซลล์ B6 ให้ป้อน: =STDEV(B9:B100)
คัดลอกสูตรไปยังคอลัมน์ตัวนับทั้งหมด
เลือกเซลล์ B9 แล้วกด Alt+W+F+Enter เพื่อตรึงบานหน้าต่าง

สถิติเหล่านี้ช่วยระบุแนวโน้ม ค่าผิดปกติ และช่วงการทำงานปกติสำหรับตัวนับแต่ละตัว

7. เครื่องมือวิเคราะห์ประสิทธิภาพสำหรับบันทึก (PAL)

7.1 บทนำสู่ PAL

Performance Analysis for Logs (PAL) เป็นเครื่องมือฟรีที่พัฒนาโดย Clint Huffman ซึ่งวิเคราะห์บันทึก Performance Monitor และสร้างรายงาน HTML พร้อมการวิเคราะห์เกณฑ์ประสิทธิภาพ PAL จะเปรียบเทียบข้อมูลประสิทธิภาพของคุณกับเกณฑ์ที่ทราบ และให้คำแนะนำโดยละเอียดสำหรับ SQL Server การเพิ่มประสิทธิภาพการทำงาน

ดาวน์โหลด PAL จากที่เก็บ GitHub: https://github.com/clinthuffman/PAL

7.2 การตั้งค่า PAL

ติดตั้ง PAL โดยทำตามขั้นตอนเหล่านี้:

ดาวน์โหลดไฟล์ติดตั้ง PAL จาก GitHub
เรียกใช้โปรแกรมติดตั้ง
คลิก ถัดไป บนหน้าจอต้อนรับ
ตรวจสอบและยอมรับไดเร็กทอรีการติดตั้ง
คลิก ถัดไป ดำเนินการต่อไป
คลิก การติดตั้ง เพื่อเริ่มการติดตั้ง
รอให้การติดตั้งเสร็จสิ้น
คลิก เสร็จสิ้น

7.3 การประมวลผลไฟล์บันทึกด้วย PAL

วิเคราะห์บันทึกการตรวจสอบประสิทธิภาพของคุณโดยใช้ PAL:

เรียกใช้ PAL จากเมนู Start หรือไดเร็กทอรีการติดตั้ง
คลิก บันทึกการนับ แถบ
คลิก หมวดหมู่สินค้า เพื่อเลือกไฟล์ .blg ของคุณ
นำทางไปยังไฟล์บันทึกการตรวจสอบประสิทธิภาพของคุณ
คลิก จุดเปิด
คลิก ไฟล์เกณฑ์ แถบ
เลือกไฟล์เกณฑ์จากดรอปดาวน์ (เช่น “SQL Server 2016” )
คลิก คำถามที่พบบ่อย แถบ
ตอบคำถามเกี่ยวกับการกำหนดค่าระบบของคุณ
ระบุว่าคุณ SQL Server คือ OLTP หรือ Data Warehouse
ระบุ RAM ทั้งหมดที่มี
คลิก ตัวเลือกการส่งออก แถบ
เลือกไดเรกทอรีเอาต์พุตสำหรับรายงาน HTML
ตรวจสอบ HTML รูปแบบผลลัพธ์
คลิก ดำเนินงาน แถบ
ตรวจสอบการเลือกของคุณ
ตรวจสอบ เริ่มดำเนินการทันที
คลิก เสร็จสิ้น

7.4 การวิเคราะห์รายงาน PAL

หลังจากที่ PAL วิเคราะห์เสร็จสิ้นแล้ว จะสร้างรายงาน HTML ที่มีเนื้อหาดังต่อไปนี้:

บทสรุปผู้บริหารเกี่ยวกับประเด็นด้านประสิทธิภาพ
การวิเคราะห์เชิงโต้ตอบโดยละเอียดพร้อมแผนภูมิ
การละเมิดเกณฑ์จะถูกเน้นด้วยสี
คำแนะนำเฉพาะสำหรับแต่ละประเด็น
แนวโน้มและรูปแบบทางประวัติศาสตร์

รายงานใช้รหัสสีเพื่อระบุระดับความรุนแรง: สีแดงสำหรับปัญหาร้ายแรง สีเหลืองสำหรับคำเตือน และสีเขียวสำหรับตัวชี้วัดที่ดี ทบทวนแต่ละส่วนเพื่อทำความเข้าใจปัญหาคอขวดด้านประสิทธิภาพและปฏิบัติตามคำแนะนำของ PAL สำหรับการเพิ่มประสิทธิภาพ

8. ทางเลือกอื่น SQL Server เครื่องมือตรวจสอบ

8.1 ในตัว SQL Server เครื่องมือ

8.1.1 SQL Server กิจกรรมการตรวจสอบ

SQL Server กิจกรรมการตรวจสอบ แสดงข้อมูลแบบเรียลไทม์เกี่ยวกับ SQL Server กระบวนการและประสิทธิภาพการทำงาน:

จุดเปิด SQL Server Management Studio (SSMS) และเชื่อมต่อกับอินสแตนซ์เซิร์ฟเวอร์ของคุณ
คลิกขวาที่ชื่อเซิร์ฟเวอร์ใน Object Explorer
เลือก กิจกรรมการตรวจสอบ

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

8.1.2 SQL Server แดชบอร์ดประสิทธิภาพ

SQL Server Management Studio มีรายงานประสิทธิภาพในตัว:

In SQL Server Management Studio (SSMS) คลิกขวาที่ SQL Server อินสแตนซ์ใน Object Explorer
เลือก รายงาน -> รายงานมาตรฐาน
เลือกจากรายงานที่มีให้เลือก เช่น แดชบอร์ดประสิทธิภาพ

แผงควบคุมประสิทธิภาพการทำงานให้ข้อมูลเชิงลึกเกี่ยวกับภาพ SQL Server ประสิทธิภาพของอินสแตนซ์ รวมถึงการใช้งาน CPU ของระบบ คำขอรอปัจจุบัน และเมตริกประสิทธิภาพ เข้าถึงได้ผ่านเมนูรายงานมาตรฐาน

8.1.3 SQL Server Profiler

SQL Server Profiler จับภาพและวิเคราะห์ SQL Server เหตุการณ์ต่างๆ เช่น การดำเนินการสอบถาม การดำเนินการธุรกรรม และกิจกรรมการเข้าสู่ระบบ

เริ่ม SQL Server โปรไฟล์:

In SQL Server Management Studio คลิก เครื่องมือ -> SQL Server Profiler

Profiler ทำให้เกิดภาระด้านประสิทธิภาพอย่างมาก ดังนั้นควรใช้ด้วยความระมัดระวังและควรใช้งานในช่วงเวลาที่ไม่ใช่ช่วงเวลาที่มีการใช้งานสูงสุด สำหรับสถานการณ์ส่วนใหญ่ Extended Events จะให้ประสิทธิภาพที่ดีกว่าโดยมีผลกระทบน้อยกว่า

8.1.4 เหตุการณ์ขยาย

กิจกรรมขยาย เป็นระบบตรวจสอบประสิทธิภาพน้ำหนักเบาที่สร้างขึ้นภายใน SQL Server. มันแทนที่ SQL Server โปรไฟเลอร์ที่มีประสิทธิภาพดีขึ้นและค่าใช้จ่ายต่ำลง

คุณสมบัติที่สำคัญ ได้แก่ :

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

สร้างเซสชันกิจกรรมขยายผ่าน SSMS:

In นักสำรวจวัตถุขยายเซิร์ฟเวอร์ของคุณและไปที่ การจัดการ -> กิจกรรมขยาย -> เซสชัน
คลิกขวาที่ไอคอน การประชุม และเลือก ตัวช่วยสร้างเซสชันใหม่
ทำตามคำแนะนำเพื่อเริ่มเซสชั่นใหม่

8.1.5 มุมมองการจัดการแบบไดนามิก (DMV)

DMV เปิดเผยข้อมูลสถานะเซิร์ฟเวอร์โดยละเอียดเพื่อการตรวจสอบสถานะ วินิจฉัยปัญหา และปรับแต่งประสิทธิภาพ DMV ที่สำคัญประกอบด้วย:

sys.dm_exec_query_stats: สถิติประสิทธิภาพการค้นหา
sys.dm_os_wait_stats: ประเภทการรอที่ส่งผลต่อประสิทธิภาพของเซิร์ฟเวอร์
sys.dm_os_performance_counters: SQL Server ข้อมูลตัวนับประสิทธิภาพ
คำขอ sys.dm_exec: กำลังดำเนินการตามคำขอ
sys.dm_exec_เซสชัน: เซสชันผู้ใช้ที่ใช้งานอยู่

สอบถามมุมมองเหล่านี้โดยใช้ T-SQL เพื่อเข้าถึงข้อมูลประสิทธิภาพแบบเรียลไทม์และเมตริกในประวัติ

การใช้งานพื้นฐาน

-- See all active connections
SELECT * FROM sys.dm_exec_connections;

-- View current sessions
SELECT * FROM sys.dm_exec_sessions;

-- Check database file stats
SELECT * FROM sys.dm_io_virtual_file_stats(NULL, NULL);

8.2 โซลูชันการตรวจสอบของบุคคลที่สาม

เรดเกต SQL Monitor

Redgate SQL Monitor เชี่ยวชาญด้านการตรวจสอบ SQL Server และสภาพแวดล้อม Azure SQL Database มอบการตรวจสอบที่ครอบคลุมทั่วทั้งองค์กร การแจ้งเตือนและแดชบอร์ดที่ปรับแต่งได้ ความสามารถในการรายงานโดยละเอียด และการผสานรวมกับเครื่องมือ Redgate อื่นๆ

SolarWinds SQL Server เครื่องมือตรวจสอบ

โซล่าร์วินด์ส SQL Server เครื่องมือตรวจสอบหรือที่เรียกว่า SQL Sentry ได้รับการออกแบบมาเพื่อวินิจฉัย แก้ไข และป้องกันปัญหาประสิทธิภาพการทำงานที่ร้ายแรง SQL Server.

ไอเดร่า SQL Server เครื่องมือตรวจสอบประสิทธิภาพ

IDERA SQL Diagnostic Manager เป็นเครื่องมือที่มีประสิทธิภาพ SQL Server เครื่องมือตรวจสอบประสิทธิภาพที่ออกแบบมาเพื่อช่วยในการตรวจสอบประสิทธิภาพเชิงรุก การวินิจฉัย และการปรับแต่ง

การตรวจสอบ SQL ของ Applications Manager

Applications Manager มี Microsoft SQL Server เครื่องมือตรวจสอบที่นำเสนอโซลูชันด้านไอทีที่มีประโยชน์ ได้รับการออกแบบมาเพื่อดูแลประสิทธิภาพของฐานข้อมูล SQL ในขณะเดียวกันก็ระบุจุดบกพร่องและแก้ไขปัญหาที่อาจนำไปสู่การหยุดชะงักในการดำเนินงานขององค์กรได้

8.3 เครื่องมือตรวจสอบโอเพนซอร์ส

ดีบีเอ แดช

DBA Dash เป็นเครื่องมือตรวจสอบโอเพ่นซอร์สฟรีที่ให้ข้อมูลเชิงลึกเกี่ยวกับ SQL Server สุขภาพ ประสิทธิภาพ และกิจกรรมต่างๆ มีประโยชน์อย่างยิ่งสำหรับสภาพแวดล้อมขนาดเล็กถึงขนาดกลาง และประกอบด้วยการตรวจสอบ DBA รายวัน การตรวจสอบประสิทธิภาพ และการติดตามการกำหนดค่า

SQLWATCH

SQLWATCH นำเสนอการกระจายอำนาจแบบเกือบเรียลไทม์ SQL Server การตรวจสอบด้วยความละเอียด 5 วินาทีสำหรับบันทึกปริมาณงานที่เพิ่มขึ้นอย่างรวดเร็ว รองรับ Grafana สำหรับแดชบอร์ดแบบเรียลไทม์ และ Power BI สำหรับการวิเคราะห์เชิงลึก เครื่องมือนี้มีตัวเลือกการกำหนดค่าที่ครอบคลุม ไม่ต้องบำรุงรักษา และปรับขนาดได้อย่างไม่จำกัด

ออปเซิร์ฟเวอร์

Opserver พัฒนาโดย Stack Exchange คอยตรวจสอบระบบต่างๆ รวมถึง SQL Server, Redis และ Elasticsearch มอบมุมมอง "เซิร์ฟเวอร์ทั้งหมด" สำหรับสถิติ CPU หน่วยความจำ เครือข่าย และฮาร์ดแวร์ทั่วทั้งโครงสร้างพื้นฐานของคุณ

sp_WhoIsActive

sp_WhoIsActive คือกระบวนการจัดเก็บสำหรับตรวจสอบกิจกรรมที่ครอบคลุม สร้างขึ้นโดย Adam Machanic ใช้งานได้กับทุก SQL Server เวอร์ชันตั้งแต่ปี 2005 จนถึงรุ่นปัจจุบัน และใช้กันอย่างแพร่หลายโดย SQL Server DBA สำหรับการตรวจสอบกิจกรรมแบบเรียลไทม์

ในการใช้ sp_WhoIsActive ให้ดาวน์โหลดจาก http://whoisactive.com/ ติดตั้งลงในฐานข้อมูลของคุณ และดำเนินการดังนี้:

EXEC sp_WhoIsActive

ขั้นตอนจะแสดงข้อมูลที่กำลังดำเนินการอยู่ ข้อมูลการรอ รายละเอียดการบล็อก และการใช้ทรัพยากร

9. แนวทางปฏิบัติที่ดีที่สุดสำหรับ SQL Server การตรวจสอบประสิทธิภาพ

9.1 การกำหนดเกณฑ์มาตรฐานประสิทธิภาพ

เกณฑ์มาตรฐานประสิทธิภาพจะกำหนดพารามิเตอร์การทำงานปกติให้กับคุณ SQL Server สิ่งแวดล้อม หากไม่มีข้อมูลพื้นฐาน คุณจะไม่สามารถระบุได้ว่าตัวชี้วัดปัจจุบันบ่งชี้ถึงปัญหาหรือพฤติกรรมทั่วไป

สร้างเส้นฐานโดย:

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

อัปเดตข้อมูลพื้นฐานทุกไตรมาสหรือหลังจากการเปลี่ยนแปลงโครงสร้างพื้นฐาน การอัปเดตแอปพลิเคชัน หรือการปรับเปลี่ยนฐานข้อมูลที่สำคัญ

9.2 การตั้งค่าเกณฑ์การแจ้งเตือนที่เหมาะสม

กำหนดค่าเกณฑ์อัจฉริยะเพื่อรับการแจ้งเตือนที่มีความหมายโดยไม่ต้องรับการแจ้งเตือนมากเกินไป:

การอนุญาตหน่วยความจำที่รอดำเนินการ > 0 บ่งชี้ถึงแรงกดดันของหน่วยความจำ
ความยาวคิวของโปรเซสเซอร์ > 2 ต่อคอร์ ชี้ให้เห็นถึงคอขวดของ CPU
วินาทีดิสก์/อ่านหรือเขียน > 20ms บ่งชี้ว่า I/O ช้า
กระบวนการที่ถูกบล็อก > 5 สัญญาณปัญหาการโต้แย้ง
อายุการใช้งานหน้า < 300 วินาที บ่งชี้ถึงแรงกดดันหน่วยความจำ

ปรับเกณฑ์ตามข้อมูลพื้นฐานและลักษณะเฉพาะของภาระงาน ใช้เกณฑ์แบบปรับเปลี่ยนได้ซึ่งคำนึงถึงความผันแปรตามปกติในสภาพแวดล้อมของคุณ

9.3 การตรวจสอบและวิเคราะห์ข้อมูลปกติ

กำหนดตารางการประเมินผลการปฏิบัติงานเป็นประจำเพื่อระบุแนวโน้มและปัญหาที่เกิดขึ้น:

รายวัน: ตรวจสอบเมตริกระดับสูงและการแจ้งเตือนล่าสุด
รายสัปดาห์: ดำเนินการวิเคราะห์เชิงลึกเกี่ยวกับแนวโน้มประสิทธิภาพ
รายเดือน: สร้างรายงานที่ครอบคลุมและเปรียบเทียบกับค่าพื้นฐาน
รายไตรมาส: ทบทวนการวางแผนกำลังการผลิตและแนวโน้มระยะยาว

บันทึกผลการค้นพบและติดตามการปรับปรุงประสิทธิภาพในช่วงเวลาต่างๆ

9.4 การปรับสมดุลค่าใช้จ่ายในการตรวจสอบ

การตรวจสอบนั้นใช้ทรัพยากร ดังนั้นจึงต้องรักษาสมดุลระหว่างการรวบรวมข้อมูลกับผลกระทบต่อประสิทธิภาพ:

ใช้ช่วงเวลา 30-60 วินาทีสำหรับการตรวจสอบอย่างต่อเนื่อง
ใช้ช่วงเวลา 15 วินาทีสำหรับการแก้ไขปัญหาที่ใช้งานอยู่เท่านั้น
จำกัดระยะเวลาการรวบรวมข้อมูล ตั้งค่าระยะเวลาเพื่อหลีกเลี่ยงข้อมูลที่มากเกินไป
จัดเก็บบันทึกบนไดรฟ์ที่แยกจากไฟล์ฐานข้อมูล
เก็บข้อมูลประสิทธิภาพเก่าเพื่อรักษาขนาดไฟล์ให้จัดการได้

Performance Monitor จะเพิ่มค่าใช้จ่ายขั้นต่ำเมื่อกำหนดค่าอย่างถูกต้อง โดยทั่วไปอยู่ที่ 2% ของทรัพยากรระบบ

9.5 การเก็บรักษาข้อมูลในระยะยาว

เก็บรักษาข้อมูลประสิทธิภาพเพื่อการวิเคราะห์แนวโน้มที่มีความหมายและการวางแผนกำลังการผลิต:

เก็บข้อมูลประสิทธิภาพการทำงานอย่างน้อย 1-2 ปี
เก็บข้อมูลแยกไว้ต่างหากหลังจาก 3-6 เดือน
บีบอัดไฟล์บันทึกเก่าเพื่อประหยัดพื้นที่
บันทึกเหตุการณ์สำคัญหรือการเปลี่ยนแปลงที่ส่งผลต่อประสิทธิภาพการทำงาน

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

9.6 การบูรณาการกับแนวทางปฏิบัติ DevOps

รวมการตรวจสอบประสิทธิภาพฐานข้อมูลลงในขั้นตอน CI/CD:

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

10. การแก้ไขปัญหาประสิทธิภาพทั่วไป

10.1 การระบุคอขวดของ CPU

ปัญหาคอขวดของ CPU มักเกิดจากเวลาตอบสนองของคิวรีที่ช้าและการใช้งานโปรเซสเซอร์ที่สูง ลองใช้ขั้นตอนเหล่านี้เพื่อวินิจฉัยปัญหา CPU:

ตรวจสอบตัวนับความยาวคิวโปรเซสเซอร์ ค่าที่สูงกว่า 2 ต่อคอร์บ่งชี้ถึงแรงกดดันของ CPU
ตรวจสอบเปอร์เซ็นต์เวลาประมวลผล ค่าที่คงอยู่มากกว่า 75% บ่งชี้ถึงปัญหาคอขวดของ CPU
เดสก์ท็อประยะไกลไปยัง SQL Server
เปิดตัวจัดการงาน (Ctrl+Shift+Esc)
คลิก กระบวนการ แถบ
ตรวจสอบ แสดงกระบวนการจากผู้ใช้ทั้งหมด
คลิก ซีพียู ส่วนหัวคอลัมน์ที่จะเรียงลำดับตามการใช้งาน CPU
ระบุกระบวนการที่ใช้ทรัพยากร CPU

หากไม่ใช่-SQL Server แอปพลิเคชันกิน CPU มาก ให้ลบแอปพลิเคชันเหล่านั้นออกจากเซิร์ฟเวอร์ฐานข้อมูล หาก sqlservr.exe ใช้ CPU สูง ให้ตรวจสอบโดยใช้วิธีการเหล่านี้:

ตรวจสอบการคอมไพล์ SQL/วินาทีและการคอมไพล์ SQL ซ้ำ/วินาที ค่าที่สูงกว่า 10% ของคำขอแบบกลุ่ม/วินาที บ่งชี้ว่าการคอมไพล์มากเกินไป
ค้นหา sys.dm_exec_query_stats เพื่อระบุการค้นหาที่ใช้ CPU มาก
ตรวจสอบแผนการดำเนินการสำหรับดัชนีที่ขาดหายไปหรือการดำเนินการที่ไม่มีประสิทธิภาพ
พิจารณาเพิ่มดัชนีเพื่อลดการสแกนตาราง

10.2 การวินิจฉัยปัญหาด้านความจำ

ปัญหาด้านความจำส่งผลกระทบอย่างมาก SQL Server ประสิทธิภาพ วินิจฉัยปัญหาหน่วยความจำโดยใช้ตัวบ่งชี้เหล่านี้:

หน่วยความจำที่พร้อมใช้งาน

หากหน่วยความจำที่ใช้งานได้ลดลงต่ำกว่า 100 MB อย่างต่อเนื่อง ระบบปฏิบัติการจะประสบปัญหาขาดแคลนหน่วยความจำ Windows อาจทำการสลับหน่วยความจำไปยังหน้าอื่น SQL Server หน่วยความจำลงในดิสก์ ทำให้ประสิทธิภาพลดลง

อายุการใช้งานหน้ากระดาษต่ำ

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

อัตราการเข้าใช้แคชบัฟเฟอร์ต่ำ

อัตราส่วนการกระทบแคชบัฟเฟอร์ต่ำกว่า 99% หมายความว่า SQL Server มักจะอ่านข้อมูลจากดิสก์มากกว่าหน่วยความจำ ซึ่งเกิดขึ้นเมื่อพูลบัฟเฟอร์มีขนาดเล็กเกินไปหรือ SQL Server เครื่องยังอยู่ในช่วงวอร์มเครื่องหลังจากรีสตาร์ท

หน่วยความจำมอบรอดำเนินการ

ค่าใดๆ ที่สูงกว่า 0 สำหรับ Memory Grants Pending แสดงว่ากำลังรอการอนุญาตหน่วยความจำอยู่ ซึ่งหมายความว่ากำลังมีหน่วยความจำไม่เพียงพอขั้นวิกฤตและจำเป็นต้องได้รับการแก้ไขโดยทันที

เพื่อแก้ไขปัญหาหน่วยความจำ:

กำหนดค่า SQL Server การตั้งค่าหน่วยความจำสูงสุดเพื่อให้เหลือ RAM ที่เพียงพอสำหรับระบบปฏิบัติการ (โดยทั่วไปคือ 4-8 GB ขึ้นอยู่กับขนาดเซิร์ฟเวอร์)
เปิดใช้งานการอนุญาต "ล็อคเพจในหน่วยความจำ" สำหรับ SQL Server บัญชีบริการ
เพิ่ม RAM ทางกายภาพให้กับเซิร์ฟเวอร์หากแรงกดดันด้านหน่วยความจำยังคงมีอยู่
ระบุและเพิ่มประสิทธิภาพแบบสอบถามที่ใช้หน่วยความจำมาก

10.3 การแก้ไขปัญหา I/O ของดิสก์

ดิสก์ I/O มักกลายเป็นปัญหาคอขวดหลักด้านประสิทธิภาพในระบบฐานข้อมูล วินิจฉัยปัญหาดิสก์โดยใช้วิธีการเหล่านี้:

ความยาวคิวดิสก์สูง

ความยาวของคิวดิสก์ที่สูงกว่า 2 อย่างสม่ำเสมอ (หรือ 2 ต่อดิสก์สำหรับ RAID) บ่งชี้ว่าระบบย่อยของดิสก์ไม่สามารถรองรับคำขอ I/O ได้ ทำให้เกิดการคั่งค้างของการดำเนินการที่รอดำเนินการ

ความหน่วงของดิสก์ที่มากเกินไป

ค่าค่าเฉลี่ยของวินาทีดิสก์/การอ่าน และค่าเฉลี่ยของวินาทีดิสก์/การเขียน ที่สูงกว่า 10-20 มิลลิวินาที บ่งชี้ว่าดิสก์ตอบสนองช้า ไดรฟ์บันทึกธุรกรรมต้องการประสิทธิภาพที่รวดเร็วเป็นพิเศษ โดยควรต่ำกว่า 5 มิลลิวินาทีสำหรับการเขียน

เปอร์เซ็นต์เวลาดิสก์สูง

เปอร์เซ็นต์เวลาใช้งานดิสก์ (Disk Time) ที่สูงกว่า 85% อย่างต่อเนื่อง แสดงว่าดิสก์เต็มประสิทธิภาพแล้ว ดิสก์ใช้เวลาส่วนใหญ่ในการประมวลผลคำขอ I/O โดยเหลือพื้นที่ว่างน้อยมาก

ก่อนที่จะแก้ไขปัญหาดิสก์ ให้ตรวจสอบว่าปัญหาเหล่านี้ไม่ใช่อาการของปัญหาหน่วยความจำ แรงหน่วยความจำไม่เพียงพอ SQL Server เพื่ออ่านข้อมูลเพิ่มเติมจากดิสก์โดยเพิ่มค่าเมตริกของดิสก์อย่างไม่เป็นธรรมชาติ

เพื่อแก้ไขปัญหา I/O ของดิสก์แท้:

อัพเกรดเป็นดิสก์ที่เร็วขึ้น (SSD แทน HDD)
ใช้งานการกำหนดค่า RAID เพื่อประสิทธิภาพที่ดีขึ้น
แยกไฟล์ฐานข้อมูล บันทึกธุรกรรม และ tempdb ลงในไดรฟ์ทางกายภาพที่แตกต่างกัน
เพิ่มหน่วยความจำเพื่อลดการอ่านดิสก์
เพิ่มประสิทธิภาพดัชนีเพื่อลด I/O ที่ไม่จำเป็น
ตรวจสอบและเพิ่มประสิทธิภาพแบบสอบถามที่มีประสิทธิภาพไม่ดี

10.4 การระบุการบล็อกและเดดล็อก

การบล็อกเกิดขึ้นเมื่อเซสชันหนึ่งล็อกไว้ ทำให้เซสชันอื่นๆ ไม่สามารถดำเนินการต่อได้ ตรวจสอบตัวนับเหล่านี้เพื่อระบุปัญหาการบล็อก:

กระบวนการที่ถูกบล็อค: ตามหลักการแล้วควรเป็น 0
ล็อครอ/วินาที: จำนวนคำขอล็อคที่ต้องรอ
เวลารอโดยเฉลี่ย: ระยะเวลาเฉลี่ยของการรอล็อค

เพื่อตรวจสอบการบล็อค:

เปิดตัวตรวจสอบกิจกรรมใน SSMS
ขยาย กระบวนการ ส่วน
มองหากระบวนการที่ไม่เป็นศูนย์ ถูกบล็อคโดย ค่า
ระบุ ID เซสชันการบล็อค
ตรวจสอบข้อสงสัยที่ทำให้เกิดการบล็อค

ใช้ sp_WhoIsActive เพื่อวิเคราะห์การบล็อกที่ละเอียดยิ่งขึ้น รายการ wait_info มากเกินไปมักบ่งชี้ถึงปัญหาการแย่งชิงหรือบล็อกของ tempdb

เพื่อลดการบล็อค:

ลดระยะเวลาการทำธุรกรรมให้สั้นที่สุด
ใช้ระดับการแยกที่เหมาะสม
เพิ่มดัชนีเพื่อลดระยะเวลาการล็อค
พิจารณาการแยก READ_COMMITTED_SNAPSHOT
ตรวจสอบและเพิ่มประสิทธิภาพแบบสอบถามที่รันยาวนาน

10.5 ปัญหาประสิทธิภาพการค้นหา

การระบุคิวรีที่มีค่าใช้จ่ายสูงเป็นสิ่งสำคัญสำหรับการตรวจสอบประสิทธิภาพของ SQL ใช้วิธีการเหล่านี้เพื่อค้นหาคิวรีที่มีปัญหา:

การใช้การตรวจสอบกิจกรรม

ใน SSMS คลิกขวาที่ชื่อเซิร์ฟเวอร์
เลือก กิจกรรมการตรวจสอบ
แสดง คำถามราคาแพงล่าสุด
ตรวจสอบแบบสอบถามที่มี CPU สูง ระยะเวลา หรือการอ่านเชิงตรรกะ

การใช้ DMV

สอบถาม sys.dm_exec_query_stats เพื่อระบุแบบสอบถามที่ใช้ทรัพยากรมาก:

SELECT TOP 50
    total_worker_time/execution_count AS avg_cpu_time,
    total_logical_reads/execution_count AS avg_logical_reads,
    execution_count,
    SUBSTRING(qt.text, (qs.statement_start_offset/2)+1,
        ((CASE qs.statement_end_offset
            WHEN -1 THEN DATALENGTH(qt.text)
            ELSE qs.statement_end_offset
        END - qs.statement_start_offset)/2) + 1) AS query_text
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
ORDER BY total_worker_time DESC

การวิเคราะห์แผนการดำเนินการ

ใน SSMS เปิดหน้าต่างแบบสอบถามใหม่
คลิก แสดงแผนการดำเนินการโดยประมาณ (Ctrl+L) หรือ รวมแผนการดำเนินการจริง (Ctrl+M)
ดำเนินการค้นหาของคุณ
ทบทวนแผนการดำเนินการสำหรับการดำเนินการที่มีราคาแพง
มองหาการสแกนตาราง การสแกนดัชนี หรือการดำเนินการที่มีต้นทุนสูง

เพิ่มประสิทธิภาพการค้นหาโดย:

การเพิ่มดัชนีที่เหมาะสม
การเขียนแบบสอบถามใหม่เพื่อหลีกเลี่ยงการดำเนินการที่มีราคาแพง
การอัพเดตสถิติ
ใช้ชื่อคอลัมน์เฉพาะแทน SELECT *
หลีกเลี่ยงคำสั่ง DISTINCT หรือ ORDER BY ที่ไม่จำเป็น

10.6 ตรวจจับและแก้ไขฐานข้อมูลที่เสียหาย

ความเสียหายของฐานข้อมูลอาจทำให้ประสิทธิภาพลดลง สูญเสียข้อมูล และระบบล้มเหลว การตรวจจับและแก้ไขปัญหาความเสียหายอย่างรวดเร็วเป็นสิ่งสำคัญอย่างยิ่งต่อการรักษาสุขภาพของฐานข้อมูล

ตัวบ่งชี้การทุจริตฐานข้อมูล

ระวังสัญญาณการทุจริตที่อาจเกิดขึ้นเหล่านี้:

ข้อความแสดงข้อผิดพลาดใน SQL Server บันทึกข้อผิดพลาด (ข้อผิดพลาด 823, 824 หรือ 825)
ข้อผิดพลาดของแอปพลิเคชันที่ไม่คาดคิดเมื่อเข้าถึงตารางที่ระบุ
ประสิทธิภาพการค้นหาที่ช้าบนการค้นหาแบบเร็วก่อนหน้านี้
SQL Server การขัดข้องหรือการรีสตาร์ทโดยไม่คาดคิด
หน้าที่น่าสงสัยปรากฏในตาราง msdb.dbo.suspect_pages

การใช้ DBCC CHECKDB เพื่อการตรวจจับ

DBCC CHECKDB เป็นเครื่องมือหลักสำหรับตรวจจับความเสียหายของฐานข้อมูล ใช้งานเป็นประจำเพื่อตรวจจับปัญหาได้ตั้งแต่เนิ่นๆ

การติดตามหน้าผู้ต้องสงสัย

SQL Server บันทึกหน้าที่น่าสงสัยลงในฐานข้อมูล msdb โดยอัตโนมัติ:

SELECT 
    database_id,
    file_id,
    page_id,
    event_type,
    error_count,
    last_update_date
FROM msdb.dbo.suspect_pages
WHERE event_type IN (1,2,3)

แถวใดๆ ที่ส่งคืนแสดงถึงปัญหาการทุจริตที่ต้องได้รับการแก้ไขทันที

กลยุทธ์การป้องกันการทุจริต

เปิดใช้งานการตรวจสอบหน้าด้วยตัวเลือก CHECKSUM
รักษาการสำรองข้อมูลฐานข้อมูลเป็นประจำ
ใช้ฮาร์ดแวร์ที่เชื่อถือได้พร้อมการแก้ไขข้อผิดพลาด
ตรวจสอบสุขภาพดิสก์โดยใช้เครื่องมือของผู้ผลิต
กำหนดตารางการทำงาน DBCC CHECKDB เป็นประจำ
เก็บ SQL Server อัปเดตด้วยแพตช์ล่าสุด

ตัวเลือกการกู้คืนและการซ่อมแซม

หากตรวจพบการทุจริต คุณสามารถลองใช้เครื่องมือในตัวได้ DBCC CHECKDB เพื่อแก้ไขปัญหา หากล้มเหลว ให้ใช้เครื่องมือของบุคคลที่สาม เช่น DataNumen SQL Recovery ซึ่งสามารถรับมือกับการทุจริตคอร์รัปชั่นที่ร้ายแรงได้

11. เทคนิคการตรวจสอบขั้นสูง

11.1 การตรวจสอบร้านค้าแบบสอบถาม

Query Store เปิดตัวใน SQL Server 2016 รวบรวมข้อมูลประสิทธิภาพการสืบค้นโดยอัตโนมัติ มอบข้อมูลเชิงลึกอันมีค่าเกี่ยวกับพฤติกรรมการสืบค้น แผนการดำเนินการ และแนวโน้มประสิทธิภาพ

การเปิดใช้งาน Query Store

ใน SSMS Object Explorer ให้คลิกขวาที่ฐานข้อมูล
เลือก อสังหาริมทรัพย์
คลิก ร้านค้าแบบสอบถาม หน้า
In โหมดการทำงาน (ตามที่ร้องขอ)ให้เลือก อ่านเขียน
กำหนดค่าการตั้งค่าเพิ่มเติมตามต้องการ
คลิก OK

การตรวจสอบประสิทธิภาพการค้นหา

เข้าถึงรายงาน Query Store ผ่าน Object Explorer:

ขยายฐานข้อมูลใน Object Explorer
แสดง ร้านค้าแบบสอบถาม
เลือกจากรายงานที่มีให้เลือก:
- แบบสอบถามถดถอย
- การใช้ทรัพยากรโดยรวม
- การค้นหาทรัพยากรที่ใช้มากที่สุด
- การสอบถามเกี่ยวกับแผนการบังคับ
- การติดตามคำถาม

การตรวจจับการถดถอยของแผน

Query Store จะตรวจจับโดยอัตโนมัติเมื่อแผนการดำเนินการคิวรีมีการเปลี่ยนแปลงและประสิทธิภาพลดลง ตรวจสอบรายงาน Regressed Queries เพื่อระบุคิวรีที่ได้รับผลกระทบจากการเปลี่ยนแปลงแผน

การจัดการแผนบังคับ

เมื่อ Query Store ระบุแผนการดำเนินการที่ดีกว่า ให้บังคับใช้ SQL Server วิธีใช้:

เปิดแบบสอบถามใน Query Store
คลิกขวาที่แผนที่ต้องการ
เลือก แผนกำลังพล

วิธีนี้จะช่วยปรับปรุงประสิทธิภาพได้ทันทีโดยไม่ต้องเปลี่ยนแปลงโค้ด

11.2 การตรวจสอบการบำรุงรักษาดัชนี

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

การตรวจสอบการแตกกระจาย

ใช้แบบสอบถามนี้เพื่อตรวจสอบการกระจายตัวของดัชนี:

SELECT 
    OBJECT_NAME(i.object_id) AS table_name,
    i.name AS index_name,
    ps.avg_fragmentation_in_percent,
    ps.page_count
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'SAMPLED') ps
INNER JOIN sys.indexes i ON ps.object_id = i.object_id 
    AND ps.index_id = i.index_id
WHERE ps.avg_fragmentation_in_percent > 10
    AND ps.page_count > 1000
ORDER BY ps.avg_fragmentation_in_percent DESC

รันแบบสอบถามนี้ในช่วงนอกเวลาเร่งด่วน เนื่องจากอาจต้องใช้ทรัพยากรมาก

การวิเคราะห์ความหนาแน่นของหน้า

ความหนาแน่นของหน้าบ่งชี้ว่าหน้าดัชนีเต็มแค่ไหน ความหนาแน่นต่ำทำให้เปลืองพื้นที่และลดประสิทธิภาพ:

SELECT 
    OBJECT_NAME(i.object_id) AS table_name,
    i.name AS index_name,
    ps.avg_page_space_used_in_percent
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'SAMPLED') ps
INNER JOIN sys.indexes i ON ps.object_id = i.object_id 
    AND ps.index_id = i.index_id
WHERE ps.avg_page_space_used_in_percent < 75

การตัดสินใจในการจัดระเบียบใหม่ vs. การสร้างใหม่

เลือกการดำเนินการบำรุงรักษาดัชนีตามระดับการกระจายตัว:

การแตกกระจาย 10-30%: ใช้ ALTER INDEX REORGANIZE
การกระจายตัว > 30%: ใช้ ALTER INDEX REBUILD
การกระจายตัว < 10%: ไม่ต้องดำเนินการใดๆ

การปรับโครงสร้างการดำเนินงานใช้ทรัพยากรน้อยลงและสามารถดำเนินการแบบออนไลน์ได้ ส่วนการปรับโครงสร้างการดำเนินงานจะครอบคลุมมากขึ้น แต่ใช้ทรัพยากรจำนวนมาก

11.3 การอัปเดตสถิติฐานข้อมูล

ความช่วยเหลือด้านสถิติฐานข้อมูล SQL Serverตัวเพิ่มประสิทธิภาพการค้นหาของ 's สร้างแผนการดำเนินการที่มีประสิทธิภาพ สถิติที่ล้าสมัยนำไปสู่ประสิทธิภาพการค้นหาที่ย่ำแย่

การสร้างสถิติใหม่โดยอัตโนมัติ

เปิดใช้งานการอัพเดทสถิติอัตโนมัติ:

ALTER DATABASE DatabaseName SET AUTO_UPDATE_STATISTICS ON
ALTER DATABASE DatabaseName SET AUTO_CREATE_STATISTICS ON

การติดตามสถิติสุขภาพ

ตรวจสอบว่าสถิติได้รับการอัปเดตครั้งล่าสุดเมื่อใด:

SELECT 
    OBJECT_NAME(s.object_id) AS TableName,
    s.name AS StatisticsName,
    STATS_DATE(s.object_id, s.stats_id) AS LastUpdated,
    sp.rows,
    sp.modification_counter
FROM sys.stats s
CROSS APPLY sys.dm_db_stats_properties(s.object_id, s.stats_id) sp
WHERE STATS_DATE(s.object_id, s.stats_id) < DATEADD(DAY, -7, GETDATE())
ORDER BY LastUpdated

อัปเดตสถิติด้วยตนเองเมื่อจำเป็น:

UPDATE STATISTICS TableName WITH FULLSCAN

11.4 การรวบรวมข้อมูลประสิทธิภาพที่กำหนดเอง

สร้างโซลูชันการตรวจสอบประสิทธิภาพแบบกำหนดเองได้โดยสอบถาม sys.dm_os_performance_counters โดยตรงและจัดเก็บผลลัพธ์ในตาราง

การสร้างสคริปต์คอลเลกชันแบบกำหนดเอง

สร้างกระบวนการจัดเก็บเพื่อรวบรวมข้อมูลตัวนับประสิทธิภาพ:

CREATE PROCEDURE dbo.CollectPerformanceCounters
AS
BEGIN
    INSERT INTO dbo.PerformanceHistory (
        SampleTime,
        CounterName,
        CounterValue
    )
    SELECT 
        GETDATE(),
        counter_name,
        cntr_value
    FROM sys.dm_os_performance_counters
    WHERE counter_name IN (
        'Page life expectancy',
        'Batch Requests/sec',
        'Buffer cache hit ratio'
    )
END

การใช้ sys.dm_os_performance_counters

สอบถามตัวนับประสิทธิภาพโดยตรง:

SELECT 
    object_name,
    counter_name,
    instance_name,
    cntr_value,
    cntr_type
FROM sys.dm_os_performance_counters
WHERE object_name LIKE '%Buffer Manager%'
ORDER BY counter_name

การจัดเก็บข้อมูลประวัติ

สร้างตารางเพื่อเก็บเมตริกประสิทธิภาพในแต่ละช่วงเวลา:

CREATE TABLE dbo.PerformanceHistory (
    ID INT IDENTITY PRIMARY KEY,
    SampleTime DATETIME2 NOT NULL,
    PageLifeExpectancy BIGINT,
    BatchRequestsPerSec DECIMAL(18,4),
    BufferCacheHitRatio DECIMAL(5,2)
)

CREATE CLUSTERED COLUMNSTORE INDEX CCI_PerformanceHistory 
ON dbo.PerformanceHistory

วิธีการจัดเก็บข้อมูลแบบหมุน

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

11.5 การตรวจสอบหลายเซิร์ฟเวอร์

สำหรับสภาพแวดล้อมที่มีหลาย SQL Server กรณีตัวอย่าง ให้ดำเนินการตรวจสอบแบบรวมศูนย์

แนวทางการตรวจสอบแบบรวมศูนย์

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

การตรวจสอบเซิร์ฟเวอร์ระยะไกล

กำหนดค่า Performance Monitor เพื่อรวบรวมข้อมูลจากเซิร์ฟเวอร์ระยะไกลโดยระบุชื่อเซิร์ฟเวอร์เมื่อเพิ่มตัวนับ ตรวจสอบให้แน่ใจว่ากฎไฟร์วอลล์อนุญาตการรับส่งข้อมูลของ Performance Monitor

การรายงานข้ามเซิร์ฟเวอร์

สร้างรายงานที่เปรียบเทียบประสิทธิภาพการทำงานระหว่างเซิร์ฟเวอร์หลายเครื่องเพื่อระบุค่าผิดปกติและความไม่สมดุลของความจุ

12 การตรวจสอบ SQL Server ในสภาพแวดล้อมคลาวด์

12.1 การตรวจสอบฐานข้อมูล Azure SQL

Azure SQL Database มอบความสามารถในการตรวจสอบในตัวที่แตกต่างจากภายในองค์กร SQL Server.

การรวมระบบ Azure Monitor

Azure Monitor รวบรวมเมตริกจาก Azure SQL Database โดยอัตโนมัติ รวมถึง:

การใช้ DTU หรือ vCore
การใช้การจัดเก็บข้อมูล
สถิติการเชื่อมต่อ
เดดล็อกและหมดเวลา

เข้าถึงเมตริกเหล่านี้ผ่านทาง Azure Portal หรือ Azure Monitor API

คุณสมบัติการตรวจสอบในตัว

ฐานข้อมูล Azure SQL ประกอบด้วย:

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

ข้อมูลเชิงลึกเกี่ยวกับประสิทธิภาพการค้นหา

ฟีเจอร์นี้แสดงภาพคิวรีที่ใช้ทรัพยากรสูงสุด การวิเคราะห์ระยะเวลาคิวรี และแนวโน้มประสิทธิภาพในอดีต เข้าถึงได้ผ่าน Azure Portal ภายใต้ทรัพยากรฐานข้อมูล SQL ของคุณ

12.2 เครื่องมือตรวจสอบแบบคลาวด์เนทีฟ

แพลตฟอร์มคลาวด์นำเสนอโซลูชันการตรวจสอบดั้งเดิมที่ปรับให้เหมาะสมสำหรับสภาพแวดล้อมของพวกเขา:

Azure Monitor และ Application Insights สำหรับฐานข้อมูล Azure SQL
AWS CloudWatch สำหรับ RDS SQL Server
การตรวจสอบ Google Cloud สำหรับระบบคลาวด์ SQL Server

เครื่องมือเหล่านี้บูรณาการกับโครงสร้างพื้นฐานคลาวด์ได้อย่างราบรื่นและให้การตรวจสอบแบบรวมศูนย์ในทรัพยากรคลาวด์ทั้งหมด

การตรวจสอบสภาพแวดล้อมแบบไฮบริด

สำหรับการปรับใช้แบบไฮบริดที่ครอบคลุมทั้งภายในสถานที่และบนคลาวด์ ให้ใช้เครื่องมือที่รองรับทั้งสภาพแวดล้อม เช่น Redgate SQL Monitor, SolarWinds DPA หรือโซลูชันแบบกำหนดเองโดยใช้การรวบรวมข้อมูลแบบรวมศูนย์

12.3 ความแตกต่างของประสิทธิภาพในระบบคลาวด์

เมฆ SQL Server สภาพแวดล้อมมีลักษณะเฉพาะตัว:

แบบจำลองการจัดสรรทรัพยากร

ผู้ให้บริการคลาวด์ใช้วิธีการจัดสรรทรัพยากรที่แตกต่างกัน (DTU, vCore, แบบไร้เซิร์ฟเวอร์) ซึ่งส่งผลต่อวิธีการตีความตัวชี้วัดประสิทธิภาพ ทำความเข้าใจข้อจำกัดและคุณลักษณะของระดับบริการของคุณ

ข้อควรพิจารณาในการปรับขนาด

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

13. การตรวจสอบประสิทธิภาพการทำงานอัตโนมัติ

13.1 SQL Server งานตัวแทน

การรวบรวมข้อมูลอัตโนมัติโดยใช้ SQL Server งานตัวแทนสำหรับการตรวจสอบที่สม่ำเสมอโดยไม่ต้องมีการแทรกแซงด้วยตนเอง

การรวบรวมข้อมูลตามกำหนดเวลา

ใน SSMS ขยาย SQL Server ตัวแทน
คลิกขวาที่ งาน และเลือก งานใหม่
ตั้งชื่องาน (เช่น “รวบรวมตัวชี้วัดประสิทธิภาพ”)
คลิก ขั้นตอน และเพิ่มขั้นตอนใหม่
ตั้งค่าประเภทเป็น สคริปต์ Transact-SQL
ป้อนสคริปต์การรวบรวมข้อมูลของคุณ
คลิก ตารางเวลา และเพิ่มตารางเวลา
กำหนดค่าความถี่ (เช่น ทุก ๆ 5 นาที)
คลิก OK เพื่อสร้างงาน

การรายงานอัตโนมัติ

สร้างงานที่สร้างและส่งรายงานประสิทธิภาพทางอีเมล:

สร้างกระบวนการจัดเก็บที่สร้างรายงาน
ใช้ Database Mail เพื่อส่งรายงานผ่านอีเมล
กำหนดเวลาให้ทำงานรายวันหรือรายสัปดาห์

13.2 การทำงานอัตโนมัติของ PowerShell

PowerShell ให้ความสามารถในการทำงานอัตโนมัติอันทรงพลังสำหรับ SQL Server การตรวจสอบประสิทธิภาพการทำงาน

สคริปต์การรวบรวมตัวนับประสิทธิภาพ

$counters = @(
    '\Processor(_Total)\% Processor Time',
    '\Memory\Available MBytes',
    '\PhysicalDisk(_Total)\Avg. Disk sec/Read'
)

$data = Get-Counter -Counter $counters -ComputerName 'SQLServer01'
$data.CounterSamples | Export-Csv 'C:\PerfLogs\counters.csv' -Append

การสอบถาม WMI

ใช้ WMI เพื่อรวบรวมข้อมูลประสิทธิภาพจากเซิร์ฟเวอร์ระยะไกล:

$cpu = Get-WmiObject Win32_Processor -ComputerName 'SQLServer01'
$memory = Get-WmiObject Win32_OperatingSystem -ComputerName 'SQLServer01'

Write-Host "CPU Usage: $($cpu.LoadPercentage)%"
Write-Host "Available Memory: $([math]::Round($memory.FreePhysicalMemory/1MB,2)) GB"

การแจ้งเตือนอัตโนมัติ

สร้างสคริปต์ PowerShell ที่จะตรวจสอบเมตริกและส่งการแจ้งเตือนเมื่อมีการละเมิดเกณฑ์:

$cpuThreshold = 80
$cpu = (Get-Counter '\Processor(_Total)\% Processor Time').CounterSamples.CookedValue

if ($cpu -gt $cpuThreshold) {
    Send-MailMessage -To 'dba@company.com' -Subject 'High CPU Alert' `
        -Body "CPU usage is $cpu%" -SmtpServer 'smtp.company.com'
}

13.3 การสร้างแดชบอร์ดการตรวจสอบ

แสดงภาพข้อมูลประสิทธิภาพด้วยแดชบอร์ดแบบโต้ตอบเพื่อให้ได้ข้อมูลเชิงลึกที่ดีขึ้น

การรวม Power BI

เชื่อมต่อ Power BI กับตารางข้อมูลประสิทธิภาพของคุณ
สร้างการแสดงภาพสำหรับตัวชี้วัดที่สำคัญ
เพิ่มตัวแบ่งส่วนสำหรับช่วงเวลาและการเลือกเซิร์ฟเวอร์
เผยแพร่แดชบอร์ดไปยังบริการ Power BI
กำหนดค่ากำหนดการรีเฟรชอัตโนมัติ

การสร้างแดชบอร์ดแบบเรียลไทม์

ใช้เครื่องมือเช่น Grafana หรือแอปพลิเคชันเว็บแบบกำหนดเองเพื่อสร้างแดชบอร์ดแบบเรียลไทม์ที่สอบถาม DMV และตัวนับประสิทธิภาพโดยตรง

การสร้างภาพแนวโน้มทางประวัติศาสตร์

สร้างแผนภูมิเส้นที่แสดงแนวโน้มในช่วงเวลาต่างๆ สำหรับ:

การใช้งาน CPU
การใช้ความจำ
ดิสก์ I / O
ประสิทธิภาพการสืบค้น
การเชื่อมต่อนับ

14. กรณีศึกษาและตัวอย่างเชิงปฏิบัติ

14.1 กรณีศึกษา: การแก้ไขแรงกดดันหน่วยความจำ

การระบุอาการ

การผลิต SQL Server ประสบปัญหาเวลาตอบสนองของคิวรีช้าในช่วงชั่วโมงเร่งด่วน ผู้ใช้บ่นเรื่องแอปพลิเคชันหมดเวลาและประสิทธิภาพการทำงานลดลง

การวิเคราะห์ตอบโต้

ข้อมูล Performance Monitor เปิดเผย:

อายุการใช้งานของหน้าลดลงเหลือ 50 วินาที (ปกติ: >300)
อัตราส่วนการกระทบแคชบัฟเฟอร์ลดลงเหลือ 85% (ปกติ: >99%)
การมอบหน่วยความจำที่ค้างอยู่มักแสดงค่า 5-10
การอ่านดิสก์ทางกายภาพต่อวินาทีเพิ่มขึ้นอย่างมาก

ขั้นตอนการแก้ปัญหา

ถูกตรวจสอบ SQL Server การตั้งค่าหน่วยความจำสูงสุด – พบว่ามีการตั้งค่าเป็นค่าเริ่มต้น (ไม่จำกัด)
ตรวจสอบเปรียบเทียบหน่วยความจำเซิร์ฟเวอร์ทั้งหมดกับหน่วยความจำเซิร์ฟเวอร์เป้าหมายแล้ว พบว่ามีความแตกต่างอย่างมีนัยสำคัญ
กำหนดค่าหน่วยความจำเซิร์ฟเวอร์สูงสุดให้เหลือ 8 GB สำหรับระบบปฏิบัติการ
เปิดใช้งานการอนุญาต "ล็อคหน้าในหน่วยความจำ" สำหรับ SQL Server บัญชีบริการ
เพิ่ม RAM อีก 32 GB ให้กับเซิร์ฟเวอร์
ตรวจสอบประสิทธิภาพเป็นเวลาหนึ่งสัปดาห์ – อายุการใช้งานของเพจคงที่เหนือ 500 วินาที

ผลลัพธ์: เวลาตอบสนองของคำถามได้รับการปรับปรุงดีขึ้น 60% การร้องเรียนของผู้ใช้หยุดลง และประสิทธิภาพการทำงานของแอปพลิเคชันกลับมาเป็นปกติ

14.2 กรณีศึกษา: การเพิ่มประสิทธิภาพ CPU

การระบุอาการ

A SQL Server แสดงให้เห็นการใช้งาน CPU สูงกว่า 90% อย่างต่อเนื่องในระหว่างเวลาทำการ ส่งผลให้ประสิทธิภาพการทำงานของแอปพลิเคชันช้าลงและผู้ใช้เกิดความหงุดหงิด

การวิเคราะห์ตอบโต้

การติดตามผลการปฏิบัติงานเผยว่า:

% เวลาประมวลผลเฉลี่ย 92% โดยมีการเพิ่มขึ้นบ่อยครั้งถึง 100%
ความยาวคิวของโปรเซสเซอร์สูงกว่า 4 อย่างสม่ำเสมอ (เซิร์ฟเวอร์มี 8 คอร์)
การรวบรวม SQL/วินาทีคือ 25% ของคำขอแบบแบตช์/วินาที (ควรน้อยกว่า 10%)
การคอมไพล์ SQL ใหม่ต่อวินาทีคือ 15% ของคำขอแบบแบตช์ต่อวินาที

ขั้นตอนการแก้ปัญหา

ใช้ DMV เพื่อระบุแบบสอบถามที่ใช้ CPU สูงสุด
วิเคราะห์แผนการดำเนินการสำหรับแบบสอบถามที่ระบุ
ค้นพบการสแกนตารางหลายรายการบนตารางขนาดใหญ่เนื่องจากดัชนีที่ขาดหายไป
สร้างดัชนีที่เหมาะสมตามคำแนะนำแผนการดำเนินการ
ระบุ SQL แบบไดนามิกที่ทำให้เกิดการคอมไพล์มากเกินไป
แก้ไขโค้ดแอปพลิเคชันเพื่อใช้แบบสอบถามแบบพารามิเตอร์
แนวทางการวางแผนที่นำไปปฏิบัติสำหรับกระบวนการจัดเก็บที่มีปัญหา
สถิติที่อัปเดตบนตารางที่ใช้งานหนัก

ผลลัพธ์: อัตราการใช้งาน CPU ลดลงเหลือ 45% โดยเฉลี่ยในช่วงเวลาทำการ เวลาในการดำเนินการค้นหาดีขึ้น 70% การตอบสนองของแอปพลิเคชันดีขึ้นอย่างมาก

14.3 กรณีศึกษา: การแก้ไขปัญหาคอขวดของดิสก์ I/O

การระบุอาการ

ผู้ใช้รายงานว่าการตอบสนองของแอปพลิเคชันช้ามากในระหว่างการดำเนินการโหลดข้อมูลและการประมวลผลแบบแบตช์ในตอนเย็น

การวิเคราะห์ตอบโต้

ข้อมูลประสิทธิภาพแสดงให้เห็นว่า:

ค่าเฉลี่ยของวินาทีดิสก์/การเขียนเกิน 45 มิลลิวินาทีบนไดรฟ์บันทึกธุรกรรม
ความยาวคิวดิสก์เฉลี่ย 12 บนไดรฟ์ไฟล์ข้อมูล
% เวลาดิสก์อยู่เหนือ 95% เป็นเวลาหลายชั่วโมงระหว่างงานแบตช์
การเขียนหน้าต่อวินาทีสูงเป็นพิเศษ

ขั้นตอนการแก้ปัญหา

ตรวจสอบการตั้งค่าหน่วยความจำแล้วพบว่าเหมาะสม – ไม่พบปัญหาหน่วยความจำ
วิเคราะห์การกำหนดค่าดิสก์ – ค้นพบไฟล์ทั้งหมดบนชุดสปินเดิลเดียวกัน
บันทึกธุรกรรมแยกไปยังไดรฟ์ SSD ความเร็วสูงเฉพาะ
ย้าย tempdb ไปยังไดรฟ์ SSD ที่แยกจากกัน
นำไฟล์ข้อมูล tempdb หลายไฟล์มาใช้งาน (หนึ่งไฟล์ต่อหนึ่งคอร์)
อัพเกรดไดรฟ์ไฟล์ข้อมูลเป็นการกำหนดค่า RAID 10 SSD
งานแบตช์ที่ได้รับการปรับให้เหมาะสมเพื่อใช้แบตช์ธุรกรรมขนาดเล็ก
เพิ่มดัชนีเพื่อลดการสแกนตารางที่ไม่จำเป็นระหว่างการดำเนินการแบบแบตช์

ผลลัพธ์: ค่าเฉลี่ยของวินาทีดิสก์/การเขียนลดลงเหลือ 3 มิลลิวินาที ความยาวคิวดิสก์เฉลี่ยต่ำกว่า 1 เวลาในการเสร็จสิ้นงานแบตช์ลดลง 75%

15. แนวโน้มในอนาคต SQL Server การตรวจสอบ

15.1 การบูรณาการ AI และการเรียนรู้ของเครื่องจักร

ปัญญาประดิษฐ์และการเรียนรู้ของเครื่องจักรกำลังเปลี่ยนแปลง SQL Server การตรวจสอบประสิทธิภาพการทำงาน

การวิเคราะห์เชิงทำนาย

แบบจำลองการเรียนรู้ของเครื่องจะคาดการณ์ความต้องการทรัพยากรในอนาคตโดยอ้างอิงจากข้อมูลในอดีต ระบบเหล่านี้สามารถคาดการณ์สิ่งต่อไปนี้ได้:

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

การตรวจจับความผิดปกติ

เครื่องมือที่ขับเคลื่อนด้วย AI จะตรวจจับรูปแบบที่ผิดปกติในตัวชี้วัดประสิทธิภาพโดยอัตโนมัติ เครื่องมือเหล่านี้จะระบุความผิดปกติที่ผู้ดูแลระบบอาจมองข้าม และแยกแยะความแตกต่างระหว่างความแปรปรวนปกติกับปัญหาที่แท้จริง

การแก้ไขอัตโนมัติ

ระบบการรักษาตัวเองจะแก้ไขปัญหาทั่วไปโดยอัตโนมัติเมื่อตรวจพบ:

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

15.2 วิวัฒนาการของการตรวจสอบบนคลาวด์

การตรวจสอบระบบคลาวด์ยังคงพัฒนาไปพร้อมกับความสามารถใหม่ๆ

แพลตฟอร์มการตรวจสอบแบบรวม

แพลตฟอร์มที่ทันสมัยให้การมองเห็นแบบกระจกบานเดียวทั่วทั้ง:

ในสถานที่ SQL Server อินสแตนซ์
ฐานข้อมูลที่โฮสต์บนคลาวด์
สภาพแวดล้อมแบบไฮบริด
แอพพลิเคชั่น
เมตริกโครงสร้างพื้นฐาน

แนวโน้มการสังเกต

การเปลี่ยนแปลงจากการติดตามไปสู่การสังเกตเน้นย้ำถึง:

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

15.3 ระบบฐานข้อมูลการรักษาตนเอง

อนาคต SQL Server เวอร์ชันต่างๆ จะรวมความสามารถอัตโนมัติมากขึ้น

การเพิ่มประสิทธิภาพอัตโนมัติ

ฐานข้อมูลจะเพิ่มประสิทธิภาพตัวเองอย่างต่อเนื่องโดย:

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

การปรับแต่งอัจฉริยะ

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

16. บทสรุปและประเด็นสำคัญ

16.1 สรุปแนวทางปฏิบัติในการติดตามที่สำคัญ

มีประสิทธิภาพ SQL Server การตรวจสอบประสิทธิภาพการทำงานต้องใช้วิธีการที่ครอบคลุมโดยผสมผสานเครื่องมือ เทคนิค และแนวทางปฏิบัติที่ดีที่สุด

สรุปการตอบโต้ที่สำคัญ

มุ่งเน้นความพยายามในการติดตามตัวนับที่สำคัญเหล่านี้:

หน่วยความจำ: อายุการใช้งานของเพจ, อัตราการเข้าใช้แคชบัฟเฟอร์, การอนุญาตหน่วยความจำที่รอดำเนินการ
CPU: % เวลาของโปรเซสเซอร์, ความยาวคิวของโปรเซสเซอร์
ดิสก์: ค่าเฉลี่ยของวินาทีดิสก์/การอ่านและการเขียน, ความยาวคิวดิสก์
SQL Server: คำขอแบบกลุ่ม/วินาที, การรวบรวม/วินาที, การเชื่อมต่อผู้ใช้

สรุปแนวทางปฏิบัติที่ดีที่สุด

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

16.2 แนวทางการปรับปรุงอย่างต่อเนื่อง

SQL Server การตรวจสอบประสิทธิภาพไม่ใช่กิจกรรมเพียงครั้งเดียว แต่เป็นกระบวนการต่อเนื่องที่ต้องมีการปรับปรุงอย่างต่อเนื่อง

รอบการตรวจสอบปกติ

รายวัน: ตรวจสอบการแจ้งเตือนและประสิทธิภาพปัจจุบัน
รายสัปดาห์: ทบทวนแนวโน้มและระบุปัญหาที่เกิดขึ้น
รายเดือน: วิเคราะห์รูปแบบระยะยาวและความต้องการกำลังการผลิต
รายไตรมาส: อัปเดตข้อมูลพื้นฐานและตรวจสอบประสิทธิภาพการติดตาม

การติดตามเครื่องมือที่ทันสมัย

อัปเดตเครื่องมือและเทคนิคการตรวจสอบให้ทันสมัยอยู่เสมอ:

ประเมินคุณสมบัติการตรวจสอบใหม่ใน SQL Server การปรับปรุง
ทดสอบเครื่องมือของบุคคลที่สามที่กำลังเกิดขึ้น
เข้าร่วมการฝึกอบรมและการประชุม
มีส่วนร่วมใน SQL Server ฟอรัมชุมชน
แบ่งปันความรู้กับสมาชิกในทีม

16.3 ขั้นตอนถัดไป

Implement SQL Server ตรวจสอบประสิทธิภาพการทำงานอย่างเป็นระบบ:

แผนงานการดำเนินงาน

สัปดาห์ที่ 1: ตั้งค่า Performance Monitor พร้อมตัวนับที่จำเป็น
สัปดาห์ที่ 2: สร้างชุดตัวรวบรวมข้อมูลสำหรับการรวบรวมข้อมูลอัตโนมัติ
สัปดาห์ที่ 3: สร้างมาตรฐานพื้นฐานระหว่างการดำเนินงานปกติ
สัปดาห์ที่ 4: กำหนดค่าการแจ้งเตือนสำหรับเกณฑ์ที่สำคัญ
เดือน 2: นำเครื่องมือตรวจสอบเพิ่มเติมมาใช้ (DMV, เหตุการณ์ขยาย)
เดือน 3: พัฒนาแดชบอร์ดและรายงานที่กำหนดเอง
ต่อเนื่อง: ปรับปรุงการตรวจสอบตามประสบการณ์และความต้องการที่เปลี่ยนแปลง

แหล่งข้อมูลเพิ่มเติม

ศึกษาต่อเกี่ยวกับ SQL Server ตรวจสอบประสิทธิภาพการทำงานผ่านเอกสารของ Microsoft บล็อกชุมชน และการฝึกปฏิบัติจริง ทดลองใช้เครื่องมือและเทคนิคต่างๆ เพื่อค้นหาวิธีที่เหมาะสมที่สุดกับสภาพแวดล้อมของคุณ

17. คำถามที่พบบ่อย (FAQ)

17.1 สิ่งที่สำคัญที่สุดคืออะไร SQL Server ตัวนับประสิทธิภาพที่ต้องตรวจสอบ?

สิ่งที่สำคัญที่สุด SQL Server ตัวนับประสิทธิภาพประกอบด้วย:

หน่วยความจำ: อายุการใช้งานของเพจ (ควร >300 วินาที) และอัตราการเข้าชมแคชบัฟเฟอร์ (ควร >99%)
CPU: % เวลาของโปรเซสเซอร์ (ค่าคงที่ <75%) และความยาวคิวของโปรเซสเซอร์ (ควร <2 ต่อคอร์)
ดิสก์: ค่าเฉลี่ยของวินาทีดิสก์/การอ่านและการเขียน (ควร <10-20ms) และความยาวคิวดิสก์ (ควร <2 ต่อดิสก์)
SQL Server: คำขอแบบแบตช์/วินาที การรวบรวม SQL/วินาที และการอนุญาตหน่วยความจำที่รอดำเนินการ (ควรเป็น 0)

ตัวนับเหล่านี้ให้ข้อมูลเชิงลึกที่ครอบคลุมเกี่ยวกับสุขภาพของระบบและช่วยระบุคอขวดได้อย่างรวดเร็ว

17.2 ฉันควรรวบรวมข้อมูลประสิทธิภาพการทำงานบ่อยเพียงใด

ความถี่ในการรวบรวมขึ้นอยู่กับวัตถุประสงค์การตรวจสอบของคุณ:

การตรวจสอบพื้นฐาน: ทุก ๆ 1 นาที (60 วินาที)
การแก้ไขปัญหาเชิงรุก: ทุก ๆ 15-30 วินาทีเป็นระยะเวลาสั้น ๆ
แนวโน้มระยะยาว: ทุก ๆ 5 นาที

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

17.3 ความแตกต่างระหว่าง Performance Monitor และ SQL Server โปรไฟเลอร์?

การตรวจสอบประสิทธิภาพและ SQL Server โปรไฟเลอร์มีวัตถุประสงค์การใช้งานที่แตกต่างกัน:

การตรวจสอบประสิทธิภาพ:

ระบบมอนิเตอร์และ SQL Server ตัวนับประสิทธิภาพ
ติดตามการใช้ทรัพยากร (CPU, หน่วยความจำ, ดิสก์)
ค่าใช้จ่ายต่ำ เหมาะสำหรับการตรวจสอบอย่างต่อเนื่อง
ให้เมตริกรวมตามระยะเวลา

SQL Server โปรไฟล์:

ร่องรอยของแต่ละบุคคล SQL Server กิจกรรมและการสอบถาม
จับข้อมูลการดำเนินการสอบถามโดยละเอียด
ค่าใช้จ่ายสูง ไม่แนะนำให้ใช้ต่อเนื่อง
ดีที่สุดสำหรับการแก้ไขปัญหาเฉพาะคำถาม
ไม่สนับสนุนอีกต่อไป เพื่อสนับสนุนกิจกรรมที่ขยายออกไป

ใช้ Performance Monitor สำหรับการตรวจสอบระบบโดยรวม และใช้ Extended Events (ไม่ใช่ Profiler) เพื่อวิเคราะห์ระดับแบบสอบถามโดยละเอียด

17.4 การตรวจสอบประสิทธิภาพสามารถส่งผลกระทบ SQL Server ประสิทธิภาพ?

เมื่อกำหนดค่าอย่างถูกต้อง Performance Monitor จะมีผลกระทบต่อน้อยที่สุด SQL Server ประสิทธิภาพการทำงาน โดยทั่วไปจะมีค่าใช้จ่ายไม่เกิน 2% อย่างไรก็ตาม การตรวจสอบที่มากเกินไปอาจทำให้เกิดปัญหาได้:

เคาน์เตอร์มากเกินไปทำให้ค่าใช้จ่ายเพิ่มขึ้น
ช่วงตัวอย่างสั้นมาก (น้อยกว่า 15 วินาที) ทำให้เกิดความเครียดต่อทรัพยากร
การรวบรวมความถี่สูงอย่างต่อเนื่องจะสร้างไฟล์บันทึกขนาดใหญ่

เพื่อลดผลกระทบ:

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

17.5 ฉันควรเก็บข้อมูลการติดตามประสิทธิภาพไว้นานแค่ไหน?

การคงอยู่ขึ้นอยู่กับความต้องการการวิเคราะห์และความจุในการจัดเก็บของคุณ:

จำนวนขั้นต่ำ: 3 เดือนสำหรับการแก้ไขปัญหาล่าสุด
ที่แนะนำ: 1-2 ปีสำหรับการวางแผนกำลังการผลิตและการวิเคราะห์แนวโน้ม
เหมาะสมที่สุด: ไม่มีกำหนดเวลาหากพื้นที่เก็บข้อมูลอนุญาต เนื่องจากข้อมูลในอดีตจะมีค่ามากขึ้นตามกาลเวลา

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

17.6 ค่าเกณฑ์ที่ดีสำหรับตัวนับประสิทธิภาพหลักคืออะไร

ค่าเกณฑ์ที่แนะนำสำหรับการแจ้งเตือน:

การมอบหน่วยความจำรอดำเนินการ: แจ้งเตือนเมื่อ > 0
อายุการใช้งานหน้า: แจ้งเตือนเมื่อ < 300 วินาที
% เวลาประมวลผล: แจ้งเตือนเมื่อ > 80% เป็นเวลา 5 นาที
ความยาวคิวโปรเซสเซอร์: แจ้งเตือนเมื่อ > 2 ต่อคอร์
ค่าเฉลี่ยวินาทีของดิสก์/อ่านหรือเขียน: แจ้งเตือนเมื่อ > 20ms
ความยาวคิวดิสก์: แจ้งเตือนเมื่อ > 2 ต่อดิสก์
กระบวนการที่ถูกบล็อค: แจ้งเตือนเมื่อ > 5

ปรับเกณฑ์เหล่านี้ตามข้อมูลพื้นฐานและลักษณะเฉพาะของปริมาณงาน สิ่งที่ปกติสำหรับสภาพแวดล้อมหนึ่งอาจบ่งชี้ถึงปัญหาในอีกสภาพแวดล้อมหนึ่ง

17.7 ฉันจะตรวจสอบได้อย่างไร SQL Server การแสดงจากระยะไกล?

มอนิเตอร์ระยะไกล SQL Server ตัวอย่างการใช้วิธีการเหล่านี้:

การตรวจสอบประสิทธิภาพ: ระบุชื่อคอมพิวเตอร์ระยะไกลเมื่อเพิ่มตัวนับ
พาวเวอร์เชลล์: ใช้พารามิเตอร์ -ComputerName กับ Get-Counter
DMV: เชื่อมต่อกับเซิร์ฟเวอร์ระยะไกลผ่าน SSMS และสอบถาม DMV
เครื่องมือของบุคคลที่สาม: เครื่องมือตรวจสอบส่วนใหญ่รองรับการตรวจสอบเซิร์ฟเวอร์จากระยะไกล

ตรวจสอบให้แน่ใจว่ากฎไฟร์วอลล์อนุญาตให้มีการรับส่งข้อมูลของ Performance Monitor และคุณมีสิทธิ์ที่เหมาะสมบนเซิร์ฟเวอร์ระยะไกล สำหรับเซิร์ฟเวอร์หลายเครื่อง ให้พิจารณาใช้การตรวจสอบแบบรวมศูนย์ด้วยเซิร์ฟเวอร์ตรวจสอบและฐานข้อมูลเฉพาะ

17.8 เครื่องมือฟรีที่ดีที่สุดสำหรับคืออะไร SQL Server ตัวตรวจสอบประสิทธิภาพ?

มีเครื่องมือฟรีที่ยอดเยี่ยมมากมายสำหรับการตรวจสอบ SQL Server ประสิทธิภาพ:

ตัวตรวจสอบประสิทธิภาพของ Windows: ในตัว ครอบคลุม และเชื่อถือได้
เครื่องตรวจสอบกิจกรรม SSMS: การตรวจสอบแบบเรียลไทม์โดยไม่ต้องติดตั้งเพิ่มเติม
กิจกรรมขยายเวลา: การตรวจสอบเหตุการณ์น้ำหนักเบาในตัว SQL Server
sp_WhoIsActive: ขั้นตอนการจัดเก็บฟรียอดนิยมสำหรับการติดตามกิจกรรมโดยละเอียด
ดีบีเอ แดช: เครื่องมือตรวจสอบโอเพ่นซอร์สพร้อมฟีเจอร์ที่ครอบคลุม
SQLWATCH: โอเพ่นซอร์สพร้อมความสามารถในการตรวจสอบแบบเกือบเรียลไทม์

สำหรับองค์กรส่วนใหญ่ Performance Monitor เมื่อใช้งานร่วมกับเครื่องมือ SSMS และ sp_WhoIsActive จะให้ความสามารถในการตรวจสอบที่ยอดเยี่ยมโดยไม่มีค่าใช้จ่ายเพิ่มเติม

17.9 ฉันจะส่งออกข้อมูล PerfMon เพื่อวิเคราะห์ได้อย่างไร

ส่งออกข้อมูลการตรวจสอบประสิทธิภาพโดยใช้วิธีการเหล่านี้:

ส่งออกเป็น CSV:

เปิด Performance Monitor โดยโหลดไฟล์บันทึกของคุณ
คลิกขวาที่กราฟและเลือก บันทึกข้อมูลเป็น
Choose ไฟล์ข้อความ (คั่นด้วยจุลภาค) (.csv)
เลือกตำแหน่งและบันทึก
เปิดใน Excel เพื่อการวิเคราะห์

ใช้คำสั่ง Relog:

relog input.blg -f csv -o output.csv

ยูทิลิตี้บรรทัดคำสั่งนี้จะแปลงไฟล์บันทึกไบนารี (.blg) เป็นรูปแบบ CSV เพื่อการวิเคราะห์ที่ง่ายขึ้นในแอปพลิเคชันสเปรดชีต

17.10 ฉันควรใช้เครื่องมือตรวจสอบของบุคคลที่สามแทนตัวเลือกในตัวเมื่อใด

พิจารณาเครื่องมือของบุคคลที่สามเมื่อ:

การจัดการจำนวนมาก SQL Server อินสแตนซ์ (10+)
ต้องมีการตรวจสอบแบบรวมศูนย์ในศูนย์ข้อมูลหลายแห่ง
ต้องการฟีเจอร์ขั้นสูง เช่น การวิเคราะห์เชิงคาดการณ์หรือการตรวจจับความผิดปกติ
ต้องการการแจ้งเตือนแบบบูรณาการกับระบบการจัดการเหตุการณ์
กำหนดให้ต้องมีการรายงานการปฏิบัติตามและการวิเคราะห์ประวัติ
ขาดทรัพยากร DBA เพื่อสร้างและบำรุงรักษาโซลูชันที่กำหนดเอง
การตรวจสอบสภาพแวดล้อมฐานข้อมูลที่หลากหลาย (SQL Server(เช่น Oracle, MySQL เป็นต้น)

เครื่องมือในตัวทำงานได้ดีกับสภาพแวดล้อมขนาดเล็ก หรือเมื่อคุณมีผู้ดูแลฐานข้อมูล (DBA) ผู้เชี่ยวชาญที่สามารถพัฒนาโซลูชันการตรวจสอบแบบกำหนดเองได้ เครื่องมือจากภายนอกมอบคุณค่าด้วยการประหยัดเวลา ฟีเจอร์ขั้นสูง และการสนับสนุนจากผู้เชี่ยวชาญ

18. แหล่งข้อมูลเพิ่มเติม

18.1 เอกสารอย่างเป็นทางการ

Microsoft มีเอกสารประกอบมากมายสำหรับ SQL Server การตรวจสอบประสิทธิภาพ:

SQL Server เอกสารประกอบการตรวจสอบประสิทธิภาพ: https://learn.microsoft.com/en-us/sql/relational-databases/performance-monitor/
มุมมองการจัดการแบบไดนามิก: https://learn.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/
กิจกรรมขยายเวลา: https://learn.microsoft.com/en-us/sql/relational-databases/extended-events/
ร้านค้าสอบถาม: https://learn.microsoft.com/en-us/sql/relational-databases/performance/monitoring-performance-by-using-the-query-store
การปรับแต่งและการตรวจสอบประสิทธิภาพ: https://learn.microsoft.com/en-us/sql/relational-databases/performance/

18.2 เครื่องมือและการดาวน์โหลดที่แนะนำ

เครื่องมือสำคัญสำหรับ SQL Server การตรวจสอบประสิทธิภาพ:

เครื่องมือ PAL: https://github.com/clinthuffman/PAL
sp_WhoIsActive: http://whoisactive.com/
ดีบีเอ แดช: https://dbadash.com/
SQLWATCH: https://github.com/marcingminski/sqlwatch
ชุดอุปกรณ์ช่วยเหลือฉุกเฉิน (เบรนท์ โอซาร์): https://www.brentozar.com/first-aid/
SQL Server สตูดิโอการจัดการ: https://learn.microsoft.com/en-us/sql/ssms/download-sql-server-management-studio-ssms

18.3 ทรัพยากรชุมชน

เรียนรู้จากไฟล์ SQL Server ชุมชน:

SQL Server ศูนย์กลาง: https://www.sqlservercentral.com/
บล็อกของเบรนท์ โอซาร์: https://www.brentozar.com/blog/
SQL แช็ค: https://www.sqlshack.com/
เคล็ดลับ MSSQL: https://www.mssqltips.com/
เรดดิต r/SQLServer: https://www.reddit.com/r/SQLServer/
กองมากเกิน SQL Server แท็ก: https://stackoverflow.com/questions/tagged/sql-server

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

เกี่ยวกับผู้เขียน

หยวน เซิง เป็นผู้ดูแลฐานข้อมูลอาวุโส (DBA) ที่มีประสบการณ์มากกว่า 10 ปีใน SQL Server สภาพแวดล้อมและการจัดการฐานข้อมูลองค์กร เขาประสบความสำเร็จในการแก้ไขปัญหาการกู้คืนฐานข้อมูลหลายร้อยกรณีในองค์กรด้านบริการทางการเงิน การดูแลสุขภาพ และการผลิต

หยวนมีความเชี่ยวชาญด้าน SQL Server การกู้คืนฐานข้อมูล โซลูชันที่มีความพร้อมใช้งานสูงรวมถึงการเพิ่มประสิทธิภาพการทำงาน ประสบการณ์ภาคปฏิบัติที่กว้างขวางของเขารวมถึงการจัดการฐานข้อมูลขนาดหลายเทราไบต์ การนำไปใช้ เสมอในกลุ่มความพร้อมใช้งานและพัฒนาแผนกลยุทธ์การสำรองข้อมูลและกู้คืนข้อมูลอัตโนมัติสำหรับระบบธุรกิจที่มีความสำคัญอย่างยิ่ง

ด้วยความเชี่ยวชาญทางเทคนิคและแนวทางปฏิบัติ Yuan มุ่งเน้นที่การสร้างคู่มือที่ครอบคลุมซึ่งจะช่วยให้ผู้ดูแลระบบฐานข้อมูลและผู้เชี่ยวชาญด้านไอทีแก้ไขปัญหาที่ซับซ้อน SQL Server ท้าทายอย่างมีประสิทธิภาพ เขาคอยติดตามข่าวสารล่าสุดอยู่เสมอ SQL Server การเปิดตัวและเทคโนโลยีฐานข้อมูลที่พัฒนาอย่างต่อเนื่องของ Microsoft ทดสอบสถานการณ์การกู้คืนเป็นประจำเพื่อให้แน่ใจว่าคำแนะนำของเขาสะท้อนถึงแนวทางปฏิบัติที่ดีที่สุดในโลกแห่งความเป็นจริง

มีคำถามเกี่ยวกับ SQL Server การกู้คืนหรือต้องการคำแนะนำในการแก้ไขปัญหาฐานข้อมูลเพิ่มเติมหรือไม่? หยวนยินดีต้อนรับ ข้อเสนอแนะและข้อเสนอแนะ เพื่อปรับปรุงทรัพยากรทางเทคนิคเหล่านี้