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

نویسنده مطلب: Vahid Yousefzadeh Leave a comment

بهبود اول: از اوراکل 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

(بیشتر…)

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

نویسنده مطلب: Vahid Yousefzadeh 1 Comment

برای انجام عملیات 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

(بیشتر…)

روشی برای تسریع در “حذف حجم بالای از اطلاعات یک جدول”

نویسنده مطلب: Vahid Yousefzadeh 1 Comment

شرایط جدول mtbl را در نظر بگیرید:

SQL>  select count(*) from mtbl;

16777216

SQL>  select to_char(creation_time,’YYYY’,’nls_calendar=persian’),count(*) from mtbl group by to_char(creation_time,’YYYY’,’nls_calendar=persian’) order by 1 desc;

TO_CHAR(CREATION_TIME,’YYYY’,’   COUNT(*)

—————————— ———-

1399                               262144

1397                              3932160

1396                              4194304

1395                              4194304

1394                              4194304

Executed in 4.563 seconds

حجم جدول mtbl:

SQL> select bytes/1024/1024 SIZE_MB from user_segments p where p.segment_name=’MTBL’;

   SIZE_MB

———-

      4286

قصد داریم رکوردهایی از این جدول که creation_time آنها مربوط به سال 1399 بوده را در جدول حفظ کرده و مابقی اطلاعات را حذف کنیم.

(بیشتر…)

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

نویسنده مطلب: Vahid Yousefzadeh Leave a comment

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

 

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

SQL> Select * from badcftable where code=2;

(بیشتر…)

آشنایی با Clustering Factor در اوراکل

نویسنده مطلب: Vahid Yousefzadeh 5 Comments

قصد داریم از طریق یکی از ایندکسهای جدول، به تک تک رکوردهای آن جدول دسترسی پیدا کنیم به این صورت که ابتدا آدرس فیزیکی یا همان rowid رکورد را از طریق ایندکس پیدا کرده و سپس با انتقال Data Block حاوی آن رکورد به حافظه، جدول را scan کنیم.

از آنجایی که اطلاعات در ایندکس به صورت “مرتب” ذخیره می شوند، هر چه ترتیب قرار گرفتن رکوردها در جدول مشابه ترتیب قرارگیری keyها در ایندکس باشد، نیاز به I/O کمتری خواهیم داشت و SCAN جدول از طریق ایندکس می تواند با سرعت بیشتری انجام شود.

به عبارتی دیگر اگر در یک Leaf Block پنج index entry موجود باشد، در بهترین حالت هر پنج رکورد متناظر با index entryها، در یک Data Block قرار می گیرند و در بدترین حالت، هرکدام از این رکوردها در یک بلاک مجزا در جدول ذخیره شده اند.

(بیشتر…)

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

نویسنده مطلب: Vahid Yousefzadeh Leave a comment

همانطور که می دانید، متغیر محیطی 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 کاراکتر وجود ندارد و در صورت تنظیم با خطای زیر مواجه خواهیم شد:

(بیشتر…)

اهدای مجوز در سطح اسکیما در اوراکل و پستگرس

نویسنده مطلب: Vahid Yousefzadeh 1 Comment

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

در دیتابیس پستگرس می توان به راحتی و با اجرای یک دستور مجوز دسترسی به تمامی جداول موجود در یک اسکیما را به کاربران اهدا کرد.مثال زیر را ببینید.

postgres=# \c postgres vahid

postgres=> select current_user;

 vahid

postgres=> select * from myschema.tbl1;

ERROR:  permission denied for schema myschema

خطای فوق عدم دسترسی کاربر vahid به جدول myschema.tbl1 را نشان می دهد. برای برطرف کردن این خطا، از طریق کاربر postgres که superuser هم هست به دیتابیس متصل شده و دستور زیر را اجرا می کنیم:

postgres=> \c postgres postgres

postgres=# grant usage on schema myschema to vahid;

GRANT

postgres=# GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA myschema TO vahid;

GRANT

(بیشتر…)

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

نویسنده مطلب: Vahid Yousefzadeh Leave a comment

همانطور که می دانید، 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

نویسنده مطلب: Vahid Yousefzadeh 1 Comment

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

(بیشتر…)