Showing posts with label Data Guard. Show all posts
Showing posts with label Data Guard. Show all posts

Sunday, October 3, 2010

Step by step Create an Oracle 11gR2 Physical Standby Database

In this article I will show step by step procedure to create an Oracle 11gR2 physical standby database. This example environment is as follows:

- Both primary and standby database are on RAC environment. Both are 2 nodes RAC.
- The distance between primary and standby database is 300 kilometers and they are within Bangladesh.
- There is 10 Mbps dedicated bandwidth between primary and standby database.
- All 4 nodes are using Red Hat Linux Enterprise version 5 operating system and same hardware structure.
- Oracle 11gR2 is installed both in primary and physical standby database.
- Oracle datafiles and clusterware are on ASM file system.

Though this example is based on RAC and ASM, you can use this document to setup any type of physical standby database. I will tell explicitly what to do based on whether your environment is non-RAC or not, whether you use ASM or not.

In this example the following values are used:
- Database name is bddipdc
- Primary database unique name as well as oracle net service name is bddipdc
- Standby database unique name as well as oracle net service name is bddipdrs
- Primary database hostname is DC-DB-01 and standby database hostname is DRS-DB-01
- Primary database IP Address is 192.168.100.101 and standby database IP Address is 192.168.105.101

Step 01: Prepare the Primary and physical standby database environment: (Both bddipdc and bddipdrs)
i) After you have physically placed hardware in both site install operating system in both end. The site in which primary database reside called as Data Center (DC) and the site in which standby database reside called as Disaster Recovery Site (DRS) and that is I choose the unique name as bddipdc and bddipdrs correspondingly.

ii) Install Oracle software as well as oracle database both in primary and standby database site. Though database creation in standby site is not mandatory but you can create database specially if you are in RAC environment. Because in that case you don't need to do many manual tasks like register database to cluster registry etc. Note that both in primary and standby site, while creating database keep the database name same that is bddipdc.

Step 02: Prepare the Primary Database for Standby Database Creation: (Only bddipdc)
i) Enable force logging on primary database.
SQL> ALTER DATABASE FORCE LOGGING;

ii) Set the database initialization parameters.
#Primary database role initialization parameters.
DB_NAME=bddipdc
DB_UNIQUE_NAME=bddipdc
LOG_ARCHIVE_CONFIG='DG_CONFIG=(bddipdc,bddipdrs)'
LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=bddipdc'
LOG_ARCHIVE_DEST_2='SERVICE=bddipdrs SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=bddipdrs'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
LOG_ARCHIVE_FORMAT=%t_%s_%r.arc
LOG_ARCHIVE_MAX_PROCESSES=30

# Standby role initialization parameters.
FAL_SERVER=bddipdrs
DB_FILE_NAME_CONVERT='bddipdrs','bddipdc'
LOG_FILE_NAME_CONVERT='bddipdrs','bddipdc'
STANDBY_FILE_MANAGEMENT=AUTO
As primary database is using spfile so run the following commands on primary database.
alter system set DB_UNIQUE_NAME=bddipdc scope=spfile sid='*';
alter system set LOG_ARCHIVE_CONFIG='DG_CONFIG=(bddipdc,bddipdrs)' scope=both sid='*';
alter system set LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=bddipdc' scope=both sid='*';
alter system set LOG_ARCHIVE_DEST_2='SERVICE=bddipdrs SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=bddipdrs' scope=both sid='*';
alter system set LOG_ARCHIVE_DEST_STATE_1=ENABLE scope=both sid='*';
alter system set LOG_ARCHIVE_DEST_STATE_2=ENABLE scope=both sid='*';
alter system set LOG_ARCHIVE_MAX_PROCESSES=30 scope=both sid='*';
alter system set STANDBY_FILE_MANAGEMENT=AUTO scope=both sid='*';
alter system set FAL_SERVER=bddipdrs scope=both sid='*';
alter system set FAL_CLIENT=bddipdc scope=both sid='*';
We have not set any DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT parameters because in standby database we want to keep same file structure as it is in primary database.

iii) Enable archivelog in primary database.
If the primary database is not in archivelog mode then enable archivelog in primary database. If your database is in archivelog mode then you can simply forward to next phase.
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE ARCHIVELOG;
SQL> ALTER DATABASE OPEN;
If your database is in RAC environment then you can follow Enable archivelog for RAC. If you are in non RAC environment then you can follow Change archivelog mode .

Step 03: Determine datafiles, controlfiles, password file, initialization parameter files to be copied from primary to standby database (bddipdc):
You can create standby database using RMAN. But in this post I want to show all steps manually because RMAN has several bug while creating another copy of database over the network.

i)Connect to one Oracle instance and determine the location of datafiles and tempfiles. Save the file location in a notepad.
Determine the location of datafile,
SQL> select name from v$datafile;
NAME
----------------------------------------------------
+DATA/bddipdc/datafile/system.267.728507607
+DATA/bddipdc/datafile/sysaux.259.728507607
+DATA/bddipdc/datafile/undotbs1.258.728507609
+DATA/bddipdc/datafile/users.257.728507609
+DATA/bddipdc/datafile/undotbs2.270.728507783
Determine the location of oracle tempfile.
SQL> select name from v$tempfile;
NAME
----------------------------------
+DATA/bddipdc/tempfile/temp.271.728507701

ii)Create the pfile from spfile of primary database.
SQL> conn / as sysdba
SQL> create pfile='/tmp/bddipdc/initbddipdc.ora' from spfile;


iii) Shutdown the primary database. If you are in RAC environment, then shut down all instances.
SQL> shut immediate;

Using srvctl,
$ srvctl stop database -d bddipdc

iv) This step is only applicable if your database files are in ASM. As our datafiles and tempfiles are in ASM file system so we need to copy them under /tmp/bddipdc in order to move the datafiles and tempfiles into another computer.

Ensure that your ORACLE_SID and ORACLE_HOME points to ASM home and ASM SID.
Invoke asmcmd.
$asmcmd
ASMCMD> cp +DATA/bddipdc/datafile/system.267.728507607 /tmp/bddipdc/system
ASMCMD> cp +DATA/bddipdc/datafile/sysaux.259.728507607 /tmp/bddipdc/sysaux
ASMCMD> cp +DATA/bddipdc/datafile/undotbs1.258.728507609 /tmp/bddipdc/undotbs1
ASMCMD> cp +DATA/bddipdc/datafile/users.257.728507609 /tmp/bddipdc/users
ASMCMD> cp +DATA/bddipdc/datafile/undotbs2.270.728507783 /tmp/bddipdc/undotbs2
ASMCMD> cp +DATA/bddipdc/tempfile/temp.271.728507701 /tmp/bddipdc/temp
v) Start one instance of primary database in mount state. If you are in non RAC environment then just start database in mount state.
SQL> startup mount;

Create the standby control file.
SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/bddipdc/control01.ora';

Step 04: Copy password file, datafile, standby controlfile, pfile from primary database to standby database.
Up to now we have datafile, tempfile, standby controlfile, pfile under one directory /tmp/bddipdc in the primary database. Now also we need to move password file into /tmp/bddipdc directory so that we can simply scp to remote location and with one command all files will be copied to standby database.
$ scp -r /tmp/bddipdc oracle@drs-db-01:/tmp/bddipdc

Copy node 1 of primary database password file across all nodes in standby database (This one is only applicable for RAC)
The password file of node 1 of primary database need to be copied across all instances in standby database as well as all other nodes in primary database as well.

Step 05: Start the Standby database and set initialization parameters. (bddipdrs)
At this stage we have all required files under location /tmp/bddipdc to setup physical standby database. We have already one database created in standby site. So we can use that spfile for our standby database creation. Though we have pfile in the location /tmp/bddipdc (which we copied from primary database) we will use current spfile of existing standby database in order minimize the steps.

i) Shut down standby database (in RAC shut down all instances) and start in nomount state (in RAC start one instance in nomount stage).
SQL> shut immediate;
SQL> startup nomount;


Set the initialization parameters.
SQL> alter system set DB_UNIQUE_NAME=bdafisdc scope=spfile sid='*';
alter system set LOG_ARCHIVE_CONFIG='DG_CONFIG=(bdafisdc,bdafisdrs)' scope=both sid='*';
alter system set LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=bdafisdc' scope=both sid='*';
alter system set LOG_ARCHIVE_DEST_2='SERVICE=bdafisdrs SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=bdafisdrs' scope=both sid='*';
alter system set LOG_ARCHIVE_DEST_STATE_1=ENABLE scope=both sid='*';
alter system set LOG_ARCHIVE_DEST_STATE_2=ENABLE scope=both sid='*';
alter system set LOG_ARCHIVE_MAX_PROCESSES=30 scope=both sid='*';
alter system set STANDBY_FILE_MANAGEMENT=AUTO scope=both sid='*';
alter system set FAL_SERVER=bdafisdrs scope=both sid='*';
alter system set FAL_CLIENT=bdafisdc scope=both sid='*';
We also set the location of control_files. We will copy standby control file into this location.
alter system set control_files='+DATA/bddipdc/controlfile/control01.ctl' scope=spfile sid='*';

iii) shutdown the standby database.
SQL> shut immediate;

iv) Delete all control files, datafiles, tempfiles of current standby database and copy these standby control file, datafile, tempfile into ASM file system. I am keeping the path of these files same as primary database. Note that if you are not in ASM file system then instead of +DATA use your desired location.
$ asmcmd
ASMCMD> cp /tmp/bddipdc/control01.ora +DATA/bddipdc/controlfile/control01.ctl
ASMCMD> cp /tmp/bddipdc/system +DATA/bddipdc/datafile/system
ASMCMD> cp /tmp/bddipdc/sysaux +DATA/bddipdc/datafile/sysaux
ASMCMD> cp /tmp/bddipdc/undotbs1 +DATA/bddipdc/datafile/undotbs1
ASMCMD> cp /tmp/bddipdc/undotbs2 +DATA/bddipdc/datafile/undotbs2
ASMCMD> cp /tmp/bddipdc/users +DATA/bddipdc/datafile/users
ASMCMD> cp /tmp/bddipdc/temp /tmp/bddipdc/temp
v) Start the standby database in mount state.
SQL> startup mount

Set the undo_management parameter manual.
SQL> alter system set undo_management=MANUAL scope=both sid='*';

Now rename datafiles and tempfiles in order to use the correct location as we copied to ASM file system.
SQL> alter database rename file '+DATA/bddipdc/datafile/system.267.728507607' to '+DATA/bddipdc/datafile/system';
SQL> alter database rename file '+DATA/bddipdc/datafile/sysaux.259.728507607' to '+DATA/bddipdc/datafile/sysaux';
SQL> alter database rename file '+DATA/bddipdc/datafile/undotbs1.258.728507609' to '+DATA/bddipdc/datafile/undotbs1';
SQL> alter database rename file '+DATA/bddipdc/datafile/users.257.728507609' to '+DATA/bddipdc/datafile/users';
SQL> alter database rename file '+DATA/bddipdc/datafile/undotbs2.270.728507783' to '+DATA/bddipdc/datafile/undotbs2';
SQL> alter database rename file '+DATA/bddipdc/tempfile/temp.271.728507701' to '+DATA/bddipdc/datafile/temp';
Step 06: Configure TNS entry and listener across all nodes. (All nodes)
In all nodes configure TNS entry so that you can reach from primary to standby database and vice versa.
Within the file $ORACLE_HOME/network/admin/tnsnames.ora add the following two entries.
BDDIPDRS =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = DRS-DB-01)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = bddipdc.world)
)
)

BDDIPDC =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = DC-DB-01)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = bddipdc.world)
)
)
Before configuring TNS entry be sure about your host name, port number and service name. You can easily check that by issuing,
$ lsnrctl status

You should put an static listener entry within $GRID_HOME/network/admin/listener.ora if you are in RAC
and you should put an static listener entry within $ORACLE_HOME/network/admin/listener.ora if you are in non RAC system.

Following is an static entry for node 1 from primary database.
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = bddipdc.world)
(ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_1)
(SID_NAME = bddipdc1)
)
)
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = IPC)(KEY = LISTENER))
(ADDRESS = (PROTOCOL = TCP)(HOST =DC-DB-01)(PORT = 1521))
)
)
Note: If you are in non RAC system then instead of SID bddipdc1 you must use Database name that is bddipdc.

Following is an static listener entry for node 2 in primary database.
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = bddipdc.world)
(ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_1)
(SID_NAME = bddipdc2)
)
)
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = IPC)(KEY = LISTENER))
(ADDRESS = (PROTOCOL = TCP)(HOST =DC-DB-02)(PORT = 1521))
)
)
Note: Just host name and Oracle SID name is change for node 2.

Following is the listener entry for the node 1 in standby database.
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = bddipdc.world)
(ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_1)
(SID_NAME = bddipdc1)
)
)
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = IPC)(KEY = LISTENER))
(ADDRESS = (PROTOCOL = TCP)(HOST =DRS-DB-01)(PORT = 1521))
)
)
Note: Just I have changed the hostname. If you are non RAC system then instead of instance SID bddipdc1 use database name bddipddc instead.

Step 7: Verify that TNS names and password file across all the instances are working properly. (All nodes):
Both in primary and standby database across all nodes issue,
$ tnsping bddipdc
$ tnsping bddipdrs
$ sqlplus sys/password@bddipdc as sysdba
$ sqlplus sys/password@bddipdrs as sysdba
If you can connect to both primary and standby instances using TNS entry from all nodes through sqlplus then your password file as well as TNS entry is perfect.


Step 8: Create standby redo log and start redo apply on standby database (bddipdrs):
Create standby redo logfile on standby database bddipdrs by following command,
alter database add standby logfile thread 1 size 50M;
alter database add standby logfile thread 2 size 50M;
alter database add standby logfile thread 1 size 50M;
alter database add standby logfile thread 2 size 50M;
alter database add standby logfile thread 1 size 50M;
alter database add standby logfile thread 2 size 50M;
Or, simply you can run following command if you are in non RAC environment.
alter database add standby logfile size 50M;
Set the undo_management parameter to AUTO.
SQL> alter system set undo_management=AUTO scope=both sid='*';
Start Redo Apply,

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

Step 09: Verify that standby database is performing properly.
i)Identify the existing archived redo log files. (bddipdrs -standby)
On the standby database, query the V$ARCHIVED_LOG view to identify existing files in the archived redo log. For example:

SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

ii)Force a log switch to archive the current online redo log file.
On the primary database, issue the ALTER SYSTEM SWITCH LOGFILE statement to force a log switch and archive the current online redo log file group:

SQL> ALTER SYSTEM SWITCH LOGFILE;

iii) Verify the new redo data was archived on the standby database.
On the standby database, query the V$ARCHIVED_LOG view to verify the redo data was received and archived on the standby database:

SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
In the output you should see one extra row than previous query.

iv)Verify that received redo has been applied.
On the standby database, query the V$ARCHIVED_LOG view to verify that received redo has been applied:

SQL> SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

Wednesday, September 29, 2010

Primary DB freezed with waited too long for a row cache enqueue lock

Problem Description
On Oracle database 10.2.0.3.0 Data Guard with Broker configuration whenever there is an attempting to restart the standby in read only, the following error occurs:

ERROR: WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK
ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
ORA-12170: TNS:Connect timeout occurred
PING[ARC6]: Error 3113 when pinging standby
ARC6: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (1089)

The errors occurred in standby database and primary database hangs!

Cause of the Problem
The above error is caused by LGWR process in Oracle Data Guard having RAC environment and it is in fact Oracle bug. The bug number is 7487408.
The bug fires whenever Data Guard is managed by Broker and standby database is shutdown or opened in read only mode. The Primary still tries to ship/send redo streams to standby in SYNC mode and eventually hangs.

Solution of the Problem
- Download the optach 7487408 from oracle support/metalink in order to solve the bug.
- The above bug is fixed in Oracle patchset 10.2.0.5. So you need to upgrade your oracle database to 10.2.0.5.

Wednesday, September 22, 2010

New Features in Oracle Data Guard Broker 11g

As 11g has two releases 11.2g and 11.1g so I will include new features into two sections.
New features in Oracle Data Guard Broker 11.1g
1. Fast start failover can be performed from a Data Guard broker if the database configuration is operating in maximum performance mode.

2. The new DBMS_DG PL/SQL package allows applications to notify the observer process to initiate a fast-start failover to the target standby database.

3. We can configure data guard broker to perform fast start failover based errors raised by the Oracle server.

4. After a failover, the observer automatically attempts to reinstate bystander standby databases.

5. Through DGMGRL CONVERT DATABASE command, you can convert physical standby database to a snapshot standby database, or reverts the snapshot standby database back to a physical standby database.

6. You can specify a connect identifier for Redo Transport Services as you want.

7. No need to shutdown database when changing the protection mode to and from maximum availability and maximum performance.

8. Support for Redo Apply on physical standby databases opened for read.

9. Allow a primary or logical standby database in a Data Guard Broker configuration to be mounted without having to be opened automatically.

10. The DGMGRL client ADD DATABASE command can import a pre-configured service attribute from a LOG_ARCHIVE_DEST_n parameter when adding a standby database to the configuration. So we can only issue "ADD DATABASE {DATABASE_NAME}" command instead of specifying any connect identifier.

11. A primary database can be in either the TRANSPORT-OFF or TRANSPORT-ON state. A standby database can be in either the APPLY-OFF or APPLY-ON state. In this way, database states become simpler.

12. In 11.1g the network bandwidth utilization in a Data Guard configuration is done efficiently by compressing archived redo logs as they are transmitted over the network to standby databases, when the log is sent to satisfy a gap at a standby database.

13. You can now specify USE_DB_RECOVERY_FILE_DEST as the value for the AlternateLocation and StandbyArchiveLocation instance-specific properties.

14. The following new Data Guard command-line interface (DGMGRL) commands are available:

CONVERT DATABASE TO SNAPSHOT STANDBY

CONVERT DATABASE TO PHYSICAL STANDBY

DISABLE FAST_START FAILOVER CONDITION

ENABLE FAST_START FAILOVER CONDITION

SHOW FAST_START FAILOVER

15. The following new database properties are available:

DGConnectIdentifier (replaces InitialConnectIdentifier)

ObserverConnectIdentifier

RedoCompression

16. The following new configuration properties are available:

FastStartFailoverAutoReinstate

FastStartFailoverLagLimit

FastStartFailoverPmyShutdown

17. The LsbyTxnConsistency database property has been renamed to LsbyPreserveCommitOrder.

18. New default of ASYNC for the LogXptMode database property.


New features in Oracle Data Guard Broker 11.2g
1. Now the broker configuration consist of 1 primary database and up to 30 standby databases.

2. The value of an instance-specific property can be changed for all instances in one command.

3. In 11.1g redo transport compression was limited to compressing redo data only when a redo gap is being resolved. In 11.2g when compression is enabled for a destination, all redo data sent to that destination is compressed.

4. Improved status and error reporting for the SHOW CONFIGURATION and SHOW DATABASE commands.

5. The SHOW DATABASE command displays the apply lag and transport lag of a standby database.

6. Shutting down all instances but one on a target physical standby for role changes is no longer required.

7. FAN/ONS (Fast Application Notification/Oracle Notification Services) notification is sent after a failover for databases configured with Oracle Clusterware and for single-instance databases registered with Oracle Restart.

8. FAN/AQ (Fast Application Notification/Advanced Queueing) notification is sent after a failover to a logical standby database.

9. Integration with Active Data Guard (automatic stop and restart of apply) when an apply instance is opened.

10. Reinstatement of the old (original) primary database after an immediate failover.

11. Improved hang detection and resolution for broker network communications. In addition, a new configuration property, CommunicationTimeout, enables the user to select an appropriate timeout value for their environment.

12. New database property, StaticConnectIdentifier, which allows the user to specify a static connect identifier that the DGMGRL client will use to start database instances.

13. Protection mode upgrades from maximum availability to maximum protection no longer require a restart of the primary database. This means that when upgrading from maximum performance mode to maximum protection mode, you can avoid a restart of the primary database by first upgrading to maximum availability. Once in maximum availability mode, you can then upgrade to maximum protection mode.

14. Data Recovery Adviser now uses Data Guard to suggest viable repair options for a primary database that cannot be repaired in a timely manner.

Saturday, July 17, 2010

While startup standby database it fails with ORA-01154

Problem Description
Whenever you try to open or shutdown a standby database it fails with error ORA-01154
SQL> connect / as sysdba
Connected.

SQL> alter database open
ORA-01154: database busy. Open, close, mount, and dismount not allowed now

SQL> shutdown
ORA-01154: database busy. Open, close, mount, and dismount not allowed now

Cause of the Problem
The database is a standby database and it is in managed recovery mode. To verify the database is in managed recovery mode, enter this command

SQL> SELECT RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS;

If it returns MANAGED then the standby database is in managed recovery mode.

If database is in managed recover mode then it is not allowed to do open or shutdown the database.

Solution of the Problem
To take the database out of managed recovery mode, enter this command

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

You can now open the database as,
SQL> ALTER DATABASE OPEN READ ONLY;

Or, you may now shutdown the database.
SQL> shutdown

Wednesday, December 16, 2009

ORA-01665: control file is not a standby control file

Problem Description
While recovering standby database, using command alter database recover managed standby database disconnect from session it fails with message ORA-01665: control file is not a standby control file like below.
SQL> alter database recover managed standby database disconnect from session;
alter database recover managed standby database disconnect from session
*
ERROR at line 1:
ORA-01665: control file is not a standby control file

Cause of the Problem
The error occurred because there was an attempt to mount, recover, or activate a standby database without a standby controlfile. In order to recover standby database you need standby controlfile. If you don't have standby controlfile and use normal controlfile then above error will occurred.

Solution of the Problem
The solution is to create a standby controlfile before attempting to use the database as a standby database.

1)So if you don't have a standby controlfile for your standby first create a standby controlfile from source database using command,

SQL>alter database create standby controlfile as 'standbyctlfile.ctl';

2)Transfer this standby controlfile into standby database.

3)Edit the standby database pfile control_files parameter in order to effect the changes.

4)Startup the database in nomount stage.
SQL> startup nomount pfile='your_pfile_location';

5)Create spfile from the pfile.
SQL> create spfile from pfile='your_pfile_location';

6)Shutdown the database.
SQL>shutdown immediate;

7)Start the database in mount state.
SQL>startup mount;

8)On the standby database, start redo apply by following command.
SQL>alter database recover managed standby database disconnect from session;

Note that only step 1) need to be performed in primary database only. All other steps will be done in standby database.

Related Documents
http://arjudba.blogspot.com/2009/04/different-types-of-standby-database-in.html
http://arjudba.blogspot.com/2009/04/what-is-oracle-data-guard.html

Friday, April 3, 2009

Different types of standby database in oracle data guard

In oracle data guard configuration, you need to setup one or more additional databases beside the primary database. These additional databases are called standby database. Up to nice standby database can be created for one primary database.

Using a backup of primary database you can set up standby database and then you can made standby database as part of data guard configuration. Once you configured standby database, data guard automatically maintains standby database by transmitting redo log from the primary database and then applying redo to the standby database.

A standby database can be of three types.

1)Physical Standby Database: A physical standby database is an identical copy of the primary database. The disk structures are also identical with primary database. It is kept synchronized with the primary database by Redo Apply- which means the redo data is received from the primary database and then redo is applied to the physical standby database.

Note that as of Oracle Database 11g release 1 (11.1), a physical standby database can receive and apply redo while it is open for read-only access. You can use physical standby database for query and reporting purpose along with data protection.

2)Logical Standby Database: A logical standby database is the same logical information of the primary database. The physical data structure need not to be same on the standby database. It is kept synchronized with the primary database by SQL Apply- which means the redo data is received from the primary database, transforms redo data into SQL statements and at last executes the SQL statements on the standby database.

You can use logical standby database for query and reporting purpose along with data protection. Also you have to facility to upgrade oracle database software and patch sets along with data protection with help of logical standby database.

3)Snapshot Standby Database: A snapshot standby database is a convertible copy of the physical standby database but the difference from the physical or logical standby database is, the redo data that it received does not apply into it. The redo is applied whenever it is converted back to the physical standby database. You can play with the snapshot standby database and while converting to physical standby database from snapshot standby database these local updates are discarded.

Note that in case of snapshot standby database, the time needed to perform a role transition is directly proportional to the amount of redo data that needs to be applied.

Related Documents
http://arjudba.blogspot.com/2009/04/what-is-oracle-data-guard.html

Thursday, April 2, 2009

What is oracle data guard

Oracle data guard is the term(you can call it a feature too) used by oracle and this feature is integrated with oracle RDBMS. Data guard create, maintain, manage and monitor one/more extra databases -called standby database, beside production database. The goal is to survive production databases from any disasters, failure or data corruptions.

At first, an exact replica of production database is created, which referred to as standby database later. Data guard then maintains and keep up to date of these standby databases with of production database. If production database becomes unavailable then data guard can switch standby database to production role and thus minimize the downtime without any data loss.

In addition to availability of production database data guard gives other advantages. Like we can do real time query in standby database, do backup operation in it and thus minimize the load of production database.

There is no restriction about the location of the stand by databases. They can be located thousands miles away from the production database or can be within same room, provided they can communicate each-other.

The more features, configurations, advantage about oracle data guard will be discussed gradually.
Related Documents
http://arjudba.blogspot.com/2009/04/different-types-of-standby-database-in.html