قبلا در مقاله ای قابلیت Automatic In-Memory که یکی از فیچرهای جدید اوراکل در نسخه 18c است را مورد بررسی قرار دادیم. همانطور که در “مقاله یاد شده” اشاره کردیم، قابلیت Automatic In-Memory از طریق پارامتر INMEMORY_AUTOMATIC_LEVEL کنترل می شود که در نسخه 18c در دو سطح LOW و MEDIUM قابل تنظیم است. در نسخه 21c می توان مقدار High را هم برای این پارامتر تنظیم کرد که در ادامه نکاتی را در این مورد ارائه خواهیم کرد.

 

Automatic In-Memory در سطح High

با تنظیم پارامتر INMEMORY_AUTOMATIC_LEVEL به مقدار High، خصیصه inmemory برای segmentهای غیر سیستمی دیتابیس به صورت INMEMORY MEMCOMPRESS AUTO فعال خواهد شد(به استثنای external table، IOTها و ایندکسها). البته اگر از قبل قابلیت INMEMORY برای سگمنتی تنظیم شده باشد، تغییری در خصیصه inmemory_compression آن ایجاد نخواهد شد.

توضیح: منظور ما از segmentهای سیستمی، سگمنهایی هستند که کاربر مالک آنها توسط خود اوراکل ایجاد شده باشد و اصطلاحا Oracle-maintained باشند البته در این استثنا یاد شده هم استثنا وجود دارد چرا که اوراکل خصیصه inmemory را برای جدول AUD$UNIFIED هم تنظیم می کند در صورتی که کاربر مالک آن(AUDSYS) توسط اوراکل ایجاد شده است:

SQL> select p.username,p.oracle_maintained from dba_users p where p.username=’AUDSYS‘;

USERNAME   O

———- –

AUDSYS     Y

زمانی که پارامتر INMEMORY_AUTOMATIC_LEVEL به مقدار high تنظیم می شود، اوراکل متناسب با آمارهایی که از نحوه رجوع و استفاده از جداول و ستونها وجود دارد، تصمیم می گیرد segmentها را در IM column store مدیریت کند به این صورت که segmentهایی که بیشتر به آنها رجوع می شود را در حافظه نگه می دارد(hot segmentها) و cold segmentها که به ندرت مورد دسترسی قرار می گیرند را فشرده و یا در صورت کمبود فضا، از IM column store حذف می کند.

البته رفتار دو مقدار MEDIUM و HIGH در این زمینه بسیار شبیه به هم است با این تفاوت که با تنظیم مقدار high برای پارامتر INMEMORY_AUTOMATIC_LEVEL، از فشرده سازی در سطح cold columnها هم بهرمند خواهیم شد.

در قسمت زیر، با ارائه یک سناریو، نحوه انجام کار Automatic In-Memory را در زمانی که پارامتر INMEMORY_AUTOMATIC_LEVEL به مقدار High تنظیم شده است، نمایش داده ایم.

---

قبل از تغییر مقدار پارامتر INMEMORY_AUTOMATIC_LEVEL، وضیعت جداول را به لحاظ فعال بودن خصیصه in-memory بررسی می کنیم:

SQL> SELECT table_name,inmemory,inmemory_compression,inmemory_priority FROM user_tables order by 1;

TABLE_NAME INMEMORY INMEMORY_COMPRESS INMEMORY

———- —————– 

TBL1            DISABLED

TBL2            DISABLED

به root container وصل شده و  پارامتر INMEMORY_AUTOMATIC_LEVEL را به مقدار high تنظیم می کنیم:

SQL> show con_name

CON_NAME

——————–

CDB$ROOT

SQL> alter system set inmemory_size=500m scope=spfile;

System altered.

SQL> alter system set INMEMORY_AUTOMATIC_LEVEL=high scope=spfile;

System altered.

SQL> startup force;

بعد از بالا آمدن دیتابیس، باید کمی منتظر بمانیم(معمولا بیش از یک دقیقه) تا خصیصه in-memory برای همه جداول تنظیم شود:

SQL> show con_name

CON_NAME

——————————

PDB1

SQL> @inmemory

همچنین از طریق ویوی v$im_user_segments خواهیم دید که هیچ کدام از این جداول در حافظه بارگذاری نشده اند:

SQL>SELECT segment_name, round(inmemory_size/1024/1024) inmemory_size_MB, round(bytes/1024/1024) bytes_MB, round(bytes_not_populated/1024/1024) bytes_not_populated_MB , populate_status FROM v$im_user_segments;

no rows selected

با فراخوانی جدول tbl1، این جدول به حافظه منتقل خواهد شد:

SQL> select /*+full(a)*/ count(*)from tbl1 a;

  COUNT(*)

———-

     75194

انتظار داریم جدول در in-memory بارگذاری شده باشد:

SQL> @im_user_segments

همچنین با فراخوانی tbl2 این جدول هم به حافظه منتقل خواهد شد:

SQL> select /*+full(a)*/ count(*)from tbl2 a;

  COUNT(*)

———-

     75195

SQL> @im_user_segments