Home » Server Options » Data Guard » ArchiveLog not transfered to Physical standby - oracle10gR2
ArchiveLog not transfered to Physical standby - oracle10gR2 [message #180937] Wed, 05 July 2006 22:24 Go to next message
herman_santoso
Messages: 2
Registered: July 2006
Junior Member
Dear all,

I try to setup a physical standby database, but after
sql>alter database recover managed standby database using current logfile disconnect;

I didn't see archive file from primary transfered into my standby database.

I am using oracle 10g R2.. Primary instance=orcl (db_unique_name=orcl), and standby instance=stdb (db_unique_name=stdb)

on the primary:
1) alter system set log_archive_dest_2='service=stdb valid_for=(online_logfiles,primary_role) db_unique_name=stdb' scope=spfile;
==> system altered;
2) but select status,error from v$archive_dest where dest_id=2;
==> INACTIVE, NULL
3) from the log file (alert_orcl.log), I found following error:
[oracle@ora1 bdump]$ tail alert_orcl1.log
Wed Jul 5 19:20:30 2006
ORACLE Instance orcl1 - Archival Error. Archiver continuing.
Wed Jul 5 19:21:00 2006
FAL[server]: Fail to queue the whole FAL gap
GAP - thread 1 sequence 215-215
DBID 1121664255 branch 593883536
Thu Jul 6 09:44:28 2006
ALTER SYSTEM SET log_archive_dest_2='service=stdb valid_for=(online_logfiles,primary_role) db_unique_name=stdb' SCOPE=SPFILE;
Thu Jul 6 09:58:19 2006
ALTER SYSTEM SET log_archive_dest_state_2='ENABLE' SCOPE=SPFILE;


on the standby:
1) from log file (alert_stdb.log), I found following error:

[oracle@app02 bdump]$ tail alert_stdb.log
Wed Jul 5 19:20:29 2006
Using STANDBY_ARCHIVE_DEST parameter default value as USE_DB_RECOVERY_FILE_DEST
RFS: Forced Shutdown due to RFS_ERROR state
RFS: Forced Shutdown due to RFS_ERROR state
FAL[client]: Failed to request gap sequence
GAP - thread 1 sequence 215-215
DBID 1121664255 branch 593883536
FAL[client]: All defined FAL servers have been attempted.
-------------------------------------------------------------
Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization
parameter is defined to a value that is sufficiently large
enough to maintain adequate log switch information to resolve
archivelog gaps.
-------------------------------------------------------------

My primary database use RAC, and my physical standby database is maximum performance mode.

Backup and restore use RMAN
backup:
RMAN>backup device type disk format '/dump/%U' database plus archivelog;
RMAN>backup device type disk format '/dump/%U' current controlfile for standby;

restore:
RMAN>duplicate target database for standby;

Some questions that bothered me:
1) is the primary should be FORCE LOGGING ?
2) why in primary my log_archive_dest_2 = INACTIVE, the system has been altered successfully
3) why I got RFS shutdown in my standby
4) How to take a look, and which area is my mistake ?

I do really desperate for help..
Many thanks before..
Re: ArchiveLog not transfered to Physical standby - oracle10gR2 [message #184535 is a reply to message #180937] Wed, 26 July 2006 23:35 Go to previous messageGo to next message
anurag078
Messages: 34
Registered: May 2006
Location: West Des Moines
Member

Did you try a TNSPING to the standby service name set in the primary database server?

Primary database ships the archvie logs to the standby through this TNS string, ie., via Oracle Net, archive logs gets transported to the standby site.

If TNSPING does not reach your standby database destination, then you have to correct TNS entry parameters in your tnsnames.ora.

[Updated on: Wed, 26 July 2006 23:36]

Report message to a moderator

Re: ArchiveLog not transfered to Physical standby - oracle10gR2 [message #185905 is a reply to message #184535] Fri, 04 August 2006 03:44 Go to previous message
angelsliu
Messages: 23
Registered: July 2006
Junior Member
I think your standby host could not tns pri rac database,and your others configure on to setup?
Previous Topic: The primary DB stopped when the standby datbase failed
Next Topic: how to make the standby database apply archivelog quickly
Goto Forum:
  


Current Time: Thu Mar 28 17:41:36 CDT 2024