کاراکتر Sqlprefix در sqlplus

فرض کنید در حال نوشتن پرس و جویی طولانی در محیط sqlplus هستیم، در همین حال اسامی فیلدهای جداول را به صورت دقیق بخاطر نداریم، در این صورت ممکن از ادامه نوشتن این پرس و جو منصرف شویم تا اسامی ستونهای جدول را مورد بازبینی قرار دهیم(describe)!!!

روش بهتری هم برای یافتن اسامی ستونهای جدول در حین اجرای این پرس و جو وجود دارد که ان هم استفاده از sqlprefix می باشد. منظور از Sqlprefix کاراکتری است که اجازه اجرای دستوری را در حین نوشتن پرس و جو ممکن می سازد.

(بیشتر…)

افزودن کامنت در زمان تغییر مقدار یک پارامتر

در زمان تغییر مقدار یک پارامتر، می توان در انتهای دستور(alter system)، توضیحی را اضافه نمود. برای مثال، در دستور زیر، مقدار پارامتر open_cursors را به عدد 800 تغییر داده و توضیح می دهیم که مقدار قبلی ان چه عددی بوده است:

SQL> alter system set open_cursors=800 comment=’old value is 300′;
System altered.

برای مشاهده این توضیحات، می توان به ویوی v$parameter رجوع کرد:

select name,value, update_comment from v$parameter where name =’open_cursors’;

NAME VALUE UPDATE_COMMENT
——————— ———— ———————
open_cursors 800 old value is 300

متغیر TWO_TASK

برای اتصال از راه دور به یک بانک اطلاعاتی در محیط sqlplus، معمولا از فرمت زیر استفاده می شود:

[oracle@ol7 ~]$ sqlplus usef/abc@pdb1

با این توضیح که منظور از pdb1 همان net service nameای است که در فایل tnsnames.ora تعریف شده است:

pdb1=
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = ol7)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = pdb1)))

در این زمینه متغیری به نام TWO_TASK هم وجود دارد که طریق دیگری را برای اتصال از راه دور ممکن می سازد به این صورت که با تنظیم این متغیر به نام یک net service name دلخواه، دیگر از متغیر ORACLE_SID که سبب اتصال به instance محلی(local) می شد، استفاده نخواهد شد و به عبارتی دیگر، این متغیر در صورت استفاده، بر متغیر ORACLE_SID ارجحیت دارد.

مثال زیر را ببینید:

[oracle@ol7 ~]$ export TWO_TASK=pdb1
[oracle@ol7 ~]$ echo $ORACLE_SID
db

در چنین شرایطی، استفاده از دستور sqlplus سبب اتصال به محیط pdb1 خواهد شد البته به شرط وارد کردن نام کاربری و رمز صحیح:

[oracle@ol7 ~]$ sqlplus usef/abc
Connected to:
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 – 64bit Production
SQL>

همچنین دستور زیر نشان می دهد که این اتصال به صورت LOCAL برقرار نشده است:

[root@ol7 ~]# ps -eaf |grep LOCAL
oracle 14499 1 0 12:23 ? 00:00:00 oracledb (LOCAL=NO)

یکی از موارد کاربرد این متغیر به هنگام استفاده از pluggable database و اتصال به یک pdb مشخص برمی گردد. همچنین در صورت استفاده از سیستم عامل ویندوز، باید به جای تنظیم متغیر TWO_TASK از متغیر LOCAL استفاده شود.

مشاهده و kill کردن کاربران متصل به سرور

پرسش: چه افرادی به سرور متصل هستند؟ چگونه می توان از ادامه اتصال این افراد جلوگیری کرد؟

پاسخ: برای نمایش ip و pid افرادی که به سرور متصل هستند، می توان از دستور who کمک گرفت:

]# who -u
root :0 2018-03-16 12:02 ? 12096 (:0)
root pts/0 2018-03-16 12:18 01:15 13658 (192.168.1.1)
root pts/1 2018-03-16 12:19 00:06 13779 (192.168.1.1)
root pts/2 2018-03-16 13:41 . 19692 (192.168.1.1)

همچنین برای پایان دادن به اتصال هر کدام از این sessionها می توان از دستور kill به همراه سیگنال 9 استفاده کرد:

]# kill -9 13658 13779 19692

پ.ن: عدد قبل از پرانتز در خروجی دستور who، عدد pid را نشان می دهد.

ایجاد و مدیریت job با کمک بسته DBMS_SCHEDULER

برای انجام زمانبندی در سطح دیتابیس، دو بسته با نامهای dbms_job و dbms_scheduler موجود می باشند که بسته dbms_job از نسخه های قدیمی اوراکل ارائه شده و در نسخه های جدید هم کماکان مورد استفاده قرار می گیرد و بسته dbms_scheduler که در نسخه جدیدتر اوراکل عرضه شد، توانست تا حدود زیادی جایگزین مناسبی برای بستهdbms_job باشد.

در این متن، قصد داریم به بسته dbms_scheduler بپردازیم.

(بیشتر…)

تفاوت مجوز سیستمی SELECT ANY DICTIONARY و نقش SELECT_CATALOG_ROLE

پرسش: چه تفاوتی بین مجوز سیستمی SELECT ANY DICTIONARY و نقش SELECT_CATALOG_ROLE وجود دارد؟

پاسخ: با دو مثال زیر، تفاوت بین این دو مجوز را نشان خواهیم داد.

مثال 1: کاربر user_a با داشتن مجوز select any dictionary می تواند به ویوها و جداول data dictionary دسترسی داشته باشد:

SQL> create user user_a identified by a;

User created.

SQL> grant select any dictionary,connect to user_a;

Grant succeeded.

SQL> conn user_a/a@pdb1

—views
SQL> select count(*) from v$datafile;
COUNT(*)
————
4

—tables
SQL> select count(*) from sys.file$;
COUNT(*)
————
4
مثال 2: کاربر user_b با داشتن نقش SELECT_CATALOG_ROLE این قابلیت را ندارد که به جداول data dictionary دسترسی داشته باشد و صرفا خواهد توانست ویوهای data dictionary را ببیند.

SQL> create user user_b identified by a;

User created.

SQL> grant SELECT_CATALOG_ROLE ,connect to user_b;

Grant succeeded.

SQL> conn user_b/a@pdb1

—views
SQL> select count(*) from v$datafile;
COUNT(*)
————
4

—tables
SQL> select count(*) from sys.file$;

ORA-00942: table or view does not exist

تفاوتهای دیگری هم بین این دو مجوز وجود دارد که در اینجا صرفا به یکی از انها اشاره شد.

پ.ن: از اوراکل 12c، دسترسی به بعضی از جداول data dictionary حتی با داشتن مجوز select any dictionary هم ممکن نمی باشد. لیست بعضی از این جداول را در زیر می بینید:

USER$, ENC$ , DEFAULT_PWD$, LINK$, USER_HISTORY$, CDB_LOCAL_ADMINAUTH$, XS$VERIFIERS

تسریع انجام عملیات join در هنگام استفاده از dblink

در زمان انجام عملیات join بین دو جدول که یکی در بانک local و دیگری در بانک remote موجود است ، به طور پیش فرض اطلاعات جدول حاضر در بانک remote به بانک local فرستاده خواهد شد و سپس عملیات join انجام می شود.
حال اگر جدول حاضر در بانک remote، حجم بسیار بیشتری از جدول local داشته باشد، انجام عملیات join بسیار کند انجام خواهد شد.
برای این مورد مشخص، در صورتی که عملیات به صورت کامل در بانک remote انجام شوند و در نهایت نتیجه به بانک مبدا برگردد، سرعت انجام عملیات بهتر خواهد شد برای انجام این کار، می توان از هینتی به نام DRIVING_SITE استفاده کرد.

(بیشتر…)