تا قبل از اوراکل نسخه 18c، انجام عملیات DMLای در محیط (Active Data Guard(ADG، صرفا برای جداول از نوع global temporary table قابل انجام بود و هرگونه اجرای دستور DMLای بر روی جداول سیستمی و applicationای، جز در حالت snapshot standby، امکان پذیر نبود.

در اوراکل 18c، با ارائه دو پارامتر مخفی به نامهای enable_proxy_adg_redirect_ و ADG_REDIRECT_FLAGS_، امکان اجرای دستورات DMLای در محیط دیتاگارد فراهم شد. مثال زیر را ببینید.

–PRIMARY:

sqlplus usef/a

SQL*Plus: Release 18.0.0.0.0 – Production on Thu Farvardin 15 13:54:30 1398

Version 18.3.0.0.0

SQL> create table usef.tbl18c(id number,tarikh  date);

Table created.

–ADG:

SQL> alter system set “_enable_proxy_adg_redirect“=true;

System altered.

SQL> alter system set “_ADG_REDIRECT_FLAGS“=1;

System altered.

SQL> conn usef/a

Connected.

SQL> insert into tbl18c values(1,sysdate);

1 row created.

SQL> commit;

Commit complete.

SQL> select id,to_char(tarikh,’YYYY/MM/DD HH24:mi:ss’,’nls_calendar=persian’) tarikh  from tbl18c;

        ID TARIKH

———- ——————-

         1 1398/01/15 13:28:17

–PRIMARY:

SQL> select id,to_char(tarikh,’YYYY/MM/DD HH24:mi:ss’,’nls_calendar=persian’) tarikh  from tbl18c;

        ID TARIKH

———- ——————-

         1 1398/01/15 13:28:17

همانطور که در این مثال مشاهده شد، با تنظیم پارامترهای مخفی مذکور، امکان اجرای دستورات DMLای در محیط دیتاگارد، در اوراکل 18c هم امکان پذیر است البته به صورت غیررسمی! و با کمک hidden parameterها.

با آمدن اوراکل نسخه 19c، قابلیت جدیدی به نام ADG REDIRECT DML ارائه شد که بدون هرگونه نیاز به پارامترهای مخفی ذکر شده، به صورت رسمی، انجام عملیات DMLای را در محیط Active Data Guard امکان پذیر می سازد.

در ادامه قصد داریم با ارائه یک سناریو، این قابلیت را با جزییات بیشتری مورد بررسی قرار دهیم.

برای ارائه این سناریو، در ابتدا با اتصال به دیتابیس اصلی(primary)، جدولی را ایجاد می کنیم:

–PRIMARY:

[oracle@ol7 ~]$ sqlplus usef/a

SQL*Plus: Release 19.0.0.0.0 – Production on Thu Apr 4 05:22:40 2019

Version 19.2.0.0.0

Copyright (c) 1982, 2018, Oracle.  All rights reserved.

SQL> conn usef/a

Connected.

SQL> create table mytbl(id number,name varchar2(19));

Table created.

به عنوان گام بعدی، برای فعالسازی قابلیت ADG REDIRECT DML، باید پارامتر ADG_REDIRECT_DML را در محیط دیتاگارد، به مقدار TRUE تنظیم کرد:

–ADG:

SQL> alter system set ADG_REDIRECT_DML=TRUE;

System altered.

همچنین در همین محیط، اطلاعاتی را در جدول mytbl درج می کنیم:

–ADG:

SQL> select OPEN_MODE from  v$database;

OPEN_MODE

——————–

READ ONLY WITH APPLY

SQL> insert into mytbl values(1,’USEF’);

1 row created.

SQL> commit;

Commit complete.

این اطلاعات، در بانک اصلی هم قابل مشاهده هستند:

–PRIMARY:

SQL> select * from usef.mytbl;

        ID NAME

———- ——————-

         1 USEF

با اجرای دستور DMLای در محیط دیتاگارد، بلافاصله رکورد مورد نظر در دیتابیس اصلی، قفل(lock) خواهد شد:

–PRIMARY:

SQL> select SID,TYPE,CTIME from v$lock where type in (‘TM’,’TX’);

no rows selected

–ADG:

SQL> update mytbl set name=’VAID’ where name=’USEF’;

1 row updated.

–PRIMARY:

SQL> select SID,TYPE,LMODE from v$lock where type in (‘TM’,’TX’);

       SID TY      LMODE

———- — ———-

        11 TX          6

        11 TM          3

همانطور که می بینید، رکورد بصورت row exclusive قفل شده است در این صورت، با اجرای مجدد این دستور در محیط primary، دستور در حالت انتظار قرار خواهد گرفت و اصطلاحا session مورد نظر، block خواهد شد:

–PRIMARY:

SQL> select distinct sid from v$mystat;

       SID

———-

       387

SQL> update mytbl set name=’VAID’ where name=’USEF’;

waiting….

با رجوع مجدد به ویوی v$lock، شاهد block شدن sessionای که دستور را در دیتابیس اصلی اجرا کرده است، خواهیم بود:

–PRIMARY:

SQL>  select SID,TYPE,LMODE,BLOCK,REQUEST from v$lock where type in (‘TM’,’TX’);

       SID TY      LMODE      BLOCK    REQUEST

———- — ———- ———- ———-

        11 TX          6          1          0

       387 TX          0          0          6

        11 TM          3          0          0

       387 TM          3          0          0

با در نظر داشتن این مسئله، بدیهی است که اگر در حین اجرای دستور DMLای در محیط دیتاگارد، بانک اصلی در دسترس نباشد، عملیات با خطا متوقف خواهد شد:

–ADG:

SQL> insert into mytbl values(2,’ALI’);

ORA-16397: statement redirection from Oracle Active Data Guard standby database to primary database failed

همچنین اگر دیتابیس اصلی در حین اجرای دستور commit از دسترس خارج شود، مجددا با خطا مواجه خواهیم شد:

–ADG:

SQL> insert into mytbl values(2,’ALI’);

1 row created.

SQL> commit;

ORA-03150: end-of-file on communication channel for database link

ORA-02063: preceding line from ADGREDIRECT

در قسمت زیر سرعت اجرای دستورات DMLای را در دو محیط Primary و Data Guard ملاحظه می کنید:

–PRIMARY:

SQL> create table prim_tbl as select * from sys.source$ where 1=2;

Table created.

SQL> create table adg_tbl as select * from sys.source$ where 1=2;

Table created.

–PRIMARY:

SQL> set timing on

SQL> insert into prim_tbl  select * from sys.source$;

295279 rows created.

Elapsed: 00:00:02.73

SQL> commit;

Commit complete.

Elapsed: 00:00:00.00

–ADG:

SQL> set timing on

SQL> insert into adg_tbl select * from sys.source$;

295279 rows created.

Elapsed: 00:00:02.53

SQL> commit;

Commit complete.

Elapsed: 00:00:01.06

همانطور که می بینید، اجرای دستور commit، در محیط دیتاگارد، نسبتا کندتر انجام می شود(حدودا 1 ثانیه!) ولی بین زمان اجرای دو دستور insert، تفاوت فاحشی وجود ندارد. البته بسیار روشن است که بستر محیطی هم در این زمینه، بسیار اثرگذار خواهد بود.