اوراکل 23c – پارامتر error_message_details برای نمایش جزییات خطا

نویسنده مطلب: وحید یوسف زاده Leave a comment

error_message_details یکی دیگر از پارامترهای جدید اوراکل در نسخه 23c هست که امکان نمایش جزییات خطاهای مربوط به Data Value را فراهم می کند با تنظیم این پارامتر به مقدار on، می توانیم برای خطاهایی نظیر ORA-00001: unique constraint violated، مقداری که سبب رخ دادن این دسته از خطاها شده است را در متن خطا ببینیم.

برای مثال، در سناریوی زیر، فعال بودن پارامتر error_message_details در پیدا کردن مقداری که باعث این خطا شده است کمک می کند:

SQL> create table tbl1(id number primary key);
Table created.
SQL> variable B number;
SQL> exec :B:=2547;
PL/SQL procedure successfully completed.
SQL> insert into tbl1 values(:B);
1 row created.
SQL> insert into tbl1 values(:B);
ERROR at line 1:
'ORA-00001: unique constraint (USEF.SYS_C008328) violated on table USEF.TBL1 columns (ID)'
'ORA-03301: (ORA-00001 details) row with column values (ID:2547) already exists'
Help: https://docs.oracle.com/error-help/db/ora-00001/

در صورتی که پارامتر error_message_details غیر فعال شود، خطای فوق به شکل زیر نمایش داده می شود:

SQL> alter system set error_message_details=DISALLOWED ;
System altered.
SQL> insert into tbl1 values(:B);
'ORA-00001: unique constraint (USEF.SYS_C008329) violated on table USEF.TBL1 columns (ID)'
Help: https://docs.oracle.com/error-help/db/ora-00001/

 

قابلیتهای جدید اوراکل 23c برای جداول Blockchain و Immutable

نویسنده مطلب: وحید یوسف زاده Leave a comment

در این مطلب سعی داریم تعدادی از قابلیتهای جدید اوراکل 23c در زمینه جداول Blockchain و Immutable را مرور کنیم.

امکان حذف  و اضافه کردن ستون به جداول Blockchain و Immutable

در نسخه 23c می توان به جداول Blockchain ستونی را اضافه کرد(البته در version v2 این نوع از جداول):

SQL> create blockchain table blockchaintb1 (
  id    number(10),
  desc1 varchar2(100)
)
no drop until 20 days idle
no delete until 20 days after insert
hashing using "SHA2_512" version "v2";  
Table created.

SQL> alter table blockchaintb1 add (desc2 varchar2(1000));
Table altered.

حذف ستون هم در این نسخه امکان پذیر است:

SQL>  alter table blockchaintb1 drop column desc2;
Table altered.

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

(بیشتر…)

قابلیت SQL Firewall در اوراکل 23c

نویسنده مطلب: وحید یوسف زاده Leave a comment

SQL Firewall یکی دیگر از قابلیتهای جدید اوراکل در نسخه 23c است بر اساس این قابلیت می توانیم مجموعه ای از دستورات را به عنوان دستورات مجاز برای دیتابیس تعریف کنیم در این صورت کاربر نمی تواند دستور دیگری خارج از این مجموعه را اجرا کند حتی اگر این کاربر مجوز اجرای آن دستورات را داشته باشد.

قصد داریم اقدامات کاربر Usef را تحت نظر بگیریم و تمامی دستورات اجرا شده توسط این کاربر را capture کنیم سپس با تنظیم SQL Firewall، به این کاربر اجازه ندهیم خارج از دستوراتی که capture شده اند، دستور جدیدی را اجرا کند.

(بیشتر…)

اوراکل 23c – بررسی وجود inconsistency در Data Dictionary

نویسنده مطلب: وحید یوسف زاده Leave a comment

نازسازگاری در دیتادیکشنری امر متداولی نیست و به ندرت اتفاق می افتد اما در صورت رخ دادن می تواند بسیار چالش ساز باشد نمونه ای از این دست ناسازگاری که شاید شما هم با آن روبرو شده باشید، invalid reference است مثلا segmentای که اطلاعاتش در dba_objects موجود نیست.

 تا قبل از نسخه 23c، این قبیل ناسازگاری ها را می توانستیم با اسکریپت hcheck.sql شناسایی کنیم. اما در اوراکل نسخه 23c، پکیجی به نام DBMS_DICTIONARY_CHECK(البته در 23.3) ارائه شد که با کمک آن می توانیم از consistency در دیتادیکشنری اطمینان حاصل کنیم. این پکیج پروسیجرهای متعددی دارد:

SQL> desc DBMS_DICTIONARY_CHECK

PROCEDURE CRITICAL
PROCEDURE FULL
PROCEDURE DUPLICATEDATAOBJ
PROCEDURE IDNSEQOBJ
PROCEDURE IDNSEQSEQ
PROCEDURE INDEXPARTITIONSEG
PROCEDURE INDEXSEG
PROCEDURE INDINDPARMISMATCH
PROCEDURE INDPARTOBJ
PROCEDURE LOBSEG
PROCEDURE MVIEW
PROCEDURE NEXTOBJECT
PROCEDURE NOSEGMENTINDEX
PROCEDURE OBJECTNAMES
PROCEDURE OBJERROR
….

در این بین، پروسیجر FULL می تواند اطلاعات کاملی را در زمینه درستی Data Dictionary ارائه دهد که در ادامه نمونه ای از خروجی آن را مشاهده می کنید:

(بیشتر…)

اوراکل 23c – بهبودهایی در زمینه DML RETURNING INTO

نویسنده مطلب: وحید یوسف زاده Leave a comment

از نسخه های قدیمی اوراکل امکان استفاده از عبارت RETURNING INTO به همراه دستورات DMLای وجود داشت که در قسمت زیر نحوه استفاده از آن را می بینید:

SQL*Plus: Release 10.1.0.4.2 - Production on Tue Aug 15 14:08:30 2023
SQL> select * from tbl1;
        ID NAME
---------- ----------
         1 Vahid
         2 Usef

SQL>declare
    var_id number;
    var_name varchar2(10);
  begin
  --Update
    update tbl1 set name='ALI' where id=2 returning name into var_name;
   	dbms_output.put_line('After_Update==>' || name='||var_name);
  --Delete
    delete tbl1 where id=1 returning name into var_name;
    dbms_output.put_line('Before_Delete==>' || name='||var_name);
  --Insert	
    insert into tbl1 values(3,'Reza') returning id,name into var_id,var_name;
    	 dbms_output.put_line('INSERT==> id='||var_id||' , name='||var_name);
    commit;
  end;
/        

After_Update==>name=ALI
Before_Delete==> name=Vahid
INSERT==> id=3 , name=Reza

SQL> select * from tbl1;
        ID NAME
---------- ----------
         2 ALI
         3 Reza

(بیشتر…)

اوراکل 23c – اضافه شدن کلمه کلیدی ORDERED به تابع JSON_SERIALIZE

نویسنده مطلب: وحید یوسف زاده Leave a comment

 تابع JSON_SERIALIZE در اوراکل نسخه 19c ارائه شد این تابع دیتای JSON را در هر دیتاتایپی که باشد، به صورت متن نمایش می دهد:

SQL> create table tbl_JSON (id number,ettelaat BLOB constraint jc1 check (ettelaat is json) );
Table created
SQL> insert into tbl_JSON values(2,'{"First_Name":"Vahid","Last_Name":"Usefzadeh","Contact":{"Email":"vahidusefzadeh@gmail.com","Phone":"091111111117"}}');
1 row inserted

SQL> select ETTELAAT from tbl_JSON;
ETTELAAT
-----------------------------------
7B2246697273745F4E616D65223A225661686964222C224C6173745F4E616D65223A22557365667A61646568222C22436F6E74616374223A7B22456D61696C223A227661686964757365667A61646568

(بیشتر…)

قابلیت Shrink کردن Bigfile tablespace در اوراکل 23c

نویسنده مطلب: وحید یوسف زاده Leave a comment

از نسخه های قدیمی اوراکل امکان resize کردن دیتافایلها وجود دارد:

SQL*Plus: Release 10.1.0.4.2 - Production on Tue Nov 21 11:15:16 2023
SQL> select bytes/1024/1024 SIZE_MB from v$datafile where file#=29;
   SIZE_MB
----------
      1024
SQL> alter database datafile 29 resize 120m;
Database altered.
SQL> select bytes/1024/1024 SIZE_MB from v$datafile where file#=29;
   SIZE_MB
----------
       120

البته resize کردن دیتافایلها همیشه با موفقیت انجام نمی شود و بعضا با آزاد بودن درصد بالایی از فضای دیتافایل، به دلیل قرار گرفتن بعضی از بلاکهای segment بر سر High Water Mark، امکان کاهش سایز دیتافایل وجود ندارد و در این حالت به خطای زیر برخواهیم خورد:

SQL> alter database datafile 1 resize 10m;
ORA-03297: file contains used data beyond requested RESIZE value

برای جلوگیری از خطای ORA-03297، باید segmentای که بر سر راه High Water Mark قرار دارد را جابجا کنیم! که البته قبلا در مطلبی به طور مفصل این مسئله را بررسی کردیم و از تکرار آن خودداری می کنیم.

مسئله ای که در این متن به آن خواهیم پرداخت، موضوع shrink کردن در سطح tablespaceها است. در نسخه 11g امکان shrink کردن Temporary tablespaceها به وجود آمد:

SQL*Plus: Release 11.2.0.4.0 Production on Tue Nov 21 10:35:57 2023
SQL> select FILE#,BYTES/1024/1024 from v$tempfile where file#=5;
     FILE# BYTES/1024/1024
---------- ---------------
         5            5120
SQL> ALTER TABLESPACE Temp_TBS SHRINK SPACE KEEP 340m;
Tablespace altered.
SQL> select FILE#,BYTES/1024/1024 from v$tempfile where file#=5;
     FILE# BYTES/1024/1024
---------- ---------------
         5             340

و نهایتا در نسخه 23c اوراکل این امکان را برای Bigfile Tablespaceها ارائه کرده است این کار با استفاده از پروسیجر dbms_space.tablespace_shrink امکان پذیر است که در ادامه نحوه استفاده از آن را شرح خواهیم داد.

(بیشتر…)

اوراکل 23c – استفاده از پروسیجر JSON_TYPE_CONVERTIBLE_CHECK برای جابجایی دیتای JSON

نویسنده مطلب: وحید یوسف زاده Leave a comment

اوراکل در نسخه 21c دیتاتایپ JSON را ارائه کرد و تا قبل از آن، دیتای JSON را می توانستیم در ستونهایی با نوع داده CLOB، BLOB و حتی VARCHAR ذخیره کنیم با این اوصاف اگر دیتابیس را به تازگی به نسخه 21c(و نسخ بالاتر) ارتقا دادیم ممکن است بخواهیم دیتای از نوع JSON را به ستونی که دیتاتایپ آن JSON است منتقل کنیم.

در نسخه 23c، پروسیجری اضافه شده است که می تواند در این فرایند مورد استفاده قرار بگیرد و بعضا بسیار راهگشا باشد. پروسیجر dbms_json.json_type_convertible_check ستونی را به عنوان ورودی می گیرد و بررسی می کند همه فیلدهای آن ستون حاوی دیتای معتبر با فرمت JSON هستند و اگر در این بررسی خطایی رخ دهد این خطا از طریق جدول json_data_precheck قابل مشاهده است.

(بیشتر…)

اوراکل 23c – شناسایی علت تغییر رفتار Optimizer با استفاده از ویوی DBA_HIST_OPTIMIZER_ENV_DETAILS

نویسنده مطلب: وحید یوسف زاده Leave a comment

تغییر 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 ارائه کرده است، انجام خواهیم داد.

(بیشتر…)

امکان جستجو در سطح کل دیتابیس با DBMS_SEARCH – اوراکل 23c

نویسنده مطلب: وحید یوسف زاده Leave a comment

در نسخه 23c، اوراکل پکیجی را به نام DBMS_SEARCH معرفی کرده است که می تواند با استفاده از زیرساخت ORACLE TEXT و حذف پیچیدگی های آن، امکان جستجو را بر روی Objectهای مختلف فراهم کند. پکیج DBMS_SEARCH با ایجاد ایندکسی از نوع JSON Search Index می تواند قابلیت جستجو را بر روی sourceهای مختلف اعم از Table و View فراهم کند.

برخلاف ایندکسهای متعارف نظیر Btree و Bitmap که بر روی ستونهای یک جدول قابل ایجاد هستند، ایندکسی که از طریق پکیج DBMS_SEARCH ایجاد می شود، می تواند چندین جدول و ویو را به عنوان source بپذیرد و جستجوی همزمان را بر روی این sourceها انجام دهد.

جداولی که به عنوان سورس تعیین می شوند می توانند حاوی ستونهایی با نوع داده number، varchar، CLOB، JSON و … باشند و محدودیتهای بسیاری کمی در این زمینه وجود دارد ضمنا اضافه کردن source به ایندکس به راحتی و صرفا با اجرای یک دستور امکان پذیر است.

توجه! ایندکسهایی که از طریق این پکیج ایجاد می شوند، بروزرسانی آنها به صورت خودکار انجام می شود(sync on commit).

(بیشتر…)