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 <resource_type>. 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.<database name>. 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 <ora>. Never make any modifications to
CRS profiles for <ora> 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
参考至:http://jingh3209.blog.163.com/blog/static/15696672008101612013898/
如有错误,欢迎指正
邮箱:czmcj@163.com
相关推荐
ORACLE RAC 可能会偶尔碰到CRS 启动的问题,这些问题可以通过查看相关日志,诸如 crsd.log,alertrac.log 等,来修正相关问题,并可以使用crs_register,crs_unregister,crs_profile 来重新注册OCR 信息。 但是有时候...
oracle RAC crs常用命令,还是比较全的啦
rac crs error example messages
Oracle RAC集群之Oracle CRS的管理与维护.pdf 学习资料 复习资料 教学资源
oracle rac 安装失败删除 crs配置,分别在sum,Linux,HP-UX,HP Tru64,IBM AIX...
Oracle_RAC_CRS、OCR、Voting破坏重建
oracle 10g rac的crs命令很多人用的时候总是忘记,我整理了一下,相信对很多dba有用
vmware + 裸设备 + crs + oracle10g RAC搭建步骤
解决在WINDOWS 2003 R2上不能安装RAC的方法CRS 10.2.0.2 error on windows 2003
1,Oracle19c RAC+ RACDG配置详细部署文档 2,Oracle19c RAC+ RACDG+racdg2配置详细部署文档 涉及主库备库参数配置、spfile、crs资源配置更新及实施过程中故障排除等; 来自于现实上亿级生产系统的实操记录。
安装RAC集群,首先要创建虚拟机共享磁盘,然后分区,挂载裸设备和进行ASM分区,然后安装Oracle集群服务CRS,最后安装Oracle10g. 由于篇幅所限,本文档去除了所有图片。如需所要,请评论 ORACLE10g RAC FOR SUSE ...
CRS-003482-01-A EMC 存储8.2
CRS-003485-01-A_8.2 license模型
vmware-vdiskmanager -c -s 10Gb -a lsilogic -t 3 "F:\rac\share.vmdk" 在vmx文件里面添加如下行,并在vmware setting里面吧磁盘分别加到两个节点上面 scsi0:1.present = "TRUE" scsi0:1.virtualDev = "lsilogic...
此文档用来讲述将goldengate注册到crs服务
Oracle 10G RAC 日常管理 CRS的管理 CRSCTL命令控制着本地节点的CRS服务(Oracle clusterware processes) SRVCTL命令介绍 SRVCTL命令可以控制RAC数据库中的instance,listener以及services。
Copy the file with .scr extension to your computers win directory (Windows for 98, Winnt for NT) and check in screens saver settings.<END><br>73,Cls_sample_Collection.zip Implement with Class and ...
对Oracle集群模式下RAC资源的管理、配置,节点增删改、启停等操作指引
Advanced_RAC_troubleshooting Advanced_RAC_troubleshooting
教程名称:Oracle RAC数据库集群视频教程(10讲)课程目录:【】1.OracleRAC集群体系结构_drm...安装OracleRAC数据库(三)【】5.OracleCRS的管理与维护_drm 资源太大,传百度网盘了,链接在附件中,有需要的同学自取。