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:
<PROCESS\_ID>_dbvisit_<DDC>_yyyymmddhhmi.trcOnce 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_IDtestdb 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: 2948_dbvisit_testdb_201312162205
Anton Els December 17, 2013 12:02
Comments