RE: Data Guard Issue

From: Scott Canaan <"Scott>
Date: Wed, 28 Aug 2024 15:43:57 +0000
Message-ID: <CH3PR16MB589746A4C7A6BF7533E8220BC5952_at_CH3PR16MB5897.namprd16.prod.outlook.com>

I did not do that, but it appears that when I told RMAN to do a backup based on the SCN, it was too old. So that’s where the problem lies. I don’t see any way to fix it other than trash the existing configuration and build it again from scratch.

CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.

From: Jon Crisler <joncrisler_at_gmail.com> Sent: Wednesday, August 28, 2024 11:41 AM To: Scott Canaan <srcdco_at_rit.edu>
Cc: Oracle-L Freelists <oracle-l_at_freelists.org> Subject: Re: Data Guard Issue

Did you do an "alter database open resetlogs " ? I think in this case you do not want a reset log. Also change the parameter dg_broker_start to false on the standby, that will save you some steps while recovering. I am thinking that alfter the work on the standby, it is now an incompatible incarnation due to the resetlogs.

On Wed, Aug 28, 2024 at 10:50 AM Scott Canaan <srcdco_at_rit.edu<mailto:srcdco_at_rit.edu>> wrote: I’ve done the cancel / restart at least 3 times. I did do an RMAN backup, copy, “restore” along with the control file which was created just after the RMAN backup.

Scott Canaan ‘88
Sr Database Administrator
Information & Technology Services
Finance & Administration
Rochester Institute of Technology
o: (585) 475-7886 | f: (585) 475-7520
srcdco_at_rit.edu<mailto:srcdco_at_rit.edu> | c: (585) 339-8659 CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.

From: Jon Crisler <joncrisler_at_gmail.com<mailto:joncrisler_at_gmail.com>> Sent: Wednesday, August 28, 2024 10:42 AM To: Scott Canaan <srcdco_at_rit.edu<mailto:srcdco_at_rit.edu>> Cc: Oracle-L Freelists <oracle-l_at_freelists.org<mailto:oracle-l_at_freelists.org>> Subject: Re: Data Guard Issue

In this case you need to cancel mrp before you try to restart it . Double check the incarnations once you get media recovery running (rman or dg mrp) . Worst case you will need a full rman copy to restore the standby , and use a control file from “after” the rman backup , otherwise you have to manually catalog your rman backups. Sent from my Atari 2600

On Aug 28, 2024, at 10:20 AM, Scott Canaan <dmarc-noreply_at_freelists.org<mailto:dmarc-noreply_at_freelists.org>> wrote:
We are running Oracle 19.23. We have a data guard configuration that isn’t working. About 2 months ago, someone changed the secondary to a snapshot standby instead of a physical standby. That was just discovered and it’s too late to recover all the now missing archive logs (backups are only kept for 30 days). I tried to restore the database from the primary via an RMAN backup/recovery. That appears to have worked. Now the archive logs are being brought over, but not applied. The secondary says it’s a physical standby, but cloud control says it’s still a snapshot standby. When I tried to recover it, I get an ORA-01153. I also noticed that the MRP0 is waiting for log 1, which doesn’t exist. I’ve been searching online and nothing is working. Of course this is a critical production database.

How do I get this data guard mess straightened out?

SQL> select status,instance_name,database_role,open_mode from v$database,v$Instance;

STATUS INSTANCE_NAME DATABASE_ROLE OPEN_MODE
------------ ---------------- ---------------- --------------------
MOUNTED CLAWPRDA PHYSICAL STANDBY MOUNTED SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS FROM V$MANAGED_STANDBY; PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS
--------- ------------ ---------- ---------- ---------- ----------

ARCH      CLOSING               1     140772     411648        298
DGRD      ALLOCATED             0          0          0          0
DGRD      ALLOCATED             0          0          0          0
ARCH      CLOSING               1     140773     411648       1219
ARCH      CONNECTED             0          0          0          0
ARCH      CONNECTED             0          0          0          0
RFS       IDLE                  1          0          0          0
RFS       RECEIVING             1     140774     258804          2
MRP0      WAIT_FOR_LOG          1          1          0          0

9 rows selected.

SQL> select sequence#, archived, applied from v$archived_log order by sequence#;

SEQUENCE# ARC APPLIED
---------- --- ---------

    140768 YES NO
    140769 YES NO
    140770 YES NO
    140771 YES NO
    140772 YES NO
    140773 YES NO 6 rows selected.

SQL> recover standby database;
ORA-01153: an incompatible media recovery is active

--

http://www.freelists.org/webpage/oracle-l Received on Wed Aug 28 2024 - 17:43:57 CEST

This message: [ Message body ]
Next message: dimensional.dba: "RE: Data Guard Issue"
Previous message: Jon Crisler: "Re: Data Guard Issue"
In reply to: Jon Crisler: "Re: Data Guard Issue"
Next in thread: dimensional.dba: "RE: Data Guard Issue"

Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ]

Original text of this message