وبلاگ وحید نوروزی

تجربه و ترجمه و تحقیق درباره اوراکل را در این وبلاگ خواهید یافت.

وبلاگ وحید نوروزی

تجربه و ترجمه و تحقیق درباره اوراکل را در این وبلاگ خواهید یافت.

  • ۰
  • ۰

سلام

اوراکل در قسمت grid infrastructure برای cluster health monitoring از crfclust.bdb ،  که دیتابیسی  از نوع Berkeley database هست استفاده می کند. گاهاً پیش میاد که این دیتابیس کوچک به شدت رشد می کنه و باعث پر شدن پارتیشن خودش می شه و متعاقباً باعث افتادن دیتابیس. 

برای حل این مشکل باید اقدامات زیر رو به ترتیب انجام بدیم:

ابتدا با کاربر grid دستور زیر رو میزنیم:

oclumon manage -repos resize 259200

باید پیغامی مبنی بر اعمال اون بر روی تمامی node ها بگیریم. اگر اینطور نشد و پیغامی غیر از این داد، باید مشکل رو رفع کنیم و دوباره این کار رو تکرار کنیم. برای من این مسئله رخ داد که پارتیش u01 بر روی node2 پر شده بود که خالیش کردم و دوباره دستور بالا رو اجرا کردم.

سپس دستور زیر رو میزنیم:

oclumon manage -get repsize

ممکنه باز هم خطا بخوریم چون در حال حاضر حجم این فایل بزرگتر از اون چیزی که باید باشه شده، اما این خطا رو ignore می کنیم و سرویس مربوطه رو ریستارت می کنیم.

crsctl stop res ora.crf  -init

crsctl start res ora.crf -init


مشکل برطرف شد. 

البته برای این مشکل اوراکل patch هم داده.

موفق باشید.


----

لطفاً در هنگام رانندگی به احترام عابرین پیاده بایستیم.


  • قدیر نوروزی میرصادقی
  • ۰
  • ۰

سلام

چند وقت پیش به علت وجود چند تا مشکل بر روی دیتابیس تصمیم گرفتم که آخرین PACTH SET رو بر روی دیتابیس اعمال کنم. مشکلاتی که من داشتم شامل monster bug اوراکل ، نشان ندادن tablespace ها در cloud control و نزدن ایمیل اخطار برای warning  و یا critical بودن فضای اونها. بالا نیامدن دیتابیس بعد از ریستارت سرور به علت تغییر permission های فایل اجرایی oracle و از این دست خطاها بود. بعد که نگاه کردم دیدم نزدیک بیست صفحه باگ با این patch حل میشه. چه اونهایی که باهاش برخود کرده بودم و چه اونهایی که برخورد نداشتم.

البته حل مشکل فایل اجرایی oracle که وظیفه ارتباط با grid infrastructure  رو به عهده داره رو حدس نمیزدم که حل کنه ولی خوشبختانه اون هم درست شد.

اول تصمیم داشتم فقط patch مربوط به engine database رو بزنم که تو راهنمای patch به این خط برخوردم و تصمیم گرفتم که grid رو هم patch کنم:

 Environments with Grid Infrastructure (GI)

If you are installing the PSU to an environment that has a Grid Infrastructure (GI) home, note the following:Grid Infrastructure PSU 11.2.0.4.171017 Patch 26635745 should be applied to the Grid Infrastructure home and Database home using the readme instructions provided with the patch

اولین قدم دانلود آخرین نسخه opatch هست و نکته ای که داره اینه که هم باید تو oracle_home و هم grid_home جایگزین بشه. 

نکته دوم این که حتماً باید در زیر oracle_home ها opatch رو بزارید . با توجه به اینکه خود opatch میتونه از مسیر جداگانه ای اجرا بشه ، شاید این اشتباه رخ بده که محل اجراش مهم نیست. اما مشکل از اونجایی رخ میده که تو اسکریپت اجرایی opatch مسیرهایی مانند ../../xyz وجود داره که از اونها استفاده می کنه.

نکته سوم اینکه باید بر روی تمامی سرورهای اصلی و گارد این کپی رخ بده.

پس فایل p6880880_112000_Linux-x86-64.zip رو به مسیرهای oracle_home و grid_home می بریم و اونجا بعد از بک آپ گرفتن opatch قبلی ، جایگزین می کنیم. مواظب باشید فایلهای دیگر رو خراب نکنید. اگر از نظر permission به مشکل برخوردید، از root کمک بگیرید و بعد با کاربر root  می تونید opatch رو به permission درست تغییر بدید.

با export کردن grid_home به عنوان oracle_home باید فایل ocm رو بسازیم. این فایل باید ساخته بشه چون اجرای این psu با کاربر root صورت میگیره و از این فایل استفاده می کنه تا بصورت اتوماتیک به همه اطلاعاتی که میخواد، دسترسی داشته باشه.

برای ساختنش دستور زیر رو می زنیم (بر روی تمامی سرورهای اصلی و گارد):

/u01/app/11.2.0/grid/OPatch/ocm/bin/emocmrsp -no_banner -output /home/oracle/ocm960920.rsp

برای اطلاعات بیشتر در مورد این دستور ، داکیومنت شماره 966023.1 رو بخونید.

حالا LISTENER رو روی سرور گارد stop می کنیم و بعد log shiping رو قطع می کنیم. حالا instance های گارد رو میاریم پایین  و همچنین اگر AGENT یا EM بالاست اونها رو STOP   می کنیم و پس از اطمینان از تمامی این کارها، دستور زیر رو با کاربر root میزنیم:

/u01/app/11.2.0/grid/OPatch/opatch auto /home/oracle/PSU_26635745_11.2.0.4.171017/26635745/ -ocmrf /home/oracle/960920.rsp 

یه نکته اضافه کنم در مورد اسم پج ها که دیگه یه عدد خالی نیست و تبدیل به نمایانگر تاریخ شده. به عنوان مثال patch فعلی مال 17 اکتبر 2017 هست.

به خاطر داشته باشید که اگر در حالت Rac هستید، به ترتیب و دونه به دونه node ها رو بزنید.

حالا گارد رو بالا میاریم و چک می کنیم که سینک شده باشه، 

به سراغ سرورهای اصلی میریم و همانطور که در مورد rac اشاره کردم، دونه باید زده بشند. instance ها روپایین میاریم.

نکته: در صورتی که با sqlplus وصل شدید از روی سرور، حتماً ازش خارج بشید چون در هنگام patch زدن، میگه library مربوط به sqlplus باز هست و نمی تونه oatch بزنه.


حالا دستور مربوط به patch رو با کاربر root می زنیم:

/u01/app/11.2.0/grid/OPatch/opatch auto /home/oracle/PSU_26635745_11.2.0.4.171017/26635745/ -ocmrf /home/oracle/960920.rsp

بعد از اتمام کار در صورتی که خطایی نداشتیم و تمامی oraclce_home ها grid  و oracle با موفقیت patch شدند، باید به دیتابیس وصل بشیم و دستورات زیر رو اجرا کنیم:

cd $ORACLE_HOME/rdbms/admin

sqlplus /nolog

SQL> CONNECT / AS SYSDBA

SQL> STARTUP

SQL> @catbundle.sql psu apply

SQL> QUIT

و بعدش برای کامپایل کردن دستور زیر رو:

cd $ORACLE_HOME/rdbms/admin

sqlplus /nolog

SQL> CONNECT / AS SYSDBA

SQL> @utlrp.sql

نکته: اگر در مرحله ای که داره patch میزنه، oracle_home رو نشناخت، با استفاده از oh بهش میشناسونیم و ترتیب هم اول grid_home و بعد oracle_Home رو با مسیر می نویسیم.

نکته: بر روی دیتابیسی که داشتم حدود 3000 INVALID OBJECT از نوع سیستمی (مربوط به SYS و PUBLIC) وجود داشت که با این PATCH حل شد.

اخطار: این مطلب برداشتی از داکیومنت 

Patch 26635745 - Oracle Grid Infrastructure Patch Set Update 11.2.0.4.171017 (Includes Database PSU 11.2.0.4.171017)

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



--------------------------------------------

در هنگام رانندگی به احترام عابرین پیاده بایستیم.

  • قدیر نوروزی میرصادقی
  • ۰
  • ۰

سلام

در زمان راه اندازی cloud control یکی از مهمترین وظایفی که می توانیم به عهده آن بگذاریم، قرار گرفتن در صفحه مانیتورینگ تیم های مانیتورینگ و dba است. لذا بر اساس این موضوع، این صفحه نباید expire شود. 

انجام این کار یک روش ساده دارد. بصورت پیش فرض در 12 این مقدار برابر 45 دقیقه و در 13 برابر null است. برای هدف ما باید این مقدار برابر 1- (منفی یک) تنظیم شود.

در 12 باید به مسیر middleware_home و سپس به پوشه oms و bin  رفته و  در 13 در زیر پوشه middleware_home و سپس bin و دستور زیر را اجرا می کنیم:

./emctl set property -name oracle.sysman.eml.maxInactiveTime -value -1 -sysman_pwd sysman_password

در 12 باید oms را ریستارت کنیم ولی در 13 احتیاج نیست:


./emctl stop oms
./emctl start oms

در 13 با پیغام  OMS restart is not required to reflect the new property value مواجه می شویم که نشان می دهد احتیاجی به restart نیست.


----------

در هنگام رانندگی به احترام عابرین پیاده بایستیم.

  • قدیر نوروزی میرصادقی
  • ۰
  • ۰

سلام

قبل از اینکه شروع کنم چند تا نکته ضروری رو مرور کنیم. اول نگه داشتن dbid و اسکریپتهای backup در جایی غیر از خود دیتابیس که اگر همه چیز از دست رفت و فقط tape برامون موند، بتونیم فقط با داشتن همین دو مورد، rman backup رو برگردونیم روی سرور جدید. البته اسکریپت بک آپ بیشتر در تسریع کار تاثیر داره تا اصل کار.

سناریوی ما شامل از دست رفتن تمامی فایلها شامل spfile  و  controlfile  و datafile ها و archivelog هاست. حالا می خواهیم  بر روی سرور جدیدی backup رو برگردونیم.

بعد از اینکه ارتباطات ما با tape برقرار شد و تنظیمات مربوطه انجام شد و کانالهای rman رو تست کردیم، زمان برگردوندن شروع میشه. یادمون باشه که گزینه atuobackup controlfile رو حتماً از قبل باید کانفیگ کنیم که تو backup ها اومده باشه وگرنه کارمون سخت تر میشه.

قدم اول تنظیم environment variable هاست که مهمترین اونها ORACLE_HOME و ORACLE_SID و PATH هستند

به rman با دستور / rman target  وصل می شویم و دستور زیر رو می زنیم:

set dbid=53246351832161;

حالا با توجه به اینکهspfile   نداریم، با زدن دستور زیر دیتابیس رو مجبور می کنیم که به مرحله nomount وارد بشه.

rman> startup force nomount;

 

spfile رو با دستور زیر بر می گردونیم:

 

RMAN> run{allocate channel ch01 type sbt; 
2> SEND 'NB_ORA_CLIENT= hypprdbv1-bn; 
3> restore  spfile from autobackup; 
4> } 

 

با زدن دستور بالا بصورت پیش فرض 7 روز رو می گرده، اگر ما میدونیم که داده های backup برای قبل از این هست، باید با دادن گزینه maxdays این رو بهش بگیم.که میشه دستور زیر:

 

RMAN> run {

1>allocate channel ch01 type sbt;

2> send 'NB_ORA_CLIENT=hypprdbv1-bn';

3> RESTORE SPFILE to pfile '/export/home/oracle/sshaik/initHYPP.ora' from autobackup maxdays 20;

4> }

 

تو دستور بالا دو تا کار همزمان صورت گرفت، و اون ایجاد PFILE بود که باید با توجه به شرایط محیطی سرور جدید تنظیم بشه. بعد از اینکه دستور بالا رو زدیم، PFILE رو باز می کنیم و فایل رو بر اساس نیاز تغییر میدیم. چند تا از مهمترینهاش پارامترهای مربوط به convert هست و دیگری db_create_file_dest که بر اساس سرور جدید باید مشخصات بدیم .  من پارامترهای مربوط به کلاستر و تنظیمات مربوطه به THREADهای دیگر رو بر داشتم.بعد از این مرحله، می تونیم باز با PFILE جدید بالا بیایم و در حالت nomount با زدن دستور create spfile from pfile ، صاحب spfile بشیم و در راه اندازی بعدی با اون بالا بیاریم دیتابیس رو.

حالا کنترل فایل رو با همون روش restore می کنیم ، اینجا دوباره باید دستور Set dbid رو بزنیم و بعد دستورات پایین  رو اجرا کنیم:

RMAN>  run {allocate channel ch01 type sbt;

2>  send 'NB_ORA_CLIENT=hypprdbv1-bn';

3> restore controlfile to '/adm02/u9001/HYPP/control/control01.ctl' from autobackup maxdays 20;

4> }

اگر to رو هم نزاریم میره سر همون جایی که تو pfile بهش گفتیم.

حالا اگر دستور زیر رو بزنیم مشخصاتی از بک آپ های موجود رو بهمون میگه. با توجه به خروجی اون که SCN 10513166137701 توش هست، می تونیم بفهمیم که تا کجا می تونیم دیتابیس رو recover  کنیم.

RMAN> run{

2> allocate channel ch01 type sbt;

3> send 'NB_ORA_CLIENT=hypprdbv1-bn';

4> restore database preview;

5> }

 

من restore رو جداگانه زدم و دستور recover  رو توش نیاوردم .

 چون محل جدیدی براشون در نظر گرفته بودم، دستورات زیر رو هم زدم:

run {

allocate channel ch01 type sbt;

send 'NB_ORA_CLIENT=hypprdbv1-bn';

set newname for database to ‘+data’;

restore database ;

switch datafile all;

}

بعد از اینکه کارش تموم شد و خواستم recover  رو انجام بدم، با خطای ora-00600  مواجه شدم:

Ora-00600 internal error code , arguments : [krbrpr_no_buffer]

که براش مجبور شدم patch با شماره 19272701 رو بزنم. بعد از اون موفق شدم که دستور recover  رو اجرا کنم. حواسمون باشه در هر مرحله اگر احساس می کنیم که ارتباطمون با دیتابیس از کلاینتی که دستور رو اجرا می کنیم ، ممکنه که قطع بشه، حتماً دستورات رو با nohup  و & بفرستیم background

Recover database until scn 10513166137701;

هنوز کار تموم نشده، باید دیتابیس با دستور زیر open بشه:

Alter database open resetlogs;

وقتی این دستور رو زدم ، با خطاهای Redo مواجه شدم که اگر بخوام مستقیم برم سر اصل مطلب و دورهایی که دور خودم زدم رو ننویسم، باید اونها رو به مسیر جدید اول rename کرد و بعد از اون clear کرد و اون وقت دستور بالا اجرا میشه.

alter database rename file  '/u01/app/oracle/redo/redo01a.log' to ‘+data/db/onlinelog/redo01a.log';

alter database clear unarchived logfile  group n;

اگر در ارتباط با اولیه که وقتی که میخواید spfile رو restore کنید روی asm به خطا خوردید، یه سر هم به دستور setasmgidwrap هم بزنید که معمولاً با ora-00600 خودش رو نشون می ده.

 

خواهش: در هنگام رانندگی به احترام عابرین پیاده بایستیم.

منابع:

http://www.shaiksameer.com/2012/08/oracle-full-db-restore-from-tape-to-new.html

منابعی که در زیر اومدن، اونایی بود که دور خودم میگشتم که مشکل رو حل کنم، ازش چیزهای خوبی در میاد، اگر بخونید بد نیست.

منابع دیگر:

http://www.dba-oracle.com/t_rman_136_recover_missing_redo_log_group.htm

http://dbaclass.com/article/ora-01623-log-3-is-current-log-for-instance-cannot-drop/

https://gavinsoorma.com/2009/07/drop-and-recreate-online-redolog-files/

http://myoracledbablogon.blogspot.com/2011/01/alter-database-open-resetlogs-error-ora.html

https://asanga-pradeep.blogspot.com/2016/08/resetlogs-fails-with-ora-00349.html

https://husnusensoy.wordpress.com/2007/11/29/disabling-an-old-rac-instance-thread/

 

  • قدیر نوروزی میرصادقی
  • ۰
  • ۰

سلام. 

امروز به دلیلی احتیاج داشتم که دیسک گروه data رو بر روی سرور دیگری با همان اطلاعاتی که روش داشتم برگردونم. 

می دونیم که تا header دیسک ها رو پاک نکنیم، به همان اسم شناخته خواهند شد. از همین مطلب استفاده کردم برای انجام این کار. ابتدا بر روی سرور جدید نرم افزار grid infrastructure رو بصورت software only نصب کردم. با زدن oraclasm listdisk  و  oracleasm acandisks پس از اینکه همکار storage  کار دیسک ها رو به سرور جدید شناسوند، باید دیسک ها رو ببینیم. 

مرحله بعدی زدن دستور زیر برای بالا آوردن resource هاست:

crsctl start resource ora.cssd

بعد از بالا اومدن باید listener  رو هم بالا بیاریم ولی قبلش به srvctl اضافه می کنیمش:

srvctl add listener

srvctl start listener

حالا یک pfile ساده که شامل پارمترهای زیر هست رو می سازیم و تحت عنوان init+ASM.ora در مسیر ORALCE_HOME/dbs در تحت کاربر grid (یا اگر تک کاربره هستید، oracle ) ذخیره می کنیم:

*.asm_power_limit=1

*.diagnostic_dest='/u01/app/grid'

*.instance_type='asm'

*.large_pool_size=12M

*.remote_login_passwordfile='EXCLUSIVE'

و حالا asm را با استفاده از pfile بصورت زیر بالا می آریم.

sqlplus / as sysasm

startup pfile='/u01/app/11.2.0/grid/dbs/init+ASM.ora'

بعد از اینکه بالا بیاد ، بهتون می گه من هیچ دیسک گروهی ندیدم، که با زدن دستور زیر ، به راحتی mount میشه. نکته ای که داره، باید اسم دیسک گروهتون رو بدونید.

alter diskgroup data mount;

اما کار تموم نشده، باید کانفیگهایی برای اضافه کردن به srvctl و همچنین ساخت spfile بدید و همچنین پسورد فایل مربوط به اون رو بسازید. اگر بخواهید همین الان دستور create spfile from pfile رو بزنید، با خطای زیر مواجه می شید:

ora-29786: SIHA attribute ...

دستورات زیر را می زینم:

srvctl add asm

srvctl config asm

حالا پسورد فایل را در پوشه dbs می سازیم:

orapwd file=orapw+ASM password=oracle

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

https://eleoracle.wordpress.com/2015/01/23/move-asm-diskgroups-between-server/

https://flashdba.com/install-cookbooks/ol5u7-11-2-0-3-single-instance-using-4k-asm/

امیدوارم چیزی رو جا نگذاشته باشم. اگر نکته ای به ذهنتون رسید که می تونم اضافه کنم، لطفاً بگید.

خواهش: در هنگام رانندگی به احترام عابرین پیاده بایستیم.

  • قدیر نوروزی میرصادقی