……….آموزش، مشاوره و پشتیبانی……….
در مبحث “آشنایی با Clustering Factor در اوراکل” مطالبی را در مورد CLUSTERING_FACTOR ارائه دادیم در این مطلب قصد داریم با چند مثال عملی را در این زمینه ارائه کرده و در پایان، هزینه استفاده از ایندکس را برای هر دو حالت با هم مقایسه خواهیم کرد.
مثال 1(CLUSTERING_FACTOR بد): قصد داریم با اجرای پرس و جوی زیر، اطلاعاتی از جدول badcftable را در خروجی نمایش دهیم:
SQL> Select * from badcftable where code=2;
با ارائه قابلیت Interval partitioning در اوراکل نسخه 11g، نیاز به اضافه کردن دستی پارتیشن، در هنگام درج اطلاعات خارج از محدوده از بین رفته است. در این متن به صورت خلاصه نکاتی را در مورد Interval Partitioning مرور خواهیم کرد.
همانطور که می دانید، متغیر محیطی ORACLE_SID، نام instance اوراکل را مشخص می کند:
[oracle@Primary ~]$ echo $ORACLE_SID
sid
SQL> select INSTANCE_NAME from v$instance;
INSTANCE_NAME
—————-
sid
در این متن نکاتی را در مورد حداکثر طول کاراکتر ORACLE_SID و نام instance ارائه خواهیم کرد.
در زمان کار با ابزار netmgr، امکان استفاده از sid با طول بیشتر از 8 کاراکتر وجود ندارد و در صورت تنظیم با خطای زیر مواجه خواهیم شد:
همانطور که می دانید، user به منظور اتصال و مدیریت دیتابیس ایجاد می شود و schema هم مجموعه ای از objectها نظیر جدول، ایندکس، ویو و … تحت یک نام می باشد در این مطلب تفاوتهای user و schema را در دو دیتابیس پستگرس و اوراکل تشریح خواهیم کرد.
در دیتابیس اوراکل، با ایجاد user، به صورت خودکار schema هم ایجاد خواهد شد و به عبارتی دقیق تر، با ایجاد اولین object برای یک user، به آن user، اسکیما(schema) هم گفته می شود و دستور مجزایی برای ساخت schema وجود ندارد.
البته دستور CREATE SCHEMA که در اوراکل وجود دارد عملا schemaای را ایجاد نخواهد کرد و صرفا امکان ساخت چندین شی را از طریق یک دستور فراهم می سازد برای مثال با توجه به آنکه کاربر usef2 در دیتابیس موجود نیست، دستور زیر با خطا متوقف خواهد شد:
SQL> create schema authorization usef2
create table t1 (c1 number)
create table t2 (c2 number);
ORA-02421: missing or invalid schema authorization identifier
همانطور که در مطلب “Direct path vs Conventional insert“ بیان شد، زمانی که با اجرای دستور DMLای، تغییری را در جدولی ایجاد می کنیم، قبل از اجرای دستور commit، اوراکل بلاکهای جدول را به حافظه منتقل کرده و سپس اطلاعات جدید تایید نشده را در این بلاکها درج/حذف/اصلاح می کند(در حالت Conventional) همچنین شکل قبلی رکوردها در undo segment و یا rollback segment ثبت خواهد شد.
زمانی که دستور drop column را اجرا می کنیم، اوراکل باید تمامی بلاکهای جدول را به حافظه منتقل کرده و اطلاعات مربوط به ستون را از همه رکوردهای حاضر در بلاک حذف کند.
در کنار عملیات I/O و پردازش رکورد، جدول هم به صورت exclusive قفل خواهد شد و مضاف بر آن، حدف ستون منجر به ایجاد redo و undo هم می شود. در نتیجه حذف ستون از یک جدول حجیم می تواند کار بسیار پرهزینه و زمانبری باشد.مثال زیر را ببینید:
در این قسمت EXCEPTION و روش استفاده از EXCEPTION-HANDLER را توضیح می دهیم. منظور از EXCEPTION رخداد خطا در زمان اجرای برنامه است. برای مثال به دنبال اطلاعاتی هستیم که در دیتابیس وجود ندارند یا یک ورودی اشتباه به زیربرنامه ارسال می کنیم.
زبان PL/SQL با استفاده از بلاک EXCEPTION-HANDLER به برنامه نویس کمک می کند تا نوع EXCEPTION برنامه را متوجه شود و در زمان رخداد آنها دستورات مناسب را اجرا کند.
فرض کنید پرس و جوی زیر یکی از پرس و جوهای پراستفاده برنامه می باشد که به دلیل عدم دسترسی به سورس کد برنامه امکان تغییر متن آن وجود ندارد:
SQL> select /*+INDEX(tbl1,IND_CODE)*/ count(*) from tbl1 where code=2 ;
COUNT(*)
———-
51199980
Elapsed: 00:00:05.23
همانطور که می بینید، این پرس و جو حدودا در زمان 4 ثانیه اجرا شده است با برداشتن HINTای که در این پرس و جو موجود است، آن را مجددا اجرا می کنیم:
SQL> select count(*) from tbl1 where code=2 ;
COUNT(*)
———-
51199980
Elapsed: 00:00:01.60
مشاهده می کنید که زمان اجرای پرس و جو با برداشتن HINT از 5 ثانیه به 1 ثانیه کاهش پیدا کرده است قصد داریم با هر بار اجرای پرس و جوی اول، دیتابیس به صورت خودکار پرس و جوی دوم(که فاقد HINT است) را اجرا کند به عبارتی دیگر، دیتابیس در پس زمینه query rewrite را انجام دهد.
همانطور که می دانید، زمانی که دیتابیس در حالت read only قرار دارد امکان ثبت اطلاعات در جداول دیتادیکشنری از بین خواهد رفت این قاعده برای جداول مربوط به auditing(نظیر aud$unified) هم صادق است از اینرو نمی توان عملیات انجام شده توسط کاربران را در دیتابیس ذخیره کرد.
در این شرایط، در صورت استفاده از قابلیت Unified auditing، اوراکل auditهای انجام شده را در محیط سیستم عامل ثبت خواهد کرد.
عملیات انجام شده توسط کاربران در قالب فایلهای باینری، با پسوند bin. و در مسیر ORACLE_BASE/audit/$ORACLE_SID$ ثبت خواهند شد و امکان مشاهده محتویات این فایلهای باینری از طریق ویوی unified_audit_trail فراهم می شود.
ممکن است در شرایطی بخواهید صرفا فرم پارس شده یکی از دستورات را از حافظه خارج کنید، در این صورت می توانید از بسته DBMS_SHARED_POOL.PURGE استفاده کنید.
SQL>select ADDRESS, HASH_VALUE,sql_text from V$SQLAREA where SQL_TEXT like ‘%delete mytbl where %’ and SQL_TEXT not like ‘%v$sql%’;
SQL> exec sys.DBMS_SHARED_POOL.PURGE ‘00000000774B91E0,3503309987′,’C’);
PL/SQL procedure successfully completed
SQL>select ADDRESS, HASH_VALUE,sql_text from V$SQLAREA where SQL_TEXT like ‘%delete mytbl where %’ and SQL_TEXT not like ‘%v$sql%’;
no rows selected
توجه: پارامتر دوم در پروسیجر Purge(کارکتر C)، به نوع object اشاره دارد که علامت اختصاری objectها را در قسمت زیر می بینید:
–P package/procedure/function –JS java source
–Q sequence –JC java class
–R trigger –JR java resource
–T type –JD java shared data