کاهش زمان ساخت Primary/Foreign Key

استفاده از عبارت parallel در زمان ساخت primary key منجر به انجام عملیات به صورت همروند نخواهد شد. دستور زیر را مشاهده کنید:

SQL> alter table all_table add constraint pk_1 primary key (id) parallel 10;
Table altered.
Elapsed: 00:00:12.36

با فعال کردن trace خواهیم دید که اوراکل برای ساخت ایندکس متناظر با این PK، از عبارت noparallel استفاده کرده و عبارت parallel تاثیر مثبتی در زمان ایجاد این Primary Key نداشته است:

PARSING IN CURSOR #140396268419760 len=72 dep=1 uid=109 oct=9 lid=109 tim=29571676036680 hv=2994446983 ad='b9930010' sqlid='c1ddax6t7r8n7'
CREATE UNIQUE INDEX "USEF"."PK_1" on "USEF"."ALL_TABLE"("ID") NOPARALLEL

بنابرین زمان اجرای دستور فوق با دستور زیر برابر خواهد بود و اجرای هر دو دستور به 13 ثانیه زمان نیاز دارد:

SQL> alter table all_table add constraint pk_1 primary key (id) noparallel;
Table altered.
Elapsed: 00:00:12.95

(بیشتر…)

اهدای مجوز به فانکشن، پکیج و پروسیجر

زمانی که یک program unit(فانکشن، پکیج، پروسیجر) به صورت invoker right ایجاد می شود، کاربر صدا زننده برنامه، با مجوز خودش این برنامه را اجرا خواهد کرد بنابرین اگر جدولی در برنامه موجود باشد که این کاربر به آن دسترسی نداشته باشد، کارش با خطا متوقف خواهد شد(بررسی Invoker’s Rights و Definer’s Rights). برای مثال، تابع زیر را در نظر بگیرید:

SQL> CREATE FUNCTION sys.Tabe(name_malek in varchar2,name_jadval in varchar2)
   RETURN VARCHAR2
   AUTHID CURRENT_USER
AS
V_bytes varchar2(1000);
BEGIN
  select bytes into V_bytes from dba_segments where owner=name_malek and segment_name=name_jadval;
   RETURN V_bytes;
END;
/
Function created.

این تابع که با یوزر sys ایجاد شده، قرار است نام segment را دریافت و حجم آن را بر اساس بایت برگرداند. عبارت AUTHID CURRENT_USER بیانگر invoker right است.

کاربری با نام vahid را با حداقل دسترسی ایجاد کرده و بررسی می کنیم که آیا این کاربر می تواند تابع فوق را اجرا کند؟

SQL> create user vahid  identified by a;
User created.
SQL> grant create session to vahid; 
Grant succeeded.

(بیشتر…)

نکاتی در مورد Materialized View و NoLogging

بروزرسانی Materialized Viewهای حجیم آن هم به صورت complete می تواند DBA را در جنبه های مختلفی به چالش بکشاند به ویژه آنکه دیتابیس در مود آرشیو قرار داشته باشد چرا که در این صورت، بروزرسانی MV منجر به ایجاد حجم زیادی از آرشیولاگ خواهد شد. البته اثرات منفی این مسئله، صرفا به فضای مصرفی redoها خلاصه نمی شود و از لحاظ پرفورمنسی هم می تواند بر روی عملکرد دیتابیس اثر منفی بگذارد.

در این متن بررسی می کنیم که غیرفعال کردن Logging در سطوح object، tablespace و database چه اثراتی را بر روی عملیات ساخت و بروزرسانی Materialized Viewها به همراه خواهد داشت(مطالعه مطلب “تاثیر عملیات NOLOGGING در دیتاگارد”  پیشنهاد می شود).

(بیشتر…)

ردیابی اهدای مجوزها در اوراکل از طریق ویوی ALL_TAB_PRIVS_MADE و USER_TAB_PRIVS_RECD

اگر کاربری مجوزی را به کاربر دیگر اهدا کند، این عملیات از طریق ویوی ALL_TAB_PRIVS_MADE قابل ردیابی است(البته با رعایت شرایطی!) و این ویو در کنار ویوی USER_TAB_PRIVS_RECD مشخص می کند که مجوز توسط کدام کاربر به کاربر دیگر اهدا شده است.

برای مثال در قسمت زیر، کاربر usef مجوز select on ali.tbl1 را به کاربر vahid اهدا می کند:

SQL> create user usef identified by a;
User created.
SQL> create user vahid identified by a;
User created.
SQL> grant create session to vahid,usef;
Grant succeeded.
SQL> grant select on ali.tbl1 to usef with grant option;
Grant succeeded.
SQL> conn usef/a
Connected.
SQL> show user
User is "USEF"
SQL> grant select on ali.tbl1 to vahid;
Grant succeeded.
SQL> conn ali/a
Connected.
SQL> select grantee, grantor,privilege, table_name from user_tab_privs_made where GRANTEE='VAHID';
GRANTEE     GRANTOR    PRIVILEGE  TABLE_NAME
----------- ---------- ---------- ----------
VAHID       USEF       SELECT     TBL1

همانطور که می بینید، با اجرای پرس و جوی فوق توسط کاربر ali، خواهیم دید که مجوز select on ali.tbl1 توسط کاربر usef به کاربر VAHID اختصاص داده شده است. البته با اجرای ویوی USER_TAB_PRIVS_RECD هم به این نتیجه خواهیم رسید:

SQL> conn vahid/a
Connected.
SQL> select owner,table_name,grantor,privilege,type from USER_TAB_PRIVS_RECD;
OWNER      TABLE_NAME GRANTOR    PRIVILEGE  TYPE
---------- ---------- ---------- ---------- ------------
ALI        TBL1       USEF       SELECT     TABLE

در این شرایط با حذف کاربر usef، دسترسی داده شده به کاربر vahid از بین خواهد رفت و به تبع آن، این دو ویو هم اطلاعاتی را در این زمینه بر نمی گردانند:

SQL> drop user usef;
User dropped.
SQL> conn ali/a
Connected.
SQL> select owner,table_name,grantor,privilege,type from USER_TAB_PRIVS_RECD;
no rows selected
SQL> select * from ALI.TBL1;
ORA-00942: table or view does not exist

با اندکی تغییر در سناریوی قبلی، نقش dba را به کاربر usef اختصاص می دهیم و بعد از ان کاربر usef، دسترسی select on ali.tbl1 را به کاربر vahid اهدا می کند، با این تغییر، دو ویوی فوق، کاربر ALI را به عنوان grantor معرفی خواهند کرد:

SQL> create user usef identified by a;
User created.
SQL> grant dba to usef;
Grant succeeded.
SQL>  conn usef/a
Connected.
SQL> grant select on ali.tbl1 to vahid;
Grant succeeded.
SQL> conn vahid/a
Connected.
SQL> select owner,table_name,grantor,privilege,type from USER_TAB_PRIVS_RECD;
OWNER      TABLE_NAME GRANTOR    PRIVILEGE  TYPE
---------- ---------- ---------- ---------- ------------------------
ALI        TBL1       ALI        SELECT     TABLE
SQL> conn ali/a
Connected.
SQL> select grantee, grantor, table_name from user_tab_privs_made where GRANTEE='VAHID';
GRANTEE     GRANTOR    TABLE_NAME
----------- ---------- ----------
VAHID       ALI        TBL1

 

اوراکل لینوکس 9 – بازسازی کرنل بعد از اجرای دستور */rm -rf /boot

در صورت حذف تصادفی(و یا عمدی!) فایلهای موجود در مسیر boot/، سیستم عامل برای استارت مجدد به مشکل برخواهد خورد چرا که این دایرکتوری حاوی فایلهایی مربوط به bootloader و همینطور kernel لینوکس است که سیستم برای boot شدن به آنها نیاز دارد.

بازسازی این فایلها از طریق rescue mode قابل انجام است که در این متن قصد داریم نحوه انجام آن را توضیح دهیم.

برای پیش بردن این سناریو، در قدم اول، محتویات boot/ را حذف می کنیم:

(بیشتر…)

اجرای کلاستر اوراکل در داکر(Oracle RAC 21c)

برای نصب Oracle RAC به منظور استفاده در محیط آموزشی و یا اجرای بعضی از تستها، معمولا از Oracle Virtual Box و یا VMware workstation استفاده می کنیم.

برای این کار باید به تعداد نودهای کلاستر، ماشین مجازی ایجاد کرده و بر روی هر کدام از این ماشینها، سیستم عاملی را نصب کنیم و در نهایت اقداماتی را در هر کدام از این سیستم عاملها انجام دهیم تا شرایط برای نصب کلاستر فراهم شود. پیکربندی کلاستر در محیط VM نسبتا زمانبر است و شاید کمی پیچیده هم باشد.

 البته در این زمینه، VM تنها گزینه ما نیست و استفاده از Docker می تواند به عنوان انتخابی دیگر، ایرادات ذکر شده را از بین ببرد.

اوراکل از نسخه 12c امکان اجرای Oracle RAC در داکر را برای محیط تست و develop فراهم کرده و در نسخه 21c، از اجرای Oracle RAC در محیط docker آن هم به صورت عملیاتی پشتیبانی می کند.

اجرای Oracle RAC در داکر، می تواند با استفاده از یک یا چند هاست انجام شود که در این متن صرفا از یک هاست استفاده خواهیم کرد و راه اندازی آن در چند هاست را به زمانی دیگر موکول می کنیم.

سیستم عاملی که از آن استفاده کرده ایم، Oracle Linux نسخه 7 می باشد و قرار است Oracle RAC نسخه 21c را در این محیط اجرا کنیم. این کار با کمک سه container انجام خواهد شد که یکی از آنها برای DNS server و دو container دیگر هم هر کدام نودهای کلاستر را تشکیل خواهند داد.

در ابتدا مراحل پیکربندی را مرور می کنیم:

1.نصب و اجرای داکر

2.آماده سازی داکر هاست

3.تنظیم Docker Network

4.نصب git و کلون Oracle Repository

5.ایجاد container برای DNS

6.ایجاد container برای راه اندازی نود اول کلاستر

7.اضافه کردن نود دوم کلاستر

(بیشتر…)

اجرای دیتابیس اوراکل با داکر

اجرای دیتابیس در محیط داکر می تواند مزایای متعددی را به همراه داشته باشد، که به عنوان نمونه می توان به “سادگی و افزایش سرعت در نصب و راه اندازی”، “اجرای نسخه های متعدد در یک هاست” و یا “اجرای دیتابیس در سیستم عاملهایی که امکان نصب مستقیم دیتابیس بر روی آنها وجود ندارد”، اشاره کرد.

در این مستند قصد داریم با گرفتن image از Oracle Container Registry، دیتابیس اوراکل را در محیط داکر اجرا کنیم برای این کار ابتدا باید در سایت oracle.com امور مقدماتی نظیر ایجاد اکانت را انجام دهیم و با توجه به انکه این متن بیشتر برای افرادی که با دیتابیس اوراکل آشنا نیستند، نوشته شده است، تمامی مراحل را با جزییات شرح داده ایم.

 

ساخت اکانت در oracle.com

در قدم اول اگر اکانتی در سایت اوراکل ندارید، با رفتن به آدرس زیر، این اکانت را ایجاد کنید:

https://profile.oracle.com/myprofile/account/create-account.jspx

 

(بیشتر…)

نصب Docker در اوراکل لینوکس 8

در این متن قصد داریم داکر را بر روی اوراکل لینوکس نسخه 8 نصب کنیم و در مطلب بعدی، اجرای اوراکل با داکر را توضیح خواهیم داد. قبل از نصب پکیج مربوط به docker، باید پکیج yum-utils را نصب کنیم:

[root@OEL8 ~]# yum install –y yum-utils

برای نصب داکر باید Docker Repository را اضافه کنیم این کار با دستور زیر قابل انجام است:

[root@OEL8 ~]# yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
Adding repo from: https://download.docker.com/linux/centos/docker-ce.repo

بعد از اجرای این دستور خواهیم دید که فایل docker-ce.repo در مسیر زیر اضافه شده است:

[root@OEL8 ~]# cd /etc/yum.repos.d/
[root@OEL8 yum.repos.d]# ll docker*
-rw-r—r--. 1 root root 1919 Sep  9 10:12 docker-ce.repo

(بیشتر…)

نکته ای در مورد بکاپ گیری از استندبای

همانطور که می دانید، در زمان بکاپ گیری با ابزار RMAN، می توان از physical standby به جای دیتابیس primary استفاده کرد تا از این جهت بار اضافه ای به primary تحمیل نشود.

با توجه به آنکه ساختار این دو محیط(primary و physical standby) مشابه هم هستند، بکاپ گیری در این دو محیط تفاوت چندانی ندارد(دیتافایلها در این دومحیط بلاک به بلاک با هم مطابقت دارند البته به شرط sync بودن استندبای)

و اندک تفاوت ایجاد شده، به open mode این دو دیتابیس برمی گردد و این تفاوت، حداقل در زمان بکاپ گیری از archive log خودش را نشان می دهد چرا که اوراکل در زمان بکاپ گیری از آرشیولاگ، log switchی را اجرا خواهد کرد و بدیهی است که این log switch در محیط physical standby قابل اجرا نخواهد بود.

دستور زیر در محیط physical standby اجرا شده است پیام RMAN-06820 در خروجی این دستور، گواهی بر نکات ذکر شده، می باشد.

rman target /
RMAN>  backup archivelog all  format '/bkp/%U';
Starting backup at 12-AUG-21
using target database control file instead of recovery catalog
'RMAN-06820: warning: failed to archive current log at primary database'
cannot connect to remote database
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=1321 device type=DISK
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=179829 RECID=83713 STAMP=1080395727
input archived log thread=1 sequence=179830 RECID=83714 STAMP=1080395729
channel ORA_DISK_1: starting piece 1 at 12-AUG-21
channel ORA_DISK_1: finished piece 1 at 12-AUG-21
piece handle=/bkp/iv06b2l4_1_1 tag=TAG20210812T140732 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 12-AUG-21

برای جلوگیری از این مسئله باید در هنگام اتصال به physical standby، پسورد کاربر sys را هم وارد کنیم که در این صورت، log switch در بانک اصلی انجام خواهد شد:

rman target sys/sys
RMAN> backup archivelog all  format '/bkp/%U';
Starting backup at 12-AUG-21
using target database control file instead of recovery catalog
'current log archived at primary database'
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=1321 device type=DISK
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=179829 RECID=83713 STAMP=1080395727
input archived log thread=1 sequence=179830 RECID=83714 STAMP=1080395729
input archived log thread=1 sequence=179831 RECID=83715 STAMP=1080396540
channel ORA_DISK_1: starting piece 1 at 12-AUG-21
channel ORA_DISK_1: finished piece 1 at 12-AUG-21
piece handle=/bkp/j106b2nv_1_1 tag=TAG20210812T140903 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
Finished backup at 12-AUG-21

در alert log محیط primary اطلاعات این log switch قابل مشاهده است:

2021-08-12T14:13:40.047070+04:30
ALTER SYSTEM ARCHIVE LOG
2021-08-12T14:13:40.066804+04:30
Thread 1 advanced to log sequence 179832 (LGWR switch)
  Current log# 3 seq# 179832 mem# 0: /oradata/DBORG/onlinelog/o1_mf_3_j4675ghj_.log
  Current log# 3 seq# 179832 mem# 1: /fra/DBORG/onlinelog/o1_mf_3_j4675jwx_.log
2021-08-12T14:13:40.285117+04:30
TT02 (PID:27803): SRL selected for T-1.S-179832 for LAD:2
2021-08-12T14:13:40.508384+04:30
NET  (PID:39106): Archived Log entry 362234 added for T-1.S-179831 ID 0x46023b59 LAD:1

 

نکته ای در مورد Role و Privilege در اوراکل

زمانی که مجوزی از نوع object privilege و یا system privilege به کاربری داده می شود(و یا از کاربر گرفته(revoke) می شود)، بلافاصله sessionهای ان user که به دیتابیس متصل هستند، از این مجوزها بهره مند خواهند شد:

–session 1:

SQL*Plus: Release 19.0.0.0.0 - Production on Thu Sep 16 19:48:16 2021
Version 19.11.0.0.0
SQL> show user
USER is "ALI"
SQL> select * from session_privs;
PRIVILEGE
----------------------------------------
CREATE SESSION

–session 2:

SQL> show user
USER is "USEF"
SQL> grant select any table to ALI;
Grant succeeded.

–session 1:

SQL> select * from session_privs;
PRIVILEGE
----------------------------------------
CREATE SESSION
SELECT ANY TABLE

اما این مسئله برای role صادق نیست و در صورت grant یا revoke کردن یک roleء، sessionهای جاری متاثر نخواهند شد مگر آنکه از دستور SET ROLE استفاده کنند:

(بیشتر…)