همانطور که می دانید، با انتقال بلاک یک جدول از دیسک به حافظه(بافرکش) و دسترسی کاربر به اطلاعات موجود در آن، این بلاک برای مدت زمانی در حافظه باقی خواهد ماند(البته در صورت امکان) تا در صورت نیاز به رجوع مجدد، لزومی به انجام 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 را به خود اختصاص خواهد داد.
Real-Time materialized view
زمان اجرای دو پرس و جوی زیر را با هم مقایسه کنید:
SQL> set timing on
پرس و جوی اول:
SQL> select /*+FULL(TBL1)*/ count(*) from tbl1;
COUNT(*)
———-
176000000
Elapsed: 00:00:02.33
ایجاد SQL Profile به صورت دستی
برای اعمال نظر در مورد execution plan پرس و جویی که اصلاح متن ان امکان پذیر نیست، می توان از sql profile کمک گرفت و از طریق ایجاد ان، هینتهایی را به این پرس و جو اعمال کرد. در ادامه همراه با یک مثال ساده، اثر استفاده از sql profile را بررسی خواهیم کرد.
تسریع انجام عملیات join در هنگام استفاده از dblink
در زمان انجام عملیات join بین دو جدول که یکی در بانک local و دیگری در بانک remote موجود است ، به طور پیش فرض اطلاعات جدول حاضر در بانک remote به بانک local فرستاده خواهد شد و سپس عملیات join انجام می شود.
حال اگر جدول حاضر در بانک remote، حجم بسیار بیشتری از جدول local داشته باشد، انجام عملیات join بسیار کند انجام خواهد شد.
برای این مورد مشخص، در صورتی که عملیات به صورت کامل در بانک remote انجام شوند و در نهایت نتیجه به بانک مبدا برگردد، سرعت انجام عملیات بهتر خواهد شد برای انجام این کار، می توان از هینتی به نام DRIVING_SITE استفاده کرد.
ایجاد چند ایندکس بر روی یک ستون(اوراکل 12c)
با کمک این ویژگی می توان بر روی یک ستون، انواع مختلفی از ایندکسها نظیر Bitmap، B-Tree، Reverse و … را ایجاد نمود که البته از بین این ایندکسها، صرفا یکی از انها می تواند در حالت visible قرار داشته باشد و مابقی ایندکسها، باید در حالت invisible قرار بگیرند.
(بیشتر…)همروندی در اوراکل(Parallel Execution)
در دنیای واقعی کارهای بسیاری وجود دارند که اساسا امکان انجام آنها به صورت سریالی به سختی قابل انجام است و به ناچار نیاز است که این کارها به صورت موازی و همروند اجرا شوند به صورت مثال، فرض کنید نیاز است تا در کشوری همانند چین، سرشماری به صورت دستی انجام بگیرد انجام این عمل توسط یک فرد شاید مضحک و غیرعملی بنظر برسد و ممکن است فرد تا پایان سرشماری، از دنیا برود!!! به همین دلیل نیاز است تا سازمانی برای انجام این کار ایجاد شود و نیروهایی را به استخدام خود در بیاورد تا بتواند با تقسیم کار بین آنها، این عمل را با سرعت بیشتری به انجام برساند.
آمارگیری بعد از درج انبوه در اوراکل 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 ;
Buffer Busy Wait
فرض کنید بلاکی توسط session شماره یک مورد دستیابی قرار گرفته و توسط آن در بافر pin شده است(هر بافر در هر لحظه تنها توسط یک session می تواند pin شود) و در همین حال session دیگری قصد دسترسی به آن بلاک را دارد در این صورت session دوم باید در انتظار بماند به این مدل از انتظار Buffer Busy Wait گفته می شود.
روشهای Join بین جداول(Nested – Hash – Sort)
سه روش برای JOIN بین جداول وجود دارد:
Nested loop – Hash join – Sort merge join
در این متن، به بررسی این سه روش خواهیم پرداخت.
(بیشتر…)