تغییر UNDO_RETENTION در PDB

از نسخه  19.9  به بعد تغییر برخی از پارامتر ها (در اینجا پارامتر مورد نظر UNDO_RETENTION  میباشد ) در Container Root (CDB$ROOT)  منجر  به تغییر آن پارامتر در بقیه PDB ها نمیشود  . از نسخه 12.2.0.1 به صورت پیش فرض هر PDB  دارای UNDO_TBS  مخصوص به خود میباشد (منظور local undo only  که تنظیم پیش فرض به هنگام ساخت یک PDB  جدید است ) از این رو هر PDB تنظیم UNDO  مخصوص به خود را دارد. برای تغییر پارامتر UNDO_RETENTION در تمامی Instance از دستور زیر استفاده کنید .

ALTER SYSTEM SET UNDO_RETENTION=10 CONTAINER=ALL SCOPE=BOTH;

دستور بالا در محیط دیتاگارد به دلیل Read-Only  بودن PDB با خطا مواجه میگردد . در محیط دیتاگارد از دستور زیر استفاده میگردد .

ALTER SESSION SET CONTAINER=CDB$ROOT;
ALTER SYSTEM SET UNDO_RETENTION=10 SCOPE=BOTH;
ALTER SESSION SET CONTAINER=SHATOOTPDB;
ALTER SYSTEM SET UNDO_RETENTION=10 SCOPE=BOTH;

لازم به ذکر است که هنگام تغییر پارامتر های داخل PDB   اگر از SCOPE=SPFILE  و یا SCOPE=BOTH  استفاده شود ، آن تغییر  در Data Dictionary  های PDB  و فایل تعریف XML  آن PDB ذخیره میشود  و بر روی SPFILE  تغییری ایجاد نمیکند . برای مشاهده پارامتر های تغییر یافته داخل PDB   از کوئری زیر استفاده شود .

SELECT PS.DB_UNIQ_NAME , PS.PDB_UID , P.NAME AS PDB_NAME , PS.NAME , PS.VALUE$ 
FROM PDB_SPFILE$ PS JOIN V$PDBS P ON PS.PDB_UID = P.CON_UID;

لیست پارامتر ها با شرایط توضیح داده شده در این بخش (طبیعتا با اعمال هر Patch set  امکان تغییر این لیست وجود دارد )

_ROLLBACK_SEGMENT_COUNT
_SMU_TIMEOUTES
_SMU_DEBUG_MODE
_UNDO_DEBUG_MODE
_HIGHTHRESHOLD_UNDORETENTION
_UNDO_AUTOTUNE
UNDO_RETENTION
_COLLECT_TEMPUNDO_STATS

داستانهای واقعی: افزایش فضای shared pool

یک RAC سه نود بر روی اوراکل نسخه 12.2 داریم. مدتی بود در وقت های پیک کاری اپلیکیشن، با ویت ایونت gc current block 2-way و ... و با مقدار بالا برخورد میکردم به نحوی که کارکرد اپلیکیشن رو مورد تاثیر خود قرار داده بود. از طرفی تمام موارد مرتبط با GC در کلاستر رو با دقت و وسواس بالا با توجه به آخرین Best Practiceها پیکربندی و بازبینی کرده بودم (به خصوص پارامترهای مرتبط با LMS مانند GCS_SERVER_PROCESSES) و با مانیتورینگ شبکه و سرعت Interconnect هام از سرعت و وضعیت خوب اونها مطمئن بودم همچنین با توجه به مشاهدات محیطی به این نتیجه رسیده بودم که در طول 2 ماه کارکرد اپلیکیشن تنها در انتهای بازه های پیک اپلیکیشن این مشکل دیده میشد پس این موضوع کنجکاوی من رو برای این که بفهمم مشکل کجا بود بیشتر کرد.

تو بررسی هام از طریق Memory Advisor در Enterprise Manager متوجه شدم که در این روزها فضای shared pool به طرز قابل توجهی بالا میره و فضای buffer cache بسیار کوچیک میشه پس با این فرض همه چیز منطقی به نظر میومد. چون با رشد فضای shared pool فضای کافی برای buffer cache نبود.

زمانی که سیستم در وضعیت و پرفورمنس مناسب قرار داشت

 

طرح تست ویژگی‌های جدید دیتابیس اوراکل 20C

اگه مطالب قبلی من رو دنبال کرده باشید من در یک طرح محدود برای تست فیچرهای اوراکل 20C هستم (جمعا ۳۳ ویژگی) از اونجایی که زمان من برای تست محدوده (حداکثر تا تاریخ 2020-Nov-20) و فیچرها زیاد هستن و من میخوام تمام این ویژگی‌ها رو به فارسی مستند کنم از تیم اوراکل برای حداکثر تا ۵ نفر اجازه گرفتم که در این طرح همراه من باشند که این فیچرها رو باهم تست و در این وبلاگ مستندسازی کنیم.

لازم به ذکره مطالب هر نفر به اسم خودش منتشر میشه و هر روز تست و مستند سازی یک ویژگی الزامی هست.

پس اگه مشتاق جزو اولین نفراتی باشید که اوراکل 20C رو تست می‌کنند از طریق تلگرام به من پیام بدید.

@MahdiGhaffari94