Re: Troubleshooting log shipping

From: Nassyam Basha <nassyambasha_at_gmail.com>
Date: Fri, 8 Jan 2016 15:08:10 +0530
Message-ID: <CAABGLu+s=o-AQdYEpMLHYf_yossp0BXqkNHNXmF2VDU-HNJZWA_at_mail.gmail.com>



Hello Upendra,

If the configuration is perfect then the redo/archive should receive on remote destinations.
If you see below, you have mentioned service=SID_DR, can you confirm you have used the Oracle net service which points to the related standby database? and what about db_unique_name also you have mentioned SID_DR, it should be the unique name but not SID, so it depends on configuration however what the db_unique_name,sid, service configured.

"*service="SID_DR", LGWR ASYNC NOAFFIRM delay=0 optional compression=disable max_failure=0 max_connections=1 reopen=15*

*                                                 db_unique_name="SID_DR"
net_timeout=30, valid_for=(all_logfiles,primary_role)*"

Can you send output of this below query? Run them from primary.

set line 120 pages 100
col severity for a15
col message for a70
col timestamp for a20
select severity,error_code,to_char(timestamp,'DD-MON-YYYY HH24:MI:SS') "timestamp" , message from v$dataguard_status where dest_id=3; select ds.dest_id id

, ad.status
, ds.database_mode db_mode
, ad.archiver type
, ds.recovery_mode
, ds.protection_mode
, ds.standby_logfile_count "SRLs"
, ds.standby_logfile_active active
, ds.archived_seq#

from v$archive_dest_status ds
, v$archive_dest ad
where ds.dest_id = ad.dest_id
and ad.status != 'INACTIVE'
order by
ds.dest_id;

Thanks.

On Fri, Jan 8, 2016 at 1:22 PM, Upendra nerilla <nupendra_at_hotmail.com> wrote:

> Hello everyone -
> Happy new year!
>
> Oracle RAC 11.2.0.3
> OEL 5.x
>
> I have an environment in which the primary is shipping logs to a local
> standby and a remote dataguard database.
> What I am seeing is that, somehow not all the archivelogs are being
> shipped to the remote site. At the time of log apply these logs are being
> transmitted over.
>
> Here is an example on how the redologs appear in the remote site:
> 512 1860501 952576512 954204160
> thread_1_seq_434986.5778.900455621
> 512 1883168 964182016 965738496
> thread_1_seq_434991.8962.900456295
> 512 1850346 947377152 948961280
> thread_1_seq_434997.9060.900456899
> 512 1865067 954914304 956301312
> thread_1_seq_435003.3202.900457539
> 512 134582 68905984 70254592
> thread_1_seq_435008.1471.900457605
> 512 1848325 946342400 947912704
> thread_1_seq_435009.3990.900458259
> 512 1863147 953931264 955252736
> thread_1_seq_435017.6484.900458793
> 512 1834310 939166720 940572672
> thread_1_seq_435023.8233.900459079
> 512 1438234 736375808 738197504
> thread_1_seq_435024.11250.900460605
>
> Similar gaps for thread_2 as well..
>
> Here is the configuration of the log_archive_dest_3 on primary for the
> remote site:
>
> *service="SID_DR", LGWR ASYNC NOAFFIRM delay=0 optional
> compression=disable max_failure=0 max_connections=1
> reopen=15
> db_unique_name="SID_DR" net_timeout=30,
> valid_for=(all_logfiles,primary_role)*
>
> I do not see any errors for the redo transport in the alert log on the
> primary site or on the remote DG site.
> Any thoughts on how should I troubleshoot this? Are there any known bugs
> around this?
>
> Your help is appreciated.
>
> Thanks
> -Upendra
>

-- 
Nassyam Basha.
*Oracle Database Consultant*| *Pythian * <http://www.pythian.com/>
[image: ACED Profile]
<https://apex.oracle.com/pls/apex/f?p=19297:4:::NO:4:P4_ID:13140>
Oracle 11g Certified Master
<http://education.oracle.com/education/otn/NassyamBasha.htm>
Co-Author: Oracle Data Guard 11gR2
<http://www.amazon.in/Oracle-Guard-11gR2-Administration-Beginners/dp/1849687900>
Co-founder of Oraworld-team <http://www.oraworld-team.com>

[image: Facebook] <https://www.facebook.com/nassyambasha>  [image: Twitter]
<https://twitter.com/oracle_ckpt>  [image: LinkedIn]
<https://in.linkedin.com/in/nassyambasha>  [image: Google +]
<https://plus.google.com/+NassyamBasha>   [image: CKPT Blog]
<http://www.oracle-ckpt.com/>
<https://www.facebook.com/nassyambasha>

--
http://www.freelists.org/webpage/oracle-l
Received on Fri Jan 08 2016 - 10:38:10 CET

Original text of this message