Recently I made a tweet about a new project with Oracle Engineered System (X9M) that remembered me about what I made with these systems until now. So, this opened the opportunity to tell my background and history until now working with these systems. Is not a show-off of ego boost post.
Metrics for Exadata deliver to you one way to deeply see, and understand, what it is happening for Exadata Storage Server and Exadata Software. Understand it is fundamental to identify and solve problems that can be hidden (or even unsee) from the database side. In this post, I will explain details about these metrics and what you can do using them.
My last article about Exadata Storage Server metrics was about one example of how to use them to identify problems that do not appear in the database side. In that post, I showed how I used the metric DB_FC_IO_BY_SEC to identify bad queries.
The point for Exadata (that I made in that article), is that most of the time, Exadata is so powerful that bad statements are handled without a problem because of the features that exist (flashcache, smartio, and others). But another point is that usually, Exadata is a high consolidated environment, where you “consolidate” a lot of databases and it is normal that some of them have different workloads and needs. Using metrics can help you to do a fine tune of your environment, but besides that, it delivers to you one way to check and control everything that’s happening.
In this post, I will not explain each metric one by one, but guide you to understand metrics and some interesting and important details about them.
It is well known that Exadata delivers a lot of power for databases and, besides that, has a lot of features that can be combined to reach the desired goals. But you need to understand how to use Exadata, it is not just knowing the internal hardware pieces, put some SQL hints, or use smart scan that makes a better DBA (or DMA).
Think about the “traditional” environment (DB + storage) and how you check for performance problems there. Basically, you just have/receive the number of IOPS from luns, throughput in MB/s, and latency from the storage side. But Exadata provides a lot of metrics that go beyond that and can be used to really understand what it is happening between the database and the access of data blocks.
For me, one of the most underrated (and not even well explained in web) features of Exadata is the metrics because they can help you to really understand Exadata deeply. As an example, from metrics, you can check the MB/s read from flash cache, disks (per type), flash log writes, reads that bypassed flash cache and went to disk, Smart I/O per database, PDB or consumer groups. It is not part of this post explain all the metrics (will be in another one), but you can read more at Chapter 6 of the Exadata User Guide.
In this post, I will show you one example of how to use the metric to identify and solve database problems. Sometimes it can be a hide and seek game, but I will try to show you how to use metrics and how they can help you on your daily basis.
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.
O que é Oracle Exadata? Essa é uma pergunta que você já deve ter ouvido por ai, bom vou tentar responder (ou ajudar a responder). Respondendo da forma mais direta possível: Oracle Exadata (ou Oracle Exadata Database Machine) é um applicance criado pela equipe de Engineering Systems da Oracle e dedicado exclusivamente para que bancos de dados Oracle (versões 11 e 12) sejam executados com a maior performance e disponibilidade possível, independe do tipo (OLTP, DSS ou DW).
Legal não é? Mas o Oracle Exadata é muito mais do que isso, existem diversos detalhes técnicos de hardware e software que são muito importantes e transformaram o Oracle Exadata em um sucesso e desejo de muitos. Neste artigo, e nos próximos, vou falar somente sobre o Oracle Exadata, mostrar detalhes técnicos e algumas decisões gerenciais que estão ligadas a ele. Vou deixar de lado os detalhes comerciais (que você acha em qualquer documento que passou pela equipe de marketing da Oracle) e falar do técnico.
No dia 31/07/2013 apresentei o 2º Webinar do Exadata SIG, este sobre gerenciamento de recursos em um ambiente Oracle. O Webinar cobriu diversos assuntos, incluindo Resource Manager, IORM, Instance Caging e algumas dicas sobre o gerenciamento do Exadata.
A principal idéia que tentei passar no Webinar é que usando o Exadata podemos administrar e gerenciar todos os recursos do ambiente. Podemos gerenciar as conexões através do uso de services do Oracle RAC, número de CPU disponíveis através o instance caging, divisão do CPU através do Resource manager, e gerenciamento do IO através do IORM. O importante é a integração que o Exadta permite.
Claro que não é só o Exadata que pode tirar proveito destas funcionalidades, um Oracle em um ambiente tradicional também pode se beneficiar de algumas delas. A única restrição é em relação ao IORM. Caso você queira ler mais sobre o IORM pode ler alguns posts que fiz sobre ele aqui no site (aqui, aqui e aqui).
O link para download do Webninar é este (Webinar-Gerenciamento-de-Recursos) . Ele está em formato PDF, os arquivos externos que estão na apresentação estão aqui (Anexos-Webinar-Exadata) em formato ZIP.
Caso queira saber mais sobre o Exadata SIG, você pode visitar a página do GUOB e clicar na aba “GUOB Exadata SIG”.
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.
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.