I bounced the secondary and it generated the following message:
The Data Guard status of DGRDTSTB is Error ORA-12650: No common encryption or
data integrity
algorithm.<https://dbmon06.rit.edu:7803/em/redirect?pageType=sdk-core-event-console-detailEvent&issueID=CC0E43CF9D70EDC6E0539B04100A25F9>
Which makes no sense to me. The sqlnet.ora on both servers was changed on
Wednesday and it worked for at least 24 hours, until the disk on the secondary
server was expanded. Plus, there are two other databases on the same servers
in a data guard configuration that are working fine.
Scott Canaan ‘88
Sr Database Administrator
Information & Technology Services
Finance & Administration
Rochester Institute of Technology
o: (585) 475-7886 | f: (585) 475-7520
srcdco@xxxxxxx<mailto:srcdco@xxxxxxx> | 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: oracle-l-bounce@xxxxxxxxxxxxx <oracle-l-bounce@xxxxxxxxxxxxx> On Behalf
Of Scott Canaan
Sent: Friday, September 17, 2021 7:36 AM
To: Andrew Kerber <andrew.kerber@xxxxxxxxx>; nupendra@xxxxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Subject: RE: Data Guard Issue
There is nothing related to this error in either alert log.
The error being reported in Cloud Control is:
ORA-16857: member disconnected from redo source for longer than specified
threshold
This error won’t go away even when I manually catch it up.
Scott Canaan ‘88
Sr Database Administrator
Information & Technology Services
Finance & Administration
Rochester Institute of Technology
o: (585) 475-7886 | f: (585) 475-7520
srcdco@xxxxxxx<mailto:srcdco@xxxxxxx> | 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@xxxxxxxxx<mailto:andrew.kerber@xxxxxxxxx>>
Sent: Thursday, September 16, 2021 4:54 PM
To: nupendra@xxxxxxxxxxx<mailto:nupendra@xxxxxxxxxxx>
Cc: oracle-l@xxxxxxxxxxxxx<mailto:oracle-l@xxxxxxxxxxxxx>; Scott Canaan
<srcdco@xxxxxxx<mailto:srcdco@xxxxxxx>>
Subject: Re: Data Guard Issue
CAUTION: This message came from outside RIT. If you are unsure about the source
or content of this message, please contact the RIT Service Center at
585-475-5000 or help.rit.edu before clicking links, opening attachments or
responding.
It would be good to see what is showing up in the alert logs, but sometimes you
can fix issues by cancelling and restarting managed standby or by setting the
log_archive_dest to defer, then enable.
On Thu, Sep 16, 2021 at 3:32 PM Upendra nerilla
<nupendra@xxxxxxxxxxx<mailto:nupendra@xxxxxxxxxxx>> wrote:
On your primary db, you could disable and enable the standby arch dest.. that
might fix it.
________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx<mailto:oracle-l-bounce@xxxxxxxxxxxxx>
<oracle-l-bounce@xxxxxxxxxxxxx<mailto:oracle-l-bounce@xxxxxxxxxxxxx>> on behalf
of Scott Canaan <srcdco@xxxxxxx<mailto:srcdco@xxxxxxx>>
Sent: Thursday, September 16, 2021 3:53 PM
To: 'oracle-l@xxxxxxxxxxxxx<mailto:oracle-l@xxxxxxxxxxxxx>'
<oracle-l@xxxxxxxxxxxxx<mailto:oracle-l@xxxxxxxxxxxxx>>
Subject: Data Guard Issue
Earlier today, I had the sysadmins add disk space to the physical standby
server. Apparently the interruption to do that was longer than data guard
liked. It stopped sending the logs from the primary to the standby. I have
manually caught up by copying the missing logs and registering them with the
standby. It applies them as soon as I do that, but any newer logs are not
being shipped from the primary to the standby. I can’t figure out why and how
to fix it.
This is Oracle 19c 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@xxxxxxx<mailto:srcdco@xxxxxxx> | 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.'
