اوراکل 19c – ارائه گزارش برای استفاده از hintها(HINT_REPORT)

زمانی که از چند HINT در متن دستور(مخصوصا یک پرس و جوی پیچیده) استفاده می کنیم، ممکن است در جستجوی روشی باشیم تا از استفاده اوراکل از این HINTها اطمینان حاصل کنیم و یا به صورت کلی بدانیم که از کدام یک از این hintها صرف نظر شده و چند hint مورد استفاده قرار گرفته است؟

(بیشتر…)

بهبود سرعت درج انبوه با unusable کردن ایندکسها

در زمان بازسازی یک جدول حجیم و یا درج قابل توجهی از اطلاعات در یک جدول، unusable کردن ایندکسها می تواند باعث تسریع انجام عملیات شود. در ادامه با یک مقایسه ساده، این موضوع را نشان خواهیم داد.

برای انجام سناریو، جدولی را به همراه دو ایندکس ایجاد می کنیم.

(بیشتر…)

نظارت اوراکل بر تغییرات جداول

در شبانه روز ممکن است دستورات DMLای متعددی بر روی جداول مختلف اجرا شوند، در نظر داشتن این مسئله، ذهن را متوجه چالش مهمی خواهد کرد!

از بین جداولی که بعضا حجم انها به چند صد میلیون می رسد، کدام یک بیشترین تغییرات را به لحاظ حجمی داشته اند؟ و به بیانی بهتر، برای کدام یک از جداول، باید(بهتر است) بروزرسانی امار(gather statistic) انجام شود؟

برای پاسخ به این دسته از سوالات، نیاز است تا نظارتی بر روی جداول صورت پذیرد و تعداد عملیات DMLای که بر روی انها انجام می شود، در جدولی از بانک ثبت شود.

(بیشتر…)

تهیه گزارش 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 انجام می شود.

(بیشتر…)

پارامتر commit_wait و log file sync

همانطور که می دانید، قبل از انجام هر commit در بانک اطلاعاتی، باید همه redo informationهای تراکنش مربوطه، با کمک پروسس LGWR، به online redo log منتقل شوند و پس از اتمام عملیات log writer، پیام انجام commit، به کاربر برگردد(Commit complete) این مدت زمان انتظار در اوراکل، به عنوان جزیی از Wait Eventای به نام log file sync شناخته می شود و بدیهی است که در صورت رخ دادن این اتفاق(انتظار برای انجام commit)، طبیعتا log file sync  هم درصد بیشتری از dbtime را به خود اختصاص خواهد داد.

(بیشتر…)

ایجاد SQL Profile به صورت دستی

برای اعمال نظر در مورد execution plan پرس و جویی که اصلاح متن ان امکان پذیر نیست، می توان از sql profile کمک گرفت و از طریق ایجاد ان، هینتهایی را به این پرس و جو اعمال کرد. در ادامه همراه با یک مثال ساده، اثر استفاده از sql profile را بررسی خواهیم کرد.

(بیشتر…)