This content has been marked as final. Show 8 replies
didnt work. I had to take standy file management out of auto and set to manual. ran the commands to rename all redo logs, put file management back to auto, restarted the redo apply, all fine. I can select member from v$logfile and see all the paths are good. I will say at this point that the only files that I can see on the OS are the redo files that were there anyway. no new files were created by the rename.
Redo is applying successfully from primary.
I went to open
DGMGRL> convert database stdby to snapshot standby;
Converting database "stdby" to a Snapshot Standby database, please wait...
Error: ORA-38784: Cannot create restore point ''.
Failed to convert database "sigbcp"
-- I reset the instance to standby, and went to alert log where I see multiple lines of type
ORA-00313: open failed for members of log group 206 of thread 2
ORA-00312: online log 206 thread 2: '/u05/oradata/stdby/<logfilename>'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
thanks osama, I had seen that but it didnt help. Update so far.
primary is ASM
standby is mounts in /u04 and /u05
standby is in maximum performance mode.
When I query v$log and v$standby_log on the standby database I seen some of the redo log files were in /u04 and /u05 and did exist. But some of the files were listed as still being in ASM with +DATA file paths. I think the rman script that was used to clone the database didnt convert properly.
all of the standby_log files are listed as ASM paths. Yet the standby is in synch. I know the standby doesnt use the redo logs until it opens so Im not too worried about those until we come to open it but My understanding of max performance mode was that it used standby logs to apply changes asynch but if the paths dont exist for those standby logs, Im puzzled how its staying in synch.
I ran a rename for all the ASM files to repoint to mount points on the standby so now all log files on v$log and v$standby_log have proper mount path but none exist on the file system. Standby is currently applying the logs.
I resolved this.
The alert logs werent showing anything meaningful.
The rename of the files didnt seem to work initially using the data guard broker to switch roles to snaphsot standby, i was still erroring as earlier posted. However, using the SQLplus method, bounced the DB first, this seemed to kickstart the alter, oracle discovered the logs and temp files that I had renamed and I was able to open snapshot standby successfully..
thanks for help osama.