thank you, gurus. together with oracle support we were able to almost painlessly recover the corrupted header using only one tool: kfed. we figured that only one block was re-written. the DISK6 became CANDIDATE as soon as I did fdisk. when running querydisk it showed: "Disk "DISK6" does not exist or is not instantiated" we then ran kfed merge and it became a member again and after scandisks DISK6 became a valid ASM disk again. So i was veeery close to bringing my shop down and rebuilding the whole thing, but God had mercy on me and i only was scared to death. Thanks a lot for everybody who replied. M On Wed, Apr 13, 2011 at 7:31 AM, Marcin Przepiorowski <pioro1@xxxxxxxxx>wrote: > On Tue, Apr 12, 2011 at 12:27 AM, D'Hooge Freek <Freek.DHooge@xxxxxxxxx> > wrote: > > Anyway, make sure you have recent backups of the databases and the > archived redo logs and call Oracle when you don't hear from support fast > enough. > > Also, open a ticket with Redhat support. They should be able to tell you > what is happening with the partition table of the lun, which would give you > more information of how it will impact applications reading from this disk. > > > > ASM keep data in disk header - all data has been overwritten by fdisk > and in that case it can be very difficult to repair it. > Everything should be running until nodes reboot. There is a tool to > read and write to ASM headers but I'm not sure if ASM keep all > necessary data > in memory and if we can access that to restore disk header. > > Drop disk and re-balance looks like only option. > > -- > Marcin Przepiorowski > http://oracleprof.blogspot.com >