You can refer to http://www.linkedin.com/groups/How-will-you-convert-single-3156190.S.5875270675291217921?view=&item=5875270675291217921&type=member&gid=3156190&trk=eml-b2_anet_digest-null-2-null&fromEmail=fromEmail&ut=22vczqI8fclmg1  for detailed information.


a. using dbca 
b. using EM 
c. using rconfig utility

1. Manually
1. DBCA
1. RCONFIG.==========> Its the very easy method to convert single instance to RAC.

Steps.
1. Install GI on both nodes.
1. Install RDBMS software on both nodes.
1. You need to changes the configuration according your setting in $ORACLE_HOME/assistants/rconfig/sampleXMLs files.
Please refer the below link.
http://chotustuff.wordpress.com/2012/08/31/convert-single-instance-11gr2-database-to-11gr2-rac-using-rconfig/



We have converted most of our critical system from “Single Instance” to “RAC”. We are extremely happy with RAC, as we can scale our business and get the highest availability. But it was not a straight forward journey. We have tuned lots of thing to make it perfect for our own business. It was a great journey working with RAC team of Oracle. 


I am sharing most of our own best practices, which may not be applicable to all of you, but this helps to run our largest OLTP systems. 
We are using 4 kinds of OLTP systems. All the tips here, based on our OLTP use cases. 
1. Pure RAC, not a partitioned application: It works great, LMS overhead is there, which is expected. But no single node configuration can handle this OLTP system, which we are running with 4 nodes RAC. 
2. Using RAC with partitioned application, where SLA is most critical. Combination of RAC and sharded application helps us to get all advantage for availability and our business SLA. 
3. Using RAC, where write mostly users are connecting in a particular node and other nodes are using for READ Mostly users. All we achieve by using RAC Service. 
4. Active/Passive use of RAC: Requirement is N+1 availability. Here one is surviving the business and another node is ready for failover or rolling patching. 




Network => This is one of the most critical hardware component for RAC. 
Linux: RDS over IB with Active/Passive configuration, when we have 2 IB channel in the configuration.. 
Solaris: RDS over IB with IPMP (Active/Passive) configuration. 
AIX: All version of Oracle does not support RDS over IB. Either use the Oracle version which supports RDS over IB or use UDP over 10GigE channel. 
One of our largest OLTP system, we are actual using 4X10GigE network with UDP. 


Storage => Must be shared between all nodes in the cluster with bigger I/O channel. Multiple channel (4 channel will be great for very large OLTP environment). Speed of the channel matters. 
Depend on your business needs; you can pick the speed of the channel. 


CRS setup -> We Prefer to Disable CRS from auto start, Auto start will help to join the node in the cluster automatically, but it will involve in RAC reconfiguration, 
This will prolong the outage for any failure at pick hours. Otherwise auto enable is cool thing to use. 


SERVICES => Based on application, services need to configure correctly. 
You can create and use the service such a way, which can meets your following requirement and as a best practice, use service to access DB also, especially in RAC. 


We use services for the following purposes. 
1. Read mostly service 
2. Write service 
3. Active/Passive service 
4. Active/Active service 
5. Shared service 
6. RO service 
7. Maintenance Job service 


ASM Parameters=> In our large system (50+ TB DB Size), we prefer to set our own parameters, which is helping us to avoid ORA-20 error and ORA-4031 for any future requirement. 
Parameters are like: 
Processes =1000 
large_pool_size= 512M 
shared_pool_size = 1G 


ASM DG => We are using mostly with 4MB AU size. 


Oracle Binary => Make sure the binary compiled with correct protocol. “skgxpinfo” will display the protocol information. While running the syntax skgxpinfo for ASM, make sure the environment set correctly. Sometime I ran this as root with the full patch of skgxpinfo for each home, and it always return me the correct value for each environment, as root user does not have any environment setting for CRS or DB home




DATABASE RAC Parameters => For our heavy OLTP system, "Dynamic Remastering (DRM)" was never been a blessing. So we have disabled DRM. It is 100% depends case by case. You may work with Oraccle to find the correct setting for your case. 


Disable DRM (Dynamic Remastering) 
_gc_policy_time=0 


Better RAC traffic flow across interconnect, we use more number of LMS processes. This is something, which you need to test and decide. 
gcs_server_processes=  
More LMS processes will provide better RAC performance, but you need latest PSU to have the greatest code. 


Set the following process in RT mode for Linux and AIX, this one was always beneficial for us, as we run single DB one each cluster, and we have lots of CPUs in the system. But, if you have too many instances on each node, you will not able to run all those process in RT mode for all instances. So, better testing and discussion with Oracle can help you to pick the best for you. 
_high_priority_processes=LMS*|VKTM|LMD*|LGWR //For Solaris, the latest PSU has the fix, which will automatically change the priority of those processes in RT mode. 
Improve the messaging parameters: 
parallel_execution_message_size= 32768 
db_file_multiblock_read_count=128 


As we have complete control on our application and every millisecond response time matters to us, we have sized most of the SGA parameter optimally and decided not to use auto tune, as it has some overhead when it will shuffle memory. The following setting may not be applicable for all. 
Disable all automated advices 
_library_cache_advice =FALSE 
_memory_imm_mode_without_autosga =FALSE 
_disable_system_state =0 // Takes too much time and resources to dump 250+ GB SGA, can eat all the file system space too // 
_enable_automatic_sqltune=FALSE // We prefer the plan with our own choice // 
_addm_auto_enable=FALSE 
_undo_autotune=FALSE 
sga_target=0 
sga_max_size=0 
resource_manager_plan='FORCE:' 
_clusterwide_global_transactions=FALSE 
db_cache_advice='off' 




Reduce cross instance traffic, by stopping cross node PQ slaves, we are still using 2 deprecated parameters. Though it will tell the parameters deprecated, but actually not. 


instance_groups = //Different value for each instance, as we do not want PQ accross the instance for our OLTP system, this requirement may not be true for all OLTP system // 
parallel_instance_group = //Different value for each instance, as we do not want PQ across the instance for our OLTP system , this requirement may not be true for all OLTP system // 


db_writer_processes=4 // Heavy OLTP system, where we have faster storage // 




_rollback_segment_count= //This is one of the most critical setting, for connection failover. This will avoid US enqueue contention for heavy OLTP system, the value // 
_mutex_wait_time=10 




use_large_pages=TRUE //Almost 40% of physical memory and it is using huge pages, Without huge page, we see performance degradation on CPU usage.// 


TABLESPACE => Like both MSSM tablespace and ASSM tablespaces. 


TABLE/INDEX => With MSSM, we use FREELIST GROUPS 17 and FREELISTS with 23 and the fix of bug "12655992: WE SEE LOTS OF FREELISTGROUP UNUSED", helped us to use all Freelist Groups. 


LOB => Configured with cache in_row and "freelists 23 " 


SEQUENCES=> 100 times of cache value with NOORDER compare to its every second usage. This setting will help to avoid the contention on "DFS lock handle" 


DDL => Truncate and drop table is an expensive operation, which we have replaced with exchange partition. 


Avoid brownout=> Reduce to frequent access by application with query on GV$VIEW


MAINTENANCE 
PATCHING => Another biggest motivation to use RAC, is rolling patching. We are using 100% rolling patching. 


We follow the following processes for our maintenance: 
Before patching a node, move services and connections from that node. 
Shrink buffercache to reduce to reduce RAC Locks. 
STOP DB for patching. 
Using our homegrown automated patching scripts, which is helping us to patch a node in less than 10 minutes. Working with Oracle as an Enhancement Request.