انجام query rewrite با استفاده از DBMS_ADVANCED_REWRITE

فرض کنید پرس و جوی زیر یکی از پرس و جوهای پراستفاده برنامه می باشد که به دلیل عدم دسترسی به سورس کد برنامه امکان تغییر متن آن وجود ندارد:

SQL>  select /*+INDEX(tbl1,IND_CODE)*/ count(*) from tbl1 where code=2 ;

  COUNT(*)

———-

  51199980

Elapsed: 00:00:05.23

همانطور که می بینید، این پرس و جو حدودا در زمان 4 ثانیه اجرا شده است با برداشتن HINTای که در این پرس  و جو موجود است، آن را مجددا اجرا می کنیم:

SQL> select count(*) from tbl1 where code=2 ;

  COUNT(*)

———-

  51199980

Elapsed: 00:00:01.60

مشاهده می کنید که زمان اجرای پرس و جو با برداشتن HINT از 5 ثانیه به 1 ثانیه کاهش پیدا کرده است قصد داریم با هر بار اجرای پرس و جوی اول، دیتابیس به صورت خودکار پرس و جوی دوم(که فاقد HINT است) را اجرا کند به عبارتی دیگر، دیتابیس در پس زمینه query rewrite را انجام دهد.

(بیشتر…)

خارج کردن اطلاعات یک دستور از shared pool

ممکن است در شرایطی بخواهید صرفا فرم پارس شده یکی از دستورات را از حافظه خارج کنید، در این صورت می توانید از بسته DBMS_SHARED_POOL.PURGE استفاده کنید.

SQL>select ADDRESS, HASH_VALUE,sql_text from V$SQLAREA where  SQL_TEXT like ‘%delete mytbl where %’ and SQL_TEXT not like ‘%v$sql%’;

SQL> exec sys.DBMS_SHARED_POOL.PURGE ‘00000000774B91E0,3503309987′,’C’);

PL/SQL procedure successfully completed


SQL>select ADDRESS, HASH_VALUE,sql_text from V$SQLAREA where  SQL_TEXT like ‘%delete mytbl where %’ and SQL_TEXT not like ‘%v$sql%’;

no rows selected

توجه: پارامتر دوم در پروسیجر Purge(کارکتر C)، به نوع object اشاره دارد که علامت اختصاری objectها را در قسمت زیر می بینید:

–P   package/procedure/function        –JS   java source

–Q  sequence                                        –JC    java class

–R  trigger                                             –JR     java resource

–T  type                                                 –JD     java shared data

نکته ای در مورد elapsed_time برای parallel queyها

در گزارش AWR و همچنین ویوهایی نظیر V$SQLه، elapsed_timeای که برای parallel queryها نمایش داده می شود، جمع بین زمان سپری شدهquery coordinator و parallel query slaveها می باشد از این جهت، نباید این عدد را با elapsed_time واقعی پرس و جو اشتباه گرفت.

مثال زیر را ببینید:

SQL> select /*+parallel(3)*/ sum(id),sum(code),avg(count) from usef.myview;

   SUM(ID)  SUM(CODE) AVG(COUNT)

———- ———- ———-

 713031680 3548381184 68.1508522

Elapsed: 00:01:18.89

SQL> /

   SUM(ID)  SUM(CODE) AVG(COUNT)

———- ———- ———-

 713031680 3548381184 68.1508522

SQL> /

Elapsed: 00:01:17.08

SQL> /

   SUM(ID)  SUM(CODE) AVG(COUNT)

———- ———- ———-

 713031680 3548381184 68.1508522

Elapsed: 00:01:17.94

پس از اجرای دستورات فوق، در گزارش AWR خواهیم دید که Elapsed Time برای query اجرا شده برابر با 228 ثانیه می باشد در صورتی که این query در مدت زمان80 ثانیه(حدودا) اجرا شده است:

 

External Table و In-Memory – اوراکل 18c

تا قبل از اوراکل 18c، امکان استفاده از قابلیت in memory برای جداول از نوع external وجود نداشت:

SQL*Plus: Release 12.2.0.1.0 Production on Mon May 18 12:05:36 2020

SQL> alter table mytbl inmemory;

ORA-30657: operation not supported on external organized table

این قابلیت در اوراکل 18c برای محیط exadata ارائه شد.

Connected to Oracle Database 18c Enterprise Edition Release 18.0.0.0.0

 SQL> alter table mytbl inmemory;

ORA-12755: Feature In-Memory External Tables is disabled due to unsupported capability.

SQL> alter system set “_exadata_feature_on”=true scope=spfile;

System altered.

SQL> startup force;

SQL> alter table mytbl inmemory;

Table altered

SQL> SELECT table_name, inmemory, inmemory_compression FROM user_external_tables;

TABLE_NAME   INMEMORY    INMEMORY_COMPRESSION

———–  ———  ———————-

MYTBL        ENABLED        FOR QUERY LOW

(بیشتر…)

ADO و مدیریت in-memory

همانطور که می دانید، objectهای که خصیصه inmemory برای انها تنظیم شده متناسب با اولویتی که دارند، در in-memory قرار خواهند گرفت برای مثال، اگر خصیصه inmemory برای جدولی با اولویت critical تعریف شده باشد، این جدول صرف نظر از تعداد دفعات رجوع، در زمان استارت دیتابیس در in memory قرار خواهد گرفت.

در این متن به این سوال پاسخ خواهیم داد که چگونه می توان از قرار گرفتن جدول و یا به صورت کلی objectای که مدت زمان زیادی از آخرین زمان دستیابی و یا اصلاح آن گذشته، به in-memory جلوگیری کرد(آن هم به صورت خودکار)؟

این کار در نسخه 12cR2 با کمک ویژگی (Automatic Data Optimization(ADO قابل انجام است همانطور که می دانید ADO که در نسخه 12cR1 ارائه شد، امکان جابجایی و فشرده سازی objectها را متناسب با آمارهای heat map فراهم می سازد. به عنوان بهبودی جدید در نسخه 12cR2، امکان ایجاد ADO policy برای خصیصه inmemory جداول هم امکان پذیر می باشد(در سطح segment).

(بیشتر…)

مروری بر ویژگی IM Expressions

اوراکل از نسخه 12cR2 قابلیت expression tracking را ارائه کرد که بر اساس آن، توابع(اعم از سیستمی و pl/sqlای)، عملگرهای محاسباتی و بصورت کلی عبارتهای استفاده شده در متن پرس و جو ها در دیتابیس ذخیره می شوند مسئولیت این کار بر عهده optimizer است و optimizer در زمان انجام عملیات hard pars، این عبارات را در مخزنی بنام (Expression Statistics Store(ESS قرار می دهد که از طریق ویوی دیتا دیکشنری DBA_EXPRESSION_STATISTICS می توان لیستی از این عبارتها را مشاهده کرد.

(بیشتر…)

ویژگی In-Memory FastStart در اوراکل 12cR2

یکی از چالشهای قابلیت in-memory در نسخه 12cR1 به هزینه بر بودن load اولیه اطلاعات(در in-memory) بعد از restart شدن دیتابیس برمی گردد چرا که اطلاعات در دیسک به صورت row format ذخیره شده و در زمان بارگذاری باید به فرمت ستونی و (عمدتا) به شکل فشرده در حافظه(in-memory) قرار بگیرند که این کار می تواند مصرف بالای منابع(مخصوصا cpu) را به همراه داشته باشد.

اوراکل در نسخه 12cR2، برای حل این مسئله، قابلیت جدیدی به نام In-Memory FastStart را ارائه کرد که بر اساس آن، اطلاعات موجود در in-memory با همان فرمتی که در حافظه قرار دارند، در دیسک و در یک tablespace مجزا ذخیره می شوند.

(بیشتر…)

بررسی پارامترهای رسمی و مخفی مربوط به PGA

همانطور که می دانید PGA متشکل از قسمتهای مختلفی می باشد که میزان استفاده هر پروسس از هر کدام از این قسمتها را می توان با کمک پارامترهای نظیر sort_area_size، hash_area_size، bitmap_merge_area_size و… کنترل کرد.

با این حال از اوراکل 9i، پارامتر دیگری به نام PGA_AGGREGATE_TARGET اضافه شد که با مقداردهی آن، اندازه هر یک از قسمتهای PGA توسط خود اوراکل مدیریت می شود.

اوراکل تلاش می کند مجموع فضای PGA تخصیص داده شده(pga1+pga2+pga3+…) به پروسسها را به مقدار در نظر گرفته شده برای پارامتر PGA_AGGREGATE_TARGET محدود کند اما در مواقعی، به خصوص در زمان بالا رفتن بارکاری سیستم و یا پایین بودن مقدار پارامتر PGA_AGGREGATE_TARGET، ممکن است مجموع فضای PGA تخصیص داده شده، از مقدار تنظیم شده برای این پارامتر بیشتر شود.

از این رو، مقدار تعیین شده برای پارامتر PGA_AGGREGATE_TARGET صرفا به عنوان یک soft limit در نظر گرفته خواهد شد و حتی در شرایطی ممکن است فضای PGA تخصیص داده شده به یک پروسس، از مقدار تنظیم شده برای این پارامتر تجاوز کند!(مطلب “نگاهی به استثنائاتی در مورد پارامترهای PGA” را مطالعه کنید)

(بیشتر…)

پیدا کردن مقادیر متناظر bind variableها برای یک sql_id مشخص

قبلا در مقاله ای در مورد cursor sharing و bind variable مطالبی را ارائه کردیم و فواید و مخاطرات استفاده از bind variable را توضیح دادیم.

همانطور که در آن مطلب اشاره شد، زمانی که پارامتر cursor_sharing به مقدار exact تنظیم شده و در کنار آن از bind variable هم استفاده نشده باشد، با کمترین تغییر در متن دستور(به طور مثال تغییر مقدار id از 10 به 11)، برای اجرای بعدی آن، نیاز به پارس مجدد خواهیم داشت. این مسئله می تواند کندی اجرای دستور و یا حتی در مواردی کندی کلی دیتابیس را به همراه داشته باشد.
برای مثال، در شرایط گفته شده، با اجرای متوالی دو دستور زیر، دو بار عملیات پارس انجام خواهد شد:

delete mytbl where file#=1 and ts#=0;

delete mytbl where file#=1 and ts#=2;

در صورتی که با تبدیل آن به فرم زیر، دستورات با یک بار پارس شدن اجرا می شوند:

delete mytbl where file#=:B1 and ts#=:B2;

(بیشتر…)

چرا Huge Page؟

مدیریت حافظه در سیستم عامل مبحث نسبتا پیچیده و گسترده ای است که ما در این نوشته قصد ورود به جزییات آن را نداریم ولی برای پاسخ دادن به سوال مطرح شده (“چرا Huge Page؟”)، به ناچار باید با اصطلاحاتی چون Page، Page Table، Page Table Entry و TLB آشنا باشیم، از اینرو، در ابتدای این متن، بعضی از مباحث مقدماتی مدیریت حافظه را مرور می کنیم.

در بیشتر پلتفرمها، فضای حافظه به قسمتهای هم اندازه که اصطلاحا Page نام دارد، تقسیم می شود اندازه صفحات در حالت پیش فرض، برابر با 4k می باشد.

مثلا اگر میزان فضای RAM اختصاص داده شده به سروری برابر با 1MB باشد، تعداد صفحات آن برابر با 256 خواهد بود و به همین شکل حافظه یک گیگابایتی به 256000 صفحه و حافظه 128GB حدودا به 32 میلیون صفحه خواهد رسید.

(بیشتر…)