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.

Continue lendo…

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.

Recentemente comentei com alguns amigos que escreveria aqui com mais frequência, escreveria sobre assuntos relacionados ao Exadata e afins. Bom, como podem ver, não deu muito certo. Assumo a culpa, foi um mês corrido, problemas para resolver, bugs, o de sempre da vida de um DBA.

Hoje vou começar uma série de posts sobre o que eu acredito ser uma das funcionalidades mais interessantes do Exadata, o I/O Resource Manager (IORM). Resumindo, para quem não sabe, com o IORM é possível priorizar e categorizar o I/O no Exadata. Como o nome já sugere, é um resource manager.

Mas antes de explicar sobre ele, vamos voltar um pouco. Quando você pensa em Exadata uma palavra que vem sempre a mente é consolidação. Consolidar bases de dados em um único local para aproveitar o máximo de recursos. Essa é uma das vantagens, mas vamos encarar os detalhes.

Em um ambiente de banco de dados normal você tem os servidores de bancos de dados (cuidando basicamente do processamento) e o storage, separados. Se você tiver vários bancos, você faz o que? Separa a carga, correto? E com o storage você faz o que, separa os bancos em Raid Groups diferentes? Luns diferentes para cada base?

Você deve estar se perguntando o que isso tem haver com o Exadata, simples. Lembra da palavrinha consolidação de alguns parágrafos acima? No Exadata além de ter servidores para banco de dados (os database servers), você tem o “storage” (os storage servers). Resumindo, estes últimos entregam o “espaço” para o ASM que estão nos database servers. O conceito de luns como em um storage comum desaparece. Falarei com detalhes isso em outro post.

Com a consolidação, você acaba “puxando” todas as bases para um único local tanto em servidores de banco quanto em storage. Você tem que começar a definir as prioridades sobre as bases de dados evitando assim concorrências entre elas. Como no Exadata você não pode trabalhar da mesma forma como um storage normal (acho que nem seja esse o intuito), você utiliza o IORM para administrar o I/O do seu Exadata. Definindo prioridades e catagorias para o I/O das bases que estão no Exadata.

Bem, o IORM é mais do que isso, a granularidade sobre o I/O é bem maior. Como falei acima, esse é o primeiro post de muitos. Na internet você encontra bastantes detalhes sobre o IORM e o Exadata. Se você tem acesso ao Metalink (sim, sou old school) verifique a nota 1187674.1, lá você encontrará um white paper sobre o Storage Server do Exadata, vale a leitura.