اوراکل 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 بیشتر با این فیچر را آشنا خواهیم شد.

(بیشتر…)

بهبودهای حلقه تکرار FOR در اوراکل 21c

با فرمت حلقه 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.


(بیشتر…)

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

ANY_VALUE تابع جدیدی است که در اوراکل 21c معرفی شده و البته در Release Updateهای انتهایی اوراکل نسخه 19c(یعنی از 19.8 به بالا) هم قابل استفاده است. در متن پیش رو با این تابع آشنا خواهیم شد.

*پرس و جوی زیر در pdb1 اجرا می شود و قرار است مشخص کند هر tablespace چند دیتافایل دارد:

select t.ts#, t.name, count(*) "Tedad_DataFile"
  from v$datafile d, v$tablespace t
 where t.ts# = d.ts#
 group by t.ts#, t.name;

همانطور که مشاهده می کنید، در پرس و جوی فوق هر دو ستون ts# و name در قسمت group by قید شده اند در صورتی که عدم درج ستون name در قسمت group by، تغییری در خروجی ایجاد نمی کند اما اوراکل اجازه این کار را به ما نمی دهد:

ORA-00979: not a GROUP BY expression

(بیشتر…)

اعمال auditing برای همه editionهای یک object

قابلیت 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

(بیشتر…)

تغییرات GIMR Database در اوراکل کلاستر 21c

GIMR یا همان Grid Infrastructure Management Repository در اوراکل 12c ارائه شد و هدف اوراکل از ارائه GIMR، ثبت وقایع و رخدادهای مربوط به کلاستر می باشد به طور دقیق تر، GIMR قرار است Cluster Health Monitor را در دیتابیسش ثبت کند. این دیتابیس حدودا 20 جدول دارد که لیست جداول آن را می توان به روش زیر مشاهده کرد:

[grid@RAC1 ~]$ export ORACLE_SID=-MGMTDB
[grid@RAC1 ~]$ sqlplus "/as sysdba"
SQL> alter session set container=GIMR_DSCREP_10;
Session altered.
SQL>  select table_name from dba_tables where owner='CHM' order by table_name;
TABLE_NAME
--------------------------------------------------------------------------------
CATCHMUTILPLS_PARTITION_TMP_TBL
CHMOS_ACTIVE_CONFIG_INT_TBL
CHMOS_ADVM_INT_TBL
…
16 rows selected.

(بیشتر…)

دیتاتایپ JSON در اوراکل 21c

همانطور که می دانید از نسخه 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.

(بیشتر…)

اوراکل21c – بروزرسانی اطلاعات JSON با کمک تابع JSON_TRANSFORM

تابع 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 آشنا خواهیم شد.

(بیشتر…)

SQL Macros در اوراکل 21c

همانطور که می دانید فراخوانی تابع در یک کوئری، context switch بین SQL engine و PL/SQL engine را در پی دارد این context switch به لحاظ پرفورمنسی اثر منفی را به دنبال خواهد داشت. برای مثال، دو دستور زیر خروجی یکسانی دارند اما مدت زمان اجرای آنها بسیار متفاوت است.

اجرای دستور بدون استفاده از function:

SQL> select sum(sal) from(select salary+60 as sal from person);

  SUM(SAL)

———-

8891924480

Elapsed: 00:00:00.81

اجرای دستور با استفاده از function:

SQL> select sum(sal) from(select sal_func(salary) as sal from person);

  SUM(SAL)

———-

8891924480

Elapsed: 00:00:10.91

(بیشتر…)

اوراکل 21c- قابلیت In-Memory Hybrid Scan

زمانی که 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 گفته می شود.

(بیشتر…)

اوراکل 21c – قابلیت PDB Recovery Isolation

در اوراکل نسخه 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

(بیشتر…)