Skip to main content

Search This Blog

Binoy Kumar

How to Change the public IP Address in an Oracle RAC

Get link
Facebook
Twitter
Pinterest
Email
Other Apps

Though this task is well documented there are still some pitfalls and quirks that can cause problems. Such as..

Should a particular task be done with the root or oracle user? Should it be performed on both nodes?

This is a step-by-step description how to perform the change of the public IP address in the Oracle two node RAC. The Oracle version is 10.2.0.3. The OS used in this example is Linux Centos 2.6.9-42.ELsmp

Note that due to the change of the private IP address the virtual IP address (VIP) may be required to change as well as it must remain in the same subnet as the public IP address.

The configuration

	Host	Current IP Address	Changed IP Address
Private IP	hst1	192.168.1.101	192.168.2.121
Private IP	hst2	192.168.1.100	192.168.2.120
VIP	hst1-vip	192.168.1.111	192.168.2.111
VIP	hst2-vip	192.168.1.110	192.168.2.110

Note that the actual value of IP addresses and host names was changed.

The basic steps

The change of the private IP address is performed in the following basic steps

1) Shut down everything except the CRS stack

2) Change the public interface

3) Modify the VIP address

4) Shut down CRS

5) Modify IP address on OS level and reconfigure /etc/hosts, listener,..

6) Restart

The order of the steps is very important. E.g. step 3) can be performed only if the CRS stack is up. If you perform step 5) prematurely, CRS will go down automatically (probably trying some reboots beforehand). This will effectively block step 3) to be done.

Shut Down Everything Except the CRS Stack

The database and nodeapps (on all nodes) are stopped.

[oracle@hst1 ~]$ srvctl stop database -d mydb

[oracle@hst1 ~]$ srvctl stop nodeapps -n hst1

[oracle@hst1 ~]$ srvctl stop nodeapps -n hst2

Note that if you use ASM, it must be stopped as well.

After that we verify the status.

[oracle@hst1 ~]$ srvctl status database -d mydb

Instance MYDB1 is not running on node hst2

Instance MYDB2 is not running on node hst1

[oracle@hst1 ~]$ srvctl status nodeapps -n hst1

VIP is not running on node: hst1

GSD is not running on node: hst1

Listener is not running on node: hst1

ONS daemon is not running on node: hst1

[oracle@hst1 ~]$ srvctl status nodeapps -n hst2

VIP is not running on node: hst2

GSD is not running on node: hst2

Listener is not running on node: hst2

ONS daemon is not running on node: hst2

Everything is OK, we can go to the next step.

Change the Public Interface

First let us have a look on the actual status

[oracle@hst1 ~]$ oifcfg getif

eth0 192.168.1.0 global public

eth1 192.168.2.0 global cluster_interconnect

We need to change the interface eth0.

As there is no modify command, we will delete and redefine the interface.

[oraclu@hst1 ~]$ oifcfg delif -global eth0

[oraclu@hst1 ~]$ oifcfg setif -global eth0/192.168.2.0:public

the exact syntax of the setif command can be found in [3]

Note that the CRS installation user (here oraclu) must be used for this operation. Otherwise an error message is issued:

PROC-5: User does not have permission to perform a cluster registry operation on

this key. Authentication error [User [oraclu] does not match with initialized u

PRIF-11: cluster registry error

Finally, we check if the action was done successfully

[oracle@hst1 ~]$ oifcfg getif

eth0 192.168.2.0 global public

eth1 192.168.2.0 global cluster_interconnect

Modify the VIP Address

As already mentioned, due to the fact that we changed the subnet of the public IP address, we must change the VIP address as well.

The following modify statement should be used.

[root@hst1 ~]# /appl/oracle/product/10.2.0/db_1/bin/srvctl modify nodeapps -n hst2 -A 192.168.2.110/255.255.255.0/eth0

[root@hst1 ~]# /appl/oracle/product/10.2.0/db_1/bin/srvctl modify nodeapps -n hst1 -A 192.168.2.111/255.255.255.0/eth0

Note that the root user should be used for this action.

The variable ORACLE_HOHE must be initialised.

Otherwise one of the following errors will be raised.

PRKO-2117 : This command should be executed as the system privilege user.

****ORACLE_HOME environment variable not set!

ORACLE_HOME should be set to the main

directory that contains Oracle products.

Set and export ORACLE_HOME, then re-run.

Shut Down CRS

The stop command must be performed on all nodes:

crsctl stop crs

Modify the IP Address on OS Level

Modify the public IP address (eth0). In Centos with application / system setting / network

Perform the change on all nodes.

Modify /etc/hosts and listener.ora files if required.

Reboot all nodes and verify the status.

Shortly after reboot we can see...

[oracle@hst2 ~]$ /sbin/ifconfig -a | egrep '(eth|Mask)'

eth0 Link encap:Ethernet HWaddr CA:FE:CA:FE:CA:FE

inet addr:192.168.2.120 Bcast:192.168.2.255 Mask:255.255.255.0

eth0:1 Link encap:Ethernet HWaddr CA:FE:CA:FE:CA:FE

inet addr:192.168.2.111 Bcast:192.168.2.255 Mask:255.255.255.0

eth0:2 Link encap:Ethernet HWaddr CA:FE:CA:FE:CA:FE

inet addr:192.168.2.110 Bcast:192.168.2.255 Mask:255.255.255.0

eth1 Link encap:Ethernet HWaddr CA:FE:CA:FE:CA:F1

inet addr:192.168.2.100 Bcast:192.168.2.255 Mask:255.255.255.0

inet addr:127.0.0.1 Mask:255.0.0.0

This means both VIP's eth0:1 and eth0:2 are switched to one host. This is not good, normally this appears if one host is down and the second host takes over the VIP.

Fortunately, after a few seconds we see..

[oracle@hst2 ~]$ /sbin/ifconfig -a | egrep '(eth|Mask)'

eth0 Link encap:Ethernet HWaddr CA:FE:CA:FE:CA:FE

inet addr:192.168.2.120 Bcast:192.168.2.255 Mask:255.255.255.0

eth0:2 Link encap:Ethernet HWaddr CA:FE:CA:FE:CA:FE

inet addr:192.168.2.110 Bcast:192.168.2.255 Mask:255.255.255.0

eth1 Link encap:Ethernet HWaddr CA:FE:CA:FE:CA:F1

inet addr:192.168.2.100 Bcast:192.168.2.255 Mask:255.255.255.0

inet addr:127.0.0.1 Mask:255.0.0.0

[oracle@hst1 ~]$ /sbin/ifconfig -a | egrep '(eth|Mask)'

eth0 Link encap:Ethernet HWaddr CA:FE:CA:FE:CA:F2

inet addr:192.168.2.121 Bcast:192.168.2.255 Mask:255.255.255.0

eth0:1 Link encap:Ethernet HWaddr CA:FE:CA:FE:CA:F2

inet addr:192.168.2.111 Bcast:192.168.2.255 Mask:255.255.255.0

eth1 Link encap:Ethernet HWaddr CA:FE:CA:FE:CA:F3

inet addr:192.168.2.101 Bcast:192.168.2.255 Mask:255.255.255.0

inet addr:127.0.0.1 Mask:255.0.0.0

I.e. the VIP's are distributed correctly.

The configuration of IP addresses is as required.

Let's have a final look at the status of the RAC.

[oracle@hst1 ~]$ srvctl status database -d mydb

Instance MYDB1 is running on node hst2

Instance MYDB2 is running on node hst1

[oracle@hst1 ~]$ srvctl status nodeapps -n hst1

VIP is running on node: hst1

GSD is running on node: hst1

Listener is running on node: hst1

ONS daemon is running on node: hst1

[oracle@hst2 ~]$ srvctl status database -d mydb

Instance MYDB1 is running on node hst2

Instance MYDB2 is running on node hst1

[oracle@hst2 ~]$ srvctl status nodeapps -n hst1

VIP is running on node: hst1

GSD is running on node: hst1

Listener is running on node: hst1

ONS daemon is running on node: hst1

[root@hst1 ~]# /appl/oraclu/product/10.2.0/crs/bin/crs_stat -t

Name Type Target State Host

------------------------------------------------------------

ora....B1.inst application ONLINE ONLINE hst2

ora....B2.inst application ONLINE ONLINE hst1

ora....DB1.srv application ONLINE ONLINE hst2

ora....DB2.srv application ONLINE ONLINE hst1

ora....BTAF.cs application ONLINE ONLINE hst2

ora.MYDB.db application ONLINE ONLINE hst2

ora....B2.lsnr application ONLINE ONLINE hst2

ora.hst2.gsd application ONLINE ONLINE hst2

ora.hst2.ons application ONLINE ONLINE hst2

ora.hst2.vip application ONLINE ONLINE hst2

ora....B1.lsnr application ONLINE ONLINE hst1

ora.hst1.gsd application ONLINE ONLINE hst1

ora.hst1.ons application ONLINE ONLINE hst1

ora.hst1.vip application ONLINE ONLINE hst1

Everything is up. We are ready!

[1] http://forums.oracle.com/forums/thread.jspa?messageID=2161448

[2] Metalink Note:276434.1

https://metalink.oracle.com/metalink/plsql/showdoc?db=NOT&id=276434.1&blackframe=1

[3] Metalink Note:283684.1

https://metalink.oracle.com/metalink/plsql/showdoc?db=NOT&id=283684.1&blackframe=1

(Account is required for Metalink access)

Get link
Facebook
Twitter
Pinterest
Email
Other Apps

Comments

Post a Comment

Popular posts from this blog

PRKH-1010 : Unable to communicate with CRS services

OS : AIX 5L Oracle 10g RAC Error message on one of the nodes PRKH - 1010 : Unable to communicate with CRS services I faced a typical issue. The localconfig command has been used for a single instance RDBMS. There is absolutely no requirement to run localconfig on RAC system and it should never be used on RAC system as it will destroy the CRS configuration When the localconfig reset was run on only one system the following things happened. Ocr.loc was created at /etc/oracle/ora.loc. Cat /etc/oracle/ocr.loc is like : Ocrconfig_loc=<$ORACLE_HOME>/cdata/localhost/local.ocr Local_only=true Cat /etc/inittab is like H1:35:respaw:/etc/init.d/init.evmd run >/dev/null 2>&1</dev/null H3:35:respawn:/etc/init.d/init.crsd run >/dev/null 2>&2 </dev/null H1:35:respawn:/etcc/init.d/init.dcssd run >/dev/null 2>&1 </dev/null<<< this one As root Run the following scripts $ORA_CRS_HOME/install/rootdelete.sh $ORA_CRS_HOME/install/rootdeinstall

vi Commands

January 26, 2012

What is vi? The default editor that comes with the UNIX operating system is called vi (visual editor). The UNIX vi editor is a full screen editor and has two modes of operation: Command mode commands which cause action to be taken on the file, and Insert mode in which entered text is inserted into the file. In the command mode, every character typed is a command that does something to the text file being edited; a character typed in the command mode may even cause the vi editor to enter the insert mode. In the insert mode, every character typed is added to the text in the file; pressing the (Escape) key turns off the Insert mode. While there are a number of vi commands, just a handful of these is usually sufficient for beginning vi users. To assist such users, this Web page contains a sampling of basic vi commands. The most basic and useful commands are marked with an asterisk (* or star) in the tables below. With practice, these commands should become automatic. NO

Determining if an Oracle Software Owner User Exists

Determining if an Oracle Software Owner User Exists To determine whether an Oracle software owner user named oracle exists, enter the following command: # id oracle If the oracle user exists, then the output from this command is similar to the following: uid=440(oracle) gid=200(oinstall) groups=201(dba),202(oper)

Powered by Blogger

Theme images by Veronica Olson

Binoy Kumar B

Archive

2012 1
- January 1

2011 7
- April 7
2010 23
2009 1
- June 1

Show more Show less

Report Abuse