مستثنی کردن اطلاعات ستونهای از نوع LOB در دیتاپامپ

قصد داریم از جدولی که بعضی از ستونهای آن حاوی اطلاعات LOB است دامپی را تهیه کنیم، منتها با توجه به حجم بالایی که اطلاعات LOB در این جدول دارند و همچنین به دلایل دیگری چون سرعت بیشتر، امنیت و یا تخصیص فضای کمتر، تصمیم داریم مانع از ثبت این اطلاعات در دامپ شده و یا حداقل در زمان import از برگرداندن این اطلاعات ممانعت کنیم.

راهکار چیست؟

مستثنی کردن اطلاعات ستونهای از نوع LOB در زمان انجام عملیات export از اوراکل نسخه 12c به راحتی قابل کنترل است این کار با ایجاد ویو و استفاده از پارامتر views_as_tables قابل انجام است اما برای برگرداندن دامپ حاوی اطلاعات LOB، نمی توان از این راهکار استفاده کرد و در این صورت استفاده از پارامتر REMAP_DATA راهگشا خواهد بود.

(بیشتر…)

KEEP AUXILIARY در اوراکل 19c

همانطور که می دانید ایجاد دستی و یا خودکار Auxiliary Instance در زمان انجام عملیاتی چون Duplicate، PDB Point-in-Time Recovery، Table Point-in-Time Recovery و … الزامی می باشد البته با انجام هر کدام از این عملیاتها، Auxiliary Instance حذف خواهد شد و امکان استفاده از استفاده از این instance به صورت کلی از بین خواهد رفت.

(بیشتر…)

نکته ای در مورد elapsed_time برای parallel queyها

در گزارش 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 ثانیه(حدودا) اجرا شده است:

 

GLOBAL TEMPORARY TABLE در دیتابیس اوراکل

گاهی اوقات در اجرای دستورات پیچیده SQL نیاز به نگه داری موقت اطلاعات برای محاسبه نتایج نهایی می باشد که می توان در این مواقع از جدول های TEMPORARY در دیتابیس اوراکل کمک گرفت. استفاده از این جدول ها می تواند سبب افزایش سرعت اجرای دستورات SQL شود. این جداول با نام مخفف GTT(GLOBAL TEMPORARY TABLE) شناخته می شوند.

(بیشتر…)

External Table و In-Memory – اوراکل 18c

تا قبل از اوراکل 18c، امکان استفاده از قابلیت in memory برای جداول از نوع external وجود نداشت:

SQL*Plus: Release 12.2.0.1.0 Production on Mon May 18 12:05:36 2020

SQL> alter table mytbl inmemory;

ORA-30657: operation not supported on external organized table

این قابلیت در اوراکل 18c برای محیط exadata ارائه شد.

Connected to Oracle Database 18c Enterprise Edition Release 18.0.0.0.0

 SQL> alter table mytbl inmemory;

ORA-12755: Feature In-Memory External Tables is disabled due to unsupported capability.

SQL> alter system set “_exadata_feature_on”=true scope=spfile;

System altered.

SQL> startup force;

SQL> alter table mytbl inmemory;

Table altered

SQL> SELECT table_name, inmemory, inmemory_compression FROM user_external_tables;

TABLE_NAME   INMEMORY    INMEMORY_COMPRESSION

———–  ———  ———————-

MYTBL        ENABLED        FOR QUERY LOW

(بیشتر…)

pin کردن object در shared pool

می دانیم که shared pool فرم پارس شده دستورات sql و pl/sql را در صورت دارا بودن فضای کافی در خود نگهداری می کند و نسخه قابل اجرای دستورات، در این قسمت از حافظه باقی خواهند ماند تا در صورت اجرای مکرر یک دستور، از کامپایل مجدد آن و یا به بیانی دقیق تر، از انجام عملیات hard pars جلوگیری شود.

فرض کنید به دلایلی چون عدم استفاده از bind variable در قسمتی از برنامه، فضای خالی ای در shared pool باقی نمانده است در این صورت، اوراکل فرمهای پارس شده را بر اساس الگوریتم LRU از حافظه خارج خواهد کرد این مسئله ممکن است سبب age out شدن objectهای سیستمی و یا applicationای شود که به کررات مورد دستیابی قرار می گیرند.

با در نظر داشتن این مسئله، قصد داریم به این سوال پاسخ دهیم که چگونه می توان این objectها را در shared pool سنجاق کرد تا الگوریتم LRU نتواند آنها را برای خروج از shared pool انتخاب کند.

(بیشتر…)

آشنایی با مفاهیم tablespaceها در اوراکل(قسمت اول)

Tablespace بزرگترین واحد منطقی تقسیم بندی اطلاعات در پایگاه داده اوراکل می باشدکه از دید منطقی شامل یک یا چند سگمنت و از لحاظ فیزیکی نیز دارای یک یا چند دیتافایل می باشد .

(بیشتر…)

پارامترهای INCLUDE، EXCLUDE و QUERY در expdp/impdp

در زمان استفاده از Data Pump، می توان در چهار سطح FULL/TABLESPACE/SCHEMA/TABLES عملیات export/import را انجام داد در مواردی ممکن است نیاز باشد تا objectهای خاصی را مستثنی کرد و یا صرفا بعضی از این objectها را در این عملیات شرکت داد، در این صورت می توان از سه پارامتر INCLUDE، EXCLUDE و QUERY استفاده کرد که در ادامه به بررسی آنها می پردازیم.

(بیشتر…)

ایجاد و مدیریت job با کمک بسته DBMS_SCHEDULER

برای انجام زمانبندی در سطح دیتابیس، دو بسته با نامهای dbms_job و dbms_scheduler موجود می باشند که بسته dbms_job از نسخه های قدیمی اوراکل ارائه شده و در نسخه های جدید هم کماکان مورد استفاده قرار می گیرد و بسته dbms_scheduler که در نسخه جدیدتر اوراکل عرضه شد، توانست تا حدود زیادی جایگزین مناسبی برای بستهdbms_job باشد.

در این متن، قصد داریم به بسته dbms_scheduler بپردازیم.

(بیشتر…)