ریکاوری دیتابیس از روی tape و تجربیاتی در همین محدوده

سلام. 

 

قبل از اینکه شروع کنم چند تا نکته ضروری رو مرور کنیم. اول نگه داشتن 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/