RE: Data Guard Issue

From: Scott Canaan <srcdco_at_rit.edu>
Date: Fri, 18 Nov 2022 19:30:58 +0000
Message-ID: <MN2PR16MB2973F05C172AD9E135FBC9D3C5099_at_MN2PR16MB2973.namprd16.prod.outlook.com>



Thanks. As it turns out, all I had to do was type “enable configuration” in dgmgrl. Then it was happy and all is good in the world again (except the snow).

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: Andrew Kerber <andrew.kerber_at_gmail.com> Sent: Friday, November 18, 2022 2:24 PM To: Scott Canaan <srcdco_at_rit.edu>
Cc: oracle-l_at_freelists.org
Subject: Re: Data Guard Issue

restart the standby and check the status in dgmgrl. If that doesnt do it, issue the convert command from within dgmgrl and see what it does.

On Fri, Nov 18, 2022 at 1:19 PM Scott Canaan <srcdco_at_rit.edu<mailto:srcdco_at_rit.edu>> wrote: We have a production database set up with data guard. This morning, I ran a script to refresh a test version using the standby. To do this, we change the standby to a snapshot standby, copy the data, then change it back to a physical standby. At the end of the script, it didn’t change back to a physical standby. I manually changed it back using the “alter database convert to physical standby” command, followed by “alter database recover managed standby database disconnect from session”. Both appeared to work and it looks like logs are being shipped and applied. But cloud control and dgmgrl both say it isn’t good. Cloud control says that it is a physical standby, but when I dig into it, it gives an ORA-16816: incorrect database role and ORA-16782: instance not open for read and write access.

This is what dgmgrl says:

DGMGRL> show configuration

Configuration - CLAWPRDA

  Protection Mode: MaxPerformance
  Members:
  CLAWPRDB - Primary database
    CLAWPRDA - Snapshot standby database       Error: ORA-16810: multiple errors or warnings detected for the member

Fast-Start Failover: Disabled

Configuration Status:
ERROR (status updated 51 seconds ago)

This is what the database itself says:

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 So which is correct? How do I get them all to agree?

This is Oracle 19c (19.16) on Red Hat 7.

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.

--

Andrew W. Kerber

'If at first you dont succeed, dont take up skydiving.'
--

http://www.freelists.org/webpage/oracle-l Received on Fri Nov 18 2022 - 20:30:58 CET

Original text of this message