تغییر Execution Plan یک کوئری می تواند به دلایل ساده ای مثل حذف و اضافه کردن ایندکس، پارتیشن بندی جدول، پارتیشن بندی ایندکس اتفاق بیفتد اما شناسایی علت تغییر رفتار Optimizer همیشه ساده نیست چرا که در بعضی از موارد تغییر در Optimizer Environment منجر به ایجاد Execution Plan جدید می شود.

برای مثال در sessionای پارامتر OPTIMIZER_INDEX_COST_ADJ که میزان گرایش Optimizer به استفاده از ایندکس را تعیین می کند، به عدد 1 و در session دیگر این پارامتر به مقدار 1000! تنظیم شده است بدون تردید این تفاوت ها در Optimizer Environment، می تواند Execution Plan بعضی از کوئری ها را تغییر دهد.

موضوع این مستند در مورد آن است که چگونه می توانیم تشخیص دهیم تغییر Execution Plan یک کوئری به دلیل تغییر در Optimizer Environment است؟ و به طور دقیق تر، کدام پارامترها و عوامل محیطی منجر به ایجاد Execution Plan جدید شده اند. این کار را با قابلیت جدیدی که اوراکل در نسخه 23c ارائه کرده است، انجام خواهیم داد.

(بیشتر…)

در نسخه 21c اگر در تراکنشی از Parallel DML استفاده کنیم، امکان گرفتن query و یا اجرای دستورات DML و یا Parallel DML بر روی همان جدول و در همان تراکنش از ما گرفته خواهد شد:

SQL> alter session enable parallel dml;
Session altered.

SQL> insert /*+parallel(10)*/ into tbl1 select * from v$datafile;
1536 rows created.

Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.8.0.0.0

SQL> select count(*) from tbl1;
'ORA-12838: cannot read/modify an object after modifying it in parallel'
SQL> delete tbl1;
'ORA-12838: cannot read/modify an object after modifying it in parallel'

با خاتمه دادن به تراکنش شاهد این خطا نخواهیم بود:

SQL> commit;
Commit complete.

SQL> select count(*) from tbl1;
  COUNT(*)
----------
      6144

SQL> delete tbl1;
6144 rows deleted.

در نسخه 23c این محدودیت برداشته شده و بدون بستن تراکنش می توانیم دستور فوق را اجرا کنیم:

Oracle Database 23c Free Release 23.0.0.0.0 - Develop, Learn, and Run for Free
Version 23.3.0.23.09

SQL> alter session enable parallel dml;
Session altered.

SQL> insert /*+parallel(10)*/ into tbl1 select * from v$datafile;
14 rows created.

SQL> select count(*) from tbl1;
  COUNT(*)
----------
        28

SQL> delete tbl1;
28 rows deleted.

Memoptimized Rowstore Fast Ingest یکی از قابلیتهای جدید اوراکل در نسخه 19c است که می تواند در زمینه IOT بسیار کاربردی باشد قبلا در مطلبی تحت عنوان “Memoptimized Fast Ingest در اوراکل 19c“، سعی کردیم به طور مفصل این قابلیت را شرح دهیم. اوراکل در نسخه 23c بهبودهایی را در این زمینه ایجاد کرده است که موضوع این مستند خواهد بود.

پشتیبانی از Partitioning

در نسخه 19c و 21c امکان تنظیم MEMOPTIMIZE FOR WRITE برای جداول پارتیشن شده وجود نداشت:

Connected to Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 
SQL> create table TBL1
  2  (
  3    id   NUMBER not null,
  4    text VARCHAR2(3000),
  5    mydate date
  6  )
  7  SEGMENT CREATION IMMEDIATE
  8  partition by range ( mydate )
  9  interval ( numtoyminterval(1,'MONTH'))
 10  (
 11   PARTITION p1 VALUES LESS THAN (TO_DATE('1-1-2015', 'DD-MM-YYYY'))
 12  );
Table created

SQL> ALTER TABLE tbl1 MEMOPTIMIZE FOR WRITE;
ORA-62165: MEMOPTIMIZE FOR WRITE cannot be enabled on table with specified partitioning type.

این قابلیت در نسخه 23c اضافه شد:

(بیشتر…)

بروز شدن همزمان Materialized Viewهای on-commit refresh از طریق sessionهای مختلف می تواند سبب رخ دادن eventای به نام enq: JI – contention شود چرا که این نوع از MVها به طور پیش فرض به صورت سریالی بروز می شوند و امکان بروزرسانی Concurrent را ندارند.

در قسمت زیر، از طریق دو session به طور همزمان دیتایی را در جدول مرجع MV درج کرده ایم که این  مسئله سبب شد تعداد زیادی از eventهای enq: JI – contention را شاهد باشیم:

SQL> create materialized view auther_contry_mv
refresh fast on commit
as
select country,count(*) from author_tbl group by country;
Materialized view created.

Session 1:
SQL>  begin
for i in  10000 ..19999 loop
insert into author_tbl values(i,'Rahmat Rabbani','m','Oracle DBA','IRAN');
commit;
end loop;
end;
/
PL/SQL procedure successfully completed.
Elapsed: 00:03:00.18

Session 2:
begin
for i in 1 ..9999 loop
insert into author_tbl values(i,'Rahmat Rabbani','m','Oracle DBA','IRAN');
commit;
end loop;
end;
/
PL/SQL procedure successfully completed.
Elapsed: 00:03:00.25

در نسخه 23c اوراکل از طریق قابلیت Materialized View Concurrent Refresh این محدودیت از بین برده است و با استفاده از این قابلیت می توان به صورت Concurrent این نوع از MVها را بروزرسانی کرد.

(بیشتر…)