cancel
Showing results for 
Search instead for 
Did you mean: 

Archived Log is not shifting from Primary to DR

Former Member
0 Kudos

we have increase the table size without taking care of DR, so

sapdata1 becomes 100% at DR site after that applying archived had

stopped at DR, after that i manually added datafile using following

commands,

select * from v$recover_file where error like '%FILE%';

Primary-:

1)select file#,name from v$datafile where file#=33;

/oracle/BP1/sapdata1/sr3_21/sr3.data21

2)select file#,name from v$datafile where file#=34;

/oracle/BP1/sapdata1/sr3_22/sr3.data22

alter system set standby_file_management =Manual;

DR-:

1)select file#,name from v$datafile where file#=33;

/oracle/BP1/102_64/dbs/UNNAMED00033

2)select file#,name from v$datafile where file#=34;

/oracle/BP1/102_64/dbs/UNNAMED00034

alter database create datafile '/oracle/BP1/102_64/dbs/UNNAMED00033'

as '/oracle/BP1/sapdata1/sr3_21/sr3.data21';

alter database create datafile '/oracle/BP1/102_64/dbs/UNNAMED00034'

as '/oracle/BP1/sapdata1/sr3_22/sr3.data22';

alter system set standby_file_management =Auto;

alter database recover managed standby database disconnect from

session;

after that all logfile which is available at DR is applied but now

automatic shifting from primary to DR is not happen, please check and

provide the solution as early as possible because if log gap increase

we have to go for backup and restore and our DR site is so far.

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Dear Orkun Gedik ,

Please find the Aler Log-:

Errors in file /oracle/BP1/saptrace/background/bp1_mrp0_20361.trc:

ORA-00313: open failed for members of log group 1 of thread 1

Thu Aug 11 18:39:53 2011

Errors in file /oracle/BP1/saptrace/background/bp1_mrp0_20361.trc:

ORA-19527: physical standby redo log must be renamed

ORA-00312: online log 1 thread 1: '/oracle/BP1/origlogA/log_g11m1.dbf'

Clearing online redo logfile 1 complete

Please find the log for bp1_mrp0_20361.trc

Start recovery at thread 1 ckpt scn 232442669 logseq 4297 block 2

      • 2011-08-11 18:39:53.881

Media Recovery add redo thread 1

      • 2011-08-11 18:39:53.881 1180 krsm.c

Managed Recovery: Active posted.

ORA-00313: open failed for members of log group 1 of thread 1

      • 2011-08-11 18:39:53.891 64311 /se_autofs/patch_archive/102044/197/10107454/k

crr.c

Clearing online redo logfile 1 /oracle/BP1/origlogA/log_g11m1.dbf

ORA-00313: open failed for members of log group 1 of thread 1

ORA-19527: physical standby redo log must be renamed

ORA-00312: online log 1 thread 1: '/oracle/BP1/origlogA/log_g11m1.dbf'

Error 19527 creating/clearing online redo logfile 1

      • 2011-08-11 18:39:53.950 64311 /se_autofs/patch_archive/102044/197/10107454/k

crr.c

Clearing online redo logfile 1 complete

      • 2011-08-11 18:39:53.960 64311 /se_autofs/patch_archive/102044/197/10107454/k

crr.c

Media Recovery Waiting for thread 1 sequence 4297

Former Member
0 Kudos

Hi Ketan,

>> ORA-00313: open failed for members of log group 1 of thread 1

At the first stage, check whether the online redolog folders are exist.

Then, check the link below;

http://www.orafaq.com/forum/t/129662/2/

Best regards,

Orkun Gedik

Former Member
0 Kudos

Dear Orkun Gedik,

Thank you very much for your reply, in my case origlog mount point is there, but i feel following thing is happening in my case,

one of my team member added data file using brtools without taking care of dr side, as primary and dr mount point size is not same while adding data file at primary log is shifted to dr and sapdata1 becomes 100% full then we increase the sapdata1 mount point at dr side but after that log is not able to applied at dr side then we performed the manual steps as mention in my first post, after that archive log which is available at dr all are applied but then now log shifting from primary to dr is not happening

From

Ketan Kapadi

Former Member
0 Kudos

Hi Ketan,

In order to be safe side, I want to be sure that you performed the steps, below;

1) did you restarted the primary and standby side, after you face with this problem?

2) did you executed defer/enable statements that I suggested at my previous message?

3) did you triggered "alter system switch logfile" statement?

Additionally, check alert log at the primary site, also.

Best regards,

Orkun Gedik

Former Member
0 Kudos

Dear Orkun Gedik,

1) did you restarted the primary and standby side, after you face with this problem?

i restarted at sap level at dr side. but i have not restarted at primary for that i will go for today

2)did you executed defer/enable statements that I suggested at my previous message?

I have performed this steps as you had mention in your earlier post but there is no change in the result.

3)did you triggered "alter system switch logfile" statement?

As Primary is in active stage so many archive generated after this cause

From,

Ketan Kapadi

+91-9099956182

Former Member
0 Kudos

Hi Ketan,

>> i restarted at sap level at dr side. but i have not restarted at primary for that i will go for today

Reboot both servers, if it is possible.

>> As Primary is in active stage so many archive generated after this cause

Ok, but it triggers RFS process manually, also. So execute this command after the reboot and you open the database respectfully.

Did you check the alert log, at primary site?

Best regards,

Orkun Gedik

Answers (2)

Answers (2)

Former Member
0 Kudos

tnsping is working from both side

Former Member
0 Kudos

Dear

Orkun Gedik,

Soory for late reply, actully my problem was resolved after rebooting the primary servers in downtime

thanks for your helpp

Former Member
0 Kudos

Hi Ketan,

Execute the statements at the primary site, below;

alter system set log_archive_dest_state_2=defer;

(wait for 5 minutes)

alter system set log_archive_dest_state_2=enable;

Best regards,

Orkun Gedik

Former Member
0 Kudos

Additionally, Check the alert log at the both sites. Morever, execute the command at the primary site, in order to check connection primary to standby ;

tnsping <Standby site SID>

Best regards,

Orkun Gedik