Automatic Big table caching

همانطور که می دانید، با انتقال بلاک یک جدول از دیسک به حافظه(بافرکش) و دسترسی کاربر به اطلاعات موجود در آن، این بلاک برای مدت زمانی در حافظه باقی خواهد ماند(البته در صورت امکان) تا در صورت نیاز به رجوع مجدد، لزومی به انجام physical read دوباره برای دستیابی به این اطلاعات نباشد. مکرر در مستندات اوراکلی خوانده ایم که مدیریت این caching در سطح بلاک(نه در سطح object) و با کمک الگوریتم (LRU(least recently used انجام می شود.

(بیشتر…)

ایجاد SQL Profile به صورت دستی

برای اعمال نظر در مورد execution plan پرس و جویی که اصلاح متن ان امکان پذیر نیست، می توان از sql profile کمک گرفت و از طریق ایجاد ان، هینتهایی را به این پرس و جو اعمال کرد. در ادامه همراه با یک مثال ساده، اثر استفاده از sql profile را بررسی خواهیم کرد.

(بیشتر…)

بروزرسانی Out of Place – ویژگی جدید MATERIALIZED VIEW در اوراکل 12c

تا قبل از اوراکل نسخه 12c، معمولا بروزرسانی به طور مستقیم در جدول مربوط به MV اتفاق می افتاد(ابتدا اطلاعات حذف شده و سپس در همان session، اطلاعات جدید درج می شوند و نهایتا commit رخ خواهد داد) به بیانی دیگر، در این نسخه ها،  بروزرسانی تنها به صورت in place (در جا) اتفاق می افتد که مرحله delete آن ممکن است متناسب با حجم جدول، زمان زیادی را صرف کند.

در نسخه 12c این امکان بوجود امد تا بدون هرگونه تغییر جدول اصلی مربوط به MATERIALIZED VIEW، بروزرسانی انجام شود که این شکل از بروزرسانی، Out of Place نام دارد.

(بیشتر…)

آمارگیری بعد از درج انبوه در اوراکل 12c

در نسخه 11g، با اجرای دستور create table as، آماری از جدول ایجاد شده، ثبت نمی شود:

create table us_tbl1 as select * from dba_source;

SELECT table_name,num_rows FROM   dba_tables WHERE  table_name = ‘US_TBL1’;

حال اگر همین دستور در نسخه 12c اجرا شود، نتیجه چیزی دیگری خواهد بود(البته استثناهایی هم در این زمینه وجود دارد):

create table us_tbl1 as select * from dba_source;

SELECT table_name,num_rows FROM   dba_tables WHERE  table_name = ‘US_TBL1’;

همچنین می توان با هینت NO_GATHER_OPTIMIZER_STATISTICS، از این قابلیت جدید، صرف نظر کرد:

create table us_tbl1 as select /*+ NO_GATHER_OPTIMIZER_STATISTICS */ * from dba_source ;