……….آموزش، مشاوره و پشتیبانی……….
در اوراکل نسخه 21c، قابلیتهای جدیدی در زمینه transportable tablespace export/import ارائه شد که در ادامه متن به این قابلیتها خواهیم پرداخت.
بهبود اول: عملیات TTS export/import را نمی توان در نسخه 19c به صورت parallel اجرا کرد:
Connected to: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 – Production
ORA-39002: invalid operation
ORA-39047: Jobs of type TRANSPORTABLE cannot use multiple execution streams.
در نسخه 21c و در زمان اجرای gridSetup.sh می توان با استفاده از پارامتر switchGridHome، بین Grid Infrastructure Home در حال اجرا و Grid Infrastructure Homeای که بر روی آن patch اعمال شده، جابجا شد. برای مثال، با کمک این قابلیت جدید می توان از Grid Infrastructure(GI) نسخه 21.3 به GI نسخه 21.4 سوییچ کرد که در ادامه نحوه انجام ان را توضیح داده ایم.
*قبل از شروع سناریو، به خاطر داشته باشید که Grid Infrastructure نسخه 21.3 از قبل نصب شده و در حال سرویس دهی است.
**در قدم اول، در کنار نسخه در حال اجرا، مسیری را برای نصب Grid Infrastructure جدید ایجاد می کنیم و patch مربوط به 21.4 RU را در دایرکتوری ای که کاربر grid به آن دسترسی دارد، unzip می کنیم:
[root@Olinux8 ~]# mkdir -p /grid21cR4/home
[root@Olinux8 ~]# chown -R grid.oinstall /grid21cR4
[grid@Olinux8 ~]$ cd /grid21cR4/home
[grid@Olinux8 home]$ unzip /source/21cR3/LINUX.X64_213000_grid_home.zip
[grid@Olinux8 home]$ unzip /source/p6880880_210000_27_Linux-x86-64.zip
[grid@Olinux8 ~]$ unzip /source/21cR4/21cR4_p33250101_210000_Linux-x86-64.zip -d /home/grid
همانطور که می دانید یکی از وظایف روزانه DBA، چک کردن پیامهای ثبت شده در Alert Log است بررسی محتویات این فایل به ویژه در زمان troubleshooting، نباید توسط DBA نادیده گرفته شود چرا که بعضا خطاها به وضوح در این فایل ثبت می شوند البته علاوه بر خطاها، پیامهای دیگری نظیر log switchها هم در این فایل موجود هستند که ممکن است سبب افزایش حجم و در نتیجه افزایش زمان پیمایش و جستجو در این فایل شوند.
اوراکل در نسخه 21c در کنار فایل alert log، فایل دیگری را با عنوان attention log ایجاد می کند که در ان پیامهای با درجه اهمیت بالاتر در دسته بندی های مختلف وفرمتی خواناتر(نسبت به alert log) ثبت می شوند تا DBA بتواند سریعتر متوجه بعضی از وقایع مهم شود. نمونه ای از این پیامها را در قسمت زیر مشاهده می کنید:
[root@oLinux7 trace]# less attention_db21c.log
{
“ERROR” : “DBW0 (ospid: 21898): terminating the instance due to ORA error 472“,
“URGENCY” : “IMMEDIATE“,
“INFO” : “Additional Information Not Available”,
“CAUSE” : “The instance termination routine was called”,
“ACTION” : “Check alert log for more information relating to instance termination rectify the error and restart the instance”,
“CLASS” : “CDB Instance / CDB ADMINISTRATOR / AL-1003”,
“TIME” : “2021-09-23T01:24:01.602-04:00”
}
همانطور که می دانید، اوراکل در نسخه 21c، معماری non-CDB را ساپورت نمی کند بنابرین برای ارتقا نسخه non-CDB به 21c، باید قبل از ارتقا، دیتابیس non-CDB را به یک PDB تبدیل کنیم. قبلا نحوه انتقال و ارتقا دیتابیسی با معماری non-CDB به نسخه 21c را با استفاده از قابلیت Replay Upgrade توضیح دادیم در این متن از ابزار Autoupgrade برای این کار استفاده خواهیم کرد.
تفاوت عمده Autoupgrade و Replay Upgrade، به تبدیل non-cdb به pdb برمیگردد چرا که در زمان استفاده از Replay Upgrade، عملیات plug/unplug باید توسط DBA انجام شود اما در زمان استفاده از ابزار Autoupgradeء، DBA صرفا باید یک فایل پیکربندی را ایجاد کند و مابقی عملیات توسط این ابزار انجام می شود.
در ادامه متن، مراحل ارتقا non-cdb از نسخه 19c به نسخه 21c را توضیح خواهیم داد.
ارتقا PDB به نسخه 21c به روشهای مختلفی قابل انجام است که قبلا نحوه انجام ان را با کمک قابلیت Replay Upgrade توضیح دادیم. یکی دیگر از روشهای انتقال و ارتقا PDB به نسخه 21c، ابزار AutoUpgrade است که در این متن با استفاده از این ابزار، PDB را به نسخه 21c ارتقا خواهیم داد.
این ابزار در مقایسه با Replay Upgrade، نیاز به مداخله DBA را به حداقل می رساند برای مثال، در روش Replay Upgradeء، DBA موظف بود PDB را به نسخه بالاتر plug کند در صورتی که در زمان استفاده از ابزار AutoUpgrade، حتی این کار هم به صورت خودکار انجام خواهد شد و DBA صرفا باید با ایجاد فایل پیکربندی، CDB مبدا و مقصد و همچنین نام PDB را مشخص کند.
در ادامه از ابزار AutoUpgrade استفاده کرده و PDBای را از نسخه 19c به نسخه 21c انتقال و ارتقا خواهیم داد.
تنظیم درست مقدار خصیصه cache برای sequenceها می تواند به لحاظ پرفرومنسی بسیار اثرگذار باشد البته در بعضی از موارد، به دلیل محدودیت application مجاز نیستیم برای cache مقداری بزرگتر از صفر در نظر بگیریم صرف نظر از این استثنا، گاها مشاهده می شود که بعضی از افراد بعد از ایجاد sequenceء، cache را با همان مقدار پیش فرض(عدد 20) رها می کنند در صورتی که این مقدار نمی تواند برای همه sequenceها مناسب باشد و برای آنکه sequenceها بتوانند بهتر پاسخگوی بارکاری باشند باید سایز cache را متناسب با نرخ استفاده sequence مقداردهی کرد.
اوراکل قابلیت جدیدی را ارائه کرده است که می تواند در این زمینه بسیار موثر باشد. ویژگی Sequence Dynamic Cache Resizing در اوراکل 21c ارائه شده(و بعدا در 19.10 هم اضافه شده است) و می تواند به صورت خودکار این مسئله(اندازه cache) را مدیریت کند.
براساس این ویژگی، cache size می تواند بر مبنای نرخ استفاده sequenceها کاهش و یا افزایش یابد(به صورت خودکار). البته این مقدار هیچ وقت از عددی که به صورت دستی برای خصیصه cache تنظیم شده، کمتر نمی شود. قابلیت Dynamic Cache Resizing به صورت پیش فرض فعال است.
در ادامه با ارائه یک سناریو، بیشتر با رفتار Sequence Dynamic Cache Resizing آشنا خواهیم شد.
یکی دیگر از قابلیتهای جدید اوراکل در نسخه 21c، امکان استفاده از هینت RESULT_CACHE در محیط Physical Standby است که در ادامه نحوه استفاده از ان توضیح داده شده است.
***مدت زمان اجرای پرس و جوی زیر، در دیتابیس primary حدودا یک دقیقه است:
–primary:
SQL> select count(*) from usef.tbl1;
COUNT(*)
———-
62775296
Elapsed: 00:01:06.45
SQL> /
COUNT(*)
———-
62775296
Elapsed: 00:01:03.61
با استفاده از هینت result_cache این زمان به زیر یک ثانیه کاهش پیدا می کند!
–primary:
SQL> select /*+ result_cache */ count(*) from usef.tbl1;
COUNT(*)
———-
62775296
Elapsed: 00:01:20.74
SQL> select /*+ result_cache */ count(*) from usef.tbl1;
COUNT(*)
———-
62775296
Elapsed: 00:00:00.00
زمانی که یک pdb را با استفاده از روش plug/unplug از نسخه پایین تر به دیتابیسی با نسخه بالاتر منتقل می کنیم، امکان open کردن این pdb به صورت نرمال وجود ندارد مگر آنکه نسخه pdb را ارتقا دهیم(تا قبل از اوراکل 21c!).
برای مثال، در قسمت زیر، pdb18 را از نسخه 18c به نسخه 19c انتقال دادیم و قصد داریم بدون ارتقا این pdb را open کنیم:
SQL*Plus: Release 19.0.0.0.0 – Production on Sat Sep 25 07:26:59 2021
Version 19.3.0.0.0
SQL> create pluggable database PDB18 using ‘/home/oracle/PDB18C.xml’ nocopy;
Pluggable database created.
SQL> show pdbs;
CON_ID CON_NAME OPEN MODE RESTRICTED
———- —————————— ———- ———-
2 PDB$SEED READ ONLY NO
3 PDB READ WRITE NO
4 PDB18 MOUNTED
SQL> alter pluggable database PDB18 open;
Warning: PDB altered with errors.
همانطو که می دانید اوراکل در نسخه 21cء، Non-CDB را ساپورت نمی کند بنابرین برای ارتقا یک دیتابیس Non-CDB به نسخه 21c، ابتدا باید آن را به PDB تبدیل کرد و پس از آن، PDB را به نسخه 21c ارتقا داد.
قابلیت Replay Upgrade که از قابلیتهای جدید اوراکل در نسخه 21c است، این امکان را می دهد تا بخشهای از عملیات ارتقا Non-CDB به صورت خودکار انجام شود. برای مثال، بعد از plug کردن Non-CDB به یک دیتابیس CDB، نیازی به اجرای اسکریپت noncdb_to_pdb.sql نخواهد بود و در زمان open کردن PDB، نسخه PDB به 21c ارتقا پیدا خواهد کرد.
در ادامه این متن، مراحل ارتقا non-cdb از نسخه 18c به نسخه 21c را با کمک قابلیت Replay Upgrade مشاهده می کنید.
قبلا در مقاله ای قابلیت Automatic In-Memory که یکی از فیچرهای جدید اوراکل در نسخه 18c است را مورد بررسی قرار دادیم. همانطور که در “مقاله یاد شده” اشاره کردیم، قابلیت Automatic In-Memory از طریق پارامتر INMEMORY_AUTOMATIC_LEVEL کنترل می شود که در نسخه 18c در دو سطح LOW و MEDIUM قابل تنظیم است. در نسخه 21c می توان مقدار High را هم برای این پارامتر تنظیم کرد که در ادامه نکاتی را در این مورد ارائه خواهیم کرد.
با تنظیم پارامتر INMEMORY_AUTOMATIC_LEVEL به مقدار High، خصیصه inmemory برای segmentهای غیر سیستمی دیتابیس به صورت INMEMORY MEMCOMPRESS AUTO فعال خواهد شد(به استثنای external table، IOTها و ایندکسها). البته اگر از قبل قابلیت INMEMORY برای سگمنتی تنظیم شده باشد، تغییری در خصیصه inmemory_compression آن ایجاد نخواهد شد.