Guenadi N Jilevski's Oracle BLOG

Oracle RAC, DG, EBS, DR and HA DBA BLOG

How to clean up after a failed 11g CRS install. What is new in 11g R2?

How to clean up after a failed 11g CRS install. What is new in 11g R2?

Although it sounds pretty much the same as a previous post How to Clean Up After a Failed 11g CRS Install in Linux
here we are looking at specifics related to Oracle 11g R2.

In Oracle 11g R1 if the Oracle Clusterware installation failed a manual cleanup was required. Steps to re-install Oracle clusterware was:

  1. Manually cleanup after the failed Oracle Clusterware install
  2. Fix the problem
  3. Restart the Oracle Clusterware installation.

In Oracle 11g R2 the installation and configuration are made more flexible and there is a clearer line between installation and configuration. In Oracle 11gR2 a new script roocrs.pl is available to de-configure and clean the Grid Infrastructure installation without removing the binaries. This script also cleans the OCR and vote disks created on ASM. The script allows to clean up the Grid Infrastructure without removing the binaries, fix the problems and re-run root.sh.

Manual Cleanup for RAC 11gR1

The Oracle provided scripts rootdelete.sh and rootdeinstall.sh remove Oracle Clusterware from your system. After running these scripts, run Oracle Universal Installer to remove the Oracle Clusterware home.
The rootdelete.sh script should be run from the Oracle Clusterware home on each node. It stops the Oracle Clusterware stack, removes inittab entries, and deletes some of the Oracle Clusterware files. The rootdeinstall.sh script should be run on the local node only, after rootdelete.sh has been run on all nodes of the cluster. Use this command either to remove the Oracle Clusterware OCR file, or to downgrade your existing installation. If for some reasons there is no access to the scripts look at the post How to Clean Up After a Failed 11g CRS Install in Linux how to remove the inittab entries and Oracle Clusterware. Although the method described in the post applies to Oracle 11g R2 the new tools can suffice most of the time.

What is new in Oracle 11g R2?

In Oracle 11g R2 a tool rootcrs.pl is provided allowing de-configuration without deinstall. After Oracle Clusterware is de-configured we can fix the problem and re-run the root.sh to re-start the Oracle Clusterware configuration.

New deinstall utility removes the binaries from the server in a similar way to OUI in previous Oracle versions.

So if root.sh fails while we install Oracle Grid infrastructure we can gather error messages from the logs, de-configure Oracle clusterware and troubleshoot the reason for the failure. After Oracle Clusterware de-configuration and successful troubleshooting we can proceed further with the configuration re-running root.sh if the problem can be fixed. Thus, in case of errors such as permissions we can save time re-installing Oracle Clusterware binaries. If necessary, we still have an option to completely remove the Oracle Clusterware binaries using the deinstall utility. Prior to running deinstall Oracle Clusterware must be de-configured using rootcrs.pl tool. Successful deinstall preceded by successful de-configure gives a pristine environment to re-start Oracle Grid installation after the failed install is troubleshot based on information gathered examining the logs.

Deconfigure Oracle Clusterware without removing the binaries:

  • Log in as the root user on a node where you encountered an error. Change directory to $GRID_HOME/crs/install. For example:

    # cd $GRID_HOME/crs/install

  • Run rootcrs.pl with the -deconfig -force flags on all but the last node.

    # perl rootcrs.pl -deconfig -force

  • If you are deconfiguring Oracle Clusterware on all nodes in the cluster, then on the last node add the –lastnode flag that completes deconfiguration on the cluster including the OCR and the voting disks.

    # perl rootcrs.pl -deconfig -force -lastnode

 

Deinstall Command for Oracle Clusterware and ASM

 

In Oracle 11gR2 binaries cannot be removed using the OUI. Instead Oracle provides deinstall utility. The deinstall utility removes the Oracle clusterware and ASM from the server. The deinstallation Tool (deinstall) stops Oracle software, and removes Oracle software and configuration files on the operating system. It is available in the installation media before installation, and is available in Oracle home directories after installation. It is located in the path $ORACLE_HOME/deinstall. You can use the Deinstallation Tool (deinstall) to remove failed or incomplete installations. It is available as a separate download from the Oracle Technology Network (OTN) Web site.

As the deinstall command runs, you are prompted to provide the home directory of the Oracle software that you want to remove from your system. Provide additional information as prompted. To run the deinstall command from an Oracle grid infrastructure for a cluster home, enter the following command.

$ cd /u01/app/11.2.0/grid/deinstall/ 
$ ./deinstall 

You can generate a deinstall parameter file by running the deinstall command using the -checkonly flag before you run the command to deinstall the home, or you can use the response file template and manually edit it to create the parameter file to use with the deinstall command.


August 12, 2010 Posted by | oracle | 8 Comments

MEMORY_TARGET not supported on this system ORA-00845

 MEMORY_TARGET not supported on this system – ORA-00845

Starting from Oracle 11g the automatic memory management feature is  defined with MEMORY_TARGET and MEMORY_MAX_TARGET parameters . The Automatic Memory Management (AMM) manages both SGA and PGA. The user specifies a value for MEMORY_TARGET and the max value that the parameter can grow is limited by MEMORY_MAX_TARGET. Once the MEMORY_TARGET is set Oracle determines the values for SGA_TARGET and PGA_AGGREGATE_TARGET. User does not need to set the above parameter values, instead can rely on Oracle to control those parameters value. Prior to Oracle 11g the user was responsible to set the SGA_TARGET and PGA_AGGRAGATE_TARGET. On Linux based systems the shared memory file system has to be mounted on /dev/shm. The MEMORY_MAX_TARGET need to be less than the shared memory mounted on /dev/shm. Make sure the shared memory filesystem is big enough for Automatic Memory Manager to work.

How to mount shared memory file system ? Execute as root.

# umount tmpfs
# mount -t tmpfs shmfs -o size=4500m /dev/shm

How to make the shared memory file system persistent across reboots?  Add an entry in /etc/fstab.

shmfs /dev/shm tmpfs size=4500m 0 

The ORA-00845 error usually appears if MEMORY_MAX_TARGET is set to a value greater or equal to the amount of memory allocated for /dev/shm.

Make sure that /dev/shm is mounted and there is sufficient memory for the shared memory file system to support AMM in Oracle.

Make sure that Oracle parameters MEMORY_MAX_TARGET, MEMORY_TARGET are less that the memory allocated to the shared memory file system in /dev/shm.

August 12, 2010 Posted by | oracle | 1 Comment