Depois de um breve hiato (mais um), volto a falar sobre o IORM. Acredito que seja interessante a leitura do último post para quem está chegando agora.

Algo importante a ser observado no IORM é a granularidade, qual o nível de controle que você deseja ter sobre o I/O do seu Exadata. Até que nível de controle você deseja chegar, mas lembrando que quanto maior o controle maior a complexidade de gerenciamento.

Como disse no post anterior, o IORM é um resource manager. Desta forma a sua configuração é muito parecida com o Resource Manager do banco de dados, na realidade eles estão intimamente ligados. Devido a esta similaridade, a configuração do IORM baseia-se em níveis e alocação de recursos (cabe um adendo para dizer que pode ser por limite também).

Assim, no IORM você pode exercer este controle de algumas formas, basicamente por dois grupos: catplan e dbplan. O catplan é a distinção de I/O por categorias, estas definidas dentro de cada banco de dados. E o dbplan é a configuração baseada somente em banco de dados.

A definição de catplan vai além do IORM, ela vem diretamente do banco de dados. No catplan o I/O distribuído pelo plano do IORM leva em consideração as categorias definidas para o Consumer Group dentro do banco de dados. Por outro lado o dbplan faz com que a alocação de I/O seja direcionada pelo IORM entre os bancos de dados especificados no plano.

Um ponto importante, e uma das grandes vantagens do IORM para mim, é a possibilidade de utilizar mesmas categorias em bancos de dados distintos. Assim, por exemplo, você pode ter uma categoria batch no IORM para garantir (ou restringir) o I/O independente do banco de origem.

Você pode achar que isso estranho ou que não seja correto, mas em um cenário onde você tem diversos bancos no seu Exadata você não gostaria de ter uma rotina de carga de dados influenciando as consultas de sua aplicação crítica, não é? Se você estivesse utilizando somente o dbplan o batch de um banco poderia estar influenciando (leia-se roubando I/O) de outro banco.

Além disso, você pode utilizar o catplan e dbplan em conjunto, maximizando a granularidade do seu controle. Assim mesmo especificando categorias você pode definir qual o banco que receberá mais I/O daquela categoria. Supondo dois bancos A e B e duas categorias C e D em um plano onde a categoria C tem 70% de I/O e a D tem 20 % (sobrando 10% para qualquer outra) e o banco A com 60% e o B 40%. Isso significa que a categoria C tem garantia de 70% de I/O e o banco A tem garantia de 60% destes 70%.

Isso ocorre, pois o catplan tem prioridade sobre o dbplan. Infelizmente na documentação não existe esta definição clara desta relação, mas em uma SR tive uma conversa com a equipe de desenvolvimento e esta informação foi repassada.

Assim, você pode ter uma idéia básica de como a granularidade do IORM funciona, como você pode garantir a distribuição do I/O entre categorias e bancos de dados. Indo um pouco mais, você pode observar que o plano do IORM pode ser facilmente integrado com o Resource Manager do banco de dados e, indo um pouco mais fundo, integrado com serviços. Fica fácil ver até onde podemos chegar, até que nível de controle você pode ter e qual a granularidade de seu I/O.

Vamos aos fatos, qual o storage hoje em que você pode dizer que o I/O para o serviço que atende conexões web pode ter prioridade sobre o que atende conexões desktop, e isso independente do banco origem da conexão e sem fazer qualquer alteração na estrutura de seu banco? Fica fácil entender porque o Exadata não é somente hardware, e isso que nem falei tudo sobre o IORM (como por exemplo, desabilitar o uso da flashcache ou o tipo de carga).

Nos próximos posts falarei um pouco mais do IORM e, o mais importante, com exemplos.