……..آموزش، مشاوره و پشتیبانی…….
با فرمت حلقه FOR آشنا هستید:
FOR loop_counter IN [REVERSE] lowest_number..highest_number
LOOP
{...statements...}
END LOOP;
مطابق این syntax، قرار است شمارنده(loop_counter) به صورت ترتیبی(با گام یک) از نقطه lowest_number به نقطه highest_number برسد. برای مثال، با اجرای قطعه کد زیر، اعداد 4 تا 8 نمایش داده می شوند:
SQL> set serveroutput on
begin
for i in 4 .. 8 loop
dbms_output.put_line(i);
end loop;
end;
/
4
5
6
7
8
PL/SQL procedure successfully completed.
قابلیت unified auditing در اوراکل نسخه 21c، عملیات auditing را برای همه editionهای یک object امکان پذیر می سازد و حتی اگر در آینده edition جدیدی ایجاد شود، auditing در سطح edition جدید هم اعمال خواهد شد. برای مثال، ویوی vw_IRIR را در دو edition مختلف ایجاد می کنیم:
SQL> alter session set edition=IR_EDITION1; Session altered SQL> CREATE EDITIONING VIEW vw_IRIR AS select * from usef.tbl1; View created SQL> alter session set edition=IR_EDITION2; Session altered SQL> CREATE OR REPLACE EDITIONING VIEW vw_IRIR AS select owner from usef.tbl1; View created SQL> select object_name, edition_name from user_objects_ae where object_name='VW_IRIR'; OBJECT_NAM EDITION_NAME ---------- -------------- VW_IRIR IR_EDITION1 VW_IRIR IR_EDITION2
همانطور که می دانید از نسخه 12cR1، دیتابیس اوراکل از JSON پشتیبانی می کند به این معنی که با ارائه چندین تابع، امکان انجام عملیاتی چون اجرای query، ایجاد index و ایجاد view را بر روی فیلدهای JSON Document فراهم می کند.
البته در این نسخه ها(تا قبل از اوراکل 21)، Data Type جدیدی برای JSON معرفی نشده و JSON Documentها باید در نوع داده VARCHAR2، CLOB و یا BLOB ذخیره شوند(نوع داده NCLOB و NVARCHAR2 را هم باید به این مجموعه اضافه کرد) که معمولا نوع داده BLOB برای این کار توصیه می شود(مطالعه مطلب “JSON و دیتابیس اوراکل” پیشنهاد می شود).
SQL> create table tbl_JSON_12c (id number,ettelaat varchar2(4000) constraint jc1 check (ettelaat is json) );
SQL> insert into tbl_JSON_12c values(2,'{“First_Name”:”Vahid”,”Last_Name”:”Usefzadeh”,”Contact”:{“Email”:”vahidusefzadeh@gmail.com”,”Phone”:”091111111117″}}’);
1 row inserted
SQL> select t.ETTELAAT.Last_Name,t.ETTELAAT.Contact.Email from tbl_JSON_12c t;
LAST_NAME CONTACT
————– —————————-
Usefzadeh vahidusefzadeh@gmail.com
اوراکل در نسخه 21c، نوع داده JSON را معرفی کرده است:
SQL> create table tbl_JSON_21c (id number, ettelaat json) ;
Table created.
SQL> insert into usef.tbl_JSON_21c values(2,'{"First_Name":"Vahid","Last_Name":"Usefzadeh","Contact":{"Email":"vahidusefzadeh@gmail.com","Phone":"091111111117"}}');
1 row created.
تابع Json_Transform که در اوراکل نسخه 21c ارائه شد، امکان انجام تغییرات در JSON documentها را فراهم می سازد. این تابع عملکری مشابه با تابع JSON_MERGEPATCH دارد البته با قابلیتهای بسیار بیشتر.
با استفاده از تابع Json_Transform می توان آیتمهای موجود در JSON documentها را UPDATE(SET)، REMOVE و RENAME کرد و یا item جدیدی به آن اضافه نمود.
این تابع می تواند در دستور select و update استفاده شود که استفاده از آن در دستور select صرفا می تواند در خروجی دستور تغییر ایجاد کند و برای بروزرسانی پایدار باید از دستور update استفاده شود.
در ادامه با توضیح عملگرهای SET، INSERT، REMOVE و RENAME بیشتر با تابع Json_Transform آشنا خواهیم شد.
زمانی که INMEMORY را در سطح column فعال می کنیم، صرفا پرس و جوهایی که به ستونهای INMEMORY جدول رجوع می کنند، از In-Memory scan بهره خواهند برد و اگر در یک پرس و جو به هیچ یک از ستونهای In-Memory رجوع نشود، اوراکل بصورت ROW-STORE access به این پرس و جو پاسخ خواهد داد.
حالت دیگری هم در اینجا قابل تصور است! اگر پرس و جویی به صورت ترکیبی،به ستونهای INMEMORY و NO INMEMORY رجوع کند، اوراکل چه نوع scanای را انتخاب خواهد کرد؟
تا قبل از نسخه 21c، اوراکل برای این دسته از پرس و جوها، به In-Memory رجوع نمی کرد و با رجوع به buffer cache و بصورت row-store access به این پرس و جوها پاسخ می داد.
اما در اوراکل 21c، قابلیت جدیدی به نام In-Memory Hybrid Scan ارائه شد که بر اساس آن، اگر برای همه ستونهایی که در قسمت where clause دستور استفاده شدند، خصیصه INMEMORY فعال شده باشد(و علاوه بر آن، ستون NO INMEMORY در select list موجود باشد) اوراکل میتواند به صورت ترکیبی از هر دو scan( یعنی row store scan و in-memory scan) استفاده کند. به این شیوه از scan، اصطلاحا In-Memory Hybrid Scan گفته می شود.
در اوراکل نسخه 19c، دیتاگارد نمی تواند عملیاتی نظیر hot cloning و point-in-time recovery را در سطح PDB مدیریت کند و در صورت انجام این قبیل عملیات در primary، دیتاگارد بدون آنکه از حالت recover خارج شود، از آن PDB صرف نظر کرده و با نادیده گرفتن PDB، به کارش ادامه خواهد داد.
–Data Guard 19c
SQL> select OPEN_MODE from v$database;
OPEN_MODE
——————–
READ ONLY WITH APPLY
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
———- —————————— ———- ———-
2 PDB$SEED READ ONLY NO
3 PDB1 READ ONLY NO
–Primary 19c
SQL> create pluggable database pdb2 from pdb1;
Pluggable database created.
SQL> alter pluggable database pdb2 open;
Pluggable database altered.
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
———- —————————— ———- ———-
2 PDB$SEED READ ONLY NO
3 PDB1 READ WRITE NO
5 PDB2 READ WRITE NO
–Data Guard 19c
SQL> select OPEN_MODE from v$database;
OPEN_MODE
——————–
READ ONLY WITH APPLY
SQL> alter pluggable database pdb2 open;
ORA-01111: name for data file 13 is unknown – rename to correct file
SQL> select name,status from v$datafile;
NAME STATUS
———————————– ——-
/oracle19c/home/dbs/UNNAMED00013 SYSOFF
/oracle19c/home/dbs/UNNAMED00014 RECOVER
/oracle19c/home/dbs/UNNAMED00015 RECOVER
/oracle19c/home/dbs/UNNAMED00016 RECOVER
در اوراکل نسخه 21c، قابلیتهای جدیدی در زمینه transportable tablespace export/import ارائه شد که در ادامه متن به این قابلیتها خواهیم پرداخت.
بهبود اول: عملیات TTS export/import را نمی توان در نسخه 19c به صورت parallel اجرا کرد:
Connected to: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 – Production
ORA-39002: invalid operation
ORA-39047: Jobs of type TRANSPORTABLE cannot use multiple execution streams.
در نسخه 21c و در زمان اجرای gridSetup.sh می توان با استفاده از پارامتر switchGridHome، بین Grid Infrastructure Home در حال اجرا و Grid Infrastructure Homeای که بر روی آن patch اعمال شده، جابجا شد. برای مثال، با کمک این قابلیت جدید می توان از Grid Infrastructure(GI) نسخه 21.3 به GI نسخه 21.4 سوییچ کرد که در ادامه نحوه انجام ان را توضیح داده ایم.
*قبل از شروع سناریو، به خاطر داشته باشید که Grid Infrastructure نسخه 21.3 از قبل نصب شده و در حال سرویس دهی است.
**در قدم اول، در کنار نسخه در حال اجرا، مسیری را برای نصب Grid Infrastructure جدید ایجاد می کنیم و patch مربوط به 21.4 RU را در دایرکتوری ای که کاربر grid به آن دسترسی دارد، unzip می کنیم:
[root@Olinux8 ~]# mkdir -p /grid21cR4/home
[root@Olinux8 ~]# chown -R grid.oinstall /grid21cR4
[grid@Olinux8 ~]$ cd /grid21cR4/home
[grid@Olinux8 home]$ unzip /source/21cR3/LINUX.X64_213000_grid_home.zip
[grid@Olinux8 home]$ unzip /source/p6880880_210000_27_Linux-x86-64.zip
[grid@Olinux8 ~]$ unzip /source/21cR4/21cR4_p33250101_210000_Linux-x86-64.zip -d /home/grid
همانطور که می دانید یکی از وظایف روزانه DBA، چک کردن پیامهای ثبت شده در Alert Log است بررسی محتویات این فایل به ویژه در زمان troubleshooting، نباید توسط DBA نادیده گرفته شود چرا که بعضا خطاها به وضوح در این فایل ثبت می شوند البته علاوه بر خطاها، پیامهای دیگری نظیر log switchها هم در این فایل موجود هستند که ممکن است سبب افزایش حجم و در نتیجه افزایش زمان پیمایش و جستجو در این فایل شوند.
اوراکل در نسخه 21c در کنار فایل alert log، فایل دیگری را با عنوان attention log ایجاد می کند که در ان پیامهای با درجه اهمیت بالاتر در دسته بندی های مختلف وفرمتی خواناتر(نسبت به alert log) ثبت می شوند تا DBA بتواند سریعتر متوجه بعضی از وقایع مهم شود. نمونه ای از این پیامها را در قسمت زیر مشاهده می کنید:
[root@oLinux7 trace]# less attention_db21c.log
{
“ERROR” : “DBW0 (ospid: 21898): terminating the instance due to ORA error 472“,
“URGENCY” : “IMMEDIATE“,
“INFO” : “Additional Information Not Available”,
“CAUSE” : “The instance termination routine was called”,
“ACTION” : “Check alert log for more information relating to instance termination rectify the error and restart the instance”,
“CLASS” : “CDB Instance / CDB ADMINISTRATOR / AL-1003”,
“TIME” : “2021-09-23T01:24:01.602-04:00”
}
همانطور که می دانید، اوراکل در نسخه 21c، معماری non-CDB را ساپورت نمی کند بنابرین برای ارتقا نسخه non-CDB به 21c، باید قبل از ارتقا، دیتابیس non-CDB را به یک PDB تبدیل کنیم. قبلا نحوه انتقال و ارتقا دیتابیسی با معماری non-CDB به نسخه 21c را با استفاده از قابلیت Replay Upgrade توضیح دادیم در این متن از ابزار Autoupgrade برای این کار استفاده خواهیم کرد.
تفاوت عمده Autoupgrade و Replay Upgrade، به تبدیل non-cdb به pdb برمیگردد چرا که در زمان استفاده از Replay Upgrade، عملیات plug/unplug باید توسط DBA انجام شود اما در زمان استفاده از ابزار Autoupgradeء، DBA صرفا باید یک فایل پیکربندی را ایجاد کند و مابقی عملیات توسط این ابزار انجام می شود.
در ادامه متن، مراحل ارتقا non-cdb از نسخه 19c به نسخه 21c را توضیح خواهیم داد.