Exadata Software - Oracle Exadata Recipes: A Problem-Solution Approach - page 40

completed
CRS-4133: Oracle High Availability Services has been stopped.
[root@cm01dbm01 ~]#

To start your cluster resources, run the command on each compute node:

[root@cm01dbm01 ~]# /u01/app/11.2.0.3/grid/bin/crsctl start crs
CRS-4123: Oracle High Availability Services has been started.
[root@cm01dbm01 ~]#

How It Works
Exadata compute server nodes run Oracle Enterprise Edition 11gR2 Grid Infrastructure to facilitate and manage
databases and other resources or processes across the compute grid. From a technical perspective, the installation,
configuration, and administration of Grid Infrastructure on Exadata is identical to Grid Infrastructure on non-Exadata
systems. Generally speaking, most companies segregate ownership of processes and software by running the Grid
Infrastructure components with a different Linux account than the account that owns the Oracle 11gR2 RDBMS
software and database instances, but this is not required.
An administrator manages Grid Infrastructure components the same way he or she would on a non-Exadata
11gR2 Grid Infrastructure environment. This is a key benefit of Exadata from an operational labor standpoint; if you
have Oracle administrators who understand and are trained on Oracle 11gR2, Grid Infrastructure, and Oracle Real
Application Clusters, you should be well-prepared to confidently manage your Oracle Exadata compute infrastructure.
On Exadata, Oracle has elected to store the Oracle Cluster Registry (OCR) and voting disks on Oracle ASM disk
groups, mapped to Exadata storage server grid disks. Most processes in Exadata's Oracle 11gR2 Grid infrastructure
perform the same functions as non-Exadata 11gR2 installations, but one software component that plays a special role
in Exadata environments is the diskmon process and associated processes:

[root@cm01dbm01 ~]# ps -ef|egrep '(diskmon|dsk)'
root 884 23558 0 11:09 pts/0 00:00:00 egrep (diskmon|dsk)
grid 20500 1 0 Jul27 ? 00:01:00 /u01/app/11.2.0.3/grid/bin/diskmon.bin -d -f
grid 21408 1 0 Jul27 ? 00:00:00 asm_dskm_+ASM1
oracle 22179 1 0 Jul27 ? 00:00:01 ora_dskm_visx1
oracle 22217 1 0 Jul27 ? 00:00:01 ora_dskm_dwprd1
oracle 31932 1 0 Jul28 ? 00:00:00 ora_dskm_visy1
[root@cm01dbm01 ~]#

diskmon itself runs on all Oracle 11gR2 installations, but it only serves a true purpose on Exadata. Its role is to monitor
storage network and cell monitoring processes, validate that the storage cells are alive, handle storage failures and I/O
fencing, monitor and control messages from database and ASM instances to storage cells, and send database resource
management plans to storage servers. In addition to the master diskmon process, each database instance on the
compute nodes run a single ora_dskm slave process as previously displayed.
Along with diskmon , two additional ASM processes perform a role on the Exadata compute servers: xdmg and xdwk :
•

XDMG monitors configured Exadata storage cells for storage state changes and performs
whatever events are required with ASM disks based on these state changes.

•

XDWK is started whenever state changes take place, such as when ASM disk DROP, ADD, or
ONLINE operations are performed. It runs asynchronously and shuts down automatically
after a period of inactivity.

You can see the xdmg and xdwk processes running on an Exadata compute nodes during a time after a cell server's
grid disks are inactivated and subsequently activated: