در نسخه های اوراکل پیش از 12c، ایجاد ایندکس برای یک جدول پارتیشن بندی شده، سبب ایجاد ایندکس برای همه پارتیشنهای آن جدول می شد. چالش اساسی در این زمینه زمانی مطرح می شود که در مواردی، ایجاد ایندکس، اساسا کاربردی برای پارتیشنهای قدیمی جدول و یا حداقل بعضی از پارتیشنهای آن، ندارد.
(بیشتر…)Real-Time Statistics در اوراکل 19c
تا قبل از اوراکل نسخه 12c، اجرای دستورات DMLای بر روی یک جدول(به هر دو روش Conventional و Direct-path)، منجر به بروزرسانی آمار(Statistics) آن جدول نمی شد و جمع آوری انلاین آمار، صرفا در زمان ساخت ایندکس قابل انجام بود.
در نسخه 12c بهبود مختصری در این زمینه رخ داد که بر اساس آن، همراه با عملیات Bulk load بر روی یک جدول، آمارهای آن جدول هم به صورت انلاین بروز خواهد شد اما کماکان برای دستورات DMLای که به صورت CONVENTIONAL اجرا می شوند، تغییری در آمارهای جدول ایجاد نمی شود.
یکی از قابلیتهای جدید اوراکل نسخه 19c، ویژگی Real-Time Statistics می باشد که قابلیت بروزرسانی آنلاین بعضی از آمارهای مهم را همراه با اجرای دستورات DMLای، فراهم خواهد کرد.
(بیشتر…)اوراکل 19c – ارائه گزارش برای استفاده از hintها(HINT_REPORT)
زمانی که از چند HINT در متن دستور(مخصوصا یک پرس و جوی پیچیده) استفاده می کنیم، ممکن است در جستجوی روشی باشیم تا از استفاده اوراکل از این HINTها اطمینان حاصل کنیم و یا به صورت کلی بدانیم که از کدام یک از این hintها صرف نظر شده و چند hint مورد استفاده قرار گرفته است؟
(بیشتر…)بهبود سرعت درج انبوه با unusable کردن ایندکسها
در زمان بازسازی یک جدول حجیم و یا درج قابل توجهی از اطلاعات در یک جدول، unusable کردن ایندکسها می تواند باعث تسریع انجام عملیات شود. در ادامه با یک مقایسه ساده، این موضوع را نشان خواهیم داد.
برای انجام سناریو، جدولی را به همراه دو ایندکس ایجاد می کنیم.
Direct path vs Conventional insert
در این متن قصد داریم به بررسی دو شیوه رایج انجام عملیات insert که Conventional و Direct-path(با کمک هینت append و append_values) می باشند، بپردازیم و در نهایت ویژگیها و چالشهای Direct-path insert را مورد بررسی قرار دهیم.
نظارت اوراکل بر تغییرات جداول
در شبانه روز ممکن است دستورات 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 را به خود اختصاص خواهد داد.