RAC setup can be tricky sometimes, In this article and upcoming articles, we are going to discuss the steps to setup up RAC 12c two node in the simple and easy way.

In this article, I will gather the high-level steps that would be required for RAC setup.

High Level Design:














IP's that I would be using:

#Public IP for 2 nodes#
192.168.56.123   racdb-scan


Steps:

1. Create a DNS server.(Check the post on how to configure it).

2. Create a Virtual Machine Racnode1 

The configuration of RAC Node 1

• Hard Disk: 60GB
• Ram: 4 GB
• OS: Oracle Enterprise Linux 6.4
• 2 network adapter eth1 and eth2 for Public and Private IP's.
• Make the IP's Static
• Install required RPM's or Oracle 12c
• Create Users and Groups. We will use a separate user for GRID and ORACLE. 

• All configuration as racnode1 will be preserved.
• Change IP address for eth1 and eth2.
• Change hostname to Racnode2

In this post, we are going to understand various groups and users that should be created when Configuring Oracle GRID and Oracle Database with different users.

Create separate users for the Grid Home(gi_home) and Oracle Database Home (db_home) binaries

• The gi_home user (ex: grid) has as its Primary Group the 'oinstall' group.Other essential OS groups assigned to it are: asmadmin (OSASM) and asmdba (OSDBA).Can also be part of the asmoper (OSOPER) group, but is not mandatory.           Example: uid=501(grid) gid=501(oinstall) groups=501(oinstall),502(dba),504(asmadmin),506(asmdba),507(asmoper)

• The db_home user (ex: oracle) has as its Primary Group the 'oinstall' group also. Other essential OS groups assigned to it are: asmdba (OSDBA) and dba (OSDBA for the database). Can also be part of the oper (OSOPER) group, but is not mandatory.   Example: uid=502(oracle) gid=501(oinstall) groups=502(dba),506(asmdba)

• The Oracle binary for the gi_home (gi_home/bin/oracle) must be owned by the gi_home software owner and be part of the 'oinstall' OS group. Also its permissions should be 6751 (-rwsr-s--x)

   Example:  -rwsr-s--x   1 grid     oinstall 220419496 Apr 14 15:22 /grid/app/11.2.0.3/grid/bin/oracle

• The Oracle binary for the db_home (db_home/bin/oracle) must be owned by the db_home software owner and be part of the 'asmadmin' (OSASM) OS group. 

   Also its permissions should be 6751 (-rwsr-s--x)
   Example:  -rwsr-s--x   1 oracle   asmadmin 249144896 Apr 17 14:11 /orahome/app/oracle/11.2.0.3/db_1/bin/oracle

• The ASM disks must be owned by the gi_home software owner and be part of the 'asmadmin' OS group. 

   Also their permissions must be 660 (rw-rw----)

If all the concurrent request submitted are going to inactive no manager state. This is observed when all managers are up and running and free to run any requests.

This could be caused due to someone Created Include Specialization Rule for Standard Manager.

Note: No Include rule should be set for Standard Manager

Steps to Fix:

1. Log into Applications.
2. Navigate: System Administrator / Concurrent / Manager / Define.
3. Query for 'Standard'.
4. Click Specialization Rules.
5. Remove any Include Rules from the Specialization Rules for Standard Manager.
6. Restart the Managers to test.

In Oracle Apps R12.2 whenever we are changing apps password we need to update the new value in EBSDatasource in Weblogic.

We can either update the same by going into weblogic console and updating it or we can update it through server using below method.


Steps:

1. Start AdminServer 

$ADMIN_SCRIPTS_HOME/adadminsrvctl.sh start 

Note: Do not start any other application tier services.

2. Change the APPS password in WLS Data Source by running the the following script:

perl $FND_TOP/patch/115/bin/txkManageDBConnectionPool.pl

When prompted, select 'updateDSPassword' to update the new APPS password in the WLS Datasource.

In case we want to abort the patching cycle due to some issues or failures and restart adop session again, Then we should perform below steps


adop phase=abort

After running abort phase, we must run a full cleanup.


adop phase=cleanup cleanup_mode=full

adop phase=fs_clone

and then restart patching cycle again.

adop phase=prepare

If an adop session is running and system crashes then it fails to update the status in the internal repository

If we try to run it adop again it will give the following error.

Error:
Error:Unable to continue as already another user is using adzdoptl.pl.
Previous session exist, cannot continue as per user input.

Solution:
We need to manually update the internal adop repository table for the latest session and making it  status to completed.

Run the following statement to find out the session that is in running state:

SQL>select adop_session_id from ad_adop_sessions where status='R';

Set the status to 'C' (Completed) for that session, to re-execute the phase that was interrupted/terminated.

SQL>update ad_adop_sessions set status='C' where status='R';