……..آموزش، مشاوره و پشتیبانی…….
برای نمایش اطلاعات JSON به صورت relational و همچنین map کردن elementهای استفاده شده در JSON Documentها به یک نوع داده مشخص، می توان از تابع JSON_TABLE استفاده کرد.
به عنوان مثال، در ادامه خواهیم دید که چگونه می توان با کمک تابع JSON_TABLE برای هر کدام از elementهای موجود در JSON Document جدول myt، نوع داده ای تعریف کرد و این اطلاعات را با ساختار رابطه ای نمایش داد.
قصد داریم اطلاعات موجود در جدول non_JSON_tbl را به فرمت JSON نمایش دهیم:
SQL> create table non_JSON_tbl(id number,first_name varchar2(100),Last_Name varchar2(100),Email varchar2(100),phone number(12));
Table created
SQL> insert into non_JSON_tbl values(1,’Vahid’,’Usefzadeh’,’vahidusefzadeh@gmail.com’,’09128110897′);
1 row inserted
SQL> commit;
Commit complete
برای این کار می توانیم از تابع JSON_OBJECT استفاده کنیم:
SELECT id,
JSON_OBJECT(KEY ‘Name‘ VALUE t.first_name,
KEY ‘LastName‘ VALUE t.Last_Name) JSON_CONVERT
FROM non_JSON_tbl t;
ID JSON_CONVERT
———- —————————————–
1 {“Name”:”Vahid”,”LastName”:”Usefzadeh”}
برای نمایش خروجی در دو ستون مجزا می توان کوئری را به صورت زیر نوشت:
SELECT id,
JSON_OBJECT(KEY ‘Name‘ VALUE t.first_name) JSON_CONVERT1,
JSON_OBJECT(KEY ‘LastName‘ VALUE t.Last_Name) JSON_CONVERT2
FROM non_JSON_tbl t;
ID JSON_CONVERT1 JSON_CONVERT2
— —————– ————————–
1 {“Name”:”Vahid”} {“LastName”:”Usefzadeh”}
همانطور که می دانید، زمانی که دیتابیس در حالت read only قرار دارد امکان ثبت اطلاعات در جداول دیتادیکشنری از بین خواهد رفت این قاعده برای جداول مربوط به auditing(نظیر aud$unified) هم صادق است از اینرو نمی توان عملیات انجام شده توسط کاربران را در دیتابیس ذخیره کرد.
در این شرایط، در صورت استفاده از قابلیت Unified auditing، اوراکل auditهای انجام شده را در محیط سیستم عامل ثبت خواهد کرد.
عملیات انجام شده توسط کاربران در قالب فایلهای باینری، با پسوند bin. و در مسیر ORACLE_BASE/audit/$ORACLE_SID$ ثبت خواهند شد و امکان مشاهده محتویات این فایلهای باینری از طریق ویوی unified_audit_trail فراهم می شود.
ممکن است در شرایطی بخواهید صرفا فرم پارس شده یکی از دستورات را از حافظه خارج کنید، در این صورت می توانید از بسته DBMS_SHARED_POOL.PURGE استفاده کنید.
SQL>select ADDRESS, HASH_VALUE,sql_text from V$SQLAREA where SQL_TEXT like ‘%delete mytbl where %’ and SQL_TEXT not like ‘%v$sql%’;
SQL> exec sys.DBMS_SHARED_POOL.PURGE ‘00000000774B91E0,3503309987′,’C’);
PL/SQL procedure successfully completed
SQL>select ADDRESS, HASH_VALUE,sql_text from V$SQLAREA where SQL_TEXT like ‘%delete mytbl where %’ and SQL_TEXT not like ‘%v$sql%’;
no rows selected
توجه: پارامتر دوم در پروسیجر Purge(کارکتر C)، به نوع object اشاره دارد که علامت اختصاری objectها را در قسمت زیر می بینید:
–P package/procedure/function –JS java source
–Q sequence –JC java class
–R trigger –JR java resource
–T type –JD java shared data
همانطور که می دانیم ساختار زبان PL/SQL بر پایه بلاک(BLOCK) است یعنی برنامه های PL/SQL به قسمت هایی از کد به نام بلاک تقسیم بندی می شوند. در ادامه اجزای یک بلاک را توضیح می دهیم.
همانطور که می دانید ایجاد دستی و یا خودکار Auxiliary Instance در زمان انجام عملیاتی چون Duplicate، PDB Point-in-Time Recovery، Table Point-in-Time Recovery و … الزامی می باشد البته با انجام هر کدام از این عملیاتها، Auxiliary Instance حذف خواهد شد و امکان استفاده از استفاده از این instance به صورت کلی از بین خواهد رفت.
در گزارش AWR و همچنین ویوهایی نظیر V$SQLه، elapsed_timeای که برای parallel queryها نمایش داده می شود، جمع بین زمان سپری شدهquery coordinator و parallel query slaveها می باشد از این جهت، نباید این عدد را با elapsed_time واقعی پرس و جو اشتباه گرفت.
مثال زیر را ببینید:
SQL> select /*+parallel(3)*/ sum(id),sum(code),avg(count) from usef.myview;
SUM(ID) SUM(CODE) AVG(COUNT)
———- ———- ———-
713031680 3548381184 68.1508522
Elapsed: 00:01:18.89
SQL> /
SUM(ID) SUM(CODE) AVG(COUNT)
———- ———- ———-
713031680 3548381184 68.1508522
SQL> /
Elapsed: 00:01:17.08
SQL> /
SUM(ID) SUM(CODE) AVG(COUNT)
———- ———- ———-
713031680 3548381184 68.1508522
Elapsed: 00:01:17.94
پس از اجرای دستورات فوق، در گزارش AWR خواهیم دید که Elapsed Time برای query اجرا شده برابر با 228 ثانیه می باشد در صورتی که این query در مدت زمان80 ثانیه(حدودا) اجرا شده است:
SQL(مخفف STRUCTURED QUERY LANGUAGE) یک زبان قدرتمند ولی ساده برای کار با بانک های اطلاعاتی است. SQL در ابتدا توسط شرکت IBM پیاده سازی شده است. در ادامه موسسه جهانی استاندارد، زبان SQL را به عنوان یک زبان رابطه ای برای کار با دیتابیس های از نوع رابطه ای تعیین کرده است. بنابراین زبان SQL به طور کامل مطابق با استانداردهای جهانی است.
از اوراکل 19c با اجرای دستور flashback database و یا انجام عملیات point in time recovery در محیط دیتابیس اصلی(primary)؛ دیتاگارد هم به صورت خودکار flashback خواهد شد و از حالت sync با primary خارج نمی شود(البته در صورت فعال بودن قابلیت flashback). این قابلیت با کمک پارامتر مخفی standby_auto_flashback_ قابل مدیریت است.
در ادامه متن زیر، با اجرای دستور flashback database و همچنین انجام PITR در محیط primary، رفتار دیتاگارد را در دو نسخه 18c و 19c مقایسه می کنیم.
گاهی اوقات در اجرای دستورات پیچیده SQL نیاز به نگه داری موقت اطلاعات برای محاسبه نتایج نهایی می باشد که می توان در این مواقع از جدول های TEMPORARY در دیتابیس اوراکل کمک گرفت. استفاده از این جدول ها می تواند سبب افزایش سرعت اجرای دستورات SQL شود. این جداول با نام مخفف GTT(GLOBAL TEMPORARY TABLE) شناخته می شوند.