خصیصه CONTAINER_DATA در محیط CDB

به صورت پیش فرض common userها در محیط root container مجاز به مشاهده اطلاعات pdb containerها نیستند و حتی با داشتن مجوز select بر روی ویوهای _V$،  GV$، CDB، نمی توانند اطلاعات containerهای دیگر را ببینید(البته common userهای ORACLE_MAINTAINED=N منظور است):

SQL> create user c##usef identified by a;

User created.

SQL> grant create session to c##usef;

Grant succeeded.

SQL> grant select on v_$session to c##usef;

Grant succeeded.

SQL> conn c##usef/a

Connected.

SQL> show con_name

CON_NAME

——————————

CDB$ROOT

SQL> select distinct con_id from v$session;

    CON_ID

———-

         1

         0

(بیشتر…)

اوراکل 19c – دو بهبود جزیی در TDE

بهبود اول: از اوراکل 12cR2 می توان tablespaceهای سیستمی نظیر SYSTEM، SYSAUX، UNDO و حتی TEMP را در حالت encrypt قرار داد:

SQL> alter system set db_create_file_dest=’/oracle/mydata/’;

System altered.

SQL> alter tablespace system encryption online encrypt;

Tablespace altered.

پس از قرار دادن system tbs در حالت encrypt، اگر بخواهیم فایل wallet را در حالت close قرار دهیم، دستور با خطای زیر متوقف خواهد شد:

Version 18.3.0.0.0

SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY  p;

ORA-28439: cannot close wallet when SYSTEM, SYSAUX, UNDO, or TEMP tablespaces are encrypted

(بیشتر…)

پیکربندی TDE در اوراکل 19c و 18c

نحوه پیکربندی TDE در اوراکل نسخه 11g و 12c را قبلا مورد بررسی قرار دادیم و در این متن قصد داریم به پیکربندی TDE در اوراکل 18c و 19c بپردازیم.

کانفیگ TDE در اوراکل نسخه 19c، تفاوت زیادی با نسخه 12c ندارد و مشابه نسخه های قبلی، مسیر فایل (wallet(keystore را می توان با کمک پارامترENCRYPTION_WALLET_LOCATION  در فایل sqlnet.ora تنظیم کرد.

البته در کنار این پارامتر، اوراکل از نسخه 18c، دو پارامتر با نامهای tde_configuration و wallet_root را هم اضافه کرده و توصیه می کند که به جای استفاده از پارامتر SQLNET.ENCRYPTION_WALLET_LOCATION، از این دو پارامتر استفاده شود و اصطلاحا SQLNET.ENCRYPTION_WALLET_LOCATION را deprecate کرده است.

(بیشتر…)

تست قسمتی از عملیات TTS بدون down time(اوراکل 19c)

برای انجام عملیات Transportable Tablespaces، باید در زمان اجرای دستور expdp و انتقال دیتافایلهای tablespace به سرور مقصد(و یا تهیه بکاپ از دیتافایلها)، tablespace را در حالت read only قرار داد(در دیتابیس مبدا) و اگر در حین اجرای دستور expdpء، tablespace در حالت read write(online) قرار داشته باشد، دستور با خطای زیر متوقف خواهد شد:

ORA-29335: tablespace ‘TBS01’ is not read only

Job “SYS”.”SYS_EXPORT_TRANSPORTABLE_01″ stopped due to fatal error at Wed Jan 20 10:32:48 2021 elapsed 0 00:00:14

(بیشتر…)

سناریوی عملی برای مشاهده نقش CLUSTERING_FACTOR خوب و بد

در مبحث “آشنایی با Clustering Factor در اوراکل” مطالبی را در مورد CLUSTERING_FACTOR ارائه دادیم در این مطلب قصد داریم با چند مثال عملی را در این زمینه ارائه کرده و در پایان، هزینه استفاده از ایندکس را برای هر دو حالت با هم مقایسه خواهیم کرد.

 

مثال 1(CLUSTERING_FACTOR بد): قصد داریم با اجرای پرس و جوی زیر، اطلاعاتی از جدول badcftable را در خروجی نمایش دهیم:

SQL> Select * from badcftable where code=2;

(بیشتر…)

مروری کوتاه بر چند نکته در مورد Interval Partitioning

با ارائه قابلیت Interval partitioning در اوراکل نسخه 11g، نیاز به اضافه کردن دستی پارتیشن، در هنگام درج اطلاعات خارج از محدوده از بین رفته است. در این متن به صورت خلاصه نکاتی را در مورد Interval Partitioning مرور خواهیم کرد.

(بیشتر…)

نکاتی در مورد حداکثر طول کاراکتر ORACLE_SID

همانطور که می دانید، متغیر محیطی ORACLE_SID، نام instance اوراکل را مشخص می کند:

 [oracle@Primary ~]$ echo $ORACLE_SID

sid

SQL> select INSTANCE_NAME from v$instance;

INSTANCE_NAME

—————-

sid

در این متن نکاتی را در مورد حداکثر طول کاراکتر ORACLE_SID و نام instance ارائه خواهیم کرد.

در زمان کار با ابزار netmgr، امکان استفاده از sid با طول بیشتر از 8 کاراکتر وجود ندارد و در صورت تنظیم با خطای زیر مواجه خواهیم شد:

(بیشتر…)

user و schema در پستگرس و اوراکل

همانطور که می دانید، user به منظور اتصال و مدیریت دیتابیس ایجاد می شود و schema هم مجموعه ای از objectها نظیر جدول، ایندکس، ویو و … تحت یک نام می باشد در این مطلب تفاوتهای user و schema را در دو دیتابیس پستگرس و اوراکل تشریح خواهیم کرد.

در دیتابیس اوراکل، با ایجاد user، به صورت خودکار schema هم ایجاد خواهد شد و به عبارتی دقیق تر، با ایجاد اولین object برای یک user، به آن user، اسکیما(schema) هم گفته می شود و دستور مجزایی برای ساخت schema وجود ندارد.

البته دستور CREATE SCHEMA که در اوراکل وجود دارد عملا schemaای را ایجاد نخواهد کرد و صرفا امکان ساخت چندین شی را از طریق یک دستور فراهم می سازد برای مثال با توجه به آنکه کاربر usef2 در دیتابیس موجود نیست، دستور زیر با خطا متوقف خواهد شد:

SQL> create schema authorization usef2

create table t1 (c1 number)

create table t2 (c2 number); 

ORA-02421: missing or invalid schema authorization identifier

(بیشتر…)

SMON و Transaction Recovery

همانطور که در مطلب Direct path vs Conventional insert بیان شد، زمانی که با اجرای دستور DMLای، تغییری را در جدولی ایجاد می کنیم، قبل از اجرای دستور commit، اوراکل بلاکهای جدول را به حافظه منتقل کرده و سپس اطلاعات جدید تایید نشده را در این بلاکها درج/حذف/اصلاح می کند(در حالت Conventional) همچنین شکل قبلی رکوردها در undo segment و یا rollback segment ثبت خواهد شد.

(بیشتر…)

نکاتی در مورد حذف ستون از جدول

زمانی  که دستور drop column را اجرا می کنیم، اوراکل باید تمامی بلاکهای جدول را به حافظه منتقل کرده و اطلاعات مربوط به ستون را از همه رکوردهای حاضر در بلاک حذف کند.

در کنار عملیات I/O و پردازش رکورد، جدول هم به صورت exclusive قفل خواهد شد و مضاف بر آن، حدف ستون منجر به ایجاد redo و undo هم می شود. در نتیجه حذف ستون از یک جدول حجیم می تواند کار بسیار پرهزینه و زمانبری باشد.مثال زیر را ببینید:

(بیشتر…)