Re: Need help with standby database REAL TIME APPLY

Turns out I didn't have a choice to keep the standby. They mounted the wrong disks and wanted them back. After I got the correct disks mounted, I created my diskgroup with 512 sector_size, which required using the parameter "asm_diskstring=/dev/oracleasm/disks/*". The standby build worked like a charm. Thanks to everyone for your help and suggestions. This forum really rocks with the wonderful support from the community.

Sandy

On Wed, Jul 29, 2020 at 9:17 AM Sandra Becker <sbecker6925_at_gmail.com> wrote:

> I think I'm going to have to blow everything away and recreate my
> diskgroup with a sector size of 512. That parameter doesn't seem to be
> working on these servers. Not sure why it did on the other one.
>
>
> On Wed, Jul 29, 2020 at 8:44 AM Sandra Becker <sbecker6925_at_gmail.com>
> wrote:
>
>> I can't create them with a blocksize of 512. It throws errors. We do
>> have another primary/standby configuration where the blocksize changed and
>> we didn't have any issues with that one. It was done by another DBA 2
>> years ago and she's no longer with the company, so I can't ask her if she
>> did anything specific. She didn't leave any notes either.
>>
>> ORA-00301: error in adding log file '+DATA' - file cannot be created
>> ORA-17502: ksfdcre:4 Failed to create file +DATA
>> ORA-15347: logical block size 512 of ASM file '+DATA' is too small for
>> disk group sector size 4096
>>
>> On Wed, Jul 29, 2020 at 8:09 AM Sandra Becker <sbecker6925_at_gmail.com>
>> wrote:
>>
>>> I'll try recreating with the blocksize parameter.
>>> Sandy
>>>
>>> On Wed, Jul 29, 2020 at 8:05 AM Andre Maasikas <amaasikas_at_gmail.com>
>>> wrote:
>>>
>>>> > You'll note the different blocksize. The standby is on newer storage.
>>>> That's probably the reason it cannot use the standby logfiles.
>>>> You can specify BLOCKSIZE 512 when creating the (standby)log files. (
>>>> ..ADD LOGFILE ... SIZE ... BLOCKSIZE 512 )
>>>> The storage array says it prefers 4096 byte blocks for performance
>>>> reasons but it works with 512 also,
>>>>
>>>> Andre
>>>>
>>>> On Wed, Jul 29, 2020 at 4:50 PM Sandra Becker <sbecker6925_at_gmail.com>
>>>> wrote:
>>>> >
>>>> > I found that output odd as well. I don't have any online redo for
>>>> Thread 0. Yes, I do the log switch and the primary catches up, but starts
>>>> to fall behind again..
>>>> >
>>>> > Query Results
>>>> > select * from v$log;
>>>> > You'll note the different blocksize. The standby is on newer storage.
>>>> > Primary:
>>>> > GROUP# THREAD# SEQUENCE# BYTES BLOCKSIZE MEMBERS ARC
>>>> STATUS FIRST_CHANGE# FIRST_TIME NEXT_CHANGE# NEXT_TIME
>>>> CON_ID
>>>> > ---------- ---------- ---------- ---------- ---------- ---------- ---
>>>> ---------- ------------- ------------------- ------------
>>>> ------------------- ----------
>>>> > 11 1 29356 1073741824 512 2 YES
>>>> INACTIVE 3.1313E+11 2018-10-06 22:31:22 3.1313E+11 2018-10-06
>>>> 23:05:03 0
>>>> > 12 1 29354 1073741824 512 2 YES
>>>> INACTIVE 3.1313E+11 2018-10-06 22:30:16 3.1313E+11 2018-10-06
>>>> 22:31:17 0
>>>> > 14 2 187465 1073741824 512 2 NO
>>>> CURRENT 3.7676E+11 2020-07-29 13:30:01 2.8147E+14
>>>> 0
>>>> > 15 2 187464 1073741824 512 2 YES
>>>> ACTIVE 3.7676E+11 2020-07-29 13:15:02 3.7676E+11 2020-07-29
>>>> 13:30:01 0
>>>> >
>>>> > Standby:
>>>> > GROUP# THREAD# SEQUENCE# BYTES BLOCKSIZE MEMBERS ARC
>>>> STATUS FIRST_CHANGE# FIRST_TIME NEXT_CHANGE# NEXT_TIME
>>>> CON_ID
>>>> > ---------- ---------- ---------- ---------- ---------- ---------- ---
>>>> ---------- ------------- ------------------- ------------
>>>> ------------------- ----------
>>>> > 1 1 0 1073741824 4096 2 YES
>>>> UNUSED 0 0
>>>> 0
>>>> > 2 1 0 1073741824 4096 2 YES
>>>> UNUSED 0 0
>>>> 0
>>>> > 3 2 0 1073741824 4096 2 YES
>>>> UNUSED 0 0
>>>> 0
>>>> > 4 2 0 1073741824 4096 2 YES
>>>> UNUSED 0 0
>>>> 0
>>>> >
>>>> > select * from v$standby_log;
>>>> > Primary:
>>>> > GROUP# DBID THREAD# SEQUENCE# BYTES
>>>> BLOCKSIZE USED ARC STATUS FIRST_CHANGE# FIRST_TIME
>>>> NEXT_CHANGE# NEXT_TIME LAST_CHANGE# LAST_TIME CON_ID
>>>> > ---------- --------------- ---------- ---------- ----------
>>>> ---------- ---------- --- ---------- ------------- -------------------
>>>> ------------ ------------------- ------------ ------------------- ----------
>>>> > 21 UNASSIGNED 1 0 1073741824
>>>> 512 0 YES UNASSIGNED
>>>> 0
>>>> > 22 UNASSIGNED 1 0 1073741824
>>>> 512 0 YES UNASSIGNED
>>>> 0
>>>> > 23 UNASSIGNED 1 0 1073741824
>>>> 512 0 YES UNASSIGNED
>>>> 0
>>>> > 24 UNASSIGNED 1 0 1073741824
>>>> 512 0 YES UNASSIGNED
>>>> 0
>>>> > 25 UNASSIGNED 1 0 1073741824
>>>> 512 0 YES UNASSIGNED
>>>> 0
>>>> > 31 UNASSIGNED 2 0 1073741824
>>>> 512 0 YES UNASSIGNED
>>>> 0
>>>> > 32 UNASSIGNED 2 0 1073741824
>>>> 512 0 YES UNASSIGNED
>>>> 0
>>>> > 33 UNASSIGNED 2 0 1073741824
>>>> 512 0 YES UNASSIGNED
>>>> 0
>>>> > 34 UNASSIGNED 2 0 1073741824
>>>> 512 0 YES UNASSIGNED
>>>> 0
>>>> > 35 UNASSIGNED 2 0 1073741824
>>>> 512 0 YES UNASSIGNED
>>>> > Standby:
>>>> > GROUP# DBID THREAD# SEQUENCE# BYTES
>>>> BLOCKSIZE USED ARC STATUS FIRST_CHANGE# FIRST_TIME
>>>> NEXT_CHANGE# NEXT_TIME LAST_CHANGE# LAST_TIME CON_ID
>>>> > ---------- --------------- ---------- ---------- ----------
>>>> ---------- ---------- --- ---------- ------------- -------------------
>>>> ------------ ------------------- ------------ ------------------- ----------
>>>> > 21 UNASSIGNED 1 0 1073741824
>>>> 4096 0 YES UNASSIGNED
>>>> 0
>>>> > 22 UNASSIGNED 1 0 1073741824
>>>> 4096 0 YES UNASSIGNED
>>>> 0
>>>> > 23 UNASSIGNED 1 0 1073741824
>>>> 4096 0 YES UNASSIGNED
>>>> 0
>>>> > 24 UNASSIGNED 1 0 1073741824
>>>> 4096 0 YES UNASSIGNED
>>>> 0
>>>> > 25 UNASSIGNED 1 0 1073741824
>>>> 4096 0 YES UNASSIGNED
>>>> 0
>>>> > 31 UNASSIGNED 2 0 1073741824
>>>> 4096 0 YES UNASSIGNED
>>>> 0
>>>> > 32 UNASSIGNED 2 0 1073741824
>>>> 4096 0 YES UNASSIGNED
>>>> 0
>>>> > 33 UNASSIGNED 2 0 1073741824
>>>> 4096 0 YES UNASSIGNED
>>>> 0
>>>> > 34 UNASSIGNED 2 0 1073741824
>>>> 4096 0 YES UNASSIGNED
>>>> 0
>>>> > 35 UNASSIGNED 2 0 1073741824
>>>> 4096 0 YES UNASSIGNED
>>>> >
>>>> > select * from v$logfile order by type,group#;
>>>> > I see two of the primary online log members have a status of
>>>> INVALID. I will be fixing those immediately.
>>>> > GROUP# STATUS TYPE MEMBER
>>>> IS_ CON_ID
>>>> > ---------- ---------- --------
>>>> ------------------------------------------------------- --- ----------
>>>> > 11 INVALID ONLINE
>>>> +DATA/UTILS/ONLINELOG/group_11.1091.1046544645 NO 0
>>>> > 11 ONLINE
>>>> +DATA/utils/onlinelog/group_11.921.918836807 NO 0
>>>> > 12 INVALID ONLINE
>>>> +DATA/UTILS/ONLINELOG/group_12.1092.1046544657 NO 0
>>>> > 12 ONLINE
>>>> +DATA/utils/onlinelog/group_12.923.918836815 NO 0
>>>> > 14 ONLINE
>>>> +DATA/utils/onlinelog/group_14.925.918836829 NO 0
>>>> > 14 ONLINE
>>>> +DATA/UTILS/ONLINELOG/group_14.1094.1046544697 NO 0
>>>> > 15 ONLINE
>>>> +DATA/utils/onlinelog/group_15.926.918836837 NO 0
>>>> > 15 ONLINE
>>>> +DATA/UTILS/ONLINELOG/group_15.1095.1046544707 NO 0
>>>> > 21 STANDBY
>>>> +DATA/UTILS/ONLINELOG/group_21.1118.1046959599 YES 0
>>>> > 21 STANDBY
>>>> +DATA/UTILS/ONLINELOG/group_21.1119.1046959595 NO 0
>>>> > 22 STANDBY
>>>> +DATA/UTILS/ONLINELOG/group_22.1116.1046959605 YES 0
>>>> > 22 STANDBY
>>>> +DATA/UTILS/ONLINELOG/group_22.1117.1046959603 NO 0
>>>> > 23 STANDBY
>>>> +DATA/UTILS/ONLINELOG/group_23.1115.1046959611 NO 0
>>>> > 23 STANDBY
>>>> +DATA/UTILS/ONLINELOG/group_23.1114.1046959615 YES 0
>>>> > 24 STANDBY
>>>> +DATA/UTILS/ONLINELOG/group_24.1113.1046959617 NO 0
>>>> > 24 STANDBY
>>>> +DATA/UTILS/ONLINELOG/group_24.1112.1046959621 YES 0
>>>> > 25 STANDBY
>>>> +DATA/UTILS/ONLINELOG/group_25.922.1046959623 NO 0
>>>> > 25 STANDBY
>>>> +DATA/UTILS/ONLINELOG/group_25.547.1046959627 YES 0
>>>> > 31 STANDBY
>>>> +DATA/UTILS/ONLINELOG/group_31.924.1046959631 NO 0
>>>> > 31 STANDBY
>>>> +DATA/UTILS/ONLINELOG/group_31.1093.1046959633 YES 0
>>>> > 32 STANDBY
>>>> +DATA/UTILS/ONLINELOG/group_32.1104.1046959637 NO 0
>>>> > 32 STANDBY
>>>> +DATA/UTILS/ONLINELOG/group_32.1105.1046959641 YES 0
>>>> > 33 STANDBY
>>>> +DATA/UTILS/ONLINELOG/group_33.1106.1046959643 NO 0
>>>> > 33 STANDBY
>>>> +DATA/UTILS/ONLINELOG/group_33.1107.1046959647 YES 0
>>>> > 34 STANDBY
>>>> +DATA/UTILS/ONLINELOG/group_34.1108.1046959651 NO 0
>>>> > 34 STANDBY
>>>> +DATA/UTILS/ONLINELOG/group_34.1109.1046959655 YES 0
>>>> > 35 STANDBY
>>>> +DATA/UTILS/ONLINELOG/group_35.1110.1046959657 NO 0
>>>> > 35 STANDBY
>>>> +DATA/UTILS/ONLINELOG/group_35.1111.1046959661 YES 0
>>>> >
>>>> > Standby:
>>>> > GROUP# STATUS TYPE MEMBER
>>>> IS_ CON_ID
>>>> > ---------- ---------- --------
>>>> ------------------------------------------------------- --- ----------
>>>> > 1 ONLINE
>>>> +DATA/UTILS_DB1/ONLINELOG/group_1.270.1046894003 NO 0
>>>> > 1 ONLINE
>>>> +DATA/UTILS_DB1/ONLINELOG/group_1.271.1046894003 NO 0
>>>> > 2 ONLINE
>>>> +DATA/UTILS_DB1/ONLINELOG/group_2.274.1046894005 NO 0
>>>> > 2 ONLINE
>>>> +DATA/UTILS_DB1/ONLINELOG/group_2.272.1046894005 NO 0
>>>> > 3 ONLINE
>>>> +DATA/UTILS_DB1/ONLINELOG/group_3.281.1046961383 NO 0
>>>> > 3 ONLINE
>>>> +DATA/UTILS_DB1/ONLINELOG/group_3.282.1046961381 NO 0
>>>> > 4 ONLINE
>>>> +DATA/UTILS_DB1/ONLINELOG/group_4.340.1046961385 NO 0
>>>> > 4 ONLINE
>>>> +DATA/UTILS_DB1/ONLINELOG/group_4.341.1046961383 NO 0
>>>> > 21 STANDBY
>>>> +DATA/UTILS_DB1/ONLINELOG/group_21.330.1046959789 NO 0
>>>> > 21 STANDBY
>>>> +DATA/UTILS_DB1/ONLINELOG/group_21.331.1046959791 YES 0
>>>> > 22 STANDBY
>>>> +DATA/UTILS_DB1/ONLINELOG/group_22.332.1046959791 NO 0
>>>> > 22 STANDBY
>>>> +DATA/UTILS_DB1/ONLINELOG/group_22.333.1046959793 YES 0
>>>> > 23 STANDBY
>>>> +DATA/UTILS_DB1/ONLINELOG/group_23.261.1046959793 NO 0
>>>> > 23 STANDBY
>>>> +DATA/UTILS_DB1/ONLINELOG/group_23.260.1046959795 YES 0
>>>> > 24 STANDBY
>>>> +DATA/UTILS_DB1/ONLINELOG/group_24.259.1046959797 NO 0
>>>> > 24 STANDBY
>>>> +DATA/UTILS_DB1/ONLINELOG/group_24.325.1046959797 YES 0
>>>> > 25 STANDBY
>>>> +DATA/UTILS_DB1/ONLINELOG/group_25.326.1046959799 NO 0
>>>> > 25 STANDBY
>>>> +DATA/UTILS_DB1/ONLINELOG/group_25.327.1046959799 YES 0
>>>> > 31 STANDBY
>>>> +DATA/UTILS_DB1/ONLINELOG/group_31.328.1046959801 NO 0
>>>> > 31 STANDBY
>>>> +DATA/UTILS_DB1/ONLINELOG/group_31.329.1046959801 YES 0
>>>> > 32 STANDBY
>>>> +DATA/UTILS_DB1/ONLINELOG/group_32.269.1046959803 YES 0
>>>> > 32 STANDBY
>>>> +DATA/UTILS_DB1/ONLINELOG/group_32.268.1046959803 NO 0
>>>> > 33 STANDBY
>>>> +DATA/UTILS_DB1/ONLINELOG/group_33.266.1046959805 YES 0
>>>> > 33 STANDBY
>>>> +DATA/UTILS_DB1/ONLINELOG/group_33.267.1046959805 NO 0
>>>> > 34 STANDBY
>>>> +DATA/UTILS_DB1/ONLINELOG/group_34.264.1046959807 YES 0
>>>> > 34 STANDBY
>>>> +DATA/UTILS_DB1/ONLINELOG/group_34.265.1046959807 NO 0
>>>> > 35 STANDBY
>>>> +DATA/UTILS_DB1/ONLINELOG/group_35.263.1046959809 YES 0
>>>> > 35 STANDBY
>>>> +DATA/UTILS_DB1/ONLINELOG/group_35.262.1046959809 NO 0
>>>> >
>>>> > select * from v$dataguard_stats order by name;
>>>> > We are forcing a log switch every 15 minutes to ensure we don't fall
>>>> too far behind on this database. It has periods of a few hours before it
>>>> has enough activity to do a normal switch.
>>>> >
>>>> > SOURCE_DBID SOURCE_DB_ NAME VALUE
>>>> UNIT TIME_COMPUTED
>>>> DATUM_TIME CON_ID
>>>> > ----------- ---------- -------------------------
>>>> ------------------------- ------------------------------
>>>> ------------------------------ ---------------------- ----------
>>>> > 0 apply finish time
>>>> day(2) to second(3) interval 07/29/2020 13:45:41
>>>> 0
>>>> > 0 apply lag +00 00:00:00
>>>> day(2) to second(0) interval 07/29/2020 13:45:41
>>>> 07/29/2020 13:45:01 0
>>>> > 0 estimated startup time 30
>>>> second 07/29/2020 13:45:41
>>>> 0
>>>> > 0 transport lag +00 00:00:00
>>>> day(2) to second(0) interval 07/29/2020 13:45:41
>>>> 07/29/2020 13:45:01 0
>>>> >
>>>> >
>>>> > On Tue, Jul 28, 2020 at 3:50 PM Neil Chandler <
>>>> neil_chandler_at_hotmail.com> wrote:
>>>> >>
>>>> >> Sandy,
>>>> >>
>>>> >> the only thing that looks strange in the output below is:
>>>> >>
>>>> >> Current Log File Groups Configuration:
>>>> >> Thread # Online Redo Log Groups Standby Redo Log Groups Status
>>>> >> (UTILS) (UTILS_DB1)
>>>> >> 0 26 0
>>>> Insufficient SRLs
>>>> >> Warning: standby redo logs not configured for thread 0 on
>>>> UTILS_DB1
>>>> >> 1 2 5
>>>> Sufficient SRLs
>>>> >>
>>>> >>
>>>> >> You have 26 online redo log groups on Thread 0 on the primary?
>>>> >>
>>>> >> on the primary and on the standby, can you remove anything that
>>>> interferes with the output, like "break on thread#" and
>>>> >>
>>>> >> select * from v$log;
>>>> >> select * from v$standby_log;
>>>> >> select * from v$logfile;
>>>> >>
>>>> >> and compare the output.
>>>> >>
>>>> >> I assume if you do an "alter system archive log current" on the
>>>> primary and check the standby, it does a catch-up then starts to fall
>>>> behind again?
>>>> >>
>>>> >> select * from v$dataguard_stats order by name;
>>>> >>
>>>> >> Neil Chandler
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> ________________________________
>>>> >> From: oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org>
>>>> on behalf of Sandra Becker <sbecker6925_at_gmail.com>
>>>> >> Sent: 28 July 2020 18:43
>>>> >> To: Hameed, Amir <Amir.Hameed_at_xerox.com>
>>>> >> Cc: Andrew Kerber <andrew.kerber_at_gmail.com>; Leng Burgess <
>>>> lkaing_at_gmail.com>; oracle-l <oracle-l_at_freelists.org>
>>>> >> Subject: Re: Need help with standby database REAL TIME APPLY
>>>> >>
>>>> >> I had dropped/recreated the log files several times already. I did
>>>> try to defer/enable the standby destination from the primary. It didn't
>>>> make a difference.
>>>> >>
>>>> >>
>>>> >> Sandy
>>>> >>
>>>> >> On Tue, Jul 28, 2020 at 11:33 AM Hameed, Amir <Amir.Hameed_at_xerox.com>
>>>> wrote:
>>>> >>
>>>> >> Hi Sandy,
>>>> >>
>>>> >> I have seen similar issue in the past and the solution was to drop
>>>> all SRL and recreate them. Once you do that, you may also want to DISABLE
>>>> the standby destination from primary and then re-enable it.
>>>> >>
>>>> >>
>>>> >>
>>>> >> Thanks,
>>>> >>
>>>> >> Amir
>>>> >>
>>>> >> From: oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org>
>>>> On Behalf Of Sandra Becker
>>>> >> Sent: Tuesday, July 28, 2020 12:21 PM
>>>> >> To: Andrew Kerber <andrew.kerber_at_gmail.com>
>>>> >> Cc: Leng Burgess <lkaing_at_gmail.com>; oracle-l <
>>>> oracle-l_at_freelists.org>
>>>> >> Subject: Re: Need help with standby database REAL TIME APPLY
>>>> >>
>>>> >>
>>>> >>
>>>> >> I verified all online and standby logs are the same size on both the
>>>> primary and the standby. Unfortunately, we no longer have Oracle support.
>>>> My boss cancelled it earlier this year as a money saving strategy. We do
>>>> have support from Spinnaker, but they've been less than helpful the last 3
>>>> times I tried to get help from them. Guess that's my only option right
>>>> now. Worst case scenario, I wipe out the standby and start all over. I
>>>> was trying to avoid that scenario.
>>>> >>
>>>> >>
>>>> >>
>>>> >> Thanks everyone for your help.
>>>> >>
>>>> >>
>>>> >>
>>>> >> Sandy
>>>> >>
>>>> >>
>>>> >>
>>>> >> Sandy
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Tue, Jul 28, 2020 at 10:13 AM Andrew Kerber <
>>>> andrew.kerber_at_gmail.com> wrote:
>>>> >>
>>>> >> Ok, kind of a shot in the dark, but look at the gv$standby_logfile
>>>> view and make sure all the standby logs and redo logs are the same size. If
>>>> thats not the issue, get with Oracle support, I cant think of anything else.
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Tue, Jul 28, 2020 at 10:57 AM Sandra Becker <
>>>> sbecker6925_at_gmail.com> wrote:
>>>> >>
>>>> >> Stopped/started managed recovery. No change.
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Tue, Jul 28, 2020 at 9:48 AM Andrew Kerber <
>>>> andrew.kerber_at_gmail.com> wrote:
>>>> >>
>>>> >> Now you might stop and start managed recovery and see if that helps.
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Tue, Jul 28, 2020 at 10:47 Sandra Becker <sbecker6925_at_gmail.com>
>>>> wrote:
>>>> >>
>>>> >> From the primary:
>>>> >>
>>>> >> ** Online Redo **
>>>> >>
>>>> >> THREAD# GROUP# SEQUENCE# MBR MBYTES ARC STATUS
>>>> FIRST_TIME
>>>> >> ------- ------- ---------- --- ---------- ---
>>>> ------------------------- -------------------
>>>> >> 1 11 29356 2 1024 YES INACTIVE
>>>> 2018-10-06 22:31:22
>>>> >> 1 12 29354 2 1024 YES INACTIVE
>>>> 2018-10-06 22:30:16
>>>> >> 2 14 187355 2 1024 NO CURRENT
>>>> 2020-07-28 15:30:01
>>>> >> 2 15 187354 2 1024 YES INACTIVE
>>>> 2020-07-28 15:15:01
>>>> >>
>>>> >>
>>>> >>
>>>> >> From the standby:
>>>> >>
>>>> >> SELECT TYPE, COUNT(*) FROM V$LOGFILE GROUP BY TYPE;
>>>> >>
>>>> >> TYPE COUNT(*)
>>>> >> -------- ----------
>>>> >> ONLINE 8
>>>> >> STANDBY 20
>>>> >>
>>>> >>
>>>> >>
>>>> >> Neil - I have the break on thread# set in my session. I did
>>>> explicitly use the THREAD 1 (or 2) when I added the standby redo logs to
>>>> both the primary and the standby. I also dropped the standby redo logs for
>>>> THREAD 0.
>>>> >>
>>>> >>
>>>> >>
>>>> >> Sandy
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Tue, Jul 28, 2020 at 9:00 AM Andrew Kerber <
>>>> andrew.kerber_at_gmail.com> wrote:
>>>> >>
>>>> >> Can you please send us the same output for the redo logs on the
>>>> primary? (not the standby redo logs)?
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Tue, Jul 28, 2020 at 9:31 AM Sandra Becker <sbecker6925_at_gmail.com>
>>>> wrote:
>>>> >>
>>>> >> I have 5 SRLs for each thread, but the alert log still says "No
>>>> standby redo logfiles available for T-2".
>>>> >>
>>>> >>
>>>> >>
>>>> >> SELECT
>>>> >> thread#,group#, sequence#, used, archived, status,
>>>> ROUND(bytes/1024/1024) mbytes, last_time
>>>> >> FROM v$standby_log
>>>> >> ORDER BY
>>>> >> thread#,
>>>> >> group#;
>>>> >>
>>>> >>
>>>> >>
>>>> >> THREAD# GROUP# SEQUENCE# USED ARC STATUS
>>>> MBYTES LAST_TIME
>>>> >> ------- ------- ---------- ---------- --- -------------------------
>>>> ---------- -------------------
>>>> >> 1 21 0 0 YES UNASSIGNED
>>>> 1024
>>>> >> 22 0 0 YES UNASSIGNED
>>>> 1024
>>>> >> 23 0 0 YES UNASSIGNED
>>>> 1024
>>>> >> 24 0 0 YES UNASSIGNED
>>>> 1024
>>>> >>
>>>> >> 25 0 0 YES UNASSIGNED
>>>> 1024
>>>> >>
>>>> >> 2 31 0 0 YES UNASSIGNED
>>>> 1024
>>>> >> 32 0 0 YES UNASSIGNED
>>>> 1024
>>>> >> 33 0 0 YES UNASSIGNED
>>>> 1024
>>>> >> 34 0 0 YES UNASSIGNED
>>>> 1024
>>>> >> 35 0 0 YES UNASSIGNED
>>>> 1024
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Tue, Jul 28, 2020 at 8:08 AM Sandra Becker <sbecker6925_at_gmail.com>
>>>> wrote:
>>>> >>
>>>> >> Ok, redoing the SRLs.
>>>> >>
>>>> >>
>>>> >>
>>>> >> Sandy
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Tue, Jul 28, 2020 at 7:45 AM Andrew Kerber <
>>>> andrew.kerber_at_gmail.com> wrote:
>>>> >>
>>>> >> You need one more srl per thread on the standby than primary redo
>>>> logs. Ie, if you have 4 redo logs per thread on the primary you need at
>>>> least 5 standby redo logs per thread.
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Tue, Jul 28, 2020 at 8:41 AM Sandra Becker <sbecker6925_at_gmail.com>
>>>> wrote:
>>>> >>
>>>> >> I added 6 more standby redo log groups to thread 2. Didn't make any
>>>> difference. Still seeing the message "RFS[8]: No standby redo logfiles
>>>> available for T-2". Today's dgmgrl output:
>>>> >>
>>>> >> Database Role: Physical standby database
>>>> >> Primary Database: UTILS
>>>> >>
>>>> >> Ready for Switchover: No
>>>> >> Ready for Failover: Yes (Primary Running)
>>>> >>
>>>> >> Capacity Information:
>>>> >> Database Instances Threads
>>>> >> UTILS 1 2
>>>> >> UTILS_DB1 1 1
>>>> >> Warning: the target standby has fewer instances than the
>>>> >> primary database, this may impact application performance
>>>> >>
>>>> >> Temporary Tablespace File Information:
>>>> >> UTILS TEMP Files: 1
>>>> >> UTILS_DB1 TEMP Files: 1
>>>> >>
>>>> >> Flashback Database Status:
>>>> >> UTILS: Off
>>>> >> UTILS_DB1: Off
>>>> >>
>>>> >> Data file Online Move in Progress:
>>>> >> UTILS: No
>>>> >> UTILS_DB1: No
>>>> >>
>>>> >> Standby Apply-Related Information:
>>>> >> Apply State: Running
>>>> >> Apply Lag: 2 minutes 9 seconds (computed 15 seconds ago)
>>>> >> Apply Delay: 0 minutes
>>>> >>
>>>> >> Transport-Related Information:
>>>> >> Transport On: Yes
>>>> >> Gap Status: No Gap
>>>> >> Transport Lag: 2 minutes 9 seconds (computed 15 seconds ago)
>>>> >> Transport Status: Success
>>>> >>
>>>> >> Log Files Cleared:
>>>> >> UTILS Standby Redo Log Files: Cleared
>>>> >> UTILS_DB1 Online Redo Log Files: Cleared
>>>> >> UTILS_DB1 Standby Redo Log Files: Available
>>>> >>
>>>> >> Current Log File Groups Configuration:
>>>> >> Thread # Online Redo Log Groups Standby Redo Log Groups Status
>>>> >> (UTILS) (UTILS_DB1)
>>>> >> 0 22 0
>>>> Insufficient SRLs
>>>> >> Warning: standby redo logs not configured for thread 0 on
>>>> UTILS_DB1
>>>> >> 1 2 4
>>>> Sufficient SRLs
>>>> >>
>>>> >> Future Log File Groups Configuration:
>>>> >> Thread # Online Redo Log Groups Standby Redo Log Groups Status
>>>> >> (UTILS_DB1) (UTILS)
>>>> >> 1 3 4
>>>> Sufficient SRLs
>>>> >>
>>>> >> Current Configuration Log File Sizes:
>>>> >> Thread # Smallest Online Redo Smallest Standby Redo
>>>> >> Log File Size Log File Size
>>>> >> (UTILS) (UTILS_DB1)
>>>> >> 1 1024 MBytes 1024 MBytes
>>>> >>
>>>> >> Future Configuration Log File Sizes:
>>>> >> Thread # Smallest Online Redo Smallest Standby Redo
>>>> >> Log File Size Log File Size
>>>> >> (UTILS_DB1) (UTILS)
>>>> >> 1 1024 MBytes 1024 MBytes
>>>> >>
>>>> >> Apply-Related Property Settings:
>>>> >> Property UTILS Value
>>>> UTILS_DB1 Value
>>>> >> DelayMins 0 0
>>>> >> ApplyParallel AUTO AUTO
>>>> >>
>>>> >> Transport-Related Property Settings:
>>>> >> Property UTILS Value
>>>> UTILS_DB1 Value
>>>> >> LogXptMode ASYNC ASYNC
>>>> >> RedoRoutes <empty> <empty>
>>>> >> Dependency <empty> <empty>
>>>> >> DelayMins 0 0
>>>> >> Binding optional optional
>>>> >> MaxFailure 0 0
>>>> >> MaxConnections 1 1
>>>> >> ReopenSecs 300 300
>>>> >> NetTimeout 30 30
>>>> >> RedoCompression DISABLE DISABLE
>>>> >> LogShipping ON ON
>>>> >>
>>>> >> Automatic Diagnostic Repository Errors:
>>>> >> Error UTILS UTILS_DB1
>>>> >> No logging operation NO NO
>>>> >> Control file corruptions NO NO
>>>> >> SRL Group Unavailable NO NO
>>>> >> System data file missing NO NO
>>>> >> System data file corrupted NO NO
>>>> >> System data file offline NO NO
>>>> >> User data file missing NO NO
>>>> >> User data file corrupted NO NO
>>>> >> User data file offline NO NO
>>>> >>
>>>> >>
>>>> >>
>>>> >> Sandy
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >
>>>> >
>>>> > --
>>>> > Sandy B.
>>>> >
>>>>
>>>
>>>
>>> --
>>> Sandy B.
>>>
>>>
>>
>> --
>> Sandy B.
>>
>>
>
> --
> Sandy B.
>
>

-- 
Sandy B.

--
http://www.freelists.org/webpage/oracle-l