Cluster startup order
Here is some interesting info in a nutshell on Startup order of Oracle Clusterware :
Key
ASM does not depend on CRS to start. ASM depends on Voting Disk which is accessed directly on Lun (without ASM).
Startup Sequence
init -> OHAS (OLR) -> CSSD/ASM (access ASMDISK/LUN and read Voting Disks) -> CRSD (open DISKGROUP and read OCR)
There are many improvements in version 11.2.
When Clusterware starts three files are involved.
OLR - Is the first file to be read and opened. This file is local and this file contains information regarding where the voting disk is stored and information to startup the ASM. (e.g ASM DiscoveryString)
VOTING DISK - This is the second file to be opened and read, this is dependent on only OLR being accessible.
ASM starts after CSSD or ASM does not start if CSSD is offline (i.e voting file missing)
How are Voting Disks stored in ASM?
Voting disks are placed directly on ASMDISK. Oracle Clusterware will store the votedisk on the disk within a disk group that holds the Voting Files.
Oracle Clusterware does not rely on ASM to access the Voting Files, which means Oracle Clusterware does not need of Diskgroup to read and write on ASMDISK. It is possible to check for existence of voting files on a ASMDISK using the V$ASM_DISK column VOTING_FILE.
So, voting files not depend of Diskgroup to be accessed, does not mean that the diskgroup is not needed, diskgroup and voting file are linked by their settings.
OCR - Finally the ASM Instance starts and mount all Diskgroups, then Clusterware Deamon (CRSD) opens and reads the OCR which is stored on Diskgroup.
So, if ASM already started, ASM does not depend on OCR or OLR to be online. ASM depends on CSSD (Votedisk) to be online.
There is a exclusive mode to start ASM without CSSD (but it's to restore OCR or VOTE purposes)
Key
ASM does not depend on CRS to start. ASM depends on Voting Disk which is accessed directly on Lun (without ASM).
Startup Sequence
init -> OHAS (OLR) -> CSSD/ASM (access ASMDISK/LUN and read Voting Disks) -> CRSD (open DISKGROUP and read OCR)
There are many improvements in version 11.2.
When Clusterware starts three files are involved.
OLR - Is the first file to be read and opened. This file is local and this file contains information regarding where the voting disk is stored and information to startup the ASM. (e.g ASM DiscoveryString)
VOTING DISK - This is the second file to be opened and read, this is dependent on only OLR being accessible.
ASM starts after CSSD or ASM does not start if CSSD is offline (i.e voting file missing)
How are Voting Disks stored in ASM?
Voting disks are placed directly on ASMDISK. Oracle Clusterware will store the votedisk on the disk within a disk group that holds the Voting Files.
Oracle Clusterware does not rely on ASM to access the Voting Files, which means Oracle Clusterware does not need of Diskgroup to read and write on ASMDISK. It is possible to check for existence of voting files on a ASMDISK using the V$ASM_DISK column VOTING_FILE.
So, voting files not depend of Diskgroup to be accessed, does not mean that the diskgroup is not needed, diskgroup and voting file are linked by their settings.
OCR - Finally the ASM Instance starts and mount all Diskgroups, then Clusterware Deamon (CRSD) opens and reads the OCR which is stored on Diskgroup.
So, if ASM already started, ASM does not depend on OCR or OLR to be online. ASM depends on CSSD (Votedisk) to be online.
There is a exclusive mode to start ASM without CSSD (but it's to restore OCR or VOTE purposes)
This description is also from the MOS note stated above
Short summary of the startup sequence: INIT spawns init.ohasd (with respawn) which in turn starts the OHASD process (Oracle High Availability Services Daemon). This daemon spawns 4 processes.
Level 1: OHASD Spawns:
cssdagent - Agent responsible for spawning CSSD.
orarootagent - Agent responsible for managing all root owned ohasd resources.
oraagent - Agent responsible for managing all oracle owned ohasd resources.
cssdmonitor - Monitors CSSD and node health (along wth the cssdagent).
Level 2: OHASD rootagent spawns:
CSDD (ora.cssd) - Cluster Synchronization Services
CRSD(ora.crsd) - Primary daemon responsible for managing cluster resources.
CTSSD(ora.ctssd) - Cluster Time Synchronization Services Daemon
Diskmon(ora.diskmon)
ACFS (ASM Cluster File System) Drivers
Level 2: OHASD oraagent spawns:
MDNSD(ora.mdnsd) - Used for DNS lookup
GIPCD(ora.gipcd) - Used for inter-process and inter-node communication
GPNPD(ora.gpnpd) - Grid Plug & Play Profile Daemon
EVMD(ora.evmd) - Event Monitor Daemon
ASM(ora.asm) - Resource for monitoring ASM instances
Level 3: CRSD spawns:
orarootagent - Agent responsible for managing all root owned crsd resources.
oraagent - Agent responsible for managing all oracle owned crsd resources.
Level 4: CRSD rootagent spawns:
Network resource - To monitor the public network
SCAN VIP(s) - Single Client Access Name Virtual IPs
Node VIPs - One per node
ACFS Registery - For mounting ASM Cluster File System
GNS VIP (optional) - VIP for GNS
Level 4: CRSD oraagent spawns:
ASM Resouce - ASM Instance(s) resource
Diskgroup - Used for managing/monitoring ASM diskgroups.
DB Resource - Used for monitoring and managing the DB and instances
SCAN Listener - Listener for single client access name, listening on SCAN VIP
Listener - Node listener listening on the Node VIP
Services - Used for monitoring and managing services
ONS - Oracle Notification Service
eONS - Enhanced Oracle Notification Service
GSD - For 9i backward compatibility
GNS (optional) - Grid Naming Service - Performs name resolution