service的起停，要看START_DEPENDENCIES和STOP_DEPENDENCIES：
我们用如下命令建立一个service：
srvctl add service -d ora11g -s srv_di_1 -r node1 -a node2 -P basic -e SELECT -m basic -z 180 -w 5
我们具体看看这个service情况：
[oracle@rac1 ~]$ crsctl stat res ora.ora11g.srv_di_1.svc -p
NAME=ora.ora11g.srv_di_1.svc
TYPE=ora.service.type
ACL=owner:oracle:rwx,pgrp:oinstall:r--,other::r--,group:dba:r-x,group:oinstall:r-x,user:oracle:r-x
ACTION_FAILURE_TEMPLATE=
ACTION_SCRIPT=
ACTIVE_PLACEMENT=1
AGENT_FILENAME=%CRS_HOME%/bin/oraagent%CRS_EXE_SUFFIX%
AGENT_PARAMETERS=
AQ_HA_NOTIFICATION=0
AUTO_START=restore
CARDINALITY=1
CHECK_INTERVAL=600
CHECK_TIMEOUT=30
CLB_GOAL=LONG
DEFAULT_TEMPLATE=PROPERTY(RESOURCE_CLASS=service) PROPERTY(SERVICE_NAME=%GEN_SERVICE_NAME%) PROPERTY(DB_UNIQUE_NAME=CONCAT(PARSE(%NAME%, ., 2), STAT(ora.ora11g.db, USR_ORA_DOMAIN), .)) ELEMENT(INSTANCE_NAME=STAT(ora.ora11g.db, GEN_USR_ORA_INST_NAME))
DEGREE=1
DESCRIPTION=Oracle Service resource
DTP=0
EDITION=
ENABLED=1
FAILOVER_DELAY=5
FAILOVER_METHOD=BASIC
FAILOVER_RETRIES=180
FAILOVER_TYPE=SELECT
FAILURE_INTERVAL=0
FAILURE_THRESHOLD=0
GEN_SERVICE_NAME=srv_di_1
HOSTING_MEMBERS=
LOAD=1
LOGGING_LEVEL=1
MANAGEMENT_POLICY=AUTOMATIC
NLS_LANG=
NOT_RESTARTING_TEMPLATE=
OFFLINE_CHECK_INTERVAL=0
PLACEMENT=restricted
PROFILE_CHANGE_TEMPLATE=
RESTART_ATTEMPTS=0
RLB_GOAL=NONE
ROLE=PRIMARY
SCRIPT_TIMEOUT=60
SERVER_POOLS=ora.ora11g_srv_di_1
SERVICE_NAME=srv_di_1
START_DEPENDENCIES=hard(ora.ora11g.db,type:ora.cluster_vip_net1.type)
weak(type:ora.listener.type)
pullup(type:ora.cluster_vip_net1.type)
pullup:always(ora.ora11g.db)
START_TIMEOUT=600
STATE_CHANGE_TEMPLATE=
STOP_DEPENDENCIES=hard(intermediate:ora.ora11g.db,type:ora.cluster_vip_net1.type)
STOP_TIMEOUT=600
TAF_POLICY=BASIC
TYPE_VERSION=2.2
UPTIME_THRESHOLD=1h
USR_ORA_DISCONNECT=false
USR_ORA_ENV=
USR_ORA_FLAGS=
USR_ORA_OPEN_MODE=
USR_ORA_OPI=false
USR_ORA_STOP_MODE=
VERSION=11.2.0.4.0
[oracle@rac1 ~]$
可以看到，
（1）start的依赖：
硬依赖于DB是否启动和VIP类型的资源是否启动，
弱依赖于listener是否启动，
尝试重启在VIP资源已经online的情况下，
不管DB如何状态下，尝试重启。
（2）stop的依赖：
硬依赖，如果资源要保持启动的情况，必须DBd资源在intermedia的中间状态或者online状态，和VIP类型的资源online状态
注：start和stop的依赖关系的详细解释，参考这里的在线文档
所以我们讨论如下3种场景：
1. srvctl 来起停数据库
1.1 srvctl stop instance on node1
service stop on node1, not startup on node2
1.2 srvctl start instance on node1
service start on node 1
用srvctl停数据库，在crsctl stat res -t中看到数据库资源的offline的。不符合service start的条件硬依赖db资源必须online。所以在节点1上的service停了。
但是如果按照pullup的条件，资源会在节点2被拉起，此时没有被拉起，是因为11.2.0.2之后的srvctl stop instance多了一个-f的参数，只有指定这个参数停instance，service才会漂移到另一个节点上。参考下面2个文档：
11gR2 RAC Service Not Failing Over To Other Node When Instance Is Shut Down (Doc ID 1324574.1)
How to failover a service during instance shutdown using srvctl (Doc ID 1520454.1)
2. sqlplus
2.1 sqlplus shutdown immediate on node1
service relocate to node2
2.2 sqlplus startup on node1
service still running node2, need manual relocate the service
用sqlplus停数据库，在crsctl stat res -t中看到数据库资源的offline的。不符合service start的条件硬依赖db资源必须online。所以在节点1上的service停了。
按照pullup的条件，资源在节点2被拉起。
节点1再次被sqlplus拉起，但是由于service在节点2上不满足stop依赖，所以无法自动的漂移到重启启动的节点1上。
3. kill
3.1 kill db pmon process on node1
service relocate to node2
3.2 db instance restart by cluster
service still running node2, need manual relocate the service
用kill停数据库，在crsctl stat res -t中看到数据库资源的target是online的。但是state有一段时间变成offline，不符合service start的条件硬依赖db资源必须online。所以在节点1上的service停了。
按照pullup的条件，资源在节点2被拉起。
由于节点1上db的target是online，符合pullup的条件，所以db被自动拉起。但是由于service在节点2上不满足stop依赖，所以无法自动的漂移到重启启动的节点1上。