How was the standby created in the first place? Was it accidentally placed in
user managed backup mode? Look at v$Backup…
Or did the standby die and ended up fuzzy forever? I don’t remember exactly
what error shows up in the alert.log but it was something along that line.
Did it apply a corrupted or perhaps shortened archivelog? Eg. When it’s
transferred manually whilst the log will still being archived…
Datafiles that are fuzzy will always recover. You won’t get an error. It’s just
that u won’t be able to open it until it gets out of fuzzy state.
I guess you could try and recreate the standby controlfile and see if it makes
the situation any better.
On 21 Jun 2022, at 8:51 am, Mladen Gogala <gogala.mladen@xxxxxxxxx> wrote:
On 6/20/22 13:05, Scott Canaan wrote:
We are running Oracle 19.15 on Red Hat 7.
On Friday, one of my co-workers tried to convert the physical standby to a
snapshot standby to use it to refresh another database. He got an error
saying more standby was needed in order to convert. Looking into the alert
log, there are messages saying that several files are “fuzzy”. He
re-established the data guard, but now the standby database says that all of
the files are “fuzzy”.
DGMGRL> show configuration
Configuration - CLAWPRDA
Protection Mode: MaxPerformance
CLAWPRDB - Primary database
CLAWPRDA - Physical standby database
Fast-Start Failover: Disabled
SUCCESS (status updated 8 seconds ago)
DGMGRL> convert database 'CLAWPRDA' to snapshot standby;
Converting database "CLAWPRDA" to a Snapshot Standby database, please wait...
Error: ORA-38788: More standby database recovery is needed
Failed to convert database "CLAWPRDA"
When in DGMGRL, what do "show database verbose CLAWPRDA" and "validate
database CLAWPRDA" show? Any indications of the error in the alert.log on the
Tel: (347) 321-1217