ADO و مدیریت in-memory

همانطور که می دانید، objectهای که خصیصه inmemory برای انها تنظیم شده متناسب با اولویتی که دارند، در in-memory قرار خواهند گرفت برای مثال، اگر خصیصه inmemory برای جدولی با اولویت critical تعریف شده باشد، این جدول صرف نظر از تعداد دفعات رجوع، در زمان استارت دیتابیس در in memory قرار خواهد گرفت.

در این متن به این سوال پاسخ خواهیم داد که چگونه می توان از قرار گرفتن جدول و یا به صورت کلی objectای که مدت زمان زیادی از آخرین زمان دستیابی و یا اصلاح آن گذشته، به in-memory جلوگیری کرد(آن هم به صورت خودکار)؟

این کار در نسخه 12cR2 با کمک ویژگی (Automatic Data Optimization(ADO قابل انجام است همانطور که می دانید ADO که در نسخه 12cR1 ارائه شد، امکان جابجایی و فشرده سازی objectها را متناسب با آمارهای heat map فراهم می سازد. به عنوان بهبودی جدید در نسخه 12cR2، امکان ایجاد ADO policy برای خصیصه inmemory جداول هم امکان پذیر می باشد(در سطح segment).

(بیشتر…)

بررسی پارامترهای رسمی و مخفی مربوط به PGA

همانطور که می دانید PGA متشکل از قسمتهای مختلفی می باشد که میزان استفاده هر پروسس از هر کدام از این قسمتها را می توان با کمک پارامترهای نظیر sort_area_size، hash_area_size، bitmap_merge_area_size و… کنترل کرد.

با این حال از اوراکل 9i، پارامتر دیگری به نام PGA_AGGREGATE_TARGET اضافه شد که با مقداردهی آن، اندازه هر یک از قسمتهای PGA توسط خود اوراکل مدیریت می شود.

اوراکل تلاش می کند مجموع فضای PGA تخصیص داده شده(pga1+pga2+pga3+…) به پروسسها را به مقدار در نظر گرفته شده برای پارامتر PGA_AGGREGATE_TARGET محدود کند اما در مواقعی، به خصوص در زمان بالا رفتن بارکاری سیستم و یا پایین بودن مقدار پارامتر PGA_AGGREGATE_TARGET، ممکن است مجموع فضای PGA تخصیص داده شده، از مقدار تنظیم شده برای این پارامتر بیشتر شود.

از این رو، مقدار تعیین شده برای پارامتر PGA_AGGREGATE_TARGET صرفا به عنوان یک soft limit در نظر گرفته خواهد شد و حتی در شرایطی ممکن است فضای PGA تخصیص داده شده به یک پروسس، از مقدار تنظیم شده برای این پارامتر تجاوز کند!(مطلب “نگاهی به استثنائاتی در مورد پارامترهای PGA” را مطالعه کنید)

(بیشتر…)

اوراکل 12c-بهبودهایی در زمینه جمع آوری آمار Global Temporary Table

تا قبل از اوراکل 12c، رفتار اوراکل در زمان جمع آوری آمار برای جداول از نوع (global temporary table(GTT تفاوتی با جداول معمولی نداشت و این مسئله می توانست در مواردی چالش برانگیز باشد.

در اوراکل 12c بهبودهایی در این زمینه حاصل شد که در ادامه دو مورد از این بهبودها را مشاهده می کنید.

(بیشتر…)

rollback کردن عملیات REDEFINITION(اوراکل 12c)

زمانی را تصور کنید که ساختار جدول حجیمی را با کمک بسته DBMS_REDEFINITION تغییر داده ایم. بعد از اتمام عملیات redefinition، به این نتیجه رسیده ایم که تغییر انجام شده، سبب کندی در عملیاتی که بر روی این جدول انجام می شوند، شده است. قصد داریم جدول را به ساختار پارتشن نشده قبل برگردانیم، راهکار چیست؟

یکی از بهبودهایی که در نسخه 12c به بسته DBMS_REDEFINITION اضافه شد، قابلیت rollback کردن عملیات انجام شده می باشد این کار به کمک پارامتر enable_rollback از بسته DBMS_REDEFINITION قابل انجام است.

(بیشتر…)

انجام عملیات redefinition در یک مرحله با کمک پروسیجر REDEF_TABLE (اوراکل 12c)

همانطور که می دانید در اوراکل 11g، برای هرگونه استفاده از بسته DBMS_REDEFINITION باید مراحلی را طی نمود و انجام عملیات در یک گام امکان پذیر نمی باشد.

در اوراکل نسخه 12c، پروسیجر جدیدی به نام REDEF_TABLE به بسته DBMS_REDEFINITION اضافه شده است که از طریق ان می توان عملیاتی نظیر جابجایی انلاین و تغییر tablespace جداول و همچنین تغییر نوع فشرده سازی جداول و ایندکسها را صرفا در یک مرحله انجام داد.

(بیشتر…)

پارامتر dml_lock_timeout در بسته DBMS_REDEFINITION(اوراکل 12c)

همانطور که می دانید، در زمان  اجرای پروسیجر FINISH_REDEF_TABLE، باید برای مدت زمان کوتاهی جدول به صورت exclusive قفل شود تا اجرای پروسیجر با موفقیت خاتمه یابد در غیر این صورت، اجرای این پروسیجر تا اتمام تراکنشهایی دیگری که بر روی جدول در حال اجرا هستند، متوقف و در حالت انتطار باقی خواهد ماند:

(بیشتر…)

مشاهده پیشرفت عملیات REDEFINITION با کمک ویوی V$ONLINE_REDEF

در اوراکل نسخه 12c، با کمک ویوی V$ONLINE_REDEF می توان روند پیشرفت عملیات REDEFINITION را به صورت انلاین دنبال کرد:

SQL> exec DBMS_REDEFINITION.REDEF_TABLE(‘USEF’,’MYTBL’,’ROW STORE COMPRESS ADVANCED’);

SQL> select ORIGINAL_TABLE_NAME,INTERIM_TABLE_NAME,OPERATION,SUBOPERATION,PROGRESS from V$ONLINE_REDEF ;

اوراکل 12cR2 – پارتیشن بندی external table

می دانیم که اطلاعات جداول از نوع external، در خارج از محیط دیتابیس و در قالب فایلی در سیستم عامل ذخیره می شوند. بسیار روشن است که اگر حجم فایل حاوی دیتا از حد مشخصی بیشتر شود، عملیات جستجو با سرعت کندتری انجام خواهد شد.

اوراکل در نسخه 12c قابلیت پارتیشن بندی external table را ارائه کرده است که میتواند در سرعت دستیابی به اطلاعات این نوع از جداول بهبودی را ایجاد کند. در ادامه این متن، به بررسی این قابلیت خواهیم پرداخت.

(بیشتر…)

معتبر ماندن وضعیت ایندکسهای Global در حین انجام عملیات Drop و Truncate پارتیشنها

می دانیم که در اوراکل 11g با حذف و یا truncate کردن پارتیشنهای یک جدول، ایندکسهای GLOBAL مربوط به آن جدول هم در وضعیت unusable قرار می گیرند مگر انکه در حین اجرای دستور alter table .. drop partition از عبارت  update indexes استفاده شود در این صورت، ایندکسهای از نوع global این جدول در صورت وجود، بصورت فوری بازسازی خواهند شد و دستور تا بازسازی کامل این ایندکسها، به کارش خاتمه نخواهد داد.

(بیشتر…)

اوراکل 12c – بهبودی در جمع آوری آمار به صورت Incremental برای جداول پارتیشن شده

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

در این صورت با هر بار اجرای بسته dbms_stat، از همه پارتیشنهای این جدول، مجددا امار جمع اوری خواهد شد حتی پارتیشنهایی که اطلاعات ان بروزرسانی نشده است.

(بیشتر…)