1. บทนำ
1.1 คืออะไร SQL Server กิจกรรมการตรวจสอบ?
SQL Server Activity Monitor เป็นอุปกรณ์วินิจฉัยในตัวostเครื่องมือไอซีภายใน SQL Server Management Studio ที่แสดงข้อมูลเกี่ยวกับ SQL Server กระบวนการและผลกระทบต่อประสิทธิภาพของเซิร์ฟเวอร์ ช่วยให้คุณติดตาม SQL Server กระบวนการ ตรวจสอบการรอทรัพยากร วิเคราะห์แบบสอบถามที่มีค่าใช้จ่ายสูง และสังเกตรูปแบบ I/O ทั้งหมดนี้จากอินเทอร์เฟซเดียว
1.2 เหตุใดจึงใช้ SQL Server กิจกรรมการตรวจสอบ?
Activity Monitor ทำหน้าที่เป็นแนวป้องกันด่านแรกของคุณเมื่อแก้ไขปัญหาด้านประสิทธิภาพ ช่วยให้คุณมองเห็นสิ่งที่เกิดขึ้นบน SQL Server โดยไม่ต้องใช้แบบสอบถาม T-SQL ที่ซับซ้อนหรือเครื่องมือของบริษัทอื่น
เครื่องมือนี้ช่วยให้คุณระบุปัญหาทั่วไปได้อย่างรวดเร็ว เช่น เซสชันที่ถูกบล็อก คิวรีที่ใช้ CPU หนัก การดำเนินการคิวรีที่มากเกินไป และปัญหาคอขวด I/O เมื่อผู้ใช้รายงานว่าแอปพลิเคชันทำงานช้าหรือไม่ตอบสนอง Activity Monitor จะช่วยคุณตรวจสอบว่าเซิร์ฟเวอร์ฐานข้อมูลเป็นสาเหตุหรือไม่
สำหรับผู้ดูแลระบบฐานข้อมูลที่ไม่ได้ทำงานกับ SQL Server Activity Monitor นำเสนอจุดเข้าถึงที่เข้าถึงได้สำหรับทำความเข้าใจกิจกรรมของเซิร์ฟเวอร์ทุกวัน แม้แต่ DBA ที่มีประสบการณ์ก็ใช้สิ่งนี้เป็น...tarจุดสำคัญสำหรับการตรวจสอบประสิทธิภาพการทำงาน
1.3 เครื่องมือตรวจสอบกิจกรรมเทียบกับเครื่องมือตรวจสอบอื่น ๆ
แม้ว่า Activity Monitor จะมีคุณค่า แต่สิ่งสำคัญคือต้องเข้าใจว่า Activity Monitor เปรียบเทียบกับตัวเลือกการตรวจสอบอื่น ๆ ได้อย่างไร:
Activity Monitor เทียบกับ sp_WhoIsActive: Activity Monitor มอบอินเทอร์เฟซแบบกราฟิกที่มีบานหน้าต่างหลายบาน ในขณะที่ sp_WhoIsActive เป็นกระบวนการจัดเก็บที่ครอบคลุมซึ่งให้ข้อมูลที่ละเอียดมากขึ้นในชุดผลลัพธ์เดียว sp_WhoIsActive แสดงประเภทการรอที่เฉพาะเจาะจงซึ่ง Activity Monitor จัดกลุ่มเข้าด้วยกันและให้ข้อมูลการบล็อกที่ละเอียดยิ่งขึ้น
Activity Monitor เทียบกับ sp_who2: คำสั่ง sp_who2 แบบดั้งเดิมจะแสดงข้อมูลเซสชันพื้นฐาน แต่ Activity Monitor ไปไกลกว่านั้นด้วยการแสดงสถิติการรอ แบบสอบถามราคาแพง และเมตริก I/O ในรูปแบบภาพที่เป็นระเบียบ
ตัวตรวจสอบกิจกรรมเทียบกับเครื่องมือของบุคคลที่สาม: โซลูชันการตรวจสอบเชิงพาณิชย์อย่าง SolarWinds Database Performance Analyzer นำเสนอการติดตามประวัติ การแจ้งเตือน และการวิเคราะห์ขั้นสูงที่ Activity Monitor ไม่มี อย่างไรก็ตาม Activity Monitor ไม่จำเป็นต้องมี c เพิ่มเติมost หรือการติดตั้ง
1.4 ประโยชน์หลักสำหรับผู้ดูแลระบบฐานข้อมูล
Activity Monitor มีข้อดีหลายประการที่ทำให้เป็นเครื่องมือ DBA ที่จำเป็น:
- ซีโร่ ซีost: เป็นแบบบิวท์อิน SQL Server ฟีเจอร์ Management Studio ไม่จำเป็นต้องเสียค่าธรรมเนียมใบอนุญาตหรือความพยายามในการปรับใช้
- การติดตามแบบเรียลไทม์: ดูกิจกรรมเซิร์ฟเวอร์ปัจจุบันที่เกิดขึ้น พร้อมช่วงเวลาการรีเฟรชที่สามารถกำหนดค่าได้ตั้งแต่ 1 วินาทีถึง 1 ชั่วโมง
- การดำเนินการแบบบูรณาการ: คลิกขวาที่กระบวนการเพื่อหยุดเซสชัน ดูรายละเอียดแบบสอบถาม หรือเปิดใช้งาน SQL Server การติดตามโปรไฟล์ทั้งหมดจากภายในเครื่องมือ
- หลายมุมมอง: ดูสุขภาพของเซิร์ฟเวอร์จากมุมต่างๆ ผ่านบานหน้าต่างเฉพาะ 5 บาน โดยแต่ละบานจะเน้นที่ด้านประสิทธิภาพเฉพาะ
- การแก้ไขปัญหาด่วน: ระบุม.ost ปัญหาประสิทธิภาพทั่วไปที่เกิดขึ้นภายในไม่กี่นาที ช่วยเร่งเวลาเฉลี่ยในการแก้ไขปัญหาของคุณ
- สิ่งกีดขวางต่ำในการเข้า: ไม่จำเป็นต้องมีความรู้ขั้นสูงเพื่อเริ่มใช้เครื่องมืออย่างมีประสิทธิภาพ แม้ว่าจะลึกซึ้งกว่าก็ตาม SQL Server ความเชี่ยวชาญช่วยในการตีความ
2. การได้รับ Started กับ Activity Monitor
ก่อนที่คุณจะสามารถใช้ประโยชน์จาก Activity Monitor ได้อย่างมีประสิทธิภาพ คุณต้องเข้าใจข้อกำหนดเบื้องต้น การอนุญาตที่จำเป็น และวิธีการต่างๆ ในการเปิดใช้งานเครื่องมือ
2.1 ข้อกำหนดเบื้องต้นและข้อกำหนดของระบบ
ในการใช้งาน SQL Server เครื่องตรวจสอบกิจกรรมที่คุณต้องการ SQL Server Management Studio (SSMS) ติดตั้งบนเครื่องของคุณหรือเซิร์ฟเวอร์จัมพ์ เครื่องมือ Activity Monitor ได้รับการออกแบบใหม่อย่างมีนัยสำคัญใน SQL Server 2008 ดังนั้นข้อมูลในคู่มือนี้จึงใช้ได้กับ SQL Server 2008 และรุ่นที่ใหม่กว่า
คุณต้องมีการเชื่อมต่อเครือข่ายกับ SQL Server อินสแตนซ์ที่คุณต้องการตรวจสอบ สำหรับ cloud-hostหากใช้ฐานข้อมูล ed โดยทั่วไปคุณจะต้องมีการเชื่อมต่อ VPN หรือกำหนดค่ากฎไฟร์วอลล์อย่างถูกต้องเพื่อเข้าถึงอินสแตนซ์
Activity Monitor ใช้งานได้กับทุกเวอร์ชัน SQL Serverรวมถึง Express, Standard และ Enterprise เครื่องมือนี้ทำงานบนเครื่องไคลเอนต์ของคุณภายใน SSMS ดังนั้นทรัพยากรของเซิร์ฟเวอร์จะได้รับผลกระทบจากคำสั่งตรวจสอบที่ดำเนินการเท่านั้น
2.2 การอนุญาตที่จำเป็น
การอนุญาตที่ถูกต้องเป็นสิ่งจำเป็นเพื่อให้ Activity Monitor ทำงานได้อย่างถูกต้อง หากไม่มีสิทธิ์ที่ถูกต้อง คุณอาจเห็นหน้าจอว่างเปล่าหรือได้รับข้อผิดพลาดการเข้าถึงถูกปฏิเสธ
2.2.1 การอนุญาตดูสถานะเซิร์ฟเวอร์
การขอ ดูสถานะเซิร์ฟเวอร์ การอนุญาตเป็นข้อกำหนดหลักสำหรับการใช้ Activity Monitor การอนุญาตระดับเซิร์ฟเวอร์นี้ช่วยให้คุณเห็นกระบวนการทั้งหมดที่ใช้งานอยู่และเมตริกที่เกี่ยวข้อง
ในการให้สิทธิ์นี้ ผู้ดูแลระบบเซิร์ฟเวอร์สามารถดำเนินการดังต่อไปนี้:
GRANT VIEW SERVER STATE TO [YourLoginName];
หากไม่มี VIEW SERVER STATE Activity Monitor จะเปิดขึ้นแต่จะไม่แสดงข้อมูลใดๆ ในบานหน้าต่างใดๆ
2.2.2 การอนุญาตระดับฐานข้อมูล
หากต้องการดูข้อมูลในบานหน้าต่าง Data File I/O คุณต้องมีสิทธิ์เพิ่มเติม โดยเฉพาะอย่างยิ่ง คุณต้องมีสิทธิ์อย่างใดอย่างหนึ่งต่อไปนี้:
- สร้างฐานข้อมูล การอนุญาต หรือ
- เปลี่ยนแปลงฐานข้อมูลใดๆ การอนุญาต หรือ
- ดูคำจำกัดความใด ๆ การอนุญาต
การอนุญาตเหล่านี้จะต้องรวมกับ ดูสถานะเซิร์ฟเวอร์ เพื่อฟังก์ชันการทำงานของ Activity Monitor อย่างครบถ้วน
2.2.3 การแก้ไขปัญหาการอนุญาต
หาก Activity Monitor เปิดขึ้นแต่ไม่แสดงข้อมูล แสดงว่าการอนุญาตเป็น most สาเหตุทั่วไป ตรวจสอบว่าการเข้าสู่ระบบของคุณได้รับสิทธิ์ VIEW SERVER STATE ที่ระดับเซิร์ฟเวอร์ คุณสามารถตรวจสอบสิทธิ์ของคุณได้โดยเรียกใช้:
SELECT * FROM fn_my_permissions(NULL, 'SERVER');
ค้นหา 'VIEW SERVER STATE' ในคอลัมน์ permission_name หากไม่มี โปรดติดต่อผู้ดูแลระบบฐานข้อมูลของคุณเพื่อขออนุญาต
2.3 วิธีการเปิด Activity Monitor ใน SSMS
SQL Server Management Studio มีวิธีการที่แตกต่างกันสี่วิธีในการเปิดตัว Activity Monitor ช่วยให้คุณมีความยืดหยุ่นขึ้นอยู่กับการตั้งค่าเวิร์กโฟลว์ของคุณ
2.3.1 วิธีที่ 1: จากแถบเครื่องมือ
วิธีที่เร็วที่สุดในการเปิด Activity Monitor คือการใช้ไอคอนแถบเครื่องมือ:
- เชื่อมต่อกับของคุณ SQL Server ตัวอย่างใน SQL Server สตูดิโอการจัดการ
- ค้นหาไอคอน Activity Monitor ในแถบเครื่องมือมาตรฐาน (จะมีลักษณะเป็นแผนภูมิแท่งที่มีปุ่มเล่นสีเขียว)
- คลิกไอคอนเพื่อเปิดตัว Activity Monitor
วิธีนี้เร็วที่สุดเมื่อคุณกำลังทำงานใน SSMS อยู่แล้วและจำเป็นต้องตรวจสอบกิจกรรมของเซิร์ฟเวอร์อย่างรวดเร็ว
2.3.2 วิธีที่ 2: จาก Object Explorer
คุณสามารถเปิด Activity Monitor ได้โดยตรงจาก Object Explorer:
- ใน Object Explorer ให้ค้นหา SQL Server อินสแตนซ์ที่คุณต้องการตรวจสอบ
- คลิกขวาที่ชื่ออินสแตนซ์
- เลือก กิจกรรมการตรวจสอบ จากเมนูบริบท
วิธีนี้มีประโยชน์เมื่อทำการเชื่อมต่อกับเซิร์ฟเวอร์หลายเครื่อง เนื่องจากวิธีนี้จะช่วยให้คุณตรวจสอบอินสแตนซ์ที่ถูกต้อง
2.3.3 วิธีที่ 3: การใช้แป้นพิมพ์ลัด
สำหรับผู้ใช้ที่เน้นการใช้คีย์บอร์ด SQL Server Management Studio มีทางลัดเฉพาะ:
- ตรวจสอบให้แน่ใจว่า SSMS เป็นหน้าต่างที่ใช้งานอยู่และคุณเชื่อมต่อกับอินสแตนซ์แล้ว
- ข่าวประชาสัมพันธ์ Ctrl + อื่น ๆ + A.
- Activity Monitor จะเปิดขึ้นสำหรับอินสแตนซ์ที่เลือกในปัจจุบันใน Object Explorer
โปรดทราบว่า Activity Monitor จะเชื่อมต่อกับอินสแตนซ์เซิร์ฟเวอร์ใดก็ตามที่คุณเลือกใน Object Explorer ดังนั้นโปรดตรวจสอบให้แน่ใจว่าคุณได้เลือกอินสแตนซ์ที่ถูกต้องก่อนใช้ทางลัดนี้
2.3.4 วิธีที่ 4: จากเมนูตัวเลือก (Starการกำหนดค่า tup)
หากคุณใช้ Activity Monitor บ่อยครั้ง คุณสามารถกำหนดค่า SSMS ให้เปิดใช้งานโดยอัตโนมัติเมื่อใดก็ตามที่คุณtarสำหรับการใช้งาน:
- In SQL Server สตูดิโอการจัดการ นำทางไปที่ เครื่องมือ -> ตัวเลือก.
- ในกล่องโต้ตอบตัวเลือก ให้ขยาย สภาพสิ่งแวดล้อมและจากนั้นเลือก Starหลอด.
- จาก ที่ starหลอด รายการแบบดรอปดาวน์ เลือก เปิดตัวสำรวจวัตถุและตัวตรวจสอบกิจกรรม.
- เลือก OK.
ครั้งต่อไปที่คุณเปิด SSMS และเชื่อมต่อกับเซิร์ฟเวอร์ Activity Monitor จะเปิดขึ้นโดยอัตโนมัติควบคู่ไปกับ Object Explorer
3. ทำความเข้าใจบานหน้าต่างการตรวจสอบกิจกรรม
Activity Monitor จัดระเบียบข้อมูลออกเป็น 5 บานหน้าต่างที่ขยายได้ แต่ละบานหน้าต่างให้มุมมองที่แตกต่างกันเกี่ยวกับกิจกรรมของเซิร์ฟเวอร์ การทำความเข้าใจว่าแต่ละบานหน้าต่างแสดงอะไรเป็นสิ่งสำคัญอย่างยิ่งต่อการแก้ไขปัญหาอย่างมีประสิทธิภาพ
3.1 แผงภาพรวม
แผงภาพรวมจะแสดงกราฟแบบเรียลไทม์สี่รายการที่ให้ภาพรวมสุขภาพของคุณอย่างรวดเร็ว SQL Server อินสแตนซ์ กราฟเหล่านี้จะอัปเดตตามช่วงเวลาที่กำหนดได้ และช่วยให้คุณระบุรูปแบบที่ผิดปกติได้ในทันที
3.1.1% เวลาประมวลผล
กราฟนี้แสดงเปอร์เซ็นต์ของเวลาที่โปรเซสเซอร์ใช้ในการรันเธรดที่ไม่ได้ใช้งานสำหรับ SQL Server อินสแตนซ์ใน CPU ทั้งหมด ค่านี้แสดงถึง SQL Serverการใช้ประโยชน์ของโปรเซสเซอร์ ไม่ใช่การใช้งาน CPU ของเซิร์ฟเวอร์ทั้งหมด
หากคุณเห็นเวลาประมวลผลอยู่ที่ 100% หรือใกล้เคียงอยู่เสมอ แสดงว่าเซิร์ฟเวอร์ของคุณถูกจำกัดด้วย CPU ซึ่งอาจบ่งชี้ถึงการสืบค้นที่ไม่มีประสิทธิภาพ ดัชนีที่หายไป หรือความจุฮาร์ดแวร์ไม่เพียงพอ ให้ใช้บานหน้าต่าง Recent Expensive Queries เพื่อระบุว่าการสืบค้นใดกำลังใช้ most ซีพียู
3.1.2 งานที่รออยู่
เมตริกนี้แสดงจำนวนงานที่กำลังรอการปล่อยทรัพยากรก่อนที่จะสามารถดำเนินการต่อได้ งานอาจรอ CPU, I/O, หน่วยความจำ หรือล็อก
จำนวนงานรอที่สูงอย่างต่อเนื่องบ่งชี้ถึงการแย่งชิงทรัพยากร บานหน้าต่าง "การรอทรัพยากร" จะให้รายละเอียดเพิ่มเติมเกี่ยวกับประเภทของทรัพยากรที่ทำให้เกิดการรอ
3.1.3 ฐานข้อมูล I/O (MB/s)
กราฟนี้แสดงอัตราการถ่ายโอนข้อมูลระหว่างหน่วยความจำและดิสก์ ซึ่งรวมทั้งการอ่านและการเขียนเข้าด้วยกัน โดยวัดเป็นเมกะไบต์ต่อวินาที
การพุ่งสูงของ I/O ของฐานข้อมูลอาจบ่งชี้ถึงการสืบค้นข้อมูลที่กำลังสแกนตารางขนาดใหญ่ กิจกรรมการบันทึกข้อมูลมากเกินไป หรือการดำเนินการจุดตรวจสอบ แผง Data File I/O จะแบ่งกิจกรรม I/O ออกตามฐานข้อมูลและไฟล์
3.1.4 คำขอแบบแบตช์/วินาที
เมตริกนี้แสดงถึงจำนวน SQL Server จำนวนชุดข้อมูลที่อินสแตนซ์ได้รับต่อวินาที ชุดข้อมูลอาจเป็นคำสั่งเดียวหรือหลายคำสั่งที่ส่งพร้อมกัน
ค่านี้ช่วยให้คุณทราบถึงกิจกรรมโดยรวมของเซิร์ฟเวอร์ คำขอแบบกลุ่มที่หายไปอย่างกะทันหันในช่วงเวลาทำการปกติอาจบ่งชี้ถึงปัญหาการเชื่อมต่อแอปพลิเคชันหรือปัญหาที่ผู้ใช้พบ
3.1.5 การตั้งค่าช่วงเวลาการรีเฟรช
คุณสามารถปรับแต่งความถี่ในการอัปเดตข้อมูลของ Activity Monitor ได้ดังนี้:
- คลิกขวาที่ใดก็ได้ในบานหน้าต่างภาพรวม
- เลือก รีเฟรชช่วงเวลา.
- เลือกช่วงเวลาจากค่าที่กำหนดไว้ล่วงหน้า: 1 วินาที, 5 วินาที, 10 วินาที (ค่าเริ่มต้น), 30 วินาที, 1 นาที หรือ 1 ชั่วโมง
การตั้งค่าช่วงเวลาการรีเฟรชให้ต่ำกว่า 10 วินาทีจะเพิ่มภาระในการตรวจสอบบนเซิร์ฟเวอร์ของคุณ สำหรับระบบที่ใช้งานจริงที่มีภาระงานสูง ควรพิจารณาใช้ช่วงเวลา 30 วินาทีหรือนานกว่านั้นเพื่อลดผลกระทบ
3.2 แผงกระบวนการ
บานหน้าต่างกระบวนการจะแสดงข้อมูลเกี่ยวกับเซสชันที่กำลังทำงานอยู่บนของคุณ SQL Server ตัวอย่าง แผงนี้มีความสำคัญต่อการระบุว่าใครกำลังทำอะไรและระบุปัญหาที่ขัดขวางการทำงาน
3.2.1 การทำความเข้าใจข้อมูลกระบวนการ
แต่ละแถวในบานหน้าต่าง "กระบวนการ" จะแสดงเซสชันที่ใช้งานอยู่บนเซิร์ฟเวอร์ บานหน้าต่างนี้จะแสดงเซสชันจากฐานข้อมูลทั้งหมดและผู้ใช้ทั้งหมด ช่วยให้คุณเห็นภาพรวมกิจกรรมของเซิร์ฟเวอร์อย่างครอบคลุม
ข้อมูลที่แสดงได้แก่ ชื่อเข้าระบบ ชื่อแอปพลิเคชันostชื่อ ฐานข้อมูลที่กำลังเข้าถึง และคำสั่งปัจจุบัน ซึ่งจะช่วยให้คุณเชื่อมโยงกิจกรรมฐานข้อมูลกับผู้ใช้หรือแอปพลิเคชันเฉพาะได้
3.2.2 คำอธิบายคอลัมน์หลัก
การทำความเข้าใจคอลัมน์สำคัญช่วยให้คุณตีความข้อมูลกระบวนการได้อย่างมีประสิทธิภาพ:
- รหัสเซสชัน: ตัวระบุเฉพาะสำหรับแต่ละการเชื่อมต่อ กระบวนการของระบบใช้รหัสเซสชันเชิงลบ
- กระบวนการผู้ใช้: ระบุว่านี่คือเซสชันผู้ใช้ (ใช่) หรือกระบวนการระบบ (ไม่ใช่)
- เข้าสู่ระบบ: การขอ SQL Server เข้าสู่ระบบหรือบัญชี Windows ที่เชื่อมโยงกับเซสชัน
- ฐานข้อมูล: บริบทฐานข้อมูลปัจจุบันสำหรับเซสชัน
- สถานะงาน: แสดงสิ่งที่เซสชันกำลังทำอยู่ในปัจจุบัน (กำลังทำงาน, ระงับ, นอนหลับ ฯลฯ)
- คำสั่ง: ประเภทของคำสั่งที่กำลังดำเนินการ (SELECT, INSERT, UPDATE เป็นต้น)
- การประยุกต์ใช้: ชื่อของแอปพลิเคชันที่สร้างการเชื่อมต่อ
- รอเวลา: เซสชันรอทรัพยากรมานานเท่าใด (เป็นมิลลิวินาที)
- ประเภทการรอ: ประเภทเฉพาะของทรัพยากรที่เซสชันกำลังรออยู่
- เวลาซีพียู: เวลา CPU ทั้งหมดที่ใช้ในเซสชันนี้นับตั้งแต่เชื่อมต่อ
- การใช้หน่วยความจำ: จำนวนหน่วยความจำ (เป็น KB) ที่ได้รับการจัดสรรให้กับเซสชันในปัจจุบัน
3.2.3 กระบวนการกรองและการเรียงลำดับ
บานหน้าต่างกระบวนการมีความสามารถในการกรองข้อมูลอันทรงพลังเพื่อช่วยให้คุณเน้นไปที่เซสชันที่เกี่ยวข้อง:
- คลิกลูกศรดรอปดาวน์ในส่วนหัวคอลัมน์ใดก็ได้
- ตัวกรองจะแสดงค่าที่มีอยู่สำหรับคอลัมน์นั้น รวมถึง ทั้งหมด, ช่องว่างและ ไม่ใช่ช่องว่าง.
- เลือกค่าเฉพาะเพื่อกรองการแสดงผลเฉพาะเซสชันเหล่านั้นเท่านั้น
ตัวอย่างเช่น คุณสามารถกรอง สถานะงาน เพื่อแสดงเฉพาะเซสชันที่กำลังทำงานหรือกรอง ฐานข้อมูล เพื่อดูกิจกรรมที่เกิดขึ้นกับฐานข้อมูลเฉพาะ
คุณสามารถเรียงลำดับตามคอลัมน์ใดก็ได้โดยคลิกที่ส่วนหัว คลิกหนึ่งครั้งเพื่อเรียงลำดับจากน้อยไปมาก และสองครั้งเพื่อเรียงลำดับจากมากไปน้อย
3.2.4 การระบุการบล็อกและเซสชันที่ถูกบล็อก
บานหน้าต่างกระบวนการช่วยให้คุณระบุสถานการณ์การบล็อกที่เซสชันหนึ่งป้องกันไม่ให้เซสชันอื่นดำเนินการต่อได้:
- ถูกบล็อคโดย: แสดงรหัสเซสชันของเซสชันที่กำลังบล็อกเซสชันนี้ หากคอลัมน์นี้มีค่า แสดงว่าเซสชันกำลังรอการล็อกจากเซสชันอื่น
- เฮดบล็อคเกอร์: จะแสดง '1' หากเซสชันนี้บล็อกผู้อื่น แต่ตัวเซสชันเองไม่ได้ถูกบล็อก นี่คือสาเหตุของการบล็อกเชน
ในการตรวจสอบปัญหาการบล็อก ให้ระบุตัวบล็อกหลักก่อน (เซสชันที่ทำเครื่องหมายด้วย '1' ในคอลัมน์ตัวบล็อกหลัก) จากนั้นตรวจสอบว่าเซสชันนั้นทำอะไรอยู่ และตัดสินใจว่าจะปล่อยให้เซสชันนั้นดำเนินการจนเสร็จสิ้นหรือยุติการทำงาน
3.2.5 การดำเนินการกระบวนการ (การฆ่า, รายละเอียด, การติดตาม)
Activity Monitor ช่วยให้คุณสามารถดำเนินการตามเซสชันแต่ละรายการได้:
- คลิกขวาที่เซสชันใดก็ได้ในบานหน้าต่างกระบวนการ
- คุณจะเห็นตัวเลือกหลายรายการ:
- รายละเอียด: แสดงคำสั่งสุดท้ายที่ดำเนินการโดยเซสชันนี้
- กระบวนการฆ่า: ยุติเซสชัน (ใช้ด้วยความระมัดระวัง)
- กระบวนการติดตามใน SQL Server โปรไฟล์: เปิดตัว SQL Server Profiler และกรองอัตโนมัติเพื่อแสดงเฉพาะกิจกรรมจากเซสชันนี้เท่านั้น
ตัวเลือกรายละเอียดจะแสดงข้อความคำสั่ง แต่โปรดทราบว่านี่คือ ล่าสุด คำสั่งถูกดำเนินการแล้ว—คำสั่งนั้นอาจไม่ได้กำลังทำงานอยู่ ตัวเลือก Trace มีประโยชน์อย่างยิ่งเมื่อคุณต้องการดูลำดับคำสั่งทั้งหมดที่เซสชันกำลังดำเนินการอยู่
3.3 แผงการรอทรัพยากร
บานหน้าต่างการรอทรัพยากรจะสรุปสถิติการรอ โดยแสดงประเภทของเซสชันทรัพยากรที่กำลังรออยู่ost บ่อยครั้ง ข้อมูลนี้มีความสำคัญอย่างยิ่งต่อการวินิจฉัยปัญหาคอขวดด้านประสิทธิภาพ
3.3.1 ทำความเข้าใจสถิติการรอ
เมื่อ SQL Server ไม่สามารถให้คำขอทรัพยากรได้ทันที (เช่น ล็อก เวลา CPU หรือหน่วยความจำ) งานที่ร้องขอจะเข้าสู่สถานะรอ สถิติการรอจะติดตามระยะเวลาการรอเหล่านี้ และช่วยให้คุณเข้าใจว่าเซิร์ฟเวอร์ใช้เวลารอมากกว่าทำงานในส่วนใด
บานหน้าต่าง Resource Waits จะรวบรวมข้อมูลจากมุมมองการจัดการแบบไดนามิกของระบบ เช่น sys.dm_os_wait_stats และ sys.dm_exec_requests ในแต่ละช่วงการรีเฟรช ระบบจะคำนวณความแตกต่างระหว่างสแนปช็อตปัจจุบันและสแนปช็อตก่อนหน้า พร้อมแสดงอัตราการสะสมสำหรับแต่ละประเภทการรอ
3.3.2 หมวดหมู่การรอ
Activity Monitor จัดกลุ่มประเภทการรอแต่ละประเภทนับร้อยประเภทไว้ในหมวดหมู่ที่กว้างขึ้นเพื่อให้ตีความได้ง่ายขึ้น:
- ซีพียู: งานที่รอให้เวลา CPU พร้อมใช้งาน
- บัฟเฟอร์แลตช์: รอวัตถุการซิงโครไนซ์ระยะสั้นที่ป้องกันการเข้าถึงหน้าข้อมูลในหน่วยความจำ หมวดหมู่นี้รวมถึงการรอการล็อกหน้า (PAGELATCH_*)
- ล็อค: การรอที่เกิดจากเซสชันถือล็อคที่เซสชันอื่นต้องการ
- หน่วยความจำ: รอการอนุญาตหน่วยความจำที่จำเป็นสำหรับการดำเนินการ เช่น การเรียงลำดับและการแฮช
- เครือข่าย I/O: รอการส่งหรือรับข้อมูลจากไคลเอนต์
- SQL CLR: การรอที่เกี่ยวข้องกับการดำเนินการ Common Language Runtime
แม้ว่าการจัดกลุ่มนี้จะทำให้มุมมองดูง่ายขึ้น แต่ก็ทำให้รายละเอียดสำคัญๆ คลุมเครือไปด้วย ตัวอย่างเช่น "Buffer Latch" อาจจัดกลุ่มการรอ PAGELATCH_SH, PAGELATCH_UP และ PAGELATCH_EX ไว้ด้วยกัน ซึ่งมีความหมายต่างกันต่อประสิทธิภาพการทำงาน
3.3.3 การตีความเวลาการรอและงานการรอ
บานหน้าต่างการรอทรัพยากรจะแสดงเมตริกหลักสองรายการสำหรับแต่ละประเภทการรอ:
- เวลาการรอสะสม (มิลลิวินาที): มิลลิวินาทีรวมที่สะสมระหว่างช่วงการรีเฟรชปัจจุบันสำหรับหมวดหมู่การรอคอยนี้
- งานที่รอ: จำนวนงานที่กำลังรอทรัพยากรในหมวดหมู่นี้ในขณะนี้
ค่าเวลาการรอนั้นน่าสนใจเป็นพิเศษ หากคุณมีช่วงเวลาการรีเฟรช 10 วินาที และเห็นเวลาการรอ 20,000 มิลลิวินาทีสำหรับหมวดหมู่หนึ่ง นั่นหมายความว่ามีการรอพร้อมกันหลายครั้ง (20,000 มิลลิวินาที / 10,000 มิลลิวินาที = ค่าเฉลี่ยของการรอพร้อมกัน 2 ครั้งในช่วงเวลาดังกล่าว)
3.3.4 การระบุคอขวดด้านประสิทธิภาพ
ใช้บานหน้าต่างการรอทรัพยากรเพื่อระบุว่าเซิร์ฟเวอร์ของคุณใช้เวลาอยู่ที่ใดost เวลาที่รอคอย:
- ขยายบานหน้าต่างการรอทรัพยากร
- สังเกตหมวดหมู่การรอที่มีการสะสมเวลาการรอสูงที่สุด
- เรียงลำดับตาม เวลาการรอสะสม เพื่อดูว่ามีทรัพยากรอะไรบ้างost ถูกจำกัด
การรอบัฟเฟอร์แลตช์สูงมักบ่งชี้ถึงการแย่งชิงข้อมูลในหน้าข้อมูลในหน่วยความจำ ซึ่งอาจบ่งชี้ถึงปัญหาคอขวด I/O หรือปัญหา tempdb การรอล็อกสูงบ่งชี้ถึงปัญหาการบล็อก การรอหน่วยความจำสูงบ่งชี้ว่ามีการให้สิทธิ์หน่วยความจำไม่เพียงพอสำหรับการดำเนินการค้นหา
3.4 แผง I/O ไฟล์ข้อมูล
แผงข้อมูลไฟล์ I/O จะแสดงกิจกรรมของดิสก์สำหรับไฟล์ฐานข้อมูลแต่ละไฟล์บนเซิร์ฟเวอร์ของคุณ ช่วยให้คุณระบุคอขวด I/O และทำความเข้าใจรูปแบบการใช้งานดิสก์
3.4.1 การทำความเข้าใจเมตริก I/O
บานหน้าต่าง I/O ไฟล์ข้อมูลจะแสดงเมตริกต่างๆ สำหรับไฟล์ฐานข้อมูลแต่ละไฟล์:
- ฐานข้อมูล: ชื่อของฐานข้อมูล
- ประเภทไฟล์: ข้อมูล (รวมถึงตารางและดัชนี) หรือบันทึก (บันทึกธุรกรรม)
- ชื่อตรรกะ: ชื่อไฟล์ลอจิคัลตามที่กำหนดไว้ใน SQL Server.
- MB/วินาที อ่าน: อัตราการอ่านข้อมูลจากไฟล์นี้
- MB/วินาที เขียน: อัตราการเขียนข้อมูลลงในไฟล์นี้
- เวลาตอบสนอง (มิลลิวินาที): เวลาตอบสนองโดยเฉลี่ยสำหรับการดำเนินการ I/O บนไฟล์นี้
เมตริกเหล่านี้จะรีเฟรชในช่วงเวลาเดียวกันกับบานหน้าต่างภาพรวม ทำให้คุณสามารถมองเห็นกิจกรรมของดิสก์ได้แบบเรียลไทม์
3.4.2 การระบุคอขวด I/O
สังเกตรูปแบบเหล่านี้ที่บ่งชี้ถึงปัญหาประสิทธิภาพ I/O:
- เวลาตอบสนองสูง: เวลาตอบสนองที่สูงกว่า 15-20 มิลลิวินาทีอย่างสม่ำเสมอบ่งชี้ว่าระบบย่อยของดิสก์ทำงานช้า เวลาตอบสนองที่สูงกว่า 50 มิลลิวินาทีบ่งชี้ถึงปัญหาคอขวด I/O ที่ร้ายแรง
- โหลดไม่สมดุล: หากไฟล์ข้อมูลหนึ่งแสดงอัตรา I/O สูงกว่าไฟล์อื่นๆ ในฐานข้อมูลเดียวกันอย่างมีนัยสำคัญ คุณอาจได้รับประโยชน์จากการเพิ่มไฟล์เพิ่มเติมเพื่อกระจายโหลด
- กิจกรรม Tempdb มากเกินไป: อัตรา I/O ที่สูงบนไฟล์ tempdb มักบ่งชี้ถึงแบบสอบถามที่สร้างชุดผลลัพธ์กลางขนาดใหญ่หรือใช้แผนการดำเนินการที่ไม่มีประสิทธิภาพ
3.4.3 การวิเคราะห์ไฟล์ฐานข้อมูล
ใช้บานหน้าต่าง I/O ของไฟล์ข้อมูลเพื่อทำความเข้าใจว่าฐานข้อมูลของคุณใช้ทรัพยากรดิสก์อย่างไร:
- ขยายบานหน้าต่าง I/O ไฟล์ข้อมูล
- เรียงลำดับตาม อ่าน MB/วินาที or MB/วินาที เขียน เพื่อระบุ most ไฟล์ที่ใช้งานอยู่
- จดบันทึกไฟล์ที่มีกิจกรรมสูงสม่ำเสมอหรือมีเวลาตอบสนองยาวนาน
- อ้างอิงข้อมูลนี้กับบานหน้าต่างแบบสอบถามราคาแพงล่าสุดเพื่อระบุว่าแบบสอบถามใดเป็นตัวขับเคลื่อนโหลด I/O
3.5 แผงการค้นหาข้อมูลราคาแพงล่าสุด
บานหน้าต่างแบบสอบถามราคาแพงล่าสุดมักจะเป็น most แผงที่มีประโยชน์สำหรับการแก้ไขปัญหาประสิทธิภาพการทำงานของแอปพลิเคชัน แสดงคิวรีที่ใช้ทรัพยากรเซิร์ฟเวอร์จำนวนมาก ช่วยให้คุณระบุโอกาสในการเพิ่มประสิทธิภาพได้
3.5.1 การทำความเข้าใจเมตริกการค้นหา
Activity Monitor จะแสดงเมตริกต่างๆ มากมายสำหรับแต่ละแบบสอบถามราคาแพง:
- การดำเนินการ/นาที: จำนวนครั้งที่แบบสอบถามถูกดำเนินการในนาทีสุดท้าย
- CPU (มิลลิวินาที/วินาที): เวลา CPU ที่ใช้ในการค้นหาต่อวินาที
- การอ่านทางกายภาพ/วินาที: จำนวนการอ่านดิสก์ทางกายภาพต่อวินาทีสำหรับการค้นหานี้
- การเขียนเชิงตรรกะ/วินาที: จำนวนการเขียนเชิงตรรกะ (ไปยังแคชบัฟเฟอร์) ต่อวินาที
- การอ่านเชิงตรรกะ/วินาที: จำนวนการอ่านเชิงตรรกะ (จากแคชบัฟเฟอร์) ต่อวินาที
- ระยะเวลาเฉลี่ย (มิลลิวินาที): เวลาดำเนินการโดยเฉลี่ยสำหรับแบบสอบถามนี้
- จำนวนแผน: จำนวนแผนการดำเนินการในแคชสำหรับการค้นหานี้
เมตริกเหล่านี้ช่วยให้คุณเข้าใจไม่เพียงแค่แบบสอบถามใดมีราคาแพงเท่านั้น แต่ ทำไม มันแพงและต้องวิ่งบ่อยแค่ไหน
3.5.2 ตัวเลือกการเรียงลำดับ
คุณสามารถเรียงลำดับบานหน้าต่างแบบสอบถามราคาแพงล่าสุดตามเมตริกต่างๆ เพื่อค้นหาปัญหาประเภทต่างๆ ได้:
- คลิกส่วนหัวคอลัมน์ใดๆ เพื่อเรียงลำดับตามเมตริกนั้น
- กลยุทธ์การจัดเรียงทั่วไปได้แก่:
- เรียงลำดับตามซีพียู: ค้นหาคำค้นหาที่ใช้ most เวลาของโปรเซสเซอร์
- เรียงลำดับตามการดำเนินการ/นาที: ระบุแบบสอบถามที่ทำงานบ่อยเกินไป
- จัดเรียงตามการอ่านทางกายภาพ: ค้นหาคำถามที่ทำให้เกิด most ดิสก์ I/O
- เรียงตามระยะเวลาเฉลี่ย: ค้นหาการค้นหาที่ทำงานยาวนาน
เมื่อแก้ไขปัญหาประสิทธิภาพการทำงาน ลองเรียงลำดับตามหลายคอลัมน์เพื่อให้ได้มุมมองที่แตกต่างกัน ปัญหาที่แท้จริงของคุณคือคิวรีที่มีการใช้งาน CPU ปานกลางแต่มีการประมวลผลต่อนาทีสูงมาก
3.5.3 การดูข้อความแบบสอบถาม
หากต้องการดูคำสั่ง SQL จริงที่อยู่เบื้องหลังแบบสอบถามราคาแพง ให้ทำดังนี้:
- คลิกขวาที่แถวแบบสอบถามในบานหน้าต่างแบบสอบถามราคาแพงล่าสุด
- เลือก แก้ไขข้อความสอบถาม.
- หน้าต่างแบบสอบถามใหม่จะเปิดขึ้นเพื่อแสดงคำสั่ง SQL ที่สมบูรณ์
วิธีนี้ช่วยให้คุณตรวจสอบตรรกะของแบบสอบถามและระบุโอกาสในการเพิ่มประสิทธิภาพที่เป็นไปได้ จากนั้นคุณสามารถคัดลอกข้อความแบบสอบถามเพื่อทดสอบเวอร์ชันที่แก้ไขแล้ว
3.5.4 การวิเคราะห์แผนการดำเนินการ
แผนการดำเนินการแสดงให้คุณเห็นว่า SQL Server ดำเนินการค้นหา เผยให้เห็นถึงความไม่มีประสิทธิภาพ เช่น ดัชนีที่หายไป หรือประเภทการเข้าร่วมที่ไม่เหมาะสม:
- คลิกขวาที่แถวแบบสอบถามในบานหน้าต่างแบบสอบถามราคาแพงล่าสุด
- เลือก แสดงแผนการดำเนินการ.
- SQL Server Management Studio จะแสดงภาพกราฟิกที่แสดงถึงการดำเนินการของแบบสอบถาม
มองหาการดำเนินการที่ใช้เปอร์เซ็นต์ของแบบสอบถาม c จำนวนมากostคำเตือนเกี่ยวกับสถิติหรือดัชนีที่หายไป และการดำเนินการสแกนตารางที่ไม่คาดคิด ซึ่งมักบ่งชี้ว่าควรมุ่งเน้นไปที่การปรับปรุงประสิทธิภาพที่ใด
3.5.5 การระบุคำถามที่มีปัญหา
ระวังรูปแบบเหล่านี้ในบานหน้าต่างแบบสอบถามราคาแพงล่าสุด:
- การดำเนินการที่มากเกินไป: การดำเนินการค้นหาหลายพันครั้งต่อนาทีอาจบ่งชี้ถึงปัญหาการค้นหา N+1 ซึ่งโค้ดแอปพลิเคชันเรียกใช้ฐานข้อมูลภายในลูป
- การอ่านทางกายภาพสูง: แบบสอบถามที่มีอัตราการอ่านทางกายภาพสูงมักจะถูกบันทึกลงในดิสก์บ่อยครั้ง แสดงให้เห็นว่ามีดัชนีที่หายไปหรือแบบสอบถามที่เขียนไม่ดี
- CPU สูงพร้อมระยะเวลาต่ำ: การสอบถามอย่างรวดเร็วจำนวนมากที่ใช้ CPU จำนวนมากโดยรวมอาจส่งผลกระทบต่อประสิทธิภาพของเซิร์ฟเวอร์ได้เช่นเดียวกับการสอบถามที่ช้าเพียงไม่กี่รายการ
- นับแผนหลายรายการ: การสอบถามที่มีแผนการดำเนินการจำนวนมากอาจประสบปัญหาการดมกลิ่นพารามิเตอร์หรือการสอบถามที่ไม่มีพารามิเตอร์ซึ่งส่งผลให้แคชแผนมีขนาดใหญ่ขึ้น
4. การใช้ Activity Monitor เพื่อแก้ไขปัญหาประสิทธิภาพ
Activity Monitor จะมีประสิทธิภาพอย่างแท้จริงเมื่อคุณใช้งานอย่างเป็นระบบเพื่อวินิจฉัยและแก้ไขปัญหาด้านประสิทธิภาพ ส่วนนี้จะครอบคลุมสถานการณ์การแก้ไขปัญหาทั่วไปและวิธีการแก้ไขปัญหาเหล่านั้น
4.1 การวินิจฉัยการดำเนินการแบบสอบถามที่มากเกินไป
หนึ่งในนั้นost ปัญหาประสิทธิภาพการทำงานทั่วไปคือการสอบถามที่ดำเนินการบ่อยเกินความจำเป็น ซึ่งมักเกิดจากปัญหาการออกแบบแอปพลิเคชัน
4.1.1 การระบุแบบสอบถามที่ซ้ำกัน
เพื่อค้นหาแบบสอบถามที่ดำเนินการบ่อยเกินไป:
- เปิดตัวตรวจสอบกิจกรรมและขยาย คำถามราคาแพงล่าสุด บานหน้าต่าง
- เรียงลำดับตาม การดำเนินการ/นาที (การประหารชีวิตต่อนาที)
- ค้นหาแบบสอบถามด้านบนที่มีจำนวนการดำเนินการที่สูงเกินสมเหตุสมผล
- คลิกขวาที่คำถามที่น่าสงสัยและเลือก แก้ไขข้อความสอบถาม เพื่อตรวจสอบคำสั่ง SQL
ตัวอย่างเช่น หากคุณเห็นคำสั่ง SELECT ง่ายๆ ทำงาน 37,000 ครั้งต่อนาที ลองตั้งคำถามว่าแอปพลิเคชันจำเป็นต้องเรียกใช้แบบสอบถามนี้บ่อยขนาดนั้นจริงหรือไม่ost การสอบถามที่ดำเนินการมากกว่าสองสามพันครั้งต่อนาทีรับประกันการสอบสวน
4.1.2 การวิเคราะห์สาเหตุที่แท้จริง
การดำเนินการค้นหามากเกินไปมักเกิดจากปัญหาเหล่านี้:
- ปัญหาการสอบถาม N+1: โค้ดแอปพลิเคชันจะดึงรายการของไอเท็ม จากนั้นจึงดำเนินการคิวรีแยกต่างหากสำหรับไอเท็มแต่ละรายการเพื่อดึงข้อมูลที่เกี่ยวข้อง การดำเนินการนี้จะสร้างคิวรีเพิ่มเติม N รายการ โดยที่ N คือจำนวนไอเท็ม
- ขาดการแคช: แอปพลิเคชันจะสอบถามข้อมูลจากฐานข้อมูล rarมีการเปลี่ยนแปลงแทนที่จะแคชไว้ในหน่วยความจำแอปพลิเคชัน
- ลูปการสำรวจ: โค้ดจะสอบถามฐานข้อมูลซ้ำๆ เพื่อตรวจสอบการเปลี่ยนแปลงสถานะแทนที่จะใช้การแจ้งเตือนการเปลี่ยนแปลงหรือคิวข้อความ
- ประสิทธิภาพ ORM ต่ำ: Entity Framework และเครื่องมือที่คล้ายคลึงกันบางครั้งสร้างรูปแบบแบบสอบถามที่ไม่มีประสิทธิภาพเมื่อนักพัฒนาไม่เข้าใจว่าโค้ดของพวกเขาแปลเป็น SQL ได้อย่างไร
เพื่อตรวจสอบสาเหตุหลัก ให้ติดตามแบบสอบถามกลับไปยังโค้ดแอปพลิเคชัน โปรดทราบ การใช้งาน และ เข้าสู่ระบบ คอลัมน์ในบานหน้าต่างกระบวนการเมื่อดำเนินการสอบถาม คุณยังสามารถคลิกขวาที่กระบวนการและเลือก กระบวนการติดตามใน SQL Server Profiler เพื่อดูรูปแบบการโทร
4.1.3 โซลูชันและแนวทางปฏิบัติที่ดีที่สุด
เมื่อคุณระบุการดำเนินการค้นหาที่มากเกินไปแล้ว ให้พิจารณาแนวทางแก้ไขดังต่อไปนี้:
- การประมวลผลแบบกลุ่ม: แก้ไขโค้ดแอปพลิเคชันเพื่อเรียกค้นรายการหลายรายการในแบบสอบถามเดียวโดยใช้การรวมหรือคำสั่ง IN แทนที่จะดำเนินการแบบสอบถามแยกกันในลูป
- การแคชผลลัพธ์: แคชเข้าถึงบ่อยครั้ง เปลี่ยนแปลงข้อมูลในหน่วยความจำแอปพลิเคชันไม่บ่อยนักพร้อมเวลาหมดอายุที่เหมาะสม
- กำลังโหลดอย่างกระตือรือร้น: กำหนดค่า ORM เพื่อใช้กลยุทธ์การโหลดแบบกระตือรือร้นที่ดึงข้อมูลที่เกี่ยวข้องด้วยแบบสอบถามจำนวนน้อยลงและมีประสิทธิภาพมากขึ้น
- การกำหนดพารามิเตอร์แบบสอบถาม: ตรวจสอบให้แน่ใจว่าแบบสอบถามใช้พารามิเตอร์แทนการเรียงค่า ซึ่งจะช่วยปรับปรุงการนำแคชแผนมาใช้ซ้ำและลดภาระในการคอมไพล์
4.2 การตรวจสอบปัญหาการบล็อก
การบล็อกเกิดขึ้นเมื่อเซสชันหนึ่งล็อกไว้ ทำให้เซสชันอื่นๆ ไม่สามารถดำเนินการต่อได้ ส่งผลให้แอปพลิเคชันตอบสนองช้าและผู้ใช้เกิดความไม่พอใจ
4.2.1 การระบุโซ่การบล็อก
การตรวจจับและวิเคราะห์การบล็อค:
- เปิดตัวตรวจสอบกิจกรรมและขยาย กระบวนการ บานหน้าต่าง
- ค้นหาเซสชันที่มีค่าใน ถูกบล็อคโดย คอลัมน์—สิ่งเหล่านี้กำลังรอการล็อคที่ถูกยึดไว้โดยเซสชันอื่น
- ค้นหาเซสชันที่มี '1' ใน บล็อกเกอร์หัว คอลัมน์—นี่คือสาเหตุหลักของการบล็อกโซ่
- หมายเหตุ รหัสเซสชัน ของตัวบล็อกหัว
- คลิกขวาที่เซสชันบล็อกหัวและเลือก รายละเอียด เพื่อดูว่ากำลังดำเนินการคำสั่งอะไร
การทำความเข้าใจเกี่ยวกับบล็อกเชนเป็นสิ่งสำคัญ ตัวบล็อกหลักคือเซสชันที่คุณต้องตรวจสอบ ไม่ใช่เซสชันที่ถูกบล็อกที่อยู่ปลายน้ำ
4.2.2 ทำความเข้าใจเกี่ยวกับประเภทของล็อค
การขอ ประเภทการรอ คอลัมน์ในบานหน้าต่างกระบวนการระบุประเภทของเซสชันที่ถูกล็อคที่กำลังรออยู่:
- แอลซีเค_เอ็ม_เอ็กซ์: การรอการล็อคแบบพิเศษ โดยทั่วไปเกิดจากการดำเนินการ UPDATE, DELETE หรือ INSERT
- LCK_M_S: การรอการล็อคแบบแชร์ โดยปกติแล้วคำสั่ง SELECT จะรอให้การล็อคแบบพิเศษถูกปลดล็อค
- LCK_M_U: การรอการล็อคการอัปเดต เป็นประเภทการล็อคระดับกลางที่ใช้ในระหว่างการอัปเดต
- LCK_M_IX: การรอการล็อคแบบพิเศษที่ตั้งใจ ระบุถึงการโต้แย้งการล็อคในระดับเพจหรือแถว
การขอ รอทรัพยากร คอลัมน์แสดงวัตถุฐานข้อมูลที่ถูกล็อค ซึ่งช่วยให้คุณเข้าใจว่าตารางหรือดัชนีใดมีส่วนเกี่ยวข้องในการแข่งขัน
4.2.3 การแก้ไขปัญหาการบล็อค
เมื่อคุณระบุเซสชันการบล็อคและสิ่งที่กำลังทำอยู่ได้แล้ว คุณมีตัวเลือกหลายประการ:
- รอดำเนินการให้เสร็จสิ้น: หากตัวบล็อกหัวกำลังรันแบบสอบถามที่ถูกต้องตามกฎหมายซึ่งจะเสร็จสิ้นในเร็วๆ นี้ อาจเป็นการดีที่สุดที่จะปล่อยให้เสร็จสิ้นตามธรรมชาติ
- ฆ่าเซสชัน: หากตัวบล็อกหัวติดหรือกำลังรันแบบสอบถามที่ควรจะถูกยกเลิก:
- คลิกขวาที่เซสชันในบานหน้าต่างกระบวนการ
- เลือก ฆ่ากระบวนการ.
- ยืนยันการดำเนินการในกล่องโต้ตอบ
- เพิ่มประสิทธิภาพการค้นหา: หากการบล็อคเกิดขึ้นซ้ำกับแบบสอบถามเดียวกัน ให้ปรับให้เหมาะสมเพื่อลดระยะเวลาการล็อค
- ปรับระดับการแยก: พิจารณาใช้ READ COMMITTED SNAPSHOT ISOLATION เพื่อลดการบล็อกในเวิร์กโหลดที่มีการอ่านหนัก
- การปรับดัชนี: เพิ่มดัชนีเพื่อเพิ่มความเร็วในการค้นหา โดยลดระยะเวลาในการล็อคข้อมูล
4.3 การวิเคราะห์การใช้งาน CPU สูง
เมื่อบานหน้าต่างภาพรวมแสดงเวลาของโปรเซสเซอร์อย่างสม่ำเสมอที่หรือใกล้เคียง 100% คุณจะต้องระบุว่าแบบสอบถามใดที่รับผิดชอบและกำหนดว่าสามารถปรับให้เหมาะสมได้หรือไม่
4.3.1 การระบุแบบสอบถามที่ใช้ CPU มาก
การค้นหาแบบสอบถามที่ใช้ CPU มากเกินไป:
- เปิด คำถามราคาแพงล่าสุด บานหน้าต่าง
- เรียงลำดับตาม ซีพียู (มิลลิวินาที/วินาที) เพื่อแสดงแบบสอบถามโดยใช้ most เวลาซีพียู
- ตรวจสอบคำค้นหาอันดับต้นๆ ในรายการ
- คลิกขวาที่แบบสอบถาม CPU สูงและเลือก แก้ไขข้อความสอบถาม เพื่อดูคำสั่ง SQL
- เลือก แสดงแผนการดำเนินการ เพื่อทำความเข้าใจว่าแบบสอบถามดำเนินการอย่างไร
ใส่ใจไม่เพียงแค่การใช้งาน CPU ของแบบสอบถามแต่ละรายการเท่านั้น แต่ยังรวมถึง การดำเนินการ/นาที คอลัมน์ การค้นหาที่ใช้ CPU ปานกลางต่อการดำเนินการ แต่ทำงานหลายพันครั้งต่อนาที อาจเป็นการใช้ CPU มากที่สุดของคุณ
4.3.2 เทคนิคการเพิ่มประสิทธิภาพการค้นหา
แนวทางทั่วไปในการลดการใช้ CPU ได้แก่:
- เพิ่มดัชนีที่หายไป: ดัชนีพยายามใช้ CPU น้อยกว่าการสแกนตารางมาก มองหาคำแนะนำดัชนีที่ขาดหายไปในแผนการดำเนินการ
- เขียนใหม่แบบสอบถามที่ไม่มีประสิทธิภาพ: แทนที่เคอร์เซอร์ด้วยการดำเนินการตามชุด กำจัดฟังก์ชันที่ไม่จำเป็นในคำสั่ง WHERE และลบการเชื่อมโยงที่ซ้ำซ้อน
- อัปเดตสถิติ: สถิติที่ล้าสมัยเป็นสาเหตุ SQL Server เพื่อเลือกแผนการดำเนินการที่ไม่มีประสิทธิภาพ เรียกใช้ UPDATE STATISTICS บนตารางที่ได้รับผลกระทบ
- ลดปริมาณข้อมูล: เพิ่มคำสั่ง WHERE เพื่อกรองข้อมูลก่อนหน้านี้ ใช้ TOP หรือ OFFSET/FETCH สำหรับการแบ่งหน้า และหลีกเลี่ยง SELECT *.
- แก้ไขการดมกลิ่นพารามิเตอร์: ใช้ OPTION (RECOMPILE) คำแนะนำแบบสอบถาม หรือแนวทางการวางแผนเมื่อการดมกลิ่นพารามิเตอร์ทำให้เกิดปัญหา
4.4 การตรวจสอบปัญหาด้านความจำ
แรงกดดันด้านหน่วยความจำอาจทำให้คิวรีล้นไปยังดิสก์ ส่งผลให้ประสิทธิภาพลดลงอย่างมาก Activity Monitor ช่วยให้คุณระบุการดำเนินการที่ใช้หน่วยความจำมากได้
4.4.1 การทำความเข้าใจเมตริกหน่วยความจำ
การขอ การใช้หน่วยความจำ คอลัมน์ในบานหน้าต่างกระบวนการแสดงหน่วยความจำที่จัดสรรให้กับแต่ละเซสชันเป็นกิโลไบต์ การใช้หน่วยความจำสูงในเซสชันเดียวมักบ่งชี้ถึง:
- การดำเนินการเรียงลำดับหรือแฮชขนาดใหญ่ที่ไม่สามารถใส่ลงในหน่วยความจำที่ได้รับอนุญาตในตอนแรกได้
- การค้นหาชุดผลลัพธ์จำนวนมหาศาล
- การทำงานแบบขนานที่มากเกินไปทำให้มีการดำเนินการตามแผนปฏิบัติการหลายชุด
- การรั่วไหลของหน่วยความจำในกระบวนการหรือฟังก์ชันที่จัดเก็บไว้ของ CLR
บานหน้าต่างการรอทรัพยากรอาจแสดงการรอหน่วยความจำเมื่อแบบสอบถามไม่สามารถรับการอนุญาตหน่วยความจำที่เพียงพอและจะต้องรอให้หน่วยความจำพร้อมใช้งาน
4.4.2 การระบุแบบสอบถามที่ใช้หน่วยความจำมาก
การค้นหาคำถามที่ทำให้หน่วยความจำทำงานหนัก:
- ตัว Vortex Indicator ได้ถูกนำเสนอลงในนิตยสาร กระบวนการ บานหน้าต่าง เรียงลำดับตาม การใช้หน่วยความจำ เพื่อดูเซสชันที่บริโภค most หน่วยความจำ
- คลิกขวาที่เซสชันที่มีการใช้หน่วยความจำสูงและเลือก รายละเอียด เพื่อดูข้อสงสัยของพวกเขา
- ตัว Vortex Indicator ได้ถูกนำเสนอลงในนิตยสาร คำถามราคาแพงล่าสุด บานหน้าต่างค้นหาแบบสอบถามที่มีค่าสูง การอ่านเชิงตรรกะ or การเขียนเชิงตรรกะเนื่องจากสิ่งเหล่านี้มักสัมพันธ์กับการใช้งานหน่วยความจำ
- ตรวจสอบแผนการดำเนินการสำหรับตัวดำเนินการ Sort และ Hash Match ซึ่งใช้การอนุญาตหน่วยความจำ
แบบสอบถามที่แสดงคำเตือน "การให้สิทธิ์หน่วยความจำ" ในแผนการดำเนินการหรือคำเตือนการรั่วไหล บ่งชี้ถึงปัญหาแรงกดดันหน่วยความจำ
4.5 การตรวจจับปัญหาประสิทธิภาพการทำงานของแอปพลิเคชัน
เมื่อผู้ใช้รายงานเวลาตอบสนองของแอปพลิเคชันที่ช้า Activity Monitor จะช่วยให้คุณระบุได้ว่าฐานข้อมูลเป็นสาเหตุของปัญหาคอขวดหรือไม่
4.5.1 การเชื่อมโยง Activity Monitor กับปัญหาแอปพลิเคชัน
เพื่อตรวจสอบความล่าช้าของแอปพลิเคชัน:
- จดบันทึกเวลาที่แน่นอนที่ผู้ใช้รายงานปัญหาและแอปพลิเคชันที่ได้รับผลกระทบ
- เปิดตัวตรวจสอบกิจกรรมและตรวจสอบ ข้อมูลทั่วไป บานหน้าต่างสำหรับทรัพยากรที่เพิ่มขึ้นในขณะนั้น
- ตัว Vortex Indicator ได้ถูกนำเสนอลงในนิตยสาร กระบวนการ บานหน้าต่าง กรองตาม การใช้งาน เพื่อแสดงเฉพาะการเชื่อมต่อจากแอปพลิเคชันที่ได้รับผลกระทบ
- มองหาที่สูง รอเวลา ค่าที่ระบุถึงความล่าช้าของฐานข้อมูล
- ตรวจสอบ คำถามราคาแพงล่าสุด บานหน้าต่างสำหรับการสอบถามจากแอปพลิเคชันที่ใช้ทรัพยากรจำนวนมาก
หากฐานข้อมูลไม่แสดงกิจกรรมที่ผิดปกติในขณะที่ผู้ใช้ประสบปัญหาความเร็วลดลง ปัญหาน่าจะเกิดจากโค้ดแอปพลิเคชัน ความหน่วงของเครือข่าย หรือประสิทธิภาพด้านไคลเอนต์
4.5.2 การระบุรูปแบบแอปพลิเคชันที่ไม่มีประสิทธิภาพ
Activity Monitor เปิดเผยรูปแบบต่อต้านหลายประการในการออกแบบแอปพลิเคชัน:
- แอปพลิเคชั่น Chatty: คิวรีขนาดเล็กจำนวนมากแทนที่จะใช้คิวรีจำนวนน้อย มีประสิทธิภาพมากขึ้น ระบุได้จากจำนวนการเชื่อมต่อที่สูงและคิวรีแบบง่ายจำนวนมากในคิวรีราคาแพงล่าสุด
- N+1 แบบสอบถาม: หนึ่งคิวรีตามด้วยคิวรีเพิ่มเติม N รายการสำหรับข้อมูลที่เกี่ยวข้อง แสดงเป็นคิวรีแบบง่ายที่มีการประมวลผลต่อนาทีสูงมาก
- ชุดผลลัพธ์ขนาดใหญ่: แอปพลิเคชันดึงข้อมูลมากกว่าที่จำเป็นมาก มองหาข้อมูลสูง การอ่านเชิงตรรกะ รวมกับแบบสอบถาม SELECT * แบบง่ายๆ
- การขาดการหมดเวลา: แอปพลิเคชันที่ไม่ได้ตั้งค่าการหมดเวลาคำสั่งอาจปล่อยให้การเชื่อมต่อเปิดอยู่โดยไม่จำกัดเวลา ซึ่งมองเห็นได้เป็นเซสชันที่ทำงานยาวนานในบานหน้าต่างกระบวนการ
5. วิธีการทางเลือก: การรับข้อมูล Activity Monitor ผ่าน T-SQL
แม้ว่า Activity Monitor จะมีอินเทอร์เฟซกราฟิกที่สะดวก แต่บางครั้งคุณอาจต้องดึงข้อมูลเทียบเท่าผ่านโปรแกรมหรือสร้างโซลูชันการตรวจสอบแบบกำหนดเอง
5.1 การใช้มุมมองการจัดการแบบไดนามิก (DMV)
SQL Server เปิดเผยข้อมูลกิจกรรมผ่านมุมมองการจัดการแบบไดนามิก ซึ่ง Activity Monitor จะสอบถามข้อมูลเบื้องหลัง
5.1.1 DMV หลักสำหรับการติดตามกิจกรรม
ม.ost DMV ที่สำคัญสำหรับการจำลองฟังก์ชันการทำงานของ Activity Monitor ได้แก่:
- คำขอ sys.dm_exec: แสดงคำขอที่กำลังดำเนินการอยู่ในปัจจุบันพร้อมข้อมูล CPU, I/O และการรอ
- sys.dm_exec_เซสชัน: ประกอบด้วยข้อมูลระดับเซสชัน เช่น ชื่อเข้าสู่ระบบost ชื่อและชื่อโปรแกรม
- sys.dm_os_wait_stats: ให้สถิติการรอสะสมสำหรับอินสแตนซ์ทั้งหมด
- sys.dm_exec_query_stats: ประกอบด้วยสถิติประสิทธิภาพโดยรวมสำหรับแบบสอบถามที่แคชไว้
- สถิติไฟล์เสมือน sys.dm_io: คืนสถิติ I/O สำหรับข้อมูลและไฟล์บันทึก
- sys.dm_exec_sql_text: ดึงข้อความ SQL สำหรับ sql_handle หรือ plan_handle ที่กำหนด
- แผนการสอบถาม sys.dm_exec: ส่งคืนแผนการดำเนินการสำหรับแบบสอบถามที่แคชไว้
5.1.2 ตัวอย่างแบบสอบถามข้อมูลกระบวนการ
หากต้องการจำลองฟังก์ชันบานหน้าต่างกระบวนการ คุณสามารถสอบถามข้อมูลดังต่อไปนี้:
SELECT
s.session_id AS [Session ID],
CASE WHEN s.is_user_process = 1 THEN 'Yes' ELSE 'No' END AS [User Process],
s.login_name AS [Login],
ISNULL(CAST(r.blocking_session_id AS VARCHAR), '') AS [Blocked By],
CASE
WHEN r2.session_id IS NOT NULL
AND (r.blocking_session_id = 0 OR r.session_id IS NULL)
THEN '1'
ELSE ''
END AS [Head Blocker],
ISNULL(DB_NAME(r.database_id), '') AS [Database],
ISNULL(t.task_state, '') AS [Task State],
ISNULL(r.command, '') AS [Command],
r.cpu_time AS [CPU Time],
r.total_elapsed_time AS [Elapsed Time],
r.wait_time AS [Wait Time],
r.wait_type AS [Wait Type],
s.memory_usage * 8 AS [Memory Use (KB)],
s.host_name AS [Host Name],
s.program_name AS [Application]
FROM sys.dm_exec_sessions s
LEFT JOIN sys.dm_exec_requests r ON s.session_id = r.session_id
LEFT JOIN sys.dm_exec_requests r2 ON r.session_id = r2.blocking_session_id
LEFT JOIN sys.dm_os_tasks t ON r.session_id = t.session_id
WHERE s.session_id != @@SPID
ORDER BY s.session_id;
5.1.3 ตัวอย่างแบบสอบถามสำหรับสถิติการรอ
หากต้องการดูสถิติการรอที่คล้ายกับบานหน้าต่างการรอทรัพยากร ให้ทำดังนี้:
SELECT TOP 10
wait_type AS [Wait Type],
wait_time_ms / 1000.0 AS [Wait Time (sec)],
waiting_tasks_count AS [Waiting Tasks],
wait_time_ms / NULLIF(waiting_tasks_count, 0) AS [Avg Wait Time (ms)]
FROM sys.dm_os_wait_stats
WHERE wait_type NOT LIKE '%SLEEP%'
AND wait_type NOT LIKE '%IDLE%'
AND wait_type NOT LIKE '%QUEUE%'
ORDER BY wait_time_ms DESC;
5.2 การใช้ sp_WhoIsActive
sp_WhoIsActive เป็นกระบวนการจัดเก็บอันทรงพลังที่สร้างโดยชุมชนซึ่งให้ข้อมูลที่ละเอียดกว่า Activity Monitor ในชุดผลลัพธ์เดียว
5.2.1 การติดตั้ง sp_WhoIsActive
ในการติดตั้ง sp_WhoIsActive:
- ดาวน์โหลดเวอร์ชันล่าสุดจาก
http://whoisactive.com. - การดาวน์โหลดเป็นสคริปต์ SQL ที่มีคำจำกัดความของขั้นตอน
- เปิดสคริปต์ใน SQL Server สตูดิโอการจัดการ
- เชื่อมต่อกับของคุณ SQL Server ตัวอย่าง.
- ดำเนินการสคริปต์เพื่อสร้างกระบวนการในฐานข้อมูลหลัก
- ให้สิทธิ์การดำเนินการแก่ผู้ใช้ที่เหมาะสม
เนื่องจาก sp_WhoIsActive ได้รับการติดตั้งในส่วนหลัก จึงสามารถเข้าถึงได้จากบริบทฐานข้อมูลใดๆ
5.2.2 ตัวอย่างการใช้งานพื้นฐาน
วิธีที่ง่ายที่สุดในการใช้ sp_WhoIsActive คือ:
EXEC sp_WhoIsActive;
ผลลัพธ์นี้จะส่งคืนชุดผลลัพธ์ที่แสดงเซสชันที่ใช้งานอยู่ทั้งหมดพร้อมกับแบบสอบถาม ประเภทการรอ ข้อมูลการบล็อค และการใช้งานทรัพยากร
สำหรับตัวอย่าง 10 วินาทีที่แสดงกิจกรรมในช่วงเวลาดังกล่าว:
EXEC sp_WhoIsActive @delta_interval = 10;
การคำนวณนี้จะคำนวณเดลต้าสำหรับเมตริกต่างๆ เช่น CPU และการอ่าน โดยแสดงสิ่งที่เกิดขึ้นในช่วง 10 วินาทีเหล่านั้น
5.2.3 พารามิเตอร์ขั้นสูง
sp_WhoIsActive รองรับพารามิเตอร์มากมายสำหรับการปรับแต่ง:
- @กรอง: กรองผลลัพธ์ให้เฉพาะเซสชัน ฐานข้อมูล หรือการเข้าสู่ระบบ
- @ชนิดตัวกรอง: ระบุว่าตัวกรองใช้กับอะไร (เซสชัน, ฐานข้อมูล, การเข้าสู่ระบบ ฯลฯ)
- @get_plans: รวมแผนการดำเนินการไว้ในผลลัพธ์ (ตั้งเป็น 1)
- @รับล็อค: แสดงข้อมูลล็อคโดยละเอียด (ตั้งค่าเป็น 1)
- @รับข้อมูลธุรกรรม: แสดงรายละเอียดธุรกรรม (ตั้งค่าเป็น 1)
- @เรียงลำดับ: สั่งผลลัพธ์ตามเมตริกที่แตกต่างกัน (CPU, การอ่าน, ระยะเวลา ฯลฯ)
- @destination_table: แทรกผลลัพธ์ลงในตารางเพื่อการติดตามประวัติ
ตัวอย่างแสดงแผนที่จัดเรียงตาม CPU:
EXEC sp_WhoIsActive
@get_plans = 1,
@sort_order = '[CPU] DESC';
5.3 การใช้กระบวนการจัดเก็บระบบ
SQL Server รวมถึงขั้นตอนการจัดเก็บแบบดั้งเดิมสำหรับการตรวจสอบกิจกรรม แม้ว่าจะให้ข้อมูลน้อยกว่า DMV หรือ Activity Monitor ก็ตาม
5.3.1 sp_who และ sp_who2
ขั้นตอน sp_who จะแสดงข้อมูลเซสชันพื้นฐาน:
EXEC sp_who;
ขั้นตอน sp_who2 จะให้รายละเอียดเพิ่มเติมเล็กน้อย:
EXEC sp_who2;
ทั้งสองขั้นตอนจะแสดง ID เซสชัน ชื่อล็อกอิน เวลา CPU และข้อมูลการบล็อก อย่างไรก็ตาม ขั้นตอนเหล่านี้ยังขาดรายละเอียดที่ละเอียดมากซึ่งหาได้จาก DMV หรือ Activity Monitorost มีประโยชน์สำหรับการตรวจสอบอย่างรวดเร็วเมื่อคุณต้องการข้อมูลขั้นต่ำอย่างรวดเร็ว
5.3.2 ขั้นตอนระบบที่มีประโยชน์อื่น ๆ
ขั้นตอนระบบเพิ่มเติมสำหรับการตรวจสอบ ได้แก่:
- สป_ล็อค: แสดงข้อมูลล็อค (ไม่สนับสนุนอีกต่อไป ใช้ sys.dm_tran_locks แทน)
- sp_monitor: แสดงสถิติเกี่ยวกับ SQL Server กิจกรรม
- sp_help: แสดงคำจำกัดความของวัตถุและข้อมูลเมตา
- DBCC SQLPERF: แสดงการใช้งานพื้นที่บันทึกธุรกรรมและสถิติการรอ
5.4 การสร้างสคริปต์การตรวจสอบแบบกำหนดเอง
สำหรับสภาพแวดล้อมที่ต้องมีการตรวจสอบเฉพาะเจาะจงมากกว่าที่ Activity Monitor จัดให้ คุณสามารถสร้างโซลูชันแบบกำหนดเองโดยใช้ DMV ได้
5.4.1 สคริปต์เทียบเท่า Activity Monitor ที่สมบูรณ์
นี่คือสคริปต์ที่ครอบคลุมซึ่งจำลอง most ฟังก์ชันการตรวจสอบกิจกรรม:
-- Processes Information
SELECT
s.session_id AS [Session ID],
CONVERT(CHAR(1), s.is_user_process) AS [User Process],
s.login_name AS [Login],
ISNULL(CONVERT(VARCHAR, w.blocking_session_id), '') AS [Blocked By],
CASE
WHEN r2.session_id IS NOT NULL
AND (r.blocking_session_id = 0 OR r.session_id IS NULL)
THEN '1'
ELSE ''
END AS [Head Blocker],
ISNULL(DB_NAME(r.database_id), N'') AS [Database],
ISNULL(t.task_state, N'') AS [Task State],
ISNULL(r.command, N'') AS [Command],
SUBSTRING(st.text, (r.statement_start_offset/2) + 1,
((CASE r.statement_end_offset
WHEN -1 THEN DATALENGTH(st.text)
ELSE r.statement_end_offset
END - r.statement_start_offset) / 2) + 1) AS [Statement],
st.text AS [Command Text],
r.cpu_time AS [CPU Time (ms)],
r.total_elapsed_time / 1000 AS [Elapsed Time (sec)],
r.wait_time AS [Wait Time (ms)],
r.wait_type AS [Wait Type],
r.wait_resource AS [Wait Resource],
s.memory_usage * 8 AS [Memory Use (KB)],
s.host_name AS [Host Name],
c.client_net_address AS [Net Address],
s.program_name AS [Application]
FROM sys.dm_exec_sessions s
LEFT JOIN sys.dm_exec_requests r ON s.session_id = r.session_id
LEFT JOIN sys.dm_exec_requests w ON r.session_id = w.blocking_session_id
LEFT JOIN sys.dm_exec_requests r2 ON r.session_id = r2.blocking_session_id
LEFT JOIN sys.dm_os_tasks t ON r.session_id = t.session_id
AND r.request_id = t.request_id
LEFT JOIN sys.dm_exec_connections c ON s.session_id = c.session_id
OUTER APPLY sys.dm_exec_sql_text(r.sql_handle) st
WHERE s.session_id != @@SPID
ORDER BY s.session_id;
-- Recent Expensive Queries
SELECT TOP 20
qs.execution_count /
DATEDIFF(MINUTE, qs.creation_time, GETDATE()) AS [Executions/min],
qs.total_worker_time / 1000 AS [CPU Time (ms)],
qs.total_physical_reads AS [Physical Reads],
qs.total_logical_writes AS [Logical Writes],
qs.total_logical_reads AS [Logical Reads],
qs.total_elapsed_time / qs.execution_count / 1000 AS [Avg Duration (ms)],
SUBSTRING(st.text, (qs.statement_start_offset/2) + 1,
((CASE qs.statement_end_offset
WHEN -1 THEN DATALENGTH(st.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) st
WHERE qs.execution_count > 0
ORDER BY qs.total_worker_time DESC;
5.4.2 การตรวจสอบอัตโนมัติด้วยงานตัวแทน SQL
คุณสามารถกำหนดเวลาสคริปต์การตรวจสอบแบบกำหนดเองได้โดยใช้ SQL Server ตัวแทน:
- สร้างตารางเพื่อเก็บผลการตรวจสอบ
- แก้ไขสคริปต์การตรวจสอบของคุณเพื่อแทรกผลลัพธ์ลงในตารางนี้
- In SQL Server สตูดิโอการจัดการ ขยาย SQL Server ตัวแทน ใน Object Explorer
- คลิกขวาที่ งาน และเลือก งานใหม่.
- กำหนดค่างานเพื่อรันสคริปต์การตรวจสอบของคุณเป็นระยะๆ
- ตั้งค่าการแจ้งเตือนหรือรายงานตามข้อมูลที่รวบรวม
แนวทางนี้ช่วยให้สามารถติดตามประวัติและวิเคราะห์แนวโน้มได้ ซึ่ง Activity Monitor ไม่สามารถให้ได้
6. ข้อจำกัดและข้อควรพิจารณาของตัวตรวจสอบกิจกรรม
แม้ว่า Activity Monitor จะมีคุณค่า แต่การเข้าใจข้อจำกัดของมันจะช่วยให้คุณใช้มันได้อย่างเหมาะสม และเสริมด้วยเครื่องมืออื่นๆ เมื่อจำเป็น
6.1 การทำความเข้าใจโอเวอร์เฮดของ Activity Monitor
Activity Monitor ไม่ฟรี เพราะต้องใช้ทรัพยากรเซิร์ฟเวอร์ในการรวบรวมและแสดงข้อมูล การเข้าใจถึงโอเวอร์เฮดนี้จะช่วยให้คุณใช้งานอย่างมีความรับผิดชอบ
6.1.1 ผลกระทบต่อทรัพยากรเซิร์ฟเวอร์
Activity Monitor จะรันคิวรีกับ DMV ของระบบทุกครั้งที่รีเฟรช คิวรีเหล่านี้กิน CPU สร้างการอ่านเชิงตรรกะ และอาจล็อกตารางระบบชั่วคราว สำหรับเซิร์ฟเวอร์ที่มีการใช้งานมาก โอเวอร์เฮดนี้อาจส่งผลกระทบต่อประสิทธิภาพการทำงาน
แผง Processes และ Recent Expensive Queries มีค่าใช้จ่ายค่อนข้างสูง เนื่องจากต้องสแกน DMV และตารางแคชที่อาจมีขนาดใหญ่ บนเซิร์ฟเวอร์ที่มีแผนแคชคิวรีหลายพันแผน การรีเฟรช Recent Expensive Queries อาจใช้เวลาหลายวินาที
เอกสารของ Microsoft เตือนว่าช่วงเวลาการรีเฟรชที่ต่ำกว่า 10 วินาทีอาจส่งผลต่อประสิทธิภาพของเซิร์ฟเวอร์ได้อย่างเห็นได้ชัด โดยเฉพาะในระบบที่โหลดไว้แล้ว
6.1.2 แนวทางปฏิบัติที่ดีที่สุดสำหรับช่วงเวลาการรีเฟรช
เลือกช่วงเวลาการรีเฟรชให้เหมาะสมกับสถานการณ์ของคุณ:
- 1-5 วินาที: ใช้สำหรับการแก้ไขปัญหาสำคัญในเซิร์ฟเวอร์ที่มีโหลดน้อยเท่านั้น อย่าปล่อยให้ Activity Monitor ทำงานในช่วงเวลาดังกล่าว
- 10 วินาที (ค่าเริ่มต้น): เหมาะสมกับม.ost สถานการณ์การแก้ไขปัญหาและการตรวจสอบทั่วไป
- 30-60 วินาที: ทางเลือกที่ดีกว่าสำหรับเซิร์ฟเวอร์การผลิตภายใต้ภาระหนักหรือเมื่อตรวจสอบเป็นระยะเวลานาน
- รีเฟรชด้วยตนเองเท่านั้น: สำหรับสถานการณ์ที่คุณต้องการตรวจสอบสถานะปัจจุบันเป็นครั้งคราวโดยไม่ต้องสำรวจอย่างต่อเนื่อง
ปิด Activity Monitor ทุกครั้งเมื่อตรวจสอบเสร็จ อย่าปล่อยให้ Activity Monitor ทำงานต่อเนื่อง โดยเฉพาะอย่างยิ่งเมื่อมีหลายอินสแตนซ์จากผู้ใช้ที่แตกต่างกัน
6.2 ปัญหาการจัดกลุ่มประเภทการรอ
แนวทางของ Activity Monitor ในการจัดหมวดหมู่การรอ ในขณะที่ทำให้มุมมองง่ายขึ้น อาจบดบังการวินิจฉัยที่สำคัญostข้อมูลไอซี
6.2.1 กลุ่ม Activity Monitor รออย่างไร
SQL Server ติดตามประเภทการรอที่แตกต่างกันหลายร้อยประเภท โดยแต่ละประเภทจะระบุทรัพยากรหรือเงื่อนไขเฉพาะ Activity Monitor จัดกลุ่มประเภทเหล่านี้ไว้ในหมวดหมู่กว้างๆ เช่น "Buffer Latch" "Lock" และ "Memory"
ตัวอย่างเช่น หมวดหมู่ "Buffer Latch" ประกอบด้วย PAGELATCH_SH, PAGELATCH_UP, PAGELATCH_EX และประเภทการรอเฉพาะอื่นๆ อีกมากมาย แม้ว่าทั้งหมดจะเกี่ยวข้องกับการเข้าถึงเพจ แต่ก็มีสาเหตุและวิธีแก้ไขที่แตกต่างกัน
Microsoft ไม่ได้บันทึกรายละเอียดที่ชัดเจนว่าประเภทการรอแบบใดที่แมปกับหมวดหมู่ใด ทำให้ยากต่อการเข้าใจว่าคุณกำลังเห็นอะไรจริงๆ
6.2.2 ประเภทการรอที่ขาดหายไป
Activity Monitor ไม่แสดงประเภทการรอทั้งหมด Most ที่น่าสังเกตคือ มักจะละเว้นการรอ CXPACKET ซึ่งบ่งชี้ถึงการดำเนินการคิวรีแบบขนาน การรอ CXPACKET เป็นเรื่องปกติและมักไม่ก่อให้เกิดปัญหา แต่การรู้ว่ามีการรออยู่จะช่วยให้คุณเข้าใจลักษณะเฉพาะของเวิร์กโหลด
เมื่อ Activity Monitor แสดง "Buffer Latch" เป็นการรอสูงสุดของคุณ แต่เครื่องมืออื่น ๆ แสดงว่า CXPACKET โดดเด่นกว่า ความแตกต่างจะมาจากตรรกะการกรองและการจัดกลุ่มของ Activity Monitor
6.2.3 เหตุใดประเภทการรอที่เฉพาะเจาะจงจึงมีความสำคัญ
การทราบประเภทการรอที่เฉพาะเจาะจงมีความสำคัญต่อการแก้ไขปัญหา:
- เพจ_เอ็กซ์: มักบ่งชี้ถึงการแย่งชิง tempdb บนหน้าการจัดสรร วิธีแก้ปัญหาคือการเพิ่มไฟล์ข้อมูล tempdb เพิ่มเติม
- เพจแลทช์_ช: อาจบ่งชี้ว่ามีหน้าร้อนในตารางผู้ใช้ วิธีแก้ปัญหาคือการแบ่งพาร์ติชันหรือการจัดระเบียบดัชนีใหม่
- เพจแลทช์อัพ: เกิดขึ้นบ่อยระหว่างการอัปเดต อาจบ่งชี้ถึงการทำงานปกติมากกว่าปัญหา
Activity Monitor จัดกลุ่มทั้งหมดนี้ไว้ภายใต้ "Buffer Latch" ทำให้การวินิจฉัยยากขึ้น เครื่องมืออย่าง sp_WhoIsActive และคิวรี DMV จะแสดงประเภทการรอที่เฉพาะเจาะจง
6.3 ความถูกต้องและความทันเวลาของข้อมูล
Activity Monitor มอบมุมมองที่ใกล้เคียงกับเวลาจริง แต่คำว่า "ใกล้" ถือเป็นคำสำคัญ การทำความเข้าใจวิธีการรวบรวมข้อมูลจะช่วยให้คุณตีความผลลัพธ์ได้อย่างถูกต้อง
6.3.1 ภาพรวมเทียบกับการตรวจสอบอย่างต่อเนื่อง
Activity Monitor จะแสดงสแนปช็อต ณ เวลาที่บันทึกในแต่ละช่วงการรีเฟรช เหตุการณ์ที่เกิดขึ้นระหว่างสแนปช็อตจะไม่ถูกบันทึก หากคิวรีทำงานเป็นเวลา 2 วินาที และคุณรีเฟรชทุก 10 วินาที คุณอาจเห็นมันเพียงครั้งเดียวหรือไม่เห็นเลย ขึ้นอยู่กับระยะเวลา
ซึ่งหมายความว่า Activity Monitor มีประสิทธิภาพในการค้นหาปัญหาที่เกิดขึ้นอย่างต่อเนื่อง (การบล็อกเวลาที่ยาวนาน, CPU สูงอย่างต่อเนื่อง) แต่ก็อาจพลาดปัญหาชั่วคราว (การหยุดชะงักชั่วคราว, การสอบถามที่เพิ่มขึ้นเป็นครั้งคราว)
6.3.2 การรวมและการสุ่มตัวอย่าง
บานหน้าต่าง "แบบสอบถามราคาแพงล่าสุด" จะแสดงข้อมูลที่รวบรวมไว้ตั้งแต่แผนการสอบถามเข้าสู่แคช แบบสอบถามที่เหมือนกันสองรายการที่มีค่าพารามิเตอร์ต่างกันจะปรากฏเป็นแถวเดียวกันหากใช้แผนเดียวกัน การรวมข้อมูลนี้สามารถปกปิดปัญหาเกี่ยวกับการรวมพารามิเตอร์เฉพาะ (ปัญหาการดักจับพารามิเตอร์)
บานหน้าต่างการรอทรัพยากรจะคำนวณอัตราโดยการเปรียบเทียบสแนปช็อต หากสถิติการรอรีเซ็ตระหว่างสแนปช็อต (rarแต่เป็นไปได้ อัตราที่คำนวณได้อาจไม่ถูกต้อง
6.4 เมื่อไม่ควรใช้ Activity Monitor
Activity Monitor ไม่เหมาะสำหรับทุกสถานการณ์การตรวจสอบ รู้จักเลือกเครื่องมืออื่นที่เหมาะสมกว่า
6.4.1 ข้อกำหนดการวิเคราะห์ทางประวัติศาสตร์
Activity Monitor แสดงเฉพาะกิจกรรมปัจจุบันหรือกิจกรรมล่าสุดเท่านั้น ไม่มีการเก็บข้อมูลย้อนหลัง หากคุณต้องการวิเคราะห์แนวโน้มในช่วงหลายวันหรือหลายสัปดาห์ เปรียบเทียบประสิทธิภาพปัจจุบันกับค่าพื้นฐาน หรือสร้างรายงานเกี่ยวกับรูปแบบประสิทธิภาพ Activity Monitor ไม่เพียงพอ
สำหรับการวิเคราะห์ทางประวัติศาสตร์ ให้ใช้ SQL Serverแผงควบคุมประสิทธิภาพในตัว เหตุการณ์ขยายพร้อมไฟล์ tarได้รับหรือโซลูชันการตรวจสอบจากบุคคลที่สาม
6.4.2 ความต้องการสถิติการรอรายละเอียด
เมื่อคุณต้องการข้อมูลประเภทการรอที่แม่นยำสำหรับการปรับแต่งขั้นสูง การจัดกลุ่มและการกรองของ Activity Monitor ทำให้ข้อมูลดังกล่าวไม่เพียงพอ ให้ใช้แบบสอบถาม DMV โดยตรงหรือใช้ sp_WhoIsActive แทน
หากต้องการวิเคราะห์สถิติการรอที่ครอบคลุม ให้ค้นหา sys.dm_os_wait_stats โดยตรงและกรองการรอที่ไม่เป็นอันตรายออกด้วยตนเอง
6.4.3 ข้อควรพิจารณาเกี่ยวกับเซิร์ฟเวอร์การผลิต
ในเซิร์ฟเวอร์ที่ใช้งานจริงซึ่งมีภาระงานสูง โอเวอร์เฮดของ Activity Monitor อาจเป็นปัญหาได้ ผู้ดูแลระบบฐานข้อมูลหลายคนไม่ควรรัน Activity Monitor พร้อมกันบนเซิร์ฟเวอร์เดียวกัน
สำหรับการติดตามการผลิต โปรดพิจารณาทางเลือกที่น้ำหนักเบา เช่น สแนปช็อต DMV ตามกำหนดเวลาที่เก็บไว้ในฐานข้อมูลการตรวจสอบ หรือใช้การกำหนดเส้นทางแบบอ่านอย่างเดียวเพื่อตรวจสอบแบบจำลองรองในการกำหนดค่าแบบเปิดตลอดเวลา
7. แนวทางปฏิบัติที่ดีที่สุดในการใช้ Activity Monitor
การปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดจะช่วยให้คุณได้รับประโยชน์สูงสุดจาก Activity Monitor พร้อมลดผลกระทบเชิงลบต่อเซิร์ฟเวอร์ของคุณให้น้อยที่สุด
7.1 เมื่อใดจึงควรใช้ Activity Monitor
Activity Monitor โดดเด่นในสถานการณ์เฉพาะเจาะจง ใช้เมื่อจุดแข็งของมันตรงกับความต้องการของคุณ
7.1.1 ปัญหาประสิทธิภาพการทำงานแบบเรียลไทม์
Activity Monitor เหมาะอย่างยิ่งเมื่อผู้ใช้กำลังประสบปัญหาและจำเป็นต้องวินิจฉัยปัญหาทันที มุมมองแบบเรียลไทม์ช่วยให้คุณเห็นสิ่งที่เกิดขึ้นในขณะนั้น
เมื่อคุณได้รับสายแจ้งว่า "แอปพลิเคชันทำงานช้า" การเปิด Activity Monitor ควรเป็นหนึ่งในขั้นตอนแรกๆ ของคุณ คุณสามารถตรวจสอบได้อย่างรวดเร็วว่าฐานข้อมูลกำลังใช้งานอยู่ ติดขัด หรือไม่ได้ใช้งาน
7.1.2 การสอบสวนความล่าช้าของแอปพลิเคชัน
เมื่อแอปพลิเคชันใดแอปพลิเคชันหนึ่งไม่ตอบสนอง Activity Monitor จะช่วยคุณตรวจสอบว่าปัญหาฐานข้อมูลเป็นสาเหตุหรือไม่ กรองบานหน้าต่างกระบวนการตามชื่อแอปพลิเคชันเพื่อดูเฉพาะกิจกรรมฐานข้อมูลของแอปพลิเคชันนั้น
หากแอปพลิเคชันไม่แสดงกิจกรรมฐานข้อมูลในขณะที่ผู้ใช้รายงานปัญหา ปัญหาน่าจะอยู่ที่ส่วนอื่นของสแต็ก หากคุณพบปัญหาการบล็อกหรือคิวรีที่มีค่าใช้จ่ายสูง คุณพบสาเหตุแล้ว
7.1.3 การตรวจสอบสุขภาพอย่างรวดเร็ว
Activity Monitor มอบแดชบอร์ดที่ยอดเยี่ยมสำหรับการตรวจสอบสุขภาพอย่างรวดเร็วระหว่างการใช้งานประจำวัน เปิดดูกราฟภาพรวม แล้วตรวจสอบว่าไม่มีอะไรผิดปกติ
การตรวจสอบแบบผิวเผินนี้ใช้เวลาเพียงไม่กี่วินาที และสามารถเปิดเผยปัญหาได้ก่อนที่จะกลายเป็นปัญหาร้ายแรง ทำให้มันเป็นส่วนหนึ่งของกิจวัตรประจำวันของคุณ
7.2 การตั้งค่าคอนฟิกูเรชันที่เหมาะสมที่สุด
การกำหนดค่า Activity Monitor อย่างเหมาะสมจะช่วยปรับปรุงทั้งประโยชน์และการใช้ทรัพยากร
7.2.1 ช่วงเวลาการรีเฟรชที่แนะนำ
จับคู่ช่วงเวลาการรีเฟรชให้ตรงกับวัตถุประสงค์ของคุณ:
- การแก้ไขปัญหาที่ใช้งานอยู่: 10 วินาทีให้การตอบสนองที่ดีด้วยค่าใช้จ่ายที่สมเหตุสมผล
- การติดตามขยาย: 30-60 วินาทีช่วยลดผลกระทบของเซิร์ฟเวอร์ในช่วงระยะเวลาสังเกตการณ์ที่ยาวนานขึ้น
- การวินิจฉัยปัญหาวิกฤต: 5 วินาทีให้รายละเอียดสูงเมื่อทุกวินาทีมีค่า แต่ใช้เพียงระยะสั้นๆ
- การตรวจสุขภาพประจำปี: รีเฟรชด้วยตนเอง (ช่วงเวลา 1 ชั่วโมง) เมื่อคุณไม่ได้รับชมอยู่
อย่าลืมปิด Activity Monitor เมื่อเสร็จสิ้น การตั้งค่าเป็นช่วงเวลาที่ยาวนานและลืมไปจะทำให้สิ้นเปลืองทรัพยากรเซิร์ฟเวอร์
7.2.2 กลยุทธ์การกรองข้อมูล
ใช้ตัวกรองเพื่อเน้นข้อมูลที่เกี่ยวข้องและลดภาระทางปัญญา:
- กรองกระบวนการตาม ฐานข้อมูล เพื่อดูเฉพาะกิจกรรมที่เกิดขึ้นกับฐานข้อมูลที่เจาะจงเท่านั้น
- กรองตาม เข้าสู่ระบบ เพื่อติดตามกิจกรรมของผู้ใช้ที่เฉพาะเจาะจง
- กรองตาม สถานะงาน = กำลังทำงานเพื่อซ่อนเซสชันที่ไม่ได้ใช้งาน
- กรองตาม การใช้งาน เพื่อแยกการรับส่งข้อมูลจากโปรแกรมเฉพาะ
- แสดงเฉพาะ NonBlanks ใน ถูกบล็อคโดย เพื่อดูเฉพาะสถานการณ์บล็อคเท่านั้น
7.2.3 การเลือกและการเรียงลำดับคอลัมน์
พัฒนาแนวทางที่เป็นระบบในการตรวจสอบข้อมูล Activity Monitor:
- Start พร้อมภาพรวม: ตรวจสอบกราฟเพื่อดูค่าที่พุ่งสูงหรือความผิดปกติที่ชัดเจน
- ตรวจสอบกระบวนการในการบล็อค: เรียงลำดับตาม ID เซสชัน จากนั้นค้นหาค่าที่ถูกบล็อค
- ตรวจสอบทรัพยากรรอ: จัดเรียงตามเวลาการรอสะสมเพื่อระบุคอขวดทรัพยากร
- วิเคราะห์คำถามราคาแพง: จัดเรียงตามเมตริกที่แตกต่างกัน (CPU, การดำเนินการ, การอ่าน) เพื่อค้นหาประเภทปัญหาที่แตกต่างกัน
- ตรวจสอบด้วยบานหน้าต่าง I/O: ยืนยันว่าแบบสอบถามที่ใช้ I/O เข้มข้นมีความสัมพันธ์กับกิจกรรมของดิสก์สูงหรือไม่
7.3 การบูรณาการกับเครื่องมืออื่น ๆ
Activity Monitor ทำงานได้ดีที่สุดเมื่อเป็นส่วนหนึ่งของชุดเครื่องมือที่ครอบคลุมมากกว่าที่จะเป็นโซลูชันแบบสแตนด์อโลน
7.3.1 การใช้ด้วย SQL Server Profiler
เครื่องติดตามกิจกรรมและ SQL Server โปรไฟเลอร์จะเสริมซึ่งกันและกันได้ดี เมื่อคุณระบุเซสชันที่มีปัญหาใน Activity Monitor ให้คลิกขวาที่เซสชันนั้นแล้วเลือก กระบวนการติดตามใน SQL Server Profiler.
การดำเนินการนี้จะเปิดใช้งาน Profiler พร้อมตัวกรองที่กำหนดค่าไว้แล้วเพื่อบันทึกเฉพาะกิจกรรมของเซสชันนั้น คุณจะเห็นลำดับคำสั่งทั้งหมดที่ดำเนินการ ข้อมูลเวลา และข้อความแสดงข้อผิดพลาด ซึ่งเป็นรายละเอียดที่ Activity Monitor ไม่ได้ระบุไว้
หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับ SQL Server ความสามารถของโปรไฟเลอร์และเทคนิคการติดตามขั้นสูง ดูของเรา ครอบคลุม SQL Server คู่มือโปรไฟเลอร์.
7.3.2 การเสริมด้วยกิจกรรมที่ขยายออกไป
Extended Events มอบการตรวจสอบอย่างละเอียดและมีค่าใช้จ่ายต่ำ ซึ่งจะช่วยจับข้อมูลที่ Activity Monitor พลาดไป สร้างเซสชัน Extended Event เพื่อติดตามเหตุการณ์เฉพาะ เช่น เดดล็อก คิวรีที่รันนาน หรือการคอมไพล์ซ้ำที่มากเกินไป
ใช้ Activity Monitor เพื่อตรวจสอบทันที และใช้ Extended Events เพื่อตรวจสอบอย่างต่อเนื่องและวิเคราะห์ข้อมูลย้อนหลัง เครื่องมือทั้งสองนี้ตอบโจทย์ความต้องการที่แตกต่างกัน
หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับ SQL Server ความสามารถของเหตุการณ์ขยายและเทคนิคการตรวจสอบขั้นสูง โปรดดูของเรา ครอบคลุม SQL Server คู่มือกิจกรรมเพิ่มเติม.
7.3.3 โซลูชันการตรวจสอบของบุคคลที่สาม
เครื่องมือเชิงพาณิชย์ เช่น SolarWinds Database Performance Analyzer, Redgate SQL Monitor และ Quest Spotlight มีคุณสมบัติที่ Activity Monitor ขาด ได้แก่ การแจ้งเตือน แนวโน้มในอดีต การวางแผนความจุ และการวินิจฉัยอัตโนมัติostไอซี
เครื่องมือเหล่านี้เป็นส่วนเสริมที่มีคุณค่าสำหรับ Activity Monitor ไม่ใช่สิ่งทดแทน Activity Monitor ยังคงมีประโยชน์สำหรับการตรวจสอบและสืบสวนอย่างรวดเร็ว แม้ว่าจะมีเครื่องมือตรวจสอบที่ซับซ้อนอยู่แล้วก็ตาม
7.4 ข้อผิดพลาดทั่วไปที่ควรหลีกเลี่ยง
การทำความเข้าใจข้อผิดพลาดทั่วไปของ Activity Monitor จะช่วยให้คุณใช้ Activity Monitor ได้อย่างมีประสิทธิภาพมากขึ้น
7.4.1 การปล่อยให้ Activity Monitor ทำงานอย่างต่อเนื่อง
ม.ost ข้อผิดพลาดที่พบบ่อยคือการเปิด Activity Monitor แล้วปล่อยให้มันทำงานไปเรื่อยๆ การกระทำเช่นนี้ทำให้สิ้นเปลืองทรัพยากรเซิร์ฟเวอร์และแทบไม่มีประโยชน์ใดๆ เนื่องจากคุณไม่ได้เฝ้าดูอยู่ตลอดเวลา
ปิด Activity Monitor เมื่อไม่ได้ใช้งาน หากคุณต้องการการตรวจสอบอย่างต่อเนื่อง ให้ใช้โซลูชันการตรวจสอบที่เหมาะสมพร้อมการรวบรวมข้อมูลตามกำหนดเวลาแทน
7.4.2 การพึ่งพา Activity Monitor เพียงอย่างเดียวมากเกินไป
Activity Monitor ให้มุมมองเดียวเกี่ยวกับสุขภาพของเซิร์ฟเวอร์ อย่าพึ่งพามันเพียงอย่างเดียว เสริมด้วย Windows Performance Monitor สำหรับเมตริกระดับระบบปฏิบัติการ Extended Events สำหรับการติดตามอย่างละเอียด และการวิเคราะห์แผนการดำเนินการสำหรับการปรับแต่งคิวรี
Activity Monitor ช่วยให้คุณระบุปัญหาได้ แต่การแก้ไขปัญหามักต้องใช้เครื่องมือเพิ่มเติมและการวิเคราะห์ที่เจาะลึกมากขึ้น
เรียนรู้เพิ่มเติมเกี่ยวกับ SQL Server การตรวจสอบประสิทธิภาพในของเรา คู่มือที่สมบูรณ์.
7.4.3 การละเลยแนวโน้มทางประวัติศาสตร์
Activity Monitor แสดงสถานะปัจจุบัน แต่ปัญหาด้านประสิทธิภาพมักมีรูปแบบที่มองเห็นได้เฉพาะเมื่อเวลาผ่านไปเท่านั้น ใช้งานการรวบรวมข้อมูลในอดีตเพื่อให้คุณสามารถเปรียบเทียบเมตริกปัจจุบันกับค่าพื้นฐานและระบุแนวโน้มได้
หากไม่มีบริบททางประวัติศาสตร์ คุณอาจไม่ตระหนักว่าการใช้งาน CPU "ปกติ" ในปัจจุบันนั้นสูงกว่าค่าพื้นฐานของเดือนที่แล้วถึง 30% ซึ่งบ่งบอกถึงการลดลงอย่างค่อยเป็นค่อยไป
8. การแก้ไขปัญหาการตรวจสอบกิจกรรม
บางครั้ง Activity Monitor เองก็ประสบปัญหา การเรียนรู้วิธีแก้ไขปัญหาเหล่านี้จะช่วยป้องกันไม่ให้เกิดความหงุดหงิด
8.1 Activity Monitor ไม่สามารถเปิดได้หรือไม่แสดงข้อมูลใดๆ
เมื่อ Activity Monitor เปิดขึ้นแต่แสดงบานหน้าต่างว่างเปล่าหรือจะไม่เปิดเลย อาจมีหลายปัจจัยที่ส่งผล
8.1.1 ปัญหาการอนุญาต
ม.ost สาเหตุทั่วไปของปัญหา Activity Monitor คือสิทธิ์การใช้งานไม่เพียงพอ เพื่อตรวจสอบและแก้ไขปัญหา:
- ตรวจสอบสิทธิ์ระดับเซิร์ฟเวอร์ของคุณ:
SELECT * FROM fn_my_permissions(NULL, 'SERVER') WHERE permission_name = 'VIEW SERVER STATE'; - หากไม่มีแถวส่งคืน แสดงว่าคุณไม่มีสิทธิ์ VIEW SERVER STATE
- ขอให้ผู้ดูแลระบบเซิร์ฟเวอร์อนุญาต:
USE master; GRANT VIEW SERVER STATE TO [YourLogin]; - ปิดและเปิด Activity Monitor อีกครั้งหลังจากได้รับอนุญาต
ปัญหาความเข้ากันได้ของเวอร์ชัน 8.1.2
การใช้เวอร์ชันเก่าของ SQL Server Management Studio เพื่อเชื่อมต่อกับระบบใหม่ SQL Server เวอร์ชันนี้อาจทำให้ Activity Monitor ล้มเหลว เครื่องมืออาจไม่เข้าใจประเภทการรอหรือคอลัมน์มุมมองระบบใหม่
ควรใช้ SSMS เวอร์ชันที่ตรงกันหรือใหม่กว่าเสมอ SQL Server เวอร์ชัน Microsoft มอบ SSMS เวอร์ชันล่าสุดให้ดาวน์โหลดฟรีแยกต่างหากจาก SQL Server ตัวเอง
8.1.3 ปัญหาไฟร์วอลล์และเครือข่าย
Activity Monitor จำเป็นต้องเชื่อมต่อกับ SQL Server อินสแตนซ์บนพอร์ตมาตรฐาน (1433 ตามค่าเริ่มต้น) หากคุณสามารถเชื่อมต่อผ่าน Object Explorer ได้ แต่ Activity Monitor ล้มเหลว กฎไฟร์วอลล์อาจบล็อกการเชื่อมต่อบางอย่าง
ตรวจสอบว่าลูกค้าของคุณสามารถเข้าถึง SQL Server เครื่องของคุณอยู่ในพอร์ตที่จำเป็นทั้งหมด ตรวจสอบทั้งไฟร์วอลล์ Windows และไฟร์วอลล์เครือข่ายใดๆ ระหว่างไคลเอนต์และเซิร์ฟเวอร์ของคุณ
8.2 ตัวตรวจสอบกิจกรรมหยุดชั่วคราวถาวร
ปัญหาทั่วไป โดยเฉพาะใน SQL Server ปี 2019 Activity Monitor เปิดในสถานะหยุดชั่วคราวและปฏิเสธที่จะกลับมาทำงานต่อ
8.2.1 การทำความเข้าใจสถานะหยุดชั่วคราว
เมื่อ Activity Monitor หยุดทำงานชั่วคราว บานหน้าต่างทั้งหมดจะแสดงสถานะ "หยุดชั่วคราว" พร้อมปุ่มดำเนินการต่อที่อาจไม่ทำงาน ซึ่งจะทำให้คุณไม่สามารถเห็นกิจกรรมใดๆ ของเซิร์ฟเวอร์ได้
สถานะหยุดชะงักโดยปกติจะเกิดขึ้นเนื่องจากปัญหาสิทธิ์ ข้อจำกัดการเชื่อมต่อระยะไกล หรือข้อบกพร่องของเวอร์ชัน SSMS มากกว่าจะเป็นการหยุดชั่วคราวโดยตั้งใจ
8.2.2 สาเหตุทั่วไป
Activity Monitor อาจเข้าสู่สถานะหยุดชั่วคราวถาวรเนื่องจาก:
- ขาดการอนุญาต VIEW SERVER STATE บนบานหน้าต่างใหม่ที่เพิ่มเข้ามาล่าสุด SQL Server รุ่น
- การเชื่อมต่อระยะไกลถูกปิดใช้งานบน SQL Server ตัวอย่าง
- ความล้มเหลวในการรับรองความถูกต้องสำหรับการค้นหาระบบเฉพาะ
- ข้อบกพร่องในรุ่น SSMS เฉพาะ โดยเฉพาะ 18.0 ถึง 18.3
- ปัญหาการเชื่อมต่อระหว่างไคลเอนต์และเซิร์ฟเวอร์
8.2.3 ขั้นตอนการแก้ไขปัญหา
เพื่อแก้ไขปัญหาสถานะการหยุดชะงักของ Activity Monitor ให้ทำดังนี้:
- อัปเดต SSMS: ดาวน์โหลดและติดตั้งล่าสุด SQL Server เวอร์ชัน Management Studio จากเว็บไซต์ของ Microsoft บั๊กสถานะหยุดชั่วคราวจำนวนมากได้รับการแก้ไขในรุ่นต่อๆ มา
- ตรวจสอบสิทธิ์: ตรวจสอบให้แน่ใจว่าคุณมีสิทธิ์ VIEW SERVER STATE และ VIEW ANY DEFINITION
- ตรวจสอบการเชื่อมต่อระยะไกล: ตรวจสอบว่าได้ SQL Server อินสแตนซ์อนุญาตให้เชื่อมต่อระยะไกล:
EXEC sp_configure 'remote access';หากค่าเป็น 0 ให้ขอให้ผู้ดูแลระบบเปิดใช้งาน
- restarต SSMS: บางครั้งเพียงแค่ปิดหน้าต่างทั้งหมดและปิดtarทิ้ง SQL Server Management Studio แก้ไขปัญหานี้แล้ว
- เชื่อมต่อกับการตรวจสอบสิทธิ์ของ Windows: หากใช้การตรวจสอบสิทธิ์แบบ SQL ให้ลองใช้การตรวจสอบสิทธิ์แบบ Windows แทน เนื่องจากบางครั้งวิธีนี้สามารถหลีกเลี่ยงปัญหาการหยุดชะงักที่เกี่ยวข้องกับการตรวจสอบสิทธิ์ได้
8.3 ปัญหาประสิทธิภาพการทำงานเมื่อใช้ Activity Monitor
หาก Activity Monitor เริ่มทำงานช้าลงหรือทำให้ประสิทธิภาพของเซิร์ฟเวอร์ลดลง จำเป็นต้องมีการปรับเปลี่ยน
8.3.1 การลดค่าใช้จ่ายในการตรวจสอบ
เพื่อลดผลกระทบของ Activity Monitor:
- เพิ่มช่วงเวลาการรีเฟรชเป็น 30 วินาทีหรือ 1 นาที
- ปิดบานหน้าต่างที่คุณไม่ได้ใช้งานโดยคลิกปุ่มยุบ
- เมื่อบานหน้าต่างถูกยุบ Activity Monitor จะไม่สอบถามข้อมูลสำหรับบานหน้าต่างเหล่านั้น
- หลีกเลี่ยงการเรียกใช้ Activity Monitor หลายอินสแตนซ์พร้อมกัน
- ปิด Activity Monitor ทั้งหมดเมื่อไม่ได้ตรวจสอบปัญหาอย่างจริงจัง
8.3.2 วิธีการตรวจสอบน้ำหนักเบาแบบทางเลือก
หาก Activity Monitor ใช้ทรัพยากรมากเกินไปสำหรับสภาพแวดล้อมของคุณ โปรดพิจารณาทางเลือกอื่น:
- สอบถาม DMV โดยตรง: เขียนแบบสอบถาม T-SQL เฉพาะที่ดึงเฉพาะข้อมูลที่คุณต้องการ
- ใช้ sp_WhoIsActive: กระบวนการจัดเก็บนี้ได้รับการปรับให้เหมาะสมอย่างมากและโดยทั่วไปจะมีค่าใช้จ่ายต่ำกว่า Activity Monitor
- ดำเนินการสุ่มตัวอย่าง: กำหนดเวลาการทำงานของ SQL Agent ที่จะจับภาพข้อมูล DMV เป็นระยะๆ และจัดเก็บผลลัพธ์ในตารางเพื่อใช้ในการวิเคราะห์ในภายหลัง
- ตรวจสอบการจำลองรอง: In กลุ่มความพร้อมใช้งานแบบเปิดตลอดเวลาให้เรียกใช้ Activity Monitor กับไดรฟ์สำรองที่สามารถอ่านข้อมูลได้ แทนที่จะเป็นไดรฟ์หลัก
8.4 ข้อมูลไม่ถูกต้องหรือขาดหายไป
บางครั้ง Activity Monitor จะแสดงข้อมูลที่ดูเหมือนไม่ถูกต้องหรือไม่สมบูรณ์
8.4.1 การตรวจสอบข้อมูลกับ DMV
เมื่อผลลัพธ์ของ Activity Monitor ดูน่าสงสัย ให้ตรวจสอบผลลัพธ์โดยการสอบถาม DMV ที่เกี่ยวข้องโดยตรง ตัวอย่างเช่น หากบานหน้าต่างกระบวนการไม่แสดงการบล็อก แต่ผู้ใช้รายงาน ให้สอบถามดังนี้
SELECT
blocking_session_id,
session_id,
wait_type,
wait_time,
wait_resource
FROM sys.dm_exec_requests
WHERE blocking_session_id != 0;
หากแบบสอบถามนี้แสดงการบล็อกที่ Activity Monitor มองข้ามไป แสดงว่าคุณได้รับการยืนยันว่ามีปัญหาด้านการแสดงผล
8.4.2 การทำความเข้าใจเกี่ยวกับเวลาการรีเฟรชข้อมูล
โปรดจำไว้ว่า Activity Monitor จะแสดงสแนปช็อต คิวรีที่รันระหว่างช่วงรีเฟรชจะไม่ปรากฏในคิวรีแบบ Expensive ล่าสุด เว้นแต่แผนการดำเนินการจะยังคงอยู่ในแคช
ในทำนองเดียวกัน สถิติการรอในบานหน้าต่าง "การรอทรัพยากร" จะแสดงการสะสมนับตั้งแต่สแนปช็อตครั้งล่าสุด ภาระงานที่เปลี่ยนแปลงอย่างรวดเร็วอาจแสดงรูปแบบที่แตกต่างกันในแต่ละครั้งที่รีเฟรช
9. เทคนิคการตรวจสอบกิจกรรมขั้นสูง
ผู้ดูแลระบบฐานข้อมูลที่มีประสบการณ์ใช้ Activity Monitor ในรูปแบบที่ซับซ้อนเพื่อดึงข้อมูลการวินิจฉัยสูงสุดostค่าไอซี
9.1 การรวมบานหน้าต่างหลายบานเพื่อวิเคราะห์สาเหตุหลัก
พลังที่แท้จริงของ Activity Monitor จะปรากฏขึ้นเมื่อคุณเชื่อมโยงข้อมูลข้ามบานหน้าต่างหลายบานเพื่อทำความเข้าใจปัญหาประสิทธิภาพการทำงานที่ซับซ้อน
9.1.1 การเชื่อมโยงการรอคอยกับกระบวนการ
เมื่อบานหน้าต่างการรอทรัพยากรแสดงเวลาการรอที่สูงในหมวดหมู่ ให้ใช้บานหน้าต่างกระบวนการเพื่อระบุเซสชันที่กำลังประสบกับการรอดังกล่าว:
- สังเกตหมวดหมู่การรอที่มีเวลาการรอสะสมสูง (เช่น "ล็อค")
- สลับไปที่บานหน้าต่างกระบวนการ
- เรียงลำดับตาม ประเภทการรอ เพื่อจัดกลุ่มเซสชันตามเวลาที่รอในปัจจุบัน
- ค้นหาเซสชันที่แสดงประเภทการรอในหมวดหมู่ที่มีปัญหา
- สำหรับเซสชันเหล่านั้น ให้ตรวจสอบ รอทรัพยากร คอลัมน์เพื่อดูว่ามีวัตถุฐานข้อมูลใดเกี่ยวข้อง
- คลิกขวาและเลือก รายละเอียด เพื่อดูข้อความสอบถาม
ความสัมพันธ์นี้ช่วยให้คุณเปลี่ยนจาก "เรามีการรอล็อค" ไปเป็น "แบบสอบถามเฉพาะนี้กำลังรอล็อคบนตารางนี้"
9.1.2 การเชื่อมโยงแบบสอบถามราคาแพงกับปัญหา I/O
เมื่อบานหน้าต่าง Data File I/O แสดงกิจกรรมดิสก์สูงบนฐานข้อมูลเฉพาะ:
- สังเกตว่าไฟล์ฐานข้อมูลใดมีอัตราการอ่านหรือเขียนสูง MB/วินาที
- เปลี่ยนไปใช้การค้นหาราคาแพงล่าสุด
- เรียงลำดับตาม การอ่านทางกายภาพ/วินาที เพื่อระบุแบบสอบถามที่อ่านจากดิสก์จำนวนมาก
- กรองหรือระบุแบบสอบถามที่ทำงานกับฐานข้อมูลที่มี I/O สูงด้วยภาพ
- ตรวจสอบแผนการดำเนินการของแบบสอบถามเหล่านั้นสำหรับการสแกนตารางหรือดัชนีที่หายไปซึ่งทำให้เกิด I/O มากเกินไป
การวิเคราะห์หลายบานหน้าต่างนี้เชื่อมโยงอาการ (I/O ของดิสก์สูง) กับสาเหตุ (แบบสอบถามที่ไม่มีประสิทธิภาพเฉพาะเจาะจง)
9.2 การใช้ Activity Monitor เพื่อการวางแผนกำลังการผลิต
แม้ว่า Activity Monitor จะไม่จัดเก็บข้อมูลในประวัติ แต่คุณสามารถใช้ Activity Monitor เพื่อสังเกตการณ์การวางแผนความจุได้อย่างมีกลยุทธ์
9.2.1 การระบุรูปแบบการใช้งานสูงสุด
ตรวจสอบกิจกรรมเซิร์ฟเวอร์ในเวลาต่างๆ ของวันเพื่อระบุรูปแบบการใช้งาน:
- เปิด Activity Monitor ในช่วงเวลาทำการที่มีผู้ใช้งานสูงสุดตามที่ทราบ
- สังเกตค่าสูงสุดของกราฟ % เวลาของโปรเซสเซอร์
- บันทึกจำนวนงานรอสูงสุด
- สังเกตคำขอแบบชุดต่อวินาทีในช่วงเวลาเร่งด่วน
- บันทึกฐานข้อมูลที่ยุ่งที่สุดในบานหน้าต่างกระบวนการ
- ทำซ้ำในช่วงนอกชั่วโมงเร่งด่วนเพื่อการเปรียบเทียบ
หากเวลาประมวลผลของโปรเซสเซอร์ในช่วงพีคเกิน 80% อย่างต่อเนื่อง แสดงว่าคุณกำลังใกล้ถึงขีดจำกัดความจุของ CPU เช่นเดียวกัน จำนวนการรอที่เพิ่มขึ้นบ่งชี้ถึงการแย่งชิงทรัพยากรที่เพิ่มขึ้น
9.2.2 การวิเคราะห์แนวโน้มทรัพยากร
ในขณะที่ Activity Monitor แสดงสถานะปัจจุบัน คุณสามารถใช้มันเพื่อตรวจสอบแนวโน้มโดยการบันทึกค่าเมตริกสำคัญในช่วงเวลาต่างๆ:
- ถ่ายภาพหน้าจอของบานหน้าต่างภาพรวมในเวลาเดียวกันทุกวัน
- บันทึกค่าสูงสุดจากกราฟแต่ละกราฟ
- เปรียบเทียบแบบสัปดาห์ต่อสัปดาห์เพื่อระบุแนวโน้มการเติบโต
- สังเกตการเพิ่มขึ้นอย่างค่อยเป็นค่อยไปของเวลาประมวลผลเฉลี่ยหรืออัตรา I/O
คู่มือแนวโน้มนี้เสริมโซลูชันการตรวจสอบที่ซับซ้อนยิ่งขึ้นและช่วยพิสูจน์การขยายกำลังการผลิต
9.3 การบันทึกข้อมูลพื้นฐานประสิทธิภาพ
การกำหนดมาตรวัดประสิทธิภาพพื้นฐานจะช่วยให้คุณรับรู้เมื่อประสิทธิภาพลดลง
9.3.1 การจับค่าเมตริกพื้นฐาน
ในช่วงเวลาที่ทราบประสิทธิภาพที่ดี ให้บันทึกข้อมูลเมตริกของ Activity Monitor:
- เปิดตัวตรวจสอบกิจกรรมระหว่างการดำเนินธุรกิจปกติ (ไม่ใช่ช่วงพีคหรือช่วงนอกพีค)
- ค่าบานหน้าต่างภาพรวมบันทึก:
- ช่วงเวลาของโปรเซสเซอร์โดยทั่วไป %
- จำนวนงานรอเฉลี่ย
- อัตรา I/O ของฐานข้อมูลปกติ
- คำขอชุดทั่วไป/วินาที
- หมายเหตุหมวดหมู่บานหน้าต่างการรอทรัพยากรที่แสดง most รอเวลา.
- บันทึกจำนวนกระบวนการที่ใช้งานอยู่โดยทั่วไปในบานหน้าต่างกระบวนการ
- บันทึกค่าเมตริกการดำเนินการสอบถามตัวแทนจากแบบสอบถามราคาแพงล่าสุด
จัดเก็บเอกสารพื้นฐานนี้ไว้เพื่อใช้อ้างอิงในอนาคตเมื่อตรวจสอบปัญหาประสิทธิภาพการทำงาน
9.3.2 การเปรียบเทียบประสิทธิภาพปัจจุบันกับประสิทธิภาพพื้นฐาน
เมื่อเกิดปัญหาประสิทธิภาพ ให้เปรียบเทียบค่าการอ่าน Activity Monitor ปัจจุบันกับค่าพื้นฐานที่บันทึกไว้:
- เวลาประมวลผลสูงกว่าค่าพื้นฐานอย่างเห็นได้ชัดหรือไม่? เน้นที่การค้นหาที่ใช้ CPU หนักๆ
- งานที่กำลังรออยู่มีระดับพื้นฐาน 2-3 เท่าหรือไม่ ตรวจสอบการรอทรัพยากร
- I/O สูงขึ้นอย่างเห็นได้ชัดหรือไม่? ตรวจสอบแผง I/O ของไฟล์ข้อมูลและแบบสอบถามราคาแพง
- คำขอแบบกลุ่มมีจำนวนต่ำกว่าเกณฑ์มาตรฐานในช่วงชั่วโมงเร่งด่วนหรือไม่? มองหาปัญหาการบล็อกหรือการเชื่อมต่อ
การเปรียบเทียบนี้ช่วยให้คุณระบุสิ่งที่เปลี่ยนแปลงไปและมุ่งเน้นความพยายามในการแก้ไขปัญหาได้อย่างเหมาะสม
9.4 การสร้างเวิร์กโฟลว์การตรวจสอบแบบกำหนดเอง
พัฒนากระบวนการทำงานอย่างเป็นระบบสำหรับสถานการณ์การสอบสวนทั่วไปเพื่อให้แน่ใจว่าการวิเคราะห์สามารถทำซ้ำได้อย่างละเอียดถี่ถ้วน
9.4.1 กระบวนการสืบสวนแบบทีละขั้นตอน
เมื่อผู้ใช้รายงานปัญหาประสิทธิภาพ ให้ปฏิบัติตามเวิร์กโฟลว์ที่สอดคล้องกัน:
- ตรวจสุขภาพด่วน: เปิดตัวตรวจสอบกิจกรรมและสแกนกราฟแผงภาพรวมเพื่อหาความผิดปกติที่เห็นได้ชัด
- ตรวจสอบการบล็อค: ขยายบานหน้าต่างกระบวนการ กรองสำหรับ NonBlanks ในคอลัมน์ที่ถูกบล็อคโดย
- ระบุการแย่งชิงทรัพยากร: ตรวจสอบแผงการรอทรัพยากรที่เรียงลำดับตามเวลาการรอ
- ค้นหาคำถามราคาแพง: ตรวจสอบแบบสอบถามราคาแพงล่าสุดที่จัดเรียงตาม CPU จากนั้นการดำเนินการ และการอ่าน
- เชื่อมโยงรูปแบบ I/O: การอ้างอิงแบบไขว้แบบสอบถามราคาแพงกับกิจกรรมบานหน้าต่าง I/O ของไฟล์ข้อมูล
- การค้นพบเอกสาร: จับภาพหน้าจอและบันทึก ID เซสชันที่เกี่ยวข้อง ประเภทการรอ และรายละเอียดแบบสอบถาม
- ดำน้ำลึก: ใช้การติดตามโปรไฟล์ การวิเคราะห์แผนการดำเนินการ และแบบสอบถาม DMV เพื่อตรวจสอบปัญหาที่ระบุโดยละเอียด
9.4.2 เกณฑ์การยกระดับ
กำหนดเกณฑ์ในการตัดสินใจว่าเมื่อใดควรยกระดับปัญหาหรือดำเนินการสืบสวนต่อไป:
- เพิ่มระดับทันที: การบล็อคเชนที่กินเวลานานกว่า 5 นาที โปรเซสเซอร์ใช้เวลา 100% นานมากกว่า 2 นาที กระบวนการระบบที่สำคัญแสดงสถานะระงับ
- ยกระดับด้วยการวิเคราะห์: การค้นหาซ้ำๆ ที่มีต้นทุนสูงซึ่งใช้ CPU มากกว่า 50%, เวลาตอบสนอง I/O สูงสม่ำเสมอมากกว่า 50ms, การอนุญาตหน่วยความจำล้มเหลวซ้ำแล้วซ้ำเล่า
- สืบสวนเพิ่มเติม: จังหวะrary รอการแก้ไขภายในไม่กี่นาที สอบถามด้วยแผนที่ไม่เหมาะสมแต่มีประสิทธิภาพที่ยอมรับได้ มีการบล็อกเล็กน้อยซึ่งมีระยะเวลาน้อยกว่า 30 วินาที
10. เครื่องติดตามกิจกรรมในที่ต่างๆ SQL Server รุ่น
Activity Monitor ได้รับการพัฒนาแล้ว SQL Server เวอร์ชันต่างๆ โดยแต่ละเวอร์ชันจะมีการปรับปรุงและปัญหาใหม่ๆ ตามมาเป็นครั้งคราว
10.1 เครื่องตรวจสอบกิจกรรมใน SQL Server 2008 และใหม่กว่า
SQL Server ในปี 2008 ได้มีการเปิดตัวการออกแบบ Activity Monitor ที่ทันสมัยซึ่งแทบจะไม่มีการเปลี่ยนแปลงใดๆ เลยจนถึงปัจจุบัน
10.1.1 คุณสมบัติใหม่ที่เปิดตัวใน SQL Server 2008
การขอ SQL Server การออกแบบ Activity Monitor ใหม่ในปี 2008 นำมาซึ่งการปรับปรุงที่สำคัญ:
- แดชบอร์ดกราฟิกพร้อมแผนภูมิแบบเรียลไทม์ในบานหน้าต่างภาพรวม
- อินเทอร์เฟซบานหน้าต่างแบบขยาย/ยุบได้แทนที่มุมมองแบบกริดอย่างเดียวแบบเดิม
- แผงการค้นหาข้อมูลราคาแพงล่าสุดแสดงข้อมูลประสิทธิภาพการค้นหาโดยรวม
- แผง I/O ไฟล์ข้อมูลสำหรับการตรวจสอบกิจกรรมของดิสก์แต่ละไฟล์
- แผงการรอทรัพยากรที่ปรับปรุงพร้อมการจัดหมวดหมู่การรอ
- คลิกขวาเมนูบริบทสำหรับการดำเนินการกระบวนการ เช่น การหยุดเซสชันและการเปิดตัว Profiler
- ช่วงเวลาการรีเฟรชที่กำหนดค่าได้ตั้งแต่ 1 วินาทีถึง 1 ชั่วโมง
การเปลี่ยนแปลงเหล่านี้ได้เปลี่ยน Activity Monitor จากรายการกระบวนการที่เรียบง่ายไปเป็นแดชบอร์ดการตรวจสอบที่ครอบคลุม
10.1.2 การเปลี่ยนแปลงจาก SQL Server 2005
SQL Server Activity Monitor ปี 2005 มีข้อจำกัดมากกว่ามาก:
- เข้าถึงได้ผ่านโฟลเดอร์การจัดการใน Object Explorer แทนแถบเครื่องมือ
- ตารางเดี่ยวแสดงรายการกระบวนการพร้อมข้อมูลพื้นฐาน
- ไม่มีแผนภูมิกราฟิกหรือหลายบานหน้าต่าง
- ไม่ต้องสอบถามราคาแพงหรือตรวจสอบ I/O
- ข้อมูลสถิติการรอแบบจำกัด
การออกแบบใหม่ในปี 2008 ถือเป็นการคิดใหม่ทั้งหมด ไม่ใช่การปรับปรุงทีละเล็กทีละน้อย
10.2 เครื่องตรวจสอบกิจกรรมใน SQL Server 2014/2016
SQL Server ปี 2014 และ 2016 ได้มีการปรับปรุงการรวบรวมข้อมูลพื้นฐานของ Activity Monitor เล็กน้อย แต่มีการเปลี่ยนแปลงทางภาพเพียงเล็กน้อย
10.2.1 การปรับปรุงและเพิ่มประสิทธิภาพ
การปรับปรุงที่สำคัญในเวอร์ชันเหล่านี้ ได้แก่ :
- ประสิทธิภาพที่ดีขึ้นเมื่อตรวจสอบเซิร์ฟเวอร์ด้วยแผนการแคชนับพันรายการ
- ปรับปรุงความสามารถในการกรองในบานหน้าต่างกระบวนการ
- ปรับปรุงความแม่นยำของการรวบรวมสถิติการรอ
- การจัดการการเรียงลำดับและการกรองคอลัมน์ที่ดีขึ้นด้วยชุดผลลัพธ์ขนาดใหญ่
- การสอบถาม DMV ที่มีประสิทธิภาพมากขึ้นช่วยลดค่าใช้จ่ายในการตรวจสอบ
อินเทอร์เฟซหลักยังคงสอดคล้องกัน SQL Server 2008 รักษาความคุ้นเคยให้กับผู้ดูแลระบบ
10.3 เครื่องตรวจสอบกิจกรรมใน SQL Server 2019/2022
เมื่อเร็ว ๆ นี้ SQL Server เวอร์ชันต่างๆ ยังคงพัฒนา Activity Monitor ต่อไป โดยเน้นที่ประสิทธิภาพและความเสถียร
10.3.1 คุณสมบัติและความสามารถล่าสุด
SQL Server Activity Monitor ปี 2019 และ 2022 ประกอบด้วย:
- รองรับประเภทการรอแบบใหม่ที่เปิดตัวในเวอร์ชันเหล่านี้
- ปรับปรุงประสิทธิภาพการเรนเดอร์ใน SSMS โดยใช้เทคโนโลยี WPF
- การจัดการเซสชันที่ใช้งานจำนวนมากได้ดีขึ้น
- ปรับปรุงความเข้ากันได้กับแพลตฟอร์ม SQL บนคลาวด์
- เมตริก CPU และ I/O ที่แม่นยำยิ่งขึ้น
10.3.2 ปัญหาที่ทราบในเวอร์ชันล่าสุด
SQL Server ปี 2019 ได้แนะนำข้อบกพร่องหลายประการของ Activity Monitor:
- สถานะหยุดชั่วคราวถาวร: ตัวตรวจสอบกิจกรรมเข้าสู่สถานะหยุดชั่วคราวบ่อยครั้งและจะไม่กลับมาทำงานต่อ โดยเฉพาะใน SSMS 18.0-18.3 ได้รับการแก้ไขแล้วใน SSMS เวอร์ชันหลังๆ
- ความล้มเหลวในการเชื่อมต่อระยะไกล: การกำหนดค่าบางอย่างป้องกันไม่ให้ Activity Monitor เปิดขึ้นบนอินสแตนซ์ระยะไกล วิธีแก้ปัญหาชั่วคราว ได้แก่ การเปิดใช้งานแฟล็กการติดตามเฉพาะ หรือการใช้ SSMS รุ่นใหม่กว่า
- ปัญหาการอนุญาต: มุมมองระบบใหม่ต้องมีสิทธิ์เพิ่มเติมที่ไม่ได้ระบุไว้อย่างชัดเจน ส่งผลให้มีการแสดงผลว่างเปล่าแม้จะใช้ VIEW SERVER STATE ก็ตาม
ใช้ SSMS เวอร์ชันล่าสุดเสมอเมื่อทำงานกับ SQL Server ปี 2019 และ 2022 เพื่อหลีกเลี่ยงปัญหาเหล่านี้
11. กรณีการใช้งานจริงและตัวอย่าง
ตัวอย่างในโลกแห่งความเป็นจริงแสดงให้เห็นถึงวิธีการใช้ Activity Monitor อย่างมีประสิทธิผลในสถานการณ์การแก้ไขปัญหาทั่วไป
11.1 กรณีศึกษา: การวินิจฉัยแอปพลิเคชันเว็บที่ช้า
ทีมพัฒนาได้รายงานว่าเว็บแอปพลิเคชันของพวกเขาช้าลงอย่างไม่สามารถยอมรับได้ โดยหน้าเพจโหลดใช้เวลาเพียง 20-30 วินาที แทนที่จะเป็น 2-3 วินาทีตามปกติ
11.1.1 การสอบสวนเบื้องต้นพร้อมแผงภาพรวม
เปิดตัวตรวจสอบกิจกรรมและตรวจสอบบานหน้าต่างภาพรวม:
- กราฟเปอร์เซ็นต์เวลาที่โปรเซสเซอร์ใช้งานแสดงการใช้งาน CPU อยู่ที่ 85-95% สูงกว่าค่าพื้นฐานปกติที่ 30-40% อย่างมาก
- งานที่รอจะผันผวนระหว่าง 10-20 งาน ในขณะที่ปกติจะอยู่ที่ 0-3 งาน
- ฐานข้อมูล I/O แสดงกิจกรรมปานกลางที่ประมาณ 50 MB/วินาที
- คำขอแบบชุดต่อวินาทีต่ำกว่าที่คาดไว้ที่ 100 ต่อวินาที เมื่อเทียบกับ 300-400 ต่อวินาทีโดยทั่วไปในช่วงเวลาทำการ
รูปแบบนี้บ่งชี้ถึงปัญหาคอขวดของ CPU ที่มีการแข่งขันทรัพยากร ทำให้ทรูพุตลดลง เซิร์ฟเวอร์กำลังทำงานอย่างหนักแต่ไม่ได้ประมวลผลคำขอจำนวนมาก
11.1.2 การระบุคำถามที่มีปัญหา
ขยายบานหน้าต่างแบบสอบถามราคาแพงล่าสุดและเรียงลำดับตามการดำเนินการ/นาที:
- แบบสอบถามด้านบนแสดงการดำเนินการ 15,000 ครั้งต่อนาที
- คลิกขวาและเลือก แก้ไขข้อความสอบถาม เพื่อตรวจสอบการสอบถาม
- แบบสอบถามเป็นคำสั่ง SELECT ง่ายๆ ที่ดึงข้อมูลผู้ใช้รายเดียว:
SELECT * FROM Users WHERE UserId = @UserId. - ไม่ควรมีการดำเนินการคิวรีนี้ 15,000 ครั้งต่อนาทีสำหรับการใช้งานแอปพลิเคชันทั่วไป
คลิกขวาที่แบบสอบถามและเลือก แสดงแผนการดำเนินการแผนนี้แสดงการสแกนตารางบนตารางผู้ใช้พร้อมคำเตือนเกี่ยวกับดัชนีที่หายไปในคอลัมน์ UserId
กรองบานหน้าต่างกระบวนการตามแอปพลิเคชันเพื่อแสดงเฉพาะการเชื่อมต่อของเว็บแอปพลิเคชัน เซสชันหลายเซสชันจะแสดงคิวรีเดียวกันนี้ทำงานซ้ำๆ กัน
11.1.3 การแก้ไขและการตรวจสอบ
ปัญหาเกิดจากสองประเด็น ได้แก่ การดำเนินการค้นหาที่มากเกินไป และดัชนีที่หายไป ขั้นตอนการแก้ไข:
- สร้างดัชนีที่หายไป:
CREATE NONCLUSTERED INDEX IX_Users_UserId ON Users (UserId); - ติดต่อทีมพัฒนา เกี่ยวกับการดำเนินการที่มากเกินไป การตรวจสอบพบปัญหาคิวรี N+1 ในโค้ดแอปพลิเคชัน ซึ่งลูปจะดึงข้อมูลรายละเอียดผู้ใช้สำหรับแต่ละรายการในรายการ
- ปรับเปลี่ยนการใช้งาน เพื่อแบตช์การค้นหาผู้ใช้เป็นแบบสอบถามเดียวโดยใช้คำสั่ง IN หรือพารามิเตอร์ค่าตาราง
- ตรวจสอบการแก้ไข โดยการตรวจสอบ Activity Monitor หลังการปรับใช้ การใช้งาน CPU ลดลงเหลือ 35-40% การดำเนินการต่อนาทีลดลงเหลือ 200-300 และเวลาตอบสนองของแอปพลิเคชันกลับสู่ปกติ
11.2 กรณีศึกษา: การแก้ไขปัญหาการบล็อก
ผู้ใช้รายงานว่าระบบการป้อนคำสั่งซื้อจะหยุดทำงานเป็นระยะๆ เป็นเวลา 30-60 วินาที ก่อนที่จะกลับมาดำเนินการตามปกติ
11.2.1 การตรวจจับโซ่การบล็อก
เปิดตัวตรวจสอบกิจกรรมระหว่างเหตุการณ์หยุดการทำงานเหล่านี้และขยายบานหน้าต่างกระบวนการ:
- เรียงลำดับตาม รหัสเซสชัน เพื่อดูเซสชันทั้งหมดที่จัดไว้
- เซสชันหลายรายการแสดงค่าใน ถูกบล็อคโดย คอลัมน์ทั้งหมดชี้ไปที่ ID เซสชัน 73
- เซสชั่นที่ 73 แสดง '1' ใน บล็อกเกอร์หัว คอลัมน์ยืนยันว่าเป็นสาเหตุหลัก
- การขอ ประเภทการรอ สำหรับเซสชันที่ถูกบล็อคจะแสดง LCK_M_X ซึ่งระบุว่าเซสชันดังกล่าวกำลังรอการล็อคแบบพิเศษ
- การขอ รอทรัพยากร คอลัมน์แสดงให้เห็นว่าการบล็อคอยู่บนตารางคำสั่งซื้อ
11.2.2 การวิเคราะห์สาเหตุ
คลิกขวาที่เซสชัน 73 และเลือก รายละเอียด เพื่อดูคำสั่ง:
UPDATE Orders
SET Status = 'Processing',
LastModified = GETDATE()
WHERE OrderId IN (SELECT OrderId FROM #TempOrders);
การอัปเดตนี้เป็นส่วนหนึ่งของงานประมวลผลแบบแบตช์ที่ทำงานเป็นรายชั่วโมง การตรวจสอบ เข้าสู่ระบบ คอลัมน์ยืนยันว่าเซสชันเป็นของบัญชีบริการการประมวลผลแบบแบตช์
แบบสอบถามกำลังล็อคตารางคำสั่งซื้อขณะประมวลผลคำสั่งซื้อหลายพันรายการ รอเวลา สำหรับเซสชันที่ถูกบล็อคจะเพิ่มขึ้นอย่างต่อเนื่อง ยืนยันว่าการดำเนินการระยะยาวนี้คือปัญหา
11.2.3 การดำเนินการแก้ไข
การแก้ไขปัญหาในระยะสั้น:
- รายละเอียดของเอกสารเซสชันที่ 73 รวมถึงข้อความสอบถามและระยะเวลา
- อนุญาตให้การอัปเดตเสร็จสมบูรณ์โดยธรรมชาติเนื่องจากเป็นการประมวลผลแบบแบตช์ที่ถูกต้องตามกฎหมาย
- หลังจากเสร็จสิ้น ให้ตรวจสอบว่าเซสชันที่ถูกบล็อคได้รับการเคลียร์และสามารถกลับมาดำเนินการตามปกติ
แนวทางแก้ไขระยะยาวที่นำไปปฏิบัติ:
- กำหนดเวลาการทำงานแบบแบตช์ใหม่ ให้ดำเนินการในช่วงนอกเวลาเร่งด่วน (ตี 2-ตี 4 แทนที่จะเป็นช่วงเวลาทำการ)
- ปรับเปลี่ยนการประมวลผลแบบแบตช์ เพื่ออัปเดตคำสั่งซื้อเป็นชุดย่อยครั้งละ 100 รายการ โดยปลดล็อคระหว่างชุด
- เพิ่มดัชนี ในคอลัมน์ OrderId เพื่อเพิ่มความเร็วในการดำเนินการอัปเดต
- พิจารณาการแยก SNAPSHOT สำหรับการดำเนินการอ่านเพื่อลดผลกระทบจากการบล็อค
11.3 กรณีศึกษา: การระบุการดำเนินการแบบสอบถามที่มากเกินไป
การตรวจสอบฐานข้อมูลแสดงให้เห็นว่าการใช้งาน CPU เพิ่มขึ้นเรื่อยๆ ในช่วงเดือนที่ผ่านมา แต่ไม่มีการเปลี่ยนแปลงที่ชัดเจนเกิดขึ้นในโค้ดแอปพลิเคชัน
11.3.1 การตรวจจับจำนวนการดำเนินการที่ผิดปกติ
เปิดตัวตรวจสอบกิจกรรมและตรวจสอบบานหน้าต่างแบบสอบถามราคาแพงล่าสุด:
- เรียงลำดับตาม การดำเนินการ/นาที เพื่อดูม.ost แบบสอบถามที่ดำเนินการบ่อยครั้ง
- แบบสอบถามยอดนิยมแสดงการดำเนินการ 37,000 ครั้งต่อนาที ซึ่งสูงกว่าแบบสอบถามอื่นๆ มาก
- คลิกขวาและเลือก แก้ไขข้อความสอบถาม.
- แบบสอบถามดึงข้อมูลหมวดหมู่ผลิตภัณฑ์:
SELECT CategoryId, CategoryName FROM ProductCategories WHERE CategoryId = @CategoryId; - แบบสอบถามง่ายๆ นี้ควรจะรวดเร็วและสามารถแคชได้ แต่กลับมีการดำเนินการหลายหมื่นครั้งต่อนาที
11.3.2 การติดตามไปยังรหัสแอปพลิเคชัน
ในบานหน้าต่างกระบวนการ ค้นหาเซสชันที่ดำเนินการแบบสอบถามนี้:
- หมายเหตุ การใช้งาน คอลัมน์แสดง “ProductCatalogService”
- คลิกขวาที่เซสชันเหล่านี้และเลือก กระบวนการติดตามใน SQL Server Profiler.
- SQL Profiler แสดงให้เห็นว่าแบบสอบถามดำเนินการซ้ำๆ อย่างรวดเร็วโดยมีค่า CategoryId ที่แตกต่างกัน
- ติดต่อทีมพัฒนาที่จัดการ ProductCatalogService เพื่อตรวจสอบโค้ด
การตรวจสอบโค้ดเผยให้เห็นปัญหา: การเปลี่ยนแปลงล่าสุดดึงข้อมูลรายการสินค้าพร้อมหมวดหมู่ สำหรับสินค้าแต่ละรายการในชุดผลลัพธ์ (ซึ่งมักจะมีมากกว่า 1,000 รายการ) โค้ดจะเรียกฐานข้อมูลแยกต่างหากเพื่อดึงข้อมูลหมวดหมู่ ซึ่งเป็นปัญหาคิวรี N+1 แบบคลาสสิก
11.3.3 การเพิ่มประสิทธิภาพแอปพลิเคชัน
ดำเนินการแก้ไขอย่างเหมาะสม:
- ปรับเปลี่ยนแบบสอบถามการใช้งาน ในการใช้ JOIN เพื่อดึงข้อมูลผลิตภัณฑ์และหมวดหมู่ในฐานข้อมูลเดียว ให้เรียกดังนี้:
SELECT p.ProductId, p.ProductName, c.CategoryId, c.CategoryName FROM Products p INNER JOIN ProductCategories c ON p.CategoryId = c.CategoryId WHERE p.Active = 1; - ปรับใช้โค้ดที่อัปเดต และตรวจสอบกิจกรรมการตรวจสอบ
- ตรวจสอบการแก้ไข: การดำเนินการต่อนาทีสำหรับการสอบถามหมวดหมู่ลดลงจาก 37,000 เหลือต่ำกว่า 100 และการใช้งาน CPU โดยรวมลดลง 40%
- บันทึกบทเรียนที่ได้รับ และแบ่งปันกับทีมพัฒนาเพื่อป้องกันปัญหาที่คล้ายกันในการเปลี่ยนแปลงโค้ดในอนาคต
12. ตรวจจับความเสียหายของฐานข้อมูลที่อาจเกิดขึ้น
แม้ว่า Activity Monitor จะไม่ได้รับการออกแบบมาโดยเฉพาะเพื่อตรวจจับความเสียหายของฐานข้อมูล แต่รูปแบบบางอย่างในการแสดงผลอาจบ่งชี้ถึงปัญหาความเสียหายพื้นฐานที่จำเป็นต้องมีการตรวจสอบเพิ่มเติม
12.1 อาการของการเสียหายของฐานข้อมูลที่อาจเกิดขึ้น
หากฐานข้อมูลเสียหายและมีการเข้าถึง คุณอาจเห็นเป็นครั้งคราว:
1. ในบานหน้าต่างกระบวนการ:
- เซสชันติดอยู่ในสถานะระงับโดยมีประเภทการรอที่ผิดปกติ
- กระบวนการแสดงสถานะข้อผิดพลาด
- การค้นหาล้มเหลวซ้ำแล้วซ้ำเล่า
2. ในบานหน้าต่างการรอทรัพยากร:
- ประเภทการรอที่เกี่ยวข้องกับ I/O ที่ผิดปกติซึ่งอาจบ่งชี้ถึงปัญหาของดิสก์ (แม้ว่าสิ่งนี้อาจบ่งชี้ถึงปัญหาฮาร์ดแวร์มากกว่าความเสียหายทางตรรกะ)
3. ในคำถามราคาแพงล่าสุด:
- การค้นหาที่มีการอ่านทางกายภาพสูงผิดปกติหากพยายามอ่านหน้าที่เสียหายซ้ำๆ
12.2 ตรวจสอบเพิ่มเติมกับ DBCC CHECKDB
เมื่อ Activity Monitor แสดงอาการที่บ่งชี้ถึงความเสียหายที่อาจเกิดขึ้น คุณควรเรียกใช้ DBCC CHECKDB ทันทีเพื่อตรวจสอบความสมบูรณ์ของฐานข้อมูล คำสั่งนี้จะสแกนหน้าฐานข้อมูลทั้งหมด ตรวจสอบความถูกต้องของค่า checksum และตรวจสอบข้อผิดพลาดด้านความสอดคล้องเชิงตรรกะ
หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับวิธีใช้ DBCC CHECKDB เพื่อตรวจสอบและแก้ไขความเสียหายของฐานข้อมูล โปรดดู คู่มือ DBCC CHECKDB ที่ครอบคลุม.
12.3 การซ่อมแซมด้วยเครื่องมือระดับมืออาชีพ
หาก DBCC CHECKDB ยืนยันว่าฐานข้อมูลเสียหาย คุณมีตัวเลือกหลายประการสำหรับการซ่อมแซม:
- แนวทางที่แนะนำคือการคืนค่าจากการสำรองข้อมูลที่ทราบว่าดี ดู คู่มือครอบคลุมของเราเกี่ยวกับวิธีการสำรองข้อมูลและคืนค่า SQL Server ฐานข้อมูล.
- สำหรับความเสียหายเล็กน้อย การใช้ DBCC CHECKDB พร้อม REPAIR_REBUILD อาจแก้ไขปัญหาได้
- สำหรับฐานข้อมูลที่สำคัญที่ไม่มีการสำรองข้อมูลล่าสุด มืออาชีพ ซอฟต์แวร์กู้คืน SQL และบริการต่างๆ มักจะสามารถกู้คืนข้อมูลที่ตัวเลือกการซ่อมแซมในตัวไม่สามารถทำได้
13 ข้อสรุป
SQL Server Activity Monitor เป็นเครื่องมืออันล้ำค่าสำหรับผู้ดูแลระบบฐานข้อมูล โดยให้ข้อมูลเชิงลึกทันทีเกี่ยวกับประสิทธิภาพของเซิร์ฟเวอร์ และช่วยวินิจฉัยปัญหาได้อย่างรวดเร็วและมีประสิทธิภาพ
13.1 สรุปประเด็นสำคัญ
ตลอดคู่มือนี้ เราได้สำรวจว่า Activity Monitor ช่วยให้คุณเข้าใจและแก้ไขปัญหาได้อย่างไร SQL Server ประสิทธิภาพ:
- Activity Monitor มอบการมองเห็นแบบเรียลไทม์ในกระบวนการ การรอ การสอบถาม และ I/O ผ่านอินเทอร์เฟซกราฟิกที่มีการจัดระเบียบ
- บานหน้าต่างทั้ง 5 บาน ได้แก่ ภาพรวม กระบวนการ การรอทรัพยากร การเข้าถึง/ส่งออกไฟล์ข้อมูล และแบบสอบถามราคาแพงล่าสุด แต่ละบานหน้าต่างนี้ให้มุมมองเฉพาะตัวเกี่ยวกับกิจกรรมของเซิร์ฟเวอร์
- สถานการณ์การแก้ไขปัญหาทั่วไป เช่น การดำเนินการค้นหาที่มากเกินไป การบล็อกโซ่ และการใช้งาน CPU สูง สามารถจัดการได้ด้วยการตรวจสอบ Activity Monitor อย่างเป็นระบบ
- แม้ว่า Activity Monitor จะทรงพลัง แต่ก็มีข้อจำกัด เช่น ขาดข้อมูลประวัติ การจัดกลุ่มประเภทการรอ และค่าใช้จ่ายในการตรวจสอบที่ส่งผลต่อการใช้งานcabความสามารถ
- การเสริม Activity Monitor ด้วยการสอบถาม DMV, sp_WhoIsActive, Extended Events และเครื่องมือจากบุคคลที่สาม จะช่วยสร้างกลยุทธ์การตรวจสอบที่ครอบคลุม
- การปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดสำหรับช่วงเวลาการรีเฟรช การปิด Activity Monitor เมื่อไม่ได้ใช้งาน และการรวมบานหน้าต่างหลายบานเพื่อสร้างความสัมพันธ์ จะทำให้ได้รับประโยชน์สูงสุดในขณะที่ลดผลกระทบให้น้อยที่สุด
13.2 ตัวตรวจสอบกิจกรรมเป็นส่วนหนึ่งของชุดเครื่องมือของคุณ
Activity Monitor ควรเป็นเครื่องมือตอบสนองแรกของคุณสำหรับการตรวจสอบประสิทธิภาพ ไม่ใช่เครื่องมือเดียวของคุณ จุดเด่นของ Activity Monitor คือการมองเห็นภาพรวมได้ทันทีระหว่างการแก้ไขปัญหา ช่วยให้คุณระบุได้อย่างรวดเร็วว่าฐานข้อมูลเป็นคอขวดหรือไม่ และระบุจุดที่ต้องตรวจสอบอย่างละเอียดมากขึ้น
ลองนึกถึง Activity Monitor ว่าเปรียบเสมือนแผงหน้าปัดรถยนต์ของคุณ เพราะมันบอกคุณได้ทันทีหากมีสิ่งผิดปกติ และช่วยให้คุณระบุจุดที่น่ากังวลได้ เช่นเดียวกับที่แผงหน้าปัดรถยนต์ของคุณไม่ได้บอกสาเหตุที่แท้จริงของไฟเตือนเครื่องยนต์ที่ติดสว่าง Activity Monitor ยังสามารถชี้ให้เห็นปัญหาต่างๆ โดยไม่เปิดเผยสาเหตุที่แท้จริงเสมอไป การวิเคราะห์เชิงลึกเช่นนี้จำเป็นต้องใช้เครื่องมือและความเชี่ยวชาญเพิ่มเติม
ผสานรวม Activity Monitor เข้ากับชุดเครื่องมือที่ครอบคลุมยิ่งขึ้น ซึ่งประกอบด้วยการวิเคราะห์แผนการดำเนินการ การติดตามสถิติการรอ โซลูชันการตรวจสอบย้อนหลัง และแนวทางปฏิบัติที่ดีที่สุดด้านประสิทธิภาพ ใช้งานร่วมกับกลยุทธ์การจัดทำดัชนีที่เหมาะสม เทคนิคการปรับแต่งแบบสอบถาม และการวางแผนความจุ
13.3 การเรียนรู้อย่างต่อเนื่อง
การเชี่ยวชาญ Activity Monitor เป็นเพียงก้าวเดียวในการเป็นผู้ดูแลฐานข้อมูลที่มีประสิทธิภาพ พัฒนาทักษะของคุณต่อไปโดย:
- การเรียนรู้ที่จะตีความแผนการดำเนินการและระบุการดำเนินการที่ไม่มีประสิทธิภาพ
- ความเข้าใจ SQL Server สถิติการรอและผลที่ตามมา
- การศึกษาเทคนิคการออกแบบและเพิ่มประสิทธิภาพดัชนี
- สำรวจ SQL Serverสถาปัตยกรรมและวิธีการประมวลผลแบบสอบถาม
- การฝึกปฏิบัติวิธีการแก้ไขปัญหาอย่างเป็นระบบ
- การสร้างประสบการณ์ด้วยเหตุการณ์ขยายเพื่อการติดตามรายละเอียด
- ทำความเข้าใจระดับการแยกธุรกรรมและผลกระทบต่อประสิทธิภาพ
การตรวจสอบประสิทธิภาพแต่ละครั้งด้วย Activity Monitor สอนสิ่งใหม่ ๆ เกี่ยวกับวิธีการ SQL Server งานและวิธีที่แอปพลิเคชันโต้ตอบกับฐานข้อมูล บันทึกสิ่งที่คุณค้นพบ แบ่งปันความรู้กับเพื่อนร่วมงาน และสร้างไลบรารีrary ของวิธีแก้ไขปัญหาทั่วไป
13.4 แหล่งข้อมูลเพิ่มเติม
ขยายความรู้ของคุณด้วยทรัพยากรอันมีค่าเหล่านี้:
- เปิดการตรวจสอบกิจกรรมใน SQL Server สตูดิโอการจัดการ (SSMS)
: เป็นทางการ SQL Server เอกสารเกี่ยวกับวิธีการเปิด Activity Monitor ใน SQL Server สตูดิโอการจัดการ (SSMS)
- กิจกรรมการตรวจสอบ
: เป็นทางการ SQL Server เอกสารเกี่ยวกับวิธีใช้ Activity Monitor
14. คำถามที่พบบ่อย (FAQ)
ถาม: อะไรคือ SQL Server กิจกรรมการตรวจสอบ?
A: SQL Server Activity Monitor เป็นเครื่องมือในตัวภายใน SQL Server Management Studio ที่แสดงข้อมูลแบบเรียลไทม์เกี่ยวกับกระบวนการที่ทำงานบน SQL Server อินสแตนซ์และผลกระทบต่อทรัพยากรเซิร์ฟเวอร์ แดชบอร์ดนี้แสดงกราฟิกพร้อมบานหน้าต่างห้าบานที่แสดงกิจกรรมต่างๆ ของเซิร์ฟเวอร์ ซึ่งรวมถึงการใช้งานโปรเซสเซอร์ งานที่รอ อัตรา I/O เซสชันที่ใช้งานอยู่ และคิวรีที่มีค่าใช้จ่ายสูง
ถาม: ฉันจะเปิด Activity Monitor ใน SSMS ได้อย่างไร
A: คุณสามารถเปิด Activity Monitor ได้โดยใช้สี่วิธี: (1) คลิกไอคอน Activity Monitor ในแถบเครื่องมือ SSMS (2) คลิกขวาที่ SQL Server ชื่ออินสแตนซ์ใน Object Explorer และเลือก กิจกรรมการตรวจสอบ, (3) กด Ctrl + อื่น ๆ + Aหรือ (4) กำหนดค่า SSMS ให้เปิดใช้งานโดยอัตโนมัติผ่าน เครื่องมือ -> ตัวเลือก -> สภาพสิ่งแวดล้อม -> Starหลอด.
ถาม: ฉันต้องมีสิทธิ์อนุญาตอะไรบ้างจึงจะใช้ Activity Monitor ได้
A: คุณต้องการ ดูสถานะเซิร์ฟเวอร์ อนุญาตให้เข้าดูม.ost ข้อมูล Activity Monitor สำหรับบานหน้าต่าง Data File I/O คุณยังต้องมี สร้างฐานข้อมูล, เปลี่ยนแปลงฐานข้อมูลใดๆหรือ ดูคำจำกัดความใด ๆ การอนุญาต หากไม่มีสิทธิ์เหล่านี้ Activity Monitor อาจเปิดได้ แต่จะแสดงบานหน้าต่างว่างเปล่า
ถาม: เหตุใด Activity Monitor ของฉันจึงหยุดชั่วคราวหรือไม่ทำงาน?
A: Activity Monitor มักจะหยุดทำงานเนื่องจากปัญหาการอนุญาต เวอร์ชัน SSMS ที่ล้าสมัย หรือการเชื่อมต่อระยะไกลถูกปิดใช้งาน วิธีแก้ไข: (1) อัปเดต SSMS เป็นเวอร์ชันล่าสุด (2) ตรวจสอบว่าคุณมีสิทธิ์ VIEW SERVER STATE (3) ตรวจสอบว่าการเชื่อมต่อระยะไกลเปิดใช้งานอยู่บน SQL Server ตัวอย่าง (4) Restart SSMS และ (5) ลองเชื่อมต่อด้วยการตรวจสอบสิทธิ์ของ Windows แทนการตรวจสอบสิทธิ์ของ SQL หากใช้cable.
ถาม: ความแตกต่างระหว่าง Activity Monitor และ sp_WhoIsActive คืออะไร
A: Activity Monitor เป็นเครื่องมือกราฟิกที่สร้างขึ้นใน SSMS ซึ่งแสดงบานหน้าต่างที่จัดระเบียบสำหรับการตรวจสอบด้านต่างๆ sp_WhoIsActive เป็นโพรซีเดอร์แบบจัดเก็บที่สร้างขึ้นโดยชุมชนฟรี ซึ่งส่งคืนข้อมูลเซสชันโดยละเอียดในชุดผลลัพธ์เดียว พร้อมด้วยประเภทการรอ รายละเอียดการบล็อก และตัวเลือกการปรับแต่งที่เฉพาะเจาะจงกว่า Activity Monitor Activity Monitor เหมาะกับการสำรวจด้วยภาพมากกว่า ในขณะที่ sp_WhoIsActive โดดเด่นในด้านการตรวจสอบแบบสคริปต์และให้ข้อมูลโดยละเอียดมากกว่า
ถาม: Activity Monitor มีผลกระทบต่อประสิทธิภาพของเซิร์ฟเวอร์หรือไม่
ตอบ: ใช่ Activity Monitor มีค่าใช้จ่ายที่วัดได้ เนื่องจากจะสอบถาม DMV ของระบบในแต่ละช่วงการรีเฟรช ผลกระทบจะเพิ่มขึ้นตามอัตราการรีเฟรชที่ต่ำลง Microsoft เตือนว่าช่วงเวลาที่น้อยกว่า 10 วินาทีอาจส่งผลต่อประสิทธิภาพของเซิร์ฟเวอร์ ควรปิด Activity Monitor เสมอเมื่อไม่ได้ใช้งาน และพิจารณาช่วงเวลาการรีเฟรช 30-60 วินาทีบนเซิร์ฟเวอร์ที่ใช้งานจริงที่มีภาระงานสูง
ถาม: ฉันสามารถรับข้อมูล Activity Monitor โดยใช้ T-SQL ได้หรือไม่
ตอบ: ใช่ Activity Monitor จะสอบถามข้อมูลมุมมองการจัดการแบบไดนามิกของระบบ เช่น sys.dm_exec_requests, sys.dm_exec_sessions, sys.dm_os_wait_stats และ sys.dm_exec_query_stats คุณสามารถสอบถามข้อมูล DMV เหล่านี้ได้โดยตรงโดยใช้ T-SQL เพื่อดึงข้อมูลเทียบเท่าผ่านโปรแกรม ซึ่งจะช่วยให้สามารถใช้งานสคริปต์ตรวจสอบแบบกำหนดเองและรวบรวมข้อมูลอัตโนมัติได้
ถาม: ช่วงเวลาการรีเฟรชเริ่มต้นคืออะไร?
A: ช่วงเวลาการรีเฟรชเริ่มต้นคือ 10 วินาที คุณสามารถเปลี่ยนแปลงได้โดยคลิกขวาที่ใดก็ได้ในบานหน้าต่างภาพรวม แล้วเลือก รีเฟรชช่วงเวลาและเลือกจากตัวเลือกที่กำหนดไว้ล่วงหน้า: 1 วินาที, 5 วินาที, 10 วินาที, 30 วินาที, 1 นาที หรือ 1 ชั่วโมง ช่วงเวลาที่สั้นลงทำให้มองเห็นภาพแบบเรียลไทม์ได้มากขึ้น แต่เพิ่มค่าใช้จ่ายในการตรวจสอบ
ถาม: ฉันจะเปิด Activity Monitor บน SSMS โดยอัตโนมัติได้อย่างไรtarทับ?
ก: กำหนดค่าการเปิดใช้งานอัตโนมัติผ่านตัวเลือก SSMS: ไปที่ เครื่องมือ -> ตัวเลือก -> สภาพสิ่งแวดล้อม -> Starหลอดจากนั้นเลือก เปิดตัวสำรวจวัตถุและตัวตรวจสอบกิจกรรม จาก ที่ starหลอด เมนูแบบดรอปดาวน์ Activity Monitor จะเปิดขึ้นโดยอัตโนมัติทุกครั้งที่คุณเชื่อมต่อกับเซิร์ฟเวอร์ใน SSMS
ถาม: ข้อจำกัดของ Activity Monitor มีอะไรบ้าง?
A: ข้อจำกัดที่สำคัญ ได้แก่: (1) ไม่มีการเก็บข้อมูลประวัติหรือความสามารถในการดูแนวโน้ม (2) ประเภทการรอจะถูกจัดกลุ่มเป็นหมวดหมู่แทนที่จะแสดงเฉพาะ (3) ประเภทการรอบางประเภท เช่น CXPACKET อาจไม่ปรากฏ (4) สแน็ปช็อต ณ จุดเวลาอาจพลาดปัญหาชั่วคราว (5) โอเวอร์เฮดของการตรวจสอบอาจส่งผลกระทบต่อเซิร์ฟเวอร์ที่ยุ่ง (6) ไม่มีกลไกการแจ้งเตือนสำหรับการตรวจสอบเชิงรุก และ (7) ไม่สามารถรวบรวมข้อมูลข้ามหลายรายการได้ SQL Server อินสแตนซ์ สำหรับความต้องการเหล่านี้ ให้เสริม Activity Monitor ด้วย Extended Events ชุดการรวบรวมข้อมูล หรือเครื่องมือตรวจสอบจากบุคคลที่สาม
เกี่ยวกับผู้เขียน
หยวน เซิง เป็นผู้ดูแลฐานข้อมูลอาวุโส (DBA) ที่มีประสบการณ์มากกว่า 10 ปีใน SQL Server สภาพแวดล้อมและการจัดการฐานข้อมูลองค์กร เขาประสบความสำเร็จในการแก้ไขปัญหาการกู้คืนฐานข้อมูลหลายร้อยกรณีในองค์กรด้านบริการทางการเงิน การดูแลสุขภาพ และการผลิต
หยวนมีความเชี่ยวชาญด้าน SQL Server การกู้คืนฐานข้อมูล โซลูชันที่มีความพร้อมใช้งานสูงรวมถึงการเพิ่มประสิทธิภาพการทำงาน ประสบการณ์ภาคปฏิบัติที่กว้างขวางของเขารวมถึงการจัดการฐานข้อมูลขนาดหลายเทราไบต์ การใช้งาน Always On Availability Groups และการพัฒนากลยุทธ์การสำรองข้อมูลและการกู้คืนอัตโนมัติสำหรับระบบธุรกิจที่สำคัญยิ่ง
ด้วยความเชี่ยวชาญทางเทคนิคและแนวทางปฏิบัติ Yuan มุ่งเน้นที่การสร้างคู่มือที่ครอบคลุมซึ่งจะช่วยให้ผู้ดูแลระบบฐานข้อมูลและผู้เชี่ยวชาญด้านไอทีแก้ไขปัญหาที่ซับซ้อน SQL Server ท้าทายอย่างมีประสิทธิภาพ เขาคอยติดตามข่าวสารล่าสุดอยู่เสมอ SQL Server การเปิดตัวและเทคโนโลยีฐานข้อมูลที่พัฒนาอย่างต่อเนื่องของ Microsoft ทดสอบสถานการณ์การกู้คืนเป็นประจำเพื่อให้แน่ใจว่าคำแนะนำของเขาสะท้อนถึงแนวทางปฏิบัติที่ดีที่สุดในโลกแห่งความเป็นจริง
มีคำถามเกี่ยวกับ SQL Server การกู้คืนหรือต้องการคำแนะนำในการแก้ไขปัญหาฐานข้อมูลเพิ่มเติมหรือไม่? หยวนยินดีต้อนรับ ข้อเสนอแนะและข้อเสนอแนะ เพื่อปรับปรุงทรัพยากรทางเทคนิคเหล่านี้


















