ویژگی Memoptimized Rowstore – Fast Ingest در اوراکل 19c

همانطور که می دانید، IOT Deviceها به طور پیوسته جریانی از داده را به سمت دیتابیس هدایت می کنند به طوری که درج این داده ها در دیتابیس رابطه ای می تواند با چالشهای پرفورمنسی همراه باشد.

در اوراکل نسخه 19c ، راهکاری برای حل این مسئله پرفورمنسی ارائه شد که مطابق با آن، این دسته از دیتا ابتدأَ در حافظه ثبت شده و در نهایت به صورت دسته ای به دیسک منتقل می شوند. این قابلیت جدید، Memoptimized Rowstore Fast Ingest نام دارد.

البته به این ویژگی اصطلاحا deferred insert هم گفته می شود چرا که ابتدا دیتا در قسمتی از large pool ثبت می شود و بعد از گذشت مدت زمانی، به صورت خودکار توسط اوراکل به دیسک منتقل شده و در زمانی که دیتا در Large Pool قرار دارد، توسط sessionهای دیگر قابل رویت نخواهد بود.

(بیشتر…)

شناسایی ایندکس های بی استفاده

ایندکس های بی استفاده سبب ایجاد سربار در عملیات DML می شوند و فضای دیتابیس را هدر می دهند. همانطور که در مطلب روشی برای شناسایی ایندکس های تکراری اشاره شد می توان تعداد موارد بکارگیری ایندکس ها توسط OPTIMIZER در بازه های زمانی گذشته را استخراج کرد و ایندکس های بی استفاده را حذف نمود. در  این متن سه روش مختلف برای شناسایی ایندکس های بی استفاده را توضیح می دهیم.

(بیشتر…)

نگاهی به اثر منفی پرفورمنسی Out Of Place Refresh

بروزرسانی Materialized View(MV) به روش Out of Place ، قابلیت جدیدی بود که در اوراکل نسخه 12c ارائه شد، در این روش، در زمان بروزرسانی MV، به جای دستکاری جدول جاری MV، اوراکل جدول جدیدی را ایجاد می کند و حاصل اجرای متن MV را در این جدول درج خواهد کرد بعد از آنکه اطلاعات بروز شده به صورت کامل در جدول جدید درج شد، این جدول با جدول جاری MV جایگزین می شود.

با توجه به آنکه در مورد ویژگی Out Of Place Refresh قبلا مطلبی را ارائه کردیم از تکرار مجدد آن پرهیز کرده و در این مطلب به بررسی یکی مضرات پرفورمنسی این شیوه از بروزرسانی خواهیم پرداخت.

Out Of Place Refresh در کنار مزایایی که دارد ممکن در شرایطی برای دیتابیس سربار پرفورمنسی ایجاد کند. چرا که در این روش از بروزرسانی، با هر بار بروزرسانی MV، جدولی حذف و جدول جدیدی ایجاد خواهد شد و جدول جدید مشخصات مختص به خود را دارد(نظیر object_id و …) و برای دیتابیس یک object جدید محسوب می شود.

ایجاد جدول جدید سبب می شود تا فرمهای پارس شده همه پرس و جوهایی که به این MV رجوع کرده اند، نامعتبر شده و از حافظه خارج شوند و این پرس و جوها برای اجرای مجدد، باید یکبار دیگر پارس شوند.

(بیشتر…)

روشی برای شناسایی ایندکس های تکراری

همانطور که در مطلب ایندکس های ترکیبی اشاره شد می توان در کنار ایندکس های عادی، ایندکس های ترکیبی که ترتیب ستون های آنها از اهمیت زیادی برخوردار است ایجاد کرد تا QUERYهای مختلف بتوانند با سرعت بالاتر اجرا شوند.

از طرفی دیگر استفاده از ایندکس های زیاد سبب ایجاد سربار در عملیات DML می شود و فضای دیتابیس را هدر می رود. در این متن یک QUERY برای یافتن ایندکس هایی که ستون های تکراری دارند معرفی می شود.

(بیشتر…)

ارتقا Minor Version لینوکس در محیط کلاستر

قبل از ارتقا Grid Infrastructure به نسخه بالاتر، باید بررسی کرد که کرنل نسخه جاری سیستم عامل، Grid Infrastructure نسخه جدید را پشتیبانی می کند؟ و در صورت عدم پشتیبانی، نسخه سیستم عامل را در صورت امکان ارتقا داد.

در جدول زیر می بینید که ACFS و AFD اوراکل 19c، در کدام یک از نسخه های کرنلOracle Linux(X86_64) پشتیبانی می شوند:

در صورت عدم پشتیبانی grid نسخه جدید در سیستم عامل نسخه جاری، در زمان ارتقا، با چنین خطایی مواجه خواهیم شد:

Verifying ACFS Driver Checks …FAILED

PRVG-6096 : Oracle ACFS driver is not supported on the current operating system

(بیشتر…)

ایندکس های ترکیبی

ایندکس ترکیبی یا COMPOSITE INDEX برای دو یا چند ستون از جدول تعریف می شود ولی به هر ترتیبی که ستون ها در عبارت ساخت ایندکس قرار گیرند فقط یکسری از QUERYها می توانند از آن ایندکس استفاده کنند. در این متن روش استفاده مناسب از ایندکس های ترکیبی و نحوه عملکرد آنها را توضیح می دهیم.

(بیشتر…)

undo_retention یا auto tuned_undoretention؟

همانطور که می دانید از طریق پارامتر undo_retention می توان تعیین کرد که undoها برای چه مدت زمانی در وضعیت unExpire قرار داشته باشند و با فرض عدم کمبود فضا برای undo tablespace، وضعیت undo dataهای unExpire بعد از چه مدت زمانی به Expire تغییر کند.

برخلاف انتظار، بسیاری از مواقع در محیطهای عملیاتی شاهد آن هستم که undo dataها بعد از مدت زمان تعیین شده برای undo_retention هم موجود و قابل استفاده هستند که در سناریوی زیر این مسئله را مشاهده می کنید.

(بیشتر…)

ایندکس های B-TREE عادی و UNIQUE

ایندکس B-TREE پرکاربردترین ایندکس در دیتابیس اوراکل است که در حالت پیش فرض به صورت غیر UNIQUE ساخته می شود. ایندکس های B-TREE را می توان به صورت UNIQUE نیز تعریف نمود که هیچ تفاوتی از لحاظ PERFORMANCE و ساختار داده ها با ایندکس عادی ندارند. در این متن ساختمان داده و روش عملکرد ایندکس های عادی B-TREEE و UNIQUE را توضیح می دهیم.

(بیشتر…)

در چه شرایطی برای یک ستون هیستوگرام تهیه می شود؟

قبلا در مطلبی توضیح دادیم که اوراکل وضعیت بروز و یا stale بودن آمارهای جدول را بر اساس اطلاعات موجود در جدول $sys.mon_mods_all تعیین می کند(ویوی dba_tab_modifications شکل خواناتری را از این اطلاعات نمایش می دهد.) و بر اساس آن تصمیم می گیرد که آمار چه جداولی را باید بروزرسانی کند.

در این متن قصد داریم بررسی کنیم که اوراکل در زمان جمع آوری آمار، بر چه مبنایی به این نتیجه می رسد تا برای ستونی Histogram تهیه کند؟

(بیشتر…)

نکاتی در مورد LOCAL TEMPORARY TABLESPACE(اوراکل 12cR2)

همانطور که می دانید، در محیط RACء، Temporary Tablespaceها در سطح دیتابیس ایجاد شده و tempfileها هم باید در فضای shared بین همه instanceها به اشتراک گذاشته شوند.

از اوراکل 12cR2 نوع دیگری از Temporary Tablespace تحت عنوان local temporary tablespace اضافه شده که tempfileهای این نوع از temp TBSها را می توان در فضای local مربوط به instance ایجاد نمود.

در ادامه متن به نحوه ایجاد و مدیریت این نوع از temp tbsها و همچنین نحوه اولویت دهی اوراکل بین Shared Temporary Tablespace و Local temporary tablespace خواهیم پرداخت.

(بیشتر…)