auto indexing یکی از قابلیتهای مهم اوراکل نسخه 19c است که در مورد این قابلیت، پیشتر مطلبی را نوشتیم(ویژگی Automatic Indexing در اوراکل 19c). در این متن به برخی از محدودیتهای این قابلیت در نسخه 19c خواهیم پرداخت البته بسیار روشن است که در نسخه های آتی اوراکل ممکن است این محدودیتها برطرف شود بنابرین باید توجه داشته باشید که سناریوهای موجود در متنی که در حال مطالعه آن هستید، در نسخه 19c(بطور دقیق تر 19cR8) تست شده است.
محدود کردن رکوردها با کمک ROWNUM ، ROW_NUMBER و FETCH
برای نمایش تعداد محدودی رکورد از خروجی یک پرس و جو، می توان از توابعی چون ROW_NUMBER، rank و همچنین Pseudo columnای بنام rownum استفاده کرد. البته در اوراکل نسخه 12c هم بهبودهای در این زمینه ایجاد شد و در این نسخه با استفاده از عبارت FETCH هم می توان به این هدف رسید. در ادامه متن با هر سه این روشها آشنا خواهیم شد.
خصیصه 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
تست قسمتی از عملیات 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
روشی برای تسریع در “حذف حجم بالای از اطلاعات یک جدول”
شرایط جدول 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 بوده را در جدول حفظ کرده و مابقی اطلاعات را حذف کنیم.
مصاحبه با موضوع آشنایی با سرویس کلود آمازون
مصاحبه با مهندس صابر طلازاده با موضوع آشنایی با سرویس کلاد آمازون(AWS) را می توانید از طریق لینک زیر مشاهده کنید:
سناریوی عملی برای مشاهده نقش CLUSTERING_FACTOR خوب و بد
در مبحث “آشنایی با Clustering Factor در اوراکل” مطالبی را در مورد CLUSTERING_FACTOR ارائه دادیم در این مطلب قصد داریم با چند مثال عملی را در این زمینه ارائه کرده و در پایان، هزینه استفاده از ایندکس را برای هر دو حالت با هم مقایسه خواهیم کرد.
مثال 1(CLUSTERING_FACTOR بد): قصد داریم با اجرای پرس و جوی زیر، اطلاعاتی از جدول badcftable را در خروجی نمایش دهیم:
SQL> Select * from badcftable where code=2;
آشنایی با Clustering Factor در اوراکل
قصد داریم از طریق یکی از ایندکسهای جدول، به تک تک رکوردهای آن جدول دسترسی پیدا کنیم به این صورت که ابتدا آدرس فیزیکی یا همان rowid رکورد را از طریق ایندکس پیدا کرده و سپس با انتقال Data Block حاوی آن رکورد به حافظه، جدول را scan کنیم.
از آنجایی که اطلاعات در ایندکس به صورت “مرتب” ذخیره می شوند، هر چه ترتیب قرار گرفتن رکوردها در جدول مشابه ترتیب قرارگیری keyها در ایندکس باشد، نیاز به I/O کمتری خواهیم داشت و SCAN جدول از طریق ایندکس می تواند با سرعت بیشتری انجام شود.
به عبارتی دیگر اگر در یک Leaf Block پنج index entry موجود باشد، در بهترین حالت هر پنج رکورد متناظر با index entryها، در یک Data Block قرار می گیرند و در بدترین حالت، هرکدام از این رکوردها در یک بلاک مجزا در جدول ذخیره شده اند.
نکاتی در مورد حداکثر طول کاراکتر 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 کاراکتر وجود ندارد و در صورت تنظیم با خطای زیر مواجه خواهیم شد:
