نگاهی به استثنائاتی در مورد پارامترهای PGA

در مطلب “بررسی پارامترهای PGA” با پارامترهایی آشنا شدیم که قرار است محدودیتی را برای مصرف PGA در سطح پروسس و یا instance ایجاد کنند. در این مطلب خواهیم دید که در بعضی از شرایط مقدار در نظر گرفته شده برای پارامترهای pga_max_size، pga_aggrigate_target_ و حتی پارامتر PGA_AGGREGATE_LIMIT، نمی تواند PGA مصرف شده توسط پروسسها را محدود کند و پروسسها تا جایی که سرور و محدودیتهای سیستم عاملی اجازه می دهد، از RAM و SWAP استفاده می کنند.

به عنوان نمونه، مطابق با داکیومنتهای اوراکل، حداکثر PGA مورد استفاده یک پروسس توسط پارامتر مخفی pga_max_size_ کنترل می شود و علاوه بر این پارامتر، مقدار PGA استفاده شده برای یک پروسس به تنهایی نمی تواند بزرگتر از مقدار تنظیم شده برای پارامتر pga_aggrigate_target  باشد.

(بیشتر…)

بررسی پارامترهای رسمی و مخفی مربوط به 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;

(بیشتر…)

فیکس کردن plan بعضی از دستورات بعد از ارتقای دیتابیس

بعد از ارتقای دیتابیس به نسخه ای بالاتر، ممکن است زمان اجرای بعضی از پرس و جوها افزایش پیدا کند. این کندی می تواند به تغییراتی که در رفتار optimizer در هر نسخه از اوراکل ایجاد می شود، برگردد.

در جدول زیر اسامی تعدادی از قابلیتهایی که توسط optimizer در نسخه 11g و 12c قابل استفاده است را مشاهده می کنید:

در این متن به دنبال روشی هستیم که تغییر رفتار optimizer، در دو نسخه مختلف اوراکل را برای یک پرس و جوی مشخص نمایش داده و سپس با کمک قابلیت SQL Plan Management، پلن اجرایی ایجاد شده توسط optimizer، در یکی از این نسخه ها را برای پرس و جوی مورد نظر، فیکس کنیم.

(بیشتر…)

pin کردن object در shared pool

می دانیم که shared pool فرم پارس شده دستورات sql و pl/sql را در صورت دارا بودن فضای کافی در خود نگهداری می کند و نسخه قابل اجرای دستورات، در این قسمت از حافظه باقی خواهند ماند تا در صورت اجرای مکرر یک دستور، از کامپایل مجدد آن و یا به بیانی دقیق تر، از انجام عملیات hard pars جلوگیری شود.

فرض کنید به دلایلی چون عدم استفاده از bind variable در قسمتی از برنامه، فضای خالی ای در shared pool باقی نمانده است در این صورت، اوراکل فرمهای پارس شده را بر اساس الگوریتم LRU از حافظه خارج خواهد کرد این مسئله ممکن است سبب age out شدن objectهای سیستمی و یا applicationای شود که به کررات مورد دستیابی قرار می گیرند.

با در نظر داشتن این مسئله، قصد داریم به این سوال پاسخ دهیم که چگونه می توان این objectها را در shared pool سنجاق کرد تا الگوریتم LRU نتواند آنها را برای خروج از shared pool انتخاب کند.

(بیشتر…)

بهبودی در جمع آوری خودکار آمار در اوراکل 19c

در محیطهای که نرخ تغییر داده نسبتا زیاد است، شاید استفاده از آمارهای بروز شده از طریق automated maintenance taskهای شبانه، چندان کارا نباشد با این نگاه، اوراکل در نسخه 19c، قابلیتهای جدیدی را در زمینه جمع آوری و بروزرسانی خودکار Statistic ارائه کرده که قبلا در مقاله ای یکی از این قابلیتها را که Real-time Statistic نام داشت، مورد بررسی قرار دادیم.

در این مقاله قصد داریم به یکی دیگر از این قابلیتها که High-frequency Optimizer Statistics Collection نام دارد، بپردازیم.

(بیشتر…)

تهیه گزارش AWR در محیط ADG

همانطور که می دانید؛ ایجاد گزارش awr در محیط ADG به صورت روتین امکان پذیر نمی باشد این اتفاق به دلیل عدم امکان ایجاد snapshot بر روی بانکی که در حالت read only قرار دارد، کاملا منطقی بنظر می رسد. در اوراکل 12cR2، راهکاری برای این مسئله اندیشیده شد و امکان تهیه این گزارش برای ADG هم فراهم شده است.

(بیشتر…)

مانیتورینگ ایندکسها در اوراکل 11g و 12c

#پرسش: کدام یک از ایندکسها در بانک اطلاعاتی بلاستفاده و قابل حذف هستند؟ تعداد رجوع به یک ایندکس را چگونه می توان تعیین کرد؟

پاسخ: دست یافتن به پاسخ قسمت اول این سوال، در اوراکل نسخه 10g و 11g نسبتا کار ساده ای است این کار با اجرای یک دستور و همچنین طول کشیدن مدت زمانی از اجرای ان(گاها بیش از چند ماه)، قابل انجام خواهد بود.

(بیشتر…)

Automatic Big table caching

همانطور که می دانید، با انتقال بلاک یک جدول از دیسک به حافظه(بافرکش) و دسترسی کاربر به اطلاعات موجود در آن، این بلاک برای مدت زمانی در حافظه باقی خواهد ماند(البته در صورت امکان) تا در صورت نیاز به رجوع مجدد، لزومی به انجام physical read دوباره برای دستیابی به این اطلاعات نباشد. مکرر در مستندات اوراکلی خوانده ایم که مدیریت این caching در سطح بلاک(نه در سطح object) و با کمک الگوریتم (LRU(least recently used انجام می شود.

(بیشتر…)