اجرای کلاستر اوراکل در داکر(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 استفاده کنند:

(بیشتر…)

اوراکل 21.7 – راه اندازی دیتاگارد در سطح PDB(قابلیت DGPDB)

DGPDB(یا همان Data Guard per Pluggable Database) قابلیت جدیدی است که در نسخه 21.7 اوراکل ارائه شده و قرار است با کمک این قابلیت، در سطح PDB، دیتاگارد راه اندازی کنیم.

 در معماری قدیمی(قبل از ارائه DGPDB)، یکی از CDBها(به انضمام همه PDBها) در نقش primary قرار داشت و CDB دیگر نقش standby را ایفا می کرد و راه اندازی دیتاگارد برای یک PDB منوط به راه اندازی دیتاگارد برای CDB$ROOT بود و دیتاگارد هم نمی توانست container اضافه ای را داشته باشد به عبارتی دیگر، Guard عینا مشابه primary و یا در صورت مستثنا کردن بعضی از PDBها(enabled_PDBs_on_standby)، دیتاگارد زیر مجموعه ای از primary بود.

اما DGPDB این محدودیتها را برداشت معماری این قابلیت که شباهتهایی هم با قابلیت PDB switchover دارد(قابلیت switchover  در نسخه 18c ارائه شده بود)، به این صورت است که:

1.هر دو CDB در نقش primary و در حالت read write قرار دارند و برخلاف معماری سنتی، CDB$ROOT بین این دو دیتابیس یکسان نیست و هر CDBء PDBهای مختص به خود را دارند.

2.نقش standby و primary در سطح PDB قابل تنظیم است مثلا برای PDB حاضر در CDB1 می توانیم در CDB2 گارد ایجاد کنیم و به همین شکل می توانیم در CDB1 برای PDBهای حاضر در CDB2 دیتاگارد راه اندازی کنیم.

3.تغییر چندانی در پروسه ارسال و دریافت redoها در طرفین ایجاد نشده و پروسه TTnn در معماری DGPDB نقش کلیدی را ایفا می کند.

(بیشتر…)

راهنمای نصب APEX 22.1

در این متن قصد داریم نحوه نصب Oracle APEX 22.1 را در دیتابیس نسخه 21c و در محیط لینوکس شرح دهیم. برای این کار نیاز است تا مراحل زیر را طی کنیم:

1.نصب اوراکل لینوکس(نسخه 8)

2.نصب و آماده سازی اوراکل(نسخه 21c)

3.نصب APEX

4.نصب ORDS

(بیشتر…)

برگرداندن بکاپ PDB در یک CDB جدید!

مطابق با داکیومنتهای اوراکل در زمینه Backup/Recovery، برای برگرداندن یک PDB ابتدا باید بکاپ CDB مربوط به آن PDB را برگرداند در غیر این صورت امکان برگرداندن PDB وجود ندارد! اما در این متن با روش جدیدی آشنا خواهیم شد که امکان برگرداندن بکاپ PDB را در یک CDB جدید فراهم می کند. البته این روش همیشه جواب نمی دهد و بهتر است که در سناریو بکاپ و ریکاوری این موضوع را در نظر داشته باشیم.

در سناریوی پیش رو قرار است از PDBای به نام RmanPDB به صورت مستقل بکاپ گرفته و با انتقال آن به سرور جدید، سعی داریم این PDB را در یک CDB جدید برگردانیم.

بکاپ از RmanPDB:

Connected to:
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.3.0.0.0
SQL> show pdbs
    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         5 PDB1                           READ WRITE NO
         4 RMANPDB                        READ WRITE NO
RMAN> backup pluggable database RmanPDB format '/oracle21c/bkp_pdb/%U' current controlfile  format '/oracle21c/bkp_pdb/control0000.bkp';
Starting backup at 16-OCT-21
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=266 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00068 name=/oracle21c/base/oradata/DB21C/CE75C2880CCD2A3FE0530488200A29C8/datafile/o1_mf_sysaux_jpo62lhz_.dbf
input datafile file number=00067 name=/oracle21c/base/oradata/DB21C/CE75C2880CCD2A3FE0530488200A29C8/datafile/o1_mf_system_jpo62lhv_.dbf
input datafile file number=00069 name=/oracle21c/base/oradata/DB21C/CE75C2880CCD2A3FE0530488200A29C8/datafile/o1_mf_undotbs1_jpo62lj1_.dbf
input datafile file number=00070 name=/oracle21c/base/oradata/DB21C/CE75C2880CCD2A3FE0530488200A29C8/datafile/o1_mf_tbs01_jpo66vjx_.dbf
channel ORA_DISK_1: starting piece 1 at 16-OCT-21
channel ORA_DISK_1: finished piece 1 at 16-OCT-21
piece handle=/oracle21c/bkp_pdb/4p0bo4mu_153_1_1 tag=TAG20211016T052342 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
channel ORA_DISK_1: starting piece 1 at 16-OCT-21
channel ORA_DISK_1: finished piece 1 at 16-OCT-21
piece handle=/oracle21c/bkp_pdb/control0000.bkp tag=TAG20211016T052342 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 16-OCT-21

(بیشتر…)

JSON Multivalue index در اوراکل 21c

در متن “JSON و دیتابیس اوراکل” توضیح دادیم که چگونه اوراکل در نسخه 12c امکان ذخیره و کنترل اطلاعات JSON را در قالب دیتاتایپ CLOB، varchar و … فراهم کرده است و همچنین مطالبی را در مورد نحوه ایندکس گذاری کلیدهای JSON ارائه کرده ایم(برای مطالعه). در نسخه 21c بهبودهای دیگری نظیر نوع داده JSON، تابع JSON_TRANSFORM و … هم به این مجموعه قابلیتها اضافه شد که قبلا بعضی از آنها را مستند کرده ایم و در این متن قصد داریم در مورد یکی دیگر از این قابلیتها که JSON Multi value index است، نکاتی را بنویسیم.

می دانیم که قرار نیست ما به ازای هر کلید در JSON، صرفا یک مقدار ذخیره شود و در مواردی ممکن است مقدار یک کلید، یک آرایه(یا همان لیست) باشد. در این شرایط استفاده از روشهای قبلی ایندکس گذاری برای جستجو چندان کارآمد نخواهند بود و باید به دنبال روش جدیدی برای این حالت باشیم. در ادامه با ارائه مثالی، بیشتر این موضوع را توضیح خواهیم داد.

(بیشتر…)

تابع checksum در اوراکل 21c

در نسخه 12c، اوراکل با ارائه تابع STANDARD_HASH، امکان محاسبه hash value را برای یک فیلد و یا عبارت فراهم کرده است:

SQL> select id,salary,substr(STANDARD_HASH(id||salary),1,20) hash_id_sal from tbl1;
        ID     SALARY HASH_ID_SAL
---------- ---------- ----------------------
         1         10 5E796E48332AF4142B10
         2         12 E2154FEA5DA2DD0D1732
         3         17 F44A286F486D11990238
         4         18 93AC1946CB917ABC4735

با این روش می توانیم از تغییر مقدار سطرهای جدول باخبر شویم. البته در نسخه های قبل از 12c هم می توانستیم از توابع دیگری نظیر ora_hash بدین منظور استفاده کنیم:

SQL> select id,salary,ora_hash(id||salary)  hash_id_sal from tbl1;

        ID     SALARY HASH_ID_SAL
---------- ---------- -----------
         1         10  3316966336
         2         12  1402677848
         3         17  3795753203
         4         18   936769390

در نسخه 21c هم قابلیت جدیدی در این زمینه ارائه شد و اوراکل با معرفی تابع checksum، امکان شناسایی تغییر دیتا را در سطح ستون فراهم کرده است.

(بیشتر…)