Oracle Exadata Database Machine: IO Resource Manager (IORM)

Por Deiby Gómez Robles y Yenugula Venkata RaviKumar (Oracle Certified Master)
Publicado en enero 2014

Introducción

La distribución de los recursos no es un tema nuevo dentro de una base de datos Oracle, siempre ha existido la posibilidad de distribuir recursos de CPU en una base de datos, sin embargo, la distribución de los recursos de escritura y lectura (IO) es una característica que solamente existe en "Oracle Database Machine" y es posible gracias a la "inteligencia" que los "Exadata Storage Server" tienen.

"IO Resource Manager (IORM)" es un componente muy importante dentro de un "Exadata Storage Server" el cual tiene como objetivo distribuir los recursos de IO hacia diferentes receptores. Esto es muy útil cuando dentro de un "Oracle Exadata Machine" se crean diferentes bases de datos las cuales mantienen diferentes cargas de trabajo, teniendo como resultado que todas compitan entre ellas mismas por los recursos. Una base de datos que necesite satisfacer una alta carga de transaccionalidad (OLTP) puede sufrir esperas debido a que constantemente se encuentra compitiendo por los recursos de IO. Lo correcto sería asignar más recursos de IO a las bases de datos que más demanda de los clientes tenga y asignar pocos recursos de IO a las bases de datos que no sean de alta prioridad, de esta manera las bases de datos con baja prioridad no intervendrán en los recursos de las bases de datos con alta prioridad y así las esperas se eliminarán.
"IO Resource Manager (IORM)" nos permite administrar los recursos de IO para diferentes objetivos, tales como:

  • Tipos de usuarios
  • Aplicaciones
  • Bases de Datos (Interdatabase / Intradatabase)
  • Tipos de cargas

Planes de "I/O Resource Manager"

Intradatabase: Los planes de recursos dentro de una base de datos son asignados a grupos consumidores. Por ejemplo si dentro de una base de datos se tienen dos aplicaciones, una que realiza tareas de IO de tipo OLTP y otra que realiza tareas de tipo "Datawarehouse", podríamos crear dos grupos consumidores y asignarle recursos de IO a cada uno de estos grupos. A este tipo de planes se les denomina "intradatabase" pues solo distribuyen recursos de IO dentro de una sola base de datos. Los planes "intradatabase" son creados por el "Database Resource Manager (DBRM)".

Interdatabase: Estos planes sirven para poder distribuir los recursos de IO dentro de varias bases de datos, en este tipo de planes los recursos se distribuyen a bases de datos, a diferencia de los planes "intradatabase" que se asignaban a grupos consumidores. Esto suele servir para evitar que las bases de datos suelan competir entre sí por los recursos de IO, sino más bien determinar qué tantos recursos de IO puede consumir cada una de ellas, de esta manera una base de datos no intervendrá con las otras.

Por Categoría: Los planes por categoría hacen uso de los planes "interdatabase" y de los planes "intradatabase" para poder asignar recursos. Este tipo de planes reparte los recursos de IO a diferentes grupos consumidores pero a través de todas las bases de datos existentes. Para poder realizar esto, cada grupo consumidor dentro de cada una de las bases de datos debe ser relacionado con una determinada categoría.

¿Cómo se distribuyen los recursos cuando existen diferentes planes?

  • Los planes de categorías tienen precedencia ante cualquier otro tipo de plan existente.
  • Los planes de tipo "interdatabase" tienen precedencia sobre los planes "intradatabase".
  • Los planes "intradatabase" son los últimos en ser ejecutados para distribuir los recursos de IO entre grupos consumidores.

Arquitectura de IORM

  • IORM maneja recursos de IO por cada "Oracle Exadata Cell" dentro de un "Oracle Exadata Machine".
  • IORM programará solicitudes de recursos de IO entrantes basándose en planes de recursos configurados previamente.
  • Las solicitudes de IO hacia los "Redo Log Files" y "Control Files" siempre tendrán más prioridad que cualquier otro tipo de solicitud.
  • Las solicitudes de IO realizadas por el proceso "DBWn" son categorizadas con la misma prioridad que las solicitudes de los usuarios.
  • El objetivo principal de IORM es gestionar los recursos de los discos.
  • IORM únicamente interviene cuando más de un grupo consumidor está activo en una base de datos.
  • IORM únicamente controla y maneja colas de IO para discos físicos, no para "Grid Disk" basados en dispositivos flash o solicitudes servidas por "Oracle Exadata Smart Flash Cache".

Parámetro "objetive" dentro de los planes de IORM: El parámetro "objetive" establece la forma en que las solicitudes físicas de IO serán enviadas a los discos. Los valores que recibe este parámetro son:

  • off: Configuración por defecto. IORM no interviene en las operaciones IO.
  • low_latency: Útil para cargas de tipo OLTP y para limitar el número de solicitudes de IO concurrentes.
  • high_throughput: Útil para DSS y ambientes con cargas de trabo de tipo "Datawarehouse". Maximiza el uso de los discos.
  • balanced: Útil para cargas de trabajo mixtas (OLTP/Datawarehouse)
  • auto: IORM decide el mejor valor para el parámetro "objetive" basándose en la carga de trabajo que esté recibiendo.

Habilitar IORM dentro de una base de datos

  • Manualmente: Establecer el parámetro de base de datos RESOURCE_MANAGER_PLAN
  • Automáticamente: Crear un "Oracle Scheduler Window" y asociarle un plan.
  • Se debe activar el IORMPLAN en cada "Oracle Exadata Cell".

Habilitar IORM a través de varias bases de datos

  • Configurar un IORMPLAN. Pueden ser utilizados Planes de Categorías y Planes "interdatabase".
  • Usar CellCLI para definir y activar los planes en cada "Oracle Exadata Cell".
  • Configurar el mismo IORMPLAN en cada "Oracle Exadata Cell".
  • Únicamente un plan de IORM puede ser activo al mismo tiempo.

¿Cómo monitorear IORM?

Consultar la base de datos que consume más recursos:

  • DB_IO_RQ_SM
  • DB_IO_RQ_LG

Consultar el tiempo que una base de datos estuvo esperando por recursos:

  • DB_IO_WT_SM
  • DB_IO_WT_LG

Demostración de IORM

En la siguiente demostración serán utilizadas dos bases de datos :

  • orcl
  • iormdb

Estas dos bases de datos compartirán los recursos de dos "Oracle Exadata Cell" (cell1 y cell2). En esta demostración se creará un "Tablespace" simultáneamente en cada una de las bases de datos. La primera parte de la demostración será sin IORM, de esta manera se verá que las dos bases de datos entrarán en conflicto por obtener tantos recursos como puedan. La segunda parte de la demostración será utilizando IORM, de tal manera que a cada base de datos se le asignarán recursos de IO para evitar que estas entren en conflicto.

Primera parte - Sin IORM

Establecer conexión en la base de datos "orcl":

[oracle@dbnode ~]$ export ORACLE_SID=orcl
[oracle@dbnode ~]$ export ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1
 [oracle@dbnode bin]$ sqlplus /nolog
SQL*Plus: Release 11.2.0.3.0 Production on Fri Oct 18 09:52:03 2013
Copyright (c) 1982, 2011, Oracle.  All rights reserved.

SQL> conn sys/oracle@orcl as sysdba
Connected.

SQL> set timing on

Establecer conexión en la base de datos "iormdb":

[oracle@dbnode ~]$ export ORACLE_SID=iormdb
[oracle@dbnode ~]$ export ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1
 [oracle@dbnode bin]$ sqlplus /nolog
SQL*Plus: Release 11.2.0.3.0 Production on Fri Oct 18 09:52:38 2013
Copyright (c) 1982, 2011, Oracle.  All rights reserved.

SQL> conn sys/oracle@iormdb as sysdba
Connected.

SQL> set timing on

Crear un "Tablespace" simultáneamente en ambas bases de datos:

• En la base de datos "orcl":

SQL> create bigfile tablespace test datafile '+DATA' size 1G;
Tablespace created.

Elapsed: 00:17:09.37

• En la base de datos "iormdb":

SQL> create bigfile tablespace test datafile '+DATA' size 1G;
Tablespace created.

Elapsed: 00:17:14.73

Mientras se crean los "Tablespace" en las bases de datos "orcl" y "iormdb", los "Storage Server" son consultados periódicamente para evaluar los recursos de IO que cada una de las bases de datos están consumiendo.

Revisión de las métricas en "Cell1":

CellCLI> list metriccurrent CD_IO_BY_W_LG_SEC where metricobjectname like 'CD.*'
         CD_IO_BY_W_LG_SEC       CD_DISK01_cell1         0.000 MB/sec
         CD_IO_BY_W_LG_SEC       CD_DISK02_cell1         0.000 MB/sec
         CD_IO_BY_W_LG_SEC       CD_DISK03_cell1         0.426 MB/sec
         CD_IO_BY_W_LG_SEC       CD_DISK04_cell1         0.921 MB/sec

Revisión de las métricas en "Cell2":

CellCLI> list metriccurrent CD_IO_BY_W_LG_SEC where metricobjectname like 'CD.*'
         CD_IO_BY_W_LG_SEC       CD_DISK01_cell2         0.000 MB/sec
         CD_IO_BY_W_LG_SEC       CD_DISK02_cell2         0.000 MB/sec
         CD_IO_BY_W_LG_SEC       CD_DISK03_cell2         0.467 MB/sec
         CD_IO_BY_W_LG_SEC       CD_DISK04_cell2         1.002 MB/sec

Nota: Note que sin un plan de IORM los tiempos de ejecución son casi idénticos pues las dos bases de datos estuvieron compitiendo por los recursos de IO.

Segunda Parte- Con IORM

Configurar IORMPLAN en "Cell1":

CellCLI> alter iormplan dbplan=((name=orcl, level=1, allocation=90), 
(name=iormdb, level=1, allocation=10),(name=other, level=2, allocation=100))
IORMPLAN successfully altered

CellCLI> alter iormplan active
IORMPLAN successfully altered

CellCLI> list iormplan detail
         name:		cell1_IORMPLAN
         catPlan:
         dbPlan:		name=orcl,level=1,allocation=90
				name=iormdb,level=1,allocation=10
				name=other,level=2,allocation=100
         objective:	basic
         status:		active

Configurar IORMPLAN en "Cell2":

CellCLI> alter iormplan dbplan=((name=orcl, level=1, allocation=90), 
(name=iormdb, level=1, allocation=10),(name=other, level=2, allocation=100))
IORMPLAN successfully altered

CellCLI> alter iormplan active
IORMPLAN successfully altered



CellCLI> list iormplan detail
         name:		cell2_IORMPLAN
         catPlan:
         dbPlan:		name=orcl,level=1,allocation=90
				name=iormdb,level=1,allocation=10
				name=other,level=2,allocation=100
         objective:	basic
         status:		active

Verificar el estado de los IORMPLAN:

[celladmin@cell1 ~]$ cellcli -e list iormplan
         cell1_IORMPLAN  active

[celladmin@cell2 ~]$ cellcli -e list iormplan
         cell2_IORMPLAN  active

Crear un "Tablespace" simultáneamente en ambas bases de datos:

• En la base de datos "orcl":

SQL> create bigfile tablespace test1 datafile '+DATA' size 1G;
Tablespace created.

Elapsed: 00:08:12.15

• En la base de datos "iormdb":

SQL> create bigfile tablespace test1 datafile '+DATA' size 1G;
Tablespace created.

Elapsed: 00:17:51.32

Revisión de las métricas en "Cell1":

CellCLI> list metriccurrent CD_IO_BY_W_LG_SEC where metricobjectname like 'CD.*'
         CD_IO_BY_W_LG_SEC       CD_DISK01_cell1         0.002 MB/sec
         CD_IO_BY_W_LG_SEC       CD_DISK02_cell1         0.000 MB/sec
         CD_IO_BY_W_LG_SEC       CD_DISK03_cell1         0.310 MB/sec
         CD_IO_BY_W_LG_SEC       CD_DISK04_cell1         0.802 MB/sec

Revisión de las métricas en "Cell2":

CellCLI> list metriccurrent CD_IO_BY_W_LG_SEC where metricobjectname like 'CD.*'
         CD_IO_BY_W_LG_SEC       CD_DISK01_cell2         0.009 MB/sec
         CD_IO_BY_W_LG_SEC       CD_DISK02_cell2         0.000 MB/sec
         CD_IO_BY_W_LG_SEC       CD_DISK03_cell2         0.894 MB/sec
         CD_IO_BY_W_LG_SEC       CD_DISK04_cell2         0.485 MB/sec

Nota: Una vez configurado IORM en los dos "Oracle Exadata Cell" asignando el 90% de los recursos a la base de datos "orcl" y el 10% de los recursos a la base de datos "iormdb" se pudo observar que al crear el "Tablespace" simultáneamente en ambas bases de datos, la base de datos "iormdb" duró mucho más tiempo en crear el "Tablespace", mientras que la base de datos "orcl" quien tuvo la mayoría de recursos asignados terminó la tarea rápidamente.

 

Deiby Gómez es un DBA, con experiencia en administración de dominios “WebLogic” e implementaciones de Arquitecturas Orientadas a Servicios (SOA). De forma frecuente es conferencista en diversos eventos Oracle en Guatemala, entre ellos OTN LAD Tour 2013 y otros. Ha brindado consultoría en implementaciones de SOA y Bases de datos en diversas empresas de su país de residencia ( Guatemala ), actualmente es Consultor en Datum S.A. de Guatemala. Deiby es OCP11g, Exadata Database Machine X3 Administrator y Oracle SOA Implementation Certified Expert.

Yenugula Venkata RaviKumar es un DBA con más de 13 años de experiencia, especializado en ambientes de Alta Disponibilidad de Bases de Datos (RAC, Data Guard, entre otras), afinación del rendimiento para Bases de Datos, Migraciones y Respaldos, Oracle Exadata v1/v2/v3, experto en Sistemas operativos como AIX, HP-UX y Linux . Ha participado como conferencista en varios eventos Oracle en la India donde actualmente reside. Obtuvo el título de OCM10g en el año 2009.