Otimizando I/O com discos SSD

Olá pessoal,

     No artigo de hoje vou comentar sobre como otimizar I/O em Bancos de Dados Oracle, utilizando discos SSD (Solid-State Drives).

    Antes, porém de falar sobre o assunto principal, quero informar que o conhecimento que irei compartilhar neste artigo foi adquirido em um dos projetos de "Otimização de Performance" em que estive engajado este ano (2015). Este projeto consistiu em otimizar a performance de uma aplicação de Business Inteligence utilizada por uma grande associação do comércio varejista nacional. O Banco de Dados dessa aplicação tinha algumas centenas de gigabytes de dados e possuía instalado o SGBD Oracle 11G Standard Edition.

     Neste projeto, entre diversas configurações e recursos que eu apliquei para otimizar o Banco de Dados, vou comentar somente sobre a experiência que tive com a implementação de índices em discos SSD. Ao pesquisar um pouco sobre SSD, podemos descobrir que atualmente ele pode ter uma performance de 5 a 10 vezes superior a de um HDD (em operações de leitura), mas é importante ressaltar que eles de destacam somente nas operações de leitura, causando muitas vezes problemas em Bancos de Dados Oracle, nas operações de gravação intensas, tais como, na gravação dos Redo Logs. Mesmo nas operações de leitura, nem sempre você consegue um ganho considerável, e eu descobri isso na prática, pois o ganho depende muito do tipo de SSD e características dos dados armazenados.

     No trabalho em que tive experiência, uma das principais instruções SQL do sistema que estava sendo executado no BD, demorava em média 44,15s para realizar uma consulta analítica complexa, que acessava dados de 2 tabelas e que fazia muito I/O físico. Esse tempo corresponde à média da 1ª execução do SQL, pois a partir da 2ª execução o Oracle fazia somente I/O lógico, e o tempo caía para menos de 2s. O que eu precisava realmente otimizar era o I/O físico, portanto após cada execução do SQL eu fazia uma limpeza da Buffer Cache executando o comando ALTER SYSTEM FLUSH BUFFER_CACHE:

      Ao analisar o plano de execução deste SQL verifiquei que as operações de maior custo correspondiam ao I/O físico que ocorria na tabela TAB_B, e em 2 índices dela: 

   

     O servidor do Banco de Dados era um Dell PowerEdge R520 com 6 HDs SAS (15.000 RPM) de 600 GB cada, montados em RAID 10; e 2 drives SSD SATA (MLC de 3GB) de 100 GB cada.

     Primeiramente tentei otimizar a performance do I/O físico movendo as tabelas para um tablespace que tinha 1 datafile criado em 1 dos discos SSD. Resultado: não vi melhoras na performance da consulta.  Fui então pesquisar sobre o porquê da consulta na tabela não ter obtido melhoras na performance. Descobri que uma operação de FTS (Full Table Scan) pode muitas vezes não apresentar diferença de desempenho em discos SSD, porque ela executa leituras sequenciais, que normalmente não são tão lentas em discos HDD, quando comparadas ao mesmo tipo de leitura em SSD. Fui então pesquisar sobre índices em SSD, e descobri que estes são os que mais poderiam obter ganhos de performance, pois leituras em índices normalmente não são sequenciais (em um HDD), o que pode gerar muitas rotações em disco e alta latência para recuperar os dados. 

      Então, o que eu fiz em seguida? Executei um REBUILD nos índices movendo-os para outro tablespace que tinha 1 datafile criado em um dos discos SSD. Adivinhe o que aconteceu? O tempo médio da consulta caiu para 17,71s, ou seja, o SQL teve um ganho de desempenho de 249%. Para ver mais detalhes sobre este assunto, participe do treinamento Database Performance Tuning.

Bom pessoal, por hoje é só!

Espero que este artigo seja útil! 

Por favor, contribua deixando um comentário se tiver alguma experiência semelhante.

Se quiser aprender mais dicas sobre como otimizar I/O com discos SSD,

leia o artigo Otimizando Bancos de Dados Oracle com Database Smart Flash Cache

Referências:

     - DE-CONFUSING SSD (FOR ORACLE DATABASES;
     - Afraid of SSD?