گاهی اوقات در گزارش گیری از دیتابیس باید اطلاعات مورد نیاز از جدول های مختلف در کنار هم نمایش یابند، بنابراین در این موارد عملیات JOIN بین جداول انجام می شود.
در این متن روش های مختلف JOIN که با استاندارد SQL:1999 سازگار می باشند توضیح داده می شوند.
……….آموزش، مشاوره و پشتیبانی……….
گاهی اوقات در گزارش گیری از دیتابیس باید اطلاعات مورد نیاز از جدول های مختلف در کنار هم نمایش یابند، بنابراین در این موارد عملیات JOIN بین جداول انجام می شود.
در این متن روش های مختلف JOIN که با استاندارد SQL:1999 سازگار می باشند توضیح داده می شوند.
ابزار AutoUpgrade ارتقا دیتابیس اوراکل به نسخه بالاتر را با مداخله کمتر DBA امکان پذیر می کند همچنین این ابزار، قابلیت ارتقا همزمان چندین دیتابیس را فراهم خواهد کرد(صرفا از طریق یک فایل config).
در این متن قصد داریم با استفاده از این ابزار، دیتابیسی را از نسخه 18c به نسخه 19c ارتقا دهیم.
توابعی که در این متن توضیح داده می شوند، داده های دریافتی از نوع کاراکتری، عددی یا تاریخ را به نوع دیگر تبدیل می کنند. در ادامه توابعی که مربوط به مقادیر NULL می باشند معرفی می گردند. همچنین روش استفاده از عبارات شرطی با منطق IF THEN-ELSE توضیح داده می شود.
زمانی که user1 مجوز اجرای پروسیجرش را به user2 اهدا می کند، user2 علاوه بر امکان اجرای این پروسیجر، می تواند محتویات پروسیجر را هم مشاهده کند:
SQL> show user
User is “user1”
SQL> create user user2 identified by u;
User created
SQL> grant create session to user2;
Grant succeeded
SQL> grant execute on user1.myproc1 to user2;
Grant succeeded
SQL> conn user2/u
Connected.
SQL> exec user1.myproc1;
PL/SQL procedure successfully completed.
زمانی که DBMS_SCHEDULER در اوراکل 10g ارائه شد، تنها سه نوع جاب PLSQL_BLOCK، STORED_PROCEDURE و EXECUTABLE را پشتیانی می کرد در اوراکل 11g هم تغییر قابل توجهی در این مسئله رخ نداد تا اینکه در نسخه 12c اوراکل job_typeهای جدیدی را به این مجموعه اضافه کرد تا تنظیم بعضی از جابها به شکل ساده تر و با وابستگی کمتری به محیط سیستم عامل قابل انجام باشد:
SHELL_SCRIPT – SQL_SCRIPT – BACKUP_SCRIPT
در این متن با هر کدام از این نوع جابها آشنا خواهیم شد.
همانطور که می دانید در اوراکل 11g، برای هرگونه استفاده از بسته DBMS_REDEFINITION باید مراحلی را طی نمود و انجام عملیات در یک گام امکان پذیر نمی باشد.
در اوراکل نسخه 12c، پروسیجر جدیدی به نام REDEF_TABLE به بسته DBMS_REDEFINITION اضافه شده است که از طریق ان می توان عملیاتی نظیر جابجایی انلاین و تغییر tablespace جداول و همچنین تغییر نوع فشرده سازی جداول و ایندکسها را صرفا در یک مرحله انجام داد.
می دانیم که shared pool فرم پارس شده دستورات sql و pl/sql را در صورت دارا بودن فضای کافی در خود نگهداری می کند و نسخه قابل اجرای دستورات، در این قسمت از حافظه باقی خواهند ماند تا در صورت اجرای مکرر یک دستور، از کامپایل مجدد آن و یا به بیانی دقیق تر، از انجام عملیات hard pars جلوگیری شود.
فرض کنید به دلایلی چون عدم استفاده از bind variable در قسمتی از برنامه، فضای خالی ای در shared pool باقی نمانده است در این صورت، اوراکل فرمهای پارس شده را بر اساس الگوریتم LRU از حافظه خارج خواهد کرد این مسئله ممکن است سبب age out شدن objectهای سیستمی و یا applicationای شود که به کررات مورد دستیابی قرار می گیرند.
با در نظر داشتن این مسئله، قصد داریم به این سوال پاسخ دهیم که چگونه می توان این objectها را در shared pool سنجاق کرد تا الگوریتم LRU نتواند آنها را برای خروج از shared pool انتخاب کند.
فرض کنید جدول mytbl را با دستور زیر ایجاد کرده ایم:
SQL> create table mytbl(id number,name varchar2(9),age number);
Table created
بعد از مدتی تصمیم گرفته ایم تا به این جدول، ستونی را با عنوان last_name اضافه کنیم:
SQL> ALTER TABLE mytbl ADD (last_name varchar2(9));
Table altered
ستون last_name به لحاظ ترتیب قرار گیری بصورت پیش فرض، به عنوان آخرین ستون این جدول در انتهای لیست ستونها قرار می گیرد:
SQL> desc mytbl;
Name Type Nullable
——— ———– ——–
ID NUMBER Y
NAME VARCHAR2(9) Y
AGE NUMBER Y
LAST_NAME VARCHAR2(9) Y
قصد داریم ستونهای AGE و LAST_NAME را به لحاظ ترتیب منطقی قرارگیری در جدول با هم جابجا کنیم، برای این کار می توانیم از دستور ALTER TABLE .. MODIFY(COLUMN_NAME INVISIBLE) که در اوراکل 12c ارائه شد، استفاده کنیم. در قسمت زیر، نحوه انجام این کار را مشاهده می کنید:
SQL> ALTER TABLE mytbl MODIFY (LAST_NAME INVISIBLE,AGE INVISIBLE);
Table altered
SQL> ALTER TABLE mytbl MODIFY (LAST_NAME VISIBLE,AGE VISIBLE);
Table altered
SQL> desc mytbl;
Name Type Nullable Default Comments
——— ———– ——– ——- ——–
ID NUMBER Y
NAME VARCHAR2(9) Y
LAST_NAME VARCHAR2(9) Y
AGE NUMBER Y
در زمان اجرای یک پرس و جوی زمانبر، ممکن است تغییراتی در جداول مرجع این پرس وجو اعمال شود در این صورت، سوالی مطرح می شود که آیا این پرس و جوی در حال اجرا، تغییرات جدید را هم در محاسباتش اعمال می کند یا خیر؟
پاسخ این سوال به نوع جداول و ویوهای مرجع پرس و جو بستگی دارد برای مثال، در زمان رجوع به dynamic performance viewها ممکن است تغییرات ایجاد شده در زمان اجرای پرس و جو لحاظ شود و نهایتا خروجی آن پرس و جو را تغییر دهد.
اما در زمان رجوع به جداولی که اطلاعات کاربران در آن ذخیره می شود، اوراکل با لحاظ کردن scn زمان اجرای پرس و جو(زمانی که پرس و جو شروع به اجرا می کند)، تغییرات جدید را در آن اعمال نخواهد کرد.
در صورتی که تغییرات جدید در محاسبات اعمال نشوند و اوراکل صرفا با کمک تصویر ثابتی که از اطلاعات جدول دارد، پرس و جو را اجرا کند، اصطلاحا مفهوم read consistency توسط اوراکل رعایت شده است.