How To Modify RAC SCAN Listener Port

Hi,

For some security reasons, you may want to change RAC scan listener port number.

As grid user:

Modify SCAN listener port

$GRID_HOME/bin/srvctl modify scan_listener -p <new_scan_port>

Please don’t forget to update database init.ora/spfile parameter file as:

alter system set remote_listener='<scan_name>:<new_port_number>’ scope=both sid=’*’;

Restart SCAN listener so the new port will be effect

$GRID_HOME/bin/srvctl stop scan_listener
$GRID_HOME/bin/srvctl start scan_listener

Confirm it

$GRID_HOME/bin/srvctl config scan_listener

Changing Public Network Interface, Subnet or Netmask in Oracle Clusterware

Hi,

If the Public Network interface change involves different subnet(netmask) or interface, delete the existing interface information from OCR and add it back with the correct information is required.  In the example here, the subnet is changed from 10.2.156.0  to 10.2.166.0

% $GRID_HOME/bin/oifcfg delif -global eth0/10.2.156.0
% $GRID_HOME/bin/oifcfg setif -global eth0/10.2.166.0:public

Then make the change at OS layer. There is no requirement to restart Oracle clusterware unless OS change requires a node reboot. This can be done in rolling fashion.

Once public network is changed, its associated VIP and SCAN VIP are also required to change.

Please ensure that public network changes are made first. If there is a node reboot or Clusterware restart after the OS network change, vip will not start.

Gather Current VIP Configuration

as Grid Infrastructure owner:

$ srvctl config nodeapps -a

Verify VIP status. It should show VIPs are ONLINE

$ crsctl stat res -t

$ ifconfig -a

– VIP logical interface is bound to the public network interface

Stopping Resources

Stop the nodeapps resources (and all dependent resources ASM/DB only if required):

as Grid Infrastructure owner:

$ srvctl stop instance -d ORCDB -n orcnode1
$ srvctl stop vip -n orcnode1 -f

Verify VIP is now OFFLINE and the interface is no longer bound to the public network

Modifying VIP and Its Associated Attributes

Determine the new VIP IP/subnet/netmask or VIP hostname, make the network change on OS first, ensure the new VIP is registered in DNS or modified in /etc/hosts . If the network interface is changed, ensure the new interface is available on the server before proceeding with the modification.

For example:
New VIP is: 10.2.166.21 orcnode1-nvip
new subnet is 10.2.166.0
new netmask is 255.255.255.0
new interface is eth2

Modify the VIP resource, as root user:

$ srvctl modify nodeapps -n orcnode1 -A orcnode1-nvip/255.255.255.0/eth2

Verify the change

$ srvctl config nodeapps -n orcnode1 -a
VIP exists.: /orcnode1-nvip/10.2.166.21/255.255.255.0/eth2

Start the nodeapps and the other resources

as Grid Infrastructure owner:

$ srvctl start vip -n orcnode1
$ srvctl start listener -n orcnode1
$ srvctl start instance -d ORCDB -n orcnode1

Verify the new VIP is ONLINE and bind to the public network interface

$ crsctl stat res -t
$ ifconfig -a

Repeat the same steps for the rest nodes in the cluster only if the similar change is required.

 

How To Rename A Pluggable Database- PDB

Hi,

I need to rename a pluggable database. It is so easy to rename.7

Let’s do it step by step:

1. Firstly set containter to PDB named DEV

alter session set container=DEV;
2. shutdown and open it in restricted mode.
shutdown immediate;
startup open restrict;
3. Now rename the PDB
alter pluggable database DEV rename global_name to ACC;
4. Check it
show con_name;
show pdbs;
5. shutdown and start in normal mode.
shutdown immediate;
startup;
6. Verify
select name,open_mode from v$pdbs;

How to Modify Public Network Information including VIP in Oracle Clusterware Without Changing Interface

Hi,

Changing public IP or VIP only without changing interface, subnet or netmask or changing MAC address only without changing anything else

If the change is only public IP or VIP address and the new ones are still in the same subnet, same interface, or if the change is only for public IP MAC address, IP/interface/subnet/netmask all remain the same, nothing needs to be done at clusterware layer, all changes need to be done at OS layer to reflect the change. For this;

  • Shutdown Oracle Clusterware stack
  • Modify the IP address at network layer, DNS and /etc/hosts file to reflect the change or modify the MAC address at network layer
  • Restart Oracle Clusterware stack

Above change can be done in rolling method, one node at a time.

Stop database and vip resources.

srvctl stop listener -n orcnode1
srvctl stop database -d orcl
srvctl stop vip -n orcnode1 -f

Change IP address at OS layer. Do this step on both nodes.

cd /etc/sysconfig/network-scripts/
vi ifcfg-bond0
vi /etc/hosts

service network restart

Start database and vip resources.

srvctl start vip -n orcnode1
srvctl start listener -n orcnode1
srvctl start database -d orcl

 

Changing the Character Set for a RAC Database Fails with an ORA-12720

Hi,

Changing the Character set for a RAC Database fails with below ORA-12720 error.

ORA-02374: conversion error loading table “RTLSDPROD”.”ZIF_CRANE_MSG_LOG”
ORA-12899: value too large for column MCHN_ID (actual: 11, maximum: 10)
ORA-02372: data for row: MCHN_ID : 0X’52880000603400006034′

The CLUSTER_DATABASE parameter must be temporarily changed in order  to alter the database character set. This will require a shutdown of the entire database (all instances).

Let’s do it step by step

Step 1: Shutdown all instances.

Step 2: On Node1, edit the initialization parameter CLUSTER_DATABASE and set it to FALSE

CLUSTER_DATABASE = FALSE

Step 3: Startup mount the instance in exclusive mode:

SQLPLUS> startup mount exclusive

Step 4: Issue the following commands:

alter system enable restricted session;
alter system set job_queue_processes = 0;
alter system set aq_tm_processes = 0;
alter database open;

Step 5: Change the character set.

Step 6: Shutdown the instance to enable parallel server.

SQLPLUS> shutdown immediate

Step 7: On Node1, edit the init.ora parameter CLUSTER_DATABASE  and set it to TRUE.

CLUSTER_DATABASE = TRUE

Step 8: Start up all the instances accessing the database.