Depois de apresentar de forma breve alguns conceitos do Oracle Exadata em artigos anteriores (aqui e aqui) vou falar um pouco sobre como usar tudo isso de forma inteligente. Você já deve ter notado que no Oracle Exadata existem muitos recursos disponíveis como cluster Oracle RAC, grande quantidade de discos, Storage Servers entre outros.

Um dos cenários mais comuns para o Oracle Exadata é a consolidação de bancos de dados distintos (e requisitos distintos) no mesmo ambiente. De qualquer forma não há nada errado, você já faz isso no ambiente tradicional. O seu storage já armazena os blocos de diversas bases, provavelmente compartilhando os mesmos discos do raid group.

Mas onde que o Oracle Exadata se sai melhor? Basicamente na integração entre hardware e software que não existe no ambiente tradicional, a granularidade do que pode ser controlado é muito maior. Muitos dos conceitos aqui podem ser aplicados no ambiente tradicional, o detalhe é utilizá-los com inteligência.

Muitos destes tópicos já foram comentados por mim no Webinar sobre Gerenciamento de Recursos que fiz para o Exadata SIG do GUOB. Fiz um post sobre o Webinar que está disponível aqui e lá existe uma descrição mais detalhada do está neste artigo. De qualquer forma, tentarei passar alguns detalhes para que você consiga utilizar os recursos disponíveis de forma inteligente.

CPU

O controle de CPU que você tem disponível no Oracle Exadata é o mesmo que você utilizaria em qualquer banco 11GR2 ou superior. Aqui temos o instance caging (através do parâmetro CPU_COUNT) para controlar quantos threads de cpu o banco de dados pode “visualizar”. O único detalhe é quanto ao total de cpu definido para todos os bancos de dados:

• Partitioning: a soma dos cpu’s definidos para todas as bases do servidor não passa do limite de cpu’s (threads) disponíveis;
• Over-Subscrive: diferentemente do anterior a soma de todos ultrapassa a quantidade física das threads de cpu’s disponíveis.
• No 12C com o surgimento de PDB’s e CDB’s existe o compartilhamento por shares onde há uma divisão por “porcentagem” sobre o que pode ser utilizado.

Cada um dos pontos acima tem suas vantagens. O importante aqui é entender que você pode ajustar o CPU (em tempo real) para seus bancos e gerenciar. Caso algum banco precise de mais CPU e outro não esteja utilizando, basta realocar.

RESOURCE MANAGER

É o gerenciador de recursos que existe dentro de cada banco de dados Oracle, através dele você define níveis sobre o que cada aplicação, usuário, categoria ou consumer group pode utilizar. Basicamente, sobre o que cada base tem de cpu você define as prioridade internas de uso.

Toda a configuração é realizada através de planos em que grupos de consumidores tem suas porcentagens e garantias de uso definidas. O mapeamento sobre quem compõe o consumer group é realizado através de consumer groups mappings, sendo que podemos definir através de usuários, aplicativos, módulos e serviços de conexão.

O importante aqui é entender a divisão, sendo que os planos contem 8 níveis e a prioridade é do 1º ao 8º. O que não é utilizado em cada nível passa aos demais. Falarei mais sobre ele em um post dedicado.

SERVICES

Eu listo services do Oracle RAC como peça integrante em um esquema de gerenciamento de recursos pois permite definir e dividir a conexão ao banco de dados de formas bem interessantes. Mas uma ressalva, utilizar somente services não quer dizer que você está fazendo gerenciamento de recursos. O importante é que ele pode ser integrado com resource manager através do mapeamento de consumer groups.

Assim, um serviço de conexão (por exemplo WEB) pode ganhar mais recursos e prioridades dentro do banco de dados através de uma simples mudança do plano ativo do resource manager. Você também pode “desligar” um tipo específico de conexão sem finalizar o banco de dados. Como disse acima, sozinho services não faz nada e por isso que o importante não é entender um único ponto, mas sim a integração possível entre todas as peças disponíveis.

IORM (I/O Resource Manager)

Todos os tópicos que listei acima podem ser utilizados tanto em um ambiente tradicional como no Oracle Exadata, mas o gerenciamento de I/O (com a granularidade ideal) só existe no Oracle Exadata e explicarei porquê. Falar sobre IORM renderia uma série de posts, o assunto é extenso mas já falei sobre ele (com mais detalhes) em 3 posts aqui, aqui e aqui. O que falarei abaixo é um resumo do IORM.

Começarei com algumas perguntas, em um ambiente tradicional se a sua aplicação WEB (que aqui seria a menos prioritária) está consumindo mais I/O do que o sua aplicação DESKTOP (a mais prioritária) o que você faz? Muda as tabelas de tablespace e as coloca em raid groups/discos diferentes? E se elas estivem acessando a mesma tabela, o que você faz? Reza?

No Oracle Exadata isso é simples de resolver, basta mudar o plano para consumo de I/O que estará tudo ajustado. Tudo isso é possível através do IORM e a sua integração direta com o resource manager do banco de dados.

A ideia básica é idêntica ao resource manager do banco de dados, você define a porcentagem que cada banco ou categoria terá de I/O e em qual nível ele poderá usar. As requisições de I/O são recebidas pelo Exadata Software e colocadas em filas de prioridades para execução, nenhuma requisição deixará de ser realizada, mas as de maior prioridade terão um tempo de resposta menor.

dbPlan

É o método mais simples de divisão do IORM, você define para cada banco qual a porcentagem de I/O que irá receber. A granularidade é definida por banco e na eventualidade de necessitar mais recursos para somente um consumer group você não irá conseguir.

catPlan

Método mais avançado de configuração, através do catplan você define quanto cada categoria poderá ter de I/O. Se você verificar na documentação do Oracle Exadata não existe como definir categorias internamente no software, estas são categorias internas dos bancos de dados.

Se você trabalha com resource manager de bancos de dados dificilmente deve ter visto esta configuração, na realidade você nem se preocupa com elas. Mas então para que serve? Através delas você pode definir categorias para seus consumer groups, e se perceber, criar categorias idênticas em bancos diferentes.  Criando as mesmas categorias em bancos diferentes você pode agrupá-las e no IORM definir que categorias do tipo BATCH receberão 10% de I/O independente do banco de origem. Além disso, supondo que queria aumentar a garantia de I/O para um único consumer group você só precisa mudar a categoria associada.

Exemplo

Vamos partir do seguinte exemplo: Você consolidou 5 bancos de dados no Oracle Exadata, sendo que em ambos você criou as categorias ALTA (para DESKTOP/WEB), MEDIA (para Integrações/DBLink’s) e BAIXA (Batch). Assim o Exadata software ao receber uma requisição de I/O irá verificar a qual categoria pertence e colocar na fila específica. Além disso também irá verificar a qual banco pertence e, dentro da fila da categoria, realocar a requisição dependendo do banco de dados de origem. E isso acontece para cada Storage Server de forma independente.

No exemplo abaixo temos um exemplo de plano para IORM que tenta ilustrar o que demonstrei acima. catPlan eleva a complexidade pois o que os bancos definidos no dbPlan irão receber depende da porcentagem de cada categoria, cria o conceito de planos dentro de planos (os subplans). No exemplo abaixo os 70% da categoria ALTA serão divididos entre os bancos do dbPlan, e isso ocorre para cada categoria. Se você tiver que garantir mais recursos de I/O para um consumer group do DB01 basta você mudar a categoria a qual ele está associado lá no banco de dados.

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

INTEGRAÇÃO

Mas então, o que existe de diferente entre o ambiente tradicional e o Oracle Exadata no gerenciamento de recursos? Na minha opinião é a granularidade no controle de recursos. Em um ambiente tradicional você não irá conseguir modificar (nem definir) prioridades diferentes de I/O para consumer groups distintos de um mesmo banco de dados que estejam consumindo a mesma tabela. Nenhum storage consegue interpretar o conteúdo das requisições enviadas pelo banco de dados e enfileirá-las, ainda mais envolvendo bancos de dados diferentes.

Um ponto pouco comentado é que no Oracle Exadata você tem a capacidade de integrar tudo, do início ao fim da requisição. Você consegue definir a conexão através de services do Oracle RAC, mapeá-los em consumer groups e definir a quantidade de CPU que cada um irá ter através do Resource Manager do banco de dados, indo além você consegue definir o quanto cada banco de dados ou categoria poderá ter de I/O através do IORM. Tudo isso de forma integrada e passível de modificação sem precisar reiniciar qualquer banco ou ter downtime de sua aplicação.

Um detalhe é que tanto o Resource Manager do banco quanto o IORM só entram em ação com mais força quando o consumo dos recursos está próximo de 100%. Mas pouco se fala é que além do gerenciamento de recursos você “ganha” a capacidade de medir tudo isso. Mesmo você não usando 100% de recursos você pode verificar o consumo de cada módulo do seu ambiente. Somente com um plano ativo no Resource Manager você consegue saber quanto de CPU é gasto por cada consumer group, e se o IORM estiver ativo algumas métricas adicionais do Exadata Software serão preenchidas e você conseguirá medir o gasto de I/O corretamente.

A ideia básica que deve ficar clara é a capacidade que o Oracle Exadata lhe dá para integrar e gerenciar tudo, do início ao fim da requisição você pode medir e controlar o consumo. Permitindo ser proativo e detectar qualquer desvio de consumo antes que o usuário perceba gargalo no sistema.

Você consegue medir e gerenciar recursos em um ambiente tradicional? Com certeza, mas não na granularidade e integração que o Oracle Exadata permite.

PRÓXIMO ARTIGO

No próximo artigo falarei sobre como você pode monitorar e gerenciar o ambiente, quais as ferramentas necessárias e o que consultar.