Showing posts with label RAC. Show all posts
Showing posts with label RAC. Show all posts

Friday, December 30, 2022

RAC DB Crash by ORA-00600: internal error code, arguments: [ksm_mga_pseg_cbk_attach:map_null]

Problem:

When implementing a change required a RAC nodes restart one by one on a 19.5 RAC 2 nodes DB, and while restarting one node in the cluster (node2), the other node (node1) started to report this error and went in hung state, neither we were able to abort the DB instance nor restart the clusterware or the Linux OS:

ORA-00600: internal error code, arguments: [ksm_mga_pseg_cbk_attach:map_null]

Analysis:

The above-mentioned error didn't come alone, it was accompanied by a bunch of other ORA-00600 errors!

ORA 600 [ipc_recreate_que_2]                              
ORA 600 [ORA-00600: internal error code, arguments: [ipc_re
ORA 600 [IPC Assert]                                       
ORA 603                                                    
ORA 600 [17090]    
                                       


Along with the only clear ORA error which explained what was going on:

ORA-27300: OS system dependent operation:open failed with status: 23
ORA-27301: OS failure message: Too many open files in system

We decided to forcefully reboot the hung node (node1) from the hardware console; as the OS went hung, and to be honest, this is a tough decision any DBA can take on a cluster node; as this is known to corrupt the clusterware files especially when fsck runs at the startup.

What made the issue worse, is that the clusterware took too much time to come up on node2 (the node which restarted gracefully), as it was having trouble reading the votedisks --remember the other node (node1) which went hung and forcefully rebooted? This explains!

You may think that everything went fine after the startup of node2, and the hero managed to kill the beast and the movie ended? NO
10 minutes after, node1 DB instance joined back the cluster and node2 crashed by the same above-mentioned bunch or ORA-600 errors.
This scenario kept happening (one node join the cluster, the other node crash), until I started up both DB instances with the pfile.


Solution:

Oracle support referred us to an unpublished Bug 30851951. This bug is well known to hit 19c RAC DBs.

In short, there is something called MGA (Managed Global Area) memory, which shares the memory between the processes that access the PGA memory by sharing it under /dev/shm (if I'm not mistaken!), The bug causes the MGA to keep opening endless number of files under /dev/shm causing the system to reach its max open_files limit and go hung.

Which means you have to pick one of the following solutions:

1- Apply the bug fix patch 30851951 which is available for 19.5
2- Apply 19.8 RU patch or higher.
3- Workaround: Set a value for pga_aggregate_limit parameter.

The best solution I can see here, is to apply the bug fix 30851951 whereas,
Applying 19.8 RU patch is a major change in the system, and setting a value for pga_aggregate_limit parameter is well known to make the system prone to more PGA related bugs on 19c RAC! 

Honestly speaking, throughout the years and after witnessing similar RAC related bugs incidents in the past --since RAC 11g, I started to have a strong feeling that RAC technology itself (because of its bugs) contributes more to the SLAs breaches than the stability of the system!

Thursday, March 3, 2022

Cleanup a Grid Infrastructure Installation on RAC Nodes

 In case you have a failed Grid Infrastructure setup or want to clean up RAC nodes from a 19c RAC setup, follow these steps:

Grid Infrastructure DE-INSTALLATION steps:

[Execute on All Nodes | As root user]   # $GRID_HOME/bin/crsctl stop resource -all
[Execute on All Nodes | As root user]   # $GRID_HOME/bin/crsctl stop has
[Execute on Node1 | As root user]         # $GRID_HOME/crs/install/rootcrs.sh -deconfig -force
[Execute on Node1 | As GRID owner]  # $GRID_HOME/oui/bin/runInstaller -detachHome -silent ORACLE_HOME=$GRID_HOME
[Execute on Rest of Nodes | As root user]        # $GRID_HOME/crs/install/rootcrs.sh -deconfig -force
[Execute on Rest of Nodes | As GRID owner] # $GRID_HOME/oui/bin/runInstaller -detachable -silent ORACLE_HOME=$GRID_HOME

[Execute on All Nodes | As root user]  
            # rm -rf $GRID_HOME/*
           
# rm -rf $GRID_HOME/.*
           
# rm -rf $ORACLE_BASE/*
           
# rm -f /etc/oracle/ocr.loc
           
# rm -f /etc/init.d/init.ohasd
           
# rm -f /etc/inittab.crs
           
# rm -rf /etc/oracle
           
# rm -f /usr/tmp/.oracle/*
           
# rm -f /tmp/.oracle/*
           
# rm -f /var/tmp/.oracle/*
           
# rm -f /etc/oratab
           
# rm -rf /var/opt/oracle

Overwrite the ASM OCR Disks headers:
[Execute on Node1 | As root user]
       
# dd if=/dev/zero of=/dev/oracleasm/disks/OCR_DISK1 bs=1024 count=100
       
# dd if=/dev/zero of=/dev/oracleasm/disks/OCR_DISK2 bs=1024 count=100
       
# dd if=/dev/zero of=/dev/oracleasm/disks/OCR_DISK3 bs=1024 count=100

Now it's good to go with a new Grid Infrastructure setup.


Monday, July 12, 2021

Step By Step How To Add a New Node To a 19c Cluster

One bad news before we start: In 19c versions older than 19.8 you will not be able to add a new node to the cluster using this procedure due to bug 30195027 [Doc ID 30195027.8]
The workaround is to upgrade your GRID_HOME to 19.8 and above using RU patch, I'll shed some light on a similar GRID_HOME upgrade task using zero downtime technique in a future a post.


In this demo:

The cluster is already having one node available with name clsn1, and we are adding one extra node with name clsn2.
orcl   refers to the cluster database name
orcl2 refers to the new instance name on the new node.
clsn2-vip refers to the virtual name of the new node.

Step1: Pre-requisites: [On the new node]

Note: Please strictly follow the prerequisites instructions, failing to do so will lead to mind-blowing strange errors during the process of adding the node to the cluster!

- Install the same OS and kernel version
as similar to the existing nodes in the cluster.

- Install Oracle's required packages: [Applicable for Linux 7]
  # wget http://public-yum.oracle.com/public-yum-ol7.repo
  # yum install -y oracle-database-preinstall-19c gcc gcc-c++ glibc-devel glibc-headers elfutils-libelf-devel gcc gcc-c++ kmod-libs kmod unixODBC unixODBC-devel dtrace-modules-headers
  # yum install -y fontconfig-devel libXrender-devel librdmacm-devel python-configshell targetcli compat-libstdc++-33
  # yum install -y oracleasm-support
 

- Provision the same ASM disks which already provisioned on the other nodes of the cluster to the new node.

- Create the same Groups & Oracle users with the same IDs as the existing nodes in the cluster:
  # groupadd -g 54322 dba
    groupadd -g 54324 backupdba
    groupadd -g 54325 dgdba
    groupadd -g 54326 kmdba
    groupadd -g 54327 asmdba
    groupadd -g 54328 asmoper
    groupadd -g 54329 asmadmin
    groupadd -g 54330 racdba

Note: Below example will add or modify oracle user, I'm doing this for oracle user only because I'm using the same oracle user "oracle" as the owner of both GRID and ORACLE DB homes.

  # useradd oracle -u 54321 -g oinstall -G dba,oper,asmdba,backupdba,dgdba,kmdba,racdba,asmadmin,asmdba,asmoper
  # usermod oracle -u 54321 -g oinstall -G dba,oper,asmdba,backupdba,dgdba,kmdba,racdba,asmadmin,asmdba,asmoper


- Copy the oracle user's .bash_profile from any of the other nodes in the cluster, replacing the node name and instance name with the right values accordingly.

- Set up the same network configuration comparing these files with other nodes in the cluster: /etc/hosts, /etc/resolv.conf
- Protect resolv.conf file from getting changed: # chattr +i /etc/resolv.conf

- Adjust MTU for loopback device: /etc/sysconfig/network-scripts/ifcfg-lo adding this parameter: MTU=16436 and execute this command: # ifconfig lo mtu 16436

- Set the NOZEROCONF parameter in /etc/sysconfig/network adding this parameter: NOZEROCONF=yes

- Setup the same OS settings as similar to other settings in the other nodes: /etc/sysctl.conf, /etc/security/limits.conf

- Stop/Disable Avahi-daemon
:
# systemctl stop avahi-daemon; systemctl disable avahi-daemon; systemctl status avahi-daemon

- Disable SELinux & Firewall:
Adding parameter: SELINUX=disabled to /etc/selinux/config ,
# systemctl stop firewalld; systemctl disable firewalld; systemctl status firewalld

- Set Server Timezone similar to other nodes in the cluster: Check /etc/localtime

- NTP configuration should be same as other nodes [if it's being used]: /etc/chrony.conf

- Configure password less SSH:

  Generate new key On the new node: # ssh-keygen -t rsa
  Copy the key to the other nodes in the cluster: e.g.  # ssh-copy-id oracle@clsn1  # cat ~/.ssh/id_rsa.pub | ssh oracle@clsn2 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"
  Test the connectivity from the new node to the other nodes in the cluster: # ssh oracle@clsn1
  Copy the keys from each active node in the cluster to the new node: # ssh-copy-id oracle@clsn2
  Test the connectivity from other nodes to the new node: # ssh oracle@clsn2

- Change the ownership of the filesystem where Oracle installation files will be installed:

  # chown oracle:oinstall /u01
  # chmod 774 /u01


- Scan ASM disks: [As root on New node]
Note: Same disks on other cluster nodes should be provisioned to the new node as well before do the scanning.

  # oracleasm scandisks
  # oracleasm listdisks


Note: Make sure all ASM disks can be listed, comparing the result with other exist nodes.

- Compare the configuration between existing node and new node: [As GRID Owner - On any of the existing nodes in the cluster]

  # $GRID_HOME/bin/cluvfy comp peer -refnode <exist_node_in_the_cluster> -n <new_node> -orainv orainventory_group -osdba osdba_group -verbose
e.g.
  # $GRID_HOME/bin/cluvfy comp peer -refnode
clsn1 -n clsn2-orainv oinstall -osdba dba -verbose
 

- Workaround INS-06006 Passwordless bug: [As grid owner]

  # echo "export SSH_AUTH_SOCK=0" >> ~/.bashrc
  # export SSH_AUTH_SOCK=0


Step 2: Clone GRID_HOME to the new node and Add it to the cluster: [As GRID Owner - On any of the existing nodes in the cluster]

# export IGNORE_PREADDNODE_CHECKS=Y
# $GRID_HOME/addnode/addnode.sh -silent "CLUSTER_NEW_NODES={
clsn2}" "CLUSTER_NEW_VIRTUAL_HOSTNAMES={clsn2-vip}" -ignorePrereq -ignoreSysPrereqs

   Monitor the operation's log for errors:
    # tail -f /u01/oraInventory/logs/addNodeActions`date -u +"%Y-%m-%d_%H-%M"`*.log


At the End execute root.sh [As root - On the New Node]
# $GRID_HOME/root.sh

    Troubleshooting:
    In case of Error: scp: /u01/grid/12.2.0.3/gpnp/profiles/peer/profile.xml: No such file or directory
    Solution: Copy profile.xml on the RAC node you issued addnode.sh from: cp -p $GRID_HOME/gpnp/clsn1/profiles/peer/profile.xml  $GRID_HOME/gpnp/profiles/peer/profile.xml
         Then run root.sh again on the new node

Step 3: Clone the ORACLE HOME to the new node: [As oracle - On any of the existing nodes in the cluster]

# $ORACLE_HOME/addnode/addnode.sh -silent "CLUSTER_NEW_NODES={clsn2}" -ignorePrereqFailure -ignoreSysPrereqs

At the End execute root.sh [As root - On the New Node]
# $ORACLE_HOME/root.sh

Step 4: Start ACFS: If exist [As root - on the New Node]

# $GRID_HOME/bin/srvctl start filesystem -device <volume_device_name> -node clsn2

Step 5: Check the cluster integrity:

# cluvfy stage -post nodeadd -n clsn2 -verbose

Step 6: Add DB instance to New Node
: [As oracle - on the New Node]

# dbca -silent -ignorePrereqFailure -addInstance -nodeName clsn2 -gdbName orcl -instanceName orcl2 -sysDBAUserName sys -sysDBAPassword oracle#123#

-gdbName            Provide the same value in DB_UNIQUE_NAME if the parameter is set.
-instanceName     The name of the instance on the new node.


Note: This will add a new instance to the new node, add an extra REDOLOG thread plus one more UNDO tablespace as well dedicated for the new instance.

Add the new instance as a preferred instance to the DB Services: [Do this for each service]

# srvctl modify service -d orcl -s reporting_svc -n -i orcl1,orcl2

References: 

https://docs.oracle.com/en/database/oracle/oracle-database/19/cwadd/adding-and-deleting-cluster-nodes.html#GUID-929C0CD9-9B67-45D6-B864-5ED3B47FE458
 

Step By Step How To delete a RAC Node from 19c Cluster

Scope: In this post, I'll go you through the steps of how to remove a node in a 19c RAC cluster.
In this demo:
clsn2 will refer to the node name to be deleted from the cluster in this demo.
orcl   will refer to the cluster database name.
orcl2 will refer to the DB instance name on the node to be deleted.

Step 1: Shutdown all DB Instances running on the node to be deleted:

# srvctl stop instance -db orcl -i orcl2 -o abort

Step 2: Delete all DB Instance on the node to be deleted:

Note: This will delete the instance, remove it's REDOLOG thread and remove its UNDO tablespace as well:

# dbca -silent -ignorePrereqFailure -deleteInstance -gdbName orcl  -instanceName orcl2   -sysDBAUserName sys -sysDBAPassword oracle#123#

-gdbName            Provide the same value in DB_UNIQUE_NAME
-instanceName     The name of the instance on the node to be deleted


Step 3: Unpin the Node to be deleted:

- Check if the node you want to remove is pinned: [As root - On the node to be deleted]

# olsnodes -s -t

- If the node is pinned, then unpin it: [As root - On the node to be deleted]

# crsctl unpin css -n clsn2
 

Step 4: Deinstall GRID Home: [As GRID HOME owner - On the node to be deleted]

# $GRID_HOME/deinstall/deinstall
 

Step 5: Remove the Node from the cluster: [As root - On any of other node in the cluster]

# $GRID_HOME/bin/crsctl delete node -n clsn2

- Verify the Node deletion: [As GRID HOME owner - On any of other node in the cluster]

# $GRID_HOME/bin/cluvfy stage -post nodedel -n node_list -verbose

    Verifying Node Removal ...
      Verifying CRS Integrity ...PASSED
      Verifying Clusterware Version Consistency ...PASSED
    Verifying Node Removal ...PASSED


Post-check for node removal was successful.

Step 6: Delete the VIP Name:

- Get the VIP name of the deleted Node: [As GRID owner - On any of other node in the cluster]

# $GRID_HOME/bin/srvctl config vip -node clsn2 | grep 'Name' 

VIP Name: clsn2-vip

- Delete the VIP name of the deleted node using the VIP name output from previous command: [As root - On any of other node in the cluster]

# $GRID_HOME/bin/srvctl stop   vip  -vip clsn2-vip
# $GRID_HOME/bin/srvctl remove vip  -vip
clsn2-vip -noprompt

References:

https://docs.oracle.com/en/database/oracle/oracle-database/19/cwadd/adding-and-deleting-cluster-nodes.html#GUID-8ADA9667-EC27-4EF9-9F34-C8F65A757F2A

Wednesday, June 3, 2020

19c Grid Infrastructure Installation when running root.sh with PRKH-1010 : Unable to communicate with CRS services.

Problem:

While executing root.sh during a 19c Grid Infrastructure on a two RAC nodes I experienced this error:

2020/05/18 10:22:47 CLSRSC-594: Executing installation step 18 of 19: 'ConfigNode'.
2020/05/18 10:22:59 Oracle Clusterware infrastructure error in CLSECHO (OS PID 27328): ADR home path /u01/oracle/diag/crs/clssrv1-vip2/crs does not exist; ADR initialization will try to create it
CLSRSC-594: Executing installation step 19 of 19: 'PostConfig'.
PRKH-1010 : Unable to communicate with CRS services.

PRKH-3003 : An attempt to communicate with the CSS daemon failed

2020/05/18 10:23:31 CLSRSC-180: An error occurred while executing the command 'srvctl start listener -l LISTENER'
Died at /u01/grid/12.2.0.3/crs/install/crsutils.pm line 12160. 


Analysis:

When checked Server static host name it wasn't set properly:

 # cat /etc/hostname
localhost.localdomain

# hostnamectl | grep hostname
Static hostname: localhost.localdomain
Transient hostname: clssrv1-vip2


# hostnamectl --static
localhost.localdomain 


Fix:

Set the server static host name properly using this Linux command:

# hostnamectl set-hostname clssrv1

Now the static name is showing the correct value of server name:

# hostnamectl
   Static hostname: clssrv1         
         Icon name: computer-server
           Chassis: server
        Machine ID: r93o4kde7b4d8o333jr4406686a4e
           Boot ID: 6b34567b7a3577767a1e3768306d954
  Operating System: Oracle Linux Server 7.4
       CPE OS Name: cpe:/o:oracle:linux:7:4:server
            Kernel: Linux 4.1.12-94.3.9.el7uek.x86_64
      Architecture: x86-64


Now re-execute the root.sh script. If it fails again remove the Grid Infrastructure installation and re-install it again.

Thursday, April 23, 2020

CRS-6706: Oracle Clusterware Release patch level ('3291738383') does not match Software patch level ('724960844')

Problem:
After patching an Oracle 19.3 GRID_HOME on Oracle Restart setup with 19.5 RU patch [30125133], I was not able to start up Oracle Restart HAS due to this error:

#  $GRID_HOME/bin/crsctl start has
CRS-6706: Oracle Clusterware Release patch level ('3291738383') does not match Software patch level ('724960844'). Oracle Clusterware cannot be started.
CRS-4000: Command Start failed, or completed with errors.

Analysis:
Despite the success of patching GRID_HOME with 19.5 RU went successful, something went wrong during the patching process.
While trying to find a solution, I landed on Oracle Note (Doc ID 1639285.1) which describes a similar problem on a RAC setup, but it didn't offer a solution for Oracle Restart setup --which is my case. So I thought to write about the solution I followed and worked for me in this post.

Solution:
Running the following commands would fix/complete an in-complete patching of the GRID_HOME on an Oracle Restart setup:
You have to run the following commands with root user while Oracle Restart HAS is stopped:
# $GRID_HOME/crs/install/roothas.sh -unlock
# $GRID_HOME/crs/install/roothas.sh -prepatch 
# $GRID_HOME/crs/install/roothas.sh -postpatch













Oracle Restart HAS will startup automatically after the last command.

Sunday, April 12, 2020

19c Clusterware fail to Startup due to CRS-41053: checking Oracle Grid Infrastructure for file permission issues CRS-4000

On a19c cluster node I got this error when trying to start one RAC node:

[root@fzppon05vs1n ~]# crsctl start crs
CRS-41053: checking Oracle Grid Infrastructure for file permission issues
PRVG-11960 : Set user ID bit is not set for file "/u01/grid/12.2.0.3/bin/extjob" on node "fzppon05vs1n".
PRVG-2031 : Owner of file "/u01/grid/12.2.0.3/bin/extjob" did not match the expected value on node "fzppon05vs1n". [Expected = "root(0)" ; Found = "oracle(54321)"]
CRS-4124: Oracle High Availability Services startup failed.
CRS-4000: Command Start failed, or completed with errors.


Before you rush and change any file permission, read below solutions carefully, because most probably it's not a permission issue!

I've faced this error in many occasions; each time I fix it with a different solution. And here is a list of all solutions, where anyone can work for you.

Solution #1: Make sure / and /var filesystems are not full

If / or /var filesystems are 100% full this may cause CRS-41053 when starting up the clusterware. If that is the case then free up the space under the full filesystem, one quick command can do the magic; cleaning yum files:
 
[As root]
# yum clean all

 
Solution #2: kill all duplicate ohasd services
 
Before trying to restart the OS, just thought to check the clusterware background processes, and here is the catch:

[root@fzppon05vs1n ~]# ps -ef | grep -v grep| grep '\.bin'
root     19786     1  1 06:18 ?        00:00:39 /u01/grid/12.2.0.3/bin/ohasd.bin reboot

root     19788     1  0 06:18 ?        00:00:00 /u01/grid/12.2.0.3/bin/ohasd.bin reboot
root     19850     1  0 06:18 ?        00:00:13 /u01/grid/12.2.0.3/bin/orarootagent.bin
root     19958     1  0 06:18 ?        00:00:14 /u01/grid/12.2.0.3/bin/oraagent.bin

...

Found lots of ohasd.bin are running, while it supposed to be only one ohasd.bin process

Checking all ohasd related processes:

[root@fzppon05vs1n ~]# ps -ef | grep -v grep | grep ohasd
root      1900     1  0 06:17 ?        00:00:00 /bin/sh /etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null
root      1947  1900  0 06:17 ?     00:00:00 /bin/sh /etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null
root      19786     1  1 06:18 ?        00:00:00 /u01/grid/12.2.0.3/bin/ohasd.bin reboot
root      19788     1  0 06:18 ?        00:00:00 /u01/grid/12.2.0.3/bin/ohasd.bin reboot


Now, let's kill all ohasd processes and give it a try:

[root@fzppon05vs1n ~]# kill -9 1900  1947 19786 19788            

or simply kill all init.ohasd using the following one command:
[root@fzppon05vs1n ~]# ps -ef | grep 'init.ohasd' | grep -v grep | awk '{print $2}' | xargs -r kill -9            
Start the clusterware:

[root@fzppon05vs1n ~]# crsctl start crs
CRS-4123: Oracle High Availability Services has been started.


Voilà! Started up.

In case this didn't work move to the next solution ...
 
 
Solution #3: Reboot the server
 
This sounds as an IT Service Disk solution, but restarting the machine is known to fix 50% or more of cluster startup weird issues :-)
  
 
Solution #4: Re-configuring the clusterware
 
In case your clusterware still doesn't start up after the above workaround, you may need to consider re-configuring the clusterware using the following commands:

Note: Re-configuring the clusterware should happen on the malfunctioning node, where it's not supposed to do any impact on the other working cluster nodes:

# $GRID_HOME/crs/install/rootcrs.sh -deconfig -force
# $GRID_HOME/root.sh

 
Conclusion:

CRS-41053 may look vague, moreover, it may mention a different file other than extjob in the error message, don't rush and change the file's ownership as advised by the error message,
- Make sure there is no filesystem is 100% full.
- Second, check for any redundant running clusterware background processes and kill it, then try to startup the clusterware.
- If clusterware is still failing; restart the node and check again for any redundant processes, if found any of them try to kill and start the cluster.
- Lastly, If your clusterware still doesn't come up, then use the sliver bullet and reconfigure the clusterware on the malfunctioning node.

Monday, November 11, 2019

CRS-4000: Command Start failed, or completed with errors

Problem:

While restarting the clusterware on one cluster node I got this error:

[root@fzppon06vs1n~]# crsctl start cluster
CRS-2679: Attempting to clean 'ora.ctssd' on 'fzppon06vs1n'
CRS-2672: Attempting to start 'ora.drivers.acfs' on 'fzppon06vs1n'
CRS-2672: Attempting to start 'ora.evmd' on 'fzppon06vs1n'
CRS-2680: Clean of 'ora.ctssd' on 'fzppon06vs1n' failed
CRS-2676: Start of 'ora.evmd' on 'fzppon06vs1n' succeeded
CRS-2674: Start of 'ora.drivers.acfs' on 'fzppon06vs1n' failed
CRS-2672: Attempting to start 'ora.drivers.acfs' on 'fzppon06vs1n'
CRS-2679: Attempting to clean 'ora.ctssd' on 'fzppon06vs1n'
CRS-2680: Clean of 'ora.ctssd' on 'fzppon06vs1n' failed
CRS-2679: Attempting to clean 'ora.ctssd' on 'fzppon06vs1n'
CRS-2680: Clean of 'ora.ctssd' on 'fzppon06vs1n' failed
CRS-2674: Start of 'ora.drivers.acfs' on 'fzppon06vs1n' failed
CRS-2672: Attempting to start 'ora.storage' on 'fzppon06vs1n'
CRS-2676: Start of 'ora.storage' on 'fzppon06vs1n' succeeded
CRS-4000: Command Start failed, or completed with errors.



Analysis:

When checking the clusterware alertlog I can find the log stopped on this line:

2019-10-07 12:15:45.495 [EVMD(23031)]CRS-8500: Oracle Clusterware EVMD process is starting with operating system process ID 23031
I've checked the time between both cluster nodes and it was in sync.
Tried to stop the clusterware forcefully and start it up:

[root@fzppon06vs1n~]# crsctl stop crs -f
CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on 'fzppon06vs1n'
CRS-2679: Attempting to clean 'ora.ctssd' on 'fzppon06vs1n'
CRS-2680: Clean of 'ora.ctssd' on 'fzppon06vs1n' failed
CRS-2679: Attempting to clean 'ora.ctssd' on 'fzppon06vs1n'
CRS-2680: Clean of 'ora.ctssd' on 'fzppon06vs1n' failed
CRS-2679: Attempting to clean 'ora.ctssd' on 'fzppon06vs1n'
CRS-2680: Clean of 'ora.ctssd' on 'fzppon06vs1n' failed
CRS-2679: Attempting to clean 'ora.ctssd' on 'fzppon06vs1n'
CRS-2680: Clean of 'ora.ctssd' on 'fzppon06vs1n' failed
CRS-2679: Attempting to clean 'ora.ctssd' on 'fzppon06vs1n'
CRS-2680: Clean of 'ora.ctssd' on 'fzppon06vs1n' failed
CRS-2799: Failed to shut down resource 'ora.cssd' on 'fzppon06vs1n'
CRS-2799: Failed to shut down resource 'ora.cssdmonitor' on 'fzppon06vs1n'
CRS-2799: Failed to shut down resource 'ora.ctssd' on 'fzppon06vs1n'
CRS-2799: Failed to shut down resource 'ora.gipcd' on 'fzppon06vs1n'
CRS-2799: Failed to shut down resource 'ora.gpnpd' on 'fzppon06vs1n'
CRS-2795: Shutdown of Oracle High Availability Services-managed resources on 'fzppon06vs1n' has failed
CRS-4687: Shutdown command has completed with errors.
CRS-4000: Command Stop failed, or completed with errors.


Looks there is a problem with stopping cssd and ctssd services as well.

Solution:

Restarted the node and the clusterware came up properly without errors:

[root@fzppon06vs1n ~]# sync;sync;sync; init 6

Analyzing such problem was challenging as there were no errors reported in the clusterware logs when the clusterware was hung during its start up. So far, restarting the RAC node is one of the silver bullet troubleshooting techniques for many of non-sense clusterware behaviors ;-)

Monday, October 14, 2019

Transaction Guard | Application Continuity | DML Failover in RAC 19c


Introduction:

Starting from 12c TAF can failover DMLs to the available nodes on a RAC environment in case of any interruption happens to it including node/service/network failure. This feature is called  Application Continuity or Transaction Guard.

Pre-requisites: [For 19c]

The applications should use Oracle Client 19c. Although the Oracle note Doc ID 2011697.1 mentioning that any 12.1+ Oracle Client will work, it didn't work for me while testing on a 19c DB.
Application Continuity works on the assumption that the applications are well written in terms of connection usage:
  • Borrowing connections and returning them to the connection pool instead of pinning connections.
  • If a statement cache at the application server level is enabled it must be disabled when the replay is used. or use JDBC statement cache, which is compatible with Application Continuity. 
  • Additional CPU utilization will happen on the client-side in order to handle garbage collections. 
Implementation:

# srvctl add service -database sprint -service pssfztest_rpt -preferred sprint1,sprint2 -tafpolicy BASIC -failovertype TRANSACTION -commit_outcome TRUE -failovermethod BASIC -failoverretry 100 -stopoption IMMEDIATE -session_state DYNAMIC -role PRIMARY -policy AUTOMATIC -clbgoal long -verbose -failover_restore LEVEL1 -replay_init_time 3600

Notes:

- Don't use replay_init_time along with failoverdelay or you will get this error when trying to start the service:
CRS-2632: There are no more servers to try to place resource 'ora.sprint.pssfztest_gg.svc' on that would satisfy its placement policy

- In order for the applications to use the DML failover feature (Application Continuity) application users should be granted execute permission on DBMS_APP_CONT: [For simplicity I'm granting it for everyone but some applications don't work properly with this feature, so it's recommended to test your application and grant this permission to the users of the applications that support Application Continuity]
SQL> grant execute on DBMS_APP_CONT to public;

- clbgoal=short is less stable than clbgoal=long where failover retries can be exhausted before reaching its max limit.

- clbgoal=short balance the sessions between RAC nodes based on response time, while clbgoal=long balance the sessions based on the total number of sessions on each node.

- The PRECONNECT option for -tafpolicy parameter is deprecated in 19c.

- If you set -failovertype = TRANSACTION, then you must set -commit_outcome to TRUE.

- For -session_state Oracle recommends to set it to DYNAMIC for most applications, to use the default session settings (NLS settings, optimizer preferences,..) after the session fails over.

- replay_init_time: Specifies the time in seconds after which replay (failover) will not happen. [It's set to 3600sec =1 hour above]

The following activities if happened can cause the transaction to failover without being disrupted [transaction will hang for a few seconds till the connectivity get restored on the available nodes]:

- instance crash.
- Partial Network disruption.
- OS kill -9 of the instance main processes (PMON/SMON).
- OS kill -STOP followed by kill -9 of the same session.
- shutdown immediate (from SQLPLUS console).
- shu abort (from SQLPLUS console).
- srvctl stop service -d sprint -i sprint1
- srvctl stop service -d sprint -i sprint1 -force
- srvctl stop instance -d sprint -i sprint1 -failover
- ALTER SYSTEM KILL SESSION command.
- ALTER SYSTEM DISCONNECT SESSION command.

The following activities will terminate the DML transaction WITHOUT failing them over but the session itself will re-connect automatically: [If performed on the node where the session is connected]
- OS kill -9 of the session PID.
- ALTER SYSTEM CANCEL SQL '<SID>,<SERIAL#>';
- srvctl stop instance -d sprint -i sprint1 -force
- crsctl stop cluster
- crsctl stop crs



Conclusion:

- Application Continuity feature can let you carry out activities like software patching, hardware/network maintenance with real ZERO downtime.

- Before using Application Continuity feature, you have to make sure that your applications are compatible with this feature by testing all the scenarios you may go through. It will be wise if you consult your application vendor before implementing this feature.
Using this feature blindly without proper testing may result in unexpected application behavior.

- Applications should not use the default database service (which has the same name as DB_NAME/DB_UNIQUE_NAME of the database) as this service is not supported by the high availability features.

References:

Wednesday, September 11, 2019

RAC Database Fail To Start Due To "terminating the instance due to error 119" error

Problem:
On a Linux 7, after system reboot I have an 11.2.0.3 RAC Database failed to start due to this error in the alertlog:

USER (ospid: 13324): terminating the instance due to error 119
Instance terminated by USER, pid = 13324

Cause:
While investigating I figured out that the SCAN name "rac1-scan" which is used in "remote_listener" initialization parameter is not pingable:
$ ping rac1-scan
ping: unknown host rac1-scan

When checked /etc/resolv.conf file I found the DNS server entry got removed:
$ cat /etc/resolv.conf
# Generated by NetworkManager
search preprod.mycompany.com


# No nameservers found; try putting DNS servers into your
# ifcfg files in /etc/sysconfig/network-scripts like so:
#
# DNS1=xxx.xxx.xxx.xxx
# DNS2=xxx.xxx.xxx.xxx
# DOMAIN=lab.foo.com bar.foo.com

Solution:
Luckily I always run a script called configuration_baseline.sh to keep a backup of the critical system files entries inside one log file, it helps to restore the entries later whenever any bad change happens to these files.

I restored the original entries of /etc/resolv.conf which holds the right DNS server name in my environment then managed to start the RAC DB successfully.

$ cat /etc/resolv.conf
# Generated by NetworkManager
search preprod.mycompany.com
nameserver 10.100.22.10

Conclusion:
terminating the instance due to error 119 error is mainly related to "remote_listener" initialization parameter setting, if this setting is messed up it can prevent the RAC instance from starting up.

Recommendation:
Always keep a copy of /etc/resolv.conf or immune the file from getting reset by the system after system reboot by using the following command:
chattr +i /etc/resolv.conf

You can use this script to help you with keeping the entries of your Linux & Oracle critical files saved somewhere, in case you will have a need to restore them later:

Tuesday, September 10, 2019

OPATCHAUTO-72083: Performing bootstrap operations failed OPATCHAUTO-72146: Failed to load patch

Problem:
While patching 19.3 GRID_HOME with July2019 RU patch 19.4 I got this error:

[root@fzppon06vs1n bin]#  export PATCH_LOCATION=/u01/oracle/RU_PATCHES/29708769
[root@fzppon06vs1n bin]# $GRID_HOME/OPatch/opatchauto apply $PATCH_LOCATION -oh $GRID_HOME

OPatchauto session is initiated at Mon Sep  9 11:00:57 2019
OPATCHAUTO-72083: Performing bootstrap operations failed.
OPATCHAUTO-72083: The bootstrap execution failed because OPATCHAUTO-72146: Failed to load patch
OPATCHAUTO-72146: Failed while collecting patch information for patch /u01/oracle/RU_PATCHES/29708769.
OPATCHAUTO-72146: Check the log for more information..
OPATCHAUTO-72083: Fix the reported problem and re-run opatchauto.

OPatchauto session completed at Mon Sep  9 11:01:02 2019
Time taken to complete the session 0 minute, 5 seconds

opatchauto bootstrapping failed with error code 255.

Solution:
The problem was with the RU patch binaries, looks the files were not copied properly, extracting the binaries properly from the zip file has fixed the problem!
unzip -d /u01/oracle/RU_PATCHES  p29708769_190000_Linux-x86-64.zip

Initially, I copied the "extracted" RU binary files from another node, seems they were incomplete.

Prerequisite check "CheckActiveFilesAndExecutables" failed

Problem:
While patching the GRID INFRASTRUCTURE home with July2019 RU patch I got this error:

[root@fzppon06vs1n 29708769]# $GRID_HOME/OPatch/opatchauto apply $PATCH_LOCATION -oh $GRID_HOME

OPatchauto session is initiated at Mon Sep  9 11:14:23 2019

System initialization log file is /u01/grid/12.2.0.3/cfgtoollogs/opatchautodb/systemconfig2019-09-09_11-14-29AM.log.

Session log file is /u01/grid/12.2.0.3/cfgtoollogs/opatchauto/opatchauto2019-09-09_11-15-43AM.log
The id for this session is TV9U

Executing OPatch prereq operations to verify patch applicability on home /u01/grid/12.2.0.3
Patch applicability verified successfully on home /u01/grid/12.2.0.3


Bringing down CRS service on home /u01/grid/12.2.0.3
CRS service brought down successfully on home /u01/grid/12.2.0.3


Start applying binary patch on home /u01/grid/12.2.0.3
Failed while applying binary patches on home /u01/grid/12.2.0.3

Execution of [OPatchAutoBinaryAction] patch action failed, check log for more details. Failures:
Patch Target : fzppon06vs1n->/u01/grid/12.2.0.3 Type[crs]
Details: [
---------------------------Patching Failed---------------------------------
Command execution failed during patching in home: /u01/grid/12.2.0.3, host: fzppon06vs1n.
Command failed:  /u01/grid/12.2.0.3/OPatch/opatchauto  apply /u01/oracle/RU_PATCHES/29708769 -oh /u01/grid/12.2.0.3 -target_type cluster -binary -invPtrLoc /u01/grid/12.2.0.3/oraInst.loc -jre /u01/grid/12.2.0.3/OPatch/jre -persistresult /u01/grid/12.2.0.3/OPatch/auto/dbsessioninfo/sessionresult_fzppon06vs1n_crs.ser -analyzedresult /u01/grid/12.2.0.3/OPatch/auto/dbsessioninfo/sessionresult_analyze_fzppon06vs1n_crs.ser
Command failure output: 
==Following patches FAILED in apply:

Patch: /u01/oracle/RU_PATCHES/29708769/29834717
Log: /u01/grid/12.2.0.3/cfgtoollogs/opatchauto/core/opatch/opatch2019-09-09_11-19-51AM_1.log
Reason: Failed during Patching: oracle.opatch.opatchsdk.OPatchException: Prerequisite check "CheckActiveFilesAndExecutables" failed. 

After fixing the cause of failure Run opatchauto resume

]
OPATCHAUTO-68061: The orchestration engine failed.
OPATCHAUTO-68061: The orchestration engine failed with return code 1
OPATCHAUTO-68061: Check the log for more details.
OPatchAuto failed.

OPatchauto session completed at Mon Sep  9 11:20:28 2019
Time taken to complete the session 6 minutes, 6 seconds

 opatchauto failed with error code 42

The environment is two nodes RAC 19c, while the patching worked fine on node1 it failed with above error on node2. 
Neither Restarting the Clusterware or killing the sessions IDs that come out of below commands did help as well:
fuser /u01/grid/12.2.0.3/lib/libsqlplus.so
fuser /u01/grid/12.2.0.3/lib/libasmclntsh19.so

Solution:
Apply the RU patch manually for each patch using opatch instead of opatchauto:

Manual patching of RU patch on GRID HOME:
Note the patch has been extracted under /u01/oracle/RU_PATCHES/ make sure that PATCH_LOCATION variables refers to the location where you extracted the RU binaries.

[As ROOT]
        Run Pre-patching script:
        # export GRID_HOME=/u01/grid/12.2.0.3
# $GRID_HOME/crs/install/rootcrs.sh -prepatch 
Stop clusterware on the local node:
        # crsctl stop cluster

[As GRID OWNER]
        Start patching:
# export PATCH_LOCATION=/u01/oracle/RU_PATCHES/29708769
$GRID_HOME/OPatch/opatch apply -oh $GRID_HOME -local $PATCH_LOCATION/29850993 
$GRID_HOME/OPatch/opatch apply -oh $GRID_HOME -local $PATCH_LOCATION/29851014 
$GRID_HOME/OPatch/opatch apply -oh $GRID_HOME -local $PATCH_LOCATION/29834717 
$GRID_HOME/OPatch/opatch apply -oh $GRID_HOME -local $PATCH_LOCATION/29401763 

[As ROOT]
        Run Post-patching script:
$GRID_HOME/crs/install/rootcrs.sh -postpatch 

Manual patching of RU patch on ORACLE HOME:
[As ORACLE OWNER]
        Run Pre-patching script:
# export PATCH_LOCATION=/u01/oracle/RU_PATCHES/29708769
$PATCH_LOCATION/29850993/custom/scripts/prepatch.sh -dbhome $ORACLE_HOME 

Stop all instances that runs from ORACLE_HOME on the local node:
# srvctl stop instance-d xxx -i xxx
        Start patching:
        # export ORACLE_HOME=/u01/oracle/12.2.0.3
# export PATCH_LOCATION=/u01/oracle/RU_PATCHES/29708769
$ORACLE_HOME/OPatch/opatch apply -oh $ORACLE_HOME -local $PATCH_LOCATION/29850993 
$ORACLE_HOME/OPatch/opatch apply -oh $ORACLE_HOME -local $PATCH_LOCATION/29834717 

        Run Post-patching script:
$PATCH_LOCATION/29850993/custom/scripts/postpatch.sh -dbhome $ORACLE_HOME 

Start back all instances on the local node:
# srvctl start instance-d xxx -i xxx

Sunday, June 16, 2019

Grid Infrastructure root.sh Fail With Error "Failed to create keys in the OLR"


During the installation of Grid Infrastructure Clusterware 12.1.0.2 on OEL 6.6 root.sh failed with the following error:

[root]# /u01/12.1.0/grid/root.sh 
Performing root user operation. 

The following environment variables are set as: 
ORACLE_OWNER= grid 
ORACLE_HOME= /u01/12.1.0/grid 

Enter the full pathname of the local bin directory: [/usr/local/bin]: 
Copying dbhome to /usr/local/bin ... 
Copying oraenv to /usr/local/bin ... 
Copying coraenv to /usr/local/bin ... 


Creating /etc/oratab file... 
Entries will be added to the /etc/oratab file as needed by 
Database Configuration Assistant when a database is created 
Finished running generic part of root script. 
Now product-specific root actions will be performed. 
Using configuration parameter file: /u01/12.1.0/grid/crs/install/crsconfig_params 
/u01/12.1.0/grid/bin/crsctl query crs releaseversion ... failed rc=1 with message: 
/u01/12.1.0/grid/bin/crsctl: line 307: /u01/12.1.0/grid/bin/crsctl.bin: Success 

Failed to create keys in the OLR, rc = 1, Message: 
/u01/12.1.0/grid/bin/clscfg: line 307: /u01/12.1.0/grid/bin/clscfg.bin: Success 

Died at /u01/12.1.0/grid/crs/install/crsutils.pm line 7705. 
The command '/u01/12.1.0/grid/perl/bin/perl -I/u01/12.1.0/grid/perl/lib -I/u01/12.1.0/grid/crs/install /u01/12.1.0/grid/crs/install/rootcrs.pl ' execution failed 

Analysis:
At the first glance, I thought there is a problem with writing to the ASM disk group where the OCR will be created, after a long analysis and research, I finally figured out that the Grid binary source files where I'm installing the Clusterware from are missing some files!

Fix:
I re-downloaded the Grid Infrastructure source binaries and managed to install the Grid Infrastructure successfully.

Reference: Doc ID 1909073.1

Sunday, August 17, 2008

RAC MOST USED COMMANDS


RAC MOST USED COMMANDS: [10g]


srvctl: For Database and Instances:

Start / Stop a RAC database:
----------------------------
srvctl start database -d  database_name -o open

srvctl stop database -d 
database_name  -o immediate


Start / Stop a RAC instance:
----------------------------
srvctl start instance-d  database_name  -i instance_name-o open

srvctl stop instance-d 
database_name  -i instance_name -o immediate

Start/stop nodeapps:
-------------------
srvctl start nodeapps -n node_name

srvctl stop nodeapps -n node_name


To add a database/instance to RAC cluster:
--------------------------------------
srvctl add database -d 
 database_name -o <ORACLE_HOME>
srvctl add instance -d  database_name  -i  instance_name -n  node_name

Start / Stop the Listener:
-------------------------
srvctl start listener –l listener_name –n 
node_name 

srvctl stop listener –l listener_name –n node_name 

To add a node:
-------------
srvctl add nodeapps -n
 node_name   -A VIP_NAME | IP

Start/stop asm:
--------------
srvctl start asm -n  node_name 

srvctl stop asm -n  node_name 

To prevent a database from starting at boot time:
------------------------------------------------
srvctl disable database -d database_name 


CRS RESOURCE STATUS:
-------------------
srvctl status service -d database_name 


CRSCTL: Resources and Nodes:

To Stop all RAC resources on the node you step on it: (By root user)
-----------------------------------------------------
crsctl stop crs

To Start all RAC resources:(By root user)
--------------------------
crsctl start crs

Check RAC status:
----------------
crs_stat -t

Crs health check:
--------------
crsctl check crs

Clusterware version:
-------------------
crsctl query crs softwareversion
crsctl query crs activeversion



Prevent the CRS from starting at boot time:
=============================
crsctl stop crs --> (On the failing node) will stop CRS.

crsctl disable crs  -->(On the failing node) Will disable crs from starting next reboot.

After you fix the problem re-enable the CRS on the node to let it start after rebooting the OS:

# crsctl enable crs

Voting disks:

Voting Disks are for Disk Heartbeat, which are essential in the detection and resolution of cluster "split brain" situation.

Backing up Vote disks:
------------------------
In 10g this can be done while the CRS is running: 10g
================================
# dd if=voting_disk_name  of=backup_file_name

In 11g you must shutdown the CRS: 11g
========================
# crsctl stop crs (On all nodes)

# dd if=voting_disk_name  of=backup_file_name

Note: Don't use copy command "cp" use "dd" command only.

When to back up vote disks:
=================
You do not have to back up the voting disk every day. Back up only in the following cases:

-After RAC installation.
-After add or delete a node on the cluster.
-After adding or removing a votedisk using CRSCTL command.

Note: 11gR2 Voting disks contents are backed up automatically in OCR, you're not required to manually backup the Voting disks.

Check Voting Disk:
------------------
# crsctl query css votedisk

Restore votedisks:  (By root user)
---------------------

Case of losing all of votedisks:
====================
1-Shutdown CRS: (On all Nodes)
- ---------------
# crsctl stop crs

2-Locate the current location of the Votedisks:
- -----------------------------------------
# crsctl query css votedisk

3-Restore all votedisks from a previous good backup taken by "dd" command: (On One node only)
- -----------------------------------------------------------------------
# dd if=Votedisk_backup_file  of=Votedisk_file   <<-- do this for all the votedisks.

4-Start CRS: (On all Nodes)
- ------------
# crsctl start crs


Case of losing ONE voting disk:
==================

1-Start the clusterware in exclusive mode: (On One node only)
- --------------------------------------------------------
# crsctl start crs -excl

2-Retrieve the list of voting disks currently defined: -if found-
- ---------------------------------------------------
# crsctl query css votedisk

##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
 1. ON     938e3a4fd41a4f5bbf8d0d5c676aca9a ( /oracle/ORCL/voting/voting_01.dbf) []
 2. ON       99f4b4f7d65f4f05bf237ad06c52b65a ( /oracle/ORCL/voting/voting_02.dbf) []
 3. OFF      0578603d0f6b4f21bfb2eb22ae82f00d ( /oracle/ORCL/voting/voting_03.dbf) []

This list may be empty if all voting disks were corrupted, or "STATE" will be "3" or "OFF".

3-Delete the corrupted voting disks:
- ------------------------------
# crsctl delete css votedisk  /oracle/ORCL/voting/voting_03.dbf

Note: You can also use the "File Universal Id" instead of the full path:

Note:
=It is not recommended to use "-force" attribute to add or delete a voting disk while the Clusterware is running. This is known to corrupt the OCR (no errors will appear but will cause node eviction).
=The "-force" attribute can be safely used ONLY if the Clusterware is stopped on all the nodes of the cluster.

4- Add the voting disks again:
- ------------------------
First: touch the corrupted file:
# touch  /oracle/ORCL/voting/voting_03.dbf

Second: Add the touched file to votedisk list:
# crsctl add css votedisk /oracle/ORCL/voting/voting_03.dbf

Note: You can copy a good votedisk to the corrupted one, you can use links to back up locations to save time.

Restart the clusterware:
-----------------------
# crsctl stop crs -f   --> -f because we started it in exclusive mode.
# crsctl start crs     --> On both Nodes.


OCR disks:

OCR disks hold the clusterware configuration information (Nodes info, registered resources,databases,instances ,listeners,services,.....etc), It's somehow similar to the "Registry" in Windows OS.

Checking OCR disks:(As root user)
-----------------------
# ocrcheck


Backup OCR:
-------------
Oracle automatically backup the OCR files every 4 hours, you can check these backup files location by using this command:

# ocrconfig -showbackup

Backup OCR to export file:(Logical backup) (By root user)
------------------------------------
# ocrconfig -export Export_File_Name


Restore OCR Disks:
--------------------

Restore OCR from automatic backups being taken every 4 hours:  (By root user)
------------------------------------------------------------
# crsctl stop crs  -> On all RAC nodes.

# ocrconfig -restore /CRS_HOME/cdata/CLUSTER_NAME/xxxx.ocr   -> From one node only.

# crsctl start crs   -> On all RAC nodes.

Restore OCR from export file been taken manually using "ocrconfig -export" command:  (By root user)
----------------------------------------------------------------------------------
# crsctl stop crs  -> On all RAC nodes.

# ocrconfig -import /backupdisk/xxxx.dmp  -> On one RAC node only.

# crsctl start crs ->On all RAC nodes.

Miscellaneous:

Check if a database is RAC or not:
========================

SQL> show parameter CLUSTER_DATABASE;

OR:
--

SQL> set serveroutput on;
SQL> BEGIN
IF dbms_utility.is_cluster_database THEN
dbms_output.put_line('Running in SHARED/RAC mode.');
ELSE
dbms_output.put_line('Running in EXCLUSIVE mode.');
END IF;
END;
/

 
Check the active instance and its Host:
==========================

SQL> SELECT * FROM SYS.V_$ACTIVE_INSTANCES;
SQL> SELECT * FROM SYS.V_$THREAD;