It might be possible that an issue arose on a specific archive log on the standby database. For example the log is corrupt or the size is wrong or the standby database cannot apply it for some reason.
In this case it would be good to identify the trace file on the primary server that will detail the process when this log was transferred to the standby server. To do this you can run the following query on the primary database to get the
PROCESS_ID (PID) for the process that transferred this log. You can then use this
PROCESS_ID to find the trace file. The trace file name will have format of:
Once you have identified the file, you can then log a ticket with Dbvisit Support with this trace file attached.
To identify this trace file run the SQL below on the primary server, providing the archive log in question's sequence#.
Run this on the primary database as the "dbvisit" repository user:
set linesize 200 col source_host for a15 col destination_host for a15 col process for a15 col oracle_sid for a10 select oracle_sid, sequence#, timestamp, source_host, destination_host, size_in_bytes, process_completed, process, process_id from dbv_transfer_log where sequence#=
<archive log sequence that showed 0 size>
SQL> select oracle_sid, sequence#, timestamp, source_host, destination_host, size_in_bytes, process_completed, process, process_id from dbv_transfer_log where sequence#=260; ORACLE_SID SEQUENCE# TIMESTAMP SOURCE_HOST DESTINATION_HOS SIZE_IN_BYTES P PROCESS PROCESS_ID
testdb 260 201312162205 DBVAWSWIN02 DBVAWSWIN01 8208384 Y COMPRESS 2948 testdb 260 201312162205 DBVAWSWIN02 DBVAWSWIN01 1786834 Y TRANSFER 2948
The trace file for the above process was:
Anton Els December 17, 2013 12:02