Monday, November 16, 2015

What is special permission in Unix -- An interesting topic for all Unix admin / DBAs

Yesterday , I had faced a strange issue while starting up oracle instance after applying PSU4 into our 12.1.0.2 database . Even when my ASM was up and running , I couldn't    able to start my database instances . Alerts log clearly showing ASM is not available .its quite strange to me so I started googling .After an hours of googling  I found the solution .The file permission of $ORACLE_HOME/bin/oracle got changed som how  while applying the PSU , So I have executed following and I am able to start my database instances .

#chown oracle:asmadmin $ORACLE_HOME/bin/oracle 
#chmod 6751 $ORACLE_HOME/bin/oracle 
  
We are familiar with setting file permission with 3 digit combination like  777,755 etc .
Now the question is,what is the purpose of this extra digit 6 here ?  and the answer is, its the combination of unix special file permission suid and sgid. 
So this time  instead of talking about Oracle specific topic , I would like to discuss more about Special permission in Unix based operating system. So for all DBAs who all are working in Unix based OS ,this will be an added advantage for them , if they have good idea about special permission in Unix. 

There are three type of special permission bits that may be setup on executable files or directories if required.
These permission bits are,
1.setuid (set user identification bit )
2.setgid (set group identification bit)
3.sticky bit

1)The suid (set user id bit)

Setting the suid bit on a file allows normal users to run that application with raised (usually superuser) priviledges. Remember that when a user launches an application, that application runs with the same permissions as that user. This is one of the fundamental differences between Windows and *nix systems.
An example of a file that has the suid bit set in most cases is the /usr/bin/passwd application. You can see that the /usr/bin/passwd application has the suid bit set by the letter s in place of the user’s eXecutable bit.

-rwsr-xr-x 1 root root 26680 May 10 13:44 passwd

For listing the setuid bit enabled files you can use the common ls command with long list parameter as follows
[root@node2 ~]# ls -lrt /bin/su
-rwsr-xr-x 1 root root 24060 Nov 27 2006 /bin/su

You can see that the owner-executable bit is set to 's', that means the executable file is setuid enabled
The passwd application allows users to change their own passwords. In order to do so, it has to write to the etc/passwd file which contains all of the accounts on a GNU/Linux system. However, if the suid bit was not set on the passwd application then the passwd application would only have the rights of the user and therefore could not make changes to the etc/passwd file. Setting the suid bit on the passwd application allows it to run as the superuser and it can therefore write the new password to the etc/passwd file.

How to set the suid bit?
Use the number 4 in front of a normal chmod string:
#chmod 4755 /home/mahi/mahi.sh
Alternatively you can use symbolic notation to get the exact result
#chmod u+s /home/mahi/mahi.sh

To unset the setuid bit use
# chmod u-s /home/mahi/mahi.sh
or
#chmod 0755 /home/mahi/mahi.sh

To search for all files in the system that have setuid bit set on them , use find command
# find / -type f -perm -04000 -exec ls -lrt {} \;

setuid on directories
Setting uid on a directory is easy to understand as it is simply ignored by Linux. i.e you can set it but it is given no special meaning when set on a directory. On Linux The setuid bit on a directory is only effective when it is on the group bit.

2)Setgid bit (set group id bit )
we can set setgid bit on both file and directory.
2.1 setgid on a file
The setgid bit is set on executable files at  the group level. When this bit is enabled , the file will be executed by the other users  with exact same privileges  that the group member have on it. SGID modes on a file don't occur nearly as frequently as SUID.

For example the linux write and wall command is owned by root with group membership set to tty. These command has setgid bit enabled on it.See the highlighted “s” in the group permission class below
[root@node2 ~]# ls -lrt /usr/bin/wall
-r-xr-sr-x 1 root tty 10420 Oct 13  2006 /usr/bin/wall
The write and wall commands are used to send messages to other users' terminals (ttys) or to any psuedo terminal (pts/n). The write command writes a message to a single user, while wall writes to all connected users. For eg;

[root@node2 ~]# wall
Hi
h r u?
^d
Then it will send message to all connected users. Sending text to another user's terminal or graphical display is normally not allowed. In order to bypass this problem, a group has been created, which owns all terminal devices. When the write and wall commands are granted SGID permissions, the commands will run using the access rights as applicable to this group, tty in the example. Since this group has write access to the destination terminal, also a user having no permissions to use that terminal in any way can send messages to it.
From the following output you can see that  each terminal device (tty1 ,pts/0,pts/1 etc) is owned by the group tty . So when a normal user run the ‘wall’ or ‘write’ command it will run with the access rights of the group tty .From the output we can see that ‘tty’  group have  the write permission  on each  destination terminal. So we will get the output on each terminal

[root@node2 ~]# ls -lrt /dev/tty1
crw--w---- 1 root tty 4, 1 Jan 21 23:29 /dev/tty1

[root@node2 ~]# ls -lrt /dev/pts
crw--w---- 1 root tty 136, 0 Jan 21 23:19 0
crw--w---- 1 root tty 136, 1 Jan 21 23:29 1

You can also send message to any destination terminal by using ‘echo’ if you have enough permission, for eg
[root@node2 ~]# echo Hi dear > /dev/pts/1
Then it will display the message “Hi dear “ on the pseudo terminal  dev/pts/1 , now try to execute
The same command as a normal user 
[mahi@node2 ~]$ echo Hi dear > /dev/pts/1
-bash: /dev/pts/1: Permission denied
Ie local user have no write permission to the destination terminal , here the ‘setuid’ bit comes into play .

How to set setgid bit on files and directory
To set setgid bit you must be either be the owner of the file or root , you can use chmod command to set setgid on files and directories

#chmod 2755 /home/mahi/free.sh
Alternatively you can use symbolic notation to get the exact result

#chmod  g+s  /home/mahi/free.sh
To unset the setgid bit

# chmod  g-s  /home/mahi/free.sh
or
#chmod 0755 /home/mahi/free.sh
To search for all files and directories in the system having setgid bit enabled

# find / -type f -perm -02000 -exec ls -lrt {} \;   (for  directories use ‘d’ instead of ‘f’ )

2.2 Setgid bit on directories
We can use the command chmod to set the group ID bit for a directory.
#chmod g+s /mydir
or with numeric mode:
#chmod 2775 /mydir

After the change, the permission of the directory "/mydir" becomes "drwxrwsr-x".

drwxrwsr-x 3 ora ora 4096 2010-03-18 19:57 /mydir
But what is so special about setting the group ID for a directory? The trick is that when another user creates a file or directory under such a directory "/mydir", the new file or directory will have its group set as the group of the owner of "/mydir", instead of the group of the user who creates it.

For example, if mahi belongs to the groups "mahi" (main group) and "ora", and he creates a file "setgid.txt" under the diretory "/mydir", "setgid.txt" will be owned by the group of "ora" instead of  mahi's main group ID "mahi".

   -rw-r--r-- 1 mahi ora   10 2010-03-18 20:01 setgid.txt

Even if ‘mahi’ does not belong to the group "ora", the files or directories he creates under "/mydir" (if "/mydir" grants the write permission to "
others") will also get owned by group "ora".

You can use such feature to share files within the group. Create a directory which permits the group to write, and set the group ID bit. Every files or directories created under it will have the same group ownership. Therefore, the whole group can share them.
One commnad for finding all the files with setuid or setgid bit

#find / -perm  +6000 -type f -exec ls -lrt {} \;

3)sticky bit 
The sticky bit is normally set on public writable directories to protect files and sub-directories  of individual users from being  deleted  by other users. This bit is typically set on /tmp and /var/tmp directories. Thus If the sticky bit is set for a directory, only the owner of that directory or the owner of a file can delete or rename a file within that directory.
Normally all users are allowed to create and delete files and sub-directories in these directories.
With default permission, any user can remove any others files and sub-directories.
Sticky bit shows up as a t in the execute position of the other permission , foe eg

[root@server ~]# ls -ld /var/tmp/ /tmp
drwxrwxrwt 32 root root 4096 Mar 15 13:35 /tmp
drwxrwxrwt  2 root root 4096 Feb 20 10:35 /var/tmp/

How to set sticky bit permission
When digit 1 is used with chmod command it sets the sticky bit on the directory
#chmod  1777 test
Alternatively you can use symbolic notation to set the same
#chmod o+t  test
There is no need to specify  ‘o’ along with chmod command you can simply do it with
#chmod  +t  test 

How to unset sticky bit permission
 #chmod  -t  test
Or
#chmod 0777 test

Note:
You may see both a ‘t’ and ‘T’ to indicate that the sticky bit is set. You can see a ‘t’  if the world already have a execute permission before you set the sticky bit , and a ‘T’ if the world  didn’t have execute set before the sticky bit was put in place. For eg:
#mkdir  testdir
#chmod 754 testdir
#chmod  o+t  testdir
# ls -ld testdir
drwxr-xr-T 2 root root 4096 Mar 15 14:23 testdir

To list all directories having sticky bit enabled
#find / -perm  -1000 -type d

Note:
Linux ignores the sticky bit when it sets on files. It is possible to set combination of suid , sgid and the sticky bit at the same time . 

           0
   Remove sticky bit,suid &sgid 
           1
   Sets sticky bit
           2
   Sets sgid bit
           3
   Sets sticky bit and sgid bit
           4
   Sets suid bit
           5
   Sets sticky bit and suid 
           6
   Sets suid and sgid bit
           7
   Sets  sticky bit, suid &sgid bit

Be sure to note that using a 0 removes suid , sgid and sticky bit all at the same time . if you use 0 to remove suid but you still want the sticky bit set you need to go back and reset the sticky bit.





Wednesday, November 11, 2015

How to apply an interim patch in RAC database .

we can follow the following practice to apply an interim patch(one- off patch ) in RAC database .

1.Before applying  the interim patch in RAC nodes , first take the backup of ORACLE_HOME in each database nodes through tar command .
As root/oracle user take the backup of oracle home that we intend to patch 
#tar -cvzf /bkp_location/oracle_12.1.0.2.tar.gz  /u01/app/oracle/product/12.1.0.2/
 To appy patch we need to login as  oracle user 

2.If the patch is a rolling one ,we can apply the patch either through local mode or in rolling patch mode.
How to check the patch is a rolling one  ?

[oracle@pdc01]$ $ORACLE_HOME/OPatch/opatch query -is_rolling_patch /nfs1/BINARIES/DB_Patch/p20476175_121020_Linux-x86-64.zip
Oracle Interim Patch Installer version 12.1.0.1.8
Copyright (c) 2015, Oracle Corporation.  All rights reserved.
Oracle Home       : /u01/app/oracle/product/12.1.0.2/db_1
Central Inventory : /u01/app/aoraInventory
   from           : /u01/app/oracle/product/12.1.0.2/db_1/oraInst.loc
OPatch version    : 12.1.0.1.8
OUI version       : 12.1.0.2.0
Log file location : /u01/app/oracle/product/12.1.0.2/db_1/cfgtoollogs/opatch/opatch2015-11-12_11-32-12AM_1.log
--------------------------------------------------------------------------------
 Patch is a rolling patch: true
 Patch is a FMW rolling patch: false
OPatch succeeded.
[oracle@pdc01]$
Or you can test it by following method,

3.Unzip the patch and go to patch directory

[oracle@pdc01]$unzip /nfs1/BINARIES/DB_Patch/p20476175_121020_Linux-x86-64.zip
[oracle@pdc01 20476175]$ /u01/app/oracle/product/12.1.0.2/db_1/OPatch/opatch query -all | grep -i "Need to shutdown Oracle instances"
 Need to shutdown Oracle instances: true
[oracle@pdc01 20476175]$
[oracle@pdc01 20476175]$ /u01/app/oracle/product/12.1.0.2/db_1/OPatch/opatch query -all | grep -i "Patch is a rolling patch"
 Patch is a rolling patch: true
[oracle@pdc01 20476175]$

4.Shut down all the services running from the Oracle home of the database of Oracle Database home. - please see the readme file for more information.

5.Apply the interim patch (one-off patch )
choose one of the following method to apply interim patches in RAC environment.

5.1   -local
              Patch the local node, then update inventory of the
              local node. Do not propagate the patch or inventory
              update to other nodes.

[oracle@pdc01 20476175]$/u01/app/oracle/product/12.1.0.2/db_1/OPatch/opatch apply -local 

Repeat the steps in remaining nodes .
 
5.2 -all_nodes (Default)
            if you don't specify -local along with opatch apply  then opatch will  patch node 1 first , once it finish with node1 , opatch will list the remaining nodes to patch . At this point we can select the remaining nodes and opatch will continue patching with remaining nodes .

[oracle@pdc01 20476175]$/u01/app/oracle/product/12.1.0.2/db_1/OPatch/opatch apply


Sunday, May 24, 2015

Data Guard Configuration for RAC through RMAN active database duplication.
In this topic I am going to cover how we can  configure dataguard in a RAC enviorment .
The main advantage of setting up dataguard in 11g/12c is that the database can be opened in Read-Only mode allowing the Users to access the physical standby database for fetching reports and on the same time the physical standby database can be in recovery mode. In other words, the physical standby database would be in recovery mode and in hand the standby database can be used for reporting purposes.

Assumptions
I have two servers (physical or VMs) with an operating system and Oracle installed on them. In this case I've used Oracle Linux 5.6 and Oracle Database 12.1.0.2.
The primary server has a running instance (TDDWH1 & TDDWH2)
The standby server has a software only installation.

Here is my enviornment setup .I am going to make a standby database for my cluster database TDDWH .
pdnode1 - node 1 primary 
pdnode2 - node 2 primary 
stnode1 - node 1 standby -10.81.155.146
stnode2 - node 2 standby -10.81.155.147

Primary Server Setup

Enable Archivelog Mode
Check that the primary database is in archivelog mode.

SQL>SELECT log_mode FROM v$database;

LOG_MODE
------------
NOARCHIVELOG

SQL>

If it is noarchivelog mode, switch is to archivelog mode.

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.

SQL> startup mount
ORACLE instance started.

Total System Global Area 1241513984 bytes
Fixed Size                  1273420 bytes
Variable Size             318767540 bytes
Database Buffers          905969664 bytes
Redo Buffers               15503360 bytes
Database mounted.

SQL> alter database archivelog;

Database altered.

SQL> ALTER SYSTEM SET LOG_ARCHIVE_FORMAT='%t_%s_%r.arc' SCOPE=SPFILE;

Where %tthread number , %s log sequence number and %r resetlogs ID that ensures unique names are constructed for the archived log files across multiple incarnations of the database

SQL> alter database open;

Database altered.

SQL> archive log list
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     34
Next log sequence to archive   36
Current log sequence           36

Note:- 

Enabled forced logging by issuing the following command.
Any nologging operations performed on the primary database do not get fully logged within the redo stream. As Oracle Data Guard relies on the redo stream to maintain the standby database, this can result in data inconsistencies between the primary and standby along with a massive headache for the DBA to resolve. To prevent this from occurring, one solution is to place the primary database into force logging mode. In this mode, all nologging operations are permitted to run without error, however, the changes will be placed in the redo stream anyway.

SQL> ALTER DATABASE FORCE LOGGING;

To verify force logging is enabled for the database:


SQL> select force_logging from v$database;

FORCE_LOGGING
--------------
YES
Configure a Standby Redo Log
A Standby Redo log is added to enable Data Guard Maximum Availability and Maximum Protection modes. It is important to configure the Standby Redo Logs (SRL) with the same size/more than the size  of the online redo logs. Oracle recommented to create one more standby redo log file group than the number of online redo log file groups on the primary database. 


A best practice generally followed is to create the standby redo logs on both the primary and the standby database so as to make role transitions smoother. By creating the standby redo logs at this stage, it is assured that they will exist on both the primary and the newly created standby database. From the primary database, connect as SYS and run the following to create four standby redo log file groups:

SQL>select thread#, group# ,bytes/1024/1024 from v$log order by 1,2;
  THREAD#     GROUP# BYTES/1024/1024
---------- ---------- ---------------
         1          1              50
         1          2              50
         2          3             100
         2          4             100

Here thread 1 have two groups for each thread . So we need to create 3 standby redo log groups for thread 1 and 2.

Here thread 2 is configured with size 100MB , so we have to create standby redo logs of size 100 M for thread 2.

SQL> alter database add standby logfile thread 1 group 5 size 50M,group 6 size 50M,group 7  size 50M;

SQL> alter database add standby logfile thread 2 group 8 size 100M,group 9 size 100M,group 10 size 100M;

Check the standby redos by 

SQL> select GROUP#,TYPE from v$logfile ;
SQL> SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG;

Create a Password File
As part of the new redo transport security and authentication features, it is now mandatory that each database in an Oracle Data Guard configuration utilize a password file. In addition, the SYS password must be identical on every database in order for redo transport to function. If a password file does not exist for the primary database, create one using the following steps: create a new password file or copy the existing password file from node1 of primary and copy to the rest of the box.

[oracle@pdnode1]:[TDDWH1] $ scp orapwTDDWH1 pdnode2:/u01/app/oracle/product/12.1.0.2/db_1/dbs/orapwTDDWH2  -- node 2 of primary
[oracle@pdnode1]:[TDDWH1] $ scp orapwTDDWH1 10.81.155.146:/u01/app/oracle/product/12.1.0.2/db_1/dbs/orapwTGDWH1 -- node 1 of standby 
[oracle@pdnode1]:[TDDWH1] $ scp orapwTDDWH1 10.81.155.147:/u01/app/oracle/product/12.1.0.2/db_1/dbs/orapwTGDWH2 -- node 2 of standby 

After creating the password file, set the remote_login_passwordfile initialization parameter to EXCLUSIVE in the spfile on the primary database. Since this parameter cannot be dynamically modified for the current running instance, the change will have to be made to the spfile and bounced in order to take effect:

SQL> alter system set remote_login_passwordfile=exclusive scope=spfile;

System altered.

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.

SQL> startup;
ORACLE instance started.
Total System Global Area 1241513984 bytes
Fixed Size                  1273420 bytes
Variable Size             318767540 bytes
Database Buffers          905969664 bytes
Redo Buffers               15503360 bytes
Database mounted.

Database opened.

Note:- 
If you have implemented any kind of  encryption  in your primary database you need to copy  those wallet directory to the standby boxes .If you forgot to copy your wallet directory the  MRP process won't come up in standby side.

[oracle@pdnode1]:[TDOSB1] $ scp -r TDDWH1  10.81.155.146:/etc/ORACLE/WALLETS/
Go to 10.81.155.146 and rename /etc/ORACLE/WALLETS/TDDWH1 to TGDWH1
oracle@pdnode1]:[TDOSB1] $ scp -r TDDWH1  10.81.155.147:/etc/ORACLE/WALLETS/
Go to 10.81.155.146 and rename /etc/ORACLE/WALLETS/TDDWH1 to TGDWH2

Configure the Primary Database Initialization Parameters
The configuration examples use the names shown in the following table:
DatabaseDB_UNIQUE_NAMEOracle Net Service Name
PrimaryTDDWHTDDWH
Physical standbyTGDWHTGDWH
Check the setting for the DB_NAME and DB_UNIQUE_NAME parameters. In this case they are both set to "TDDWH" on the primary database.

SQL> show parameter db_name

NAME      TYPE  VALUE
------------------------------------ ----------- ------------------------------
db_name       string  TDDWH

SQL> show parameter db_unique_name

NAME      TYPE  VALUE
------------------------------------ ----------- ------------------------------
db_unique_name      string  TDDWH

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 "TGDWH".

Set Standby related parameters as follows ,
SQL> alter system set log_archive_dest_1='location=+ORADATA/TDDWH/ARCHIVELOG valid_for=(all_logfiles,all_roles) db_unique_name=TDDWH' sid='*' scope=both;

SQL> alter system set log_archive_dest_2='service=TGDWH NOAFFIRM LGWR ASYNC COMPRESSION=ENABLE VALID_FOR=(ALL_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=TGDWH' sid='*' scope=both;

 SQL>alter system set LOG_ARCHIVE_DEST_state_1=ENABLE sid='*' scope=both;
SQL>alter system set LOG_ARCHIVE_DEST_state_2=ENABLE sid='*' scope=both;

SQL>alter system set log_archive_config='DG_CONFIG=(TDDWH,TGDWH)' sid='*' scope=both;

Here TDDWH & TGDWH are db_unique_name for primary and standby (not oracle-net entry )

Set FAL_CLIENT and FAL_SERVER Parameters
Under certain circumstances, either because of network failures or a busy source environment, a gap builds up between the target sending the information and the destination receiving the changes and applying them. Since the MRP/LSP process has no direct communication link with the primary database to obtain a copy of the missing archive files, such gaps or archive gaps are resolved by the fetch archive log (FAL) client and server,identified by the initialization parameters FAL_CLIENT and FAL_SERVER.

FAL_SERVER specifies the FAL (fetch archive log) server for a standby database.The value is an Oracle Net service name, which is assumed to be configured properly on the standby database system to point to the desired FAL server.

FAL_CLIENT specifies the FAL (fetch archive log) client name that is used by the FAL service, configured through the FAL_SERVER parameter, to refer to the FAL client. The value is an Oracle Net service name, which is assumed to be configured properly on the FAL server system to point to the FAL client (standby database). Given the dependency of FAL_CLIENT on FAL_SERVER, the two parameters should be configured or changed at the same time.

FAL_CLIENT and FAL_SERVER are initialization parameters used to configure log gap detection and resolution at the standby database side of a physical database configuration. This functionality is provided by log apply services and is used by the physical standby database to manage the detection and resolution of archived redo logs.


FAL_CLIENT and FAL_SERVER only need to be defined in the initialization parameter file for the standby database(s). It is possible; however, to define these two parameters in the initialization parameter for the primary database server to ease the amount of work that would need to be performed if the primary database were required to transition its role.

Create oracle-net entry for TGDWH and also for TDDWH  on both nodes

SQL> alter system set fal_client='TDDWH' sid='*' scope=both;

SQL> alter system set fal_server='TGDWH' sid='*' scope=both;

Make sure tns entry for both TDDWH and TGDWH are present in all 4 boxes ie, you should able to tnsping TDDWH and TGDWH from all 4 boxes

The initialization parameter, STANDBY_FILE_MANAGEMENT, enables you to control whether or not adding a datafile to the primary database is automatically propagated to the standby database, as follows:

SQL>ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;

Duplicating stanby databsae from active database 

Make an entry UR=A for the auxiliary instance both in standby and primary ,otherwise make a static listener entry for the standby database 

From node 1 of standby

[oracle@stnode1]:[TGDWH1] $ tnsping TGDWH

TNS Ping Utility for Linux: Version 12.1.0.2.0 - Production on 28-APR-2015 17:40:53

Copyright (c) 1997, 2014, Oracle.  All rights reserved.

Used parameter files:
/u01/app/oracle/product/12.1.0.2/db_1/network/admin/sqlnet.ora
Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = ptgracscan)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = TGDWH)(UR=A)))
OK (0 msec)
[oracle@stnode1]:[TGDWH1] $

From node 1 of primary

[oracle@pdnode1]:[TDDWH1] $ tnsping TGDWH

TNS Ping Utility for Linux: Version 12.1.0.2.0 - Production on 28-APR-2015 17:41:40

Copyright (c) 1997, 2014, Oracle.  All rights reserved.

Used parameter files:
/u01/app/oracle/product/12.1.0.2/db_1/network/admin/sqlnet.ora
Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 10.81.155.146)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = TGDWH)(UR=A)))
OK (0 msec)
[oracle@pdnode1]:[TDDWH1] $

Make a proper initTGDWH1.ora and put it in the dbs directory of 10.81.155.146
the important perameter to consider 
*.db_unique_name='TGDWH'
*.db_name='TDDWH'
*.compatible='same as that of primary'
*.cluster_database=FALSE
*.db_create_file_dest='+ORADATA'
*.db_recovery_file_dest='+ORAFRA'
*.db_recovery_file_dest_size=4000M
*.control_files='+ORADATA/tgdwh/controlfile/stanby_control1.ctl','+ORAFRA/tgdwh/controlfile/standby_control2.ctl'
*.fal_server='TDDWH'
*.fal_client='TGDWH'
*.log_archive_config='DG_CONFIG=(TDDWH, TGDWH)'
*.log_archive_dest_1='location=use_db_recovery_file_dest valid_for=(all_logfiles,all_roles) db_unique_name=TGDWH'
*.log_archive_dest_2='service=TDDWH NOAFFIRM LGWR ASYNC COMPRESSION=ENABLE valid_for=(ONLINE_LOGFILE,PRIMARY_ROLE) db_unique_name=TDDWH'
*.log_archive_dest_state_2='defer'
*.STANDBY_FILE_MANAGEMENT=AUTO

Note:- if you are using use_db_recovery_file_dest , you have to define db_recovery_file_dest . You don't have to worry about other parameter like adump , as oracle will automatically create while doing duplicaste

SQL>startup noumount pfile='initTGDWH1.ora';
 



====> duplicate the standby database by 
[oracle@stnode1]:[TGDWH1] $rman TARGET sys/Orcl1234@TDDWH AUXILIARY sys/Orcl1234@TGDWH
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;
}

Once duplicate database finished its woks , start redo apply by

SQL> alter database recover managed standby database using current logfile disconnect from session;
SQL> select  thread#, sequence# ,name,applied from v$archived_log order by sequence#

SQL> select process,status,sequence#,block#,blocks from v$managed_standby;

---- if rfs is not coming check LOG_ARCHIVE_DEST_state_2 is set to enable or not in primary.

Once mrp process start applying the redo records  check error from primary 

set linesize 500
col DESTINATION for a30
SELECT inst_id,DEST_ID , STATUS ,DESTINATION , ERROR FROM gV$ARCHIVE_DEST WHERE DEST_ID <4 order by 1,2;

Adding instances to cluster 
Once mrp start applying archives , we can configure the new database to cluster,

[oracle@stnode1]:[TGHTB1] $ sqlplus / as sysdba

SQL*Plus: Release 12.1.0.2.0 Production on Wed Apr 29 18:22:36 2015

Copyright (c) 1982, 2014, Oracle.  All rights reserved.

Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, Oracle Label Security,
OLAP, Advanced Analytics, Oracle Database Vault and Real Application Testing options

SQL> shut immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> 
SQL> exit
Disconnected from Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, Oracle Label Security,
OLAP, Advanced Analytics, Oracle Database Vault and Real Application Testing options
[oracle@stnode1]:[TGHTB1] $
[oracle@stnode1]:[TGHTB1] $ vi initTGHTB1.ora
[oracle@stnode1]:[TGHTB1] $ here I made changes cluster_database='TRUE'
[oracle@stnode1]:[TGHTB1] $ sqlplus / as sysdba

SQL*Plus: Release 12.1.0.2.0 Production on Wed Apr 29 18:26:33 2015

Copyright (c) 1982, 2014, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> startup  nomount;
ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance
ORACLE instance started.

Total System Global Area 1610612736 bytes
Fixed Size                  2924928 bytes
Variable Size             989859456 bytes
Database Buffers          603979776 bytes
Redo Buffers               13848576 bytes
SQL>
SQL> create spfile='+ORAFRA' from pfile;

File created.

------------------------> note down the location of spfile created .
SQL> shut immediate;
ORA-01507: database not mounted
ORACLE instance shut down.
SQL> exit
Disconnected from Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP, Advanced Analytics
and Real Application Testing options
[oracle@stnode1]:[TGHTB1] $ cp initTGHTB1.ora initTGHTB1.ora_old
[oracle@stnode1]:[TGHTB1] $ vi initTGHTB1.ora
[oracle@stnode1]:[TGHTB1] $ here I added spfile='+ORAFRA/TGHTB/PARAMETERFILE/spfile.11344.878322445'
[oracle@stnode1]:[TGHTB1] $ pwd
/u01/app/oracle/product/12.1.0.2/db_1/dbs
[oracle@stnode1]:[TGHTB1] $ scp initTGHTB1.ora stnode2:/u01/app/oracle/product/12.1.0.2/db_1/dbs/initTGHTB2.ora
initTGHTB1.ora                                                                                                             100%   60     0.1KB/s   00:00
[oracle@stnode1]:[TGHTB1] $
[oracle@stnode1]:[TGHTB1] $ cat /etc/oratab | grep TGHTB1
TGHTB1:/u01/app/oracle/product/12.1.0.2/db_1:N          # line added by Agent
[oracle@stnode1]:[TGHTB1] $ srvctl add database -d TGHTB -o /u01/app/oracle/product/12.1.0.2/db_1
[oracle@stnode1]:[TGHTB1] $ srvctl add instance -d TGHTB -i TGHTB1 -n stnode1
[oracle@stnode1]:[TGHTB1] $ srvctl add instance -d TGHTB -i TGHTB2 -n stnode2
[oracle@stnode1]:[TGHTB1] $ srvctl status database -d TGHTB
Instance TGHTB1 is not running on node stnode1
Instance TGHTB2 is not running on node stnode2
[oracle@stnode1]:[TGHTB1] $ srvctl start database -d TGHTB
[oracle@stnode1]:[TGHTB1] $ srvctl status database -d TGHTB
Instance TGHTB1 is running on node stnode1
Instance TGHTB2 is running on node stnode2
[oracle@stnode1]:[TGHTB1] $