نصب Oracle GoldenGate 21c با معماری Microservice

در این مستند قصد داریم به نحوه نصب Oracle GoldenGate 21c با معماری Microservice بپردازیم. قبل از نصب باید در نظر داشته باشیم که برای استفاده از نسخه مایکروسرویس گلدن گیت، می توانیم این نرم افزار را در سمت source و یا target نصب کنیم و نصب آن در هر دو طرف replication الزامی نیست همچنین source و یا target بودن سرور تاثیری در مراحل نصب نخواهد داشت.

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

[oracle@target ~]$ mkdir /oracle/OGGMA21c

ابزار runInstaller را برای نصب نرم افزار اجرا می کنیم:

[oracle@target source]$ unzip 213000_fbo_ggs_Linux_x64_Oracle_services_shiphome.zip
[oracle@target ~]$ cd /source/fbo_ggs_Linux_x64_Oracle_services_shiphome/Disk1
[oracle@target Disk1]$ ./runInstaller
Starting Oracle Universal Installer...
Checking Temp space: must be greater than 120 MB.   Actual 70018 MB    Passed
Checking swap space: must be greater than 150 MB.   Actual 1023 MB    Passed
Checking monitor: must be configured to display at least 256 colors.    Actual 16777216    Passed
Preparing to launch Oracle Universal Installer from /tmp/OraInstall2023-03-09_10-45-39AM. Please wait ...

بر خلاف نسخه های قبلی، در نسخه 21c نیازی به انتخاب نسخه دیتابیس در طول نصب golden gate وجود ندارد:

(بیشتر…)

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

(بیشتر…)

نصب 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

(بیشتر…)

اوراکل 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

(بیشتر…)

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، امکان شناسایی تغییر دیتا را در سطح ستون فراهم کرده است.

(بیشتر…)

اوراکل 21c – پشتیبانی از شرط نامساوی در Automatic Indexing

قابلیت auto indexing در اوراکل نسخه 19c شرط عدم تساوی را پشتیبانی نمی کند که قبلا در این مورد مطلبی را ارائه کرده ایم. نسخه 21c این قابلیت را فراهم کرده است که در ادامه این مسئله را می بینید.

برای نمایش این محدودیت، جدولی را همراه با حجم قابل توجهی از اطلاعات ایجاد می کنیم:

SQL> create table tb(id number,name varchar2(100),date_time date,c1 varchar2(4000),c2 varchar2(4000));
Table created
SQL> insert into tb select rownum,'test'||’’||rownum,sysdate - rownum,rpad('test',400,'c1'),rpad('test',400,'c2') from dual connect by level <=666444;
666444 rows inserted
SQL> commit;
Commit complete
SQL> exec dbms_stats.gather_table_stats(ownname => user,tabname => 'TB');
PL/SQL procedure successfully completed

بعد از ایجاد جدول، پرس و جوی زیر را که شرط عدم تساوی در آن استفاده شده است را در دیتابیس اجرا می کنیم:

Select count(*) from tb where id between 1 and 10;

همچنین با اجرای بلاک plsql زیر، سعی در مجاب کردن اوراکل برای بررسی این پرس و جو داریم:

declare
  temp number;
begin
  for a in 1 .. 1000 loop
    select count(*) into temp from tb where id between 1 and 10;
  end loop;
end;

پس از گذشت interval پانزده دقیقه ای، گزارشی از آخرین اجرا را می بینیم:

select DBMS_AUTO_INDEX.REPORT_ACTIVITY(SYSTIMESTAMP-1,SYSTIMESTAMP,'HTML','ALL','ALL') from dual;

با اجرای دستور زیر خواهیم دید که بر روی ستون id ایندکسی ایجاد شده است:

select owner,index_name,table_name,auto from dba_indexes where AUTO='YES';

قابلیتهای جدید اوراکل 21c در زمینه عملگرهای مجموعه ای

تا قبل از نسخه 21c، صرفا می توانستیم از سه عملگر مجموعه ای INTERSECT، MINUS و UNION [ALL] در اوراکل استفاده کنیم اما در نسخه 21c دو عملگر جدید EXCEPT و EXCEPT ALL به این مجموعه اضافه شدند که این دو عملگر معادل عملگرهای MINUS و MINUS ALL هستند و صرفا به دلیل استفاده از عبارتهای EXCEPT و EXCEPT ALL در دیتابیسهای دیگر، اوراکل هم این دو عملگر را به مجموعه عملگرهای خود اضافه کرده است.

مجددا تاکید می شود که در عمل تفاوتی بین EXCEPT و MINUS وجود ندارد و حتی در صورت استفاده از عملگر EXCEPT، اوراکل در زمان اجرای پرس و جو، در مرحله Query Transformation، عملگر EXCEPT را به MINUS تبدیل می کند.

با این توضیحات، در شرایط زیر، برای برگرداندن رکوردهایی که در t1.c1 وجود دارند اما در t2.c1 وجود ندارد(با حذف رکوردهای تکراری!!) دو انتخاب داریم، عملگرEXCEPT و عملگر MINUS:

select t1.c1 from t1
MINUS
select t2.c1 from t2;
D
Z
select t1.c1 from t1
EXCEPT
select t2.c1 from t2;
D
Z

(بیشتر…)

اوراکل 21c – بازگرداندن دیتابیس به هر زمانی در گذشته

اوراکل در نسخه 19c اجازه نمی دهد که یک pdb را به زمانی از یک ORPHAN incarnation برگردانیم:

SQL*Plus: Release 19.0.0.0.0 - Production on Thu Apr 21 08:28:57 2022
Version 19.3.0.0.0
SQL>  SELECT con_id, status, pdb_incarnation# inc#, begin_resetlogs_scn, end_resetlogs_scn FROM v$pdb_incarnation ORDER BY 3;
    CON_ID STATUS        INC# BEGIN_RESETLOGS_SCN END_RESETLOGS_SCN
---------- ------- ---------- ------------------- -----------------
         3 PARENT           0             1920977           1920977
         3 ORPHAN           1             1963437           1963437
         3 CURRENT          2             1964176           1964176
SQL>  alter pluggable database pdb1401 close;
Pluggable database altered.
SQL> flashback pluggable database to scn 1962565;
ORA-39889: Specified System Change Number (SCN) or timestamp is in the middle of a previous PDB RESETLOGS operation.
SQL> flashback pluggable database PDB1401  to scn 1963437;
ORA-39889: Specified System Change Number (SCN) or timestamp is in the middle of a previous PDB RESETLOGS operation.
[oracle@stb ~]$ rman target sys/sys@192.168.1.20:1521/pdb1401
RMAN> reset pluggable database pdb1401  to incarnation 1;
'RMAN-07536: command not allowed when connected to a Pluggable Database'

اما در نسخه 21c این قابلیت به وجود آمد تا بتوان یک PDB را به هر زمانی در گذشته برگرداند(البته گذشته نزدیک). در ادامه با سناریوی زیر و با ایجاد یک ORPHAN incarnation بیشتر با این فیچر را آشنا خواهیم شد.

(بیشتر…)