Ao falar de IORM, deve-se lembrar que ele é somente uma parte do processo. Como já citei em posts anteriores, o IORM é um resource manager semelhante ao encontrado no banco de dados, sendo chamado de interdatabase enquanto o resource manager do banco de dados é chamado de intradatabase. O IORM deve ser somente uma das funcionalidades utilizadas em um projeto para Exadata, um bom projeto começa com preocupações que vão desde a conexão a base de dados, passando pela gerência dos recursos internos da instância e indo até I/O.

A integração do IORM com o resource manager do banco de dado pode ser realizada através de categorias (catPlan). Apesar de o IORM em suas métricas apresentar a distinção por consumer groups não é possível utilizá-los na definição do plano de recursos. Com o uso de categorias, você pode ir além de uma simples delimitação de recursos por bancos de dados, você pode agrupar o I/O independente do banco de origem.

Além do controle através de categorias, o IORM pode utilizar somente bases de dados (dbPlan), mas este não consegue se integrar completamente com o plano de recursos da base de dados. O uso é realizado de maneira indireta, somente através das métricas, sem qualquer possibilidade de gerência ou direcionamento dos recursos.

Antes de começar a definição do plano de recursos do IORM deve-se analisar o conjunto das bases de dados que estarão em execução. Indo além, deve-se verificar quais os tipos de aplicativos e carga de trabalho existente. Com base nesse levantamento será possível traçar quais os serviços que podem ser criados, quais os consumer groups existentes e principalmente, quais as categorias de I/O que são comuns entre as bases de dados.

Caso a carga de trabalho sobre as bases de dados não seja conhecida, um questionário pode ser elaborado para identificar qual a demanda. Como estamos falando de um plano de recursos que vai além do controle de CPU é importante abordar aspectos como o tipo de consultas existentes, funcionalidades da aplicação (como carga de dados e afins), tipos relatórios, uso de lobs, demanda por throughput ou tempo de resposta. Caso existam demandas distintas para a mesma base de dados é importante identificar qual a prioridade entre elas. É importante que estas dúvidas sejam respondidas pela equipe da aplicação (desenvolvedores, analistas, gerentes) por conhecerem (deveriam) a aplicação com mais detalhes. Mas este questionário não deve ser a única fonte de informação, a análise realizada pelo DBA (análise das consultas, top queries, top consumers…) também é fundamental.

Com estas as respostas, pode-se identificar qual a demanda sobre o I/O e CPU que estará no Exadata, permitindo criar os serviços e consumer groups a fim de elaborar um plano adequado. Por parte do banco de dados a criação destes pode ser através de SQL ou GridControl. A versão 12c do GridControl teve algumas mudanças quanto à localização e acesso ao resource manager, agora existe um menu dedicado a este. Apesar desta integração com o IORM não houve qualquer alteração no uso do resource manager no banco de dados, o conceito e métodos continuam os mesmos.

Antes de continuarmos vamos tomar como exemplo o seguinte cenário:

DB01, utilizado em ambiente OLTP contando com os serviços abaixo:

• DB01_WEB: serviço para conexões dos aplicativos WEB, utilizado exclusivamente para OLTP. Alta demanda quanto a conexões e CPU, necessidade por tempo de resposta.
• DB01_DESKTOP: serviço para conexões dos aplicativos DESKTOP, aplicativos com ênfase em funções administrativas e controle dos dados. Baixa demanda e necessidade por tempo de resposta.
• DB01_BATCH: serviço utilizado para aplicativos de carga de dados e consolidações de dados. Demanda elevada fora do horário comercial, (caso ocorra algum erro, o aplicativo pode ser executado com conjunto específico de dados) necessita de throughput.
• DB01_LINK: serviço para conexões via DBLINK entre as bases de dados, algumas MV’s de outras bases acessam os dados através deste. Alta demanda 24×7 e necessidade por tempo de resposta.

DB02, utilizado em ambiente misto de OLTP e DSS, conta com os serviços abaixo:

• DB02_WEB: serviço para conexões dos aplicativos WEB, utilizado principalmente para consultas, algumas informações são oriundas do DB01 através de MV’s. Demanda média quanto a conexões e CPU, necessita de tempo de tempo de resposta.
• DB02_DESKTOP: serviço para conexões dos aplicativos DESKTOP, aplicativos utilizado pela equipe de tomada de decisão, manipulação de dados e relatórios gerenciais. Baixa demanda por conexão e alta para CPU, necessidade por tempo de resposta.

No cenário acima podemos identificar que o DB01 poderia apresentar os seguintes consumer groups (em ordem de prioridade): WEB, LINK, DESKTOP, BATCH. Já o DB02 apresenta (também em ordem de prioridade): DESKTOP e WEB. Para ambas as bases, os serviços não foram agrupados em consumer groups, esse agrupamento será realizado através de categorias o que facilita um controle mais apurado de toda a carga de I/O do Exadata. De qualquer forma, as métricas do IORM permitem identificar os consumer groups e as suas demandas.

Em ambas as bases existe um serviço chamado SUPORTE que é utilizado por qualquer atividade administrativa ou manutenção no modelo de dados. Não é o intuito apresentar aqui o plano de recursos de CPU, mas com o cenário acima pode-se ter uma idéia da divisão de recursos.

Com base no cenário apresentado podemos identificar as seguintes categorias:

• ALTA: Categoria para I/O que demanda uma alta prioridade e não pode sofrer interferência das outras. Utilizada pelos consumer groups WEB (DB01) e DESKTOP(DB02).
• MEDIA_ALTA: Categoria para I/O com alta demanda, mas com prioridade mais baixa que a anterior, pode sofrer interferência de outras categorias. Utilizada pelo consumer group LINK (DB01).
• MEDIA: Categoria de I/O de média prioridade. Utilizado pelo consumer groups WEB (DB02)
• BAIXA: Categoria de baixa prioridade para I/O. Utilizada pelos consumer groups DESKTOP e BATCH (ambos DB01).

Para a criação destas categorias nas bases de dados o único método disponível é através de SQL e pela função CREATE_CATEGORY do pacote DBMS_RESOURCE_MANAGER. Assim, seguindo o cenário, temos:

BEGIN
    DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
    DBMS_RESOURCE_MANAGER.CREATE_CATEGORY(CATEGORY => 'ALTA', COMMENT => 'Alta demanda.');
    DBMS_RESOURCE_MANAGER.CREATE_CATEGORY(CATEGORY => 'MEDIA_ALTA', COMMENT => 'Media/Alta demanda.');
    DBMS_RESOURCE_MANAGER.CREATE_CATEGORY(CATEGORY => 'MEDIA', COMMENT => 'Media demanda.');
    DBMS_RESOURCE_MANAGER.CREATE_CATEGORY(CATEGORY => 'BAIXA', COMMENT => 'Baixa demanda.');
    DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;

Com o comando acima, podemos criar as categorias na base de dados. O comando acima cria todas as categorias, mas pode-se optar por criar somente as utilizadas e este deve ser executado em cada base de dados do ambiente. As categorias existentes na base de dados podem ser obtidas através da tabela “dba_rsrc_categories”.

O mapeamento entre categorias e consumer groups é realizado através da função UPDATE_CONSUMER_GROUP do pacote DBMS_RESOURCE_MANAGER (pode ser utilizado CREATE_CONSUMER_GROUP caso o consumer group esteja sendo criado). O mapeamento pode ser verificado através da tabela “dba_rsrc_consumer_groups” e pela coluna “category”.

Para o DB01 do cenário teríamos:

BEGIN
    DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
    DBMS_RESOURCE_MANAGER.UPDATE_CONSUMER_GROUP(consumer_group => 'WEB', new_category => 'ALTA');
    DBMS_RESOURCE_MANAGER.UPDATE_CONSUMER_GROUP(consumer_group => 'DESKTOP', new_category => 'BAIXA');
    DBMS_RESOURCE_MANAGER.UPDATE_CONSUMER_GROUP(consumer_group => 'BATCH', new_category => 'BAIXA');
    DBMS_RESOURCE_MANAGER.UPDATE_CONSUMER_GROUP(consumer_group => 'LINK', new_category => 'MEDIA_ALTA');
    DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;

Para o banco DB02 teríamos:

BEGIN
    DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
    DBMS_RESOURCE_MANAGER.UPDATE_CONSUMER_GROUP(consumer_group => 'WEB', new_category => 'MEDIA');
    DBMS_RESOURCE_MANAGER.UPDATE_CONSUMER_GROUP(consumer_group => 'DESKTOP', new_category => 'ALTA');
    DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;

Assim, todo e qualquer I/O que saia das bases DB01 ou DB02 recebe um selo/marcação a qual pode ser identificada e tratada pelo software do Exadata. Agora podendo ser mensurada, tratada e enfileirada como um recurso pelo IORM independente da base de dados de origem.

Sem o uso de categorias a única granularidade existente seria por base de dados, em alguns casos esta granularidade por base de dados é interessante, mas para outros não. Em casos de consolidação de bases de dados, ou aquelas que apresentam diversos serviços/cargas de trabalho uma granularidade mais fina é desejada. Com o uso de categorias é possível verificar quanto de I/O está sendo utilizado e conseqüentemente quanto demandam um consumer group e um serviço de uma base de dados. Também com o uso de categorias é possível agrupar e priorizar as cargas de trabalho independente da base de origem.

Um plano de recursos do IORM para o cenário proposto poderia ser:

ALTER IORMPLAN                                                         -
   catPlan=( (name=ALTA, level=1, allocation=70),                      -
             (name=MEDIA_ALTA, level=2, allocation=60),                -
             (name=MEDIA, level=3, allocation=50),                     -
             (name=BAIXA, level=4, allocation=80),                     -
             (name=OTHER, level=5, allocation=100)                     -
             ),                                                        -
    dbPlan=( (name=DB01, level=1, allocation=60),                      -
             (name=DB02, level=2, allocation=90),                      -
             (name=OTHER, level=3, allocation=100, flashCache=OFF)     -
             ),                                                        -
objective=low_latency

Como pode ser observado no plano acima, a divisão é feita por níveis como o resource manager do banco de dados, onde podem ser especificados até 8 níveis com definições de allocation ou limit. No caso do limit ele deve ser utilizado com cuidado, pois pode acabar impedindo que recursos não utilizados por outros bancos ou categorias sejam utilizados.

Por exemplo, em um cenário onde o I/O está saturado por categorias que não sejam dos dois primeiros níveis, e tivéssemos limitado a categoria MEDIA para 50% ao invés de utilizar allocation. Neste caso, pode ocorrer que recursos que tenham sobrado dos níveis anteriores não sejam utilizados pela categoria MEDIA e esta fique limitada com 50% sendo o excedente direcionado ao próximo nível. Com o uso de allocation, esta restrição não existe e a categoria poderia alocar mais do que foi definido.

Tomando como exemplo o plano do exemplo, em caso de uma saturação do I/O (entenda-se como saturação 100% de uso) o IORM começaria a aplicar com mais rigor as regras definidas no plano. Algumas requisições poderiam ser processadas imediatamente enquanto outras de níveis menos prioritários, ou que já tivessem extrapolado sua alocação, poderiam ser enfileiradas.

Assim, do total de requisições de I/O disponíveis, elas seriam divididas primeiramente entre as categorias do catplan e o valor de cada categoria seria dividido entre o dbplan. Pela definição do resource manager o primeiro nível receberia e dividiria o I/O pelos seus consumidores, o que não foi alocado mais a sobra (não utilizado pelos consumidores do nível) seriam repassados ao próximo nível e assim sucessivamente até o último nível.

Segundo o plano acima, 70% seria alocado para a categoria ALTA, o que não foi alocado (30%) juntamente com o que não foi utilizado seriam destinados ao nível 2. Destes 70% da categoria ALTA, 60% seriam destinados ao DB01 (primeiro nível), os 40% restantes mais o que não foi utilizado seria alocado (em 90%) pelo banco DB02. Somente após o fim do que não foi utilizado pelo dbPlan o excedente seria disponibilizado para o próximo nível das categorias (isso seria considerado a sobra do nível da categoria ALTA), assim primeiramente há uma liberação de recursos para o catplan que divide entre seus consumidores com base  nas porcentagens do dbplan. Mesmo a existência do OTHERS no dbplan com 100% não impede ou aloca esta sobra, visto que nenhuma outra base tem esta categoria associada, e se outro banco existisse ele deveria estar especificado no plano.

Pela definição do IORM e resource manager do banco de dados a divisão de I/O será primeiramente dentro do nível e a sobra será enviada ao próximo nível. Por exemplo, no plano abaixo existem duas categorias no nível 2, o I/O seria dividido entre a MEDIA_ALTA e MEDIA, mas o que não foi utilizado pela categoria MEDIA_ALTA (por exemplo) não seria repassado para a categoria MEDIA, ele seria repassado para o próximo nível.

ALTER IORMPLAN                                                      -
    catPlan=( (name=ALTA, level=1, allocation=60),                  -
              (name=MEDIA_ALTA, level=2, allocation=50),            -
              (name=MEDIA, level=2, allocation=40),                 -
              (name=BAIXA, level=3, allocation=80),                 -
              (name=OTHER, level=4, allocation=100)                 -
            )

É importante resaltar dois aspectos no plano do IORM e daquele existente no banco de dados. A primeira é com o coringa OTHER, ele serve para que qualquer outro I/O que seja não categorizado ou oriundo de banco de dados possa ser controlado. Preferencialmente deve ser o nível com menor prioridade e ser único no nível, assim não existirá sobra de recursos. Por exemplo, tudo o que for originário do serviço SUPORTE será direcionado a categoria OTHER pelo IORM.

O segundo ponto é com o valor de alocação dos recursos, tanto de I/O quanto CPU. Recomenda-se que não seja alocado 100% em um único nível (que não seja o último), isso permitirá que os níveis posteriores possam receber recursos.  Os valores alocados devem refletir a demanda da carga de trabalho. No Exadata estamos falando de um ambiente que pode entregar mais do que 20.000 IOPS, então uma alocação de 50% é uma fatia alta. Além disso, quando categorias são utilizadas, os recursos e alocações são referentes à carga de trabalho exclusivos da categoria e não da base inteira.

Algumas definições adicionais podem ser especificadas no plano do IORM, o parâmetro flasCache habilita ou não o uso do flash para as bases de dados. O flash pode ser desligado tanto para armazenamento de dados (flashCache) quanto para o uso na escrita de redo (flashLog). Assim, evita-se que bancos menos prioritários aloquem espaço na flash.

Além disso, pode-se especificar o “modo de otimização” que o IORM irá seguir. O parâmetro “objective” pode ser definido como:

• low_latency: este modo é dedicado a bases OLTP onde a latência no acesso aos discos deve ser a menor possível. Em detrimento, o IORM faz um balanceamento no uso do disco evitando um consumo excessivo por large I/O.
• balanced: modo balanceado entre OLTP e DSS, utilizado no caso de cargas de trabalhos mistas destes. Neste, o IORM permite um uso maior de large I/O, aumentando o throughput.
• high_throughput: Utilizado em cargas de trabalho exclusivamente DSS, onde o uso de large I/O é maioria.
• auto: neste modo o IORM analisa as requisições e faz o ajuste automático entre os modos para OLTP e DSS.
• off: modo padrão e nenhuma otimização é realizada.

Para contextualizar, large I/O são requisições que acessam 128KB ou mais por vez. Em cargas de trabalho que são basicamente OLTP o uso de small I/O (menos de 128KB por requisição) é o que ocorre em sua maioria. Este tipo de carga é mais suscetível a latência no acesso ao disco, necessitando de um acesso rápido. Em cargas de trabalho DSS, o uso de large I/O é maioria e são mais suscetíveis ao throughput de processamento, necessitam uma maior capacidade para entrega de I/O do que baixa latência.

Nos exemplos de planos de recursos acima, somente alguns aspectos foram demonstrados. Existem outras abordagens que podem ser seguidas, como por exemplo, a definição somente do dbplan ou catplan. O IORM é um assunto extenso, mas os exemplos tentaram abordar uma forma mais avançada de uso.

Como pode ser observado, o uso do catplan em conjunto com o dbplan apresenta diversas vantagens. Podemos ter um controle maior sobre todo o caminho, desde a requisição do usuário, até o I/O. Com o IORM podemos responder a algumas questões do dia a dia com maior facilidade, por exemplo, quanto cada serviço ou aplicativo do banco de dados gasta em IOPS, latência, espera e afins?

A manutenção e o monitoramente constante do IORM e do resource manager do banco de dados são necessários. Como sabemos a carga de trabalho sobre o banco de dados pode ser dinâmica e o plano de recursos necessitarem de ajustes. Para o monitoramento do IORM são utilizadas métricas do storage do Exadata.

Por fim, qual o storage tem este controle sobre o I/O sem a necessidade de alteração na aplicação? Até o momento não foi necessária nenhuma alteração na base de dados (tablespaces ou índices) ou no aplicativo, somente a string de conexão.  Como já exposto pela Oracle, Exadata não é só hardware, é software também.

No próximo post falarei sobre o monitoramento, as métricas do IORM e algumas novidades das últimas versões.