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

در شبانه روز ممکن است دستورات 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 را بررسی خواهیم کرد.

(بیشتر…)

همروندی در اوراکل(Parallel Execution)

در دنیای واقعی کارهای بسیاری وجود دارند که اساسا امکان انجام آنها به صورت سریالی به سختی قابل انجام است و به ناچار نیاز است که این کارها به صورت موازی و همروند اجرا شوند به صورت مثال، فرض کنید نیاز است تا در کشوری همانند چین، سرشماری به صورت دستی انجام بگیرد انجام این عمل توسط یک فرد شاید مضحک و غیرعملی بنظر برسد و ممکن است فرد تا پایان سرشماری، از دنیا برود!!! به همین دلیل نیاز است تا سازمانی برای انجام این کار ایجاد شود و نیروهایی را به استخدام خود در بیاورد تا بتواند با تقسیم کار بین آنها، این عمل را با سرعت بیشتری به انجام برساند.

(بیشتر…)

Buffer Busy Wait

فرض کنید بلاکی توسط session شماره یک مورد دستیابی قرار گرفته و توسط آن در بافر pin شده است(هر بافر در هر لحظه تنها توسط یک session می تواند pin شود) و در همین حال session دیگری قصد دسترسی به آن بلاک را دارد در این صورت session دوم باید در انتظار بماند به این مدل از انتظار Buffer Busy Wait گفته می شود.

(بیشتر…)

Join methods

زمانی که یک دستور با چندین شرط join اجرا می شود، عمل join در هر لحظه تنها بین دو جدول آن دستور انجام خواهد شد یعنی به عبارت دیگر، عمل join یک عمل باینری می باشد حال برای تعیین ترتیب join بین جداول، باید حالات مختلفی توسط اوراکل بررسی شود که این کار می تواند وقت زیادی را از سیستم بگیرد برای جلوگیری از این اتلاف وقت، می توان ترتیب پیوند را با استفاده از هینت ORDERED تعیین کرد یعنی با استفاده از این هینت در درون دستور، ترتیب پیوندها بر اساس ترتیب جداول در عبارت from تعیین شوند.

(بیشتر…)