Standby Log corruption -- in Recover phase
Hi All,
I am trying to set up RAC to RAC dataguard between 2 databases in different data centers.
I am able to ship archivelogs from primary to DR. The logs are not getting applied.
In the standby alert log -- I see the following errors (several of these CORRUPTION DETECTED Errors)
CORRUPTION DETECTED: In redo blocks starting at block 4097count 2048 for thread 4 sequence 15019
RFS[1185]: Possible network disconnect with primary database *Deleted Oracle managed file
+FR1/drdb/archivelog/2012_07_02/thread_4_seq_15019.578.787560321*
RFS[1186]: Possible network disconnect with primary database Mon Jul 02 06:45:36 2012
RFS[1189]: Assigned to RFS process 5016
RFS[1189]: Opened log for thread 2 sequence 12872 dbid 832151255 branch
782279895
*CORRUPTION DETECTED: In redo blocks starting at block 1count 2048 for thread 2 sequence 12872 Deleted Oracle managed file
+FR1/drdb/archivelog/2012_07_02/thread_2_seq_12872.578.787560337*
Mon Jul 02 06:45:38 2012
another thing is -- I have another application, where there is dataguard from RAC to single instance. For this I dont see any problem..
can anybody throw some light on this problem?
Thanks in advance..
Krishna
Edited by: user10697869 on Jul 2, 2012 4:02 AM
Right now, I dont have any corruption.
INST_ID PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS
1 ARCH CLOSING 1 31 10240 1775
1 ARCH CLOSING 3 32 8192 1243
1 ARCH CONNECTED 0 0 0 0
1 ARCH CLOSING 2 29 4096 1063
1 ARCH CLOSING 4 31 4096 719
1 RFS IDLE 0 0 0 0
2 ARCH CLOSING 3 34 6144 1046
2 ARCH CONNECTED 0 0 0 0
2 ARCH CLOSING 1 22 6144 911
2 ARCH CLOSING 3 35 10240 1556
2 ARCH CLOSING 4 23 1 1946
INST_ID PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS
2 RFS IDLE 0 0 0 0
2 RFS IDLE 0 0 0 0
2 RFS IDLE 0 0 0 0
2 RFS IDLE 0 0 0 0
2 RFS IDLE 0 0 0 0
2 MRP0 WAIT_FOR_LOG 3 11753 0 0
MRP0 is running -- but primary node say.. it cannot create archivelog..
this is from broker log.
Redo transport problem detected: redo transport for database drdb has the following error:
ORA-00270: error creating archive log
07/03/2012 01:45:28
Redo transport problem detected: redo transport for database drdb has the following error:
ORA-00270: error creating archive log
07/03/2012 01:46:28
Redo transport problem detected: redo transport for database drdb has the following error:
ORA-00270: error creating archive log
i dont understand why there is an error in creating archivelog..
I am printing my output of gv$logfile for both primary and standby..
Is there any thing wrong in this config??
"INST_ID" "GROUP#" "STATUS" "TYPE" "MEMBER" "IS_RECOVERY_DEST_FILE"
1 12 "" "ONLINE" "+DG1/primdb/onlinelog/group_12.257.783544139" "NO"
1 10 "" "ONLINE" "+REDO/primdb/onlinelog/group_10.257.784552287" "NO"
1 29 "" "STANDBY" "+DG1/primdb/onlinelog/group_29.264.787264987" "NO"
1 11 "" "ONLINE" "+REDO/primdb/onlinelog/group_11.258.784552299" "NO"
1 12 "" "ONLINE" "+REDO/primdb/onlinelog/group_12.259.784552311" "NO"
1 13 "" "ONLINE" "+REDO/primdb/onlinelog/group_13.260.784552323" "NO"
1 14 "" "ONLINE" "+REDO/primdb/onlinelog/group_14.261.784552335" "NO"
1 15 "" "ONLINE" "+REDO/primdb/onlinelog/group_15.262.784552347" "NO"
1 16 "" "ONLINE" "+REDO/primdb/onlinelog/group_16.263.784552363" "NO"
1 17 "" "ONLINE" "+REDO/primdb/onlinelog/group_17.264.784552377" "NO"
1 18 "" "ONLINE" "+REDO/primdb/onlinelog/group_18.265.784552391" "NO"
1 19 "" "ONLINE" "+REDO/primdb/onlinelog/group_19.266.784552403" "NO"
1 20 "" "ONLINE" "+REDO/primdb/onlinelog/group_20.267.784552413" "NO"
1 21 "" "ONLINE" "+REDO/primdb/onlinelog/group_21.268.784552423" "NO"
1 22 "" "ONLINE" "+REDO/primdb/onlinelog/group_22.269.784552433" "NO"
1 23 "" "ONLINE" "+REDO/primdb/onlinelog/group_23.270.784552445" "NO"
1 10 "" "ONLINE" "+DG1/primdb/onlinelog/group_10.284.783543933" "NO"
1 24 "" "ONLINE" "+REDO/primdb/onlinelog/group_24.271.784552453" "NO"
1 11 "" "ONLINE" "+DG1/primdb/onlinelog/group_11.285.783543979" "NO"
1 13 "" "ONLINE" "+DG1/primdb/onlinelog/group_13.286.783544253" "NO"
1 14 "" "ONLINE" "+DG1/primdb/onlinelog/group_14.287.783544347" "NO"
1 15 "" "ONLINE" "+DG1/primdb/onlinelog/group_15.288.783544531" "NO"
1 16 "" "ONLINE" "+DG1/primdb/onlinelog/group_16.289.783544655" "NO"
1 17 "" "ONLINE" "+DG1/primdb/onlinelog/group_17.290.783544659" "NO"
1 18 "" "ONLINE" "+DG1/primdb/onlinelog/group_18.291.783544685" "NO"
1 19 "" "ONLINE" "+DG1/primdb/onlinelog/group_19.292.783544691" "NO"
1 20 "" "ONLINE" "+DG1/primdb/onlinelog/group_20.293.783544697" "NO"
1 21 "" "ONLINE" "+DG1/primdb/onlinelog/group_21.294.783544701" "NO"
1 22 "" "ONLINE" "+DG1/primdb/onlinelog/group_22.295.783544717" "NO"
1 23 "" "ONLINE" "+DG1/primdb/onlinelog/group_23.296.783544721" "NO"
1 24 "" "ONLINE" "+DG1/primdb/onlinelog/group_24.297.783544727" "NO"
1 25 "" "ONLINE" "+DG1/primdb/onlinelog/group_25.298.783544731" "NO"
1 25 "" "ONLINE" "+REDO/primdb/onlinelog/group_25.272.784552459" "NO"
1 29 "" "STANDBY" "+FR1/primdb/onlinelog/group_29.4913.787264989" "NO"
1 30 "" "STANDBY" "+DG1/primdb/onlinelog/group_30.320.787264993" "NO"
1 30 "" "STANDBY" "+FR1/primdb/onlinelog/group_30.4912.787264995" "NO"
1 31 "" "STANDBY" "+DG1/primdb/onlinelog/group_31.319.787264997" "NO"
1 31 "" "STANDBY" "+FR1/primdb/onlinelog/group_31.4911.787264999" "NO"
1 32 "" "STANDBY" "+DG1/primdb/onlinelog/group_32.318.787265001" "NO"
1 32 "" "STANDBY" "+FR1/primdb/onlinelog/group_32.4910.787265003" "NO"
1 33 "" "STANDBY" "+DG1/primdb/onlinelog/group_33.317.787265005" "NO"
1 33 "" "STANDBY" "+FR1/primdb/onlinelog/group_33.4909.787265007" "NO"
1 34 "" "STANDBY" "+DG1/primdb/onlinelog/group_34.316.787265009" "NO"
1 34 "" "STANDBY" "+FR1/primdb/onlinelog/group_34.4908.787265011" "NO"
1 35 "" "STANDBY" "+DG1/primdb/onlinelog/group_35.315.787265013" "NO"
1 35 "" "STANDBY" "+FR1/primdb/onlinelog/group_35.4905.787265015" "NO"
1 36 "" "STANDBY" "+DG1/primdb/onlinelog/group_36.314.787265019" "NO"
1 36 "" "STANDBY" "+FR1/primdb/onlinelog/group_36.4904.787265021" "NO"
1 37 "" "STANDBY" "+DG1/primdb/onlinelog/group_37.313.787265023" "NO"
1 37 "" "STANDBY" "+FR1/primdb/onlinelog/group_37.4903.787265027" "NO"
1 38 "" "STANDBY" "+DG1/primdb/onlinelog/group_38.312.787265029" "NO"
1 38 "" "STANDBY" "+FR1/primdb/onlinelog/group_38.4902.787265031" "NO"
1 39 "" "STANDBY" "+DG1/primdb/onlinelog/group_39.263.787265033" "NO"
1 39 "" "STANDBY" "+FR1/primdb/onlinelog/group_39.4901.787265035" "NO"
1 40 "" "STANDBY" "+DG1/primdb/onlinelog/group_40.278.787265037" "NO"
1 40 "" "STANDBY" "+FR1/primdb/onlinelog/group_40.4899.787265039" "NO"
1 41 "" "STANDBY" "+DG1/primdb/onlinelog/group_41.279.787265041" "NO"
1 41 "" "STANDBY" "+FR1/primdb/onlinelog/group_41.4898.787265043" "NO"
1 42 "" "STANDBY" "+DG1/primdb/onlinelog/group_42.277.787265047" "NO"
1 42 "" "STANDBY" "+FR1/primdb/onlinelog/group_42.4897.787265049" "NO"
1 43 "" "STANDBY" "+DG1/primdb/onlinelog/group_43.276.787265051" "NO"
1 43 "" "STANDBY" "+FR1/primdb/onlinelog/group_43.4896.787265053" "NO"
1 44 "" "STANDBY" "+DG1/primdb/onlinelog/group_44.275.787265055" "NO"
1 44 "" "STANDBY" "+FR1/primdb/onlinelog/group_44.4894.787265057" "NO"
1 45 "" "STANDBY" "+DG1/primdb/onlinelog/group_45.282.787265259" "NO"
1 45 "" "STANDBY" "+FR1/primdb/onlinelog/group_45.4893.787265261" "NO"
1 47 "" "STANDBY" "+DG1/primdb/onlinelog/group_47.324.787265263" "NO"
1 47 "" "STANDBY" "+FR1/primdb/onlinelog/group_47.4892.787265265" "NO"
1 48 "" "STANDBY" "+DG1/primdb/onlinelog/group_48.325.787265267" "NO"
1 48 "" "STANDBY" "+FR1/primdb/onlinelog/group_48.4891.787265269" "NO"
1 46 "" "STANDBY" "+DG1/primdb/onlinelog/group_46.326.787265279" "NO"
1 46 "" "STANDBY" "+FR1/primdb/onlinelog/group_46.4890.787265281" "NO"
3 12 "" "ONLINE" "+DG1/primdb/onlinelog/group_12.257.783544139" "NO"
3 10 "" "ONLINE" "+REDO/primdb/onlinelog/group_10.257.784552287" "NO"
3 29 "" "STANDBY" "+DG1/primdb/onlinelog/group_29.264.787264987" "NO"
3 11 "" "ONLINE" "+REDO/primdb/onlinelog/group_11.258.784552299" "NO"
3 12 "" "ONLINE" "+REDO/primdb/onlinelog/group_12.259.784552311" "NO"
3 13 "" "ONLINE" "+REDO/primdb/onlinelog/group_13.260.784552323" "NO"
3 14 "" "ONLINE" "+REDO/primdb/onlinelog/group_14.261.784552335" "NO"
3 15 "" "ONLINE" "+REDO/primdb/onlinelog/group_15.262.784552347" "NO"
3 16 "" "ONLINE" "+REDO/primdb/onlinelog/group_16.263.784552363" "NO"
3 17 "" "ONLINE" "+REDO/primdb/onlinelog/group_17.264.784552377" "NO"
3 18 "" "ONLINE" "+REDO/primdb/onlinelog/group_18.265.784552391" "NO"
3 19 "" "ONLINE" "+REDO/primdb/onlinelog/group_19.266.784552403" "NO"
3 20 "" "ONLINE" "+REDO/primdb/onlinelog/group_20.267.784552413" "NO"
3 21 "" "ONLINE" "+REDO/primdb/onlinelog/group_21.268.784552423" "NO"
3 22 "" "ONLINE" "+REDO/primdb/onlinelog/group_22.269.784552433" "NO"
3 23 "" "ONLINE" "+REDO/primdb/onlinelog/group_23.270.784552445" "NO"
3 10 "" "ONLINE" "+DG1/primdb/onlinelog/group_10.284.783543933" "NO"
3 24 "" "ONLINE" "+REDO/primdb/onlinelog/group_24.271.784552453" "NO"
3 11 "" "ONLINE" "+DG1/primdb/onlinelog/group_11.285.783543979" "NO"
3 13 "" "ONLINE" "+DG1/primdb/onlinelog/group_13.286.783544253" "NO"
3 14 "" "ONLINE" "+DG1/primdb/onlinelog/group_14.287.783544347" "NO"
3 15 "" "ONLINE" "+DG1/primdb/onlinelog/group_15.288.783544531" "NO"
3 16 "" "ONLINE" "+DG1/primdb/onlinelog/group_16.289.783544655" "NO"
3 17 "" "ONLINE" "+DG1/primdb/onlinelog/group_17.290.783544659" "NO"
3 18 "" "ONLINE" "+DG1/primdb/onlinelog/group_18.291.783544685" "NO"
3 19 "" "ONLINE" "+DG1/primdb/onlinelog/group_19.292.783544691" "NO"
3 20 "" "ONLINE" "+DG1/primdb/onlinelog/group_20.293.783544697" "NO"
3 21 "" "ONLINE" "+DG1/primdb/onlinelog/group_21.294.783544701" "NO"
3 22 "" "ONLINE" "+DG1/primdb/onlinelog/group_22.295.783544717" "NO"
3 23 "" "ONLINE" "+DG1/primdb/onlinelog/group_23.296.783544721" "NO"
3 24 "" "ONLINE" "+DG1/primdb/onlinelog/group_24.297.783544727" "NO"
3 25 "" "ONLINE" "+DG1/primdb/onlinelog/group_25.298.783544731" "NO"
3 25 "" "ONLINE" "+REDO/primdb/onlinelog/group_25.272.784552459" "NO"
3 29 "" "STANDBY" "+FR1/primdb/onlinelog/group_29.4913.787264989" "NO"
3 30 "" "STANDBY" "+DG1/primdb/onlinelog/group_30.320.787264993" "NO"
3 30 "" "STANDBY" "+FR1/primdb/onlinelog/group_30.4912.787264995" "NO"
3 31 "" "STANDBY" "+DG1/primdb/onlinelog/group_31.319.787264997" "NO"
3 31 "" "STANDBY" "+FR1/primdb/onlinelog/group_31.4911.787264999" "NO"
3 32 "" "STANDBY" "+DG1/primdb/onlinelog/group_32.318.787265001" "NO"
3 32 "" "STANDBY" "+FR1/primdb/onlinelog/group_32.4910.787265003" "NO"
3 33 "" "STANDBY" "+DG1/primdb/onlinelog/group_33.317.787265005" "NO"
3 33 "" "STANDBY" "+FR1/primdb/onlinelog/group_33.4909.787265007" "NO"
3 34 "" "STANDBY" "+DG1/primdb/onlinelog/group_34.316.787265009" "NO"
3 34 "" "STANDBY" "+FR1/primdb/onlinelog/group_34.4908.787265011" "NO"
3 35 "" "STANDBY" "+DG1/primdb/onlinelog/group_35.315.787265013" "NO"
3 35 "" "STANDBY" "+FR1/primdb/onlinelog/group_35.4905.787265015" "NO"
3 36 "" "STANDBY" "+DG1/primdb/onlinelog/group_36.314.787265019" "NO"
3 36 "" "STANDBY" "+FR1/primdb/onlinelog/group_36.4904.787265021" "NO"
3 37 "" "STANDBY" "+DG1/primdb/onlinelog/group_37.313.787265023" "NO"
3 37 "" "STANDBY" "+FR1/primdb/onlinelog/group_37.4903.787265027" "NO"
3 38 "" "STANDBY" "+DG1/primdb/onlinelog/group_38.312.787265029" "NO"
3 38 "" "STANDBY" "+FR1/primdb/onlinelog/group_38.4902.787265031" "NO"
3 39 "" "STANDBY" "+DG1/primdb/onlinelog/group_39.263.787265033" "NO"
3 39 "" "STANDBY" "+FR1/primdb/onlinelog/group_39.4901.787265035" "NO"
3 40 "" "STANDBY" "+DG1/primdb/onlinelog/group_40.278.787265037" "NO"
3 40 "" "STANDBY" "+FR1/primdb/onlinelog/group_40.4899.787265039" "NO"
3 41 "" "STANDBY" "+DG1/primdb/onlinelog/group_41.279.787265041" "NO"
3 41 "" "STANDBY" "+FR1/primdb/onlinelog/group_41.4898.787265043" "NO"
3 42 "" "STANDBY" "+DG1/primdb/onlinelog/group_42.277.787265047" "NO"
3 42 "" "STANDBY" "+FR1/primdb/onlinelog/group_42.4897.787265049" "NO"
3 43 "" "STANDBY" "+DG1/primdb/onlinelog/group_43.276.787265051" "NO"
3 43 "" "STANDBY" "+FR1/primdb/onlinelog/group_43.4896.787265053" "NO"
3 44 "" "STANDBY" "+DG1/primdb/onlinelog/group_44.275.787265055" "NO"
3 44 "" "STANDBY" "+FR1/primdb/onlinelog/group_44.4894.787265057" "NO"
3 45 "" "STANDBY" "+DG1/primdb/onlinelog/group_45.282.787265259" "NO"
3 45 "" "STANDBY" "+FR1/primdb/onlinelog/group_45.4893.787265261" "NO"
3 47 "" "STANDBY" "+DG1/primdb/onlinelog/group_47.324.787265263" "NO"
3 47 "" "STANDBY" "+FR1/primdb/onlinelog/group_47.4892.787265265" "NO"
3 48 "" "STANDBY" "+DG1/primdb/onlinelog/group_48.325.787265267" "NO"
3 48 "" "STANDBY" "+FR1/primdb/onlinelog/group_48.4891.787265269" "NO"
3 46 "" "STANDBY" "+DG1/primdb/onlinelog/group_46.326.787265279" "NO"
3 46 "" "STANDBY" "+FR1/primdb/onlinelog/group_46.4890.787265281" "NO"
2 12 "" "ONLINE" "+DG1/primdb/onlinelog/group_12.257.783544139" "NO"
2 10 "" "ONLINE" "+REDO/primdb/onlinelog/group_10.257.784552287" "NO"
2 29 "" "STANDBY" "+DG1/primdb/onlinelog/group_29.264.787264987" "NO"
2 11 "" "ONLINE" "+REDO/primdb/onlinelog/group_11.258.784552299" "NO"
2 12 "" "ONLINE" "+REDO/primdb/onlinelog/group_12.259.784552311" "NO"
2 13 "" "ONLINE" "+REDO/primdb/onlinelog/group_13.260.784552323" "NO"
2 14 "" "ONLINE" "+REDO/primdb/onlinelog/group_14.261.784552335" "NO"
2 15 "" "ONLINE" "+REDO/primdb/onlinelog/group_15.262.784552347" "NO"
2 16 "" "ONLINE" "+REDO/primdb/onlinelog/group_16.263.784552363" "NO"
2 17 "" "ONLINE" "+REDO/primdb/onlinelog/group_17.264.784552377" "NO"
2 18 "" "ONLINE" "+REDO/primdb/onlinelog/group_18.265.784552391" "NO"
2 19 "" "ONLINE" "+REDO/primdb/onlinelog/group_19.266.784552403" "NO"
2 20 "" "ONLINE" "+REDO/primdb/onlinelog/group_20.267.784552413" "NO"
2 21 "" "ONLINE" "+REDO/primdb/onlinelog/group_21.268.784552423" "NO"
2 22 "" "ONLINE" "+REDO/primdb/onlinelog/group_22.269.784552433" "NO"
2 23 "" "ONLINE" "+REDO/primdb/onlinelog/group_23.270.784552445" "NO"
2 10 "" "ONLINE" "+DG1/primdb/onlinelog/group_10.284.783543933" "NO"
2 24 "" "ONLINE" "+REDO/primdb/onlinelog/group_24.271.784552453" "NO"
2 11 "" "ONLINE" "+DG1/primdb/onlinelog/group_11.285.783543979" "NO"
2 13 "" "ONLINE" "+DG1/primdb/onlinelog/group_13.286.783544253" "NO"
2 14 "" "ONLINE" "+DG1/primdb/onlinelog/group_14.287.783544347" "NO"
2 15 "" "ONLINE" "+DG1/primdb/onlinelog/group_15.288.783544531" "NO"
2 16 "" "ONLINE" "+DG1/primdb/onlinelog/group_16.289.783544655" "NO"
2 17 "" "ONLINE" "+DG1/primdb/onlinelog/group_17.290.783544659" "NO"
2 18 "" "ONLINE" "+DG1/primdb/onlinelog/group_18.291.783544685" "NO"
2 19 "" "ONLINE" "+DG1/primdb/onlinelog/group_19.292.783544691" "NO"
2 20 "" "ONLINE" "+DG1/primdb/onlinelog/group_20.293.783544697" "NO"
2 21 "" "ONLINE" "+DG1/primdb/onlinelog/group_21.294.783544701" "NO"
2 22 "" "ONLINE" "+DG1/primdb/onlinelog/group_22.295.783544717" "NO"
2 23 "" "ONLINE" "+DG1/primdb/onlinelog/group_23.296.783544721" "NO"
2 24 "" "ONLINE" "+DG1/primdb/onlinelog/group_24.297.783544727" "NO"
2 25 "" "ONLINE" "+DG1/primdb/onlinelog/group_25.298.783544731" "NO"
2 25 "" "ONLINE" "+REDO/primdb/onlinelog/group_25.272.784552459" "NO"
2 29 "" "STANDBY" "+FR1/primdb/onlinelog/group_29.4913.787264989" "NO"
2 30 "" "STANDBY" "+DG1/primdb/onlinelog/group_30.320.787264993" "NO"
2 30 "" "STANDBY" "+FR1/primdb/onlinelog/group_30.4912.787264995" "NO"
2 31 "" "STANDBY" "+DG1/primdb/onlinelog/group_31.319.787264997" "NO"
2 31 "" "STANDBY" "+FR1/primdb/onlinelog/group_31.4911.787264999" "NO"
2 32 "" "STANDBY" "+DG1/primdb/onlinelog/group_32.318.787265001" "NO"
2 32 "" "STANDBY" "+FR1/primdb/onlinelog/group_32.4910.787265003" "NO"
2 33 "" "STANDBY" "+DG1/primdb/onlinelog/group_33.317.787265005" "NO"
2 33 "" "STANDBY" "+FR1/primdb/onlinelog/group_33.4909.787265007" "NO"
2 34 "" "STANDBY" "+DG1/primdb/onlinelog/group_34.316.787265009" "NO"
2 34 "" "STANDBY" "+FR1/primdb/onlinelog/group_34.4908.787265011" "NO"
2 35 "" "STANDBY" "+DG1/primdb/onlinelog/group_35.315.787265013" "NO"
2 35 "" "STANDBY" "+FR1/primdb/onlinelog/group_35.4905.787265015" "NO"
2 36 "" "STANDBY" "+DG1/primdb/onlinelog/group_36.314.787265019" "NO"
2 36 "" "STANDBY" "+FR1/primdb/onlinelog/group_36.4904.787265021" "NO"
2 37 "" "STANDBY" "+DG1/primdb/onlinelog/group_37.313.787265023" "NO"
2 37 "" "STANDBY" "+FR1/primdb/onlinelog/group_37.4903.787265027" "NO"
2 38 "" "STANDBY" "+DG1/primdb/onlinelog/group_38.312.787265029" "NO"
2 38 "" "STANDBY" "+FR1/primdb/onlinelog/group_38.4902.787265031" "NO"
2 39 "" "STANDBY" "+DG1/primdb/onlinelog/group_39.263.787265033" "NO"
2 39 "" "STANDBY" "+FR1/primdb/onlinelog/group_39.4901.787265035" "NO"
2 40 "" "STANDBY" "+DG1/primdb/onlinelog/group_40.278.787265037" "NO"
2 40 "" "STANDBY" "+FR1/primdb/onlinelog/group_40.4899.787265039" "NO"
2 41 "" "STANDBY" "+DG1/primdb/onlinelog/group_41.279.787265041" "NO"
2 41 "" "STANDBY" "+FR1/primdb/onlinelog/group_41.4898.787265043" "NO"
2 42 "" "STANDBY" "+DG1/primdb/onlinelog/group_42.277.787265047" "NO"
2 42 "" "STANDBY" "+FR1/primdb/onlinelog/group_42.4897.787265049" "NO"
2 43 "" "STANDBY" "+DG1/primdb/onlinelog/group_43.276.787265051" "NO"
2 43 "" "STANDBY" "+FR1/primdb/onlinelog/group_43.4896.787265053" "NO"
2 44 "" "STANDBY" "+DG1/primdb/onlinelog/group_44.275.787265055" "NO"
2 44 "" "STANDBY" "+FR1/primdb/onlinelog/group_44.4894.787265057" "NO"
2 45 "" "STANDBY" "+DG1/primdb/onlinelog/group_45.282.787265259" "NO"
2 45 "" "STANDBY" "+FR1/primdb/onlinelog/group_45.4893.787265261" "NO"
2 47 "" "STANDBY" "+DG1/primdb/onlinelog/group_47.324.787265263" "NO"
2 47 "" "STANDBY" "+FR1/primdb/onlinelog/group_47.4892.787265265" "NO"
2 48 "" "STANDBY" "+DG1/primdb/onlinelog/group_48.325.787265267" "NO"
2 48 "" "STANDBY" "+FR1/primdb/onlinelog/group_48.4891.787265269" "NO"
2 46 "" "STANDBY" "+DG1/primdb/onlinelog/group_46.326.787265279" "NO"
2 46 "" "STANDBY" "+FR1/primdb/onlinelog/group_46.4890.787265281" "NO"
4 12 "" "ONLINE" "+DG1/primdb/onlinelog/group_12.257.783544139" "NO"
4 10 "" "ONLINE" "+REDO/primdb/onlinelog/group_10.257.784552287" "NO"
4 29 "" "STANDBY" "+DG1/primdb/onlinelog/group_29.264.787264987" "NO"
4 11 "" "ONLINE" "+REDO/primdb/onlinelog/group_11.258.784552299" "NO"
4 12 "" "ONLINE" "+REDO/primdb/onlinelog/group_12.259.784552311" "NO"
4 13 "" "ONLINE" "+REDO/primdb/onlinelog/group_13.260.784552323" "NO"
4 14 "" "ONLINE" "+REDO/primdb/onlinelog/group_14.261.784552335" "NO"
4 15 "" "ONLINE" "+REDO/primdb/onlinelog/group_15.262.784552347" "NO"
4 16 "" "ONLINE" "+REDO/primdb/onlinelog/group_16.263.784552363" "NO"
4 17 "" "ONLINE" "+REDO/primdb/onlinelog/group_17.264.784552377" "NO"
4 18 "" "ONLINE" "+REDO/primdb/onlinelog/group_18.265.784552391" "NO"
4 19 "" "ONLINE" "+REDO/primdb/onlinelog/group_19.266.784552403" "NO"
4 20 "" "ONLINE" "+REDO/primdb/onlinelog/group_20.267.784552413" "NO"
4 21 "" "ONLINE" "+REDO/primdb/onlinelog/group_21.268.784552423" "NO"
4 22 "" "ONLINE" "+REDO/primdb/onlinelog/group_22.269.784552433" "NO"
4 23 "" "ONLINE" "+REDO/primdb/onlinelog/group_23.270.784552445" "NO"
4 10 "" "ONLINE" "+DG1/primdb/onlinelog/group_10.284.783543933" "NO"
4 24 "" "ONLINE" "+REDO/primdb/onlinelog/group_24.271.784552453" "NO"
4 11 "" "ONLINE" "+DG1/primdb/onlinelog/group_11.285.783543979" "NO"
4 13 "" "ONLINE" "+DG1/primdb/onlinelog/group_13.286.783544253" "NO"
4 14 "" "ONLINE" "+DG1/primdb/onlinelog/group_14.287.783544347" "NO"
4 15 "" "ONLINE" "+DG1/primdb/onlinelog/group_15.288.783544531" "NO"
4 16 "" "ONLINE" "+DG1/primdb/onlinelog/group_16.289.783544655" "NO"
4 17 "" "ONLINE" "+DG1/primdb/onlinelog/group_17.290.783544659" "NO"
4 18 "" "ONLINE" "+DG1/primdb/onlinelog/group_18.291.783544685" "NO"
4 19 "" "ONLINE" "+DG1/primdb/onlinelog/group_19.292.783544691" "NO"
4 20 "" "ONLINE" "+DG1/primdb/onlinelog/group_20.293.783544697" "NO"
4 21 "" "ONLINE" "+DG1/primdb/onlinelog/group_21.294.783544701" "NO"
4 22 "" "ONLINE" "+DG1/primdb/onlinelog/group_22.295.783544717" "NO"
4 23 "" "ONLINE" "+DG1/primdb/onlinelog/group_23.296.783544721" "NO"
4 24 "" "ONLINE" "+DG1/primdb/onlinelog/group_24.297.783544727" "NO"
4 25 "" "ONLINE" "+DG1/primdb/onlinelog/group_25.298.783544731" "NO"
4 25 "" "ONLINE" "+REDO/primdb/onlinelog/group_25.272.784552459" "NO"
4 29 "" "STANDBY" "+FR1/primdb/onlinelog/group_29.4913.787264989" "NO"
4 30 "" "STANDBY" "+DG1/primdb/onlinelog/group_30.320.787264993" "NO"
4 30 "" "STANDBY" "+FR1/primdb/onlinelog/group_30.4912.787264995" "NO"
4 31 "" "STANDBY" "+DG1/primdb/onlinelog/group_31.319.787264997" "NO"
4 31 "" "STANDBY" "+FR1/primdb/onlinelog/group_31.4911.787264999" "NO"
4 32 "" "STANDBY" "+DG1/primdb/onlinelog/group_32.318.787265001" "NO"
4 32 "" "STANDBY" "+FR1/primdb/onlinelog/group_32.4910.787265003" "NO"
4 33 "" "STANDBY" "+DG1/primdb/onlinelog/group_33.317.787265005" "NO"
4 33 "" "STANDBY" "+FR1/primdb/onlinelog/group_33.4909.787265007" "NO"
4 34 "" "STANDBY" "+DG1/primdb/onlinelog/group_34.316.787265009" "NO"
4 34 "" "STANDBY" "+FR1/primdb/onlinelog/group_34.4908.787265011" "NO"
4 35 "" "STANDBY" "+DG1/primdb/onlinelog/group_35.315.787265013" "NO"
4 35 "" "STANDBY" "+FR1/primdb/onlinelog/group_35.4905.787265015" "NO"
4 36 "" "STANDBY" "+DG1/primdb/onlinelog/group_36.314.787265019" "NO"
4 36 "" "STANDBY" "+FR1/primdb/onlinelog/group_36.4904.787265021" "NO"
4 37 "" "STANDBY" "+DG1/primdb/onlinelog/group_37.313.787265023" "NO"
4 37 "" "STANDBY" "+FR1/primdb/onlinelog/group_37.4903.787265027" "NO"
4 38 "" "STANDBY" "+DG1/primdb/onlinelog/group_38.312.787265029" "NO"
4 38 "" "STANDBY" "+FR1/primdb/onlinelog/group_38.4902.787265031" "NO"
4 39 "" "STANDBY" "+DG1/primdb/onlinelog/group_39.263.787265033" "NO"
4 39 "" "STANDBY" "+FR1/primdb/onlinelog/group_39.4901.787265035" "NO"
4 40 "" "STANDBY" "+DG1/primdb/onlinelog/group_40.278.787265037" "NO"
4 40 "" "STANDBY" "+FR1/primdb/onlinelog/group_40.4899.787265039" "NO"
4 41 "" "STANDBY" "+DG1/primdb/onlinelog/group_41.279.787265041" "NO"
4 41 "" "STANDBY" "+FR1/primdb/onlinelog/group_41.4898.787265043" "NO"
4 42 "" "STANDBY" "+DG1/primdb/onlinelog/group_42.277.787265047" "NO"
4 42 "" "STANDBY" "+FR1/primdb/onlinelog/group_42.4897.787265049" "NO"
4 43 "" "STANDBY" "+DG1/primdb/onlinelog/group_43.276.787265051" "NO"
4 43 "" "STANDBY" "+FR1/primdb/onlinelog/group_43.4896.787265053" "NO"
4 44 "" "STANDBY" "+DG1/primdb/onlinelog/group_44.275.787265055" "NO"
4 44 "" "STANDBY" "+FR1/primdb/onlinelog/group_44.4894.787265057" "NO"
4 45 "" "STANDBY" "+DG1/primdb/onlinelog/group_45.282.787265259" "NO"
4 45 "" "STANDBY" "+FR1/primdb/onlinelog/group_45.4893.787265261" "NO"
4 47 "" "STANDBY" "+DG1/primdb/onlinelog/group_47.324.787265263" "NO"
4 47 "" "STANDBY" "+FR1/primdb/onlinelog/group_47.4892.787265265" "NO"
4 48 "" "STANDBY" "+DG1/primdb/onlinelog/group_48.325.787265267" "NO"
4 48 "" "STANDBY" "+FR1/primdb/onlinelog/group_48.4891.787265269" "NO"
4 46 "" "STANDBY" "+DG1/primdb/onlinelog/group_46.326.787265279" "NO"
4 46 "" "STANDBY" "+FR1/primdb/onlinelog/group_46.4890.787265281" "NO"
Similar Messages
-
RMAN-05501: RMAN-11003 ORA-00353: log corruption near block 2048 change
Hi Gurus,
I've posted few days ago an issue I got while recreating my Dataguard.
The Main issue was while duplicating target from active database I got this errors during the recovery process.
The Restore Process Went fine, RMAN Copied the Datafiles very well, but stop when at the moment to start the recovery process from the auxiliary db
Yesterday I took one last try,
I follow same procedure, the one described in all Oracle Docs, Google and so on ... it's not a secret I guess.
The I got the same issue, same errors.
I read soemthing about archivelogs, and the Block corruption and so on, I've tried so many things (register the log... etc etc ), and than I read something about "catalog the logfile)
and that's waht I did.
But I was just connect to the target db.
contents of Memory Script:
set until scn 1638816629;
recover
standby
clone database
delete archivelog
executing Memory Script
executing command: SET until clause
Starting recover at 14-MAY-13
starting media recovery
archived log for thread 1 with sequence 32196 is already on disk as file /archives/CMOVP/stby/1_32196_810397891.arc
archived log for thread 1 with sequence 32197 is already on disk as file /archives/CMOVP/stby/1_32197_810397891.arc
archived log for thread 1 with sequence 32198 is already on disk as file /archives/CMOVP/stby/1_32198_810397891.arc
archived log for thread 1 with sequence 32199 is already on disk as file /archives/CMOVP/stby/1_32199_810397891.arc
archived log for thread 1 with sequence 32200 is already on disk as file /archives/CMOVP/stby/1_32200_810397891.arc
archived log for thread 1 with sequence 32201 is already on disk as file /archives/CMOVP/stby/1_32201_810397891.arc
archived log for thread 1 with sequence 32202 is already on disk as file /archives/CMOVP/stby/1_32202_810397891.arc
archived log for thread 1 with sequence 32203 is already on disk as file /archives/CMOVP/stby/1_32203_810397891.arc
archived log for thread 1 with sequence 32204 is already on disk as file /archives/CMOVP/stby/1_32204_810397891.arc
archived log for thread 1 with sequence 32205 is already on disk as file /archives/CMOVP/stby/1_32205_810397891.arc
archived log for thread 1 with sequence 32206 is already on disk as file /archives/CMOVP/stby/1_32206_810397891.arc
archived log for thread 1 with sequence 32207 is already on disk as file /archives/CMOVP/stby/1_32207_810397891.arc
archived log for thread 1 with sequence 32208 is already on disk as file /archives/CMOVP/stby/1_32208_810397891.arc
archived log for thread 1 with sequence 32209 is already on disk as file /archives/CMOVP/stby/1_32209_810397891.arc
archived log for thread 1 with sequence 32210 is already on disk as file /archives/CMOVP/stby/1_32210_810397891.arc
archived log for thread 1 with sequence 32211 is already on disk as file /archives/CMOVP/stby/1_32211_810397891.arc
archived log for thread 1 with sequence 32212 is already on disk as file /archives/CMOVP/stby/1_32212_810397891.arc
archived log for thread 1 with sequence 32213 is already on disk as file /archives/CMOVP/stby/1_32213_810397891.arc
archived log for thread 1 with sequence 32214 is already on disk as file /archives/CMOVP/stby/1_32214_810397891.arc
archived log for thread 1 with sequence 32215 is already on disk as file /archives/CMOVP/stby/1_32215_810397891.arc
archived log for thread 1 with sequence 32216 is already on disk as file /archives/CMOVP/stby/1_32216_810397891.arc
archived log for thread 1 with sequence 32217 is already on disk as file /archives/CMOVP/stby/1_32217_810397891.arc
archived log for thread 1 with sequence 32218 is already on disk as file /archives/CMOVP/stby/1_32218_810397891.arc
archived log for thread 1 with sequence 32219 is already on disk as file /archives/CMOVP/stby/1_32219_810397891.arc
archived log for thread 1 with sequence 32220 is already on disk as file /archives/CMOVP/stby/1_32220_810397891.arc
archived log for thread 1 with sequence 32221 is already on disk as file /archives/CMOVP/stby/1_32221_810397891.arc
archived log for thread 1 with sequence 32222 is already on disk as file /archives/CMOVP/stby/1_32222_810397891.arc
archived log for thread 1 with sequence 32223 is already on disk as file /archives/CMOVP/stby/1_32223_810397891.arc
archived log file name=/archives/CMOVP/stby/1_32196_810397891.arc thread=1 sequence=32196
released channel: prm1
released channel: stby1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 05/14/2013 01:11:33
RMAN-05501: aborting duplication of target database
RMAN-03015: error occurred in stored script Memory Script
ORA-00283: recovery session canceled due to errors
RMAN-11003: failure during parse/execution of SQL statement: alter database recover logfile '/archives/CMOVP/stby/1_32196_810397891.arc'
ORA-00283: recovery session canceled due to errors
ORA-00354: corrupt redo log block header
ORA-00353: log corruption near block 2048 change 1638686297 time 05/13/2013 22:42:03
ORA-00334: archived log: '/archives/CMOVP/stby/1_32196_810397891.arc'
################# What I did: ################################
Rma target /
RMAN>catalog archivelog '/archives/CMOVP/stby/1_32196_810397891.arc';
The I connect to target and Auxiliary again :Rman target / catalog rman/rman@rman auxiliary
and I run the last content of the failing memory script:RMAN> run
set until scn 1638816629;
recover
standby
clone database
delete archivelog
And The DB start the recovery Process and my Standby complete the recovery very weel with message "Recovery Finnish or Termintaed or Completed"
The I could configure Datagurd
And I check the process and the Log Apply was on and running fine, no gaps, perfect!!!!!
How !!! Just Cataloging an "Supposed Corrupted"archive log !!!!!!
If Any ideas, that ould be great to understand this.
Rgds
CarlosokKarol wrote:
Hi Gurus,
I've posted few days ago an issue I got while recreating my Dataguard.
The Main issue was while duplicating target from active database I got this errors during the recovery process.
The Restore Process Went fine, RMAN Copied the Datafiles very well, but stop when at the moment to start the recovery process from the auxiliary db
Yesterday I took one last try,
I follow same procedure, the one described in all Oracle Docs, Google and so on ... it's not a secret I guess.
The I got the same issue, same errors.
I read soemthing about archivelogs, and the Block corruption and so on, I've tried so many things (register the log... etc etc ), and than I read something about "catalog the logfile)
and that's waht I did.
But I was just connect to the target db.
contents of Memory Script:
set until scn 1638816629;
recover
standby
clone database
delete archivelog
executing Memory Script
executing command: SET until clause
Starting recover at 14-MAY-13
starting media recovery
archived log for thread 1 with sequence 32196 is already on disk as file /archives/CMOVP/stby/1_32196_810397891.arc
archived log for thread 1 with sequence 32197 is already on disk as file /archives/CMOVP/stby/1_32197_810397891.arc
archived log for thread 1 with sequence 32198 is already on disk as file /archives/CMOVP/stby/1_32198_810397891.arc
archived log for thread 1 with sequence 32199 is already on disk as file /archives/CMOVP/stby/1_32199_810397891.arc
archived log for thread 1 with sequence 32200 is already on disk as file /archives/CMOVP/stby/1_32200_810397891.arc
archived log for thread 1 with sequence 32201 is already on disk as file /archives/CMOVP/stby/1_32201_810397891.arc
archived log for thread 1 with sequence 32202 is already on disk as file /archives/CMOVP/stby/1_32202_810397891.arc
archived log for thread 1 with sequence 32203 is already on disk as file /archives/CMOVP/stby/1_32203_810397891.arc
archived log for thread 1 with sequence 32204 is already on disk as file /archives/CMOVP/stby/1_32204_810397891.arc
archived log for thread 1 with sequence 32205 is already on disk as file /archives/CMOVP/stby/1_32205_810397891.arc
archived log for thread 1 with sequence 32206 is already on disk as file /archives/CMOVP/stby/1_32206_810397891.arc
archived log for thread 1 with sequence 32207 is already on disk as file /archives/CMOVP/stby/1_32207_810397891.arc
archived log for thread 1 with sequence 32208 is already on disk as file /archives/CMOVP/stby/1_32208_810397891.arc
archived log for thread 1 with sequence 32209 is already on disk as file /archives/CMOVP/stby/1_32209_810397891.arc
archived log for thread 1 with sequence 32210 is already on disk as file /archives/CMOVP/stby/1_32210_810397891.arc
archived log for thread 1 with sequence 32211 is already on disk as file /archives/CMOVP/stby/1_32211_810397891.arc
archived log for thread 1 with sequence 32212 is already on disk as file /archives/CMOVP/stby/1_32212_810397891.arc
archived log for thread 1 with sequence 32213 is already on disk as file /archives/CMOVP/stby/1_32213_810397891.arc
archived log for thread 1 with sequence 32214 is already on disk as file /archives/CMOVP/stby/1_32214_810397891.arc
archived log for thread 1 with sequence 32215 is already on disk as file /archives/CMOVP/stby/1_32215_810397891.arc
archived log for thread 1 with sequence 32216 is already on disk as file /archives/CMOVP/stby/1_32216_810397891.arc
archived log for thread 1 with sequence 32217 is already on disk as file /archives/CMOVP/stby/1_32217_810397891.arc
archived log for thread 1 with sequence 32218 is already on disk as file /archives/CMOVP/stby/1_32218_810397891.arc
archived log for thread 1 with sequence 32219 is already on disk as file /archives/CMOVP/stby/1_32219_810397891.arc
archived log for thread 1 with sequence 32220 is already on disk as file /archives/CMOVP/stby/1_32220_810397891.arc
archived log for thread 1 with sequence 32221 is already on disk as file /archives/CMOVP/stby/1_32221_810397891.arc
archived log for thread 1 with sequence 32222 is already on disk as file /archives/CMOVP/stby/1_32222_810397891.arc
archived log for thread 1 with sequence 32223 is already on disk as file /archives/CMOVP/stby/1_32223_810397891.arc
archived log file name=/archives/CMOVP/stby/1_32196_810397891.arc thread=1 sequence=32196
released channel: prm1
released channel: stby1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 05/14/2013 01:11:33
RMAN-05501: aborting duplication of target database
RMAN-03015: error occurred in stored script Memory Script
ORA-00283: recovery session canceled due to errors
RMAN-11003: failure during parse/execution of SQL statement: alter database recover logfile '/archives/CMOVP/stby/1_32196_810397891.arc'
ORA-00283: recovery session canceled due to errors
ORA-00354: corrupt redo log block header
ORA-00353: log corruption near block 2048 change 1638686297 time 05/13/2013 22:42:03
ORA-00334: archived log: '/archives/CMOVP/stby/1_32196_810397891.arc'
################# What I did: ################################
Rma target /
RMAN>catalog archivelog '/archives/CMOVP/stby/1_32196_810397891.arc';
The I connect to target and Auxiliary again :Rman target / catalog rman/rman@rman auxiliary
and I run the last content of the failing memory script:RMAN> run
set until scn 1638816629;
recover
standby
clone database
delete archivelog
And The DB start the recovery Process and my Standby complete the recovery very weel with message "Recovery Finnish or Termintaed or Completed"
The I could configure Datagurd
And I check the process and the Log Apply was on and running fine, no gaps, perfect!!!!!
How !!! Just Cataloging an "Supposed Corrupted"archive log !!!!!!
If Any ideas, that ould be great to understand this.
Rgds
CarlosHi,
Can you change standby database archive destination from /archives/CMOVP/stby/ other disk?
I think this problem on your disk.
Mahir
p.s. I remember you before thread, too -
I want to convert our old script based primary /standby database into a dataguard config using the LGWR as log transport.
I already have old log files on the standby database, but the data in them is from 2004. Not entirely interesting since the database gets recovered from the arch log files every night.
Point is, can I use these as standby log files, or do I have to (somehow) drop these and re-create new standby logfiles. I cant drop them anyway since when I try, I get "ORA-01624, log 1 needed for crash recovery". (Like h*ll, since the data is older than Noah).
Will these just get re-written?
null
nullNote:219344.1 This note from metalink gives "Usage, Benefits and Limitations of Standby Redo Logs (SRL)".
Standby Redo Logs are only supported for the Physical Standby Database in
Oracle 9i and as well for Logical Standby Databases in 10g. Standby Redo Logs
are only used if you have the LGWR activated for archival to the Remote Standby
Database.
The great Advantage of Standby Redo Logs is that every Entry written into
the Online RedoLogs of the Primary Database is transfered to the Standby
Site and written into the Standby Redo Logs at the same time; threfore, you
reduce the probability of Data Loss on the Standby Database. -
Log corruption near block 1737
hi,
i am getting an error while open the db
SQL> alter database open;
alter database open
ERROR at line 1:
ORA-00368: checksum error in redo log block
ORA-00353: log corruption near block 1737 change 16680088 time 12/22/2008
10:40:13
ORA-00312: online log 2 thread 1: 'G:\ORACLE\ORADATA\HOTEST\REDO02.LOG'while doing an incomplete recovery it is asking for an archived file which i am not having i.e ARC_801_1.ARC.........
SQL> recover database until cancel;
ORA-00279: change 16679127 generated at 12/22/2008 10:37:11 needed for thread 1
ORA-00289: suggestion : G:\ORACLE\ARCH\ARC_801_1.ARC
ORA-00280: change 16679127 for thread 1 is in sequence #801
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: 'G:\ORACLE\ORADATA\HOTEST\SYSTEM01.DBF'
ORA-01112: media recovery not startedpls suggest me for the same....I am not having a archived log of sequence no. 801 neither i am having backup, is there any other way to up the db....
SMON: enabling tx recovery
Mon Dec 22 10:37:16 2008
Database Characterset is WE8MSWIN1252
replication_dependency_tracking turned off (no async multimaster replication found)
Completed: alter database open
Corrupt block relative dba: 0x0300cc4b (file 12, block 52299)
Bad check value found during buffer read
Data in bad block -
type: 6 format: 2 rdba: 0x0300cc4b
last change scn: 0x0000.000fa127 seq: 0x1 flg: 0x06
consistency value in tail: 0xa1270601
check value in block header: 0x8f85, computed block checksum: 0xcf00
spare1: 0x0, spare2: 0x0, spare3: 0x0
Reread of rdba: 0x0300cc4b (file 12, block 52299) found valid data
Corrupt block relative dba: 0x0300cdfb (file 12, block 52731)
Bad check value found during buffer read
Data in bad block -
type: 6 format: 2 rdba: 0x0300cdfb
last change scn: 0x0000.000fa128 seq: 0x1 flg: 0x04
consistency value in tail: 0xa1280601
check value in block header: 0x446b, computed block checksum: 0x3200
spare1: 0x0, spare2: 0x0, spare3: 0x0
Reread of rdba: 0x0300cdfb (file 12, block 52731) found valid data
Dump file g:\oracle\admin\hotest\bdump\alert_hotest.log
Mon Dec 22 10:41:29 2008
ORACLE V9.2.0.4.0 - Production vsnsta=0
vsnsql=12 vsnxtr=3
Windows 2000 Version 5.1 Service Pack 2, CPU type 586
Mon Dec 22 10:41:29 2008
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
SCN scheme 2
Using log_archive_dest parameter default value
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up ORACLE RDBMS Version: 9.2.0.4.0.
System parameters with non-default values:
processes = 150
timed_statistics = TRUE
shared_pool_size = 50331648
large_pool_size = 8388608
java_pool_size = 33554432
control_files = G:\oracle\oradata\hotest\CONTROL01.CTL, G:\oracle\oradata\hotest\CONTROL02.CTL, G:\oracle\oradata\hotest\CONTROL03.CTL
db_block_size = 8192
db_cache_size = 25165824
compatible = 9.2.0.0.0
log_archive_start = TRUE
log_archive_dest_1 = location=G:\oracle\arch
log_archive_dest_2 = SERVICE=stand LGWR ASYNC
log_archive_dest_state_1 = ENABLE
log_archive_dest_state_2 = ENABLE
fal_server = STAND
fal_client = HOTEST
log_archive_format = arc_%s_%t.arc
db_file_multiblock_read_count= 16
fast_start_mttr_target = 300
undo_management = AUTO
undo_tablespace = UNDOTBS1
undo_retention = 10800
remote_login_passwordfile= EXCLUSIVE
db_domain =
instance_name = hotest
dispatchers = (PROTOCOL=TCP) (SERVICE=hotestXDB)
job_queue_processes = 10
hash_join_enabled = TRUE
background_dump_dest = G:\oracle\admin\hotest\bdump
user_dump_dest = G:\oracle\admin\hotest\udump
core_dump_dest = G:\oracle\admin\hotest\cdump
sort_area_size = 524288
db_name = hotest
open_cursors = 300
star_transformation_enabled= FALSE
query_rewrite_enabled = FALSE
pga_aggregate_target = 25165824
aq_tm_processes = 1
PMON started with pid=2
DBW0 started with pid=3
LGWR started with pid=4
CKPT started with pid=5
SMON started with pid=6
RECO started with pid=7
CJQ0 started with pid=8
QMN0 started with pid=9
Mon Dec 22 10:41:36 2008
starting up 1 shared server(s) ...
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
ARCH: STARTING ARCH PROCESSES
ARC0 started with pid=12
ARC0: Archival started
ARC1 started with pid=13
Mon Dec 22 10:41:37 2008
ARCH: STARTING ARCH PROCESSES COMPLETE
Mon Dec 22 10:41:37 2008
ARC0: Thread not mounted
Mon Dec 22 10:41:38 2008
ARC1: Archival started
Mon Dec 22 10:41:38 2008
ARC1: Thread not mounted
Mon Dec 22 10:41:38 2008
alter database mount exclusive
Mon Dec 22 10:41:43 2008
Successful mount of redo thread 1, with mount id 1003521250.
Mon Dec 22 10:41:43 2008
Database mounted in Exclusive Mode.
Completed: alter database mount exclusive
Mon Dec 22 10:41:43 2008
alter database open
Mon Dec 22 10:41:44 2008
Beginning crash recovery of 1 threads
Mon Dec 22 10:41:44 2008
Started first pass scan
ORA-368 signalled during: alter database open...
Mon Dec 22 10:42:35 2008
Restarting dead background process QMN0
QMN0 started with pid=9
Dump file g:\oracle\admin\hotest\bdump\alert_hotest.log
Mon Dec 29 10:14:22 2008
ORACLE V9.2.0.4.0 - Production vsnsta=0
vsnsql=12 vsnxtr=3
Windows 2000 Version 5.1 Service Pack 2, CPU type 586
Mon Dec 29 10:14:22 2008
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
SCN scheme 2
Using log_archive_dest parameter default value
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up ORACLE RDBMS Version: 9.2.0.4.0.
System parameters with non-default values:
processes = 150
timed_statistics = TRUE
shared_pool_size = 50331648
large_pool_size = 8388608
java_pool_size = 33554432
control_files = G:\oracle\oradata\hotest\CONTROL01.CTL, G:\oracle\oradata\hotest\CONTROL02.CTL, G:\oracle\oradata\hotest\CONTROL03.CTL
db_block_size = 8192
db_cache_size = 25165824
compatible = 9.2.0.0.0
log_archive_start = TRUE
log_archive_dest_1 = location=G:\oracle\arch
log_archive_dest_2 = SERVICE=stand LGWR ASYNC
log_archive_dest_state_1 = ENABLE
log_archive_dest_state_2 = ENABLE
fal_server = STAND
fal_client = HOTEST
log_archive_format = arc_%s_%t.arc
db_file_multiblock_read_count= 16
fast_start_mttr_target = 300
undo_management = AUTO
undo_tablespace = UNDOTBS1
undo_retention = 10800
remote_login_passwordfile= EXCLUSIVE
db_domain =
instance_name = hotest
dispatchers = (PROTOCOL=TCP) (SERVICE=hotestXDB)
job_queue_processes = 10
hash_join_enabled = TRUE
background_dump_dest = G:\oracle\admin\hotest\bdump
user_dump_dest = G:\oracle\admin\hotest\udump
core_dump_dest = G:\oracle\admin\hotest\cdump
sort_area_size = 524288
db_name = hotest
open_cursors = 300
star_transformation_enabled= FALSE
query_rewrite_enabled = FALSE
pga_aggregate_target = 25165824
aq_tm_processes = 1
PMON started with pid=2
DBW0 started with pid=3
LGWR started with pid=4
CKPT started with pid=5
SMON started with pid=6
RECO started with pid=7
CJQ0 started with pid=8
QMN0 started with pid=9
Mon Dec 29 10:14:28 2008
starting up 1 shared server(s) ...
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
ARCH: STARTING ARCH PROCESSES
ARC0 started with pid=12
ARC0: Archival started
ARC1 started with pid=13
ARC1: Archival started
Mon Dec 29 10:14:30 2008
ARCH: STARTING ARCH PROCESSES COMPLETE
Mon Dec 29 10:14:30 2008
ARC1: Thread not mounted
Mon Dec 29 10:14:31 2008
ARC0: Thread not mounted
Mon Dec 29 10:14:32 2008
alter database mount exclusive
Mon Dec 29 10:14:37 2008
Successful mount of redo thread 1, with mount id 1004122632.
Mon Dec 29 10:14:37 2008
Database mounted in Exclusive Mode.
Completed: alter database mount exclusive
Mon Dec 29 10:14:37 2008
alter database open
Mon Dec 29 10:14:37 2008
Beginning crash recovery of 1 threads
Mon Dec 29 10:14:38 2008
Started first pass scan
ORA-368 signalled during: alter database open...
Mon Dec 29 10:15:29 2008
Restarting dead background process QMN0
QMN0 started with pid=9
Mon Dec 29 10:20:44 2008
Restarting dead background process QMN0
QMN0 started with pid=9
Mon Dec 29 10:25:54 2008
Restarting dead background process QMN0
QMN0 started with pid=9
Mon Dec 29 10:31:09 2008
Restarting dead background process QMN0
QMN0 started with pid=9
Mon Dec 29 10:36:24 2008
Restarting dead background process QMN0
QMN0 started with pid=9
Mon Dec 29 10:41:40 2008
Restarting dead background process QMN0
QMN0 started with pid=9
Mon Dec 29 10:46:55 2008
Restarting dead background process QMN0
QMN0 started with pid=9
Mon Dec 29 10:52:10 2008
Restarting dead background process QMN0
QMN0 started with pid=9
Mon Dec 29 10:57:26 2008
Restarting dead background process QMN0
QMN0 started with pid=9
Mon Dec 29 11:02:41 2008
Restarting dead background process QMN0
QMN0 started with pid=9
Mon Dec 29 11:07:56 2008
Restarting dead background process QMN0
QMN0 started with pid=9
Mon Dec 29 11:13:05 2008
Restarting dead background process QMN0
QMN0 started with pid=9
Mon Dec 29 11:18:15 2008
Restarting dead background process QMN0
QMN0 started with pid=9
Mon Dec 29 11:23:30 2008
Restarting dead background process QMN0
QMN0 started with pid=9
Mon Dec 29 11:28:39 2008
Restarting dead background process QMN0
QMN0 started with pid=9
Mon Dec 29 11:33:49 2008
Restarting dead background process QMN0
QMN0 started with pid=9
Mon Dec 29 11:39:04 2008
Restarting dead background process QMN0
QMN0 started with pid=9
Mon Dec 29 11:44:19 2008
Restarting dead background process QMN0
QMN0 started with pid=9
Mon Dec 29 11:49:35 2008
Restarting dead background process QMN0
QMN0 started with pid=9
Mon Dec 29 11:54:44 2008
Restarting dead background process QMN0
QMN0 started with pid=15
Mon Dec 29 11:59:59 2008
Restarting dead background process QMN0
QMN0 started with pid=14
Mon Dec 29 12:03:06 2008
alter database open
Mon Dec 29 12:03:06 2008
Beginning crash recovery of 1 threads
Mon Dec 29 12:03:07 2008
Started first pass scan
ORA-368 signalled during: alter database open...
Mon Dec 29 12:05:09 2008
Restarting dead background process QMN0
QMN0 started with pid=15
Mon Dec 29 12:05:14 2008
ALTER DATABASE RECOVER database until cancel
Mon Dec 29 12:05:14 2008
Media Recovery Start
Starting datafile 1 recovery in thread 1 sequence 801
Datafile 1: 'G:\ORACLE\ORADATA\HOTEST\SYSTEM01.DBF'
Starting datafile 2 recovery in thread 1 sequence 801
Datafile 2: 'G:\ORACLE\ORADATA\HOTEST\UNDOTBS01.DBF'
Starting datafile 3 recovery in thread 1 sequence 801
Datafile 3: 'G:\ORACLE\ORADATA\HOTEST\CWMLITE01.DBF'
Starting datafile 4 recovery in thread 1 sequence 801
Datafile 4: 'G:\ORACLE\ORADATA\HOTEST\DRSYS01.DBF'
Starting datafile 5 recovery in thread 1 sequence 801
Datafile 5: 'G:\ORACLE\ORADATA\HOTEST\EXAMPLE01.DBF'
Starting datafile 6 recovery in thread 1 sequence 801
Datafile 6: 'G:\ORACLE\ORADATA\HOTEST\INDX01.DBF'
Starting datafile 7 recovery in thread 1 sequence 801
Datafile 7: 'G:\ORACLE\ORADATA\HOTEST\ODM01.DBF'
Starting datafile 8 recovery in thread 1 sequence 801
Datafile 8: 'G:\ORACLE\ORADATA\HOTEST\TOOLS01.DBF'
Starting datafile 9 recovery in thread 1 sequence 801
Datafile 9: 'G:\ORACLE\ORADATA\HOTEST\USERS01.DBF'
Starting datafile 10 recovery in thread 1 sequence 801
Datafile 10: 'G:\ORACLE\ORADATA\HOTEST\XDB01.DBF'
Starting datafile 11 recovery in thread 1 sequence 801
Datafile 11: 'G:\ORACLE\ORADATA\HOTEST\CADATA3.ORA'
Starting datafile 12 recovery in thread 1 sequence 801
Datafile 12: 'G:\ORACLE\ORADATA\HOTEST\CADATA.ORA'
Starting datafile 13 recovery in thread 1 sequence 801
Datafile 13: 'G:\ORACLE\ORADATA\HOTEST\CADATAWRO.ORA'
Starting datafile 14 recovery in thread 1 sequence 801
Datafile 14: 'G:\ORACLE\ORADATA\HOTEST\CADATANRO.ORA'
Starting datafile 15 recovery in thread 1 sequence 801
Datafile 15: 'G:\ORACLE\ORADATA\HOTEST\CADATACRO.ORA'
Starting datafile 16 recovery in thread 1 sequence 801
Datafile 16: 'G:\ORACLE\ORADATA\HOTEST\CADATAOTH.ORA'
Starting datafile 17 recovery in thread 1 sequence 801
Datafile 17: 'G:\ORACLE\ORADATA\HOTEST\CADATAERO.ORA'
Starting datafile 18 recovery in thread 1 sequence 801
Datafile 18: 'G:\ORACLE\ORADATA\HOTEST\CADATAHO.ORA'
Starting datafile 19 recovery in thread 1 sequence 801
Datafile 19: 'G:\ORACLE\ORADATA\HOTEST\CADATASRO.ORA'
Starting datafile 20 recovery in thread 1 sequence 801
Datafile 20: 'G:\ORACLE\ORADATA\HOTEST\PAYROLL.ORA'
Starting datafile 21 recovery in thread 1 sequence 801
Datafile 21: 'G:\ORACLE\ORADATA\HOTEST\ORION.ORA'
Starting datafile 22 recovery in thread 1 sequence 801
Datafile 22: 'G:\ORACLE\ORADATA\HOTEST\ATHENA.ORA'
Starting datafile 23 recovery in thread 1 sequence 801
Datafile 23: 'G:\ORACLE\ORADATA\HOTEST\CAL_YEAR_2004.ORA'
Starting datafile 24 recovery in thread 1 sequence 801
Datafile 24: 'G:\ORACLE\ORADATA\HOTEST\CAL_YEAR_2005.ORA'
Starting datafile 25 recovery in thread 1 sequence 801
Datafile 25: 'G:\ORACLE\ORADATA\HOTEST\CAL_YEAR_2006.ORA'
Starting datafile 26 recovery in thread 1 sequence 801
Datafile 26: 'G:\ORACLE\ORADATA\HOTEST\CAL_YEAR_2007.ORA'
Starting datafile 27 recovery in thread 1 sequence 801
Datafile 27: 'G:\ORACLE\ORADATA\HOTEST\CAL_YEAR_2008.ORA'
Starting datafile 28 recovery in thread 1 sequence 801
Datafile 28: 'G:\ORACLE\ORADATA\HOTEST\CAL_YEAR_2009.ORA'
Starting datafile 29 recovery in thread 1 sequence 801
Datafile 29: 'G:\ORACLE\ORADATA\HOTEST\EXAMPLE02.DBF'
Starting datafile 30 recovery in thread 1 sequence 801
Datafile 30: 'G:\ORACLE\ORADATA\HOTEST\EXAMPLE02.RAW'
Media Recovery Log
ORA-279 signalled during: ALTER DATABASE RECOVER database until cancel ...
Mon Dec 29 12:06:24 2008
ALTER DATABASE RECOVER CANCEL
Mon Dec 29 12:06:24 2008
ORA-1547 signalled during: ALTER DATABASE RECOVER CANCEL ...
Mon Dec 29 12:06:24 2008
ALTER DATABASE RECOVER CANCEL
ORA-1112 signalled during: ALTER DATABASE RECOVER CANCEL ...
Mon Dec 29 12:06:40 2008
alter database open resetlogs
Mon Dec 29 12:06:41 2008
ORA-1194 signalled during: alter database open resetlogs...
Mon Dec 29 12:06:47 2008
alter database open noresetlogs
Mon Dec 29 12:06:48 2008
Beginning crash recovery of 1 threads
Mon Dec 29 12:06:48 2008
Started first pass scan
ORA-368 signalled during: alter database open noresetlogs...
Mon Dec 29 12:10:24 2008
Restarting dead background process QMN0
QMN0 started with pid=15
Mon Dec 29 12:15:39 2008
Restarting dead background process QMN0
QMN0 started with pid=15
Mon Dec 29 12:20:55 2008
Restarting dead background process QMN0
QMN0 started with pid=15
Mon Dec 29 12:26:10 2008 -
Can not remove standby log file, please help
Hi,
My v$logfile
GROUP# STATUS TYPE MEMBER
IS_RECOVERY_DEST_FILE
3 ONLINE /u01/app/oracle/oradata/orcl/redo03.log
NO
2 ONLINE /u01/app/oracle/oradata/orcl/redo02.log
NO
1 ONLINE /u01/app/oracle/oradata/orcl/redo01.log
NO
GROUP# STATUS TYPE MEMBER
IS_RECOVERY_DEST_FILE
4 STANDBY /u01/app/oracle/oradata/orcl/stdlog01.log
NO
5 STANDBY /u01/app/oracle/oradata/orcl/stdlog02.log
NO
And when i clear standby log 5
SQL> alter database clear logfile group 5;
alter database clear logfile group 5
ERROR at line 1:
ORA-00600: internal error code, arguments: [2130], [0], [8], [2], [], [], [],[]
Please help me :(I hoping you can provide more information. v$log should not return information on standby, V$STANDBY_LOG will.
Are you preforming the query on the primary or standby side?
What version of Oracle are you using?
Why do you need to remove the standby log?
You should only have to clear a logfile if it has become corrupt, what make you think this is the case?
If you can provide more details if would be very helpful.
Best Regards
mseberg
Since you have posted the exact same question in the GENERAL DATABASE section and refuse to supply version information there you really have provide more details before anybody will help you.
Remove standby redo log, get ORA-00600
Edited by: mseberg on Apr 9, 2011 5:35 AM -
Standby logs in logical standby
I am currently running a logical standby database in an Oracle 10gR2/Linux environment.
The primary and standby databases both seem to be running fine, however I am concerned that there seems to be an excessively large number of standby log files marked as 'CURRENT' - 127 files spanning more then 36 hrs at the time of writing.
According to the alert log of the standby database, more than 35 standby log files were deleted last time a series of files was deleted.
Can anybody suggest why there would be such a large number of standby files marked as 'CURRENT'?? Is it possible to find out why these files are required, and therefore clear any potential blockage??
ThanksHI eceramm,
Thanks for you reply.
The last 100 line from the logical standby alert log are:
LOGMINER: End mining logfile: /opt/oracle/oradata/UATDR/onlinelog/o1_mf_4_3vpq26xd_.log
Tue May 6 08:08:41 2008
Thread 1 advanced to log sequence 8186
Current log# 1 seq# 8186 mem# 0: /opt/oracle/oradata/UATDR/onlinelog/o1_mf_1_3vpp35lp_.log
Current log# 1 seq# 8186 mem# 1: /opt/oracle/flash_recovery_area/UATDR/onlinelog/o1_mf_1_3vpp36s4_.log
Tue May 6 08:12:35 2008
RFS[4]: Successfully opened standby log 4: '/opt/oracle/oradata/UATDR/onlinelog/o1_mf_4_3vpq26xd_.log'
Tue May 6 08:12:35 2008
RFS LogMiner: Client enabled and ready for notification
Tue May 6 08:12:36 2008
RFS LogMiner: Registered logfile [opt/oracle/arch/standby/UATDR/1_6351_647020607.dbf] to LogMiner session id [1]
Tue May 6 08:12:36 2008
LOGMINER: Begin mining logfile: /opt/oracle/oradata/UATDR/onlinelog/o1_mf_4_3vpq26xd_.log
Tue May 6 08:12:36 2008
LOGMINER: End mining logfile: /opt/oracle/oradata/UATDR/onlinelog/o1_mf_4_3vpq26xd_.log
Tue May 6 08:38:42 2008
Thread 1 advanced to log sequence 8187
Current log# 3 seq# 8187 mem# 0: /opt/oracle/oradata/UATDR/onlinelog/o1_mf_3_3vpp39z0_.log
Current log# 3 seq# 8187 mem# 1: /opt/oracle/flash_recovery_area/UATDR/onlinelog/o1_mf_3_3vpp3bto_.log
Tue May 6 08:42:35 2008
RFS[6]: Successfully opened standby log 4: '/opt/oracle/oradata/UATDR/onlinelog/o1_mf_4_3vpq26xd_.log'
Tue May 6 08:42:35 2008
RFS LogMiner: Client enabled and ready for notification
Tue May 6 08:42:35 2008
RFS LogMiner: Registered logfile [opt/oracle/arch/standby/UATDR/1_6352_647020607.dbf] to LogMiner session id [1]
Tue May 6 08:42:35 2008
LOGMINER: Begin mining logfile: /opt/oracle/oradata/UATDR/onlinelog/o1_mf_4_3vpq26xd_.log
Tue May 6 08:42:35 2008
LOGMINER: End mining logfile: /opt/oracle/oradata/UATDR/onlinelog/o1_mf_4_3vpq26xd_.log
Tue May 6 09:08:42 2008
Thread 1 advanced to log sequence 8188
Current log# 2 seq# 8188 mem# 0: /opt/oracle/oradata/UATDR/onlinelog/o1_mf_2_3vpp37sc_.log
Current log# 2 seq# 8188 mem# 1: /opt/oracle/flash_recovery_area/UATDR/onlinelog/o1_mf_2_3vpp38pk_.log
Tue May 6 09:12:37 2008
RFS[7]: Successfully opened standby log 4: '/opt/oracle/oradata/UATDR/onlinelog/o1_mf_4_3vpq26xd_.log'
Tue May 6 09:12:37 2008
RFS LogMiner: Client enabled and ready for notification
Tue May 6 09:12:37 2008
RFS LogMiner: Registered logfile [opt/oracle/arch/standby/UATDR/1_6353_647020607.dbf] to LogMiner session id [1]
Tue May 6 09:12:37 2008
LOGMINER: Begin mining logfile: /opt/oracle/oradata/UATDR/onlinelog/o1_mf_4_3vpq26xd_.log
Tue May 6 09:12:37 2008
LOGMINER: End mining logfile: /opt/oracle/oradata/UATDR/onlinelog/o1_mf_4_3vpq26xd_.log
Tue May 6 09:38:43 2008
Thread 1 advanced to log sequence 8189
Current log# 1 seq# 8189 mem# 0: /opt/oracle/oradata/UATDR/onlinelog/o1_mf_1_3vpp35lp_.log
Current log# 1 seq# 8189 mem# 1: /opt/oracle/flash_recovery_area/UATDR/onlinelog/o1_mf_1_3vpp36s4_.log
Tue May 6 09:42:35 2008
RFS[4]: Successfully opened standby log 4: '/opt/oracle/oradata/UATDR/onlinelog/o1_mf_4_3vpq26xd_.log'
Tue May 6 09:42:35 2008
RFS LogMiner: Client enabled and ready for notification
Tue May 6 09:42:35 2008
LOGMINER: Begin mining logfile: /opt/oracle/oradata/UATDR/onlinelog/o1_mf_4_3vpq26xd_.log
Tue May 6 09:42:35 2008
RFS LogMiner: Registered logfile [opt/oracle/arch/standby/UATDR/1_6354_647020607.dbf] to LogMiner session id [1]
Tue May 6 09:42:35 2008
LOGMINER: End mining logfile: /opt/oracle/oradata/UATDR/onlinelog/o1_mf_4_3vpq26xd_.log
Tue May 6 10:08:41 2008
Thread 1 advanced to log sequence 8190
Current log# 3 seq# 8190 mem# 0: /opt/oracle/oradata/UATDR/onlinelog/o1_mf_3_3vpp39z0_.log
Current log# 3 seq# 8190 mem# 1: /opt/oracle/flash_recovery_area/UATDR/onlinelog/o1_mf_3_3vpp3bto_.log
Tue May 6 10:12:37 2008
RFS[6]: Successfully opened standby log 4: '/opt/oracle/oradata/UATDR/onlinelog/o1_mf_4_3vpq26xd_.log'
Tue May 6 10:12:37 2008
RFS LogMiner: Client enabled and ready for notification
Tue May 6 10:12:37 2008
RFS LogMiner: Registered logfile [opt/oracle/arch/standby/UATDR/1_6355_647020607.dbf] to LogMiner session id [1]
Tue May 6 10:12:37 2008
LOGMINER: Begin mining logfile: /opt/oracle/oradata/UATDR/onlinelog/o1_mf_4_3vpq26xd_.log
Tue May 6 10:12:37 2008
LOGMINER: End mining logfile: /opt/oracle/oradata/UATDR/onlinelog/o1_mf_4_3vpq26xd_.log
Tue May 6 10:38:43 2008
Thread 1 advanced to log sequence 8191
Current log# 2 seq# 8191 mem# 0: /opt/oracle/oradata/UATDR/onlinelog/o1_mf_2_3vpp37sc_.log
Current log# 2 seq# 8191 mem# 1: /opt/oracle/flash_recovery_area/UATDR/onlinelog/o1_mf_2_3vpp38pk_.log
Tue May 6 10:42:35 2008
RFS[7]: Successfully opened standby log 4: '/opt/oracle/oradata/UATDR/onlinelog/o1_mf_4_3vpq26xd_.log'
Tue May 6 10:42:35 2008
RFS LogMiner: Client enabled and ready for notification
Tue May 6 10:42:35 2008
RFS LogMiner: Registered logfile [opt/oracle/arch/standby/UATDR/1_6356_647020607.dbf] to LogMiner session id [1]
Tue May 6 10:42:35 2008
LOGMINER: Begin mining logfile: /opt/oracle/oradata/UATDR/onlinelog/o1_mf_4_3vpq26xd_.log
Tue May 6 10:42:35 2008
LOGMINER: End mining logfile: /opt/oracle/oradata/UATDR/onlinelog/o1_mf_4_3vpq26xd_.log
Tue May 6 11:08:41 2008
Thread 1 advanced to log sequence 8192
Current log# 1 seq# 8192 mem# 0: /opt/oracle/oradata/UATDR/onlinelog/o1_mf_1_3vpp35lp_.log
Current log# 1 seq# 8192 mem# 1: /opt/oracle/flash_recovery_area/UATDR/onlinelog/o1_mf_1_3vpp36s4_.log
Tue May 6 11:12:36 2008
RFS[4]: Successfully opened standby log 4: '/opt/oracle/oradata/UATDR/onlinelog/o1_mf_4_3vpq26xd_.log'
Tue May 6 11:12:36 2008
RFS LogMiner: Client enabled and ready for notification
Tue May 6 11:12:36 2008
LOGMINER: Begin mining logfile: /opt/oracle/oradata/UATDR/onlinelog/o1_mf_4_3vpq26xd_.log
Tue May 6 11:12:36 2008
RFS LogMiner: Registered logfile [opt/oracle/arch/standby/UATDR/1_6357_647020607.dbf] to LogMiner session id [1]
Tue May 6 11:12:36 2008
LOGMINER: End mining logfile: /opt/oracle/oradata/UATDR/onlinelog/o1_mf_4_3vpq26xd_.log
Thanks for your interest
Gavin -
Standby log files in Oracle Dataguard
Hi,
What is the difference between standby log files and online redo log files in a Dataguard environment?
What is the use of standby log files?
Thanks,
Charith.You're probably familiar with the Online Redo Logs (ORLs). Transaction changes are written from the Log Buffer to the ORLs by the LGWR process.
If you are setting up a physical standby, then you will want to create Standby Redo Logs (SRLs) in the standby database. When SRL's are in place, a process called LNS will transport redo from the Log Buffer of the primary to the RFS process on the standby which will write the redo to the SRLs. If the SRL does not exist, RFS can't do this. The biggest benefit of using SRLs is that you will experience much less data loss, even in MAX PERFORMANCE mode. Redo will constantly be shipped. You won't have to wait for ARCH to transport a full archived redo log.
Cheers,
Brian -
I erceived the following error in my alert log file:
Errors in file /app/oracle/diag/rdbms/peptest/PEPTEST1/trace/PEPTEST1_ora_8981.trc (incident=651420):
ORA-00353: log corruption near block 79361 change 6409669490 time 07/17/2013 11:59:33
ORA-00334: archived log: '+FLASH/peptest/archivelog/2013_07_17/thread_1_seq_118356.469.821016003'
ORA-07445: exception encountered: core dump [kzvd_objprivCheck()+1622] [SIGSEGV] [ADDR:0x38] [PC:0x193ECBE] [Address not mapped to object] []
Incident details in: /app/oracle/diag/rdbms/peptest/PEPTEST1/incident/incdir_651420/PEPTEST1_ora_8981_i651420.trc
The database version is Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production running on Linux wwhpepotst1 2.6.18-128.el5 #1 SMP Wed Jan 21 08:45:05 EST 2009 x86_64 x86_64 x86_64 GNU/Linux.
This is a RAC database with ASM.
The following is the extract from the trace file:
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x38] [PC:0x193ECBE, kzvd_objprivCheck()+1622]
Incident 651419 created, dump file: /app/oracle/diag/rdbms/peptest/PEPTEST1/incident/incdir_651419/PEPTEST1_ora_8981_i651419.trc
ORA-07445: exception encountered: core dump [kzvd_objprivCheck()+1622] [SIGSEGV] [ADDR:0x38] [PC:0x193ECBE] [Address not mapped to obj
ect] []
Incident 651420 created, dump file: /app/oracle/diag/rdbms/peptest/PEPTEST1/incident/incdir_651420/PEPTEST1_ora_8981_i651420.trc
ORA-00353: log corruption near block 79361 change 6409669490 time 07/17/2013 11:59:33
ORA-00334: archived log: '+FLASH/peptest/archivelog/2013_07_17/thread_1_seq_118356.469.821016003'
ORA-07445: exception encountered: core dump [kzvd_objprivCheck()+1622] [
Can I please have a suggestion on how to procced with resolving this issue?submit Service Request to My Oracle Support
-
I'm a bit confused about standby log files
Hi all,
I'm a bit confused about something and wondering if someone can explain.
I have a Primary database that ships logs to a Logical Standby database.
Everything appears to be working properly. If I check the v$archived_log table in the Primary and compare it to the dba_logstdby_log view in the Logical Standby, I'm seeing that logs are being applied.
On the logical standby, I have the following configured for log_archive_dest_n parameters:
*.log_archive_dest_1='LOCATION=/u01/oracle/archivedlogs/ORADB1
VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=PNX8A_GMD'
*.log_archive_dest_2='LOCATION=/u02/oracle/archivedlogs/ORADB1
VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=PNX8A_GMD'
*.log_archive_dest_3='LOCATION=/u03/oracle/archivedlogs/ORADB1
VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=PNX8A_GMD'
*.log_archive_dest_4='SERVICE=PNX8A_WDC ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=PNX8A_WDC'
*.log_archive_dest_5='LOCATION=/u01/oracle/standbylogs/ORADB1
VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=PNX8A_GMD'
*.log_archive_dest_6='LOCATION=/u02/oracle/standbylogs/ORADB1
VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=PNX8A_GMD'
*.log_archive_dest_7='LOCATION=/u03/oracle/standbylogs/ORADB1
VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=PNX8A_GMD'
Here is my confusion now. Before converting from a Physical standby database to a Logical Standby database, I was under the impression that I needed the standby logs (i.e. log_archive_dest_5, 6 and 7 above) because a Physical Standby database would receive the redo from the primary and write it into the standby logs before applying the redo in the standby logs to the Physical standby database.
I've now converted to a Logical Standby database. What's happening is that the standby logs are accumulating in the directory pointed to by log_archive_dest_6 above (/u02/oracle/standbylogs/ORADB1). They do not appear to be getting cleaned up by the database.
In the Logical Standby database I do have STANDBY_FILE_MANAGEMENT parameter set to AUTO. Can anyone explain to me why standby log files would continue to accumulate and how I can get the Logical Standby database to remove them after they are no longer needed on the LSB db?
Thanks in advance.
John SJSebastian wrote:
I assume you mean in your question, why on the standby database I am using three standby log locations (i.e. log_archive_dest_5, 6, and 7)?
If that is your question, my answer is that I just figured more than one location would be safer but I could be wrong about this. Can you tell me if only one location should be sufficient for the standby logs? The more I think of this, that is probably correct because I assume that Log Transport services will re-request the log from the Primary database if there is some kind of error at the standby location with the standby log. Is this correct?As simple configure as below. Why more multiple destinations for standby?
check notes Step by Step Guide on How to Create Logical Standby [ID 738643.1]
>
LOG_ARCHIVE_DEST_1='LOCATION=/arch1/boston VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_2='SERVICE=chicago LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_3='LOCATION=/arch2/boston/ VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=boston'
The following table describes the archival processing defined by the initialization parameters shown in Example 4-2.
When the Boston Database Is Running in the Primary Role When the Boston Database Is Running in the Logical Standby Role
LOG_ARCHIVE_DEST_1 Directs archival of redo data generated by the primary database from the local online redo log files to the local archived redo log files in /arch1/boston/. Directs archival of redo data generated by the logical standby database from the local online redo log files to the local archived redo log files in /arch1/boston/.
LOG_ARCHIVE_DEST_2 Directs transmission of redo data to the remote logical standby database chicago. Is ignored; LOG_ARCHIVE_DEST_2 is valid only when boston is running in the primary role.
LOG_ARCHIVE_DEST_3 Is ignored; LOG_ARCHIVE_DEST_3 is valid only when boston is running in the standby role. Directs archival of redo data received from the primary database to the local archived redo log files in /arch2/boston/.
>
Source:-
http://docs.oracle.com/cd/B19306_01/server.102/b14239/create_ls.htm -
HT1349 my laptop got corrupted and recovered but i am not able to connect my iphone to my laptop
my laptop got corrupted and recovered but i am not able to connect my iphone to my laptop. Pls help me to recovery my iphone.
I had the same problem with my wife's iPhone 4, go to settings, network an see if 3G is activated in your phone, also check if data is activated, if this don't work, than the problem is not in the phone but with the carrier.
Your phone may show the 3G or the Edge network icon next to the signal bar, but 3G and Edge may not be really activated for your phone in your carrier network, even if you have a data plan, sometimes their activation department kind of forget to activate the full service in their network, it already happen to us several times.
Call your carrier and confirm if they really activated the 3G or Edge data in your phone in their network according to your data plan . They may need your phone's EMEI and ICCID numbers, you will find it at settings, info
Hope that helps -
Launch daemon's, I have deleted the files in the folder and can not log in to recover the files , safe book didn't help can you ?
- Can you use Target Disk Mode : How to use and troubleshoot FireWire target disk mode to assist to recover the files.
- Need another Mac and a Firewire cable
Cheers -
Applying transaction log corrupted database?
Hi experts,
Symptoms:
I built a standby system this Monday and I completed a full DB restore without errors. I used log shipping to apply logs but an error occurred: SQL Server detected a logical consistency-based I/O error: incorrect pageid (expected 20:5746350; actual 0:0). It occurred during a read of page (20:5746350) in database ID 5 at offset 0x00000af5d5c000 in file 'l:\TCPDATA4\TCPDATA19.ndf'.
I run dbcc page and found page(20:5746350) did corrupt on standby system. However, I ran dbcc page on production and it is ok. I restored this full db to another standby and ran dbcc page and it is ok. Also, Checkalloc, Checkcatalog, Checktable on production are ok.
Questions:
Does checktable detect secondary indexes corruption? I am re-compressing COSP indexes and running full checkdb on production right now to find out what's going on in our DB. How do I fix this issue? Any information will be really appreciated.
Error message:
2011-08-23 17:26:00.19 spid52 The log shipping secondary database TCCDBM1.TCP has restore threshold of 45 minutes and is out of sync. No restore was performed for 1 minutes. Restored latency is 720 minutes. Check agent log and logshipping monitor information.
2011-08-23 17:26:39.62 Backup Log was restored. Database: TCP, creation date(time): 2011/07/03(05:36:16), first LSN: 184193:4075900:1, last LSN: 184193:7288500:1, number of dump devices: 1, device information: (FILE=1, TYPE=DISK: {'w:\LogB\TCP_20110822213010.trn'}). This is an informational message. No user action is required.
2011-08-23 17:28:00.88 spid52 Error: 14421, Severity: 16, State: 1.
2011-08-23 17:28:00.88 spid52 The log shipping secondary database TCCDBM1.TCP has restore threshold of 45 minutes and is out of sync. No restore was performed for 2 minutes. Restored latency is 716 minutes. Check agent log and logshipping monitor information.
2011-08-23 17:28:34.03 Backup Log was restored. Database: TCP, creation date(time): 2011/07/03(05:36:16), first LSN: 184193:7288500:1, last LSN: 184193:10880343:1, number of dump devices: 1, device information: (FILE=1, TYPE=DISK: {'w:\LogB\TCP_20110822213511.trn'}). This is an informational message. No user action is required.
2011-08-23 17:28:53.06 spid65 Error: 824, Severity: 16, State: 2.
2011-08-23 17:28:53.06 spid65 SQL Server detected a logical consistency-based I/O error: incorrect pageid (expected 20:5746350; actual 0:0). It occurred during a read of page (20:5746350) in database ID 5 at offset 0x00000af5d5c000 in file 'l:\TCPDATA4\TCPDATA19.ndf'. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.
2011-08-23 17:30:00.54 spid52 Error: 14421, Severity: 16, State: 1.
2011-08-23 17:30:00.54 spid52 The log shipping secondary database TCCDBM1.TCP has restore threshold of 45 minutes and is out of sync. No restore was performed for 2 minutes. Restored latency is 713 minutes. Check agent log and logshipping monitor information.
2011-08-23 17:30:35.94 spid53 Error: 824, Severity: 16, State: 2.Hi Dennis!
I understand your reasonable doubt, but think that physical corruptions are 99,999...% caused by a hardware failure e.g. a defective RAM module, or a related, low-level failure as e.g. an outdated NIC driver, etc.
Then, in this case it is clear that you have a platform problem only on your standby system, and not in the one running productively right now.
Maybe you already checked your platform, but you should take into account that in most cases just reading the logs is not enough; stress tests on all of the components are usually necessary. Most of the time, when we analyze hardware related problems, the problem is only reproduced when special tests are performed. Furthermore it is possible that more than one component is weak or broken.
My recommendation is that you check the components in this order:
- disks (complete surface) (while SAP and SQL Server are shut down)
- disk controller
- Memory (stress test)
- CPU
- all other components
Consider that restoring a backup and running in a damaged platform would imply further problems. You would be waiting until the next problem arises and that would imply a system halt or corruptions, maybe even with data loss.
Once the hardware checked and -if necessary- fixed, you can proceed as explained in SAP notes 142731 and 1420452. Of course you can also restore in a different hardware, but remember checking the platform as it is also exposed to hardware failures.
Cheers!!
--Jesú -
Suppose the current online redo log is corrupted, is there any way to make database functional other than doing incomplete recovery?
Oracle documentation says we have to do incomplete recovery. Is Cancel based Incomplete recovery the only option.
If this database is also the primary database for A physical standby database how to synchronize the Standby database with Primary? Since we would be opening Primary with Resetlogs....Incomplete Recovery upto the last (archive) redo log before the current one IS the only option.
Your current redo log would have some transactions in it. Also, the datafiles would have had some dirty blocks written to disk by DBWR. Therefore, the datafiles would be inconsistent until and unless you can apply the redo that goes with those changes. Since the redo cannot be applied from the corrupt file, the datafiles themselves must be reverted to a prior image -- upto the last redo that can be applied.
As for the standby, if you have Flashback configured, you can Flashback the Standby to the point 2 SCNs before the Primary Resetlogs.
See DataGuard Scenario 12.5 at
http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/scenarios.htm#i1049616
Else use Scenario 8.4 at
http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/manage_ps.htm#i1026480
Hemant K Chitale
http://hemantoracledba.blogspot.com
Edited by: Hemant K Chitale on Jul 22, 2009 12:13 AM -
Hi,
I have the following scenario
database (10g r2) is on achieve log mode on linux server. and i have multiplex my redolog files on 3 disks.
My redolog file are corrupt due to disk failure, how to recover them from other disks on with i have multiplexed them.
- Nimish GargYou don't recover redo log files. If you have a corrupted redo log file and is giving error to you, you should remove that redo log's information with alter database command. As you mentioned that the disk is corrupt, so the next step would be correct the error, create another member over the mount point and use it.
HTH
Aman.... -
How to find out which archived logs needed to recover a hot backup?
I'm using Oracle 11gR2 (11.2.0.1.0).
I have backed up a database when it is online using the following backup script through RMAN
connect target /
run {
allocate channel d1 type disk;
backup
incremental level=0 cumulative
filesperset 4
format '/san/u01/app/backup/DB_%d_%T_%u_%c.rman'
database
}The backup set contains the backup of datafiles and control file. I have copied all the backup pieces to another server where I will restore/recover the database but I don't know which archived logs are needed in order to restore/recover the database to a consistent state.
I have not deleted any archived log.
How can I find out which archived logs are needed to recover the hot backup to a consistent state? Can this be done by querying V$BACKUP_DATAFILE and V$ARCHIVED_LOG? If yes, which columns should I query?
Thanks for any help.A few ways :
1a. Get the timestamps when the BACKUP ... DATABASE began and ended.
1b. Review the alert.log of the database that was backed up.
1c. From the alert.log identify the first Archivelog that was generated after the begin of the BACKUP ... DATABASE and the first Archivelog that was generated after the end of the BACKUP .. DATABASE.
1d. These (from 1c) are the minimal Archivelogs that you need to RECOVER with. You can choose to apply additional Archivelogs that were generated at the source database to contininue to "roll-forward"
2a. Do a RESTORE DATABASE alone.
2b. Query V$DATAFILE on the restored database for the lowest CHECKPOINT_CHANGE# and CHECKPOINT_TIME. Also query for the highest CHECKPOINT_CHANGE# and CHECKPOINT_TIME.
2c. Go back to the source database and query V$ARCHIVED_LOG (FIRST_CHANGE#) to identify the first Archivelog that has a higher SCN (FIRST_CHANGE#) than the lowest CHECKPOINT_CHANGE# from 2b above. Also query for the first Archivelog that has a higher SCN (FIRST_CHANGE#) than the highest CHECKPOINT_CHANGE# from 2b above.
2d. These (from 2c) are the minimal Archivelogs that you need to RECOVER with.
(why do you need to query V$ARCHIVED_LOG at the source ? If RESTORE a controlfile backup that was generated after the first Archivelog switch after the end of the BACKUP ... DATABASE, you would be able to query V$ARCHIVED_LOG at the restored database as well. That is why it is important to force an archivelog (log switch) after a BACKUP ... DATABASE and then backup the controlfile after this -- i.e. last. That way, the controlfile that you have restored to the new server has all the information needed).
3. RESTORE DATABASE PREVIEW in RMAN if you have the archivelogs and subsequent controlfile in the backup itself !
Hemant K Chitale
Maybe you are looking for
-
I know that there are problems with the @ sign and puctuations. What else will I be facing? Really bummed. Amazon guarentee was rejected. They reply 'that i knew what I was buying'. I just opened the box. Hasnt been turned on. So frustrated. But cons
-
Charactersitic values to be used in IFTHEN ELSE STATEMENT IN QUERY
scenario: i need to use the characteristic values(not the attributes) to be used in an IF THEN ELSE STATEMENT in query. so i created a formula variable for the characteritic of processing type replacement path, replace with key.The values are not fet
-
I have i-cloud set up on ipad and PC and the photo's box is ticked on both. I am trying to get photo's taken from my camera which I have transferred to my PC onto my ipad. I have copied the required photo's from my PC and pasted into the Photo stream
-
Conditional Formatting of a Direct Database Request Columns in OBIEE 11g
Hi All, I need to do the conditional formatting like changing the column color based of some condition, but i can do to the conditional formatting in the normal answers in the column properties. But i want to do it in the rows of Direct Database Requ
-
In my datagrid I used Inline item rendering to create text link. code is given <mx:DataGridColumn headerText="Nomenclature"> <mx:itemRenderer> <mx:Component> <mx:Label htmlText="<u>{data.NOMENCLATURE