I was wondering what will happen iff some archivelog gap really happens in a dataguard environment. How to resolve it? What has to be done manually and what happens automatically due to the remote file service (fal), for example.
Well, my attempt in producing the problem goes like this:
- verify normal operation by doing manual log switches on primary and watching the alert.log on primary and standby what happens
- defering the remote log destination (usually #2) on primary
- doing another manual log switches on primary that do now, don’t get shipped to standby
- backup primary with removing all backed up archive logs from the recovery destination
- bounce primary and standby
- activating the remote log destination (usually #2) on primary again, doing another manual log switches on primary, watching the alert.log on primary and standby what happens
Ok, let’s follow the alert.log on primary and standby …
just for short, digged another “circumstance” of oracle operation, in a data guard environment this time. i usually set up standby databases from a rman backup set, clone and adapt the spfile, clone the password file, create a new instance and so on. this works great, no problems so far.
Bitbach's Blog 