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

نویسنده مطلب: وحید یوسف زاده Leave a comment

در گزارش 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 ثانیه(حدودا) اجرا شده است:

 

ADO و مدیریت in-memory

نویسنده مطلب: وحید یوسف زاده 3 Comments

همانطور که می دانید، 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).

(بیشتر…)

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

نویسنده مطلب: وحید یوسف زاده Leave a comment

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

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

(بیشتر…)

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

نویسنده مطلب: وحید یوسف زاده 4 Comments

همانطور که می دانید 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 مشخص

نویسنده مطلب: وحید یوسف زاده 2 Comments

قبلا در مقاله ای در مورد 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 بعضی از دستورات بعد از ارتقای دیتابیس

نویسنده مطلب: وحید یوسف زاده Leave a comment

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

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

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

(بیشتر…)

pin کردن object در shared pool

نویسنده مطلب: وحید یوسف زاده Leave a comment

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

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

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

(بیشتر…)

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

نویسنده مطلب: وحید یوسف زاده 2 Comments

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

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

(بیشتر…)

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

نویسنده مطلب: وحید یوسف زاده 1 Comment

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

(بیشتر…)

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

نویسنده مطلب: وحید یوسف زاده 1 Comment

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

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

(بیشتر…)