زمانی که یک دستور با چندین شرط join اجرا می شود، عمل join در هر لحظه تنها بین دو جدول آن دستور انجام خواهد شد یعنی به عبارت دیگر، عمل join یک عمل باینری می باشد حال برای تعیین ترتیب join بین جداول، باید حالات مختلفی توسط اوراکل بررسی شود که این کار می تواند وقت زیادی را از سیستم بگیرد برای جلوگیری از این اتلاف وقت، می توان ترتیب پیوند را با استفاده از هینت ORDERED تعیین کرد
enq: TM – contention معمولا به دو دلیل اصلی زیر رخ می دهد(البته دلایل دیگر هم دارد):
1. عدم ایندکس گذاری بر روی کلید خارجی در جدول child
2. direct load insert
|
User2 |
User1 |
|
|
update usef_wait set a=25 where a=18 ; |
|
update usef_wait set a=35 where a=19 ; |
|
|
|
|
|
update usef_wait set a=26 where a=18 ; |
|
این نوع wait معمولا زمانی که چند نفر بخواهند به صورت همزمان یک رکورد را تغییر دهند، اتفاق می افتد. وبرای کم رنگ کردن آن باید برنامه را طوری تغییر داد تا کاربر زودتر مجبور به rollback یا commit شود.
ابن wait در مود Share(mode=4 و ستون p1 ویوی v$active_session_history برابر با 1415053316 می باشد) و یا مود Exclusive(mode=6 و p1=1415053318) ممکن است اتفاق بیفتد.
وقتی که اوراکل دستوری را اجرا می کند، سعی دارد تا فرم قابل اجرای دستور اجرا شده(که plan آن مشخص شده) را در library cache نگهدارد تا در صورت امکان از آن استفاده مجدد کند حال اگر این فرم پارس شده برای دستور دیگری مورد استفاده قرار بگیرد می گویند یک soft parse انجام شده است و در صورتی که اوراکل مجبور شود یک فرم جدید قابل اجرا(که در library cache موجود نیست) برای دستور وارده بسازد، hard parse صورت گرفته است.
معمولا بعد از مدتی کار بر روی جداول و یا در پی اتفاقاتی خاص، ممکن است که نیاز شود تا جدولی خاص از یک tablespace و یا کل objectهای tablespace را دوباره سازماندهی کنیم tablespace reorganization معمولا به عنوان یک امر خطیر در حیطه وظایف dba محسوب می شود. آنچه که در این قسمت قصد داریم در مورد آن مطالبی را ارائه کنیم، دلایل نیاز به reorganization و چگونگی انجام آن می باشد.
در هنگام اجرای پرس و جو، بعد از مراحل پارس دستور، بهینه کننده با توجه به آمارهایی که از objectها در اختیار دارد،باید محاسباتی را انجام دهد و در صورت امکان، فرم دستور را تغییر دهد و در نهایت هم برای آن دستور، یک نقشه اجرایی بسازد. نقشه اجرایی مشخص می کند که برای اجرای دستور، باید به چه اشیاهایی رجوع شود همچنین نحوه دستیابی به اطلاعات آن اشیاها را نیز مشخص می کند.
در این قسمت نقش cursorها را در عمل پارس یک دستور sql، در سه مرحله توضیح خواهیم داد:
اول) در ابتدای کار، با استفاده از اطلاعات pga مشخصاتclose cursorها بررسی می شود تا اگر از بین انها موردی یافت شد که نیاز این دستور را برای دسترسی به فرم پارس شده اش برآورده می کند، انتخاب کند تا دیگر نیازی به مرحله soft parse نداشته باشد. حداکثر تعداد close cursorهابه ازای هر session با استفاده از پارامتر SESSION_CACHED_CURSORS مشخص می شود.
