راهنمای جامع بهینه‌سازی عملکرد In-Memory OLTP در SQL Server

دامنه این راهنمای جامع

این مقاله نقشه کامل خانواده In-Memory OLTP در SQL Server است. هدف آن حل مسئله «کاهش تأخیر تراکنش‌های پرتعداد و حذف بخشی از قفل و Latch در مسیرهای حساس» و ایجاد ارتباط روشن میان گزینه‌های پیکربندی، اشیای مدیریتی و Queryهای تشخیصی است.

مخاطبان اصلی DBAها، توسعه‌دهندگان سامانه‌های تراکنشی و معماران کارایی هستند. پیش‌نیاز، شناخت T-SQL، دسترسی آزمایشگاهی و توانایی ثبت Baseline است. در پایان می‌توانید اعضای این خانواده را دسته‌بندی کنید، تفاوت کاربرد آن‌ها را تشخیص دهید و برای هر مورد به آموزش مستقل بروید.

این خانواده دقیقاً 16 موضوع فرزند دارد و لینک هر موضوع فقط در همین مجموعه ارائه شده است. شماره مجموعه بخشی از عنوان یا Slug نیست و ترتیب معرفی مطابق داده ورودی حفظ شده است.

تعریف مجموعه و جایگاه آن

In-Memory OLTP مجموعه‌ای از قابلیت‌های SQL Server است که برای کاهش تأخیر تراکنش‌های پرتعداد و حذف بخشی از قفل و Latch در مسیرهای حساس به‌کار می‌رود.

هسته فنی این مجموعه بر مفاهیم Memory-Optimized Table، XTP Engine، Hash Index، Native Compilation، Checkpoint Files، Garbage Collection استوار است. انتخاب یک عضو بدون شناخت رابطه آن با دیگر اجزا می‌تواند به تنظیم ناقص، مشاهده اشتباه یا نتیجه‌ای کوتاه‌مدت منجر شود.

نقشه مجموعه نشان می‌دهد اعضای In-Memory OLTP چگونه از تعریف و پیکربندی به مشاهده Runtime، تحلیل هزینه و تصمیم اصلاحی متصل می‌شوند.

دسته‌بندی اجزا و مسیر مطالعه

1. آموزش MEMORY_OPTIMIZED = ON و ساخت جدول حافظه‌محور در SQL Server

گزینه MEMORY_OPTIMIZED = ON یک جدول را به موتور In-Memory OLTP متصل می‌کند تا نسخه‌بندی چندگانه و ساختارهای حافظه‌محور برای دسترسی همزمان استفاده شوند.

آموزش کامل و مثال‌های عملی MEMORY_OPTIMIZED = ON

2. آموزش DURABILITY = SCHEMA_AND_DATA در In-Memory OLTP

DURABILITY = SCHEMA_AND_DATA ساختار و داده جدول حافظه‌محور را پایدار می‌کند و تغییرات ثبت‌شده پس از بازیابی دوباره در حافظه بارگذاری می‌شوند.

آموزش کامل و مثال‌های عملی DURABILITY = SCHEMA_AND_DATA

3. آموزش DURABILITY = SCHEMA_ONLY برای داده‌های موقت پرسرعت

DURABILITY = SCHEMA_ONLY ساختار جدول را نگه می‌دارد اما ردیف‌ها پس از Restart یا Failover بازیابی نمی‌شوند؛ بنابراین برای داده‌های قابل بازسازی مناسب است.

آموزش کامل و مثال‌های عملی DURABILITY = SCHEMA_ONLY

4. آموزش Hash Index در جدول‌های Memory-Optimized SQL Server

Hash Index در جدول حافظه‌محور برای جست‌وجوی برابری طراحی شده و با نگاشت کلید به Bucket مسیر دسترسی کوتاهی ایجاد می‌کند.

آموزش کامل و مثال‌های عملی Hash Index

5. آموزش Nonclustered Index برای جدول‌های حافظه‌محور SQL Server

Nonclustered Index حافظه‌محور ساختاری مرتب و مناسب بازه، مرتب‌سازی و شرط‌های نابرابری است و با ایندکس دیسکی یکسان نیست.

آموزش کامل و مثال‌های عملی Nonclustered Index

6. تنظیم BUCKET_COUNT در Hash Indexهای In-Memory OLTP

BUCKET_COUNT ظرفیت منطقی جدول Hash را تعیین می‌کند و بر طول زنجیره Bucket، مصرف حافظه و سرعت جست‌وجوی مساوی اثر می‌گذارد.

آموزش کامل و مثال‌های عملی BUCKET_COUNT

7. آموزش Natively Compiled Stored Procedure در SQL Server

Natively Compiled Stored Procedure بخشی از مسیر Native Compilation در In-Memory OLTP است و هزینه تفسیر T-SQL را در سناریوهای پرتکرار کاهش می‌دهد.

آموزش کامل و مثال‌های عملی Natively Compiled Stored Procedure

8. کاربرد WITH NATIVE_COMPILATION در رویه‌های ذخیره‌شده SQL Server

WITH NATIVE_COMPILATION بخشی از مسیر Native Compilation در In-Memory OLTP است و هزینه تفسیر T-SQL را در سناریوهای پرتکرار کاهش می‌دهد.

آموزش کامل و مثال‌های عملی WITH NATIVE_COMPILATION

9. آموزش BEGIN ATOMIC در رویه‌های Native SQL Server

BEGIN ATOMIC بلوک تراکنشی اجباری رویه‌های Native است و Isolation Level، زبان و رفتار تراکنش را به‌صورت صریح مشخص می‌کند.

آموزش کامل و مثال‌های عملی BEGIN ATOMIC

10. آموزش sys.dm_db_xtp_table_memory_stats و تحلیل حافظه جدول‌ها

نمای مدیریتی sys.dm_db_xtp_table_memory_stats اطلاعات عملیاتی مرتبط با موتور XTP را در سطح مناسب نمایش می‌دهد و برای اندازه‌گیری، عیب‌یابی و تصمیم ظرفیت‌سنجی استفاده می‌شود.

آموزش کامل و مثال‌های عملی sys.dm_db_xtp_table_memory_stats

11. آموزش sys.dm_db_xtp_memory_consumers و مصرف‌کنندگان حافظه XTP

نمای مدیریتی sys.dm_db_xtp_memory_consumers اطلاعات عملیاتی مرتبط با موتور XTP را در سطح مناسب نمایش می‌دهد و برای اندازه‌گیری، عیب‌یابی و تصمیم ظرفیت‌سنجی استفاده می‌شود.

آموزش کامل و مثال‌های عملی sys.dm_db_xtp_memory_consumers

12. آموزش sys.dm_db_xtp_hash_index_stats و سلامت Hash Index

نمای مدیریتی sys.dm_db_xtp_hash_index_stats اطلاعات عملیاتی مرتبط با موتور XTP را در سطح مناسب نمایش می‌دهد و برای اندازه‌گیری، عیب‌یابی و تصمیم ظرفیت‌سنجی استفاده می‌شود.

آموزش کامل و مثال‌های عملی sys.dm_db_xtp_hash_index_stats

13. آموزش sys.dm_db_xtp_index_stats و آمار ایندکس‌های حافظه‌محور

نمای مدیریتی sys.dm_db_xtp_index_stats اطلاعات عملیاتی مرتبط با موتور XTP را در سطح مناسب نمایش می‌دهد و برای اندازه‌گیری، عیب‌یابی و تصمیم ظرفیت‌سنجی استفاده می‌شود.

آموزش کامل و مثال‌های عملی sys.dm_db_xtp_index_stats

14. آموزش sys.dm_db_xtp_transactions و تراکنش‌های In-Memory

نمای مدیریتی sys.dm_db_xtp_transactions اطلاعات عملیاتی مرتبط با موتور XTP را در سطح مناسب نمایش می‌دهد و برای اندازه‌گیری، عیب‌یابی و تصمیم ظرفیت‌سنجی استفاده می‌شود.

آموزش کامل و مثال‌های عملی sys.dm_db_xtp_transactions

15. آموزش sys.dm_xtp_gc_stats و پایش Garbage Collection در XTP

نمای مدیریتی sys.dm_xtp_gc_stats اطلاعات عملیاتی مرتبط با موتور XTP را در سطح مناسب نمایش می‌دهد و برای اندازه‌گیری، عیب‌یابی و تصمیم ظرفیت‌سنجی استفاده می‌شود.

آموزش کامل و مثال‌های عملی sys.dm_xtp_gc_stats

16. آموزش sys.dm_xtp_system_memory_consumers و حافظه سیستمی XTP

نمای مدیریتی sys.dm_xtp_system_memory_consumers اطلاعات عملیاتی مرتبط با موتور XTP را در سطح مناسب نمایش می‌دهد و برای اندازه‌گیری، عیب‌یابی و تصمیم ظرفیت‌سنجی استفاده می‌شود.

آموزش کامل و مثال‌های عملی sys.dm_xtp_system_memory_consumers

جدول مقایسه موضوعات

موضوع یا تابع	نوع	کاربرد اصلی / نکته مهم	لینک آموزش کامل
MEMORY_OPTIMIZED = ON	FEATURE	گزینه MEMORY_OPTIMIZED = ON یک جدول را به موتور In-Memory OLTP متصل می‌کند تا نسخه‌بندی چندگانه و ساختارهای حافظه‌محور برای دسترسی همزمان استفاده شوند…	مطالعه آموزش کامل
DURABILITY = SCHEMA_AND_DATA	FEATURE	DURABILITY = SCHEMA_AND_DATA ساختار و داده جدول حافظه‌محور را پایدار می‌کند و تغییرات ثبت‌شده پس از بازیابی دوباره در حافظه بارگذاری می‌شوند.…	مطالعه آموزش کامل
DURABILITY = SCHEMA_ONLY	FEATURE	DURABILITY = SCHEMA_ONLY ساختار جدول را نگه می‌دارد اما ردیف‌ها پس از Restart یا Failover بازیابی نمی‌شوند؛ بنابراین برای داده‌های قابل بازسازی مناسب …	مطالعه آموزش کامل
Hash Index	FEATURE	Hash Index در جدول حافظه‌محور برای جست‌وجوی برابری طراحی شده و با نگاشت کلید به Bucket مسیر دسترسی کوتاهی ایجاد می‌کند.…	مطالعه آموزش کامل
Nonclustered Index	FEATURE	Nonclustered Index حافظه‌محور ساختاری مرتب و مناسب بازه، مرتب‌سازی و شرط‌های نابرابری است و با ایندکس دیسکی یکسان نیست.…	مطالعه آموزش کامل
BUCKET_COUNT	FEATURE	BUCKET_COUNT ظرفیت منطقی جدول Hash را تعیین می‌کند و بر طول زنجیره Bucket، مصرف حافظه و سرعت جست‌وجوی مساوی اثر می‌گذارد.…	مطالعه آموزش کامل
Natively Compiled Stored Procedure	FEATURE	Natively Compiled Stored Procedure بخشی از مسیر Native Compilation در In-Memory OLTP است و هزینه تفسیر T-SQL را در سناریوهای پرتکرار کاهش می‌دهد.…	مطالعه آموزش کامل
WITH NATIVE_COMPILATION	FEATURE	WITH NATIVE_COMPILATION بخشی از مسیر Native Compilation در In-Memory OLTP است و هزینه تفسیر T-SQL را در سناریوهای پرتکرار کاهش می‌دهد.…	مطالعه آموزش کامل
BEGIN ATOMIC	FEATURE	BEGIN ATOMIC بلوک تراکنشی اجباری رویه‌های Native است و Isolation Level، زبان و رفتار تراکنش را به‌صورت صریح مشخص می‌کند.…	مطالعه آموزش کامل
sys.dm_db_xtp_table_memory_stats	DMV_OR_VIEW	نمای مدیریتی sys.dm_db_xtp_table_memory_stats اطلاعات عملیاتی مرتبط با موتور XTP را در سطح مناسب نمایش می‌دهد و برای اندازه‌گیری، عیب‌یابی و تصمیم ظرف…	مطالعه آموزش کامل
sys.dm_db_xtp_memory_consumers	DMV_OR_VIEW	نمای مدیریتی sys.dm_db_xtp_memory_consumers اطلاعات عملیاتی مرتبط با موتور XTP را در سطح مناسب نمایش می‌دهد و برای اندازه‌گیری، عیب‌یابی و تصمیم ظرفیت…	مطالعه آموزش کامل
sys.dm_db_xtp_hash_index_stats	DMV_OR_VIEW	نمای مدیریتی sys.dm_db_xtp_hash_index_stats اطلاعات عملیاتی مرتبط با موتور XTP را در سطح مناسب نمایش می‌دهد و برای اندازه‌گیری، عیب‌یابی و تصمیم ظرفیت…	مطالعه آموزش کامل
sys.dm_db_xtp_index_stats	DMV_OR_VIEW	نمای مدیریتی sys.dm_db_xtp_index_stats اطلاعات عملیاتی مرتبط با موتور XTP را در سطح مناسب نمایش می‌دهد و برای اندازه‌گیری، عیب‌یابی و تصمیم ظرفیت‌سنجی…	مطالعه آموزش کامل
sys.dm_db_xtp_transactions	DMV_OR_VIEW	نمای مدیریتی sys.dm_db_xtp_transactions اطلاعات عملیاتی مرتبط با موتور XTP را در سطح مناسب نمایش می‌دهد و برای اندازه‌گیری، عیب‌یابی و تصمیم ظرفیت‌سنج…	مطالعه آموزش کامل
sys.dm_xtp_gc_stats	DMV_OR_VIEW	نمای مدیریتی sys.dm_xtp_gc_stats اطلاعات عملیاتی مرتبط با موتور XTP را در سطح مناسب نمایش می‌دهد و برای اندازه‌گیری، عیب‌یابی و تصمیم ظرفیت‌سنجی استفا…	مطالعه آموزش کامل
sys.dm_xtp_system_memory_consumers	DMV_OR_VIEW	نمای مدیریتی sys.dm_xtp_system_memory_consumers اطلاعات عملیاتی مرتبط با موتور XTP را در سطح مناسب نمایش می‌دهد و برای اندازه‌گیری، عیب‌یابی و تصمیم ظ…	مطالعه آموزش کامل

این جریان نشان می‌دهد برای In-Memory OLTP ابتدا مسئله و Scope تعیین می‌شود، سپس عضو مناسب انتخاب، تغییر اعمال و خروجی با View یا DMV مرتبط کنترل می‌شود.

شش مثال ترکیبی و قابل اجرا

مثال ترکیبی 1: کنترل مرحله 1 در In-Memory OLTP

این مثال بخشی از زنجیره تصمیم In-Memory OLTP را پوشش می‌دهد و برای ساخت Baseline یا تأیید وضعیت استفاده می‌شود. آن را با نام اشیا و Permission محیط مقصد هماهنگ کنید.

SELECT SERVERPROPERTY('IsXTPSupported') AS IsXTPSupported;

شاخص	خروجی نمونه
Metric_1381_1	وضعیت نمونه برای مرحله 1
Decision	ادامه، اصلاح یا Rollback بر اساس Baseline

نکته فنی مثال 1: نتیجه را در کنار تغییرات همزمان Instance تحلیل کنید و از یک مشاهده منفرد نتیجه‌گیری قطعی نکنید.

مثال ترکیبی 2: کنترل مرحله 2 در In-Memory OLTP

SELECT name, type_desc FROM sys.filegroups WHERE type = 'FX';

شاخص	خروجی نمونه
Metric_1381_2	وضعیت نمونه برای مرحله 2
Decision	ادامه، اصلاح یا Rollback بر اساس Baseline

نکته فنی مثال 2: نتیجه را در کنار تغییرات همزمان Instance تحلیل کنید و از یک مشاهده منفرد نتیجه‌گیری قطعی نکنید.

مثال ترکیبی 3: کنترل مرحله 3 در In-Memory OLTP

SELECT name, durability_desc FROM sys.tables WHERE is_memory_optimized = 1;

شاخص	خروجی نمونه
Metric_1381_3	وضعیت نمونه برای مرحله 3
Decision	ادامه، اصلاح یا Rollback بر اساس Baseline

نکته فنی مثال 3: نتیجه را در کنار تغییرات همزمان Instance تحلیل کنید و از یک مشاهده منفرد نتیجه‌گیری قطعی نکنید.

مثال ترکیبی 4: کنترل مرحله 4 در In-Memory OLTP

SELECT OBJECT_NAME(object_id) AS table_name, memory_used_by_table_kb FROM sys.dm_db_xtp_table_memory_stats ORDER BY memory_used_by_table_kb DESC;

شاخص	خروجی نمونه
Metric_1381_4	وضعیت نمونه برای مرحله 4
Decision	ادامه، اصلاح یا Rollback بر اساس Baseline

نکته فنی مثال 4: نتیجه را در کنار تغییرات همزمان Instance تحلیل کنید و از یک مشاهده منفرد نتیجه‌گیری قطعی نکنید.

مثال ترکیبی 5: کنترل مرحله 5 در In-Memory OLTP

SELECT OBJECT_NAME(object_id) AS table_name, avg_chain_length, empty_bucket_count FROM sys.dm_db_xtp_hash_index_stats;

شاخص	خروجی نمونه
Metric_1381_5	وضعیت نمونه برای مرحله 5
Decision	ادامه، اصلاح یا Rollback بر اساس Baseline

نکته فنی مثال 5: نتیجه را در کنار تغییرات همزمان Instance تحلیل کنید و از یک مشاهده منفرد نتیجه‌گیری قطعی نکنید.

مثال ترکیبی 6: کنترل مرحله 6 در In-Memory OLTP

SELECT * FROM sys.dm_xtp_gc_stats;

شاخص	خروجی نمونه
Metric_1381_6	وضعیت نمونه برای مرحله 6
Decision	ادامه، اصلاح یا Rollback بر اساس Baseline

نکته فنی مثال 6: نتیجه را در کنار تغییرات همزمان Instance تحلیل کنید و از یک مشاهده منفرد نتیجه‌گیری قطعی نکنید.

سناریوهای واقعی

در سناریوی سازمانی، In-Memory OLTP معمولاً برای یک Query منفرد انتخاب نمی‌شود؛ بلکه بخشی از طراحی ظرفیت، SLO و Change Management است. ابتدا Workloadها بر اساس اهمیت و رفتار طبقه‌بندی می‌شوند، سپس ابزار مناسب برای کنترل یا مشاهده هر دسته انتخاب می‌شود.

سناریوی دوم، عیب‌یابی پس از رشد بار است. در این حالت تیم باید میان مشکل طراحی داده، تنظیم Instance، الگوی اتصال و محدودیت منابع تفکیک قائل شود. اعضای In-Memory OLTP شواهد لازم برای این تفکیک را فراهم می‌کنند اما جایگزین تحلیل ریشه‌ای نیستند.

نکته مهم در طراحی خانواده

هیچ عضو In-Memory OLTP را به‌صورت جدا از وابستگی‌ها و بدون Rollback در Production اجرا نکنید. برخی تغییرات فقط پس از Reconfigure، Compile جدید، Restart یا اتصال جدید دیده می‌شوند؛ بنابراین زمان مشاهده باید با مدل اثر همان عضو هماهنگ باشد.

اشتباهات رایج

انتخاب ابزار بر اساس نام و نه Scope واقعی اثر.
نداشتن Baseline و مقایسه با بازه بار نامشابه.
ترکیب همزمان چند تغییر و ناممکن شدن تشخیص علت.
نادیده گرفتن Permission، Edition یا تفاوت نسخه.
حذف یا Disable بدون ثبت وابستگی و مسیر بازگشت.

Performance Considerations

در In-Memory OLTP معیار اصلی فقط زمان پاسخ نیست. CPU، حافظه، Compile، صف درخواست، تعداد Session و هزینه نگهداری باید همزمان دیده شوند. یک بهبود محلی ممکن است فشار را به بخش دیگری منتقل کند.

برای تحلیل معتبر، Query Store یا Snapshotهای DMV را در بازه‌های همسان نگه دارید و تغییرات Deployment را کنار داده Performance ثبت کنید. Polling سنگین خود می‌تواند اندازه‌گیری را منحرف کند.

Best Practices

برای هر تغییر یک فرضیه قابل آزمون بنویسید.
عضو مناسب را از جدول مقایسه انتخاب و آموزش مستقل آن را مطالعه کنید.
تغییر را کوچک، قابل برگشت و زمان‌بندی‌شده نگه دارید.
تعریف کاتالوگی و رفتار Runtime را با هم کنترل کنید.
پس از موفقیت، Runbook و مالک نگهداری را ثبت کنید.

پنل تصمیم نهایی برای In-Memory OLTP خطاهای طراحی را با مسیر اندازه‌گیری، کنترل ریسک و انتخاب Best Path مقایسه می‌کند.

سؤالات متداول

برای شروع کار با In-Memory OLTP چه پیش‌نیازی لازم است؟

پیش از اجرا، نسخه و Edition، سطح دسترسی، وضعیت پایگاه داده و یک محیط آزمایشی همسان با Production را بررسی کنید. برای In-Memory OLTP ثبت Baseline اولیه باعث می‌شود تغییر واقعی از نوسان عادی جدا شود.

چگونه صحت پیکربندی In-Memory OLTP را بررسی کنیم؟

تعریف کاتالوگی را با نمای Runtime مقایسه کنید، سپس یک سناریوی کنترل‌شده اجرا و نتیجه را در بازه زمانی مشخص ثبت کنید. اتکا به یک Snapshot برای قضاوت درباره In-Memory OLTP کافی نیست.

In-Memory OLTP در چه پروژه‌هایی ارزش تجاری بیشتری ایجاد می‌کند؟

در سامانه‌هایی که تأخیر، پایداری و تفکیک بارکاری مستقیماً بر درآمد یا SLA اثر دارد، In-Memory OLTP می‌تواند ارزش بیشتری ایجاد کند؛ البته نتیجه باید با شاخص قابل اندازه‌گیری تأیید شود.

چه زمانی هزینه نگهداری In-Memory OLTP از منفعت آن بیشتر می‌شود؟

وقتی حجم عملیات پایین، تیم فاقد مهارت نگهداری یا مسیر بازگشت نامشخص است، پیچیدگی In-Memory OLTP ممکن است توجیه نداشته باشد. تصمیم باید بر هزینه کل مالکیت استوار باشد.

In-Memory OLTP با روش جایگزین در SQL Server چه تفاوتی دارد؟

روش جایگزین معمولاً Scope، هزینه اجرا و میزان کنترل متفاوتی دارد. مقایسه درست باید روی Workload واقعی، Plan یا مصرف منابع و نه صرفاً زمان یک Query انجام شود.

برای پیاده‌سازی حرفه‌ای In-Memory OLTP چه خدماتی لازم است؟

تحلیل Workload، طراحی آزمایش، پیاده‌سازی مرحله‌ای، مستندسازی، آموزش تیم و پایش پس از انتشار اجزای اصلی خدمت حرفه‌ای هستند؛ اجرای مستقیم در Production بدون این زنجیره پرریسک است.

رایج‌ترین خطای عملیاتی در In-Memory OLTP چیست؟

خطای رایج، اعمال تنظیم بدون اندازه‌گیری وضعیت پایه و بدون کنترل وابستگی‌هاست. در In-Memory OLTP ابتدا Scope را محدود کنید و هر تغییر را با یک معیار موفقیت و یک شرط توقف همراه سازید.

اثر In-Memory OLTP بر Performance چگونه اندازه‌گیری می‌شود؟

شاخص مناسب به موضوع بستگی دارد، اما زمان پاسخ، CPU، Memory، تعداد اجرای موفق، صف انتظار و تغییر Plan از معیارهای رایج‌اند. مقایسه باید در پنجره بار مشابه انجام شود.

بهترین روش مستندسازی و Rollback برای In-Memory OLTP چیست؟

نام اشیا، دلیل تغییر، مقدار قبل و بعد، مالک تصمیم، زمان اعمال، Query اعتبارسنجی و فرمان بازگشت را در Runbook ثبت کنید تا In-Memory OLTP به تنظیمی ناشناخته تبدیل نشود.

In-Memory OLTP با کدام نسخه‌های SQL Server سازگار است؟

قابلیت دقیق می‌تواند بین نسخه‌ها و محیط‌های Azure تفاوت داشته باشد. مستندات همان نسخه را بررسی و Syntax را روی محیط Test اجرا کنید؛ از تعمیم رفتار نسخه جدید به سرور قدیمی پرهیز شود.

سؤالات مصاحبه

چگونه تشخیص می‌دهید In-Memory OLTP واقعاً روی Workload اثر گذاشته است؟
اگر پس از اعمال In-Memory OLTP وضعیت بدتر شد، ترتیب عیب‌یابی شما چیست؟
چه تفاوتی میان تعریف کاتالوگی و وضعیت Runtime در In-Memory OLTP وجود دارد؟
برای جلوگیری از تغییرات ناخواسته در In-Memory OLTP چه کنترل‌هایی می‌گذارید؟
چه زمانی تصمیم می‌گیرید In-Memory OLTP را حذف یا به روش دیگری مهاجرت دهید؟

چک‌لیست نهایی

فهرست اعضای خانواده و نقش هرکدام را مشخص کنید.
Baseline را قبل از تغییر ثبت کنید.
Permission و سازگاری نسخه را بررسی کنید.
لینک آموزش مستقل عضو انتخابی را مطالعه کنید.
Query اعتبارسنجی و Rollback را آماده کنید.
نتیجه و هزینه جانبی را در Runbook بنویسید.

جمع‌بندی و مسیر ادامه

In-Memory OLTP یک مجموعه ابزار مرتبط است، نه یک تنظیم جادویی. مسیر درست از تعریف مسئله، انتخاب عضو مناسب، آزمایش کنترل‌شده و مشاهده Runtime عبور می‌کند. برای ادامه، یکی از آموزش‌های زیر را بر اساس مسئله واقعی خود انتخاب کنید.

خدمات برنامه‌نویسی و پایگاه داده

برنامه‌نویسی در اصفهان؛ قبول سفارش‌های برنامه‌نویسی و پایگاه داده با شماره 09131253620. انجام پروژه، آموزش برنامه‌نویسی و آموزش SQL Server با رویکرد حرفه‌ای و قابل پشتیبانی.

مجموعه‌ای معتبر با سابقه فعالیت حرفه‌ای از سال ۱۳۷۵ شمسی تاکنون در طراحی سامانه‌های تحت وب، وب‌سایت، پایگاه داده و راهکارهای نرم‌افزاری فعالیت می‌کند.

برای سفارش پروژه‌های جدید با ایتا، واتساپ و تماس مستقیم: +989131253620 ارتباط بگیرید یا صفحه تماس با ما را ببینید.

راهنمای جامع بهینه‌سازی عملکرد In-Memory OLTP در SQL Server | آموزش تخصصی SQL Server