SRVCTL For RAC

Log Directory Structure in Cluster Ready Service:

$ORA_CRS_HOME/crs/log--->contains trace files for the CRS resources
$ORA_CRS_HOME/crs/init--->contains the trace files of the CRS daemon during startup.Good Place to start with any CRS login problems.
$ORA_CRS_HOME/css/log---->The Cluster Synchronization (CSS) logs indicate all actions sych as reconfigurations,missed check -inbs,connects and disconnects from the client CSS listener.In some cases,the loggeer logs messages with category of auth.crit for the rebbots done by oracle.This could be used for checking the exact time when the reboot occured
$ORA_CRS_HOME/css/init----->contains core dumps from cluster synchronization service daemon(OCSSd) AND THE PROCESS id (pid) FOR THE css DAEMON whose death is treated as fatal.If abnormal restarts of CSS exist,the core files will have the format core.
$ORA_CRS_HOME/evm/log---> Logfiles for the Event Volume manager and evmlogger daemons.Not used for debugging as the CRS and CSS directories.
$ORA_CRS_HOME/evm/init--->PID and lock files for EVM .Core files of EVM should also be written here.
$ORA_CRS_HOME/srvm/log--->Log files for the Oracle Cluster Registry(OCR) which contsins the details at the oracle cluster level.
$ORA_CRS_HOME/log----->Logfiles for Oracle Cluterware(known as cluster alert)which contains diagnostic messages at the oracle cluster level.This is available form oracle database 10g R2

Client want to go for DR test.The changes During DR Test should Not REflect On Prod(Means the changed Data during DR Test should Not reflect on primar

Possibility1:Planned Fail over


Note:Primary Database will be down until DR Test completes

a.Take cold/hot/RMAN backup on primary before DR test

b.Take cold/hot/RMAN backup on standby Database before DR test. c.Shutdown Primary Database

d.On standby Database fire the below command sql> alter database activate standby database;

e.Once standby Database is activated,Execute the below command. sql > alter database open

f.Now standby Database is converted to primary Database.

g.Go For DR Test Post Fail over:After DR test.

a.shutdown standby Database(Which was activated as per step d) b.remove all the datafile,controlfile,redologfile....except pfile or spfile or Drop Database on standby Database

c.Restore the backup on standby Database (which was taken on step b) d.After successful Restore,Execute below commands
startup nomount
sql > alter database mount standby Database

alter database recover managed standby database disconnect from session;

e.start the Primary Database(This step can be done as per the requirement..means you can start earlier also)

f.Do Manual switches sql > alter system switch logfile ;

g.check the synchronization with standby Database.

Other Possibility will be posted shortly..Hope the above scenario makes helps..Be free to comment or suggestion... Cheers, Ayyappa Y
------------*****--****----------------------
Possibility2 :Using FLASHBACK ON STANDBY DATABASE

Requirements

The following requirements need to be met in order to create a snapshot standby.

1.Database version should be 10.2* or higher
2.Primary & standby Database should be in archive log mode
3.Database should be in sync before you proceed.
4.Flash Recovery Area (FRA) is required on the standby database to implement a Flashback database.


ON PRIMARY DATABASE:

a.Do Manual switches
sql > ALTER SYSTEM ARCHIVE LOG CURRENT;

b.check the synchronization with standby Database
sql > select max(sequence#) from v$log_history;

c.Stop the synchronization & shipping of the archives from primary:
sql > alter system set log_archive_dest_stat2_2=defer;

On standby Database:

a.Cancel The Recovery Process:
sql > alter database recover managed standby database cancel;

b.Create Guarantee Restore point
CREATE RESTORE POINT ayyu_stdby GUARANTEE FLASHBACK DATABASE;

c.Activate the standby Database
sql > alter database activate standby database;

d.Open the standby Database
sql > alter database open

Now You can use the DR box for testing purpose..

e.Once testing is completed.Perform the Following

sql > shu immediate;
sql > startup Mount;

sql>Flashback Database to restore point ayyu_stdby;
sql > ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

Post DR test:

On Primary:

a.Enable the archive destination
sql > alter system set log_archive_dest_stat2_2=enable;

On standby:

a.start the recovery Process
sql > alter database recover managed standby database disconnect from session;

============================================================

Possibility-3 :Using SNAPSHOT STANDBY FEATURE IN 11G(Below Document is from ORACLE_BASE)

Snapshot standby allows the standby database to be opened in read-write mode. When switched back into standby mode, all changes made whilst in read-write mode are lost. This is achieved using flashback database, but the standby database does not need to have flashback database explicitly enabled to take advantage of this feature, thought it works just the same if it is.

If you are using RAC, turn off all but one of the RAC instances. Make sure the instance is in MOUNT mode.

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;

Make sure managed recovery is disabled.

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

Convert the standby to a snapshot standby. The following example queries the V$DATABASE view to show that flashback database is not enabled prior to the conversion operation.

SELECT flashback_on FROM v$database;

FLASHBACK_ON
------------------
NO

ALTER DATABASE CONVERT TO SNAPSHOT STANDBY;
ALTER DATABASE OPEN;
SELECT flashback_on FROM v$database;

FLASHBACK_ON
------------------
RESTORE POINT ONLY

SQL>

You can now do treat the standby like any read-write database.

To convert it back to the physical standby, losing all the changes made since the conversion to snapshot standby, issue the following commands.

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
SHUTDOWN IMMEDIATE;
STARTUP NOMOUNT;
ALTER DATABASE MOUNT STANDBY DATABASE;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
SELECT flashback_on FROM v$database;

FLASHBACK_ON
------------------
NO

SQL>

The standby is once again in managed recovery and archivelog shipping is resumed. Notice that flashback database is still not enabled.

============================================================