Epicor ERP และ SQL Server Performance Tuning

บทสรุปผู้บริหาร · Executive Summary

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

Epicor ERP บน SQL Server 2016 มีอาการช้าลงตามปริมาณงานและ Active Records การ Purge ช่วยได้เพียงชั่วคราว ทีมจึงวิเคราะห์ Business Process, Job Closing, Scalar User Defined Function และพฤติกรรมของ Database Engine ร่วมกัน

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

ความหมายต่อการตัดสินใจ การเพิ่ม Hardware หรือ Purge ข้อมูลอาจบรรเทาอาการแต่ไม่แทน Root Cause Analysis งานนี้แก้ได้เพราะเชื่อม 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

จากอาการสู่ผลลัพธ์ · Case Journey

สิ่งที่ทีมพบ สิ่งที่ดำเนินการ และผลลัพธ์

อาการที่พบ

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

จุดที่ทีมวิเคราะห์

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

การแก้ไขและผลลัพธ์

ปรับ Job Closing และจัดการ Active Records ที่ไม่จำเป็น
ปรับ Query Path ที่เกี่ยวข้องกับ Scalar UDF
Epicor ERP ตอบสนองดีขึ้นจนผู้ใช้งานยอมรับได้

ผลลัพธ์: ระบบกลับมาทำงานได้เร็วขึ้นโดยแก้ทั้ง Business Process, Application Query และ Database Engine ไม่ได้จำกัดวิธีคิดไว้ที่ฐานข้อมูลยี่ห้อเดียว

วิธีดำเนินการ · Actions

ลำดับการวิเคราะห์และแก้ปัญหา

กำหนดอาการ, Incident window และ Business transaction ที่ช้าให้วัดซ้ำได้
เก็บจำนวน Active Records, สถานะ Job และปริมาณงานในช่วงเดียวกับ Database metrics
ใช้ Query Store หากเปิดใช้งานอยู่ หรือเก็บ DMV snapshot อย่างมีช่วงเวลา เพื่อระบุ Query, duration, CPU และ logical reads
เก็บ Actual Execution Plan และ runtime statistics ของ Query ที่หลักฐานชี้ถึง โดยปกปิดชื่อ Object ก่อนเผยแพร่
ทดสอบการปรับ 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 ของ SQL Server 2016

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

เอกสารอ้างอิง · References

เอกสารเทคนิคที่เกี่ยวข้อง

แหล่งข้อมูล Case: เรียบเรียงจากประสบการณ์แก้ปัญหา Epicor ERP และ SQL Server โดยปกปิดชื่อองค์กร ระบบ และ Object ภายใน
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

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