keliatannya itu setelah saya check di metalink, dapat saja terjadi untuk phsical standby datagard yang tidak memakai mode max protection, alias mode asyncronous. keliatannya ini bug oracle.. hehehe.. masih bingung jg kenapa, apa gara2 node primarynya very2 busy kadang2 salah satu node RAC nya restart.. thanks ya pa arif idenya. mungkin berguna bagi temen2 yang lainnya kalo2 terjadi seperti yang saya alami setelah saya coba 1.backup incremental dari mulai SCN terakhir standby di primary 2.recover menggunakan incremental backup tersebut. 3.backup as copy datafile yang terbentuk di primary diantara scn tersebut, anehnya kok nggak terbentuk ada satu datafile hasil recover nya.. tapi pake backup as copy it works.. 4.create standby controlfile di primary 5.rename datafile(untuk yang pake ASM karena di primary sama di standby namanya pasti beda kalo ganti controlfile) 6.coba recover managed standby database--done
--- Pada Sen, 10/8/09, hendra chen <[email protected]> menulis: Dari: hendra chen <[email protected]> Judul: Re: [indo-oracle] error ketika recovery standby Kepada: [email protected] Tanggal: Senin, 10 Agustus, 2009, 2:41 PM Di cancel aja pak jika archive nya tidak ada atau inconsistent. .. trus open dengan reset logs nya Best Regards, Hendra --- On Mon, 10/8/09, Mohammad Arief Pradipto <arief.pradipto@ fif.astra. co.id> wrote: From: Mohammad Arief Pradipto <arief.pradipto@ fif.astra. co.id> Subject: Re: [indo-oracle] error ketika recovery standby To: indo-oracle@ yahoogroups. com Date: Monday, 10 August, 2009, 9:10 AM Keliatannya archive log tersebut tidak bisa dipakai untuk merecover sequence yang disebutkan Pak Adi.. Pak Adi menggunakan Data Guard ngg ya. Langkah langkah berikut bisa dicoba: 1. Apa Pak Adi punya duplikat archive log yang bersangkutan di tempat lain, apabila punya, coba recover dengan archive log tersebut dulu 2. Apabila tidak punya, Pak Adi menggunakan database versi berapa. Apabila database yang digunakan versi 10g ke atas, Coba dulu merecover standby database dengan menggunakan backup dengan RMAN. Coba cek link berikut http://el-caro. blogspot. com/2006/ 10/recovering- standby-database -from.html 3. Apabila database Pak Adi tidak 10g, maka standby database dibangun ulang lagi dari scratch regards, adipt ----- Original Message ----- From: adi rahadian<mailto: adi_rahadian_ kurniadi@ yahoo.co. id> To: indo-oracle@ yahoogroups. com<mailto:indo- oracle@ yahoogroups. com> Sent: Wednesday, August 05, 2009 8:53 AM Subject: [indo-oracle] error ketika recovery standby Dear gurus, saya mengalami masalah ketika recovery di standby datagard berikut errornya ketika saya coba recover SQL> recover standby database; ORA-00279: change 4511054344 generated at 08/04/2009 11:21:57 needed for thread 1 ORA-00289: suggestion : /archive/rac1_ 44294_679751197. arc ORA-00280: change 4511054344 for thread 1 is in sequence #44294 Specify log: {<RET>=suggested | filename | AUTO | CANCEL} auto ORA-00279: change 4511054344 generated at 08/04/2009 11:16:45 needed for thread 2 ORA-00289: suggestion : /archive/rac2_ 30079_679751197. arc ORA-00280: change 4511054344 for thread 2 is in sequence #30079 ORA-00283: recovery session canceled due to errors ORA-00600: internal error code, arguments: [3020], [49], [495057], [206015953], [], [], [], [] ORA-10567: Redo is inconsistent with data block (file# 49, block# 495057) ORA-10564: tablespace GL ORA-01110: data file 49: '+DGDATA/racdg/ datafile/ gl.344.683176477 ' ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 92695 ORA-01112: media recovery not started kelihatanya error ketika recover sequence 30079 thread 2, ORA-10567: Redo is inconsistent with data block (file# 49, block# 495057) mohon advice dari para master tks adie Lebih Bersih, Lebih Baik, Lebih Cepat - Rasakan Yahoo! Mail baru yang Lebih Cepat hari ini! http://id.mail. yahoo.com [Non-text portions of this message have been removed] ____________ _________ _________ __ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorized use or dissemination of this e-mail in whole or in part is strictly prohibited. PT Federal International Finance, which has its seat at North of Jakarta, Indonesia, including its affiliated companies, shall not be liable for the improper or incomplete transmission of the information contained in this e-mail nor for any delay in its receipt or damage to your system. PT Federal International Finance (or its affiliated companies) does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. [Non-text portions of this message have been removed] New Email names for you! Get the Email name you've always wanted on the new @ymail and @rocketmail. Hurry before someone else does! http://mail. promotions. yahoo.com/ newdomains/ sg/ [Non-text portions of this message have been removed] Yahoo! Mail Kini Lebih Cepat dan Lebih Bersih. Rasakan bedanya sekarang! http://id.mail.yahoo.com [Non-text portions of this message have been removed]
