Active Data Guard and Snapshot Standby Features Of 11G

Active Data Guard and Snapshot Standby Features Of 11G
This is a nice database article to see active data guard and snapshot standby features in 11G. It also covers the below topics:
1: Activate Real Time Query on a physical standby database
2: Convert a physical standby database to snapshot standby mode
3: Utilize a snapshot standby database for testing application changes
4: Convert a snapshot standby database back to physical standby mode
http://www.databasejournal.com/features/oracle/article.php/3834931/article.htm

Configuring Dataguard Broker

Configuring Dataguard Broker:
This is a beautiful database article to configure dataguard broker in 11G . It also covers the below topics:
1: Demonstrates how to set up and utilize Data Guard Broker features in Oracle Database 11g.
2: Configuration of standby redo logs on the standby database.
3: Configuration of the primary and standby databases to ensure successful setup of Data Guard Broker
4: Data Guard Broker configuration on primary and standby database servers
5: Using Data Guard Broker to perform a switchover operation
6: Using Data Guard Broker to perform a switchback operation
http://www.databasejournal.com/features/oracle/article.php/3822176/Configuring-Data-Guard-Broker.htm
I hope the above link will definitely help you to configure and use data guard broker in your environment.

Task List for Physical Standby Database Creation

Task List: Preparing to create a physical standby database:
This section provides a checklist of tasks that you perform to create a physical standby database and synchronize it so that it is ready to begin managed recovery. Each step includes a reference to a section that provides additional information.

Preparing the Primary Database for Standby Database Creation:
Primary Node:
Enable Forced Logging
Create a Password File
Configure a Standby Redo Log
Set Primary Database Initialization Parameters
Enable Archiving

Step-by-Step Instructions for Creating a Physical Standby Database:
Primary Node:
Create a Backup Copy of the Primary Database Datafiles
Create a Control File for the Standby Database
Prepare an Initialization Parameter File for the Standby Database
Copy Files from the Primary System to the Standby System

Standby Node:
Set Up the Environment to Support the Standby Database
Start the Physical Standby Database
Verify the Physical Standby Database Is Performing Properly

Post-Creation Steps:
Primary/Standby Node:
Upgrade the data protection mode
Enable Flashback Database

Configure Standby Database using RMAN

Configure Physical Standby Database using RMAN:
Follow the below steps to configure physical standby database using RMAN

Target Database:
Make sure the target database is mount or on open stage.

$ export ORACLE_SID TEST
$ rman target /
RMAN> show all;
Using target database controlfile instead of recovery catalog RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 1 DAYS;
CONFIGURE BACKUP OPTIMIZATION OFF;CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/u01/oradata/backup/Oracle_Backups d_ F.rman';
CONFIGURE DEVICE TYPE DISK PARALLELISM 1;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/u01/oradata/backup/Oracle_Backups d_ F.rman';
CONFIGURE MAXSETSIZE TO UNLIMITED;
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/oradata/backup/ORACLEORA92DATABASESNCFTEST.ORA';

2. Backup the current production database to create a standby database:

RMAN> backup database include current controlfile for standby plus archivelog;

3. Manually copy the backup sets from the production server to the DR Server (location of backups must match on both production and DR). Make sure all DR filesystems are identical with respect to the target database environment.

4. On the DR Server start up the TEST database in nomount mode. Make sure the parameter file and password file are all present at DR server at $ORACLE_HOME/dbs location for UNIX system.

$ set ORACLE_SID TEST
$ sqlplus /nolog
SQL> connect / as sysdba
SQL> startup nomount
SQL> exit

5. Create the standby database using RMAN. This assumes the database file structures will be identical on both servers. Also you have initialization parameter, password file and backup piece are all placed in their correct locations. The tnsnames.ora and listener.ora must have information for target and auxiliary database and listener is up.

$ RMAN target ‘sys/password@TEST’ auxiliary / (This is executed from DR server.)
RMAN> duplicate target database for standby nofilenamecheck dorecover;

6. Once the DR database is created, you will need to manually add a tempfile:

SQL> alter database open read only;
SQL> alter tablespace temp add tempfile ‘/u01/oradata/TEMP01.DBF’ size 500M;

7. Put the DR database into managed standby mode:

SQL> shutdown immediate
SQL> startup nomount
SQL> alter database mount standby database;
SQL> alter database recover managed standby database disconnect;

8. On the production database switch logs to initiate replication:

SQL> alter system switch logfile;

The configuration of Dataguard is now complete.

For more detailed information to create a Physical standby database using RMAN, refer the below URL:
http://www.idevelopment.info/data/Oracle/DBA_tips/RMAN_9i/RMAN9_32.shtml

Logical vs Physical Standby database

Logical vs Physical Standby database:
------------------------------------------------
The primary functional difference between logical and physical standby database setups is that:

Physical standby database: This is always an exact structural duplicate of the master database.
Logical standby database: Permits you to add additional objects (tables, indexes, etc) to the database.
Logical standby database: Logical standby is based on newer technologies (logical standby is new in Oracle 9.2) and tends to be generally regarded as more tempramental than physical standby.

Physical standby database: This is physically identical to the primary database on a block-for-block basis. It's maintained in managed recovery mode to remain current and can be set to read only. Archive logs are copied and applied.
Logical standby database: This is logically identical to the primary database. It is updated using SQL statements.

Physical Standby database: Achieved by copying the archivle log files.
Logical Standby database: Makes the dml statements using archivelogs generated and applies to the secondary database.

Physical Standby database: Archived redo logs and FTP'ed directly to the standby database which is always running in "recover" mode. Upon arrival, the archived redo logs are applied directly to the standby database.
Logical standby database: This uses LogMiner techniques to transform the archived redo logs into native DML statements (insert, update, delete). This DML is transported and applied to the standby database.
Logical standby database: This can have additional materialized views and indexes added for faster performance.

Learn more how to create physical or logical standby databases for your enterprise.
http://www.orafaq.com/node/957

Data Guard Protection Modes

Oracle 10G Data Guard Protection Modes:
---------------------------------------------------------
This chapter contains the following sections:

• Data Guard Protection Modes
• Setting the Data Protection Mode of a Primary Database

Data Guard Protection Modes:
This section describes the Data Guard protection modes.
In these descriptions, a synchronized standby database is meant to be one that meets the minimum requirements of the configured data protection mode and that does not have a redo gap.

Maximum Availability:
This protection mode provides the highest level of data protection that is possible without compromising the availability of a primary database. Transactions do not commit until all redo data needed to recover those transactions has been written to the online redo log and to at least one synchronized standby database. If the primary database cannot write its redo stream to at least one synchronized standby database, it operates as if it were in maximum performance mode to preserve primary database availability until it is again able to write its redo stream to a synchronized standby database.

This mode ensures that no data loss will occur if the primary database fails, but only if a second fault does not prevent a complete set of redo data from being sent from the primary database to at least one standby database.

Maximum Performance:
This protection mode provides the highest level of data protection that is possible without affecting the performance of a primary database. This is accomplished by allowing transactions to commit as soon as all redo data generated by those transactions has been written to the online log. Redo data is also written to one or more standby databases, but this is done asynchronously with respect to transaction commitment, so primary database performance is unaffected by delays in writing redo data to the standby database(s).

This protection mode offers slightly less data protection than maximum availability mode and has minimal impact on primary database performance.

This is the default protection mode.

Maximum Protection
This protection mode ensures that zero data loss occurs if a primary database fails. To provide this level of protection, the redo data needed to recover a transaction must be written to both the online redo log and to at least one synchronized standby database before the transaction commits. To ensure that data loss cannot occur, the primary database will shut down, rather than continue processing transactions, if it cannot write its redo stream to at least one synchronized standby database.

Because this data protection mode prioritizes data protection over primary database availability, Oracle recommends that a minimum of two standby databases be used to protect a primary database that runs in maximum protection mode to prevent a single standby database failure from causing the primary database to shut down.

Setting the Data Protection Mode of a Primary Database
Perform the following steps to change the data protection mode of a primary database:
Step 1 Select a data protection mode that meets your availability, performance and data protection requirements.

Step 2 Verify that redo transport is configured to at least one standby database
The value of the LOG_ARCHIVE_DEST_n database initialization parameter that corresponds to the standby database must include the redo transport attributes listed below for the data protection mode that you are moving to.

If the primary database has more than one standby database, only one of those standby databases must use the redo transport settings.

The standby database must also have a standby redo log.

Required Redo Transport Attributes for Data Protection Modes

Maximum Availability:

• AFFIRM
• SYNC
• DB_UNIQUE_NAME

Maximum Performance:

• NOAFFIRM
• ASYNC
• DB_UNIQUE_NAME

Maximum Protection:

• AFFIRM
• SYNC
• DB_UNIQUE_NAME

Step 3 Verify that the DB_UNIQUE_NAME database initialization parameter has been set to a unique name on the primary and standby database.

For example, if the DB_UNIQUE_NAME parameter has not been defined on either database, the following SQL statements might be used to assign a unique name to each database.

Execute this SQL statement on the primary database:

SQL> ALTER SYSTEM SET DB_UNIQUE_NAME='CHICAGO' SCOPE=SPFILE;

Execute this SQL statement on the standby database:

SQL> ALTER SYSTEM SET DB_UNIQUE_NAME='BOSTON' SCOPE=SPFILE;

Step 4 Verify that the LOG_ARCHIVE_CONFIG database initialization parameter has been defined on the primary and standby database and that its value includes a DG_CONFIG list that includes the DB_UNIQUE_NAME of the primary and standby database.

For example, if the LOG_ARCHIVE_CONFIG parameter has not been defined on either database, the following SQL statement could be executed on each database to configure the LOG_ARCHIVE_CONFIG parameter:

SQL> ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(CHICAGO,BOSTON)';

Step 5 Shut down the primary database and restart it in mounted mode if the protection mode is being set to Maximum Protection or being changed from Maximum Performance to Maximum Availability. If the primary database is an Oracle Real Applications Cluster, shut down all of the instances and then start and mount a single instance.
For example:

SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;

Step 6 Set the data protection mode.
Execute the following SQL statement on the primary database:

SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {AVAILABILITY PERFORMANCE PROTECTION};

If the primary database is an Oracle Real Applications Cluster, any instances stopped in Step 5 can now be restarted.

Step 7 Open the primary database.
If the database was restarted in Step 5, open the database:
SQL> ALTER DATABASE OPEN;

Step 8 Confirm that the primary database is operating in the new protection mode.
Perform the following query on the primary database to confirm that it is operating in the new protection mode:
SQL> SELECT PROTECTION_MODE FROM V$DATABASE;

Oracle Data Guard

Introducing Oracle Data Guard:
Oracle Data Guard is the most effective and comprehensive Disaster Recovery solution available today for enterprise data. Follow the below URL to understand the basics of Oracle Data guard.
http://www.oracle.com/technology/deploy/availability/pdf/DataGuardTechnologyOverview.pdf

Manage Dataguard via OEM

Manage Physical Standby Database using OEM:
This presentation will give you an idea how to manage a physical standby database using grid control. This covers failover and switchover scenarios also.

http://docs.google.com/Presentation?id=dfwx283d_950hjf546f3