Please see my other blog for Oracle EBusiness Suite Posts - EBMentors

Search This Blog

Note: All the posts are based on practical approach avoiding lengthy theory. All have been tested on some development servers. Please don’t test any post on production servers until you are sure.

Wednesday, October 30, 2013

Exadata: What differentiates GI on Exadata with GI on non-Exadata?

The installation,configuration, and administration of Grid Infrastructure on Exadata is identical to Grid Infrastructure on non-Exadata systems. 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@exadb ~]# ps -ef|egrep '(diskmon|dsk)'
oracle    2931     1  0 17:46 ?        00:00:00 /u01/app/oracle/product/11.2.0/grid/bin/diskmon.bin -d -f
oracle    3369     1  0 17:48 ?        00:00:00 asm_dskm_+ASM
oracle    3529     1  0 17:50 ?        00:00:00 ora_dskm_exadb
root      4109  3232  0 18:08 pts/1    00:00:00 egrep (diskmon|dsk)

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 also.

Along with diskmon, two additional ASM processes perform a role on the Exadata DB 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.

[root@exadb ~]# ps -ef|grep -i xd|grep -v grep
oracle    3413     1  0 17:48 ?        00:00:00 asm_xdmg_+ASM

No comments: