原文链接： http://www.dbaleet.org/shoug_share_session_introduction_of_exadata_core_processes/ Exadata存储服务器运行在Oracle Linux x86_64平台之上，所有的共享存储都放置在存储服务器上，除了操作系统以外，存储服务器上还使用了Exadata专有的存储管理软件。存储软件包括三大核心进程cellsrv， MS和RS。这三组进程的职责各有不同，各自都发挥着十分重要的作用。以下将逐一对这些进程进行介绍。

Cellsrv 进程

Cellsrv是Exadata存储服务器上最核心的一个进程，它是数据库服务器和存储服务器服务器之间的一座桥梁，用来处理所有的数据库服务器和存储服务器的之间的通讯。 Cellsrv通常包含以下功能： • 为简单的块请求提供服务。如果一个请求为单块读，则cellsrv将其转化为一个传统的高速缓存读取； • 为智能扫描（smart scan）提供服务，如果一个全表/全索引扫描的数据库请求中包含了direct path read，那么cellsrv则会执行与之相对应的smart scan。 • 如果使用了IORM， cellsrv对数据库服务器和存储服务器之间I/O带宽进行控制； • Cellsrv同时还会统计和收集各种与其操作相关的统计信息。  

Restart server 进程

  Restart server (RS)是CELLCLI命令行通过执行alter cell startup services rs 创建出来的子进程。正如其名所暗示的，它主要负责监控MS或者cellsrv等其它一些进程，它还能在其它进程崩溃或者存在内存泄漏的情况下自动完成这些进程的重启，并且不会对这些进程提供的服务可用性造成影响。在Exadata存储服务器上并不存在一个名为RS的进程，实际上RS的工作是由好几个进程共同来完成的。   如上图所示，虚线方框内的进程都是RS的组成部分，他们都以cellrs开头，如果是监控进程则会包含mt后缀。 其中 • cellrssrm为核心的RS进程 • cellrsbkm为备用的RS进程。 监控进程包括: • cellrssmt——核心主服务cellrssrm的监控进程 • cellrsbmt——备份服务cellrsbkm的监控进程 • cellrsomt——为cellsrv的监控进程，它会定时发起一种ioctl心跳消息以确认cellsrv是否存活，如果这个心跳丢失，则会创建一个adrci的时间保留现场以后，将其重启。cellsrv的状态信息存放在$OSSCONF/cellrsos.state文件内。 • cellrsmmt——为MS的监控进程。主要监控MS的http端口是否正常工作，另外监控MS的内存使用情况，确保其在正常范围以内。MS的状态信息存放在$OSSCONF/cellrsms.state文件中。 MS的告警日志信息与cellsrv的告警日志是都是存放在 $ADR_BASE/diag/asm/cell/<hostname>/trace/alert*.log里面。同时在这个trace目录下还能找到监控进程的trace文件，通常这类文件以名字中包含rstrc以标识为RS的trace文件。

Management server 进程

管理服务器 (MS) 主要提供 Exadata存储服务器配置的功能。很多人会以为CellCLI是Exadata存储服务器的配置工具，但是实际上CellCLI只是Exadata配置管理的一个客户端工具（grid control插件也是其中的一个客户端工具），真正的管理工作是由MS来完成的。MS的管理范围仅限于当前的存储服务器，如果需要管理多个存储服务器，则需要通过dcli工具对远程的存储服务器进行管理。除了CELLSRV收集的统计信息以外， MS也会收集其它的一些统计信息并且同时负责发送告警信息。此外MS进程负责存储服务器上的日志的删除（deletion）和轮换（rotation），删除和轮换的详细策略比较复杂，这里不一一列出，请参考Oracle Exadata Storage Server User’s Guide的Understanding Automated Cell Maintenance一节。 MS是一个OC4J的应用程序，它使用Oracle Diagnostic Logging(ODL)，其配置文件一般位于/opt/oracle/cell/oc4j/ms/j2ee/home/config/j2ee-logging.xml。MS程序标准输出设备stdout位于$LOG_HOME/ms.lst 标准的错误输出（stderr ）位于$LOG_HOME/ms.err，但是这两者对于诊断问题通常没有太大的帮助。 MS的log文件位于位于 $ADR_BASE/diag/asm/cell/<hostname>/trace/ms-odl.log，其trace文件位于: $ADR_BASE/diag/asm/cell/<hostname>/trace/ms-odl.trc，其中其单个文件最大大小限制为5MB，当文件大小达到5MB以上，会将自动为其加上.0, .1之类的后缀，并且会创建一个新的日志文件，当然文件上限数为10个，总大小为50MB。 MS输出的日志取决于其日志所在的tracelevel， 以下都是有效的MS日志的tracelevel： • Java logging level , 包括SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST，logging的级别依此递增。 • Oracle Diagnostic Logging (ODL) logging level 包括INCIDENT_ERROR:1, ERROR:1, WARNING:1, NOTIFICATION:1, NOTIFICATION:16, TRACE:1, TRACE:16, TRACE:32， logging级别也是一次递增 当前其默认的logging level为INFO。我们可以通过以下命令来修改ms的tracelevel： “cellcli -e alter cell tracelevel=finer” 修改完成以后cellinit.ora文件里面对应的条目会更新，但是需要重启MS服务新的tracelevel才能生效。可以通过命令list cell attributes all来查看当前的tracelevel。 另外值得一提的重要配置文件就是cell_disk_config.xml文件，此文件位于$OSSCONF目录，由MS进程进行管理，里面几乎包含了除告警和策略以外所有对象的配置。如果有对一个或者多个对象进行修改时，这个文件的内容就会被更新。同样cellsrv在启动和在某些情况下需要读取这个文件的内容。鉴于这个文件的重要性，在同一目录下还存在名称为cell_disk_config_xml_的文件，这些文件是cell_disk_config.xml的自动备份文件。这个配置文件有系统进行自动管理，请不要对其进行手工更新。

DSKM 进程

Diskmon是Exadata上的非常重要的一个基础进程，虽然从名字上来看，diskmon可能是负责对存储的磁盘进行监控，但是实际上其主要职责是负责监控Exadata存储服务器进程和存储网络，确保存储节点能够正常访问，如果存储服务器无法正常访问，CRS会向diskmon发出一个I/O fencing的请求，diskmon接收以后将其投递到存储服务器一端。Diskmon进程另外一个功能是将IORM plan推送到存储服务器一端。 diskmon个进程位于数据库服务器一端，属于Oracle CRS的一部分，在非Exadata的Oracle集群环境下，这个进程并没有使用到。例如在11.2.0.3以前，这个进程是启动的，但是没有完成任何实质性工作，在11.2.0.3以后，这个资源默认就是是offline的。在Exadata上，每台数据库服务器上都存在1个主（master）diskmon进程(名称为diskmon.bin)，而每个数据库实例都存在1个从（slave） diskmon进程(名称为ora_diskm_sid)，主进程监视并将状态信息推送给从属进程。从进程使用 SGA 与 RDBMS或者ASM 进程进行通讯。 Diskmon进程的日志位于$CRS_HOME/log/hostname/diskmon目录。但是diskmon的日志文件通常对于诊断问题帮助不大，只有在极为特殊的情况下，Oracle的support才会要求提供diskmon的信息。

小结

通过对Exadata的核心进程的介绍，我们了解了各个进程所负责完成的工作，其架构及运行机制，这一部分信息是诊断Exadata Storagetroubleshooting的过程中是至关重要的一环节。