آموزش، مشاوره و پشتیبانی دیتابیس اوراکل

۱۳۸ مطلب با موضوع «پایگاه‌داده :: Oracle DBA» ثبت شده است

قابلیت Gradual Database Password Rollover

برای تغییر پسوردها شما میتوانید از قابلیت جدیدی که در نسخه 19.12 به بعد معرفی شده است (Gradual Database Password Rollover) استفاده کنید . در این روش امکان استفاده همزمان از رمز عبور قبلی و رمز عبور جدید برای مدت زمان مشخصی که در پروفایل آن کاربر تعریف میشود وجود دارد . در این فاصله زمانی میتوان نسبت به تعویض رمز عبور کاربر در پایگاه داده و بر روی تنظیمات برنامه اقدام نمود. پس از سپری شدن زمان مقرر شده امکان استفاده از رمز عبور قبلی وجود نخواهد داشت .

ابتدا پارامتر PASSWORD_ROLLOVER_TIME را در پروفایل کاربر تنظیم میکنیم . کمترین میزان برای پارامتر PASSWORD_ROLLOVER_TIME یک ساعت و بیشترین مقدار 60 روز میباشد . در این مثال مدت زمان یک ساعت در نظر گرفته شده است .

ALTER PROFILE USER_PROFILE LIMIT PASSWORD_ROLLOVER_TIME 1/24;

توجه
تمامی یوزر هایی که از پروفایل استفاده میکنند شامل Policy جدید میشوند .
Session های که به پایگاه داده متصل هستند با تغییر پسورد دچار اختلال نمیشوند.

این پارامتر می تواند حداقل مقدار 1 ساعت (1/24) و حداکثر 60 روز را داشته باشد.

پسورد کاربر مورد نظر را تغییر داده .

ALTER USER USERSERVICES IDENTIFIED BY NEW_PASSWORD;

در این مرحله نسبت به تغییر پسورد در فایل های مربوط به تنظیمات برنامه اقدام کنید .
پس از تغییرات در تنظیمات برنامه در صورتی که مدت زمان پارامتر PASSWORD_ROLLOVER_TIME به اتمام رسیده باشد امکان استفاده از رمز عبور قبلی وجود ندارد . همچنین با استفاده از دستور زیر میتوان زودتر از موعد مقرر شده Policy تنظیم شده را منقضی نمود .

ALTER USER USERSERVICES EXPIRE PASSWORD ROLLOVER PERIOD;

جهت غیر فعال کردن این قابلیت کافیه مقدار پارامتر را به 0 تغییر داد.

ALTER PROFILE USER_PROFILE LIMIT PASSWORD_ROLLOVER_TIME 0;

۲۱ ارديبهشت ۰۱ ، ۰۸:۰۰ ۰ نظر
مهدی غفاری

تغییر تنظیمات مربوط به Maintenance Windows

هنگام ساخت پایگاه داده با استفاده از ابزار DBCA و انتخاب Template های از پیش ساخته شده ، منطقه زمانی Scheduler به صورت پیش فرض بر روی UTC -07:00 قرار میگیرد که منجر به اجرا شدن تمامی Maintenance Windows با منظقه زمانی Los Angeles میشود . همچنین در تقویم میلادی روز های شنبه و یکشنبه تعطیل میباشد لذا به طور پیش فرض در این دو روز Task های مربوط به Maintenance Windows منابع و زمان بیشتری را مورد استفاده قرار میدهند .
دستورات زیر شامل : تغییر منطقه زمانی به Asia/Tehran ، تغییر زمان شروع به ساعت 2 بامداد ، تغییر مدت زمان اجرا هر Task به 1 ساعت در Container(CDB$ROOT) میشود .

ALTER SESSION SET CONTAINER=CDB$ROOT;

BEGIN
--DISABLE WEEKEND AND WEEKNIGHT SCHEDULER
DBMS_SCHEDULER.DISABLE('WEEKNIGHT_WINDOW');
DBMS_SCHEDULER.DISABLE('WEEKEND_WINDOW');
--DISABLE SCHEDULER BEFORE CHANGING ATTRIBUTE
DBMS_SCHEDULER.DISABLE('SATURDAY_WINDOW');
DBMS_SCHEDULER.DISABLE('SUNDAY_WINDOW');
DBMS_SCHEDULER.DISABLE('MONDAY_WINDOW');
DBMS_SCHEDULER.DISABLE('TUESDAY_WINDOW');
DBMS_SCHEDULER.DISABLE('WEDNESDAY_WINDOW');
DBMS_SCHEDULER.DISABLE('THURSDAY_WINDOW');
DBMS_SCHEDULER.DISABLE('FRIDAY_WINDOW');
--CHANGE DEFUALT TIME ZONE FOR SCHEDULER
DBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTE('DEFAULT_TIMEZONE', 'ASIA/TEHRAN');
--CHANGE START_TIME AND DURATION ATTRIBUTE
DBMS_SCHEDULER.SET_ATTRIBUTE(NAME => 'SATURDAY_WINDOW', ATTRIBUTE => 'DURATION', VALUE => NUMTODSINTERVAL(1, 'HOUR'));
DBMS_SCHEDULER.SET_ATTRIBUTE('SATURDAY_WINDOW', 'REPEAT_INTERVAL', 'FREQ=WEEKLY;BYDAY=SAT;BYHOUR=02;BYMINUTE=0;BYSECOND=0');
DBMS_SCHEDULER.SET_ATTRIBUTE(NAME => 'SUNDAY_WINDOW', ATTRIBUTE => 'DURATION', VALUE => NUMTODSINTERVAL(1, 'HOUR'));
DBMS_SCHEDULER.SET_ATTRIBUTE('SUNDAY_WINDOW', 'REPEAT_INTERVAL', 'FREQ=WEEKLY;BYDAY=SUN;BYHOUR=02;BYMINUTE=0;BYSECOND=0');
DBMS_SCHEDULER.SET_ATTRIBUTE(NAME => 'MONDAY_WINDOW', ATTRIBUTE => 'DURATION', VALUE => NUMTODSINTERVAL(1, 'HOUR'));
DBMS_SCHEDULER.SET_ATTRIBUTE('MONDAY_WINDOW', 'REPEAT_INTERVAL', 'FREQ=WEEKLY;BYDAY=MON;BYHOUR=02;BYMINUTE=0;BYSECOND=0');
DBMS_SCHEDULER.SET_ATTRIBUTE(NAME => 'TUESDAY_WINDOW', ATTRIBUTE => 'DURATION', VALUE => NUMTODSINTERVAL(1, 'HOUR'));
DBMS_SCHEDULER.SET_ATTRIBUTE('TUESDAY_WINDOW', 'REPEAT_INTERVAL', 'FREQ=WEEKLY;BYDAY=TUE;BYHOUR=02;BYMINUTE=0;BYSECOND=0');
DBMS_SCHEDULER.SET_ATTRIBUTE(NAME => 'WEDNESDAY_WINDOW', ATTRIBUTE => 'DURATION', VALUE => NUMTODSINTERVAL(1, 'HOUR'));
DBMS_SCHEDULER.SET_ATTRIBUTE('WEDNESDAY_WINDOW', 'REPEAT_INTERVAL', 'FREQ=WEEKLY;BYDAY=WED;BYHOUR=02;BYMINUTE=0;BYSECOND=0');
DBMS_SCHEDULER.SET_ATTRIBUTE(NAME => 'THURSDAY_WINDOW', ATTRIBUTE => 'DURATION', VALUE => NUMTODSINTERVAL(1, 'HOUR'));
DBMS_SCHEDULER.SET_ATTRIBUTE('THURSDAY_WINDOW', 'REPEAT_INTERVAL', 'FREQ=WEEKLY;BYDAY=THU;BYHOUR=02;BYMINUTE=0;BYSECOND=0');
DBMS_SCHEDULER.SET_ATTRIBUTE(NAME => 'FRIDAY_WINDOW', ATTRIBUTE => 'DURATION', VALUE => NUMTODSINTERVAL(1, 'HOUR'));
DBMS_SCHEDULER.SET_ATTRIBUTE('FRIDAY_WINDOW', 'REPEAT_INTERVAL', 'FREQ=WEEKLY;BYDAY=FRI;BYHOUR=02;BYMINUTE=0;BYSECOND=0');
--Enable Scheduler
DBMS_SCHEDULER.ENABLE('SATURDAY_WINDOW');
DBMS_SCHEDULER.ENABLE('SUNDAY_WINDOW');
DBMS_SCHEDULER.ENABLE('MONDAY_WINDOW');
DBMS_SCHEDULER.ENABLE('TUESDAY_WINDOW');
DBMS_SCHEDULER.ENABLE('WEDNESDAY_WINDOW');
DBMS_SCHEDULER.ENABLE('THURSDAY_WINDOW');
DBMS_SCHEDULER.ENABLE('FRIDAY_WINDOW');
END;
/

ادامه مطلب...
۲۰ ارديبهشت ۰۱ ، ۰۹:۵۷ ۰ نظر
مهدی غفاری

تغییر 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

۲۰ ارديبهشت ۰۱ ، ۰۹:۵۰ ۰ نظر
مهدی غفاری

فعال سازی Fix Controlها

Fix Control ها باگ های رفع شده Optimizer میباشند که به صورت پیشفرض غیرفعال میباشند . دلیل غیر فعال بودن Fix Control ها این است که با تغییر تنظیمات مربوط به Optimizer امکان تغییر Plan دستورات SQL وجود دارد و Plan جدید ممکن است باعث بدتر شدن Performance گردد . با توجه به نیاز دیتابیس ها برای اعمال Patch set به صورت دوره ای پیشنهاد میگردد برای ثابت کردن Plan دستورات SQL ، از SQL Plan Management استفاده گردد .

نمایش Fix Control های موجود (خروجی به صورت خلاصه نمایش داده شده است .)

SET SERVEROUTPUT ON;
EXECUTE DBMS_OPTIM_BUNDLE.GETBUGSFORBUNDLE;
19.12.0.0.210720DBRU:
    Bug: 31459242,  fix_controls: 31459242
    Bug: 31082719,  fix_controls: 31082719
    Bug: 28708585,  fix_controls: 28708585
    Bug: 31821701,  fix_controls: 31821701
    Bug: 32107621,  fix_controls: 32107621
    Bug: 26758837,  fix_controls: 26758837
    Bug: 31558194,  fix_controls: 31558194
    Bug: 30781970,  fix_controls: 30781970
    Bug: 30142527,  fix_controls: 30142527
    Bug: 31143146,  fix_controls: 31143146
    Bug: 31961578,  fix_controls: 31961578
    Bug: 31496840,  fix_controls: 31496840
    Bug: 22387320,  fix_controls: 22387320
     ….
PL/SQL procedure successfully completed.

ادامه مطلب...
۲۰ ارديبهشت ۰۱ ، ۰۹:۳۴ ۰ نظر
مهدی غفاری

رفع خطای ORA-65345: cannot refresh pluggable database در RMAN HOTCLONE

بعد از قضیه داستان های واقعی: کلون گیری باگ دار بودم که یه PDB با نزدیک 600 گیگ دیتا انتقال پیدا نمیکرد و در هنگام کلون گیری با خطای زیر مواجه میشد:

RMAN-08018: channel ORA_AUX_DISK_1: starting archived log restore to user-specified destination
RMAN-08508: archived log destination=+FRA
RMAN-08169: channel ORA_AUX_DISK_1: using network backup set from service CDB1
RMAN-08022: channel ORA_AUX_DISK_1: restoring archived log
RMAN-08510: archived log thread=1 sequence=8700
RMAN-08180: channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:01
RMAN-03091: Finished restore at 14-APR-22
RMAN-05045:
Performing import of metadata...
RMAN-06136: Oracle error from auxiliary database: ORA-00283: recovery session canceled due to errors
ORA-65345: cannot refresh pluggable database

اگه جستجو کنید این مشکل زمانی پیش میاد که مقصد قادر به رفرش شدن از دیتابیس مبدا نیست. یکی از دلایل ممکنه به خاطر وجود MRP در سرور مبدا باشه (اگه بر فرض دیتابیس مبدا گارد باشه) اما در مورد من دیتابیس مبدا ADG نبود پس این مشکل با داکیومنت ORA-65345 When Refreshing PDB Sourced From Active Data Guard Standby (Doc ID 2765472.1) برای من وجود نداشت. پس مشکل کجا بود؟

تو جستجوهای خودم بودم که به لینک زیر برخورد کردم:

Bug 32631551 - Refresh pluggable database fails with ORA-283: recovery session canceled due to errors ORA-65345: cannot refresh pluggable database (Doc ID 32631551.8)

و قهمیدم یک باگ شبیه این مورد ثبت شده و تا پچ 19.13 هم وجود داره و تو نسخه 20.1.0 و پچ 19.14 فیکس شده. خب راه حل سریع این باگ میگفت که مسیر recovery_file_dest و LOG_ARCHIVE_DEST_n = 'LOCATION=USE_DB_RECOVERY_FILE_DEST' رو پیکربندی کنیم. من برای اینکه از پارامترها اطمینان پیدا کنم هم در دیتابیس مبدا و هم مقصد دوباره پیکربندی ها رو چک کردم و همه چیز به نظر خوب بود.

ادامه مطلب...
۲۶ فروردين ۰۱ ، ۱۷:۱۸ ۰ نظر
مهدی غفاری

رفع خطای ORA-15124: ASM file name contains an invalid alias name در RMAN HOTCLONE

در ادامه عملیات داستان های واقعی: کلون گیری باگ دار بودم که در دیتابیس مقصد با خطای ORA-15124: ASM file name contains an invalid alias name مواجه شدم.


RMAN-08018: channel ORA_AUX_DISK_1: starting archived log restore to user-specified destination
RMAN-08508: archived log destination=+FRA
RMAN-08169: channel ORA_AUX_DISK_1: using network backup set from service CDB1
RMAN-08022: channel ORA_AUX_DISK_1: restoring archived log
RMAN-08510: archived log thread=1 sequence=8645
RMAN-08180: channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:01
RMAN-03091: Finished restore at 12-APR-22
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate PDB command at 04/12/2022 19:32:47
RMAN-05501: aborting duplication of target database
RMAN-06136: Oracle error from auxiliary database: ORA-15124: ASM file name '+DATA/FMSDB/B6E05B19F9FE428FE05301A4A8C02926/DATAFILE/cl_ezpdo1_mf_temp2_%u_.tmp' contains an invalid alias name

برای اینکه بفهمیم در دیتابیس اصلی چه دیتافایلهایی وجود دارد میتونیم از rman استفاده کنیم و مسیر فایلها رو ببینیم:

$rman target / log=srdc_rman_output_<date>.log
RMAN> set echo on;
RMAN> report schema;
RMAN> exit;

ادامه مطلب...
۲۴ فروردين ۰۱ ، ۱۳:۲۸ ۰ نظر
مهدی غفاری

داستان های واقعی: کلون گیری باگ دار

داشتم از ویژگی کلون گیری آنلاین PDBها (Cloning a Remote PDB یا در RMAN HOTCLONE) برای انتقال PDBها از سرور قدیمی به سرور جدید که از نسخه 12.1.0.1 به بعد ارائه شده بود طبق مقاله Multitenant : Duplicate a Pluggable Database (PDB) to an existing Container Database (CDB) in Oracle Database 18c از دوست عزیزمون آقای Tim Hall استفاده میکردم که با خطای ORA-15122: ASM file name string contains an invalid file number مواجه شدم.

محیط من شامل

سیستم عامل:

Oracle Linux Server release 8.4

دیتابیس سورس:

Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Version 19.13.0.0 with File System

دیتابیس مقصد:

Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Version 19.13.0.0 with File System ASM

طبق مقاله آقای Tim Hall ابتدا اتصال امون رو با rman به سرور اصلی و کمکی برقرار میکنیم (با این تفاوت که لاگ و دیباگ رو روشن میکنیم)

(در اینجا CDB1 سرور اصلی (سورس) و CDB2 سرور کمکی (auxiliary) است - اضافه کردن UR = A در TNS فراموش نشه!!)

rman target sys/<password-sys>@CDB1 auxiliary sys/<password-sys>@CDB2 log /tmp/pdb_clone.log trace /tmp/pdb_clone.trc debug

بعد از اتصال موفق دستور زیر رو برای شروع کلون گیری در rman اجرا میکنیم.

ادامه مطلب...
۲۴ فروردين ۰۱ ، ۰۸:۳۳ ۰ نظر
مهدی غفاری

بازیابی اطلاعات و ساختار جداول از فایل های Dump صدمه دیده اوراکل

مواقعی است که فایل های DUMP دیتابیس اوراکل شما به دلایل مختلف همانند بد افزارها، باج افزارها و یا خطاهای دیسک صدمه دیده اند تو این مواقع میتونید روی کمک ما حساب کنید.

بازیابی قسمت های قابل بازیابی اطلاعات از فایل های DUMP دیتابیس های اوراکل ه صدمه دیده به صورت تخصصی توسط ما قابل انجام است.

شرایط بازیابی

Characterset: AL32UTF8

National Characterset: UTF8 or AL16UTF16

مراحل بازیابی

  • ارسال دامپ فایل به وسیله هارد اکسترنال یا دیگر رسانه های ذخیره سازی و یا از طریق فضاهای ذخیره سازی کلود
  • اعلام درصد و هزینه بازیابی اطلاعات از فایل های دریافتی
۰۲ بهمن ۰۰ ، ۱۰:۱۵ ۰ نظر
مهدی غفاری

ساخت سرویس جدید در سناریو دیتاگارد بدون زیرساخت Grid

تو سناریوی اوراکل دیتاگارد ما یک مدار دیتابیسی تشکیل میدیم که هر وقت سرور اصلی در سایت A از دسترس خارج شد اپلیکیشن با وقفه کوتاهی بتونه به سرور دوم در سایت B متصل بشه (تو سناریو حداکثر پایداری بهتره اپلیکیشن های ریپورت به دیتاگارد متصل نشن و برای سناریو اکتیو دیتاگارد یک دیتاگارد مجزا و مختص به ریپورت به صورت آبشاری راه اندازی بشه که بار روی سرور اصلی هم نباشه)

جهت انجام خودکار این سناریو به طوری که اپلیکیشن به یک سرویس جدا وصل بشه و وابسته به سرویس و IP در هر Instance در مواقع Failover و Switchover نباشه میتونید به شیوه زیر عمل کنید:

ادامه مطلب...
۰۸ آبان ۰۰ ، ۱۴:۰۱ ۰ نظر
مهدی غفاری

داستانهای واقعی: افزایش فضای 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 نبود.

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

 

ادامه مطلب...
۲۷ مهر ۰۰ ، ۰۷:۴۵ ۴ نظر
مهدی غفاری