Nimbrung dikit kalau boleh ... Sebelumnya mau tanya, ada pakai dataguard atau bikin server standby secara manual? kalau pakai dataguard, mestinya tidak perlu membuat script seperti yang anda buat, karena akan dihandle mekanisme dataguard secara otomatis.
Anyway, kalau lihat statement anda, saya rasa acuan anda cukup query dari v$archived_log, bukan yang dari recovery process. karena sequence yang ada di v$archive_log pasti sudah terbentuk archivelognya di standby server dan sudah teregister tetapi belum ter-applied. Masalahnya adalah apakah archivelog itu terkirim/terbentuk dengan baik di standby, sehingga menyebabkan proses recoverynya ada yang gagal, yang akhirnya menyebabkan log gap seperti pada kasus anda. Dari kasus anda, mestinya saat kejadian tersebut, kalau kita query v$archived_log, status kolom applied dari seq# 180053 - 180504 pasti menunjukkan 'NO'. Padahal, file archive seq 180053 mungkin sudah terbentuk di standby, tapi mungkin saja dia korup/rusak. sehingga anda mesti copy ulang dari primary dan apply manual log tersebut. regards, joey Mohammad Arief Pradipto wrote: > Thanks responsenya pak Defri, > > maksud saya gini, saya mau bikin script yang mengotomatisasi kegiatan > recovery ini, karena kegiatan recovery ini akan rutin setiap bulan. Jadi niat > saya semula saya mau ambil last archived log yang ada di standby database, > kemudian dari last sequence tersebut saya buat script yang akan ftp mengambil > next sequence-nya dari server repository archive log per 100 record. Niatnya > seperti itu, tapi kemudian terbentur masalah bahwa sequence yang diminta oleh > recovery process tidak sesuai dengan record last archive yang sudah > terarchived. Sehingga sekarang saat ini saya kejar manual dahulu, sampai last > sequence yang diminta dan record last archived sudah sesuai, baru saya lanjut > lagi dengan script saya. > > Thanks bantuannya masters > > > regards, > > adipt > > ----- Original Message ----- > From: defri afrian<mailto:[email protected]> > To: [email protected]<mailto:[email protected]> > Sent: Friday, January 29, 2010 9:31 AM > Subject: External Email: --> Re: [indo-oracle] Recovery Progress > > > > Dear Arief, > > Anda copykan file fifapps_1_180053_650976694.arc dari primary db ke standby > db, kemudian register file archive tersebut di standby db menggunakan command > : > > alter database register physical logfile > '/oradata/archive/fifapps_1_180053_650976694.arc'; > Untuk direktiry menyesuaikan. > > Semoga membantu > > Regards, > Defry > > --- On Thu, 1/28/10, mohammad arief pradipto > <[email protected]<mailto:aa.adipt%40gmail.com>> wrote: > > From: mohammad arief pradipto > <[email protected]<mailto:aa.adipt%40gmail.com>> > Subject: Re: [indo-oracle] Recovery Progress > To: [email protected]<mailto:indo-oracle%40yahoogroups.com> > Date: Thursday, January 28, 2010, 2:07 AM > > Masih berkaitan tentang recovery.. Mohon bantuannya dari Masters semua. > > Saya sedang recover manual salah satu standby database, namun ada ketidak > sesuaian antara sequence# actual yang diminta oleh Recovery Process dan last > archived sequence yang saya query di view > > Sequence actual yang diminta adalah sebagai berikut > > SQL> recover standby database; > ORA-00279: change 86979430936 generated at 01/26/2010 22:17:50 needed for > thread 1 > ORA-00289: suggestion : > /fifappsdata/data02/fifapps/arc/fifapps_1_180053_650976694.arc > ORA-00280: change 86979430936 for thread 1 is in sequence *#180053 --> ini > adalah sequence terakhir yang diminta* > > Specify log: {<RET>=suggested | filename | AUTO | CANCEL} > > Sedangkan last archived log yang saya berhasil query adalah sebagai berikut > > SQL> select max(sequence#) from v$log_history; > > MAX(SEQUENCE#) > -------------- > *180504 --> Sequence# yang berhasil saya query* > > Perbedaannya sampai 500 archived log.. Maksud saya adalah saya ingin query > sehingga output yang saya terima adalah sequence# yang akan diminta oleh > Recovery Process. Bisa minta tolong bantuannya masters? > > regards, > > adipt > > On Thu, Jan 28, 2010 at 3:59 PM, mohammad arief pradipto > <[email protected]<mailto:aa.adipt%40gmail.com> > >> wrote: >> > > >> Recovery yang sedang berjalan dicancel dulu pak Sudarsono.. >> >> SQL> alter database recover database cancel; >> >> kemudian recover ulang >> >> >> Hope this helps, >> >> adipt >> >> 2010/1/28 . Sudarsono >> <[email protected]<mailto:logminer.viewer%40gmail.com>> >> >> >> >>> Dear All, >>> >>> saya sedang melakukan restore database. >>> pada saat recovery incomplete until time >>> tiba-tiba session putus (ter-kill via O/S) sebelum waktu yang diinginkan >>> bagaimana cara melakukan recovery ulang? >>> karena jika di-run script yang sama >>> keluar message error bahwa recovery sedang berjalan. >>> >>> TIA >>> >>> [Non-text portions of this message have been removed] >>> >>> >>> >>> >> >> -- >> adipt >> [email protected]<mailto:aa.adipt%40gmail.com> >> 021 68 535 141 >> http://adipt.blogspot.com/ >> >> > > -- > adipt > [email protected]<mailto:aa.adipt%40gmail.com> > 021 68 535 141 > http://adipt.blogspot.com/ > > [Non-text portions of this message have been removed] > > ------------------------------------ > > -- > -----------I.N.D.O - O.R.A.C.L.E--------------- > Keluar: > [email protected]<mailto:indo-oracle-unsubscribe%40yahoogroups.com> > Website: > > [Non-text portions of this message have been removed] > > > > > ________________________________ > Mulai 1 januari 2010 PT. Federal International Finance menempati gedung baru > > MENARA FIF - Jl. TB. Simatupang Kav. 15, Cilandak Barat Jakarta 12340, Telp: > (021) 769 8899, Fax: (021) 7590 5599 > > > [Non-text portions of this message have been removed] > > > > ------------------------------------ > > -- > -----------I.N.D.O - O.R.A.C.L.E--------------- > Keluar: [email protected] > Website: http://indooracle.wordpress.com > http://www.facebook.com/group.php?gid=51973053515 > ----------------------------------------------- > > Bergabung dengan Indonesia Thin Client User Groups, > Terminal Server, Citrix, New Moon Caneveral, di: > http://indo-thin.blogspot.comYahoo! Groups Links > > > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. [Non-text portions of this message have been removed]
