Automatic Index Optimization در اوراکل 21c

همانطور که می دانید، از طریق قابلیت (Automatic Data Optimization (ADO می توان سیاستهایی را بر اساس آمارهای دستیابی و اصلاح segmentها، برای کاهش فضای مصرفی و بهبود کارایی اعمال کرد برای مثال با فشرده سازی جداولی که کمتر مورد اصلاح و یا دستیابی قرار می گیرند و نیز انتقال segmentهای کم طرفدار به دیسک با هزینه کمتر، می توان قدمهایی را در زمینه بهینه سازی برداشت.

ADO در اوراکل نسخه 12c ارائه شد و بعدا در هر کدام از نسخه ها، قابلیتهای جدیدی به آن اضافه شد که در این مطلب، به قابلیت جدید اوراکل نسخه 21c در این زمینه خواهیم پرداخت.

در این نسخه می توان با کمک ADO برای ایندکسها پالیسیهایی را وضع کرد مثلا می توان بر اساس تاریخ آخرین زمان دستیابی و اصلاح، در سه سطح فشرده سازی(compressing)، بازسازی(rebuilding) و کاهش حجم(shrinking) قوانینی را اعمال نمود.

(بیشتر…)

اوراکل 21c- قابلیت In-Memory Hybrid Scan

زمانی که INMEMORY را در سطح column فعال می کنیم، صرفا پرس و جوهایی که به ستونهای INMEMORY جدول رجوع می کنند، از In-Memory scan بهره خواهند برد و اگر در یک پرس و جو به هیچ یک از ستونهای In-Memory رجوع نشود، اوراکل بصورت ROW-STORE access به این پرس و جو پاسخ خواهد داد.

حالت دیگری هم در اینجا قابل تصور است! اگر پرس و جویی به صورت ترکیبی،به ستونهای INMEMORY و NO INMEMORY رجوع کند، اوراکل چه نوع scanای را انتخاب خواهد کرد؟

تا قبل از نسخه 21c، اوراکل برای این دسته از پرس و جوها، به In-Memory رجوع نمی کرد و با رجوع به buffer cache و بصورت row-store access به این پرس و جوها پاسخ می داد.

اما در اوراکل 21c، قابلیت جدیدی به نام In-Memory Hybrid Scan ارائه شد که بر اساس آن، اگر برای همه ستونهایی که در قسمت where clause دستور استفاده شدند، خصیصه INMEMORY فعال شده باشد(و علاوه بر آن، ستون NO INMEMORY در select list موجود باشد) اوراکل میتواند به صورت ترکیبی از هر دو scan( یعنی row store scan و in-memory scan) استفاده کند. به این شیوه از scan، اصطلاحا In-Memory Hybrid Scan گفته می شود.

(بیشتر…)

قابلیت Sequence Dynamic Cache Resizing در اوراکل 21c و 19.10

تنظیم درست مقدار خصیصه cache برای sequenceها می تواند به لحاظ پرفرومنسی بسیار اثرگذار باشد البته در بعضی از موارد، به دلیل محدودیت application مجاز نیستیم برای cache مقداری بزرگتر از صفر در نظر بگیریم صرف نظر از این استثنا، گاها مشاهده می شود که بعضی از افراد بعد از ایجاد sequenceء، cache را با همان مقدار پیش فرض(عدد 20) رها می کنند در صورتی که این مقدار نمی تواند برای همه sequenceها مناسب باشد و برای آنکه sequenceها بتوانند بهتر پاسخگوی بارکاری باشند باید سایز cache را متناسب با نرخ استفاده sequence مقداردهی کرد.

اوراکل قابلیت جدیدی را ارائه کرده است که می تواند در این زمینه بسیار موثر باشد. ویژگی Sequence Dynamic Cache Resizing در اوراکل 21c ارائه شده(و بعدا در 19.10 هم اضافه شده است) و می تواند به صورت خودکار این مسئله(اندازه cache) را مدیریت کند.

براساس این ویژگی، cache size می تواند بر مبنای نرخ  استفاده sequenceها کاهش و یا افزایش یابد(به صورت خودکار). البته این مقدار هیچ وقت از عددی که به صورت دستی برای خصیصه cache تنظیم شده، کمتر نمی شود. قابلیت Dynamic Cache Resizing به صورت پیش فرض فعال است.

 در ادامه با ارائه یک سناریو، بیشتر با رفتار Sequence Dynamic Cache Resizing آشنا خواهیم شد.

(بیشتر…)

اوراکل 21c- مقایسه explain plan با کمک تابع compare_explain

در اوراکل 21c تابعی با نام compare_explain به dbms_xplan اضافه شد که امکان مقایسه بین explain planهای دو دستور را فراهم می کند. در قسمت انتهایی گزارش(Comparison Results) این تابع، تفاوت دو plan نمایش داده خواهد شد.

مثال زیر را ببینید.

SQL> create table mytbl as select * from dba_objects;

Table created

SQL> create index ind1_object_id on mytbl(object_id);

Index created

SQL> explain plan  set statement_id = ‘Plan1’  for select /*+ full(mytbl) */ * from mytbl where object_id=9;

Explained

SQL> explain plan  set statement_id = ‘Plan2’ for select /*+ index(mytbl) */ * from mytbl where object_id=9;   

Explained

SQL> VARIABLE varvar1 varchar2(9000)

SQL> exec :varvar1 := dbms_xplan.compare_explain(‘Plan1′,’Plan2’);

PL/SQL procedure successfully completed.

(بیشتر…)

REBUILD کردن ایندکسها

یکی از روش های بهبود پرفورمنس در دیتابیس اوراکل استفاده از قابلیت REBUILD کردن ایندکس ها است. REBUILD کردن ایندکس هایی که با روشی مناسب انتخاب می شوند می تواند پرفورمنس دیتابیس را به طور قابل ملاحظه ای بهبود دهد. البته عملیات آنالیز و REBUILD ایندکس زمانبر بوده و سربار ایجاد می کند. در این متن REBUILD ایندکس ها و روش استفاده مناسب از آن توضیح داده می شود.

(بیشتر…)

انواع SCANهای OPTIMIZER

در دیتابیس اوراکل، OPTIMIZER برای هر دستور SQL مسیرهای دسترسی مختلف به جدول ها را تعیین کرده و با یکدیگر مقایسه می کند تا بهینه ترین مسیر برای EXECUTION PLAN را انتخاب کند. این مقایسه بر اساس آمارهای جمع آوری شده از ایندکس ها و جدول های دیتابیس انجام می شود.

برای هر EXECUTION PLAN مسیر دسترسی نهایی به داده ها با استفاده از عمل SCAN مشخص می شود. در این متن انواع مختلف SCANهای OPTIMIZER توضیح داده می شوند.

(بیشتر…)

ویژگی 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 برای یافتن ایندکس هایی که ستون های تکراری دارند معرفی می شود.

(بیشتر…)