a-)
cluster file system with each instance writing to a shared location
or
b-)
cluster file system with each instance writing to a seperate location as long as all the locations are in directories under the same mount point

This is the reference in the 11g documentation:

““Redo received from another Oracle database via redo transport is written to the current standby redo log group by a RFS background process. When a log switch occurs on the redo source database, incoming redo is then written to the next standby redo log group, and the previously used standby redo log group is archived by an ARCn background process.””

The only reference to ARCHIVELOG mode howeve is the ARCn process.

The bug reference number is 8513469.

In the 10gR2 docs it states that you may decide to add a standby group on the primary if there are delays in the RFS trace files etc…

Specifically it says “Whenever you add an online redo log file group to the primary database, you must add a corresponding standby redo log file group to the standby database”

However, I only get errors if I try to add/drop standby logs on the standby:
“ORA-01156: recovery in progress may need access to files”

Any thoughts?

I had discussed this Andrey some time ago and we know the way, just didn’t get around to blogging about it.

Always remember google is your searching-for-answers friend.

Here is a paper from Oracle which spells out in detail how to implement a Physical standby from a RAC cluster.

http://www.oracle.com/technology/deploy/availability/pdf/MAA_WP_10g_RACPrimaryRACPhysicalStandby.pdf

su – oracle
rman target / catalog rcat_owner@rcatdb
RMAN> BACKUP CURRENT CONTROLFILE FOR STANDBY;
RMAN> BACKUP CHECK LOGICAL FULL DATABASE PLUS ARCHIVELOG;
RMAN> exit;

scp source_backup_directory oracle@standby:standby_backup_directoryOn Destination or Standby db:

sqlplus “/ as sysdba”
startup nomount
exit;On Source/Primary db:

rman target / catalog rcat_owner@rcatdb auxiliary sys@STANDBY

RMAN> DUPLICATE TARGET DATABASE FOR STANDBY NOFILENAMECHECK DORECOVER;
RMAN> exit;On Source/primary db:

show parameter log_archive_dest;
alter system set log_archive_dest_x = ‘SERVICE=STANDBY LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=PROD’;
alter system set log_archive_dest_state_x = ‘ENABLE’;On Destination or Auxiliary STANDBY:

alter system set FAL_SERVER = ‘PROD’;
alter system set FAL_CLIENT = ‘STANDBY’;

shutdown immediate;
startup nomount;
alter database mount standby database;
alter database recover managed standby database disconnect from session;To check progress:

On Primary:

column destination format a30

select dest_id,destination,status,database_mode,recovery_mode,error from V$ARCHIVE_DEST_STATUS
where status != ‘INACTIVE’;To check progress on Primary or Standby:

select * from v$managed_standby;

SATISH NAWLE
SQL STAR
9224639278

you are right – RMAN’s duplicate command does not do everything for you regarding standby redo logs (I am about the case when they are already created on primary database). But after duplication of the target database proper entries (taking into consideration log_file_name_convert parameter on standby side) for standby logs will be created, but without files under that. The files can be simply recreated through ALTER DATABASE CLEAR LOGFILE GROUP (n – standby log file group) command. And after that you can continue with Data Guard (or Standby) configuration.

Regards,
Andrey Goryunov

So you have the availability of RAC and the redundancy and Disaster Recovery (DR) of Dataguard.

“This is not the same level of redundancy or availability of Oracle RAC, but getting close.” But if your building blows up or floods, unless you have a stretched RAC cluster your dataguard solution provides you much more protection way above the availability of RAC.

jason.