ค่า Default ของระดับความเข้ากันได้ (Compatibility Level)
ทุก Database จะสืบทอด Compatibility Level จาก Model Database ที่สร้างมันขึ้นมา ตัวอย่างเช่น Database ของ SQL Server 2012 จะมี Default Compatibility Level = 110 เว้นแต่คุณเปลี่ยนเอง
Compatibility Level หลัง Restore
เมื่อ Restore Backup จาก SQL Version เก่าไปยัง Version ใหม่ Compatibility Level จะคงเดิมเหมือนตอน Backup เว้นแต่ Level ต้นทางต่ำกว่าระดับต่ำสุดที่ Version ใหม่รองรับ ในกรณีนั้น Level จะเปลี่ยนเป็นระดับต่ำสุดที่รองรับ เช่น Restore SQL 2005 ไป SQL 2017 Level จะกลายเป็น 100 (ต่ำสุดของ SQL 2017)
Compatibility Level หลัง Upgrade
Tempdb, Model, MSDB, และ Resource Database จะถูกตั้งเป็น Current Compatibility Level หลัง Upgrade ส่วน Master System Database จะคง Level เดิมก่อน Upgrade
ตรวจสอบและเปลี่ยน Compatibility Level
Query คอลัมน์ compatibility_level ใน sys.databases เพื่อดู Level ปัจจุบัน
เปลี่ยน Level ด้วยคำสั่ง ALTER DATABASE:
USE Master;
GO
ALTER DATABASE <database name> SET COMPATIBILITY_LEVEL = <compatibility-level>;หรือใช้ Wizard: คลิกขวา Database → Properties → Options → Database Compatibility Level
สำคัญ: ถ้า Database ถูก Access โดย User อยู่ ให้เปลี่ยนเป็น Single-user Mode ก่อน แล้วค่อยกลับไป Multi-user Mode หลังเปลี่ยน Level
Default และ Supported Compatibility Levels
ตารางแสดง Version, Default Level และ Supported Levels:
แหล่งที่มา: https://www.sqlskills.com/blogs/glenn/database-compatibility-level-in-sql-server/
Compatibility Level และประสิทธิภาพ
ก่อน SQL 2014 DBA ไม่กังวล Performance ด้าน Compatibility Level มันใช้ควบคุม Feature ใหม่ๆ และ Backward Compatibility เป็นหลัก
ตอน Migrate Version ควรทำ Full Regression Test เพื่อดูการเปลี่ยนแปลง Performance บาง Query เร็วขึ้นกับ Level เก่า บ้างช้าลง ต้องทดสอบจริง
ตั้งแต่ SQL Server 2014 Database ที่รัน Level 120 ขึ้นไป จะใช้ Cardinality Estimate ใหม่ Cardinality Estimation คือ Logic ที่ SQL Server ใช้ประมาณ Cost เพื่อเลือก Execution Plan คำนวณจาก Statistics ของ Object ที่เกี่ยวข้อง โดยสรุปคือ Row-count Estimates รวมกับข้อมูล Distribution, Distinct Values, Duplicate Counts ใน Table/Object ที่ Query อ้างถึง ถ้าประมาณผิดอาจนำไปสู่ Disk I/O เกินจาก Memory Grant ไม่พอ (TempDB Spills) หรือเลือก Serial Plan แทน Parallel Plan เป็นต้น
ผลกระทบจากการเปลี่ยน Compatibility Level
การเปลี่ยน Level = บอก Database ให้เปลี่ยน Feature Set บาง Feature เพิ่มเข้ามา บางอย่างเก่าถูกลบ ตัวอย่าง FOR BROWSE Clause ห้ามใช้ใน INSERT และ SELECT INTO ที่ Level 100 แต่ Level 90 ใช้ได้ (แต่ถูก Ignore) ถ้า App ใช้ Feature นี้ อาจได้ผลไม่คาดคิด
ย้าย Database จาก Level ต่ำไปสูง อาจคิดว่า Feature ใหม่ใช้ไม่ได้ถ้าไม่เปลี่ยน Level — แต่จริงๆ แล้ว Instance-level Features ใช้ได้แม้ไม่เปลี่ยน Compatibility Level เฉพาะ Database-level Features เท่านั้นที่ถูกควบคุม
สรุป
Database Compatibility Level กำหนดว่า SQL Server ใช้ Feature ต่างๆ ยังไง ทำให้มันทำงานเหมือน Version ที่กำหนด เพื่อ Backward Compatibility เนื่องจากเป็น Database Property จึงมีผลต่อ Database-level Features ของ Database นั้นๆ เท่านั้น
ถ้า Upgrade Database (ย้าย Server หรือ In-place Upgrade) Compatibility Level จะคงเดิมถ้ายังรองรับ
ถ้า Level = SQL 2014 (120) ขึ้นไป → ใช้ Cardinality Estimation ใหม่ ถ้า Level = 2012 (110) หรือต่ำกว่า → ใช้ Optimizer เก่า
ใช้แท็บ Feedback เพื่อแสดงความคิดเห็นหรือถามคำถาม
เพิ่มประสิทธิภาพสภาพแวดล้อมด้วยบริการผู้เชี่ยวชาญ
ผู้เชี่ยวชาญ Rackspace Application Services (RAS) ให้บริการ Professional และ Managed Services ครอบคลุม Portfolio หลากหลาย:
- Platform สำหรับ eCommerce และ Digital Experience
- Enterprise Resource Planning (ERP)
- Business Intelligence
- Salesforce Customer Relationship Management (CRM)
- Databases
- Email Hosting และ Productivity
เรามอบ:
- Unbiased Expertise: ลดความซับซ้อนและนำทางการ Modernization เน้นความสามารถที่สร้างคุณค่าทันที
- Fanatical Experience™: รวมแนวทาง Process First. Technology Second.® พร้อม Technical Support ให้ Soluation ครบวงจร
- Unrivaled Portfolio: ประยุกต์ประสบการณ์ Cloud มากมายช่วยเลือกและ Deploy เทคโนโลยีที่เหมาะสมบน Cloud ที่เหมาะสม
- Agile Delivery: ตรงจุดที่คุณอยู่ในการเดินทางและทำให้ความสำเร็จของเราสอดคล้องกับคุณ
แชทตอนนี้เพื่อเริ่มต้น
