1. บทนำสู่ SQL Server Profiler
1.1 คืออะไร SQL Server โปรไฟเลอร์และเหตุใดเราจึงต้องการมัน?
SQL Server Profiler เป็นเครื่องมืออินเทอร์เฟซผู้ใช้แบบกราฟิกสำหรับการตรวจสอบและบันทึกเหตุการณ์ที่เกิดขึ้นภายใน SQL Serverเครื่องมือวินิจฉัยอันทรงพลังนี้ช่วยให้ผู้ดูแลระบบฐานข้อมูลและนักพัฒนาสามารถสังเกตกิจกรรมของเอนจินฐานข้อมูลแบบเรียลไทม์ ซึ่งช่วยในการระบุปัญหาคอขวดด้านประสิทธิภาพ แก้ไขปัญหาแอปพลิเคชัน และตรวจสอบเหตุการณ์ด้านความปลอดภัย
1.2 SQL Server โปรไฟล์ในปี 2025: สถานะปัจจุบันและทางเลือก
Microsoft ไม่สนับสนุนอีกต่อไป SQL Server โปรไฟล์เริ่มต้นด้วย SQL Server 2016 แนะนำ กิจกรรมขยาย เป็นเทคโนโลยีทดแทน อย่างไรก็ตาม เครื่องมือนี้ยังคงมีอยู่ในปัจจุบัน SQL Server เวอร์ชันต่างๆ รวมถึง SQL Server 2022 และยังคงถูกใช้กันอย่างแพร่หลายโดยผู้เชี่ยวชาญด้านฐานข้อมูล
1.3 ใครควรใช้คู่มือนี้
- คู่มือนี้เหมาะสำหรับผู้ดูแลระบบฐานข้อมูลที่ต้องการตรวจสอบ SQL Server วิเคราะห์ปัญหาประสิทธิภาพการทำงาน และรับรองความน่าเชื่อถือของระบบ ผู้ดูแลฐานข้อมูล (DBA) จะได้รับคำแนะนำเชิงปฏิบัติสำหรับการบันทึกร่องรอย วิเคราะห์เหตุการณ์ และนำกลยุทธ์การตรวจสอบไปใช้
- นักพัฒนาแอปพลิเคชันได้รับประโยชน์จากการเข้าใจว่าโค้ดของพวกเขาโต้ตอบกับ SQL ServerSQL Profiler ช่วยให้นักพัฒนาระบุแบบสอบถามที่ไม่มีประสิทธิภาพ ตรวจสอบพฤติกรรมของแอปพลิเคชัน และดีบักข้อผิดพลาดที่เกี่ยวข้องกับฐานข้อมูล
- นักวิเคราะห์และที่ปรึกษาด้านประสิทธิภาพจะค้นพบเทคนิคขั้นสูงสำหรับการวิเคราะห์เวิร์กโหลด การวางแผนความจุ และการปรับปรุงระบบให้เหมาะสม ขอบเขตที่ครอบคลุมของการกำหนดค่าการติดตาม การกรอง และการวิเคราะห์ ช่วยให้สามารถประเมินประสิทธิภาพฐานข้อมูลได้อย่างครอบคลุม
2 ความเข้าใจ SQL Server พื้นฐานของโปรไฟเลอร์
2.1 อย่างไร SQL Server โปรไฟเลอร์เวิร์คส์
SQL Server โปรไฟล์เลอร์ทำงานเป็นแอปพลิเคชันไคลเอนต์ที่เชื่อมต่อกับเอ็นจิ้น SQL Trace ที่ทำงานภายใน SQL Serverเมื่อคุณสร้างการติดตาม เอนจินฐานข้อมูลจะตรวจสอบเหตุการณ์ที่ระบุและบันทึกเหตุการณ์เหล่านั้นตามการกำหนดค่าของคุณ เอนจินการติดตามจะรวบรวมข้อมูลเหตุการณ์โดยมีผลกระทบต่อประสิทธิภาพของเซิร์ฟเวอร์น้อยที่สุดเมื่อกำหนดค่าอย่างถูกต้อง
โครงสร้างพื้นฐาน SQL Trace พื้นฐานใช้ Event Hooks แบบ Lightweight ทั่วทั้งเอ็นจินฐานข้อมูล เมื่อเกิดเหตุการณ์ที่ตรงกับนิยามการติดตามของคุณ เอ็นจินจะรวบรวมข้อมูลที่เกี่ยวข้องและส่งไปยังอินเทอร์เฟซ Profiler หรือจัดเก็บลงในไฟล์หรือตาราง สถาปัตยกรรมนี้ช่วยให้สามารถรวบรวมข้อมูลได้อย่างยืดหยุ่นโดยไม่ต้องแก้ไขโค้ดแอปพลิเคชัน
2.2 แนวคิดหลักและคำศัพท์
เหตุการณ์ 2.2.1
เหตุการณ์แสดงถึงเหตุการณ์เฉพาะภายใน SQL Server ที่เอ็นจิ้นการติดตามสามารถจับได้ แต่ละเหตุการณ์จะสอดคล้องกับการดำเนินการฐานข้อมูลหรือกิจกรรมของระบบที่เฉพาะเจาะจง SQL Server โปรไฟเลอร์จัดระเบียบเหตุการณ์ต่างๆ ให้เป็นหมวดหมู่เชิงตรรกะเพื่อให้กำหนดค่าได้ง่ายขึ้น
หมวดหมู่เหตุการณ์ทั่วไปประกอบด้วย TSQL สำหรับการดำเนินการคิวรี, Stored Procedures สำหรับการเรียกใช้กระบวนการ, Locks สำหรับการตรวจสอบการทำงานพร้อมกัน และ Errors and Warnings สำหรับการติดตามข้อยกเว้น การเลือกเหตุการณ์ที่เหมาะสมจะเป็นตัวกำหนดว่าข้อมูลการติดตามของคุณจะบันทึกอะไร และส่งผลโดยตรงต่อประโยชน์และประสิทธิภาพของการติดตาม
การทำความเข้าใจเกี่ยวกับประเภทของเหตุการณ์จะช่วยให้คุณกำหนดค่าการติดตามที่มีประสิทธิภาพได้ เหตุการณ์ RPC:Completed จะบันทึกการเรียกกระบวนการระยะไกลที่เสร็จสมบูรณ์ เหตุการณ์ SQL:BatchCompleted จะติดตามชุดคำสั่งค้นหาเฉพาะกิจ และเหตุการณ์ Lock:Deadlock จะระบุการเกิด Deadlock เลือกเหตุการณ์ที่สอดคล้องกับวัตถุประสงค์ในการแก้ไขปัญหาหรือการตรวจสอบเฉพาะของคุณ
2.2.2 คอลัมน์ข้อมูล
คอลัมน์ข้อมูลจะกำหนดว่าข้อมูลการติดตามจะบันทึกสำหรับแต่ละเหตุการณ์ใด คอลัมน์ทั่วไปประกอบด้วย TextData สำหรับคำสั่ง SQL จริง, Duration สำหรับเวลาดำเนินการ, CPU สำหรับการใช้หน่วยประมวลผล, Reads สำหรับการอ่านดิสก์เชิงตรรกะ และ Writes สำหรับการเขียนดิสก์เชิงตรรกะ
คอลัมน์ที่จำเป็นจะแตกต่างกันไปตามกรณีการใช้งาน โดยทั่วไปการแก้ไขปัญหาประสิทธิภาพจำเป็นต้องใช้คอลัมน์ Duration, CPU, Reads และ Writes การตรวจสอบความปลอดภัยจำเป็นต้องใช้คอลัมน์ LoginName, DatabaseName และ ObjectName ส่วนการดีบักแอปพลิเคชันจะได้รับประโยชน์จากคอลัมน์ ApplicationName, SPID และ Error
การเลือกเฉพาะคอลัมน์ที่จำเป็นจะช่วยลดค่าใช้จ่ายในการติดตามและทำให้การวิเคราะห์ง่ายขึ้น หลีกเลี่ยงการบันทึกคอลัมน์ทั้งหมดที่มีอยู่ เว้นแต่จำเป็นจริงๆ คอลัมน์ที่เพิ่มเข้ามาแต่ละคอลัมน์จะเพิ่มปริมาณข้อมูลที่รวบรวมและประมวลผล ซึ่งอาจส่งผลกระทบต่อประสิทธิภาพของเซิร์ฟเวอร์
ตัวกรอง 2.2.3
ตัวกรองจะจำกัดเหตุการณ์ที่การติดตามจะบันทึกตามเกณฑ์ที่กำหนด ตัวกรองที่กำหนดค่าอย่างเหมาะสมจะช่วยลดปริมาณการติดตามได้อย่างมาก ทำให้สามารถจัดการการวิเคราะห์ได้และลดผลกระทบต่อประสิทธิภาพ ตัวกรองจะประเมินข้อมูลเหตุการณ์ก่อนบันทึก ป้องกันการรวบรวมข้อมูลที่ไม่จำเป็น
เกณฑ์การกรองทั่วไปประกอบด้วย DatabaseName เพื่อเน้นฐานข้อมูลเฉพาะ, ApplicationName เพื่อแยกแอปพลิเคชันเฉพาะ, Duration เพื่อบันทึกเฉพาะการดำเนินการที่ช้า และ LoginName เพื่อติดตามผู้ใช้เฉพาะ การรวมตัวกรองหลายตัวเข้าด้วยกันจะสร้างคำจำกัดความการติดตามที่แม่นยำ ซึ่งบันทึกสิ่งที่คุณต้องการได้อย่างแม่นยำ
การกรองข้อมูลที่คำนึงถึงประสิทธิภาพเป็นสิ่งสำคัญสำหรับสภาพแวดล้อมการใช้งานจริง ควรกรองข้อมูลตามชื่อฐานข้อมูลหรือชื่อแอปพลิเคชันเสมอ เพื่อหลีกเลี่ยงการดักจับกิจกรรมของระบบ ตั้งค่าเกณฑ์ระยะเวลาขั้นต่ำเพื่อละเว้นการสืบค้นข้อมูลแบบรวดเร็ว ควรใช้ตัวกรอง TextData อย่างระมัดระวัง เนื่องจากตัวกรองเหล่านี้จำเป็นต้องใช้การเปรียบเทียบสตริงซึ่งเพิ่มภาระงาน
2.2.4 เทมเพลตการติดตาม
เทมเพลตการติดตามจะให้ตัวเลือกเหตุการณ์ คอลัมน์ และตัวกรองที่กำหนดค่าไว้ล่วงหน้าสำหรับสถานการณ์ทั่วไป SQL Server โปรแกรม Profiler มีเทมเพลตสำเร็จรูปหลายแบบที่ใช้เป็นจุดเริ่มต้นในการสร้างการติดตาม เทมเพลตแบบกำหนดเองจะบันทึกการตั้งค่าของคุณเพื่อนำกลับมาใช้ใหม่ในการติดตามหลายครั้ง
เทมเพลตมาตรฐานจะบันทึกชุดเหตุการณ์ทั่วไปที่เหมาะสมสำหรับการตรวจสอบขั้นพื้นฐาน เทมเพลต TSQL มุ่งเน้นไปที่การดำเนินการคิวรีโดยมีค่าใช้จ่ายน้อยที่สุด เทมเพลต Tuning จะรวบรวมเหตุการณ์เฉพาะสำหรับการวิเคราะห์ Database Engine Tuning Advisor แต่ละเทมเพลตจะปรับสมดุลการบันทึกข้อมูลกับผลกระทบต่อประสิทธิภาพ
การสร้างเทมเพลตแบบกำหนดเองช่วยประหยัดเวลาและรับประกันความสอดคล้องกันในทุกเซสชันการติดตาม กำหนดค่าการติดตามด้วยเหตุการณ์ คอลัมน์ และตัวกรองที่คุณต้องการ จากนั้นบันทึกเป็นเทมเพลต เทมเพลตแบบกำหนดเองจะมีประโยชน์อย่างยิ่งเมื่อคุณแก้ไขปัญหาที่คล้ายกันซ้ำๆ กัน
3. การเริ่มต้นใช้งาน SQL Server Profiler
3.1 ข้อกำหนดและข้อกำหนดเบื้องต้นของระบบ
SQL Server โปรไฟเลอร์มาพร้อมกับ SQL Server Management Studio และรองรับการบำรุงรักษาทั้งหมดในปัจจุบัน SQL Server เวอร์ชันต่างๆ จาก SQL Server เพื่อ 2016 2022
ข้อกำหนดการอนุญาตจะกำหนดว่าใครสามารถสร้างและรันการติดตามได้ สมาชิกของบทบาทเซิร์ฟเวอร์คงที่ของ sysadmin มีสิทธิ์เข้าถึงแบบไม่จำกัด SQL Server ฟังก์ชันการทำงานของ Profiler สำหรับผู้ใช้ที่ไม่ใช่ผู้ดูแลระบบ สิทธิ์ ALTER TRACE จะให้ความสามารถในการสร้างและจัดการการติดตาม
ข้อควรพิจารณาเกี่ยวกับเครือข่ายจะถูกนำมาใช้เมื่อติดตามเซิร์ฟเวอร์ระยะไกล การติดตามฝั่งไคลเอ็นต์จำเป็นต้องมีการเชื่อมต่อเครือข่ายอย่างต่อเนื่องระหว่างเวิร์กสเตชันของคุณและ SQL Server อินสแตนซ์ การเชื่อมต่อที่ขาดหายจะทำให้การติดตามฝั่งไคลเอ็นต์หยุดทำงาน ซึ่งอาจสูญเสียข้อมูลที่บันทึกไว้ การติดตามฝั่งเซิร์ฟเวอร์จะหลีกเลี่ยงข้อจำกัดนี้โดยการทำงานบนเซิร์ฟเวอร์ฐานข้อมูลทั้งหมด
3.2 วิธีการเปิดตัว SQL Server Profiler
3.2.1 เริ่มต้นจาก SQL Server สตูดิโอการจัดการ (SSMS)
ปฏิบัติตามขั้นตอนเหล่านี้เพื่อเปิดตัว SQL Server โปรไฟล์เลอร์จาก SSMS:
- จุดเปิด SQL Server Management Studio และเชื่อมต่อกับสิ่งใด ๆ SQL Server ตัวอย่าง.
- คลิก เครื่องมือ เมนูในแถบเมนูด้านบน
- เลือก SQL Server Profiler จากเมนูแบบเลื่อนลง
- การขอ SQL Server แอปพลิเคชัน Profiler เปิดขึ้นในหน้าต่างใหม่
3.2.2 การเริ่มต้นจากเมนูเริ่มของ Windows
ทางเข้า SQL Server โปรไฟเลอร์โดยตรงจาก Windows โดยใช้ขั้นตอนเหล่านี้:
- คลิกที่หน้าต่าง เริ่มต้น ปุ่ม
- ประเภท SQL Server Profiler ในช่องค้นหา
- เลือก SQL Server Profiler จากผลการค้นหา
- แอปพลิเคชันเปิดโดยไม่มีการเชื่อมต่อที่ใช้งานอยู่
หรืออีกวิธีหนึ่งคือ เข้าไปที่เมนู Start ตามลำดับชั้น:
- เปิด เริ่มต้น เมนู
- ค้นหาตำแหน่ง ไมโครซอฟท์ SQL Server เครื่องมือ โฟลเดอร์
- ขยายโฟลเดอร์และคลิก SQL Server Profiler.
3.2.3 การเชื่อมต่อกับ SQL Server อินสแตนซ์
หลังจากเปิดตัว SQL Server โปรไฟเลอร์สร้างการเชื่อมต่อโดยทำตามขั้นตอนเหล่านี้:
- คลิก เนื้อไม่มีมัน ในแถบเมนู
- เลือก ร่องรอยใหม่ จากเมนูแบบเลื่อนลง
- การขอ เชื่อมต่อกับเซิร์ฟเวอร์ กล่องโต้ตอบปรากฏขึ้น
- กรอกชื่อเซิร์ฟเวอร์ของคุณใน ชื่อเซิร์ฟเวอร์ สนาม
- Choose รับรองความถูกต้องของ Windows or SQL Server การยืนยันตัวตน.
- หากใช้งาน SQL Server การพิสูจน์ตัวตน กรุณาป้อนข้อมูลประจำตัวในการเข้าสู่ระบบของคุณ
- คลิก ติดตามเราได้ที่ เพื่อสร้างการเชื่อมต่อ
สำหรับการเชื่อมต่อระยะไกล โปรดระบุชื่อเซิร์ฟเวอร์แบบเต็ม รวมถึงชื่ออินสแตนซ์หากมี ใช้รูปแบบ SERVERNAME\INSTANCENAME สำหรับอินสแตนซ์ที่มีชื่อ ตรวจสอบการเชื่อมต่อเครือข่ายและการตั้งค่าไฟร์วอลล์หากการเชื่อมต่อล้มเหลว
4. การสร้างและการกำหนดค่า SQL Server ร่องรอย
4.1 การสร้างร่องรอยแรกของคุณโดยใช้เทมเพลต
สร้างร่องรอยแรกของคุณโดยใช้ขั้นตอนเหล่านี้:
- ยิง SQL Server Profiler
- คลิก เนื้อไม่มีมัน -> ร่องรอยใหม่ และเชื่อมต่อกับเซิร์ฟเวอร์เป้าหมายของคุณ
- การขอ คุณสมบัติของการติดตาม กล่องโต้ตอบปรากฏขึ้น
- กรอกชื่อที่บรรยายใน ชื่อร่องรอย สนาม
- เลือกเทมเพลตจาก ใช้เทมเพลต หล่นลง.
- เลือกกระเป๋า มาตรฐาน (ค่าเริ่มต้น) เทมเพลตสำหรับการตรวจสอบทั่วไป หรือเทมเพลตอื่นสำหรับวัตถุประสงค์อื่นๆ เทมเพลตนี้มีเหตุการณ์ คอลัมน์ และตัวกรองที่กำหนดค่าไว้ล่วงหน้าสำหรับสถานการณ์ทั่วไป
- คลิก วิ่ง เพื่อเริ่มบันทึกเหตุการณ์ทันที
4.2 ปรับแต่งการติดตามของคุณ
หลายครั้งที่เทมเพลตไม่สามารถตอบสนองความต้องการของคุณได้ ในกรณีนี้ คุณสามารถปรับแต่งการติดตามของคุณได้อย่างเต็มที่:
- ตัว Vortex Indicator ได้ถูกนำเสนอลงในนิตยสาร คุณสมบัติของการติดตาม โต้ตอบ
- เลือก ว่างเปล่า เทมเพลตจาก ใช้เทมเพลต หล่นลง.
- คลิก การเลือกกิจกรรม แท็บนี้ คุณสามารถปรับแต่งเหตุการณ์ คอลัมน์ข้อมูล และตัวกรองทั้งหมดได้ตามความต้องการ เราจะอธิบายรายละเอียดเพิ่มเติมในหัวข้อถัดไป
4.3 การเลือกเหตุการณ์ที่จะบันทึก
คุณสามารถเลือกกิจกรรมได้ใน การเลือกกิจกรรม แท็บ
- คลิก + ไอคอนข้างๆ หมวดหมู่กิจกรรมเพื่อขยาย
- คลิกช่องกาเครื่องหมายข้างกิจกรรมเพื่อเลือก
4.3.1 การทำความเข้าใจหมวดหมู่เหตุการณ์
SQL Server โปรแกรม Profiler จัดระเบียบเหตุการณ์ต่างๆ เป็นหมวดหมู่เพื่อการจัดกลุ่มอย่างเป็นระบบ หมวดหมู่ Stored Procedures ประกอบด้วยเหตุการณ์สำหรับการเรียกใช้โปรซีเดอร์ เช่น SP:Starting, SP:Completed และ SP:StmtCompleted เหตุการณ์เหล่านี้ติดตามการเรียกใช้โปรซีเดอร์ที่จัดเก็บไว้และการเรียกใช้คำสั่งแต่ละรายการภายในโปรซีเดอร์
หมวดหมู่ TSQL จะบันทึกการเรียกใช้คิวรีแบบเฉพาะกิจด้วยเหตุการณ์ต่างๆ เช่น SQL:BatchStarting และ SQL:BatchCompleted เหตุการณ์เหล่านี้จะติดตามคิวรีที่ส่งโดยตรงไปยัง TSQL SQL Server นอกเหนือจากกระบวนการที่เก็บไว้
หมวดหมู่ Locks จะตรวจสอบเหตุการณ์ที่เกี่ยวข้องกับการทำงานพร้อมกัน ได้แก่ Lock:Acquired, Lock:Released, Lock:Deadlock และ Lock:Timeout ใช้เหตุการณ์เหล่านี้เพื่อวินิจฉัยปัญหาการบล็อกและเดดล็อกที่ส่งผลกระทบต่อประสิทธิภาพของแอปพลิเคชัน
หมวดหมู่ข้อผิดพลาดและคำเตือนจะบันทึกเหตุการณ์ข้อยกเว้นต่างๆ รวมถึงข้อยกเว้น คำเตือน และข้อความแสดงข้อผิดพลาดของผู้ใช้ เหตุการณ์เหล่านี้ช่วยระบุข้อผิดพลาดของแอปพลิเคชันและ SQL Server คำเตือนระหว่างเซสชันการติดตาม
4.3.2 การเลือกเหตุการณ์ที่เหมาะสมกับสถานการณ์ของคุณ
การตรวจสอบประสิทธิภาพจำเป็นต้องมีเหตุการณ์ที่บันทึกการใช้ทรัพยากร เลือก RPC:Completed และ SQL:BatchCompleted เพื่อติดตามการดำเนินการคิวรี ระบุคอลัมน์ Duration, CPU, Reads และ Writes เพื่อวัดการใช้ทรัพยากร เหตุการณ์เหล่านี้เป็นพื้นฐานสำหรับการระบุปัญหาคอขวดด้านประสิทธิภาพ
การตรวจสอบความปลอดภัยจำเป็นต้องมีเหตุการณ์ที่ติดตามการพิสูจน์ตัวตนและการอนุญาต เลือก Audit Login, Audit Logout, Audit Login Failed และ Object:Opened เพื่อตรวจสอบการเข้าถึงฐานข้อมูล ระบุคอลัมน์ LoginName, DatabaseName และ ObjectName เพื่อระบุว่าใครเข้าถึงทรัพยากรใด
สถานการณ์การดีบักจะได้รับประโยชน์จากการบันทึกเหตุการณ์อย่างครอบคลุม รวมถึงเหตุการณ์ของโพรซีเดอร์ที่จัดเก็บไว้ เหตุการณ์ของชุดคำสั่ง SQL และเหตุการณ์ข้อผิดพลาด เพื่อติดตามลำดับการทำงานทั้งหมด บันทึกบริบทเพิ่มเติมด้วยคอลัมน์ SPID, ApplicationName และ HostName เพื่อเชื่อมโยงเหตุการณ์กับเซสชันเฉพาะ
4.4 การกำหนดค่าคอลัมน์ข้อมูล
โดยค่าเริ่มต้น เมื่อคุณเลือกเหตุการณ์ คอลัมน์ข้อมูลทั้งหมดจะถูกเลือก (ทำเครื่องหมายไว้) คุณสามารถยกเลิกการเลือกคอลัมน์ที่ไม่จำเป็นเพื่อลดค่าใช้จ่ายและทำให้การวิเคราะห์ง่ายขึ้น:
คอลัมน์สำคัญสำหรับทุกการติดตามประกอบด้วย EventClass เพื่อระบุประเภทของเหตุการณ์ TextData เพื่อบันทึกคำสั่ง SQL จริง LoginName เพื่อระบุผู้ใช้ที่ดำเนินการ และ StartTime เพื่อประทับเวลาเมื่อเหตุการณ์เกิดขึ้น คอลัมน์เหล่านี้ให้บริบทพื้นฐานสำหรับทุกเหตุการณ์ที่บันทึกไว้
คอลัมน์ที่เกี่ยวข้องกับประสิทธิภาพจะวัดการใช้ทรัพยากร ระยะเวลาจะแสดงระยะเวลาที่เหตุการณ์ใช้ไปเป็นไมโครวินาที CPU จะแสดงเวลาของโปรเซสเซอร์เป็นมิลลิวินาที การอ่านจะนับจำนวนการอ่านเพจแบบลอจิคัล การเขียนจะติดตามการเขียนเพจแบบลอจิคัล เมตริกเหล่านี้ระบุการดำเนินการที่ใช้ทรัพยากรจำนวนมากซึ่งจำเป็นต้องมีการปรับแต่งประสิทธิภาพ
คอลัมน์ความปลอดภัยและการตรวจสอบติดตามรูปแบบการเข้าถึงข้อมูล DatabaseName ระบุว่ามีการเข้าถึงฐานข้อมูลใด ObjectName ระบุตารางหรืออ็อบเจ็กต์ที่เกี่ยวข้อง ApplicationName ระบุว่าแอปพลิเคชันใดเป็นผู้เริ่มกิจกรรม คอลัมน์เหล่านี้เมื่อรวมกันแล้วจะแสดงเส้นทางการตรวจสอบที่ครอบคลุม
4.5 การตั้งค่าตัวกรองเพื่อลดเสียงรบกวน
4.5.1 เกณฑ์ตัวกรองทั่วไป
กำหนดค่าตัวกรองโดยใช้วิธีการต่อไปนี้:
- เปิด คุณสมบัติของการติดตาม โต้ตอบ
- คลิก การเลือกกิจกรรม แถบ
- คลิก ตัวกรองคอลัมน์ ปุ่มที่ด้านล่างขวา
- เลือกคอลัมน์จากรายการทางด้านซ้าย
- กำหนดค่าเกณฑ์การกรองในแผงทางด้านขวา
- คลิก OK เพื่อใช้ตัวกรอง
ตัวกรองชื่อแอปพลิเคชันจะแยกกิจกรรมจากแอปพลิเคชันเฉพาะ ขยายคอลัมน์ ApplicationName ในกล่องโต้ตอบตัวกรอง ป้อนชื่อแอปพลิเคชันของคุณใน Like ทุ่งนาและ SQL Server โปรไฟเลอร์จะบันทึกเฉพาะเหตุการณ์จากแอปพลิเคชันนั้น ตัวกรองนี้มีประโยชน์อย่างยิ่งในการแก้ไขปัญหาเฉพาะแอปพลิเคชัน
ตัวกรองชื่อฐานข้อมูลจะจำกัดการจับภาพเฉพาะฐานข้อมูลที่ระบุ กรองตามชื่อฐานข้อมูลเพื่อแยกกิจกรรมฐานข้อมูลระบบและมุ่งเน้นไปที่ฐานข้อมูลแอปพลิเคชันของคุณ ป้อนชื่อฐานข้อมูลใน Like or เท่ากัน ฟิลด์ขึ้นอยู่กับว่าคุณต้องการการจับคู่ไวด์การ์ดหรือไม่
ตัวกรองระยะเวลาจะจับเฉพาะการทำงานที่ช้าเท่านั้น ตั้งค่าเกณฑ์ขั้นต่ำใน มากกว่าหรือเท่ากับ ใต้คอลัมน์ "ระยะเวลา" ตัวอย่างเช่น การตั้งค่าระยะเวลา >= 1000 จะจับเฉพาะเหตุการณ์ที่ใช้เวลานานกว่าหนึ่งวินาที โดยกรองคิวรีที่ดำเนินการเร็วออกไป
ตัวกรองชื่อผู้ใช้จะติดตามกิจกรรมของผู้ใช้แต่ละราย กรองตามชื่อล็อกอินเพื่อตรวจสอบผู้ใช้ฐานข้อมูลรายใดรายหนึ่ง วิธีนี้ช่วยระบุว่าผู้ใช้รายใดดำเนินการค้นหาที่มีปัญหาหรือเข้าถึงข้อมูลสำคัญ
4.4.2 แนวทางปฏิบัติที่ดีที่สุดสำหรับการกรอง
การกรองข้อมูลที่มีประสิทธิภาพจะช่วยสร้างสมดุลระหว่างการเก็บรวบรวมข้อมูลกับผลกระทบต่อประสิทธิภาพการทำงาน ควรใช้ตัวกรองอย่างน้อยหนึ่งตัวเสมอเพื่อป้องกันการเก็บรวบรวมข้อมูลกิจกรรมของระบบมากเกินไป ตัวกรอง DatabaseName และ ApplicationName ควรเป็นจุดเริ่มต้นสำหรับการติดตามข้อมูลส่วนใหญ่
หลีกเลี่ยงการบันทึกข้อมูลในวงกว้างเกินไปในสภาพแวดล้อมการใช้งานจริง การบันทึกข้อมูลโดยไม่กรองจะเก็บข้อมูลจำนวนมหาศาล ซึ่งอาจทำให้ประสิทธิภาพของเซิร์ฟเวอร์ลดลงและทำให้การวิเคราะห์ทำได้ยาก กำหนดเกณฑ์การกรองเฉพาะที่ตรงกับวัตถุประสงค์ในการแก้ไขปัญหาของคุณ
ทดสอบตัวกรองก่อนนำไปใช้งานจริง รันการติดตามกับสภาพแวดล้อมการพัฒนาหรือการทดสอบก่อน เพื่อตรวจสอบว่าตัวกรองสามารถบันทึกเหตุการณ์ที่คาดหวังได้โดยไม่ต้องโอเวอร์เฮดมากเกินไป ปรับเกณฑ์ตัวกรองตามปริมาณข้อมูลที่บันทึก
4.5 การทำงานกับเทมเพลตการติดตาม
4.5.1 ภาพรวมเทมเพลตในตัว
เทมเพลตมาตรฐานนี้ให้การบันทึกเหตุการณ์ที่สมดุล เหมาะสำหรับการตรวจสอบทั่วไป ประกอบด้วยเหตุการณ์การดำเนินการคิวรีทั่วไป การเรียกใช้โพรซีเดอร์ที่เก็บไว้ และการติดตามข้อผิดพลาดพื้นฐาน ใช้เทมเพลตนี้เมื่อคุณต้องการการมองเห็นที่ครอบคลุมโดยไม่ทราบว่าต้องค้นหาอะไร
เทมเพลต TSQL มุ่งเน้นการดำเนินการคิวรีโดยเลือกเหตุการณ์น้อยที่สุด เทมเพลตนี้จะบันทึกเหตุการณ์ SQL:BatchCompleted และ RPC:Completed พร้อมคอลัมน์สำคัญสำหรับการวิเคราะห์ประสิทธิภาพ เทมเพลตนี้มีค่าใช้จ่ายที่ต่ำกว่าเทมเพลตมาตรฐาน
เทมเพลตการปรับแต่งจะปรับการเลือกเหตุการณ์ให้เหมาะสมที่สุดสำหรับการวิเคราะห์ Database Engine Tuning Advisor โดยจะบันทึกเหตุการณ์และคอลัมน์ที่จำเป็นสำหรับการวิเคราะห์เวิร์กโหลดและคำแนะนำดัชนี ใช้เทมเพลตนี้เมื่อเตรียมการติดตามสำหรับการปรับแต่งประสิทธิภาพอัตโนมัติ
เทมเพลต TSQL_Replay ประกอบด้วยเหตุการณ์และคอลัมน์ทั้งหมดที่จำเป็นสำหรับฟังก์ชันการเล่นซ้ำการติดตาม เทมเพลตนี้จะบันทึกรายละเอียดการดำเนินการที่ครอบคลุม ช่วยให้คุณสามารถจำลองเวิร์กโหลดที่บันทึกไว้ในสภาพแวดล้อมการทดสอบได้ เทมเพลตนี้สร้างไฟล์การติดตามขนาดใหญ่ขึ้นเนื่องจากการรวบรวมข้อมูลจำนวนมาก
4.5.2 การสร้างเทมเพลตที่กำหนดเอง
สร้างเทมเพลตที่กำหนดเองโดยทำตามขั้นตอนเหล่านี้:
- คลิก เนื้อไม่มีมัน -> แม่แบบ -> เทมเพลตใหม่ …
- กรอกชื่อที่บรรยายใน ชื่อเทมเพลตใหม่ สนาม
- ทางเลือกให้ตรวจสอบ สร้างเทมเพลตใหม่บนเทมเพลตที่มีอยู่แล้ว และเลือกเทมเพลตที่มีอยู่หากคุณไม่ต้องการสร้างจากศูนย์:
- คลิก การเลือกกิจกรรม แท็บปรับแต่งเทมเพลตการติดตามด้วยเหตุการณ์ คอลัมน์ และตัวกรองที่คุณต้องการเช่นเดียวกับคุณ ทำด้วยร่องรอยปกติ.
- คลิก ลด เพื่อบันทึกเทมเพลต
เทมเพลตการส่งออกเพื่อการแบ่งปันกับสมาชิกในทีมหรือเพื่อวัตถุประสงค์ในการสำรองข้อมูล:
- คลิก เนื้อไม่มีมัน -> แม่แบบ -> เทมเพลตการส่งออก.
- เลือกเทมเพลตที่คุณต้องการส่งออก
- นำทางไปยังตำแหน่งที่คุณต้องการบันทึก
- ป้อนชื่อไฟล์แล้วคลิก ลด.
- แชร์ไฟล์ *.tdf (SQL Server ไฟล์เทมเพลตโปรไฟเลอร์) พร้อมไฟล์อื่น ๆ SQL Server ผู้ใช้โปรไฟเลอร์
4.6 การบันทึกผลลัพธ์การติดตาม
โดยค่าเริ่มต้น SQL Server โปรไฟเลอร์จะแสดงเหตุการณ์ในหน้าต่างติดตาม แต่จะไม่บันทึกเหตุการณ์เหล่านั้น คุณสามารถเลือกที่จะบันทึกข้อมูลการติดตามลงในไฟล์หรือตารางใน คุณสมบัติของการติดตาม กล่องโต้ตอบเมื่อคุณสร้างการติดตามใหม่
4.6.1 บันทึกลงในไฟล์
- ตัว Vortex Indicator ได้ถูกนำเสนอลงในนิตยสาร คุณสมบัติของการติดตาม บทสนทนา, ตรวจสอบ บันทึกลงไฟล์.
- คลิกไอคอนโฟลเดอร์เพื่อเปิดเบราว์เซอร์ไฟล์
- นำทางไปยังตำแหน่งที่คุณต้องการบันทึก
- ป้อนชื่อไฟล์ที่มีนามสกุล .trc
- คลิก ลด.
- ชุด ตั้งค่าขนาดไฟล์สูงสุด เพื่อจำกัดขนาดไฟล์แต่ละไฟล์
- ทำให้สามารถ เปิดใช้งานการหมุนเวียนไฟล์ เพื่อสร้างไฟล์หลายไฟล์
- เปิดใช้งานได้ตามต้องการ เซิร์ฟเวอร์ประมวลผลข้อมูลการติดตาม สำหรับการติดตามฝั่งเซิร์ฟเวอร์
การจัดการขนาดไฟล์ช่วยป้องกันการใช้พื้นที่ดิสก์จนหมด ตั้งค่าขนาดไฟล์สูงสุดให้เหมาะสม เช่น 500 MB หรือ 1 GB ขึ้นอยู่กับพื้นที่ดิสก์ที่มีอยู่และระยะเวลาการติดตามที่คาดไว้ ระบบ File Rollover จะสร้างไฟล์ใหม่โดยอัตโนมัติเมื่อขนาดไฟล์ถึงขีดจำกัด โดยเพิ่มตัวเลขต่อท้ายชื่อไฟล์
4.6.2 บันทึกลงในตาราง
- ตัว Vortex Indicator ได้ถูกนำเสนอลงในนิตยสาร คุณสมบัติของการติดตาม บทสนทนา, ตรวจสอบ บันทึกลงในตาราง.
- การขอ ตารางจุดหมายปลายทาง กล่องโต้ตอบปรากฏขึ้น
- เลือกเซิร์ฟเวอร์จาก เซิร์ฟเวอร์ หล่นลง.
- เลือกฐานข้อมูลจาก ฐานข้อมูล หล่นลง.
- เลือกตารางที่มีอยู่หรือป้อนชื่อตารางใหม่ใน ตาราง สนาม
- คลิก OK เพื่อยืนยัน.
- ตั้งค่าได้ตามต้องการ ตั้งค่าจำนวนแถวสูงสุด เพื่อจำกัดขนาดตาราง
ข้อควรพิจารณาด้านประสิทธิภาพจะถูกนำมาใช้เมื่อบันทึกลงในตาราง การจัดเก็บตารางจะเพิ่มค่าใช้จ่ายเพิ่มเติมเมื่อเทียบกับการจัดเก็บไฟล์ เนื่องจาก SQL Server ต้องเขียนข้อมูลติดตามผ่านกลไกจัดเก็บข้อมูล ใช้พื้นที่เก็บข้อมูลตารางเมื่อคุณต้องการสืบค้นข้อมูลติดตามทันทีด้วย T-SQL
การเก็บรักษาข้อมูลมีความสำคัญอย่างยิ่งสำหรับการติดตามแบบตาราง ตั้งค่าขีดจำกัดแถวสูงสุดเพื่อป้องกันไม่ให้ตารางมีขนาดใหญ่เกินไป เก็บถาวรหรือลบข้อมูลการติดตามเก่าเป็นประจำเพื่อรักษาประสิทธิภาพ พิจารณาการแบ่งพาร์ติชันตารางการติดตามขนาดใหญ่เพื่อการจัดการที่ดีขึ้น
5. การดำเนินการและการจัดการ SQL Server ร่องรอย
5.1 การเริ่มต้น การหยุดชั่วคราว และการหยุดการติดตาม
จัดการการดำเนินการติดตามโดยใช้ปุ่มแถบเครื่องมือ:
- สีเขียว เริ่มต้น ปุ่มเริ่มบันทึกเหตุการณ์ตามการกำหนดค่าของคุณ
- คลิก หยุด เพื่อระงับการเก็บรวบรวมข้อมูลชั่วคราวโดยไม่ตัดการเชื่อมต่อ
- คลิก หยุด เพื่อสิ้นสุดการติดตามและปิดการเชื่อมต่อ
ผ่านรายการเมนู:
โดยการคลิกขวาที่รายการใดๆ ในหน้าต่างติดตาม:
การจัดการวงจรชีวิตการติดตามส่งผลกระทบต่อทรัพยากรเซิร์ฟเวอร์ การติดตามที่ใช้งานอยู่จะใช้หน่วยความจำและพลังประมวลผลตามสัดส่วนของปริมาณเหตุการณ์ที่บันทึกได้ หยุดการติดตามชั่วคราวในช่วงเวลาที่ไม่จำเป็นต้องตรวจสอบเพื่อลดค่าใช้จ่าย และหยุดการติดตามทั้งหมดเมื่อการวิเคราะห์เสร็จสิ้นเพื่อปลดปล่อยทรัพยากร
การติดตามฝั่งไคลเอ็นต์จำเป็นต้องมีการเชื่อมต่อ Profiler ที่ใช้งานอยู่ การปิด SQL Server หน้าต่าง Profiler จะหยุดการติดตามฝั่งไคลเอ็นต์ทันที ย่อขนาดหน้าต่าง Profiler แทนที่จะปิดมันลง เพื่อให้การติดตามยังคงทำงานต่อไปในขณะที่ทำงานในแอปพลิเคชันอื่น
5.2 การตรวจสอบการติดตามแบบเรียลไทม์
ตรวจสอบเหตุการณ์ที่บันทึกไว้แบบเรียลไทม์ในหน้าต่างติดตามหลัก แต่ละแถวแสดงถึงเหตุการณ์เดียว โดยคอลัมน์แสดงคุณสมบัติของเหตุการณ์ ตารางจะอัปเดตอย่างต่อเนื่องระหว่างการติดตามที่กำลังทำงานอยู่ โดยจะแสดงเหตุการณ์ล่าสุดไว้ด้านล่างสุดตามค่าเริ่มต้น
ระบุรูปแบบและปัญหาโดยการสังเกตความถี่และลักษณะของเหตุการณ์ เหตุการณ์ที่มีระยะเวลานานบ่งชี้ถึงปัญหาด้านประสิทธิภาพ เหตุการณ์ข้อผิดพลาดที่เกิดขึ้นบ่อยครั้งบ่งชี้ถึงปัญหาของแอปพลิเคชัน กิจกรรมการเข้าสู่ระบบที่ผิดปกติอาจส่งสัญญาณถึงปัญหาด้านความปลอดภัย การตรวจสอบแบบเรียลไทม์ช่วยให้สามารถตอบสนองต่อปัญหาที่เกิดขึ้นได้ทันที
เลื่อนดูเหตุการณ์ที่บันทึกไว้เพื่อตรวจสอบเหตุการณ์เฉพาะเจาะจง คลิกที่แถวใดก็ได้เพื่อเลือกเหตุการณ์และดูรายละเอียดทั้งหมด ดับเบิลคลิกที่เหตุการณ์เพื่อเปิดกล่องโต้ตอบคุณสมบัติโดยละเอียดที่แสดงค่าของคอลัมน์ทั้งหมด ใช้ฟีเจอร์ล็อกการเลื่อนเพื่อป้องกันไม่ให้ระบบเลื่อนอัตโนมัติขณะตรวจสอบเหตุการณ์ในอดีต
5.3 การจัดการการติดตามพร้อมกันหลายรายการ
การรันการติดตามหลายรายการพร้อมกันช่วยเพิ่มความยืดหยุ่นสำหรับสถานการณ์การตรวจสอบที่ซับซ้อน สร้างการติดตามแยกต่างหากสำหรับกิจกรรมฐานข้อมูลในด้านต่างๆ เช่น การติดตามหนึ่งสำหรับการตรวจสอบประสิทธิภาพ และอีกการติดตามหนึ่งสำหรับการตรวจสอบความปลอดภัย การติดตามแต่ละรายการจะทำงานแยกกันโดยมีการกำหนดค่าของตัวเอง
การจัดสรรทรัพยากรมีความสำคัญอย่างยิ่งเมื่อมีการติดตามหลายรายการ การติดตามที่ใช้งานอยู่แต่ละครั้งจะใช้หน่วยความจำ CPU และอาจรวมถึง I/O ของดิสก์ด้วย จำกัดจำนวนการติดตามพร้อมกันและตรวจสอบให้แน่ใจว่าการติดตามแต่ละรายการใช้ตัวกรองที่เหมาะสมเพื่อลดภาระงาน ตรวจสอบประสิทธิภาพของเซิร์ฟเวอร์ขณะใช้งานการติดตามหลายรายการ
ประสานเวลาการติดตามเพื่อป้องกันการติดตามที่มีค่าใช้จ่ายสูงซ้อนทับกัน หากเป็นไปได้ ให้ดำเนินการติดตามที่ใช้ทรัพยากรมากในช่วงเวลาที่มีกิจกรรมน้อย กำหนดเวลาการติดตามที่แตกต่างกันในเวลาที่ต่างกัน แทนที่จะดำเนินการทุกอย่างพร้อมกัน
5.4 การติดตามฝั่งไคลเอ็นต์เทียบกับการติดตามฝั่งเซิร์ฟเวอร์
โดยค่าเริ่มต้น การติดตามที่สร้างขึ้นใหม่จะเป็นการติดตามฝั่งไคลเอ็นต์ ซึ่งต้องมีการเชื่อมต่อที่ใช้งานอยู่จาก SQL Server โปรแกรม Profiler เชื่อมต่อกับเซิร์ฟเวอร์ฐานข้อมูล การติดตามจะหยุดทันทีหากการเชื่อมต่อขาดหายหรือโปรแกรม Profiler ถูกปิด
คุณยังสามารถสร้างการติดตามฝั่งเซิร์ฟเวอร์ซึ่งทำงานบน SQL Server อินสแตนซ์โดยไม่ต้องเชื่อมต่อ Profiler ที่ใช้งานอยู่ การติดตามฝั่งเซิร์ฟเวอร์ยังคงทำงานต่อไปแม้หลังจากปิดแล้ว SQL Server โปรไฟเลอร์ เขียนข้อมูลไปยังตำแหน่งไฟล์ที่ระบุ
ในการสร้างการติดตามด้านเซิร์ฟเวอร์:
- คลิก ไฟล์ -> ร่องรอยใหม่ …
- ตัว Vortex Indicator ได้ถูกนำเสนอลงในนิตยสาร คุณสมบัติของการติดตาม บทสนทนา, ตรวจสอบ บันทึกลงไฟล์
- ตั้งค่าตำแหน่งไฟล์และการตั้งค่าอื่น ๆ
- ทำให้สามารถ เซิร์ฟเวอร์ประมวลผลข้อมูลการติดตาม เพื่อสร้างการติดตามด้านเซิร์ฟเวอร์
ผลกระทบด้านประสิทธิภาพจะแตกต่างกันอย่างมากระหว่างประเภทการติดตาม การติดตามฝั่งไคลเอ็นต์ต้องส่งข้อมูลผ่านเครือข่ายไปยังอินเทอร์เฟซ Profiler ซึ่งจะเพิ่มความล่าช้าและการใช้แบนด์วิดท์ การติดตามฝั่งเซิร์ฟเวอร์จะทำให้เกิดโอเวอร์เฮดน้อยลงเนื่องจากข้อมูลถูกเขียนลงดิสก์บนเซิร์ฟเวอร์โดยตรง
ใช้การติดตามฝั่งไคลเอ็นต์สำหรับการแก้ไขปัญหาเฉพาะหน้า การวินิจฉัยอย่างรวดเร็ว และสถานการณ์ที่การแสดงผลภาพทันทีมีความสำคัญ เลือกใช้การติดตามฝั่งเซิร์ฟเวอร์สำหรับการตรวจสอบการทำงานในสภาพแวดล้อมการผลิต การบันทึกข้อมูลระยะยาว และสถานการณ์ที่ต้องการการทำงานโดยอัตโนมัติ
6. การวิเคราะห์ SQL Server ข้อมูลโปรไฟล์
6.1 การเปิดและตรวจสอบร่องรอยที่บันทึกไว้
โหลดไฟล์ติดตามที่บันทึกไว้โดยใช้ขั้นตอนเหล่านี้:
- ยิง SQL Server Profiler
- คลิก เนื้อไม่มีมัน -> จุดเปิด -> ไฟล์ติดตาม.
- นำทางไปยังตำแหน่งไฟล์ติดตาม
- เลือกไฟล์ .trc แล้วคลิก จุดเปิด.
- ข้อมูลการติดตามโหลดเข้าสู่หน้าต่างหลัก
โหลดตารางการติดตามตามกระบวนการนี้:
- คลิก เนื้อไม่มีมัน -> จุดเปิด -> ตารางการติดตาม.
- เชื่อมต่อกับเซิร์ฟเวอร์ที่โฮสต์ตารางการติดตาม (trace table)
- เลือกฐานข้อมูลจาก ฐานข้อมูล หล่นลง.
- เลือกตารางจาก ตาราง หล่นลง.
- คลิก OK เพื่อโหลดข้อมูล
6.2 การกรองและการค้นหาข้อมูลการติดตาม
6.2.1 การกรองข้อมูลหลังการจับภาพ
ใช้ตัวกรองกับข้อมูลการติดตามที่โหลดโดยใช้ขั้นตอนเหล่านี้:
- คลิก Edit -> หา หรือกด Ctrl + F.
- ป้อนข้อความค้นหาใน สิ่งที่ค้นหา สนาม
- เลือกคอลัมน์ที่จะค้นหาจาก มองใน หล่นลง.
- คลิก ค้นหาถัดไป เพื่อค้นหาเหตุการณ์ที่ตรงกัน
การกรองแบบคอลัมน์จะปรับแต่งข้อมูลที่แสดงโดยไม่ต้องบันทึกเหตุการณ์ซ้ำ คลิกขวาที่ส่วนหัวคอลัมน์ใดก็ได้ แล้วเลือกตัวเลือกตัวกรองจากเมนูบริบท ป้อนเกณฑ์ตัวกรองเพื่อแสดงเฉพาะแถวที่ตรงกัน วิธีนี้ช่วยเร่งการวิเคราะห์โดยการซ่อนเหตุการณ์ที่ไม่เกี่ยวข้อง
6.2.2 การค้นหาเหตุการณ์เฉพาะ
ฟังก์ชันการค้นหาช่วยค้นหาเหตุการณ์เฉพาะเจาะจงในไฟล์ติดตามขนาดใหญ่ ใช้กล่องโต้ตอบค้นหาเพื่อค้นหาตามเนื้อหาข้อความ ประเภทเหตุการณ์ หรือค่าคอลัมน์ นิพจน์ทั่วไปช่วยให้สามารถค้นหารูปแบบที่ซับซ้อนได้เมื่อจำเป็น
บุ๊กมาร์กเหตุการณ์สำคัญเพื่อใช้อ้างอิงอย่างรวดเร็วระหว่างการวิเคราะห์ คลิกขวาที่เหตุการณ์ที่น่าสนใจและเลือกตัวเลือกบุ๊กมาร์กเพื่อทำเครื่องหมายไว้ นำทางระหว่างบุ๊กมาร์กต่างๆ โดยใช้แป้นพิมพ์ลัดหรือคำสั่งเมนู ซึ่งช่วยให้เปรียบเทียบเหตุการณ์ที่เกี่ยวข้องได้ง่ายขึ้น
6.3 การจัดกลุ่มและรวบรวมเหตุการณ์
จัดกลุ่มกิจกรรมตามค่าคอลัมน์เพื่อระบุรูปแบบและสรุปกิจกรรม คลิกขวาที่ส่วนหัวคอลัมน์ใดก็ได้ แล้วเลือก จัดกลุ่มตามคอลัมน์นี้ เพื่อจัดระเบียบกิจกรรม มุมมองแบบกลุ่มจะรวมกิจกรรมที่คล้ายกันเข้าด้วยกัน ทำให้มองเห็นรูปแบบโดยรวมได้ง่ายขึ้น
มุมมองแบบรวมแสดงข้อมูลสรุปทางสถิติของข้อมูลการติดตาม จัดกลุ่มตาม TextData เพื่อดูจำนวนครั้งที่แต่ละคิวรีถูกดำเนินการ จัดกลุ่มตาม LoginName เพื่อดูสรุปกิจกรรมของแต่ละผู้ใช้ การรวมแสดงรูปแบบที่ไม่ชัดเจนทันทีในรายการเหตุการณ์โดยละเอียด
ขยายและยุบกลุ่มเพื่อเจาะลึกไปยังหมวดหมู่เฉพาะ คลิกไอคอนบวกและลบที่อยู่ข้างหัวกลุ่มเพื่อแสดงหรือซ่อนเหตุการณ์ที่จัดกลุ่มไว้ มุมมองแบบลำดับชั้นนี้ช่วยให้การวิเคราะห์จากบนลงล่างทำได้ง่ายขึ้น โดยเริ่มต้นจากรูปแบบระดับสูงและเจาะลึกลงไปในรายละเอียด
6.4 การแยกแบบสอบถาม SQL จากการติดตาม
แยกแบบสอบถามจากข้อมูลการติดตามโดยทำตามขั้นตอนเหล่านี้:
- ค้นหาคำค้นหาที่สนใจในตารางติดตาม
- คลิกแถวเพื่อเลือกเหตุการณ์
- ดูข้อความสอบถามฉบับสมบูรณ์ในแผงด้านล่าง
- ข่าวประชาสัมพันธ์ Ctrl + A เพื่อเลือกข้อความสอบถามทั้งหมด
- ข่าวประชาสัมพันธ์ CTRL + C เพื่อคัดลอกข้อความสอบถาม
- วางคำถามลงใน Management Studio เพื่อวิเคราะห์เพิ่มเติม
ระบุคิวรีที่มีปัญหาโดยการเรียงลำดับตามคอลัมน์ประสิทธิภาพ คลิกที่ส่วนหัวคอลัมน์ระยะเวลาเพื่อเรียงลำดับตามเวลาดำเนินการ คิวรีที่ช้าที่สุดจะปรากฏที่ด้านบนหรือด้านล่างขึ้นอยู่กับทิศทางการเรียงลำดับ ในทำนองเดียวกัน ให้เรียงลำดับตาม CPU, การอ่าน หรือการเขียน เพื่อระบุการดำเนินการที่ใช้ทรัพยากรมาก
ส่งออกแบบสอบถามสำหรับการทดสอบโดยการคัดลอกจากการติดตามไปยังหน้าต่างแบบสอบถาม ปรับเปลี่ยนแบบสอบถามที่แยกออกมาเพื่อทดสอบกลยุทธ์การเพิ่มประสิทธิภาพ เปรียบเทียบแผนการดำเนินการและตัวชี้วัดประสิทธิภาพระหว่างเวอร์ชันดั้งเดิมและเวอร์ชันที่เพิ่มประสิทธิภาพแล้ว
6.5 การเชื่อมโยงเหตุการณ์และการทำความเข้าใจกระบวนการดำเนินการ
ความสัมพันธ์ระหว่างเหตุการณ์หลักและเหตุการณ์ย่อยแสดงให้เห็นถึงลำดับชั้นของการดำเนินการ เหตุการณ์ SQL:BatchStarting เป็นเหตุการณ์หลักของเหตุการณ์ SQL:StmtStarting ซึ่งเป็นเหตุการณ์หลักของเหตุการณ์การดำเนินการของโปรซีเดอร์ การทำความเข้าใจความสัมพันธ์เหล่านี้ช่วยให้สามารถติดตามเส้นทางการดำเนินการที่สมบูรณ์ผ่านโค้ดของคุณได้
การติดตามธุรกรรมจะเชื่อมโยงเหตุการณ์ที่เกี่ยวข้องกันในแต่ละช่วงเวลา ใช้คอลัมน์ SPID เพื่อจัดกลุ่มเหตุการณ์ตามเซสชัน ภายในเซสชัน เหตุการณ์จะเกิดขึ้นตามลำดับเวลา ซึ่งแสดงลำดับของการดำเนินการ มุมมองนี้แสดงให้เห็นว่าการดำเนินการต่างๆ โต้ตอบกันอย่างไรภายในธุรกรรม
เชื่อมโยงเหตุการณ์โดยการตรวจสอบค่าคอลัมน์ที่ใช้ร่วมกัน เหตุการณ์ที่มี SPID เหมือนกันเกิดขึ้นในเซสชันเดียวกัน เหตุการณ์ที่มี ApplicationName เดียวกันมาจากแอปพลิเคชันเดียวกัน ใช้ความสัมพันธ์เหล่านี้เพื่อทำความเข้าใจสถานการณ์การทำงานที่ซับซ้อน
7 ร่วมกัน SQL Server กรณีการใช้งานโปรไฟเลอร์
7.1 การแก้ไขปัญหาประสิทธิภาพ
7.1.1 การระบุแบบสอบถามที่ช้า
จับภาพแบบสอบถามที่ช้าโดยใช้การกำหนดค่าต่อไปนี้:
- สร้างร่องรอยใหม่โดยใช้ ทีเอสคิวแอล แบบ
- ตัว Vortex Indicator ได้ถูกนำเสนอลงในนิตยสาร การเลือกกิจกรรม แท็บ ตรวจสอบ SQL:BatchCompleted และ RPC:เสร็จสมบูรณ์ ถูกเลือก
- คลิก ตัวกรองคอลัมน์.
- เลือก ระยะเวลา จากรายการคอลัมน์
- ใส่ 1000000 ลงใน มากกว่าหรือเท่ากับ ฟิลด์สำหรับจับแบบสอบถามที่ใช้เวลามากกว่า 1 วินาที
- คลิก OK และเริ่มการติดตาม
- ดำเนินการติดตามระหว่างช่วงที่มีการใช้งานสูงสุด
- หยุดการติดตามและเรียงลำดับตามระยะเวลาเพื่อระบุแบบสอบถามที่ช้าที่สุด
การวิเคราะห์ตามระยะเวลาจะเผยให้เห็นรูปแบบเวลาดำเนินการ เรียงลำดับเหตุการณ์ที่บันทึกไว้ตามคอลัมน์ระยะเวลาเพื่อดูการดำเนินการที่ใช้เวลานานที่สุดก่อน ตรวจสอบคอลัมน์ TextData สำหรับเหตุการณ์เหล่านี้เพื่อระบุคิวรีที่ทำให้เกิดความล่าช้า
คิวรีที่ใช้ CPU และ I/O อย่างหนักจำเป็นต้องใช้วิธีการปรับแต่งประสิทธิภาพที่แตกต่างกัน เรียงลำดับตามคอลัมน์ CPU เพื่อค้นหาคิวรีที่เชื่อมโยงกับโปรเซสเซอร์ซึ่งจำเป็นต้องปรับปรุงอัลกอริทึม เรียงลำดับตามคอลัมน์ Reads หรือ Writes เพื่อระบุคิวรีที่เชื่อมโยงกับ I/O ซึ่งได้รับประโยชน์จากการทำดัชนีหรือการเขียนคิวรีใหม่
7.1.2 การตรวจจับการบล็อคและเดดล็อก
กำหนดค่าการตรวจจับการบล็อคโดยทำตามขั้นตอนเหล่านี้:
- สร้างร่องรอยใหม่
- ตัว Vortex Indicator ได้ถูกนำเสนอลงในนิตยสาร การเลือกกิจกรรม แท็บ ขยาย ล็อค.
- เลือก ล็อค:เดดล็อค และ ล็อค: โซ่ล็อคตาย.
- แสดง ข้อผิดพลาดและคำเตือน.
- เลือก รายงานกระบวนการที่ถูกบล็อค.
- รวมคอลัมน์: SPID, ข้อมูลข้อความ, ชื่อฐานข้อมูล, ชื่อล็อกอิน.
- เริ่มการติดตามและเฝ้าสังเกตเหตุการณ์การล็อก
การตรวจสอบเหตุการณ์การล็อกเผยให้เห็นปัญหาการทำงานพร้อมกันที่ส่งผลต่อประสิทธิภาพของแอปพลิเคชัน เหตุการณ์ล็อก:เดดล็อกบ่งชี้ว่าเมื่อใด SQL Server ตรวจพบและแก้ไขสถานการณ์เดดล็อก เหตุการณ์ลูกโซ่ล็อก:เดดล็อก แสดงกระบวนการที่เกี่ยวข้องกับเดดล็อก
กราฟเดดล็อกแสดงภาพสถานการณ์เดดล็อก เมื่อเกิดเหตุการณ์เดดล็อก คอลัมน์ TextData จะมี XML ที่อธิบายเหตุการณ์เดดล็อก คัดลอก XML นี้และเปิดใน SQL Server Management Studio เพื่อดูแผนภาพเดดล็อกแบบกราฟิกที่แสดงให้เห็นว่ากระบวนการใดบ้างที่บล็อกซึ่งกันและกัน
7.1.3 การค้นหาดัชนีที่หายไป
จับภาระงานสำหรับการวิเคราะห์ดัชนีโดยใช้ขั้นตอนเหล่านี้:
- สร้างร่องรอยใหม่โดยใช้ การปรับเสียง แบบ
- กำหนดค่าการติดตามเพื่อบันทึกลงในไฟล์
- รันการติดตามระหว่างช่วงเวิร์กโหลดตัวแทน
- รวบรวมกิจกรรมอย่างน้อยหลายชั่วโมง
- หยุดการติดตามและบันทึกไฟล์
- เปิดตัวที่ปรึกษาการปรับแต่งฐานข้อมูลเครื่องยนต์
- เลือกไฟล์ติดตามเป็นแหล่งที่มาของเวิร์กโหลด
- ดำเนินการวิเคราะห์เพื่อรับคำแนะนำดัชนี
การผสานรวมกับ Database Engine Tuning Advisor จะช่วยแนะนำดัชนีโดยอัตโนมัติ Tuning Advisor จะวิเคราะห์ปริมาณงานที่บันทึกไว้และแนะนำดัชนีที่จะช่วยปรับปรุงประสิทธิภาพ ตรวจสอบคำแนะนำอย่างรอบคอบก่อนนำไปใช้ โดยคำนึงถึงค่าใช้จ่ายในการจัดเก็บข้อมูลและค่าบำรุงรักษา
7.2 การแก้ไขปัญหาแอปพลิเคชัน
7.2.1 การแก้ไขข้อผิดพลาดของแอปพลิเคชัน
ติดตามข้อผิดพลาดของแอปพลิเคชันโดยใช้การกำหนดค่านี้:
- สร้างร่องรอยใหม่
- แสดง ข้อผิดพลาดและคำเตือน ในแท็บการเลือกกิจกรรม
- เลือก ข้อยกเว้น, ข้อความแสดงข้อผิดพลาดของผู้ใช้และ ความสนใจ.
- รวมคอลัมน์: ความผิดพลาด, ข้อมูลข้อความ, ชื่อแอปพลิเคชัน, SPID.
- กรองตาม ชื่อแอปพลิเคชัน เพื่อให้มุ่งเน้นไปที่การใช้งานของคุณ
- เริ่มการติดตามและจำลองสถานการณ์ข้อผิดพลาด
- ตรวจสอบเหตุการณ์ข้อผิดพลาดที่บันทึกไว้เพื่อหาข้อมูลในการวินิจฉัย
การติดตามข้อผิดพลาดจะเปิดเผยรายละเอียดข้อยกเว้นที่มักซ่อนจากแอปพลิเคชัน คอลัมน์ข้อผิดพลาดประกอบด้วย SQL Server หมายเลขข้อผิดพลาด คอลัมน์ TextData จะแสดงข้อความแสดงข้อผิดพลาดและแบบสอบถามที่ทำให้เกิดข้อผิดพลาด คอลัมน์ความรุนแรงจะแสดงระดับความรุนแรงของข้อผิดพลาด
การตรวจสอบข้อยกเว้นจะตรวจจับปัญหารันไทม์ รวมถึงการละเมิดข้อจำกัด ข้อผิดพลาดในการอนุญาต และเหตุการณ์หมดเวลา เชื่อมโยงเหตุการณ์ข้อผิดพลาดกับเหตุการณ์คิวรีก่อนหน้าเพื่อทำความเข้าใจว่าอะไรเป็นสาเหตุของข้อยกเว้น
7.2.2 การติดตามการสื่อสารระหว่างแอปพลิเคชันกับฐานข้อมูล
ตรวจสอบกิจกรรมแอปพลิเคชันโดยทำตามขั้นตอนเหล่านี้:
- สร้างร่องรอยใหม่โดยใช้ Standard แบบ
- คลิก ตัวกรองคอลัมน์.
- เลือก ชื่อแอปพลิเคชัน และกรอกชื่อแอปพลิเคชันของคุณลงใน Like สนาม
- กรองตามทางเลือก ชื่อโฮสต์ เพื่อแยกเซิร์ฟเวอร์เฉพาะ
- เริ่มการติดตามระหว่างการทำงานของแอปพลิเคชัน
- ตรวจสอบเหตุการณ์ที่บันทึกไว้เพื่อดูการโต้ตอบกับฐานข้อมูลทั้งหมด
การกรองชื่อแอปพลิเคชันจะแยกแบบสอบถามจากแอปพลิเคชันเฉพาะ SQL Server ตั้งชื่อแอปพลิเคชันจากสตริงการเชื่อมต่อ ทำให้ง่ายต่อการติดตามแอปพลิเคชันแต่ละตัวในสภาพแวดล้อมที่มีหลายแอปพลิเคชัน ตรวจสอบว่าสตริงการเชื่อมต่อของคุณมีพารามิเตอร์ชื่อแอปพลิเคชันเพื่อให้การกรองมีประสิทธิภาพ
การติดตามการเชื่อมต่อจะแสดงวงจรชีวิตของเซสชัน รวมถึงเหตุการณ์การเข้าสู่ระบบ การดำเนินการสอบถาม และการออกจากระบบ ตรวจสอบอัตราการสร้างการเชื่อมต่อเพื่อระบุปัญหาการรวมกลุ่มการเชื่อมต่อ การเชื่อมต่อที่มากเกินไปบ่งชี้ถึงปัญหาการกำหนดค่าแอปพลิเคชันที่อาจเกิดขึ้น
7.2.3 การตรวจสอบพฤติกรรมการใช้งาน
ตรวจสอบพฤติกรรมแอปพลิเคชันที่คาดหวังโดยใช้การวิเคราะห์การติดตาม บันทึกการดำเนินการฐานข้อมูลทั้งหมดระหว่างธุรกรรมทางธุรกิจ และตรวจสอบการดำเนินการคิวรีที่ถูกต้องตามลำดับที่ถูกต้อง เปรียบเทียบคิวรีที่บันทึกจริงกับพฤติกรรมที่คาดหวังเพื่อระบุความคลาดเคลื่อน
การตรวจสอบพารามิเตอร์ช่วยให้มั่นใจว่าแอปพลิเคชันส่งค่าที่ถูกต้องไปยังโพรซีเดอร์ที่จัดเก็บไว้และคิวรีแบบพารามิเตอร์ ตรวจสอบข้อความคิวรีที่บันทึกไว้เพื่อยืนยันว่าค่าพารามิเตอร์ตรงตามที่คาดหวัง พารามิเตอร์ที่ไม่ถูกต้องมักทำให้เกิดข้อผิดพลาดทางตรรกะที่แสดงออกมาเป็นผลลัพธ์ทางธุรกิจที่ไม่ถูกต้อง
7.3 การตรวจสอบความปลอดภัย
7.3.1 การตรวจสอบความพยายามในการเข้าสู่ระบบ
กำหนดค่าการตรวจสอบการเข้าสู่ระบบโดยใช้ขั้นตอนเหล่านี้:
- สร้างร่องรอยใหม่
- แสดง ตรวจสอบการรักษาความปลอดภัย ในแท็บการเลือกกิจกรรม
- เลือก การเข้าสู่ระบบการตรวจสอบ, การตรวจสอบการออกจากระบบและ การเข้าสู่ระบบการตรวจสอบล้มเหลว.
- รวมคอลัมน์: ชื่อล็อกอิน, ชื่อโฮสต์, ชื่อแอปพลิเคชัน, เวลาเริ่มต้น.
- เริ่มการติดตามเพื่อตรวจสอบกิจกรรมการตรวจสอบสิทธิ์
- ตรวจสอบเหตุการณ์การเข้าสู่ระบบที่ล้มเหลวเพื่อดูปัญหาความปลอดภัยที่อาจเกิดขึ้น
การเข้าสู่ระบบที่สำเร็จและล้มเหลวช่วยให้สามารถติดตามการตรวจสอบสิทธิ์ได้อย่างครอบคลุม เหตุการณ์การตรวจสอบการเข้าสู่ระบบจะบันทึกความพยายามในการตรวจสอบสิทธิ์ที่สำเร็จ พร้อมข้อมูลประจำตัวผู้ใช้และข้อมูลแหล่งที่มา เหตุการณ์การตรวจสอบการเข้าสู่ระบบล้มเหลวบ่งชี้ความพยายามเข้าสู่ระบบที่ไม่สำเร็จ ซึ่งอาจหมายถึงการโจมตีหรือปัญหาการกำหนดค่า
การติดตามการตรวจสอบสิทธิ์จะเผยให้เห็นรูปแบบการเข้าถึงฐานข้อมูล ตรวจสอบความถี่ในการเข้าสู่ระบบเพื่อตรวจจับกิจกรรมที่ผิดปกติ การพยายามเข้าสู่ระบบที่ล้มเหลวหลายครั้งแล้วเข้าสู่ระบบสำเร็จ อาจบ่งชี้ว่าข้อมูลประจำตัวถูกบุกรุก การเข้าสู่ระบบที่ล้มเหลวจากตำแหน่งที่ไม่คาดคิดควรได้รับการตรวจสอบ
7.3.2 การติดตามการเข้าถึงและการแก้ไขข้อมูล
ตรวจสอบการเข้าถึงข้อมูลโดยใช้การกำหนดค่านี้:
- สร้างร่องรอยใหม่
- แสดง ตรวจสอบการรักษาความปลอดภัย.
- เลือก ตรวจสอบการเข้าถึงวัตถุฐานข้อมูล.
- รวมคอลัมน์: ชื่อวัตถุ, ชื่อล็อกอิน, ข้อมูลข้อความ, ชื่อฐานข้อมูล.
- กรองตาม ชื่อวัตถุ เพื่อตรวจสอบตารางที่ละเอียดอ่อนโดยเฉพาะ
- เริ่มการติดตามเพื่อบันทึกความพยายามในการเข้าถึง
การติดตาม SELECT, INSERT, UPDATE และ DELETE ช่วยให้สามารถตรวจสอบการแก้ไขข้อมูลได้อย่างครอบคลุม บันทึกเหตุการณ์ SQL:BatchCompleted ด้วยตัวกรองที่เหมาะสมเพื่อตรวจสอบการดำเนินการเข้าถึงข้อมูลทั้งหมด กรองตาม ObjectName หรือ TextData เพื่อเน้นเฉพาะตารางที่ละเอียดอ่อน
การเข้าถึงข้อมูลที่ละเอียดอ่อนจำเป็นต้องมีการตรวจสอบอย่างรอบคอบเพื่อให้มั่นใจว่าเป็นไปตามนโยบายความปลอดภัย จัดทำร่องรอยสำหรับตารางที่มีข้อมูลส่วนบุคคล ข้อมูลทางการเงิน หรือข้อมูลที่เป็นความลับอื่นๆ โดยเฉพาะ ตรวจสอบรูปแบบการเข้าถึงเป็นประจำเพื่อระบุการเข้าถึงข้อมูลที่ไม่เหมาะสม
ตรวจจับกิจกรรมที่น่าสงสัยโดยการวิเคราะห์รูปแบบคิวรีในร่องรอยที่บันทึกไว้ มองหาคิวรีที่ผิดปกติซึ่งไม่ตรงกับพฤติกรรมการใช้งานปกติ คำสั่ง SELECT ที่ไม่มีคำสั่ง WHERE ดึงข้อมูลทั้งตารางอาจบ่งชี้ถึงความพยายามในการขโมยข้อมูล
ความพยายามยกระดับสิทธิ์จะปรากฏเป็นข้อผิดพลาดเกี่ยวกับสิทธิ์ หรือความพยายามในการรันคำสั่งผู้ดูแลระบบ ตรวจสอบคิวรีที่พยายามเข้าถึงตารางระบบ แก้ไขการกำหนดค่าเซิร์ฟเวอร์ หรือสร้างบัญชีที่มีสิทธิ์ กรองเหตุการณ์ข้อผิดพลาดและตรวจสอบคอลัมน์ TextData เพื่อหากิจกรรมที่น่าสงสัย
7.4 การวางแผนกำลังการผลิตและการวิเคราะห์ปริมาณงาน
สร้างเกณฑ์มาตรฐานโดยบันทึกปริมาณงานตัวแทนระหว่างการปฏิบัติงานปกติ ดำเนินการติดตามในช่วงเวลาทำการปกติเพื่อทำความเข้าใจรูปแบบกิจกรรมมาตรฐาน บันทึกการติดตามเหล่านี้เป็นเกณฑ์มาตรฐานประสิทธิภาพสำหรับการเปรียบเทียบในอนาคต
การระบุการใช้งานสูงสุดจะเผยให้เห็นช่วงเวลาที่ระบบของคุณมีภาระงานสูงสุด บันทึกการติดตามในช่วงเวลาต่างๆ เช่น เวลาทำการ ช่วงเวลาการประมวลผลแบบกลุ่ม และกิจกรรมหลังเวลาทำการ วิเคราะห์จำนวนเหตุการณ์และการใช้ทรัพยากรเพื่อระบุช่วงเวลาที่ใช้งานสูงสุด
รูปแบบการใช้ทรัพยากรเกิดขึ้นจากการวิเคราะห์ปริมาณงาน จัดกลุ่มเหตุการณ์ตามช่วงเวลาเพื่อดูการกระจายกิจกรรมตลอดทั้งวัน คำนวณค่า CPU, I/O ของดิสก์ และเมตริกระยะเวลาโดยรวมเพื่อประเมินปริมาณการใช้ทรัพยากร ใช้ข้อมูลนี้เพื่อวางแผนการอัปเกรดความจุหรือระบุโอกาสในการเพิ่มประสิทธิภาพ
8. ขั้นสูง SQL Server เทคนิคโปรไฟเลอร์
8.1 การสร้างการติดตามฝั่งเซิร์ฟเวอร์ด้วย T-SQL
8.1.1 การใช้ sp_trace_create และขั้นตอนที่เกี่ยวข้อง
สร้างการติดตามฝั่งเซิร์ฟเวอร์ด้วยโปรแกรมโดยใช้กระบวนการจัดเก็บ T-SQL วิธีนี้ช่วยให้สามารถสร้างและจัดการการติดตามได้โดยอัตโนมัติโดยไม่ต้อง SQL Server อินเทอร์เฟซกราฟิกของโปรไฟเลอร์
กำหนดการติดตามฝั่งเซิร์ฟเวอร์โดยใช้โค้ดตัวอย่างนี้:
- ประกาศตัวแปรสำหรับ ID การติดตามและเส้นทางไฟล์
- เรียก sp_trace_create เพื่อสร้างการติดตามใหม่
- ใช้ sp_trace_setevent เพื่อเพิ่มเหตุการณ์และคอลัมน์
- เลือกใช้ sp_trace_setfilter เพื่อกำหนดค่าตัวกรอง
- เรียกใช้ฟังก์ชัน sp_trace_setstatus เพื่อเริ่มการติดตาม (trace)
ขั้นตอน sp_trace_create จะเริ่มต้นนิยามการติดตามใหม่ ระบุเส้นทางไฟล์เอาต์พุต ขนาดไฟล์สูงสุด และตัวเลือก rollover ขั้นตอนนี้จะส่งคืน ID การติดตามที่ใช้ในการเรียกใช้ขั้นตอนถัดไปเพื่อกำหนดค่าการติดตาม
เพิ่มเหตุการณ์โดยใช้โพรซีเดอร์ sp_trace_setevent ระบุรหัสการติดตาม รหัสเหตุการณ์ และรหัสคอลัมน์สำหรับแต่ละชุดข้อมูลเหตุการณ์-คอลัมน์ที่คุณต้องการบันทึก เรียกใช้โพรซีเดอร์นี้หลายๆ ครั้งเพื่อสร้างการกำหนดค่าการติดตามที่สมบูรณ์
กำหนดค่าตัวกรองด้วยโพรซีเดอร์ sp_trace_setfilter ระบุ ID การติดตาม, ID คอลัมน์, ตัวดำเนินการเชิงตรรกะ, ตัวดำเนินการเปรียบเทียบ และค่าตัวกรอง การเรียกใช้ตัวกรองหลายรายการรวมกันเพื่อสร้างเกณฑ์ตัวกรองที่ซับซ้อน
เริ่มการติดตามโดยเรียกใช้ sp_trace_setstatus ด้วยค่าสถานะ 1 หยุดการติดตามโดยเรียกใช้โปรซีเดอร์เดียวกันด้วยค่าสถานะ 0 ลบคำจำกัดความการติดตามโดยเรียกใช้ด้วยค่าสถานะ 2
8.1.2 ข้อดีของการติดตามฝั่งเซิร์ฟเวอร์
การลดค่าใช้จ่ายของไคลเอนต์ทำให้การติดตามฝั่งเซิร์ฟเวอร์เหมาะอย่างยิ่งสำหรับการตรวจสอบการใช้งานจริง เซิร์ฟเวอร์ฐานข้อมูลจัดการการติดตามทั้งหมดโดยไม่ใช้ทรัพยากรเครื่องไคลเอนต์ แบนด์วิดท์เครือข่ายไม่ถูกใช้ไปกับการส่งเหตุการณ์ไปยังแอปพลิเคชันไคลเอนต์
การดำเนินการอัตโนมัติช่วยให้สามารถรวบรวมการติดตามโดยไม่ต้องมีผู้ดูแลได้ การติดตามฝั่งเซิร์ฟเวอร์จะยังคงทำงานต่อไปหลังจากการสร้าง แม้ว่าจะไม่มีการเชื่อมต่อไคลเอนต์ก็ตาม กำหนดเวลาการสร้างการติดตามผ่าน SQL Server งานตัวแทนสำหรับการตรวจสอบอัตโนมัติ
ผลกระทบต่อประสิทธิภาพที่ลดลงเป็นผลมาจากการประมวลผลฝั่งเซิร์ฟเวอร์ เหตุการณ์จะถูกเขียนลงดิสก์โดยตรงโดยไม่ต้องมีการทำซีเรียลไลเซชันเพิ่มเติมหรือส่งข้อมูลผ่านเครือข่าย การจัดการบัฟเฟอร์จะช่วยเพิ่มประสิทธิภาพ I/O ของดิสก์เพื่อประสิทธิภาพโดยรวมที่ดีขึ้น
8.2 ฟังก์ชันการติดตามการเล่นซ้ำ
8.2.1 การจับร่องรอยสำหรับการเล่นซ้ำ
สร้างร่องรอยที่พร้อมเล่นซ้ำโดยทำตามขั้นตอนเหล่านี้:
- สร้างร่องรอยใหม่โดยใช้ TSQL_รีเพลย์ แบบ
- ตรวจสอบว่าได้เลือกเหตุการณ์และคอลัมน์ที่จำเป็นทั้งหมดแล้ว
- กำหนดค่าการติดตามเพื่อบันทึกลงในไฟล์
- รันการติดตามในช่วงระยะเวลาการทำงานที่คุณต้องการบันทึก
- หยุดการติดตามและบันทึกไฟล์
เหตุการณ์และคอลัมน์ที่จำเป็นช่วยให้มั่นใจได้ว่าการติดตามการเล่นซ้ำจะสมบูรณ์ เทมเพลต TSQL_Replay ประกอบด้วยประเภทเหตุการณ์และคอลัมน์ข้อมูลที่จำเป็นทั้งหมด การขาดองค์ประกอบที่จำเป็นจะทำให้การเล่นซ้ำไม่สำเร็จ ดังนั้นควรใช้เทมเพลตนี้เมื่อบันทึกข้อมูลเพื่อวัตถุประสงค์ในการเล่นซ้ำเสมอ
8.2.2 การเล่นซ้ำร่องรอย
เล่นซ้ำเวิร์กโหลดที่บันทึกไว้โดยใช้ขั้นตอนเหล่านี้:
- In SQL Server โปรไฟเลอร์ คลิก เนื้อไม่มีมัน -> จุดเปิด -> ไฟล์ติดตาม.
- เลือกไฟล์ติดตามที่พร้อมเล่นซ้ำ
- คลิก Replay -> เริ่มต้น.
- เชื่อมต่อกับเซิร์ฟเวอร์เป้าหมายในกล่องโต้ตอบการเล่นซ้ำ
- กำหนดค่าตัวเลือกการเล่นซ้ำรวมทั้งลำดับและระยะเวลาในการเล่นซ้ำ
- คลิก OK เพื่อเริ่มการเล่นซ้ำ
- ติดตามความคืบหน้าการเล่นซ้ำในหน้าต่างสถานะ
ตัวเลือกการกำหนดค่าการเล่นซ้ำควบคุมวิธีการ SQL Server Profiler จะสร้างเวิร์กโหลดที่บันทึกไว้ขึ้นมาใหม่ เล่นซ้ำเหตุการณ์ตามลำดับที่บันทึกไว้เพื่อรักษาความสัมพันธ์เชิงเวลา กำหนดค่าว่าจะรักษาเวลาเดิมหรือเล่นซ้ำเหตุการณ์ให้เร็วที่สุด
8.2.3 กรณีการใช้งานสำหรับการเล่นซ้ำการติดตาม
การทดสอบโหลดได้รับประโยชน์จากการเล่นซ้ำการติดตาม (trace replay) โดยการจำลองปริมาณงานจริง บันทึกการติดตามปริมาณงานจริงและเล่นซ้ำกับระบบทดสอบเพื่อตรวจสอบประสิทธิภาพภายใต้รูปแบบการใช้งานจริง ปรับการตั้งค่าการทำงานพร้อมกันเพื่อจำลองระดับภาระงานที่แตกต่างกัน
การตรวจสอบการย้ายสภาพแวดล้อมช่วยให้มั่นใจได้ว่าระบบใหม่สามารถรองรับเวิร์กโหลดที่มีอยู่ได้ บันทึกร่องรอยจากระบบการผลิตปัจจุบันและเล่นซ้ำบนฮาร์ดแวร์ใหม่หรือที่อัปเดตแล้ว SQL Server เวอร์ชันต่างๆ เปรียบเทียบเมตริกประสิทธิภาพเพื่อตรวจสอบว่าการโยกย้ายจะไม่ทำให้ประสิทธิภาพลดลง
สถานการณ์การทดสอบได้แก่ การทดสอบการถดถอยหลังจากการเปลี่ยนแปลงโค้ด การตรวจสอบการเปลี่ยนแปลงตัวเพิ่มประสิทธิภาพ SQL Server เวอร์ชันต่างๆ และการทดสอบความเครียดของการกำหนดค่าฮาร์ดแวร์ Replay มอบเวิร์กโหลดที่สม่ำเสมอและทำซ้ำได้เพื่อการทดสอบที่เชื่อถือได้
8.3 การรวม SQL Profiler เข้ากับที่ปรึกษาการปรับแต่งเครื่องมือฐานข้อมูล
สร้างไฟล์เวิร์กโหลดสำหรับ Database Engine Tuning Advisor โดยบันทึกการติดตามเหตุการณ์ที่เหมาะสม ใช้เทมเพลต Tuning เพื่อให้แน่ใจว่าข้อมูลที่จำเป็นทั้งหมดจะถูกบันทึกไว้สำหรับการวิเคราะห์
เปิดใช้งาน Database Engine Tuning Advisor และเลือกไฟล์ติดตามของคุณเป็นแหล่งเวิร์กโหลด Advisor จะวิเคราะห์คิวรีที่บันทึกไว้และแนะนำดัชนี มุมมองที่จัดทำดัชนี หรือกลยุทธ์การแบ่งพาร์ติชันที่จะช่วยปรับปรุงประสิทธิภาพ
เวิร์กโฟลว์การเพิ่มประสิทธิภาพการทำงานผสานรวมการบันทึกการติดตาม (trace capture) เข้ากับการวิเคราะห์การปรับแต่ง (tuning analysis) บันทึกปริมาณงานตัวแทนระหว่างการปฏิบัติงานปกติ วิเคราะห์ด้วย Tuning Advisor ตรวจสอบคำแนะนำ ทดสอบการเปลี่ยนแปลงที่แนะนำในการพัฒนา และนำการเปลี่ยนแปลงที่ได้รับอนุมัติไปใช้ในขั้นตอนการผลิต
8.4 การรวบรวมการติดตามอัตโนมัติ
กำหนดเวลาการติดตามโดยใช้ SQL Server งานของเอเจนต์จะรวบรวมข้อมูลโดยอัตโนมัติ สร้างสคริปต์ T-SQL ที่กำหนดการติดตามฝั่งเซิร์ฟเวอร์โดยใช้ขั้นตอน sp_trace กำหนดเวลาให้สคริปต์เหล่านี้ทำงานตามเวลาหรือช่วงเวลาที่กำหนด
ระบบอัตโนมัติของ PowerShell ช่วยให้สามารถจัดการสถานการณ์การติดตามที่ซับซ้อนได้ เขียนสคริปต์ PowerShell ที่สร้างการติดตาม ตรวจสอบสถานะ และประมวลผลข้อมูลที่รวบรวมได้ กำหนดเวลาสคริปต์ PowerShell ผ่าน Task Scheduler หรือ SQL Server ตัวแทน.
SQL Server งานของเอเจนต์ช่วยให้การทำงานตามกำหนดเวลาเป็นไปอย่างน่าเชื่อถือ สร้างงานที่เริ่มต้นการติดตามเมื่อเริ่มต้นช่วงเวลาการตรวจสอบ และหยุดการติดตามหลังจากที่การเก็บรวบรวมข้อมูลเสร็จสมบูรณ์ กำหนดค่าการแจ้งเตือนงานเพื่อแจ้งเตือนผู้ดูแลระบบเมื่อเกิดข้อผิดพลาด
8.5 การวิเคราะห์ร่องรอยด้วยโปรแกรม
อ่านไฟล์ติดตามด้วย T-SQL โดยใช้ฟังก์ชัน fn_trace_gettable ฟังก์ชันค่าตารางนี้จะวิเคราะห์ไฟล์ติดตามและส่งคืนข้อมูลเหตุการณ์เป็นชุดผลลัพธ์ สามารถสืบค้นข้อมูลนี้โดยใช้ T-SQL มาตรฐานเพื่อดำเนินการวิเคราะห์แบบกำหนดเองได้
สคริปต์การวิเคราะห์แบบกำหนดเองช่วยให้สามารถประมวลผลการติดตามอัตโนมัติ เขียนคิวรีที่คำนวณสถิติรวม ระบุรูปแบบ หรือระบุความผิดปกติ ตั้งเวลาให้สคริปต์เหล่านี้ทำงานโดยอัตโนมัติหลังจากการรวบรวมการติดตามเสร็จสิ้น
สร้างรายงานโดยการสืบค้นข้อมูลการติดตามที่เก็บไว้ในตาราง สร้างมุมมองที่รวบรวมเหตุการณ์ตามช่วงเวลา ผู้ใช้ หรือแอปพลิเคชัน สร้างโซลูชันการรายงานที่ให้ข้อมูลเชิงลึกเกี่ยวกับกิจกรรมและประสิทธิภาพของฐานข้อมูลอย่างสม่ำเสมอ
9. SQL Server แนวทางปฏิบัติที่ดีที่สุดของโปรไฟเลอร์
9.1 แนวทางปฏิบัติที่ดีที่สุดด้านประสิทธิภาพ
9.1.1 การลดค่าใช้จ่ายในการติดตามให้เหลือน้อยที่สุด
เลือกเฉพาะเหตุการณ์ที่จำเป็นเพื่อลดค่าใช้จ่ายในการติดตาม ประเภทเหตุการณ์เพิ่มเติมแต่ละประเภทจะเพิ่มปริมาณข้อมูลที่ระบบติดตามต้องประมวลผล ตรวจสอบวัตถุประสงค์การตรวจสอบของคุณและระบุเฉพาะเหตุการณ์ที่เกี่ยวข้องโดยตรงกับเป้าหมายเหล่านั้น
ใช้ตัวกรองอย่างมีประสิทธิภาพเพื่อป้องกันการรวบรวมข้อมูลที่ไม่เกี่ยวข้อง กรองตามชื่อฐานข้อมูลเพื่อแยกฐานข้อมูลระบบออก กรองตามระยะเวลาเพื่อจับเฉพาะคิวรีที่ช้า กรองตามชื่อแอปพลิเคชันเพื่อมุ่งเน้นไปที่แอปพลิเคชันเฉพาะ การกรองที่เหมาะสมช่วยลดค่าใช้จ่ายในการติดตามได้อย่างมาก
การพิจารณาเปรียบเทียบระหว่างฝั่งเซิร์ฟเวอร์และฝั่งไคลเอ็นต์ส่งผลต่อประสิทธิภาพการทำงาน การติดตามฝั่งเซิร์ฟเวอร์จะเขียนข้อมูลลงดิสก์โดยตรงโดยมีค่าใช้จ่ายน้อยที่สุด การติดตามฝั่งไคลเอ็นต์จะส่งเหตุการณ์ผ่านเครือข่ายไปยังอินเทอร์เฟซ Profiler ซึ่งเพิ่มความล่าช้าและการใช้แบนด์วิดท์ ควรใช้การติดตามฝั่งเซิร์ฟเวอร์สำหรับการตรวจสอบการผลิต
9.1.2 การเพิ่มประสิทธิภาพการจัดเก็บร่องรอย
การจัดการขนาดไฟล์ช่วยป้องกันการใช้พื้นที่ดิสก์จนหมด ตั้งค่าขีดจำกัดขนาดไฟล์สูงสุดให้เหมาะสมกับพื้นที่จัดเก็บที่มีอยู่ เปิดใช้งานฟังก์ชัน File Rollover เพื่อสร้างไฟล์หลายไฟล์แทนที่จะเพิ่มไฟล์เดียวไปเรื่อยๆ ตรวจสอบพื้นที่ดิสก์ระหว่างการดำเนินการติดตาม
ตารางและไฟล์จัดเก็บข้อมูลมีการแลกเปลี่ยนประสิทธิภาพที่แตกต่างกัน การจัดเก็บไฟล์ให้ประสิทธิภาพที่ดีกว่าในระหว่างการดำเนินการติดตาม เนื่องจากไม่ต้องผ่านกลไกการจัดเก็บ การจัดเก็บตารางช่วยให้สามารถสืบค้นข้อมูลติดตามด้วย T-SQL ได้ แต่จะเพิ่มภาระการเขียนข้อมูล เลือกประเภทการจัดเก็บตามความต้องการในการวิเคราะห์ของคุณ
9.2 แนวทางปฏิบัติที่ดีที่สุดด้านความปลอดภัย
การจัดการสิทธิ์จะควบคุมว่าใครสามารถสร้างและรันการติดตามได้ ให้สิทธิ์ ALTER TRACE เฉพาะผู้ใช้ที่เชื่อถือได้ซึ่งจำเป็นต้องมีความสามารถในการติดตามเท่านั้น สมาชิกของบทบาท sysadmin จะมีสิทธิ์เข้าถึงการติดตามแบบไม่จำกัด โปรดตรวจสอบและตรวจสอบสิทธิ์การติดตามอย่างสม่ำเสมอ
การปกป้องข้อมูลที่ละเอียดอ่อนจำเป็นต้องมีการกำหนดค่าการติดตามอย่างระมัดระวัง หลีกเลี่ยงการบันทึกข้อความค้นหาทั้งหมดเมื่อทำงานกับข้อมูลที่ละเอียดอ่อน พิจารณาการกรองหรือการเข้ารหัสผลลัพธ์การติดตามที่มีข้อมูลที่เป็นความลับ จัดเก็บไฟล์การติดตามไว้ในสถานที่ที่ปลอดภัยพร้อมการควบคุมการเข้าถึงที่เหมาะสม
ความปลอดภัยของไฟล์ติดตามช่วยป้องกันการเข้าถึงข้อมูลที่บันทึกไว้โดยไม่ได้รับอนุญาต ตั้งค่าสิทธิ์การเข้าถึงไฟล์เพื่อจำกัดการเข้าถึงไฟล์ติดตาม เข้ารหัสไฟล์ติดตามหากมีข้อมูลสำคัญ ลบไฟล์ติดตามหลังจากการวิเคราะห์เสร็จสิ้นเพื่อลดความเสี่ยงในการเปิดเผยข้อมูล
9.3 การพิจารณาสภาพแวดล้อมการผลิต
9.3.1 เมื่อใดจึงควรใช้ Profiler ในการผลิต
การประเมินความเสี่ยงจะกำหนดเวลา SQL Server โปรแกรม Profiler เหมาะสำหรับการใช้งานจริง Profiler ก่อให้เกิดค่าใช้จ่ายเพิ่มเติมที่สามารถวัดได้ ซึ่งจะเพิ่มขึ้นตามขอบเขตของการติดตาม ควรประเมินว่าคุณค่าของการวินิจฉัยนั้นคุ้มค่ากับผลกระทบต่อประสิทธิภาพหรือไม่ ก่อนที่จะทำการติดตามในสภาพแวดล้อมการใช้งานจริง
การกำหนดค่าผลกระทบขั้นต่ำช่วยให้การติดตามการผลิตมีความปลอดภัยมากขึ้น ใช้ตัวกรองแบบเลือกเฉพาะเพื่อจับเฉพาะเหตุการณ์สำคัญ ตั้งค่าเกณฑ์ระยะเวลาเพื่อละเว้นการสืบค้นข้อมูลที่ดำเนินการอย่างรวดเร็ว จำกัดระยะเวลาการติดตามให้สั้นลงในช่วงเซสชันการแก้ไขปัญหา กำหนดค่าการติดตามฝั่งเซิร์ฟเวอร์เพื่อลดค่าใช้จ่ายของไคลเอ็นต์
9.3.2 ทางเลือกสำหรับการติดตามการผลิต
Extended Events ช่วยลดค่าใช้จ่ายในการตรวจสอบการผลิต เทคโนโลยีสมัยใหม่นี้มอบประสิทธิภาพและความยืดหยุ่นที่ดีกว่า SQL Server โปรไฟเลอร์ ย้ายโซลูชันการตรวจสอบไปยัง Extended Events สำหรับการใช้งานการผลิตในระยะยาว
Query Store จะบันทึกข้อมูลประสิทธิภาพการทำงานของคิวรีโดยอัตโนมัติโดยไม่ต้องตั้งค่าการติดตามด้วยตนเอง เปิดใช้งาน Query Store บนฐานข้อมูลที่ใช้งานจริงเพื่อติดตามสถิติการทำงานของคิวรีเมื่อเวลาผ่านไป Query Store มีความสามารถในการตรวจสอบประสิทธิภาพส่วนใหญ่โดยไม่ต้องมีภาระในการติดตามเพิ่มเติม
มุมมองการจัดการแบบไดนามิกมอบการตรวจสอบแบบเบา ๆ สำหรับสถานการณ์เฉพาะ DMV ให้ข้อมูลสถานะปัจจุบันโดยไม่ต้องบันทึกเหตุการณ์ในอดีต สอบถาม DMV เป็นระยะเพื่อตรวจสอบสถานะของเซิร์ฟเวอร์โดยไม่ต้องเสียเวลาติดตามอย่างต่อเนื่อง
9.4 แนวทางปฏิบัติที่ดีที่สุดในการจัดการร่องรอย
หลักเกณฑ์การตั้งชื่อช่วยให้มั่นใจได้ว่าไฟล์ติดตามสามารถระบุและจัดระเบียบได้ ระบุวันที่ เวลา ชื่อเซิร์ฟเวอร์ และวัตถุประสงค์ในชื่อไฟล์ติดตาม ใช้รูปแบบการตั้งชื่อที่สอดคล้องกันในทุกไฟล์ติดตามเพื่ออำนวยความสะดวกในการจัดการและวิเคราะห์
เอกสารบันทึกการกำหนดค่าและวัตถุประสงค์ของการติดตาม บันทึกเหตุการณ์ที่คุณบันทึกไว้ เหตุผลที่สร้างการติดตาม และสิ่งที่คุณได้เรียนรู้จากการวิเคราะห์ เก็บรักษาบันทึกการติดตามที่รันกับระบบการผลิตเพื่อวัตถุประสงค์ในการปฏิบัติตามข้อกำหนดและการแก้ไขปัญหา
นโยบายการเก็บรักษาข้อมูลช่วยป้องกันการสะสมไฟล์ติดตามที่มากเกินไป กำหนดระยะเวลาที่ควรเก็บรักษาไฟล์ติดตามไว้โดยพิจารณาจากความต้องการทางธุรกิจและความจุของพื้นที่จัดเก็บ ดำเนินการลบไฟล์ติดตามเก่าโดยอัตโนมัติเพื่อเพิ่มพื้นที่ว่างในดิสก์ เก็บไฟล์ติดตามที่สำคัญไว้ในที่จัดเก็บข้อมูลระยะยาวก่อนการลบ
9.5 ข้อผิดพลาดทั่วไปที่ควรหลีกเลี่ยง
การติดตามมากเกินไปจะทำให้ประสิทธิภาพการทำงานลดลงอย่างมากและสร้างปริมาณข้อมูลที่จัดการได้ยาก หลีกเลี่ยงการบันทึกเหตุการณ์ทั้งหมดโดยไม่ใช้ตัวกรอง เริ่มต้นด้วยการติดตามที่แคบและตรงประเด็น และขยายขอบเขตเฉพาะเมื่อจำเป็นเท่านั้น ข้อมูลที่มากขึ้นไม่ได้หมายความว่าจะดีกว่าเสมอไปสำหรับการแก้ไขปัญหาอย่างมีประสิทธิภาพ
การลืมหยุดการติดตามจะทำให้สิ้นเปลืองทรัพยากรและเปลืองพื้นที่ดิสก์ ควรหยุดการติดตามทุกครั้งเมื่อการตรวจสอบเสร็จสิ้น ตั้งค่าขีดจำกัดระยะเวลาการติดตามหรือขนาดไฟล์สูงสุดเพื่อป้องกันการติดตามที่ควบคุมไม่ได้ ตรวจสอบการติดตามที่กำลังทำงานอยู่เป็นประจำ และหยุดการติดตามที่ไม่ได้ใช้งานหรือไม่จำเป็น
การละเลยการปรับแต่งตัวกรองจะส่งผลให้ประสิทธิภาพการทำงานต่ำและการวิเคราะห์ทำได้ยาก ควรใช้เวลาในการกำหนดค่าตัวกรองที่มีประสิทธิภาพก่อนเริ่มการติดตาม ทดสอบตัวกรองในสภาพแวดล้อมการพัฒนาเพื่อตรวจสอบว่าสามารถดักจับข้อมูลที่คาดหวังได้หรือไม่ ทบทวนและปรับปรุงตัวกรองตามผลลัพธ์ที่ได้
10. ทางเลือกอื่น SQL Server โปรไฟล์เลอร์ในปี 2025
10.1 เหตุการณ์ขยาย: การทดแทนสมัยใหม่
10.1.1 เหตุการณ์ที่ขยายออกไปคืออะไร
เหตุการณ์ที่ขยายออกไปแสดงถึง SQL Serverสถาปัตยกรรมการจัดการเหตุการณ์ที่ทันสมัยของ Microsoft ออกแบบระบบนี้โดยเฉพาะเพื่อจัดการกับ SQL Server ข้อจำกัดของ Profiler ได้แก่ ค่าใช้จ่ายด้านประสิทธิภาพและความยืดหยุ่นในการกำหนดค่า Extended Events มอบความสามารถในการตรวจสอบที่ครอบคลุมพร้อมการใช้ทรัพยากรที่ลดลงอย่างมาก
สถาปัตยกรรมและประโยชน์ต่างๆ ที่ทำให้ Extended Events แตกต่างจากเทคโนโลยีการติดตามแบบเก่า เอนจินเหตุการณ์จะผสานรวมเข้ากับ SQL Serverสถาปัตยกรรมหลักของระบบนี้ สามารถบันทึกเหตุการณ์ได้โดยมีค่าใช้จ่ายน้อยที่สุด การบัฟเฟอร์เหตุการณ์แบบอะซิงโครนัสช่วยป้องกันไม่ให้การตรวจสอบไปขัดขวางการทำงานของฐานข้อมูล ตัวเลือกการกำหนดเป้าหมายที่ยืดหยุ่นช่วยให้สามารถกำหนดค่าเอาต์พุตได้หลากหลาย
ข้อได้เปรียบด้านประสิทธิภาพทำให้ Extended Events เหมาะอย่างยิ่งสำหรับการตรวจสอบการผลิต เกณฑ์มาตรฐานแสดงให้เห็นว่า Extended Events ช่วยลดค่าใช้จ่ายลง 50-90% เมื่อเทียบกับรุ่นเทียบเท่า SQL Server การติดตามโปรไฟล์ สถาปัตยกรรมนี้ปรับขนาดได้ดีขึ้นเมื่อมีปริมาณเหตุการณ์สูง และรองรับเซสชันการตรวจสอบพร้อมกันได้มากขึ้น
10.1.2 การย้ายจากโปรไฟเลอร์ไปยังเหตุการณ์ขยาย
การแมปเหตุการณ์แปล SQL Server เหตุการณ์ Profiler เทียบเท่ากับเหตุการณ์ Extended Events เหตุการณ์ Profiler ส่วนใหญ่จะมีเหตุการณ์ Extended Events ที่ตรงกัน ไมโครซอฟต์มีเอกสารที่แสดงการจับคู่เหตุการณ์ทั่วไประหว่างสองระบบนี้
การสร้างเซสชันใน Extended Events จำเป็นต้องเรียนรู้ไวยากรณ์และแนวคิดใหม่ๆ กำหนดเซสชันเหตุการณ์โดยใช้คำสั่ง T-SQL CREATE EVENT SESSION หรืออินเทอร์เฟซกราฟิก Extended Events ใน Management Studio เซสชันจะระบุเหตุการณ์ที่จะบันทึก ข้อมูลที่จะรวบรวม และตำแหน่งที่จะจัดเก็บผลลัพธ์
10.1.3 เครื่องมือและอินเทอร์เฟซเหตุการณ์ขยาย
UI ของ SSMS Extended Events มอบการจัดการเซสชันแบบกราฟิก เข้าถึง Extended Events ผ่านโฟลเดอร์ Management ใน Object Explorer สร้าง แก้ไข และตรวจสอบเซสชันเหตุการณ์ผ่านอินเทอร์เฟซ ดูข้อมูลที่บันทึกไว้ในรูปแบบกราฟิก รวมถึงตารางและแผนภูมิ
การจัดการเซสชัน T-SQL ช่วยให้สามารถควบคุม Extended Events แบบโปรแกรมได้ เขียนคำสั่ง CREATE EVENT SESSION เพื่อกำหนดเซสชันในโค้ด ใช้ ALTER EVENT SESSION เพื่อแก้ไขเซสชันที่กำลังทำงานอยู่ ยกเลิกเซสชันด้วย DROP EVENT SESSION วิธีนี้ช่วยอำนวยความสะดวกให้กับโซลูชันการตรวจสอบอัตโนมัติ
10.2 SQL Server ร้านค้าแบบสอบถาม
Query Store จะบันทึกข้อมูลประสิทธิภาพการทำงานของคิวรีโดยอัตโนมัติสำหรับฐานข้อมูลที่เปิดใช้งาน ฟีเจอร์นี้จะติดตามแผนคิวรี สถิติการดำเนินการ และตัวชี้วัดประสิทธิภาพตลอดระยะเวลาโดยไม่ต้องกำหนดค่าการติดตามด้วยตนเอง Query Store จะเก็บรักษาข้อมูลประวัติการใช้งานไว้ เพื่อให้สามารถวิเคราะห์แนวโน้มและตรวจจับการถดถอยได้
การตรวจสอบประสิทธิภาพการสืบค้นแบบเรียลไทม์ผ่าน Query Store เผยให้เห็นพฤติกรรมปัจจุบันของระบบ ดูการสืบค้นที่ดำเนินการล่าสุด แผนการดำเนินการ และการใช้ทรัพยากร ระบุการสืบค้นที่มีระยะเวลาเพิ่มขึ้นหรือแผนการดำเนินการที่เปลี่ยนแปลง ซึ่งอาจบ่งชี้ถึงปัญหา
การวิเคราะห์แบบสอบถามย้อนหลังช่วยให้สามารถเปรียบเทียบข้อมูลข้ามช่วงเวลาได้ Query Store จะเก็บข้อมูลประสิทธิภาพสำหรับช่วงเวลาการเก็บรักษาที่กำหนดค่าได้ เปรียบเทียบประสิทธิภาพปัจจุบันกับค่าพื้นฐานย้อนหลังเพื่อระบุการถดถอย วิเคราะห์แนวโน้มประสิทธิภาพเพื่อคาดการณ์ความต้องการความจุในอนาคต
ใช้ Query Store เมื่อคุณต้องการการตรวจสอบประสิทธิภาพแบบอัตโนมัติและเปิดใช้งานตลอดเวลา เปิดใช้งาน Query Store บนฐานข้อมูลการผลิตเพื่อติดตามพฤติกรรมการสืบค้นข้อมูลอย่างต่อเนื่อง Query Store ช่วยเสริมการแก้ไขปัญหาตามการติดตาม โดยให้บริบทเชิงประวัติสำหรับปัญหาด้านประสิทธิภาพ
10.3 มุมมองการจัดการแบบไดนามิก (DMV)
การตรวจสอบแบบน้ำหนักเบาผ่าน DMV ให้ข้อมูลสถานะปัจจุบันโดยไม่ต้องบันทึกเหตุการณ์ในอดีต DMV เปิดเผยข้อมูลภายใน SQL Server สถิติและข้อมูลเมตาผ่านมุมมองที่สามารถสอบถามได้ สอบถาม DMV โดยใช้คำสั่ง T-SQL SELECT มาตรฐาน
คิวรี DMV ทั่วไปสำหรับการตรวจสอบประสิทธิภาพประกอบด้วย sys.dm_exec_query_stats สำหรับสถิติประสิทธิภาพการคิวรี, sys.dm_exec_requests สำหรับคำขอที่กำลังดำเนินการอยู่ และ sys.dm_os_wait_stats สำหรับสถิติการรอ มุมมองเหล่านี้ให้ข้อมูลเชิงลึกเกี่ยวกับสถานะและกิจกรรมของเซิร์ฟเวอร์ ณ จุดเวลา
DMV เสริมประสิทธิภาพการตรวจสอบแบบติดตามผลด้วยการแสดงข้อมูลแบบเรียลไทม์ ใช้ DMV เพื่อตรวจสอบสถานะอย่างรวดเร็วและวิเคราะห์สถานะปัจจุบัน ผสานรวมการสอบถาม DMV เข้ากับข้อมูลติดตามผลเพื่อแนวทางการแก้ไขปัญหาที่ครอบคลุม
10.4 เครื่องมือตรวจสอบบุคคลที่สาม
ทางเลือกเชิงพาณิชย์ให้ความสามารถในการตรวจสอบที่เพิ่มขึ้น SQL Serverเครื่องมือในตัวของ SolarWinds ผลิตภัณฑ์จากผู้จำหน่ายอย่าง SolarWinds, Redgate และ Quest มอบฟีเจอร์การตรวจสอบ การแจ้งเตือน และการวิเคราะห์ที่ครอบคลุม เครื่องมือเหล่านี้มักรวมแหล่งข้อมูลหลายแหล่งเข้าด้วยกัน รวมถึงข้อมูลการติดตาม DMV และตัวนับประสิทธิภาพ
การเปรียบเทียบคุณสมบัติเผยให้เห็นจุดแข็งของวิธีการตรวจสอบที่แตกต่างกัน เครื่องมือจากบุคคลที่สามมอบอินเทอร์เฟซผู้ใช้ที่เหนือกว่า การแจ้งเตือนอัตโนมัติ และแนวโน้มย้อนหลัง SQL Serverเครื่องมือในตัวของระบบนี้ไม่มีค่าใช้จ่ายเพิ่มเติมและมีการบูรณาการที่ลึกซึ้งยิ่งขึ้น ประเมินเครื่องมือต่างๆ ตามความต้องการและงบประมาณของคุณ
10.5 การเลือกเครื่องมือที่เหมาะสมกับความต้องการของคุณ
เมทริกซ์การตัดสินใจช่วยเลือกเครื่องมือตรวจสอบที่เหมาะสม สำหรับการแก้ไขปัญหาเฉพาะหน้า SQL Server โปรแกรม Profiler ยังคงใช้งานได้ง่ายและมีประสิทธิภาพ สำหรับการตรวจสอบการผลิต โปรแกรม Extended Events หรือ Query Store จะให้ประสิทธิภาพที่ดีกว่า สำหรับการตรวจสอบองค์กรอย่างครอบคลุม โซลูชันจากผู้ให้บริการภายนอกจะมีคุณสมบัติมากที่สุด
เกณฑ์การเลือกเครื่องมือประกอบด้วยค่าใช้จ่ายด้านประสิทธิภาพ ความสะดวกในการใช้งาน ข้อกำหนดการจัดเก็บข้อมูล และข้อจำกัดด้านงบประมาณ ควรพิจารณาความเชี่ยวชาญของทีมเมื่อเลือกเครื่องมือ เครื่องมือที่คุ้นเคยจะช่วยให้แก้ไขปัญหาได้เร็วขึ้น แม้ว่าทางเลือกใหม่กว่าจะมีฟีเจอร์ที่ดีกว่าก็ตาม
ผสานรวมเครื่องมือหลากหลายเพื่อกลยุทธ์การตรวจสอบที่ครอบคลุม ใช้ Query Store เพื่อติดตามประสิทธิภาพอย่างต่อเนื่อง ใช้ Extended Events เพื่อตรวจสอบปัญหาเฉพาะ และ DMV สำหรับการตรวจสอบสุขภาพแบบเรียลไทม์ วิธีการแบบหลายชั้นนี้ให้การตรวจสอบที่มีเสถียรภาพโดยไม่มีค่าใช้จ่ายเพิ่มเติมที่มากเกินไป
11 การแก้ไขปัญหา SQL Server ปัญหาของโปรไฟเลอร์
11.1 ปัญหาการเชื่อมต่อทั่วไป
ความล้มเหลวในการรับรองความถูกต้องป้องกัน SQL Server โปรแกรมตรวจสอบการเชื่อมต่อกับเซิร์ฟเวอร์เป้าหมาย โปรดตรวจสอบให้แน่ใจว่าคุณใช้ข้อมูลประจำตัวที่ถูกต้องสำหรับวิธีการตรวจสอบสิทธิ์ที่เลือก การตรวจสอบสิทธิ์ Windows ต้องใช้บัญชี Windows ของคุณที่มีสิทธิ์ที่เหมาะสม SQL Server สิทธิ์ SQL Server การตรวจสอบสิทธิ์ต้องใช้ข้อมูลประจำตัวในการเข้าสู่ระบบ SQL ที่ถูกต้อง
ปัญหาการเชื่อมต่อเครือข่ายอาจปรากฏเป็นข้อผิดพลาดการหมดเวลาหรือการเชื่อมต่อล้มเหลว โปรดตรวจสอบ SQL Server อนุญาตการเชื่อมต่อระยะไกลในการกำหนดค่า ตรวจสอบการตั้งค่าไฟร์วอลล์ที่อนุญาตการรับส่งข้อมูลบน SQL Serverพอร์ตของ ทดสอบการเชื่อมต่อพื้นฐานโดยใช้ ping และ telnet ก่อนแก้ไขปัญหาเฉพาะของ Profiler
11.2 ปัญหาประสิทธิภาพการทำงานของโปรไฟเลอร์
การดำเนินการติดตามที่ช้าบ่งชี้ว่าโอเวอร์เฮดที่มากเกินไปจากการกำหนดค่าการติดตาม โปรดตรวจสอบเหตุการณ์ที่เลือกและกำจัดเหตุการณ์ที่ไม่จำเป็น เพิ่มตัวกรองเพื่อลดปริมาณเหตุการณ์ที่บันทึก พิจารณาใช้การติดตามฝั่งเซิร์ฟเวอร์เพื่อลดภาระการประมวลผลฝั่งไคลเอ็นต์
การใช้ทรัพยากรที่สูงส่งผลกระทบต่อทั้งสอง SQL Server และไคลเอ็นต์ Profiler ตรวจสอบ CPU และหน่วยความจำของเซิร์ฟเวอร์ระหว่างการดำเนินการติดตาม หากทรัพยากรเซิร์ฟเวอร์มีจำกัด ให้เพิ่มการเลือกตัวกรองหรือลดระยะเวลาการจับภาพ ปัญหาทรัพยากรของไคลเอ็นต์จำเป็นต้องปิดแอปพลิเคชันอื่นหรืออัปเกรดฮาร์ดแวร์ของไคลเอ็นต์
11.3 ปัญหาไฟล์ติดตามและตาราง
ไฟล์ติดตามที่เสียหายป้องกันการเปิดใน SQL Server Profiler ความเสียหายมักเกิดจากการยุติการติดตามที่ไม่เรียบร้อยหรือข้อผิดพลาดของดิสก์ ลองเปิดไฟล์ในโปรแกรมแก้ไขข้อความเพื่อตรวจสอบว่าไม่ได้เสียหายทั้งหมด บางครั้งสามารถกู้คืนข้อมูลบางส่วนได้โดยการนำเข้าลงในตารางโดยใช้ fn_trace_gettable
ปัญหาการเข้าถึงตารางเกิดขึ้นเมื่อพยายามโหลดการติดตามจาก SQL Server ตาราง ตรวจสอบว่าคุณมีสิทธิ์ SELECT ในตารางการติดตาม ตรวจสอบว่าตารางไม่ได้ถูกลบหรือเปลี่ยนชื่อ ตรวจสอบให้แน่ใจว่าคุณเชื่อมต่อกับเซิร์ฟเวอร์และฐานข้อมูลที่ถูกต้องซึ่งมีตารางการติดตาม
11.4 เหตุการณ์ที่ขาดหายไปหรือข้อมูลไม่ครบถ้วน
การตั้งค่าตัวกรองที่ไม่ถูกต้องอาจทำให้การติดตามพลาดเหตุการณ์ที่คาดหวัง ตรวจสอบเกณฑ์ตัวกรองอย่างละเอียดเพื่อให้แน่ใจว่าไม่ได้ยกเว้นเหตุการณ์ที่ต้องการ ทดสอบตัวกรองโดยการเรียกใช้การติดตามสั้นๆ และตรวจสอบว่าข้อมูลที่บันทึกได้ตรงกับที่คาดหวัง ลบตัวกรองชั่วคราวเพื่อตรวจสอบว่าตัวกรองเป็นสาเหตุของปัญหาหรือไม่
บัฟเฟอร์ล้นเกิดขึ้นเมื่อ SQL Server ไม่สามารถเขียนข้อมูลการติดตามได้เร็วพอที่จะรองรับการสร้างเหตุการณ์ได้ ซึ่งมักเกิดขึ้นกับการติดตามที่ไม่ได้กรองในระหว่างที่มีกิจกรรมสูง อาการต่างๆ ได้แก่ เหตุการณ์หายไป หรือคำเตือน "เหตุการณ์ไม่ได้ถูกบันทึก" แก้ไขปัญหาโดยการเพิ่มตัวกรองเพื่อลดปริมาณเหตุการณ์ หรือเพิ่มประสิทธิภาพ I/O ของดิสก์ตำแหน่งไฟล์การติดตาม
11.5 โปรไฟเลอร์ขัดข้องและข้อผิดพลาด
ข้อความแสดงข้อผิดพลาดที่พบบ่อย ได้แก่ “ไม่สามารถสร้างการติดตามได้” ซึ่งบ่งชี้ถึงปัญหาการอนุญาตหรือข้อจำกัดด้านทรัพยากร ข้อความ “การติดตามถูกหยุด” บ่งชี้ถึงความล้มเหลวในการติดตามฝั่งเซิร์ฟเวอร์ ซึ่งอาจเกิดจากสภาวะดิสก์เต็ม ข้อผิดพลาด “คำจำกัดความการติดตามไม่ถูกต้อง” บ่งชี้ถึงปัญหาการกำหนดค่า
กลยุทธ์การแก้ไขปัญหาขึ้นอยู่กับข้อผิดพลาดเฉพาะนั้นๆ ข้อผิดพลาดด้านสิทธิ์การเข้าถึงจำเป็นต้องให้สิทธิ์ ALTER TRACE แก่ผู้ใช้ ข้อผิดพลาดด้านทรัพยากรจำเป็นต้องเคลียร์พื้นที่ดิสก์หรือหน่วยความจำ ข้อผิดพลาดด้านการกำหนดค่าจำเป็นต้องตรวจสอบและแก้ไขการตั้งค่าการติดตาม การรีสตาร์ท SQL Server โปรไฟเลอร์หากไม่ตอบสนอง
12. การปฏิบัติ SQL Server สถานการณ์และตัวอย่างของโปรไฟเลอร์
12.1 สถานการณ์ที่ 1: การระบุแบบสอบถามที่ช้าที่สุดในฐานข้อมูลของคุณ
บทช่วยสอนนี้จะสาธิตการจับและวิเคราะห์แบบสอบถามที่ช้า
กำหนดค่าการติดตามโดยทำตามขั้นตอนเหล่านี้:
- ยิง SQL Server ใช้โปรแกรม Profiler เพื่อเชื่อมต่อกับเซิร์ฟเวอร์เป้าหมายของคุณ
- คลิก เนื้อไม่มีมัน -> ร่องรอยใหม่.
- ป้อน “การวิเคราะห์แบบสอบถามช้า” ใน ชื่อร่องรอย สนาม
- เลือก ทีเอสคิวแอล จาก ใช้เทมเพลต หล่นลง.
- คลิก การเลือกกิจกรรม แถบ
- คลิก ตัวกรองคอลัมน์.
- เลือก ระยะเวลา และใส่ 1000000 เข้าไป มากกว่าหรือเท่ากับ.
- เลือก ชื่อฐานข้อมูล และใส่ชื่อฐานข้อมูลของคุณใน Like.
- คลิก OK เพื่อปิดตัวกรอง
- ทำให้สามารถ บันทึกลงไฟล์ และระบุเส้นทางไฟล์
- คลิก วิ่ง เพื่อเริ่มต้นการจับภาพ
ดำเนินการติดตามในช่วงเวลาทำการสูงสุดอย่างน้อย 30 นาที เพื่อบันทึกปริมาณงานให้เพียงพอ หยุดการติดตามหลังจากรวบรวมข้อมูลเพียงพอแล้ว
วิเคราะห์ผลลัพธ์ตามกระบวนการนี้:
- คลิก ระยะเวลา ส่วนหัวคอลัมน์ที่จะเรียงลำดับตามเวลาการดำเนินการ
- ระบุ 10 อันดับแบบสอบถามที่ดำเนินมายาวนานที่สุด
- สำหรับแต่ละแบบสอบถาม ให้ตรวจสอบ ข้อมูลข้อความ คอลัมน์.
- คัดลอกข้อความแบบสอบถามและวางลงใน Management Studio
- ใช้ แสดงแผนการดำเนินการโดยประมาณ เพื่อวิเคราะห์การสอบถาม
- ค้นหาการสแกนตาราง ดัชนีที่หายไป หรือการรวมที่ไม่มีประสิทธิภาพ
- รีวิว ซีพียู, อ่านและ เขียน คอลัมน์สำหรับรูปแบบการใช้ทรัพยากร
12.2 สถานการณ์ที่ 2: การแก้ไขปัญหาเดดล็อก
ตัวอย่างนี้แสดงวิธีการจับภาพและวิเคราะห์เดดล็อก
กำหนดค่าการตรวจสอบเดดล็อกโดยใช้ขั้นตอนเหล่านี้:
- สร้างการติดตามใหม่ที่ชื่อว่า "การสืบสวนเดดล็อก"
- คลิก การเลือกกิจกรรม แถบ
- คลิก แสดงกิจกรรมทั้งหมด.
- แสดง ล็อค หมวดหมู่
- เลือก ล็อค:เดดล็อค.
- เลือก ล็อค: โซ่ล็อคตาย.
- แสดง ข้อผิดพลาดและคำเตือน หมวดหมู่
- เลือก รายงานกระบวนการที่ถูกบล็อค.
- ทำให้มั่นใจ ข้อมูลข้อความ เลือกคอลัมน์แล้ว
- คลิก วิ่ง เพื่อเริ่มการตรวจสอบ
เมื่อเกิดการเดดล็อกระหว่างการดำเนินการติดตาม เหตุการณ์ล็อค:เดดล็อกจะปรากฏในตารางติดตาม
ตีความข้อมูลเดดล็อกโดยทำตามขั้นตอนเหล่านี้:
- คลิก ล็อค:เดดล็อค แถวเหตุการณ์
- ดู ข้อมูลข้อความ คอลัมน์ในแผงด้านล่าง
- คัดลอกเนื้อหา XML จาก TextData
- เปิด Management Studio และสร้างหน้าต่างแบบสอบถามใหม่
- วาง XML ลงในหน้าต่างแบบสอบถาม
- บันทึกไฟล์ด้วยนามสกุล .xdl
- เปิดไฟล์ .xdl ใน Management Studio เพื่อดูกราฟเดดล็อก
- กราฟแสดงกระบวนการที่เกี่ยวข้อง ทรัพยากรที่ถูกล็อค และเหยื่อที่เลือก
- ตรวจสอบคำถามจากทั้งสองกระบวนการเพื่อทำความเข้าใจความขัดแย้ง
ขั้นตอนการแก้ไขปัญหาโดยทั่วไปเกี่ยวข้องกับการเรียงลำดับการดำเนินการใหม่ในโค้ดแอปพลิเคชันเพื่อเข้าถึงทรัพยากรในลำดับที่สอดคล้องกัน การลดขอบเขตของธุรกรรม หรือการนำคำแนะนำการล็อกที่เหมาะสมมาใช้
12.3 สถานการณ์ที่ 3: การติดตามการสอบถามทั้งหมดจากแอปพลิเคชันเฉพาะ
สถานการณ์จำลองนี้สาธิตการตรวจสอบแบบสอบถามเฉพาะแอปพลิเคชัน
กำหนดค่าการติดตามเฉพาะแอปพลิเคชันโดยใช้ขั้นตอนเหล่านี้:
- สร้างการติดตามใหม่ที่ชื่อว่า “การติดตามการค้นหาแอปพลิเคชัน”
- เลือก Standard แบบ
- คลิก การเลือกกิจกรรม แถบ
- คลิก ตัวกรองคอลัมน์.
- เลือก ชื่อแอปพลิเคชัน.
- กรอกชื่อแอปพลิเคชันของคุณใน Like สนาม
- หากแอปพลิเคชันของคุณใช้การรวมกลุ่มการเชื่อมต่อ คุณอาจจำเป็นต้องมีการจับคู่ไวด์การ์ด
- คลิก OK เพื่อใช้ตัวกรอง
- ทำให้สามารถ บันทึกลงในตาราง เพื่อให้ง่ายต่อการสอบถาม
- คลิก วิ่ง เพื่อเริ่มต้นการจับภาพ
การวิเคราะห์รูปแบบแบบสอบถามเผยให้เห็นว่าแอปพลิเคชันของคุณโต้ตอบกับ SQL Server:
- หลังจากรวบรวมข้อมูลแล้วให้หยุดการติดตาม
- เปิด Management Studio และเชื่อมต่อกับเซิร์ฟเวอร์ด้วยตารางการติดตาม
- สอบถามตารางร่องรอยเพื่อวิเคราะห์รูปแบบ
- นับจำนวนแบบสอบถามตามประเภทเพื่อดูการผสมผสานการดำเนินการ
- ระบุคำสั่ง SQL ที่ถูกเรียกใช้บ่อยที่สุด
- มองหาแบบสอบถามที่สามารถแคชหรือปรับแต่งได้
- ตรวจสอบการค้นหาแบบซ้ำที่เหมือนกันซึ่งบ่งชี้ถึงการรวมกลุ่มการเชื่อมต่อที่ขาดหายไป
12.4 สถานการณ์ที่ 4: การตรวจสอบการเข้าถึงข้อมูลเพื่อการปฏิบัติตาม
ตัวอย่างนี้แสดงการสร้างเส้นทางการตรวจสอบความปลอดภัย
กำหนดค่าการตรวจสอบความปลอดภัยโดยทำตามขั้นตอนเหล่านี้:
- สร้างการติดตามใหม่ที่ชื่อว่า “เส้นทางการตรวจสอบความปลอดภัย”
- คลิก การเลือกกิจกรรม แถบ
- คลิก แสดงกิจกรรมทั้งหมด.
- แสดง ตรวจสอบการรักษาความปลอดภัย หมวดหมู่
- เลือก การเข้าสู่ระบบการตรวจสอบ, การตรวจสอบการออกจากระบบ, การเข้าสู่ระบบการตรวจสอบล้มเหลว.
- เลือก ตรวจสอบการเข้าถึงวัตถุฐานข้อมูล.
- แสดง ทีเอสคิวแอล หมวดหมู่
- เลือก SQL:BatchCompleted.
- คลิก ตัวกรองคอลัมน์.
- กรองตาม ชื่อวัตถุ เพื่อตรวจสอบตารางที่ละเอียดอ่อนโดยเฉพาะ
- ทำให้สามารถ บันทึกลงในตาราง เพื่อการเก็บรักษาในระยะยาว
- เปิดใช้งานการติดตามฝั่งเซิร์ฟเวอร์สำหรับการทำงานโดยไม่ต้องดูแล
- คลิก วิ่ง เพื่อเริ่มการตรวจสอบบัญชี
สร้างรายงานการตรวจสอบโดยการสอบถามตารางการติดตาม:
- สร้างแบบสอบถามสรุปการเข้าถึงตามผู้ใช้และช่วงเวลา
- ระบุรูปแบบการเข้าถึงที่ผิดปกติหรือกิจกรรมหลังเวลาทำการ
- เอกสารล้มเหลวในการพยายามเข้าสู่ระบบเพื่อตรวจสอบความปลอดภัย
- ส่งออกข้อมูลการตรวจสอบไปยังระบบการรายงานเพื่อจัดทำเอกสารการปฏิบัติตามข้อกำหนด
- เก็บบันทึกการตรวจสอบที่เสร็จสิ้นตามนโยบายการเก็บข้อมูล
12.5 สถานการณ์ที่ 5: การจับภาระงานสำหรับการทดสอบประสิทธิภาพ
สถานการณ์จำลองนี้สาธิตการจับปริมาณงานเพื่อวัตถุประสงค์ในการทดสอบ
สร้างร่องรอยที่พร้อมเล่นซ้ำโดยใช้ขั้นตอนเหล่านี้:
- สร้างการติดตามใหม่ที่ชื่อว่า “การจับภาระงาน”
- เลือก TSQL_รีเพลย์ จากเมนูแบบดรอปดาวน์ของเทมเพลต
- เทมเพลตนี้รวมเหตุการณ์และคอลัมน์ที่จำเป็นทั้งหมดสำหรับการเล่นซ้ำ
- คลิก การเลือกกิจกรรม แถบ
- ใช้ตัวกรองหากคุณต้องการจับภาพส่วนเวิร์กโหลดที่เฉพาะเจาะจง
- ทำให้สามารถ บันทึกลงไฟล์.
- ระบุเส้นทางไฟล์ที่มีพื้นที่ดิสก์เพียงพอ
- ตั้งค่าขีดจำกัดขนาดไฟล์ที่เหมาะสมและเปิดใช้งานการหมุนเวียน
- คลิก วิ่ง เพื่อเริ่มต้นการจับภาพ
บันทึกข้อมูลระหว่างการดำเนินธุรกิจแบบตัวแทน สำหรับการเก็บข้อมูลปริมาณงานที่ครอบคลุม ให้รันการติดตามเป็นเวลาหลายชั่วโมงโดยครอบคลุมรูปแบบกิจกรรมที่แตกต่างกัน หยุดการติดตามหลังจากรวบรวมข้อมูลเพียงพอแล้ว
การวิเคราะห์ภาระงานเผยให้เห็นรูปแบบพฤติกรรมของระบบ:
- เปิดไฟล์ติดตามที่บันทึกไว้ใน SQL Server Profiler
- ตรวจสอบการกระจายเหตุการณ์ตามประเภทและเวลา
- คำนวณเมตริกการใช้ทรัพยากรรวม
- ระบุช่วงที่มีกิจกรรมสูงสุดและปัญหาคอขวดของทรัพยากร
- ใช้ร่องรอยสำหรับการวิเคราะห์ที่ปรึกษาการปรับแต่งกลไกฐานข้อมูล
- เล่นซ้ำร่องรอยกับระบบทดสอบเพื่อตรวจสอบการเปลี่ยนแปลง
13. การตรวจจับการทุจริตฐานข้อมูลด้วย SQL Server Profiler
13.1 การใช้ SQL Server โปรไฟเลอร์สำหรับสัญญาณเตือนการทุจริตในระยะเริ่มต้น
ความเสียหายของฐานข้อมูลถือเป็นหนึ่งในภัยคุกคามที่ร้ายแรงที่สุดต่อความสมบูรณ์ของข้อมูลและความน่าเชื่อถือของระบบ ในขณะที่ SQL Server Profiler ไม่ใช่เครื่องมือตรวจจับการทุจริตโดยเฉพาะ แต่สามารถจับสัญญาณเตือนที่สำคัญซึ่งบ่งชี้ถึงปัญหาการทุจริตที่อาจเกิดขึ้นซึ่งต้องมีการสอบสวนทันที
13.2 เหตุการณ์ข้อผิดพลาดร้ายแรงที่บ่งชี้ถึงการทุจริตที่อาจเกิดขึ้น
- ข้อผิดพลาดระดับความรุนแรง 24 (823, 824, 825): ความล้มเหลวของฮาร์ดแวร์และสื่อ
- ข้อผิดพลาด 605: ความพยายามในการดึงข้อมูลหน้าล้มเหลว
- ข้อผิดพลาด 8928 และ 8929: ความเสียหายของวัตถุ
13.3 พฤติกรรมฐานข้อมูลที่น่าสงสัยและรูปแบบการเตือน
- การหมดเวลาของการค้นหาซ้ำบนวัตถุเฉพาะ
- การละเมิดการเข้าถึงและแอปพลิเคชันขัดข้อง
- การรวมกลุ่มข้อผิดพลาดที่ผิดปกติ
13.4 เรียกใช้ DBCC CHECKDB ตามผลการค้นพบของ Profiler
If SQL Server Profiler ตรวจพบการทุจริตที่น่าสงสัย คุณสามารถใช้ DBCC CHECKDB เพื่อตรวจสอบฐานข้อมูลทั้งหมด จากนั้นดำเนินการซ่อมแซมหากยืนยันว่าพบการทุจริต เราได้เขียนไว้แล้ว คำแนะนำที่ครอบคลุมเกี่ยวกับวิธีการทำภารกิจเหล่านี้.
หาก DBCC CHECKDB ไม่สามารถซ่อมแซมฐานข้อมูลได้ ความเสียหายจะร้ายแรง ในกรณีนี้ คุณสามารถใช้ เครื่องมือการกู้คืน SQL ของบุคคลที่สาม.
14. คำถามที่พบบ่อย
ถาม: คือ SQL Server โปรไฟเลอร์ยังคงรองรับใน SQL Server ? 2022
ตอบ: ใช่ SQL Server โปรไฟเลอร์ยังรวมอยู่ใน SQL Server 2022 และ SQL Server Management Studio แม้ว่าจะเลิกใช้แล้วตั้งแต่ SQL Server 2016 Microsoft ยังคงวางจำหน่ายเครื่องมือนี้พร้อมกับเวอร์ชันปัจจุบัน แต่ขอแนะนำให้เปลี่ยนไปใช้เครื่องมือ Extended Events สำหรับการใช้งานการตรวจสอบแบบใหม่ เครื่องมือนี้ยังคงใช้งานได้และถูกใช้อย่างแพร่หลายสำหรับการแก้ไขปัญหาและการวิเคราะห์เฉพาะกิจ
ถาม: อะไรคือความแตกต่างระหว่าง SQL Server โปรไฟล์เลอร์และการติดตาม SQL?
A: SQL Server Profiler เป็นเครื่องมืออินเทอร์เฟซผู้ใช้แบบกราฟิกที่เชื่อมต่อกับเอ็นจิ้น SQL Trace ที่ทำงานภายใน SQL ServerSQL Trace คือเทคโนโลยีพื้นฐานที่บันทึกเหตุการณ์ต่างๆ คุณสามารถสร้างการติดตามได้โดยใช้อินเทอร์เฟซของ Profiler หรือโดยตรงผ่านโพรซีเดอร์ที่เก็บไว้ของ T-SQL เช่น sp_trace_create Profiler ช่วยให้กำหนดค่าได้ง่ายขึ้น ขณะที่การติดตามของ T-SQL มอบความสามารถในการทำงานอัตโนมัติที่มากขึ้น
ถาม: ค่าใช้จ่ายด้านประสิทธิภาพการทำงานมีเท่าไร SQL Server โปรไฟเลอร์เพิ่มเหรอ?
ตอบ: ผลกระทบต่อประสิทธิภาพจะแตกต่างกันไปตามการกำหนดค่าการติดตาม การติดตามที่กรองข้อมูลอย่างดีซึ่งบันทึกเฉพาะเหตุการณ์ที่เฉพาะเจาะจงอาจเพิ่มค่าใช้จ่ายได้ 1-5% การติดตามที่กำหนดค่าไม่ดีโดยไม่มีตัวกรองอาจเพิ่มค่าใช้จ่ายได้ 20-50% หรือมากกว่า โดยเฉพาะอย่างยิ่งในระบบที่มีการใช้งานมาก การติดตามฝั่งเซิร์ฟเวอร์มีผลกระทบน้อยกว่าการติดตามฝั่งไคลเอ็นต์ ควรใช้ตัวกรองเพื่อลดปริมาณเหตุการณ์และทดสอบการติดตามในสภาพแวดล้อมที่ไม่ใช่การใช้งานจริงก่อนเสมอ
ถาม: ฉันสามารถวิ่งได้ไหม SQL Server โปรไฟเลอร์บนเซิร์ฟเวอร์การผลิต?
A: คุณสามารถวิ่งได้ SQL Server โปรไฟล์เลอร์บนเซิร์ฟเวอร์ที่ใช้งานจริง แต่โปรดใช้ความระมัดระวัง ควรใช้ตัวกรองแบบเลือกเฉพาะเจาะจง จำกัดระยะเวลาการติดตาม และเลือกใช้การติดตามฝั่งเซิร์ฟเวอร์เพื่อลดผลกระทบ รันการติดตามการใช้งานจริงในช่วงที่มีกิจกรรมน้อยเมื่อทำได้ สำหรับการตรวจสอบการใช้งานจริงอย่างต่อเนื่อง ให้พิจารณาใช้ Extended Events หรือ Query Store แทน เนื่องจากมีค่าใช้จ่ายที่ต่ำกว่า
ถาม: ฉันต้องใช้สิทธิ์อะไรบ้าง SQL Server โปรไฟเลอร์?
A: คุณต้องมีสิทธิ์ ALTER TRACE เพื่อสร้างและรันการติดตาม สมาชิกของบทบาทเซิร์ฟเวอร์แบบคงที่ของ sysadmin จะมีสิทธิ์นี้โดยอัตโนมัติ สำหรับผู้ใช้ที่ไม่ใช่ sysadmin ให้สิทธิ์ ALTER TRACE อย่างชัดเจน นอกจากนี้ คุณต้องมีสิทธิ์ที่เหมาะสมในการบันทึกข้อมูลการติดตามลงในไฟล์หรือตารางตามการกำหนดค่าของคุณ
ถาม: ทำไมฉันถึงไม่เห็นเหตุการณ์ทั้งหมดในการติดตามของฉัน?
A: เหตุการณ์ที่หายไปมักเกิดจากตัวกรองที่จำกัดมากเกินไปหรือบัฟเฟอร์ล้น โปรดตรวจสอบการกำหนดค่าตัวกรองของคุณเพื่อให้แน่ใจว่าไม่ได้ยกเว้นเหตุการณ์ที่ต้องการ บัฟเฟอร์ล้นเกิดขึ้นเมื่อ SQL Server ไม่สามารถเขียนเหตุการณ์ได้เร็วพอ โดยปกติแล้วจะมีร่องรอยที่ไม่ได้กรองบนระบบที่มีการใช้งานมาก เพิ่มตัวกรองเพื่อลดปริมาณเหตุการณ์หรือเพิ่มประสิทธิภาพ I/O ของดิสก์ ตรวจสอบข้อความแสดงข้อผิดพลาดที่ระบุว่าเหตุการณ์ไม่ได้ถูกบันทึก
ถาม: ฉันจะจับข้อมูลเดดล็อคได้อย่างไร SQL Server โปรไฟเลอร์?
ก: สร้างการติดตามที่รวมเหตุการณ์ Lock:Deadlock และ Lock:Deadlock Chain จากหมวดหมู่ Locks ตรวจสอบให้แน่ใจว่าได้เลือกคอลัมน์ TextData ไว้แล้ว เนื่องจากมี XML ของกราฟ Deadlock เมื่อเกิด Deadlock ให้คัดลอก XML จากคอลัมน์ TextData บันทึกด้วยนามสกุล .xdl แล้วเปิดใน SQL Server Management Studio เพื่อดูแผนภาพเดดล็อกแบบกราฟิก
ถาม: ความแตกต่างระหว่างการบันทึกร่องรอยลงในไฟล์กับตารางคืออะไร
A: ไฟล์มีประสิทธิภาพที่ดีขึ้นในระหว่างการดำเนินการติดตามเนื่องจากสามารถข้าม SQL Server เอ็นจิ้นจัดเก็บข้อมูล ไฟล์เทรซจะเขียนข้อมูลลงดิสก์โดยตรงโดยมีค่าใช้จ่ายน้อยที่สุด ส่วนตารางเทรซจะเขียนผ่านเอ็นจิ้นจัดเก็บข้อมูล ซึ่งเพิ่มค่าใช้จ่าย แต่สามารถเรียกใช้คิวรี T-SQL ได้ทันทีกับข้อมูลเทรซ ใช้ไฟล์สำหรับสถานการณ์และตารางที่เน้นประสิทธิภาพ เมื่อคุณต้องการคิวรีข้อมูลทันทีระหว่างหรือหลังการบันทึกข้อมูล
ถาม: ฉันสามารถทำให้เป็นอัตโนมัติได้หรือไม่ SQL Server การรวบรวมการติดตามโปรไฟเลอร์?
ตอบ: ใช่ ทำการรวบรวมข้อมูลการติดตามโดยอัตโนมัติโดยใช้การติดตามฝั่งเซิร์ฟเวอร์ที่สร้างด้วยโพรซีเดอร์ที่จัดเก็บไว้ของ T-SQL เขียนสคริปต์โดยใช้ sp_trace_create และโพรซีเดอร์ที่เกี่ยวข้อง จากนั้นจึงกำหนดเวลาผ่าน SQL Server งานของตัวแทน วิธีนี้ช่วยให้สามารถรวบรวมการติดตามโดยไม่ต้องมีผู้ดูแลตามกำหนดเวลาที่กำหนด สคริปต์ PowerShell มอบตัวเลือกการทำงานอัตโนมัติอีกทางหนึ่งสำหรับสถานการณ์ที่ซับซ้อนมากขึ้น
ถาม: ฉันควรรันการติดตามเป็นเวลานานเพียงใด?
ตอบ: ระยะเวลาการติดตามขึ้นอยู่กับวัตถุประสงค์ของคุณ สำหรับการแก้ไขปัญหาเฉพาะ ให้ติดตามไปพร้อมๆ กับการจำลองปัญหา ซึ่งโดยทั่วไปจะใช้เวลา 5-30 นาที สำหรับการวิเคราะห์ประสิทธิภาพ ให้บันทึกอย่างน้อยหนึ่งชั่วโมงในช่วงเวลาที่มีกิจกรรมสูงสุด สำหรับการวิเคราะห์ภาระงานหรือการวางแผนกำลังการผลิต ให้บันทึกหลายชั่วโมงในช่วงเวลาต่างๆ กัน หยุดการติดตามทุกครั้งเมื่อการตรวจสอบเสร็จสิ้น เพื่อปลดปล่อยทรัพยากร
ถาม: ฉันควรทำอย่างไรหากไฟล์ติดตามของฉันมีขนาดใหญ่เกินไป?
ก: เปิดใช้งานการโยกย้ายไฟล์ในคุณสมบัติการติดตามเพื่อสร้างไฟล์ขนาดเล็กหลายไฟล์แทนที่จะเป็นไฟล์ขนาดใหญ่เพียงไฟล์เดียว ตั้งค่าขนาดไฟล์สูงสุดที่เหมาะสมกับพื้นที่ดิสก์และความต้องการในการวิเคราะห์ของคุณ ใช้ตัวกรองเพื่อลดปริมาณเหตุการณ์ที่บันทึก สำหรับการติดตามขนาดใหญ่ ให้พิจารณาวิเคราะห์ข้อมูลแบบแบ่งเซ็กเมนต์แทนการโหลดการติดตามทั้งหมดในครั้งเดียว เก็บถาวรหรือลบไฟล์การติดตามเก่าเป็นประจำเพื่อจัดการพื้นที่ดิสก์
ถาม: ฉันจะค้นหาคำค้นหาที่ทำให้มีการใช้งาน CPU สูงได้อย่างไร
A: สร้างการติดตามโดยใช้เหตุการณ์ SQL:BatchCompleted และ RPC:Completed รวมคอลัมน์ CPU, Duration และ TextData กรองตาม Duration เพื่อบันทึกเฉพาะคิวรีที่ใช้เวลาเกินเกณฑ์ เช่น 1000 มิลลิวินาที หลังจากรวบรวมข้อมูลแล้ว ให้เรียงลำดับตามคอลัมน์ CPU จากมากไปน้อย คิวรีที่อยู่ด้านบนสุดจะใช้เวลาประมวลผลมากที่สุด ตรวจสอบคิวรีเหล่านี้เพื่อหาโอกาสในการปรับปรุงประสิทธิภาพ เช่น การขาดดัชนีหรือตรรกะที่ไม่ eficiente
ถาม: ทำได้ SQL Server แผนการดำเนินการแบบสอบถามการจับภาพโปรไฟเลอร์?
A: SQL Server Profiler สามารถบันทึกข้อมูลแผนการดำเนินการผ่านเหตุการณ์ Showplan XML ในหมวดหมู่ Performance เลือกเหตุการณ์ Showplan XML หรือ Showplan XML Statistics Profile เพื่อบันทึกแผนการดำเนินการทั้งหมด คอลัมน์ TextData ประกอบด้วยข้อมูลแผน XML อย่างไรก็ตาม สำหรับการวิเคราะห์แผนการดำเนินการตามปกติ SQL Server คุณสมบัติแผนการดำเนินการแบบกราฟิกของ Management Studio หรือ Query Store มอบทางเลือกที่ง่ายกว่า
ถาม: เทมเพลตใดเหมาะสมที่สุดสำหรับการเริ่มต้นการตรวจสอบทั่วไป?
A: เทมเพลตมาตรฐานเป็นจุดเริ่มต้นที่ดีสำหรับการตรวจสอบทั่วไป ประกอบด้วยเหตุการณ์การเรียกใช้คิวรีทั่วไป การเรียกใช้โพรซีเดอร์ที่จัดเก็บไว้ และการติดตามข้อผิดพลาด พร้อมค่าใช้จ่ายส่วนเกินที่สมดุล สำหรับการตรวจสอบที่มีผลกระทบน้อยกว่า โดยเน้นที่ประสิทธิภาพของคิวรี ให้ใช้เทมเพลต TSQL ปรับแต่งเทมเพลตตามความต้องการเฉพาะของคุณโดยการเพิ่มตัวกรองและปรับการเลือกเหตุการณ์หลังจากทำความเข้าใจพื้นฐานแล้ว
ถาม: ฉันจะติดตามเฉพาะแอปพลิเคชันหรือผู้ใช้ที่ระบุได้อย่างไร
A: ใช้ตัวกรองคอลัมน์เพื่อแยกแอปพลิเคชันหรือผู้ใช้เฉพาะ สำหรับแอปพลิเคชัน ให้กรองตามคอลัมน์ ApplicationName โดยใช้ชื่อที่ระบุในสตริงการเชื่อมต่อของคุณ สำหรับผู้ใช้ ให้กรองตามคอลัมน์ LoginName ด้วย SQL Server ชื่อล็อกอินหรือชื่อบัญชีผู้ใช้ Windows ผสานรวมตัวกรองหลายตัวเพื่อจำกัดขอบเขตให้แคบลง เช่น การกรองตามทั้ง ApplicationName และ DatabaseName เพื่อตรวจสอบกิจกรรมของแอปพลิเคชันใดแอปพลิเคชันหนึ่งในฐานข้อมูลเฉพาะ
15. บทสรุปและขั้นตอนถัดไป
15.1 ประเด็นสำคัญ
SQL Server แม้ว่าฟังก์ชันการทำงานจะล้าสมัยไปแล้ว แต่ Profiler ก็ยังคงเป็นเครื่องมือที่มีคุณค่าสำหรับการแก้ไขปัญหาฐานข้อมูลแบบเฉพาะกิจ อินเทอร์เฟซที่ใช้งานง่ายและการบันทึกเหตุการณ์ที่ครอบคลุมทำให้เหมาะสำหรับการวินิจฉัยอย่างรวดเร็วเมื่อคุณต้องการผลลัพธ์ทันที ใช้ Profiler สำหรับการแก้ไขปัญหาเฉพาะเจาะจง การวิเคราะห์พฤติกรรมของแอปพลิเคชัน และการตรวจสอบความปลอดภัย
แนวทางปฏิบัติที่ดีที่สุด ได้แก่ การใช้ตัวกรองอย่างเข้มงวดเพื่อลดผลกระทบต่อประสิทธิภาพ การเลือกการติดตามฝั่งเซิร์ฟเวอร์สำหรับสภาพแวดล้อมการใช้งานจริง และการจำกัดระยะเวลาการติดตามให้อยู่ในระยะเวลาที่จำเป็น เลือกเฉพาะเหตุการณ์และคอลัมน์ที่จำเป็นเพื่อลดค่าใช้จ่าย บันทึกการติดตามลงในไฟล์แทนตารางเพื่อประสิทธิภาพที่ดีขึ้นในระหว่างการบันทึกข้อมูล
15.2 ก้าวไปข้างหน้า: การยอมรับเครื่องมือสมัยใหม่
เปลี่ยนจาก SQL Server โปรไฟเลอร์ไปจนถึงเหตุการณ์ที่ขยายเวลาสำหรับโซลูชันการตรวจสอบระยะยาว แม้ว่าโปรไฟเลอร์จะยังคงใช้งานได้ แต่การลงทุนเวลาเพื่อเรียนรู้เหตุการณ์ที่ขยายเวลาจะช่วยให้คุณพร้อมสำหรับอนาคต SQL Server เริ่มจากเวอร์ชันต่างๆ ก่อน เริ่มจากเซสชัน Extended Events แบบง่ายๆ ที่จำลองการติดตาม Profiler ทั่วไปของคุณ
เปิดใช้งาน Query Store บนฐานข้อมูลที่ใช้งานจริงเพื่อรับการตรวจสอบประสิทธิภาพอัตโนมัติโดยไม่ต้องกำหนดค่าการติดตามด้วยตนเอง Query Store จะบันทึกแผนการสืบค้นและสถิติการดำเนินการอย่างต่อเนื่อง ซึ่งเป็นข้อมูลพื้นฐานสำหรับการวิเคราะห์ประสิทธิภาพ ผสานรวม Query Store กับเซสชัน Extended Events ที่กำหนดเป้าหมายเพื่อการตรวจสอบที่ครอบคลุมยิ่งขึ้น
15.3 แหล่งข้อมูลเพิ่มเติม
ทรัพยากรต่อไปนี้จะช่วยให้คุณเจาะลึกยิ่งขึ้น SQL Server ความรู้เกี่ยวกับโปรไฟเลอร์และการติดตามแนวทางปฏิบัติที่ดีที่สุดอยู่เสมอ:
เอกสารอย่างเป็นทางการของ Microsoft
- SQL Server เอกสารประกอบโปรไฟเลอร์ – ข้อมูลอ้างอิงที่ครอบคลุมสำหรับเหตุการณ์ คอลัมน์ และขั้นตอนต่างๆ
- กระบวนการจัดเก็บระบบติดตาม SQL – การอ้างอิง T-SQL สำหรับการสร้างการติดตามฝั่งเซิร์ฟเวอร์
- เอกสารเหตุการณ์ที่ขยายเพิ่มเติม – คำแนะนำการย้ายถิ่นฐานและแนวทางการติดตามสมัยใหม่
- เอกสารประกอบการเก็บข้อมูลแบบสอบถาม – การอ้างอิงการติดตามประสิทธิภาพการค้นหาอัตโนมัติ
- เครื่องมือตรวจสอบและปรับแต่งประสิทธิภาพ – ภาพรวมทั้งหมด SQL Server ตัวเลือกการตรวจสอบ
ทรัพยากรชุมชน
- SQL Server ศูนย์กลาง – บทความ ฟอรัม และสคริปต์สำหรับผู้เชี่ยวชาญด้านฐานข้อมูล
- กองมากเกิน SQL Server แท็ก – คำถามและคำตอบของชุมชนสำหรับคำถามการแก้ไขปัญหาเฉพาะ
- Reddit r/SQLServer – ฟอรัมสนทนาสำหรับ SQL Server หัวข้อและคำแนะนำ
- ฟอรัม SQLServerCentral.com – การสนทนาชุมชนที่กระตือรือร้นเกี่ยวกับการสร้างโปรไฟล์และประสิทธิภาพ
- MSDN SQL Server เว็บบอร์ด – เว็บบอร์ดสนับสนุนชุมชนที่จัดทำโดย Microsoft
บล็อกและบทความทางเทคนิค
- SQL Server การตรวจสอบประสิทธิภาพ – เนื้อหาการตรวจสอบประสิทธิภาพและเพิ่มประสิทธิภาพเฉพาะ
- บล็อก Brent Ozar Unlimited – การปรับแต่งประสิทธิภาพและการติดตามแนวทางปฏิบัติที่ดีที่สุด
- SQLSkills.com – ระดับผู้เชี่ยวชาญ SQL Server เนื้อหาจากผู้นำในอุตสาหกรรม
- ไมโครซอฟท์ SQL Server บล็อก – การอัปเดตผลิตภัณฑ์อย่างเป็นทางการและการประกาศคุณสมบัติ
- พูดคุยง่ายๆ – ปฏิบัติจริง SQL Server บทช่วยสอนและกรณีศึกษา
การฝึกอบรมและการรับรอง
- Microsoft เรียนรู้ – โมดูลการฝึกอบรมออนไลน์ฟรีสำหรับ SQL Server
- ได้รับการรับรองจาก Microsoft: ผู้ช่วยผู้ดูแลระบบฐานข้อมูล Azure – เส้นทางการรับรองอย่างเป็นทางการ
- Pluralsight SQL Server หลักสูตร – การฝึกอบรมวิดีโอเกี่ยวกับการสร้างโปรไฟล์และการปรับแต่งประสิทธิภาพ
- LinkedIn Learning SQL Server การฝึกอบรม – หลักสูตรพัฒนาวิชาชีพ
- Udemy SQL Server หลักสูตรการแสดง – ตัวเลือกการฝึกอบรมภาคปฏิบัติจริง
หนังสือ
- SQL Server การปรับแต่งประสิทธิภาพการค้นหา – คู่มือการเพิ่มประสิทธิภาพการทำงานที่ครอบคลุม
- มือโปร SQL Server ภายใน – เจาะลึกเข้าไป SQL Server สถาปัตยกรรม
- SQL Server แผนการดำเนินการ – ทำความเข้าใจเกี่ยวกับการเพิ่มประสิทธิภาพแบบสอบถาม
- การจัดทำดัชนีประสิทธิภาพของผู้เชี่ยวชาญสำหรับ SQL Server – การออกแบบและเพิ่มประสิทธิภาพดัชนี
- SQL Server การแก้ไขปัญหาขั้นสูงและการปรับแต่งประสิทธิภาพ – เทคนิคการวินิจฉัยขั้นสูง
เครื่องมือและยูทิลิตี้
- SQL Server สตูดิโอการจัดการ – อินเทอร์เฟซหลักสำหรับ SQL Server Profiler
- Azure DataStudio – เครื่องมือฐานข้อมูลข้ามแพลตฟอร์มที่ทันสมัย
- sp_WhoIsActive – กระบวนการจัดเก็บการตรวจสอบที่สร้างโดยชุมชนยอดนิยม
- SQL Sentry Plan Explorer – เครื่องมือวิเคราะห์แผนการดำเนินการฟรี
- DBForge Studio – ผู้พัฒนาภายนอก SQL Server เครื่องมือพัฒนาและบริหารจัดการ
เกี่ยวกับผู้เขียน
หยวน เซิง เป็นผู้ดูแลฐานข้อมูลอาวุโส (DBA) ที่มีประสบการณ์มากกว่า 10 ปีใน SQL Server สภาพแวดล้อมและการจัดการฐานข้อมูลองค์กร เขาประสบความสำเร็จในการแก้ไขปัญหาการกู้คืนฐานข้อมูลหลายร้อยกรณีในองค์กรด้านบริการทางการเงิน การดูแลสุขภาพ และการผลิต
หยวนมีความเชี่ยวชาญด้าน SQL Server การกู้คืนฐานข้อมูล โซลูชันที่มีความพร้อมใช้งานสูงรวมถึงการเพิ่มประสิทธิภาพการทำงาน ประสบการณ์ภาคปฏิบัติที่กว้างขวางของเขารวมถึงการจัดการฐานข้อมูลขนาดหลายเทราไบต์ การนำไปใช้ เสมอในกลุ่มความพร้อมใช้งานและพัฒนาแผนกลยุทธ์การสำรองข้อมูลและกู้คืนข้อมูลอัตโนมัติสำหรับระบบธุรกิจที่มีความสำคัญอย่างยิ่ง
ด้วยความเชี่ยวชาญทางเทคนิคและแนวทางปฏิบัติ Yuan มุ่งเน้นที่การสร้างคู่มือที่ครอบคลุมซึ่งจะช่วยให้ผู้ดูแลระบบฐานข้อมูลและผู้เชี่ยวชาญด้านไอทีแก้ไขปัญหาที่ซับซ้อน SQL Server ท้าทายอย่างมีประสิทธิภาพ เขาคอยติดตามข่าวสารล่าสุดอยู่เสมอ SQL Server การเปิดตัวและเทคโนโลยีฐานข้อมูลที่พัฒนาอย่างต่อเนื่องของ Microsoft ทดสอบสถานการณ์การกู้คืนเป็นประจำเพื่อให้แน่ใจว่าคำแนะนำของเขาสะท้อนถึงแนวทางปฏิบัติที่ดีที่สุดในโลกแห่งความเป็นจริง
มีคำถามเกี่ยวกับ SQL Server การกู้คืนหรือต้องการคำแนะนำในการแก้ไขปัญหาฐานข้อมูลเพิ่มเติมหรือไม่? หยวนยินดีต้อนรับ ข้อเสนอแนะและข้อเสนอแนะ เพื่อปรับปรุงทรัพยากรทางเทคนิคเหล่านี้