metalink下的几个关于10g rac的文档

metalink下的几个关于10g rac的文档

 

http://www.itpub.net/thread-1079909-1-1.html

http://www.itpub.net/660105.html

For Linux x86 : Metalink Note 419646.1
For Linux x86_64: Metalink Note 421308.1

239998.1   how to clean up after a failed crs install
298073.1   how to remove crs auto start and restart for a rac instance
295871.1   how to verify is crs install is valid
263897.1   how to stop the cluster ready service

Subject:  10g RAC: How to Clean Up After a Failed CRS Install 
  Doc ID:  Note:239998.1 Type:  BULLETIN 
  Last Revision Date:  24-AUG-2006 Status:  PUBLISHED 


PURPOSE
-------

The purpose of this document is to help DBA's and support analysts understand how
to clean up a failed CRS (Cluster Ready Services) install for 10g RAC.


SCOPE & APPLICATION
-------------------

DBA's and Support Analysts


10g RAC: How to Clean Up After a Failed CRS Install
---------------------------------------------------

Not cleaning up a failed CRS install can cause problems like node reboots.
Follow these steps to clean up a failed CRS install:

1. Run the rootdelete.sh script. then the rootdeinstall.sh script. from the 
$ORA_CRS_HOME/install directory.  Running these scripts should be sufficent
to clean up your CRS install.  If you have any problems with these scripts 
please open a service request.  

If for some reason you have to manually remove the install due to problems
with the scripts, continue to step 2:

2. Stop the Nodeapps on all nodes:

        srvctl stop nodeapps -n

3. Prevent CRS from starting when the node boots.  To do this issue the following
as root:

Sun:

        rm /etc/init.d/init.cssd 
        rm /etc/init.d/init.crs 
        rm /etc/init.d/init.crsd 
        rm /etc/init.d/init.evmd 
        rm /etc/rc3.d/K96init.crs
        rm /etc/rc3.d/S96init.crs
        rm -Rf /var/opt/oracle/scls_scr 
        rm -Rf /var/opt/oracle/oprocd
        rm /etc/inittab.crs 
        cp /etc/inittab.orig /etc/inittab

Linux:

        rm -f /etc/init.d/init.cssd 
        rm -f /etc/init.d/init.crs 
        rm -f /etc/init.d/init.crsd 
        rm -f /etc/init.d/init.evmd 
        rm -f /etc/rc2.d/K96init.crs
        rm -f /etc/rc2.d/S96init.crs
        rm -f /etc/rc3.d/K96init.crs
        rm -f /etc/rc3.d/S96init.crs
        rm -f /etc/rc5.d/K96init.crs
        rm -f /etc/rc5.d/S96init.crs
        rm -Rf /etc/oracle/scls_scr
        rm -f /etc/inittab.crs 
        cp /etc/inittab.orig /etc/inittab

HP-UX:

        rm /sbin/init.d/init.cssd 
        rm /sbin/init.d/init.crs 
        rm /sbin/init.d/init.crsd 
        rm /sbin/init.d/init.evmd 
        rm /sbin/rc2.d/K960init.crs
        rm /sbin/rc2.d/K001init.crs
        rm /sbin/rc3.d/K960init.crs
        rm /sbin/rc3.d/S960init.crs
        rm -Rf /var/opt/oracle/scls_scr 
        rm -Rf /var/opt/oracle/oprocd
        rm /etc/inittab.crs 
        cp /etc/inittab.orig /etc/inittab

HP Tru64:

        rm /sbin/init.d/init.cssd 
        rm /sbin/init.d/init.crs 
        rm /sbin/init.d/init.crsd 
        rm /sbin/init.d/init.evmd 
        rm /sbin/rc3.d/K96init.crs
        rm /sbin/rc3.d/S96init.crs
        rm -Rf /var/opt/oracle/scls_scr 
        rm -Rf /var/opt/oracle/oprocd
        rm /etc/inittab.crs 
        cp /etc/inittab.orig /etc/inittab

IBM AIX:

        rm /etc/init.cssd 
        rm /etc/init.crs 
        rm /etc/init.crsd 
        rm /etc/init.evmd 
        rm /etc/rc.d/rc2.d/K96init.crs
        rm /etc/rc.d/rc2.d/S96init.crs
        rm -Rf /etc/oracle/scls_scr
        rm -Rf /etc/oracle/oprocd
        rm /etc/inittab.crs 
        cp /etc/inittab.orig /etc/inittab

4. If they are not already down, kill off EVM, CRS, and CSS processes or reboot
   the node:

        ps -ef | grep crs        
        kill
        ps -ef | grep evm
        kill
        ps -ef | grep css        
        kill

   Do not kill any OS processes, for example icssvr_daemon process !

5. If there is no other Oracle software running (like listeners, DB's, etc...), 
   you can remove the files in /var/tmp/.oracle or /tmp/.oracle.  Example:

        rm -f /var/tmp/.oracle

        or

        rm -f /tmp/.oracle

6. Remove the ocr.loc 
   Usually the ocr.loc can be found at /etc/oracle

7. De-install the CRS home in the Oracle Universal Installer

8. Remove the CRS install location:

          rm -Rf /*

9. Clean out the OCR and Voting Files with dd commands.  Example:

        dd if=/dev/zero f=/dev/rdsk/V1064_vote_01_20m.dbf bs=8192 count=2560
        dd if=/dev/zero f=/dev/rdsk/ocrV1064_100m.ora bs=8192 count=12800

   If you placed the OCR and voting disk on a shared filesystem, remove them.

   If you are removing the RDBMS installation, also clean out any ASM disks if 
   they have already been used.

10.If you would like to re-install CRS, follow the steps in the RAC Installation manual.

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

Subject:  HOW TO REMOVE CRS AUTO START AND RESTART FOR A RAC INSTANCE 
  Doc ID:  Note:298073.1 Type:  BULLETIN 
  Last Revision Date:  13-MAY-2005 Status:  PUBLISHED 


***
This article is being delivered in Draft form. and may contain
errors.  Please use the MetaLink "Feedback" button to advise
Oracle of any issues related to this article.
***

PURPOSE
-------

HOW TO REMOVE CRS AUTO START AND RESTART FOR A RAC INSTANCE 
with Oracle Database 10g (10.1.0.4)


SCOPE & APPLICATION
-------------------
Anyone with an RAC Database using Oracle Clusterware (CRS) and 
Oracle Database 10g.  You must be at 10.1.0.4.


HOW TO REMOVE CRS AUTO START AND RESTART FOR A RAC INSTANCE
-----------------------------------------------------------

OVERVIEW
Oracle Clusterware (CRS) is a new feature of Oracle Database 10g Real 
Application Clusters that further differentiates RAC for high availability and 
scalability. CRS provides automated management and sophisticated monitoring of
RAC instances and is designed to enhance the overall user experience of cluster
database management. 
By default, CRS is configured to auto-start database instances as a part of node
boot and provide lights-out instance failure detection followed by an 
auto-restart of the failed instance. However, on some special occasions, 
it might be highly desirable to limit the level of protection CRS provides 
for a RAC database. Namely, this implies preventing instances from auto-starting
on boot and not auto-restarting failed instances.  The latter, however, may be
relaxed to allow a single attempt to restart a failed instance. This way, CRS 
will attempt to restore availability of the instance, but avoid thrashing if a 
problem that caused the instance to fail also keeps preventing it from 
successfully recovering on restart. Either way, the choice to customize this is 
left to the DBA.
Oracle Database 10g Real Application Clusters release 10.1.0.4 and above make 
it possible to accomplish the above stated change in CRS behavior. This document
lists the steps necessary to limit the level of CRS protection over a RAC 
database.
HIGH LEVEL APPROACH
In a nutshell, the procedure amounts to the following two parts
  1. Identifying a set of CRS resources that affect the behavior 
  2. Modifying a few profile attributes to contain special values for the 
resources identified in the first step

The following sections will cover both phases in detail.
IDENTIFYING RELEVANT RESOURCES
The automated management of a RAC database is accomplished by modeling various 
RAC applications/features as CRS resources. A CRS resource is defined by a 
profile, which contains a list of attributes that tell CRS how manage the 
resource.  CRS resources created to manage a RAC database can be identified as 
belonging to a well-known type. There is a finite and relatively small number 
of types. The type may be easily identified given the name of a resource: each 
name ends with a . For instance, ora.linux.db is of type db, 
which happens to mean database. To display the names of the resources managed 
by the CRS, use the crs_stat command from a clustered node.  The output of the 
command is a set of names and states of resources registered on the cluster to 
which the node belongs.

Figure 1. Example Listing resource names using crs_stat
$ crs_stat
NAME=ora.linux.ar.us.oracle.com.cs
TYPE=application
TARGET=OFFLINE
STATE=OFFLINE

NAME=ora.linux.ar.us.oracle.com.linux.srv
TYPE=application
TARGET=OFFLINE
STATE=OFFLINE

Additional output is available but has been truncated for clarity's sake


The relevant resources are the resources that belong to the following 4 types: 

  db - Denotes resources that represent a database
  srv -Denotes resources that represent a service member.
  cs - Denotes resources that represent a service.
  inst - Denotes resources that represent a database instance

The CRS profiles for these resources must be modified for the new CRS behavior 
to take effect for all RAC databases installed on the cluster. If, however, 
the affect of the change is to be limited to a subset of installed databases, 
the list of resources needs to be filtered further. (The rest of this section 
should be skipped if the new CRS behavior. is to be in effect for all databases 
installed on the cluster.)
Please note that since more than one database may be installed on a cluster, 
to modify the level of protection for a particular database, one must identify 
the resources that represent entities of this database. This may be easily 
accomplished since the names of the resources belonging to the above- stated 
types always start with ora..  For instance, ora.linux.db 
means that the resource belongs to the database named linux.  Only resources of 
the above-enumerated types that belong to the selected databases will need to 
have their profiles modified. 
MODIFYING RESOURCE PROFILES
Please note that Oracle strongly discourages any modifications made to CRS 
profiles for any resources starting with . Never make any modifications to 
CRS profiles for resources but the ones explicitly described below in 
this document. 

To modify a profile attribute for a resource, the following steps must be 
followed:
  1.Generate the resource profile file by issuing the following command: 
        crs_stat -p resource_name > $CRS_HOME/crs/public/resource_name.cap

  2.Update desired attributes by editing the file created in step 1.

  3.Commit the updates made as a part of the previous step by issuing the 
    following command
        crs_register -u resource_name

  4.  Verify the updates have been committed by issuing the following command 
        crs_stat -p resource_name

For each of the resources identified as a part of the preceding section, the 
following modifications must be made:
  1.Resources of type inst must have the following attributes modified
        AUTO_START must be set to 2
        RESTART_ATTEMPTS must be set to 0 or 1. The former value will prevent 
    CRS from attempting to restart a failed instance at all while the latter
    will grant it a single attempt; if this only attempt is unsuccessful, 
    CRS will leave the instance as is.
  2.Resources of type db, srv,  cs must have the following attributes modified
    AUTO_START must be set to 2

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

Subject:  How to verify if CRS install is Valid 
  Doc ID:  Note:295871.1 Type:  HOWTO 
  Last Revision Date:  08-FEB-2006 Status:  PUBLISHED 

In this Document
  Goal
  Solution



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



Applies to: Oracle Server - Enterprise Edition - Version: 10.1.0.2.0 to 10.2.0
Information in this document applies to any platform.
Oracle CRS GoalThe goal of this document is to document the steps to confirm if the CRS install is valid SolutionYou have completed the CRS install. Now you want to verify if the install is valid.

To Ensure that the CRS install on all the nodes is valid, the following should be checked on all the nodes.

Ensure that you have successfully completed running root.sh on all nodes during the install. (Please do not re-run root.sh, this is very dangerous and might corrupt your installation, The object of this step is to only confirm if the root.sh was run  successfully after the install 
Run the command $ORA_CRS_HOME/bin/crs_stat. Please ensure that this command does not error out but dumps the information for each resource. It does not matter what CRS stat returns for each resource. If the crs_stat exits after printing information about each resource then it means that the CRSD daemon is up and  the client crs_stat utility can communicate with it.  This will also indicate that the CRSD can read the OCR. If the crs_stat errors out with CRS-0202: No resources are registered, Then this means that there are no resources registered. This is not an error but is mostly seen on systems when the rdbms software has not yet been installed in the ORACLE_HOME. 
Run the command $ORA_CRS_HOME/bin/olsnodes. This should return all the nodes of the cluster. Successful run of this command would mean that the css is up and running. Also the CSS from each node can talk to the CSS of other nodes. 
Output of crsctl check css returns "CSS daemon appears healthy" 
Additionally in 10gR2 crsctl check command can be run 

For E.g crsctl check crs

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

Subject:  10G: How to Stop the Cluster Ready Services (CRS) 
  Doc ID:  Note:263897.1 Type:  HOWTO 
  Last Revision Date:  29-MAR-2005 Status:  MODERATED 

This document is being delivered to you via Oracle Support's Rapid Visibility (RaV) Rapid Visibility (RaV) process, and therefore has not been subject to an independent technical review.  



The information in this document applies to: 
Oracle Server - Enterprise Edition - Version: 10.1 to 10.2
Information in this document applies to any platform.

Goal
This article will explain how you need to stop the Cluster Ready Services (CRS) which is new in Oracle 10g. 
Fix
1) First make sure you stop the RAC instance in your cluster environment.
This can be done as the ORACLE owner using the SRVCTL utility. (Server Control Utility)

example: 
srvctl stop instance -i -d 
srvctl stop nodeapp -n 
srvctl stop nodeapp -n 


2) When all your instances are stopped you need to logon as ROOT, the CRS processes need to be stopped as root. 

$ /sbin/init q 
$ /etc/init.d/init.crs stop

Now your Cluster Ready Service will stop.

/sbin/init q : This will re-examen the inittab and check if at the current runlevel process are not running ,if this is the case they will be started again. 
/etc/init.d/init.crs stop : This will stop the following deamons in this order, CRSD, CSSD and EVMD.

If you try to Kill the processes you will notice that the process will reappear. Or a system reboot will take place. So this is not an option you can use.
If you don't want to start the processes after system reboot, there is a disable option.
$ /etc/init.d/init.crs disable

After a system reboot the CRS processes will not start, this can be useful for maintenance, but starting in another runlevel is an option then too instead of disable..

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/611609/viewspace-670750/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/611609/viewspace-670750/