Case 1 · Field Case · Cross-platform Database Performance

วิเคราะห์ Epicor ERP และ SQL Server โดยมองทั้ง Business Process, Query และ Database Engine

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

กรณีจากงานภาคสนาม Technical Review ปกปิดชื่อองค์กรและ Object ไม่มีผลเชิงตัวเลขในชุดข้อมูลปัจจุบัน SQL Server — ไม่มี ORA-xxxxx
บทสรุปผู้บริหาร · Executive Summary

ปัญหาประสิทธิภาพต้องเริ่มจาก Workload ไม่ใช่ยี่ห้อฐานข้อมูล

ข้อมูลการให้บริการที่มีอยู่กล่าวถึง Epicor ERP บน SQL Server 2016 ที่มีอาการช้า และเคยเชื่อมโยงอาการกับ Business Process, ปริมาณ Active Records และ Scalar User Defined Function ใน Application Query ประเด็นเหล่านี้เป็นเส้นทางตรวจสอบที่สมเหตุสมผล แต่ยังไม่พบ Execution Plan, Query Store, performance report หรือข้อมูลก่อน–หลังสำหรับพิสูจน์ว่าองค์ประกอบใดเป็น Root Cause ของเหตุการณ์จริง

คุณค่าของ Case นี้คือการแสดงว่า VT Technology วิเคราะห์ Database Performance โดยไล่จากกระบวนการธุรกิจไปยัง Application SQL, Execution Plan, Database Engine และ Infrastructure วิธีคิดนี้ใช้ได้กับหลายแพลตฟอร์ม แต่การเลือกวิธีแก้ ต้องอ้างอิงกลไกและหลักฐานเฉพาะของผลิตภัณฑ์แต่ละรายเสมอ

ความหมายต่อการตัดสินใจ ยังไม่ควรเพิ่มฮาร์ดแวร์, Purge ข้อมูล, Rewrite Function หรือ Upgrade Database จากบริบทเหตุการณ์เพียงอย่างเดียว ลำดับแรกควรกำหนดอาการและช่วงเวลา เก็บ Business metric กับ Database metric ในช่วงเดียวกัน แล้วจึงทดสอบสมมติฐานทีละข้อโดยมีแผนย้อนกลับ
Layer 1

Business Process

ตรวจวงจร Job, สถานะข้อมูล และปริมาณ Active Records ที่สัมพันธ์กับอาการ

Layer 2

Application SQL

ระบุ Query, Scalar UDF, runtime statistics และ Execution Plan ที่เกิดในช่วงเดียวกัน

Layer 3

Database Engine

ตรวจ SQL Server build, compatibility level, optimizer behavior และ resource pressure

ขอบเขตหลักฐาน · Evidence Boundary

ข้อมูลที่มี แนวทางที่ต้องตรวจ และข้อสรุปที่ยังไม่ควรใช้

ข้อมูลที่บันทึกไว้

  • ระบุ Epicor ERP และ SQL Server 2016
  • กล่าวถึง Job Closing และ Active Records
  • กล่าวถึง Scalar UDF ในเส้นทาง Query

เป็นไปได้ แต่ต้องตรวจเพิ่ม

  • ข้อมูลค้างอาจทำให้ Workload เพิ่มขึ้น
  • Scalar UDF อาจเพิ่ม CPU หรือจำกัดแผนบางรูปแบบ
  • Business Process กับ Query อาจส่งผลซ้อนกัน

ยังสรุปไม่ได้

  • CPU, จำนวนแถว หรือระยะเวลาที่เกิดจริง
  • Query, Function หรือ Index ใดเป็น Root Cause
  • วิธีใดถูกนำไปใช้และระบบดีขึ้นเท่าใด
สถานะเอกสาร: หน้านี้เป็น “บันทึกการวิเคราะห์เชิงเทคนิค” ไม่ใช่ Case Study ที่ยืนยันผลสำเร็จ และจะไม่เพิ่มตัวเลขจากความทรงจำจนกว่าจะพบหลักฐานต้นทางที่ตรวจสอบย้อนกลับได้
แนวทางตรวจสอบ · Safe Next Actions

ลำดับการเก็บหลักฐานก่อนเลือกวิธีแก้

  1. กำหนดอาการ, Incident window และ Business transaction ที่ช้าให้วัดซ้ำได้
  2. เก็บจำนวน Active Records, สถานะ Job และปริมาณงานในช่วงเดียวกับ Database metrics
  3. ใช้ Query Store หากเปิดใช้งานอยู่ หรือเก็บ DMV snapshot อย่างมีช่วงเวลา เพื่อระบุ Query, duration, CPU และ logical reads
  4. เก็บ Actual Execution Plan และ runtime statistics ของ Query ที่หลักฐานชี้ถึง โดยปกปิดชื่อ Object ก่อนเผยแพร่
  5. ทดสอบการปรับ Business Process หรือ Query ทีละรายการในสภาพแวดล้อมควบคุม แล้วเปรียบเทียบ metric เดิมด้วย workload ที่เทียบกันได้

การ Rewrite Scalar UDF, Force Plan, เพิ่ม Index, Purge ข้อมูล หรือ Upgrade SQL Server มีผลต่อโค้ด แผนการทำงาน และการดูแลระบบ จึงต้องมีการทดสอบ ผลกระทบ และ Rollback plan ก่อนใช้กับ Production

รายละเอียดเชิงเทคนิค · Technical Evidence

รายละเอียดสำหรับ DBA/IT

ศัพท์เทคนิคอยู่ใน HTML ตั้งแต่โหลดหน้า แต่พับไว้เพื่อให้ผู้อ่านทั่วไปเห็นบทสรุปก่อน

กรอบวิเคราะห์ Database Performance แบบข้ามแพลตฟอร์ม

หลักการร่วมคือเชื่อมลำดับ อาการ → Workload → SQL → Execution Plan → Database Engine → OS/Storage/Network แล้วหาหลักฐานที่เกิดในช่วงเวลาเดียวกัน สิ่งที่ต่างกันคือเครื่องมือ, Wait model, Optimizer behavior และความเสี่ยงของการเปลี่ยนแปลงในแต่ละผลิตภัณฑ์

ดังนั้นคำว่า “ไม่ยึดติดกับยี่ห้อ” หมายถึงใช้กระบวนการวิเคราะห์จากหลักฐานร่วมกัน ไม่ได้หมายความว่าวิธีแก้ของ Oracle, SQL Server หรือฐานข้อมูลอื่นสามารถนำมาใช้แทนกันโดยตรง

หลักฐาน SQL Server ที่ยังต้องค้นหา
ชั้นการวิเคราะห์ หลักฐานที่ต้องมี คำถามที่ต้องตอบ สถานะ
Business Process Job lifecycle, Active Records, transaction volume อาการสัมพันธ์กับสถานะงานและปริมาณข้อมูลหรือไม่ ยังไม่พบ
Application SQL Query text แบบปกปิด, Query Store/DMV, runtime statistics Query ใดใช้ CPU, duration และ logical reads สูงใน Incident window ยังไม่พบ
Execution Plan Actual plan, estimates เทียบ actual, UDF operators แผนใดและกลไกใดทำให้ต้นทุนเพิ่ม ยังไม่พบ
Engine/Infrastructure Build, compatibility level, waits, CPU, I/O และ memory window คอขวดอยู่ใน Engine หรือทรัพยากรชั้นใด ยังไม่พบ
Scalar UDF ใน SQL Server 2016 ต้องตีความอย่างไร

Scalar T-SQL UDF อาจมีต้นทุนจากการเรียกซ้ำแบบ iterative, การประมวลผลคำสั่งภายในแยกกัน และข้อจำกัดด้านการทำ parallelism แต่การพบ UDF ใน Query ไม่ได้พิสูจน์ว่า UDF เป็น Root Cause ต้องตรวจ Actual Execution Plan และ runtime statistics ของ Query นั้นก่อน

Microsoft ระบุว่า Scalar UDF Inlining เป็นความสามารถของ SQL Server 2019 และใหม่กว่า สำหรับ Function และบริบทที่ผ่านเงื่อนไข จึงไม่ควรนำความสามารถดังกล่าวไปอธิบาย SQL Server 2016 และไม่ควรสรุปว่าการ Upgrade จะทำให้ Query นี้เร็วขึ้นโดยอัตโนมัติ

Query Store, Version scope และ ORA-xxxxx

Query Store มีใน SQL Server 2016 และสามารถเก็บ Query, Execution Plan และ runtime statistics แต่ SQL Server 2016 ไม่ได้เปิด Query Store โดยค่าเริ่มต้นทุกฐานข้อมูล การเปิดหรือเปลี่ยนค่าต้องประเมิน storage, retention และผลกระทบก่อน หากไม่ได้เปิดไว้ในช่วงเหตุการณ์ ข้อมูลย้อนหลังอาจไม่มี

Case นี้เป็น Microsoft SQL Server จึงไม่มีรหัส Oracle ORA-xxxxx ที่เกี่ยวข้อง การเพิ่ม ORA เพื่อ SEO จะทำให้ผู้อ่านและ Search Engine เข้าใจเหตุการณ์ผิด

แหล่งข้อมูลและข้อจำกัด · Sources

แหล่งข้อมูลและข้อจำกัด

  • แหล่งข้อมูล Case: เรียบเรียงจากข้อมูลการให้บริการที่มีอยู่ โดยชุดเอกสารปัจจุบันไม่ครอบคลุมไฟล์ Performance ต้นทางสำหรับตรวจสอบซ้ำ
  • ข้อจำกัด: ไม่มี Incident window, Business metric, Query Store, DMV snapshot, Execution Plan หรือผลทดสอบก่อน–หลังในชุดข้อมูลปัจจุบัน
  • Scalar UDF: อ้างอิง Microsoft Learn: Scalar UDF Inlining
  • Query Store: อ้างอิง Microsoft Learn: Monitor Performance by Using the Query Store

ระบบ ERP ช้า แต่ยังไม่ทราบว่าปัญหาอยู่ชั้นใด?

VT Technology วิเคราะห์ตั้งแต่ Business Process, Application SQL และ Execution Plan ไปจนถึง Database Engine และ Infrastructure โดยเลือกเครื่องมือให้เหมาะกับแพลตฟอร์มและหลักฐานที่มี

ปรึกษาการวิเคราะห์ Database Performance