Oracle Exadata: Procesos de Exadata Storage Server

Por Karan Dodwal, Joel Pérez O ACE director& César Aguilar
Publicado en Octubre 2017


Oracle Exadata Storage Server es un servidor de almacenamiento inteligente que proporciona muchas capacidades de descarga en Exadata.

Exadata Storage Server es un servidor de almacenamiento altamente optimizado que ejecuta el Oracle Exadata Storage Server Software para almacenar y acceder a los datos de la base de datos Oracle. Con los sistemas de almacenamiento tradicionales, los datos se transfieren a los nodos de cálculo para su procesamiento sin ninguna capacidad inteligente. Con las funciones como exploración inteligente, índices de almacenamiento, compresión híbrida en las columnas y otras características, Storage Server proporciona una solución completa en la que el cliente no tiene que comprar subsistemas de almacenamiento de otros proveedores.

Oracle proporciona una solución completa de almacenamiento para la base de datos a través del Exadata Storage Server.

Oracle Exadata Storage Server procesa datos a nivel de almacenamiento y transmite sólo lo que se necesita al servidor de base de datos. Hay algunos procesos en el Storage Server que ayudan a facilitar estas características, en este artículo veremos esos procesos y entenderemos su función y las características que proporcionan en Exadata Storage Server.

Exadata Storage Server tiene los siguientes procesos principales: -

  1. RS Process
  2. CELLSRV Process
  3. MS Process

RS Process

El proceso RS, es responsable de monitorear y reiniciar MS y CELLSRV. Si estos procesos no responden, es el proceso RS que los reinicia. Este es el proceso principal inicial y la funcionalidad del proceso RS es dada por Cellrssrm, el proceso Cellrsrm lanza 3 procesos auxiliares que son cellrsomt, cellrsbmt y cellrsmmt. Veamos como estos procesos se ven en el Storage Server.

[root@cell ~]# ps -ef |grep cellrssrm
root      3698     1  0 13:42 ?        00:00:00 
/opt/oracle/cell12.1.1.1.1_LINUX.X64_140712/cellsrv/bin/cellrssrm -ms 1 -cellsrv 1 root 4159 4104 0 13:45 pts/0 00:00:00 grep cellrssrm

En la pantalla anterior podemos observar el id del proceso de cellrssrm es 3698


[root@cell ~]# ps -ef |grep cellrsomt 
root      3707  3698  1 13:42 ?        00:00:03
/opt/oracle/cell12.1.1.1.1_LINUX.X64_140712/cellsrv/bin/cellrsomt -rs_conf
/opt/oracle/cell12.1.1.1.1_LINUX.X64_140712/cellsrv/deploy/config/cellinit.ora -ms_conf
/opt/oracle/cell12.1.1.1.1_LINUX.X64_140712/cellsrv/deploy/config/cellrsms.state -cellsrv_conf
/opt/oracle/cell12.1.1.1.1_LINUX.X64_140712/cellsrv/deploy/config/cellrsos.state -debug 0 root 4190 4104 0 13:46 pts/0 00:00:00 grep cellrsomt

Ahora en la pantalla anterior el id del proceso padre de cellrsomt es 3698, esto significa que cellrsomt es lanzado por cellrssrm


[root@cell ~]# ps -ef |grep cellrsbmt
root      3705  3698  0 13:42 ?        00:00:00
/opt/oracle/cell12.1.1.1.1_LINUX.X64_140712/cellsrv/bin/cellrsbmt -rs_conf
/opt/oracle/cell12.1.1.1.1_LINUX.X64_140712/cellsrv/deploy/config/cellinit.ora -ms_conf
/opt/oracle/cell12.1.1.1.1_LINUX.X64_140712/cellsrv/deploy/config/cellrsms.state -cellsrv_conf
/opt/oracle/cell12.1.1.1.1_LINUX.X64_140712/cellsrv/deploy/config/cellrsos.state -debug 0 root 4205 4104 0 13:47 pts/0 00:00:00 grep cellrsbmt

También se nota en la pantalla anterior el id de proceso padre de cellrsbmt es 3698 que significa cellrsbmt también se inicia por cellrssrm


[root@cell ~]# ps -ef |grep cellrsmmt 
root      3706  3698  0 13:42 ?        00:00:00
/opt/oracle/cell12.1.1.1.1_LINUX.X64_140712/cellsrv/bin/cellrsmmt -rs_conf
/opt/oracle/cell12.1.1.1.1_LINUX.X64_140712/cellsrv/deploy/config/cellinit.ora -ms_conf
/opt/oracle/cell12.1.1.1.1_LINUX.X64_140712/cellsrv/deploy/config/cellrsms.state -cellsrv_conf
/opt/oracle/cell12.1.1.1.1_LINUX.X64_140712/cellsrv/deploy/config/cellrsos.state -debug 0 root 4219 4104 0 13:47 pts/0 00:00:00 grep cellrsmmt

Por último, se observa que el proceso padre id de cellrsmmt es también 3698, lo que significa que cellrsmmt también es lanzado por cellrssrm


Con los ejemplos anteriores nos podemos dar cuenta que estos son los 3 procesos de ayuda iniciados por Cellrssrm que es el proceso RS real.


MS Process

El proceso de servidor de administración (MS) realmente realiza la descarga de métricas en el disco. El proceso MS recibe los datos de métricas de CELLSRV, mantiene un subconjunto de métricas en la memoria y escribe en un repositorio interno basado en disco cada hora. Como parte de su otra responsabilidad, el proceso de MS puede generar alertas para eventos importantes de hardware o software de celdas de almacenamiento.

[root@cell ~]# ps -ef |grep cellrsmmt 
root      3706  3698  0 13:42 ?        00:00:00
/opt/oracle/cell12.1.1.1.1_LINUX.X64_140712/cellsrv/bin/cellrsmmt -rs_conf
/opt/oracle/cell12.1.1.1.1_LINUX.X64_140712/cellsrv/deploy/config/cellinit.ora -ms_conf
/opt/oracle/cell12.1.1.1.1_LINUX.X64_140712/cellsrv/deploy/config/cellrsms.state -cellsrv_conf
/opt/oracle/cell12.1.1.1.1_LINUX.X64_140712/cellsrv/deploy/config/cellrsos.state -debug 0 root 4236 4104 0 13:48 pts/0 00:00:00 grep cellrsmmt [root@cell ~]# [root@cell ~]# ps -ef |grep ms.err root 3712 3706 4 13:42 ? 00:00:14 /usr/java/default/bin/java -Xms256m -Xmx512m
-XX:-UseLargePages -Djava.library.path=/opt/oracle/cell12.1.1.1.1_LINUX.X64_140712/cellsrv/lib
-Ddisable.checkForUpdate=true -jar
/opt/oracle/cell12.1.1.1.1_LINUX.X64_140712/oc4j/ms/j2ee/home/oc4j.jar -out
/opt/oracle/cell12.1.1.1.1_LINUX.X64_140712/cellsrv/deploy/log/ms.lst -err
/opt/oracle/cell12.1.1.1.1_LINUX.X64_140712/cellsrv/deploy/log/ms.err root 4238 4104 0 13:48 pts/0 00:00:00 grep ms.err

En la pantalla anterior se observa que el proceso MS es iniciado por cellrsmmt, como el proceso padre de 3712 es 3706, donde el proceso 3706 es cellrsmmt.


CELLSRV: En los servidores de almacenamiento, el proceso CELLSRV recibe la información de predicado del servidor de BD a través del protocolo iDB para proporcionar servicios como el escaneado inteligente. El proceso CELLSRV proporciona la mayoría de los servicios de almacenamiento de Oracle Exadata y es el componente principal del software de almacenamiento. Una de sus funciones es procesar, recopilar y almacenar métricas.

[root@cell ~]# ps -ef |grep "/cellsrv " 
root      3711  3707  3 13:42 ?        00:00:11
/opt/oracle/cell12.1.1.1.1_LINUX.X64_140712/cellsrv/bin/cellsrv 100 5000 9 5042 root 4240 4104 0 13:48 pts/0 00:00:00 grep /cellsrv [root@cell ~]# [root@cell ~]# ps -ef |grep cellrsomt root 3707 3698 1 13:42 ? 00:00:04
/opt/oracle/cell12.1.1.1.1_LINUX.X64_140712/cellsrv/bin/cellrsomt -rs_conf
/opt/oracle/cell12.1.1.1.1_LINUX.X64_140712/cellsrv/deploy/config/cellinit.ora -ms_conf
/opt/oracle/cell12.1.1.1.1_LINUX.X64_140712/cellsrv/deploy/config/cellrsms.state -cellsrv_conf
/opt/oracle/cell12.1.1.1.1_LINUX.X64_140712/cellsrv/deploy/config/cellrsos.state -debug 0 root 4268 4104 0 13:48 pts/0 00:00:00 grep cellrsomt

A partir de la pantalla anterior se observa que el proceso CELLSRV se inicia mediante el proceso id 3707, es decir, cellrsomt, el proceso CELLSRV 3711 tiene su id de proceso padre como 3707 y ese id de proceso 3707 es de cellrsomt.


Con la información anterior vemos que los procesos del servidor de almacenamiento principal son RS, MS y CELLSRV. Estos procesos facilitan las características de Exadata Storage Server. Es importante entender que los 3 procesos son vitales todo el tiempo en Exadata Storage Server. En caso de que 1 del servidor de almacenamiento no responda, Oracle Exadata Cuarto, medio y rack completo proporciona 3, 7 y 14 servidores de almacenamiento, respectivamente, para tolerancia a fallos y alta disponibilidad.

Hasta acá ha llegado este articulo.

Si deseas estar al día con valiosa información de tecnología Oracle Cloud, Exadata y mas, se parte de nuestra red en Linkedin, cada día tendrás material para leer acerca de estas fascinante tendencias y soluciones.

Karan Dodwal: https://www.linkedin.com/in/karan-dodwal-ocm-765b2b2b/
Joel Perez’s LinkedIn: www.linkedin.com/in/SirDBaaSJoelPerez
Joel Pérez’s Blog: https://community.oracle.com/blogs/Sir.DBaaSJoelPerez
César Aguilar: https://www.linkedin.com/in/césar-aguilar-vásquez-oce®-ocp®-56a08b46/


Karan Dodwal es un arquitecto especializado en Alta Disponibilidad de Oracle. Senior OCM DBA Oracle con varios años de experiencia en el área de desarrollo y administración de base de datos Oracle. Trabaja como consultor Oracle. Ha brindado diversos servicios y capacitaciones sobre los productos de Oracle en Asia Pacífico, Asia del Sur y la Gran China. Es ponente del Grupo de Usuarios "All India Oracle Users Group (North India Chapter)". Ha realizado configuraciones de Oracle de alta disponibilidad en todas las plataformas de misión crítica de Oracle Database. Él es un experto en todas las soluciones de alta disponibilidad de Oracle como RAC, Exadata, Data Guard y otros. Con frecuencia publica artículos en varios sitios web y en su blog: http: //karandba.blogspot.in. Participa activamente en eventos de grupos de usuarios y participa de forma frecuente en foros de OTN.

Joel Pérez es un experto DBA (Oracle ACE Director, Maximum Availability OCM, OCM Cloud & OCM12c/11g) con más de 17 años de experiencia real en el mundo de tecnología Oracle, especializado en diseño e implementación de soluciones de: Cloud, Alta disponibilidad, Recuperación contra desastres, Upgrades, Replicación y toda área relacionada con bases de datos Oracle. Joel se desempeña como: Database Cloud Solution Architect & International Business Manager para la compañía en.Enmotech.com Yunhe Enmo (Beijing) Technology Co. Ltd. Beijing, China. LinkedIn: www.linkedin.com/in/SirDBaaSJoelPerez

César Aguilar es un DBA (OCE RAC 11g, OCP12c, OCP/OCA 11g, Oracle Database12c CertifiedImplementationSpecialist) con experiencia en RAC, Data Guard y otras soluciones de alta disponibilidad. Actualmente se encuentra radicado en Ecuador y trabaja para la compañía Refundation ConsultingGroup “http://www.refundation.com” como consultor DBA

Este artículo ha sido revisado por el equipo de productos Oracle y se encuentra en cumplimiento de las normas y prácticas para el uso de los productos Oracle.