Creating a Physical Standby DB with RMAN 11g

Quick summary
Create a Standby Database from Active database with the following command:
DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE


The steps described here are to configure the standby database for maximum performance mode, which is the default data protection mode.

Details about this example:
Primary hostname – MY_PRIMARY_HOST
Standby hostname – MY_SECONDARY_HOST

TNS alias for Primary – FGUARD
TNS alias for standby – STB_QAFGUARD

Primary DB_NAME=FGUARD      Primary Database DB_UNIQUE_NAME= FGUARD
Standby DB_NAME=FGUARD     Standby Database DB_UNIQUE_NAME= STB_QAFGUARD

NOTE =
The DB_NAME of the standby database will be the same as that of the primary, but it must have a different DB_UNIQUE_NAME value. The DB_UNIQUE_NAME values of the primary and standby database should be used in the DG_CONFIG setting of the LOG_ARCHIVE_CONFIG parameter. For this example, the standby database will have the value "STB_QAFGUARD".
ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(FGUARD,STB_QAFGUARD)';


Prior to Oracle Database 11g, you could create a duplicate database with RMAN for testing or for standby. It required the source database, a copy of a backup on the destination system, and the destination database itself.
Oracle Database 11g greatly simplifies this process. You can instruct the source database to perform online image copies and archived log copies directly to the auxiliary instance, by using Enterprise Manager or the FROM ACTIVE DATABASE clause of the RMAN DUPLICATE command. Preexisting backups are no longer needed.
The database files are copied from the source to a destination or AUXILIARY instance via an inter-instance network connection. RMAN then uses a “memory script” (one that is contained only in memory) to complete recovery and open the database.
Password files are copied to the destination. The destination must have the same SYS user password as the source. In other words, at the beginning of the active database duplication process, both databases (source and destination) must have password files.
When creating a standby database, the password file from the primary database overwrites the current (temporary) password file on the standby database. When you use the command line and do not duplicate for a standby database, then you need to use the PASSWORD clause (with the FROM ACTIVE DATABASE clause of the RMAN DUPLICATE command).


RMAN Options:
NOFILENAMECHECK
Prevents RMAN from checking whether the source database datafiles and online redo logs files share the same names as the duplicated files. This option is necessary when you are creating a duplicate database in a different host that has the same disk configuration, directory structure, and filenames as the host of the source database. If duplicating a database on the same host as the source database, then make sure that NOFILENAMECHECK is not set.
The NOFILENAMECHECK option is required when the standby and primary datafiles and online redo logs have identical filenames. Thus, if you want the duplicate database filenames to be the same as the source database filenames, and if the databases are in different hosts, then you must specify NOFILENAMECHECK

SPFILE ... SET 'string_pattern'
Sets the specified initialization parameters to the specified values. You can use SET to set the LOG_FILE_NAME_CONVERT parameter for the online redo logs.
It copies the server parameter file from the source database to the operating system-specific default location for this file on the standby database.
RMAN uses the server parameter file to start the auxiliary instance for standby database creation. Any remaining options of the DUPLICATE command are processed after the database instance is started with the server parameter file.
If you execute DUPLICATE with the SPFILE clause, then the auxiliary instance must already be started with a text-based initialization parameter file. In this case, the only required parameter in the temporary initialization parameter file is DB_NAME, which can be set to any arbitrary value. RMAN copies the binary server parameter file, modifies the parameters based on the settings in the SPFILE clause, and then restarts the standby instance with the server parameter file. When you specify SPFILE, RMAN never uses the temporary text-based initialization parameter file to start the instance.
If FROM ACTIVE DATABASE is specified on DUPLICATE, then a server parameter file must be in use by the source database instance. If FROM ACTIVE DATABASE is not specified on DUPLICATE, then RMAN restores a backup of the server parameter file to the standby database.


DORECOVER:
Specifies that RMAN should recover the standby database after creating it. If you specify an untilClause, then RMAN recovers to the specified SCN or time and leaves the database mounted.
RMAN leaves the standby database mounted after media recovery is complete, but does not place the standby database in manual or managed recovery mode. After RMAN creates the standby database, you must resolve any gap sequence before placing it in manual or managed recovery mode, or opening it in read-only mode.


PARAMETER_VALUE_CONVERT:
Replaces the first string with the second string in all matching initialization parameter values. Note that DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT are exceptions to this rule and are not affected.
You can use PARAMETER_VALUE_CONVERT to set a collection of initialization parameter values and avoid explicitly setting them all. For example, if the source database uses disk group +ALPHA while the standby database will use +BETA, then you could modify all parameters that refer to these disk groups by specifying SPFILE PARAMETER_VALUE_CONVERT (‘+ALHPA’,'+BETA’).



DB_FILE_NAME_CONVERT 'string_pattern'
Specifies a rule for creating the filenames for duplicate datafiles and tempfiles. Note that DB_FILE_NAME_CONVERT specified on the DUPLICATE command overrides the initialization parameter DB_FILE_NAME_CONVERT if it is set in the initialization parameter file.

Example:
DUPLICATE TARGET DATABASE TO dup1
  FROM ACTIVE DATABASE
  DB_FILE_NAME_CONVERT '/disk1','/disk2'
  SPFILE
    PARAMETER_VALUE_CONVERT '/disk1', '/disk2'
    SET LOG_FILE_NAME_CONVERT '/disk1','/disk2'
    SET SGA_MAX_SIZE '200M'
    SET SGA_TARGET '125M';

The PARAMETER_VALUE_CONVERT option substitutes /disk2 for /disk1 in all initialization parameters that specify filenames (with the exception of DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT). The SET LOG_FILE_NAME_CONVERT clause substitutes /disk2 for /disk1 in the filenames of the online redo logs of the duplicate database. The DB_FILE_NAME_CONVERT option replaces /disk1 with /disk2 in the names of the duplicate datafiles and tempfiles.


Another Example with Path Changes:
run {
    allocate channel prmy1 type disk;
    allocate channel prmy2 type disk;
    allocate auxiliary channel stby type disk;
    duplicate target database for standby from active database
    dorecover
    spfile
        parameter_value_convert 'FGUARD','STB_QAFGUARD'
        SET DB_UNIQUE_NAME='STB_QAFGUARD'
        set db_file_name_convert='/opt/oracle/oradata/FGUARD/','/opt/oracle/oradata/STB_QAFGUARD/'
        set log_file_name_convert='/opt/oracle/oradata/FGUARD/','/opt/oracle/oradata/STB_QAFGUARD/'
        set control_files='/u01/app/oracle/oradata/STB_QAFGUARD/control01.ctl','/u01/app/oracle/oradata/STB_QAFGUARD/control02.ctl'
        set log_archive_max_processes='5'
        set fal_client='STB_QAFGUARD'
        set fal_server='FGUARD'
        set standby_file_management='AUTO'
        set log_archive_config='dg_config=(FGUARD,STB_QAFGUARD)'
        set log_archive_dest_2='service=FGUARD ASYNC valid_for=(ONLINE_LOGFILE,PRIMARY_ROLE) db_unique_name=FGUARD'
     ;
     }


Starting the Work
On this step we want to be sure that the primary database is configured correctly to support a physical standby database.
You only need to perform these preparatory tasks once. After you complete these steps, the database is prepared to serve as the primary database for one or more standby databases. You should perform the following steps:
1. Determine if FORCE LOGGING is enabled on Primary. If it is not, then enable it by using the FORCE LOGGING mode.
This statement may take some time to complete, because it waits for all unlogged direct write I/O to finish. Use SQL*Plus to execute the following commands:
SELECT force_logging FROM v$database;
ALTER DATABASE FORCE LOGGING;
SELECT force_logging FROM v$database;

2. Configure redo transport authentication.
Data Guard uses Oracle Net sessions to transport redo data and control messages between the members of a Data Guard configuration. These redo transport sessions are authenticated using either the Secure Sockets Layer (SSL) protocol or a remote login password file.
Create a passwordfile under $ORACLE_HOME/dbs (if that is not already there). Remember that the value of the password needs to be the same as that of the primary database's password file. I have found that the ignorecase parameter is essential in 11g when putting one of these configurations together.
$ orapwd file=orapwfguard password=password ignorecase=y entries=25

Copy the password file from the $ORACLE_HOME/dbs directory on primary server to $ORACLE_HOME/dbs on the standby server.


3. Update listener.ora on Standby machine by adding the following to the SID_LIST_LISTENER section

    (SID_DESC =
      (GLOBAL_DBNAME = STB_QAFGUARD)
      (ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_1)
      (SID_NAME = FGUARD)
    )

So the file it will look like this:
SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (SID_NAME = PLSExtProc)
      (ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_1)
      (PROGRAM = extproc)
    )
    (SID_DESC =
      (GLOBAL_DBNAME = STB_QAFGUARD)
      (ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_1)
      (SID_NAME = FGUARD)
    )
  )

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1))
      (ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT = 1521))
    )
  )

LOGGING_LISTENER = OFF


Stop and restart the Listener on the Standby Machine
lsnrctl stop
lsnrctl start

Also, update tnsnames.ora on Standby as well as Primary site with the alias FGUARD and STB_QAFGUARD
FGUARD =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = MY_PRIMARY_HOST)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = FGUARD)
    )
  )  

STB_QAFGUARD =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = MY_SECONDARY_HOST)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = STB_QAFGUARD)
    )
  )  


4. If you decide to run the data guard in maximum protection or maximum availability, the transaction are copied over to the standby site by the LGWR and are written to the standby logfiles; this is why we create standby logfiles that will be used not locally, but by the standby. We also recommend to create the standby logfiles so that after a possible switchover, the old primary
may work properly as a standby for any protection mode.
Configure the primary database to receive redo data, by adding the standby logfiles to the primary. You can use the following lines, after validating the directory paths reflect your environment.
NOTE: Always create one additional standby log group than there are online log groups. Also, they must be of the same size than the online log groups.
These standby logfiles will be automatically created on the standby DB once we run the RMAN commands.
When standby redologs are created, they are listed in V$LOGFILE, but their groups are listed in V$STANDBY_LOG
set echo on
ALTER DATABASE ADD STANDBY LOGFILE '/u01/app/oracle/oradata/FGUARD/stdby_redo01.log' SIZE 50M;
ALTER DATABASE ADD STANDBY LOGFILE '/u01/app/oracle/oradata/FGUARD/stdby_redo02.log' SIZE 50M;
ALTER DATABASE ADD STANDBY LOGFILE '/u01/app/oracle/oradata/FGUARD/stdby_redo03.log' SIZE 50M;
ALTER DATABASE ADD STANDBY LOGFILE '/u01/app/oracle/oradata/FGUARD/stdby_redo04.log' SIZE 50M;



5. Create an init.ora on the Standby machine with just a single line which is the db_name parameter
echo DB_NAME='FGUARD' > initFGUARD.ora


6. On the standby system, change to the /u01/app/oracle/admin directory. Create a directory with a name that matches your physical standby SID:
cd $ORACLE_BASE/admin
mkdir FGUARD
mkdir FGUARD/adump
mkdir FGUARD/bdump
mkdir FGUARD/cdump
mkdir FGUARD/udump
mkdir FGUARD/dpdump
mkdir FGUARD/pfile
mkdir FGUARD/scripts
mkdir $ORACLE_BASE/oradata/FGUARD
Note: Depending on how you configured your existing primary database you may need to also create a similar directory in your fast recovery area (i.e. $ORACLE_BASE/fast_recovery_area)

7 . On the standby system, set the ORACLE_SID environment variable and start the instance in NOMOUNT mode with the text initialization parameter file created earlier
export ORACLE_SID=FGUARD
sqlplus "sys as sysdba"
startup nomount ;

Note:
We are assuming that the Primary DB is already on archive log mode.
If that is not the case, you need to perform the following steps on that Primary box:
archive log list;
shutdown immediate
startup mount;
alter database archivelog;
alter database open;


8. On the primary system, ensure the ORACLE_SID environment variable is set to your primary database and call RMAN
rman target / auxiliary sys@STB_QAFGUARD
or
RMAN> connect target sys@FGUARD
RMAN> connect auxiliary sys@STB_QAFGUARD

RMAN> run {
    allocate channel prmy1 type disk;
    allocate channel prmy2 type disk;
    allocate auxiliary channel stby type disk;
    duplicate target database for standby from active database
        nofilenamecheck
    dorecover
    spfile
        set standby_file_management='AUTO'
        SET DB_UNIQUE_NAME='STB_QAFGUARD'
        set log_archive_config='dg_config=(FGUARD,STB_QAFGUARD)'
        SET LOG_ARCHIVE_DEST_2='service=FGUARD LGWR SYNC REGISTER VALID_FOR=(online_logfile,primary_role)'
        SET FAL_SERVER='FGUARD'
        SET FAL_CLIENT='STB_QAFGUARD'
     ;
     }

9. Change the init.ora parameters related to redo transport and redo apply

On this steps we will performing several changes to the Primary init.ora parameters. These includes:
DB_NAME Specifies the database name. Must be FGUARD.
DB_UNIQUE_NAME Specify a unique name for each database. Does not change even if DG roles change. Must be FGUARD.
CONTROL_FILES Specifies the local path name for the control files on the primary database.
LOG_ARCHIVE_CONFIG Uses the DG_CONFIG attribute to list the DB_UNIQUE_NAME of the primary and standby databases.
LOG_ARCHIVE_DEST_1 Defaults to archive destination for the local archived redo log files
LOG_ARCHIVE_DEST_2 Valid only for the primary role, this destination transmits redo data to the remote physical standby destination STB_QAFGUARD
REMOTE_LOGIN_PASSWORDFILE Must be EXCLUSIVE or SHARED if a remote login password file is used (default =EXCLUSIVE)
LOG_ARCHIVE_DEST_STATE_n Must be ENABLE (default)


On Primary
SQL> alter system set standby_file_management=AUTO scope=both;
SQL> alter system set DB_UNIQUE_NAME='FGUARD' scope=both;
SQL> alter system set LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=FGUARD' scope=both;
SQL> alter system set LOG_ARCHIVE_DEST_2='SERVICE=STB_QAFGUARD LGWR SYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=STB_QAFGUARD' scope=both;
SQL> alter system set LOG_ARCHIVE_DEST_STATE_1='enable' scope=both;
SQL> alter system set LOG_ARCHIVE_DEST_STATE_2='enable' scope=both;
SQL> ALTER SYSTEM SET log_archive_config = 'DG_CONFIG=(FGUARD,STB_QAFGUARD)' scope=both;
SQL> alter system set fal_server=STB_QAFGUARD scope=both;
SQL> alter system set fal_client=FGUARD scope=both;  --This MAIN DB UNIQUE NAME


10. Check the Standby DB
select name,open_mode,database_role from v$database;
NAME      OPEN_MODE            DATABASE_ROLE
--------- -------------------- ----------------
MATRIX    MOUNTED              PHYSICAL STANDBY


select PROCESS,PID,STATUS,THREAD#,SEQUENCE#,BLOCK#,DELAY_MINS from v$managed_standby;
PROCESS          PID STATUS          THREAD#  SEQUENCE#     BLOCK# DELAY_MINS
--------- ---------- ------------ ---------- ---------- ---------- ----------
ARCH            6384 CONNECTED             0          0          0          0
ARCH            7544 CONNECTED             0          0          0          0
ARCH            7260 CONNECTED             0          0          0          0
ARCH            6668 CONNECTED             0          0          0          0
ARCH            7272 CONNECTED             0          0          0          0


Now let's put the Standby in Recovery Mode ( a new MRP Process will show up on the Alert Log file and also on the v$managed_standby query):
Alter database recover managed standby database disconnect from session;

select PROCESS,PID,STATUS,THREAD#,SEQUENCE#,BLOCK#,DELAY_MINS from v$managed_standby;
PROCESS          PID STATUS          THREAD#  SEQUENCE#     BLOCK# DELAY_MINS
--------- ---------- ------------ ---------- ---------- ---------- ----------
ARCH            6384 CONNECTED             0          0          0          0
ARCH            7544 CONNECTED             0          0          0          0
ARCH            7260 CONNECTED             0          0          0          0
ARCH            6668 CONNECTED             0          0          0          0
ARCH            7272 CONNECTED             0          0          0          0
MRP0            7476 WAIT_FOR_LOG          1         25          0          0


To use Real Time Apply , Standby redo logfiles are mandatory. Once, the standby redo logfiles has been created on the standby use:
alter database recover manages standby database using current logfile disconnect from session;


If you want to execute Read-Only Queries on the Standby you can shutdown the Standby and enable managed recovery (active standby mode, that means that you can execute read-only queries)
SQL> shutdown immediate;
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.

SQL> startup
ORACLE instance started.
Total System Global Area 1043886080 bytes
Fixed Size 2160352 bytes
Variable Size 775948576 bytes
Database Buffers 260046848 bytes
Redo Buffers 5730304 bytes
Database mounted.
Database opened.

SQL> recover managed standby database using current logfile disconnect;

An examination of the v$database view should yield 'PHYSICAL STANDBY'
SQL> select database_role from v$database;


11. Check if the MRP process is running
SQL> !ps -ef |grep mrp
oracle 446526 1 0 10:59:01 – 0:00 ora_mrp0_FGUARD



Verify that the Physical Standby Database is Performing Correctly
Once you create the physical standby database and set up redo transport services, you may want to verify database modifications are being successfully transmitted from the primary database to the standby database. To see that redo data is being received on the standby database, you should first identify the existing archived redo log files on the standby database, force a log switch and archive a few online redo log files on the primary database, and then check the standby database again. The following steps show how to perform these tasks.
1. On the standby database, identify the existing archived redo log files by querying the V$ARCHIVED_LOG view.
SELECT sequence#, first_time, next_time, applied
FROM v$archived_log
ORDER BY sequence#;

2. On the primary database, issue a number of ALTER SYSTEM SWITCH LOGFILE statements to archive a number of redo log files.
alter system switch logfile;
alter system switch logfile;
archive log list;

3. On the standby database, re-query the V$ARCHIVED_LOG view to verify the redo data was received and applied on the standby database.
SELECT sequence#, first_time, next_time, applied
FROM v$archived_log
ORDER BY sequence#;


Using the Data Guard Manager Linemode
If you want to use the Data Guard environment, you will need first to start the Data Guard Monitor process (DMON) on both sites with the following commands in BOTH sides:
connect sys@FGUARD as sysdba
alter system set dg_broker_start=true;
connect sys@STB_QAFGUARD as sysdba
alter system set dg_broker_start=true;

If you examine the parameter LOG_ARCHIVE_DEST_2 on the primary site, you will see that DMON has set it to the appropriate value, so that redo can be transmitted to the standby site.  The use of RMAN made this all fairly easy to do.
Now, we are ready to use the Data Guard Broker, which can be administrated using Database Control in 11g, or using the DGMGRL utility.
So we call Data Guard Manager Linemode and create its configuration:
dgmgrl
DGMGRL> help
DGMGRL> connect sys@FGUARD
DGMGRL> create configuration myconfig as primary database is FGUARD connect identifier is FGUARD;
DGMGRL> add database STB_QAFGUARD as connect identifier is STB_QAFGUARD maintained as physical;
DGMGRL> enable configuration;
DGMGRL> show configuration;


Optional Steps and Performing actions with the Data Guard Manager

Add the Logical Standby to the Broker Configuration if that has been configured:
If you want to use the Data Guard environment, you will need first to start the Data Guard Monitor process (DMON) on both sites with the following commands in BOTH sides:
connect sys@PRIMARY as sysdba
alter system set dg_broker_start=true;
connect sys@RECO as sysdba
alter system set dg_broker_start=true;

dgmgrl
dgmgrl> connect sys@PRIMARY
dgmgrl> show configuration;
dgmgrl> add database RECO as connect identifier is RECO maintained as logical;
dgmgrl> enable database RECO;
dgmgrl> show configuration;


Maximum Protection with Logical Standby Database
dgmgrl> edit database PRIMARY set property LogXptMode=SYNC;
dgmgrl> edit database RECOset property LogXptMode=SYNC;
dgmgrl> edit configuration set protection mode as maxprotection;
show configuration;


Change of Protection Level and Transport Method
dgmgrl> connect sys@PRIMARY
dgmgrl> show configuration verbose;
dgmgrl> show database verbose RECO;

Maximum Protection; here 2 Standby Databases are recommended. The changes are always done on Primary and Standby in case of a later SWITCHOVER.
dgmgrl> edit database PRIMARY set property LogXptMode=SYNC;
dgmgrl> edit database RECO set property LogXptMode=SYNC;
dgmgrl> edit configuration set protection mode as maxprotection;
dgmgrl> show configuration;

Maximum Availability
dgmgrl> edit database PRIMARY set property LogXptMode=SYNC;
dgmgrl> edit database RECO set property LogXptMode=SYNC;
dgmgrl> edit configuration set protection mode as maxavailability;
dgmgrl> show configuration;

Maximum Performance with LGWR-Transport
If there was a higher Protection Level beforehand, it must be lowered to Maximum Performance now
dgmgrl> edit configuration set protection mode as maxperformance;
dgmgrl> edit database PRIMARY set property LogXptMode=ASYNC;
dgmgrl> edit database RECO set property LogXptMode=ASYNC;
dgmgrl> show configuration;

Maximum Performance with ARCH-Transport 
dgmgrl> edit configuration set protection mode as maxperformance;
dgmgrl> edit database PRIMARY set property LogXptMode=ARCH;
dgmgrl> edit database RECO set property LogXptMode=ARCH;
dgmgrl> show configuration;


Switchover and Failover
Switchover: Primary and Standby exchange their roles
dgmgrl> connect sys@PRIMARY
dgmgrl> switchover to RECO;

Failover: Emergency, the Primary is destroyed
dgmgrl> connect sys@PRIMARY
dgmgrl>failover to RECO;


Fast-Start-Failover
Modify Broker-Configuration
dgmgrl> EDIT DATABASE PRIMARY SET PROPERTY FastStartFailoverTarget = physt;
dgmgrl> EDIT DATABASE RECO SET PROPERTY FastStartFailoverTarget = prima;
dgmgrl> EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold = 20;
dgmgrl> ENABLE FAST_START FAILOVER;

Start the Observer on another computer
START OBSERVER;


Snapshot Standby
Use DGMGRL to convert your Standby DB into a Test System :
dgmgrl> convert database RECO to snapshot standby;

You can do testing now as you like while Redo from the Primary is still received. Reconvert the Test System into Standby DB:
convert database RECO to physical standby;


Active Data Guard
Interrupt Redo Apply on the Physical Standby:
DGMGRL > edit database RECO set state=apply-off;

Open Physical Standby Read-Only:
alter database open read only;

Turn on Redo Apply again:
dgmgrl> edit database RECO set state=apply-on;


Backup & Recovery
Restore a datafile to the Primary from Physical Standby:
RMAN> connect target sys@RECO
RMAN> connect auxiliary sys@PRIMARY
RMAN> backup as copy datafile 4 auxiliary format=’/home/oracle/PRIMARY/users01.dbf’;
RMAN> exit;

Recover the datafile on the Primary:
RMAN> connect target sys@PRIMARY
RMAN> recover datafile 4;


11g Active Data Guard
Active Data Guard is a brilliant new 11g feature, which allows a physical standby database to be opened “Read Only” as in past releases, but which then allows the media recovery process to be restarted. This allows SQL queries to be done whilst the standby database is applying redo, shipped from the primary! To implement this, do the following:
DGMGRL
DGMGRL> connect sys@FGUARD
DGMGRL> edit database STB_QAFGUARD set state=apply-off;
alter database open read only;
DGMGRL> edit database STB_QAFGUARD set state=apply-on;

DML performed on your primary database is visible almost instantly on the physical standby due to the use of  Real Time Apply.
Consequently, you can offload query only workloads  from your primary database to your physical standby, thereby reducing the load on your primary database, while maintaining your disaster recovery capability! 


11g Snapshot Standby Databases
Another very useful feature of 11g is the ability to convert your standby database into a test database, while the redo from the primary site is still received. After your testing is done, you can convert your test database back to a standby database. Although data protection and a disaster recovery capability are maintained when using a “Snapshot Standby”, a failover done while it exists, will most likely be slower, because it must be converted back to a “Physical Standby” and then all redo received from the primary whilst  using the “Snapshot Standby”, must be applied before the failover is completed. If you wish to use this feature, then perhaps you should deploy two standby databases, one for DR and one for use as a “Snapshot Standby” as required. 
Here is how it is done:
DGMGRL> startup force mount
DGMGRL > convert database STB_QAFGUARD to snapshot standby;
DGMGRL> show configuration
Configuration
  Name:                mycon
  Enabled:             YES
  Protection Mode:     MaxAvailability
  Databases:
    FGUARD- Primary database
    STB_QAFGUARD- Snapshot standby database
Fast-Start Failover: DISABLED
Current status for "mycon":
SUCCESS

You have now converted your standby database into a test database. This feature is extremely useful when combined with the  Real Application Testing features provided in the 11g which are beyond the scope of this article.

Note: Under the covers, the convert command enables flashback database if not already enabled. When converting back to a physical standby, the snapshot standby is flashed back to the point in time when the physical standby was originally converted. When testing is completed, you convert the snapshot standby database back to a physcial standby database.
Converting back to a standby is done as follows:

DGMGRL> convert database FGUARD to physical standby;
Converting database "FGUARD" to a Physical Standby database,
please wait...
Operation requires shutdown of instance "FGUARD" on database
"FGUARD"
Shutting down instance "FGUARD"...
[…]
Operation requires startup of instance "FGUARD" on database
"FGUARD"
[…]
Continuing to convert database "FGUARD" ...
Operation requires shutdown of instance "FGUARD" on database
"FGUARD"
[…]
Operation requires startup of instance "FGUARD" on database
"FGUARD"
Starting instance "FGUARD"...
ORACLE instance started.
Database mounted.
Database "FGUARD" converted successfully



Information collected from: http://gavinsoorma.com/2009/12/11g-standby-database-creation-without-any-rman-backups/