Oracle Exadata Database Machine: I/O Resource Manager (IORM)

Por Alex Zaballa y Yenugula Venkata RaviKumar (Oracle Certified Master)
Postado em Março 2015

Revisado por Marcelo Pirovar - Solution Architect

Introdução

A distribuição dos recursos não é um tema novo quando falamos de banco de dados Oracle, porém estamos acostumados a ouvir falar sobre a possibilidade de distribuir e controlar os recursos de CPU. Agora iremos falar sobre um recurso que está presente no Oracle Database Machine, que é a possibilidade de distribuição dos recursos de leitura e escrita (I/O), que se tornou possível graças ao Exadata Storage Server.

O IORM é um componente muito importante dentro do Exadata Storage Server, que tem como objetivo distribuir os recursos de I/O. Isto é muito útil, por exemplo em um Exadata, quando possuímos diferentes bancos de dados, com diferentes cargas de trabalho e que podem competir entre si pelos recursos. Um banco de dados com alta carga transacional (OTLP), pode sofrer esperas devido a estas constantes competições por recursos de I/O. O correto seria atribuir mais recursos de I/O para estes bancos de dados que possuem maior demanda e atribuir poucos recursos aos bancos de dados de menor prioridade.  

O IORM nos permite administrar os recursos de I/O para diferentes finalidades, tais como:

  • Tipos de usuários
  • Aplicações
  • Banco de Dados (Interdatabase / Intradatabase)
  • Tipos de cargas

 

I/O Resource Management

Intradatabase: Os planos de recursos dentro de um banco de dados são atribuídos a grupos de consumidores. Por exemplo, se em um mesmo banco de dados existem duas aplicações, uma que executa tarefas de I/O do tipo OLTP e outra que executa tarefas do tipo Datawarehouse, poderíamos criar dois grupos de consumidores e atribuir recursos I/O para cada um desses grupos. Estes tipos de planos são chamados de intradatabase, porque só serão distribuídos recursos I/O dentro de um único banco de dados. Os planos intradatabase são criadas pelo Database Resource Manager (DBRM).

Interdatabase: Estes planos servem para distribuir os recursos de I/O aos diversos bancos de dados. Em tais planos, o IORM determina a prioridade do I/O com base no nome do banco de dados e assim faz a distribuição dos recursos, ao contrário dos planos intradatabase, que foram distribuídos aos grupos de consumidores dentro de um mesmo banco de dados. Isso geralmente é usado para evitar que os bancos de dados passem a competir entre si por recursos I/O.

Categories: Os planos por categoria fazem uso dos planos interdatabase e dos planos intradatabase para alocar recursos. Neste tipo de plano, os recursos de I/O são distribuídos entre os diferentes grupos de consumidores, mas através de todos os bancos de dados existentes. Para fazer isso, cada grupo de consumidores em cada um dos bancos de dados devem estar relacionados a uma determinada categoria.


Como é a alocação dos recursos quando existem diferentes planos?

  • Os planos de categorias têm precedência sobre qualquer outro plano existente;
  • Os planos do tipo interdatabase têm precedência sobre os planos intradatabase;
  • Os planos do tipo intradatabase são os últimos a serem executados para a distribuição de recursos entre os grupos de consumidores de I/O.

Arquitetura do IORM

  • O IORM gerencia os recursos de I/O para cada Oracle Exadata Cell dentro de uma Oracle Exadata Machine;
  • O IORM irá programar as solicitações de recursos de I/O entrantes baseado nos planos de recursos configurados previamente;
  • As solicitações de I/O para Redo Log Files e Control Files sempre terão prioridade maior do que qualquer outra solicitação;
  • As solicitações de I/O realizadas pelos processos DBWn serão categorizadas com a mesma prioridade das solicitações de usuários;
  • O objetivo principal do IORM é gerenciar os recursos dos discos;
  • O IORM só intervém quando existe mais de um grupo de consumidores ativo em um banco de dados;
  • O IORM controla e gerencia apenas as filas de I/O dos discos físicos, não gerencia os dispositivos baseados em flash ou solicitações atendidas pelo Oracle Exadata Smart Flash Cache.

IORM Objective

A diretiva Objective determina como o balanceamento de carga de I/O será aplicado em cada célula:

  • Off: Configuração default. O IORM não interfere nas operações de I/O;
  • Low_latency: Útil para as cargas do tipo OLTP e para limitar o número de solicitações      simultâneas de I/O;
  • High_throughput: Útil para DSS e ambientes com grande quantidade de carga do tipo DataWarehouse. Maximiza o uso do disco;
  • Balanced: Útil para a carga de trabalho mista (OLTP / DataWarehouse);
  • Auto: IORM decide qual o melhor valor para o parâmetro com base na carga de trabalho que está recebendo.

Habilitar o IORM dentro de um banco de dados:

  • Manualmente: setar o parâmetro RESOURCE_MANAGER_PLAN no banco de dados.
  • Automaticamente: Criar uma Oracle Scheduler Window e associar a um plano.
  • Ativar o plano do IORM em cada Oracle Exadata Cell.

 

Habilitar o IORM em diversos banco de dados:

  • Configurar um IORMPLAN. Podem ser utilizados Planos de Categorias e Planos interdatabase.
  • Usar o CellCLI para definir e ativar os planos em cada Oracle Exadata Cell.
  • Configurar o mesmo IORMPLAN em cada Oracle Exadata Cell.
  • Somente um plano de  IORM pode ser ativado ao mesmo tempo.

 

Como monitorar o IORM?

Consultar o banco de dados que consome mais recursos:

  • DB_IO_RQ_SM
  • DB_IO_RQ_LG

Consultar quanto tempo um banco de dados esperou por recursos:

  • DB_IO_WT_SM
  • DB_IO_WT_LG

Demonstrando o IORM

Na demonstração a seguir, serão utilizados dois bancos de dados:

  • orcl
  • iormdb

Estes dois bancos de dados irão compartilhar os recursos de duas Oracle Exadata Cells (cell1 e cell2). Nesta demonstração, iremos criar duas Tablespaces ao mesmo tempo, uma em cada um dos bancos de dados. A primeira parte, sem o IORM, assim poderemos ver os dois bancos de dados entrando em conflito para obter o máximo de recursos de I/O possível. Na segunda parte da demonstração, faremos uso do IORM, de modo que serão atribuídos recursos de I/O a cada um dos banco de dados, a fim de evitar tal conflito.

 

Primeira parte – Sem o IORM

Efetuar a conexão no banco de dados 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

Efetuar a conexão no banco de dados 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

Criar duas Tablespaces simultaneamente, cada uma em um dos bancos de dados :

  • No banco orcl: 
SQL> create bigfile tablespace test datafile '+DATA' size 1G;
Tablespace created.

Elapsed: 00:17:09.37
  • No banco iormdb:
SQL> create bigfile tablespace test datafile '+DATA' size 1G;
Tablespace created.

Elapsed: 00:17:14.73

Ao criar as Tablespaces nos bancos de dados orcl e iormdb, os Storage Servers são consultados periodicamente para avaliar os recursos de I/O que cada um dos bancos de dados estão consumindo.

Revisão das métricas na 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

Revisão das métricas na 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: Repare que sem um plano de IORM, os tempos de execução são quase idênticos, pois os bancos de dados estavam concorrendo por recursos de I/O.

 

Segunda Parte – Com o IORM

Configurar o IORMPLAN na 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 o IORMPLAN na 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 o status do  IORMPLAN:

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

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

Criar duas Tablespaces simultaneamente, cada uma em um dos bancos de dados:

  • No banco  orcl:
SQL> create bigfile tablespace test1 datafile '+DATA' size 1G;
Tablespace created.

Elapsed: 00:08:12.15
  • No banco iormdb:
SQL> create bigfile tablespace test1 datafile '+DATA' size 1G;
Tablespace created.

Elapsed: 00:17:51.32

Revisão das métricas na 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

Revisão nas métricas na 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: Uma vez configurado o IORM nos dois Oracle Exadata Cells, alocando 90% dos recursos para o banco de dados orcl e os 10% restantes para o banco de dados iormdb, podemos observar que ao criar as Tablespaces simultaneamente em ambos os bancos de dados, o banco iormdb demorou muito mais tempo para criar a Tablespace, no entanto o banco orcl que teve a maioria dos recursos assegurados terminou a tarefa rapidamente.

 

Alex Zaballa, formado em Análise de Sistemas, é especialista em Banco de Dados Oracle com sólidos conhecimentos em Servidores de Aplicação e Sistemas Operacionais; trabalha com Oracle há 15 anos, é ORACLE ACE, certificado OCM Database 11G e conta com mais de 140 outras certificações em produtos da Oracle. Alex também é fundador do Grupo de Usuários Oracle de Angola (GUOA) e membro do time OraWorld.

Yenugula Venkata Ravikumar é um DBA com mais de 15 anos de experiencia com Oracle e em ambientes de alta disponibilidade (RAC, Data Guard, dentre outros), tuning e desempenho, migrações, backup e recover, Oracle Exadata X2 e X3, é Expert em sistemas operacionais tais como como AIX, HP-UX e Linux. Já participou como conferencista de Oracle pela India, onde mora atualmente. Obteve o título de "Oracle Certified Master (OCM 10g)" em 2009.

Este artigo foi revisto pela equipe de produtos Oracle e está em conformidade com as normas e práticas para o uso de produtos Oracle.