Voltar ao site

Conhecendo brevemente o Oracle ASM

27 de dezembro de 2015

Olá pessoal, neste artigo vamos conhecer um pouco sobre o ASM (Automatic Storage Management). O ASM é um software que gerencia os discos que serão utilizados pelo banco de dados Oracle que vamos instalar posteriormente. Normalmente as instalações básicas não fazem uso do ASM, pois é um recurso a mais que precisa ser instalado, configurado e administrado, mas deixando de usar o ASM você perde os seus benefícios. Para instalá-lo é necessário fazer download das mídias do Grid Infrastructure (GI) que contém os componentes do ASM e do Clusterware. Depois de instalar o GI e ter o ASM operando podemos instalar o software do banco de dados.

Automatic Storage Management

O ASM é um volume manager (gerenciador de volumes) e também um filesystem (sistema de arquivos) para os arquivos do banco de dados Oracle, e suporta configurações de bancos de dados Oracle single-instance e bancos de dados que usam Oracle Real Application Clusters (Oracle RAC). O Oracle ASM é a solução de gerenciamento de armazenamento recomendada pela Oracle que fornece uma solução alternativa aos volume managers, filesystems e raw devices convencionais.

O Oracle Automatic Storage Management usa diskgroups para armazenar os datafiles; um diskgroup é uma coleção de discos que o ASM gerencia como uma unidade. Num diskgroup é exposta uma interface de filesystem para arquivos do banco de dados Oracle. O conteúdo dos arquivos que são armazenados em um diskgroup são distribuídos uniformemente para eliminar hot-spots e fornecer um desempenho uniforme entre todos os discos.

Adicionar ou remover discos de um diskgroup é uma operação que ocorre de maneira totalmente online, depois de qualquer uma destas operações o ASM redistribui os dados entre todos os discos restantes do diskgroup. Por exemplo, temos um diskgroup chamado DATA, com redundância somente no storage, este diskgroup tem 4 discos de 100GB, totalizando 400GB para o diskgroup, temos utilizado apenas 200GB de dados, o balanceamento faz com que tenhamos 50GB de dados em cada disco do diskgroup DATA. Neste caso a conta é “espaço utilizado/quantidade de discos”, então 200GB/4=50GB. Se removermos um disco ainda teremos 300GB de tamanho total do nosso diskgroup e a distribuição dos dados ficará 200GB/3, pois agora teremos somente 3 discos, então a operação de rebalanceamento distribuirá aproximadamente 66,67GB para cada um dos três discos restantes e somente depois que esta operação de rebalanceamento terminar o disco será efetivamente removido do diskgroup, durante o processo o disco removido fica com um status de dropping. Ao adicionar discos a operação ocorre basicamente da mesma maneira. Temos 4 discos de 100GB para armazenar 200GB de dados, então temos 50GB em cada um dos quatro discos, se adicionarmos um quinto disco teremos 200GB/5 e cada disco passará a armazenar 40GB de dados quando a operação de rebalanceamento finalizar.

Esta imagem ilustra que os discos iniciais do diskgroup estão quase cheios, então são adicionados 2 novos discos de tamanho maior, depois que todos os discos estão balanceados, os discos iniciais (menores) são removidos e novamente o diskgroup é rebalanceado.

Vantagens x Desvantagens do ASM

Comparado a gerenciadores de volume padrões e filesystems (tanto clustered filesystem ou single filesystem), o ASM tem algumas vantagens:

  • Não é necessário grandes quantidades de memória para cache. A memória não necessária para cache pode ser utilizada para a SGA, que é mais eficiente. O ASM vai usar poucas centenas de MB de memória para seu gerenciamento interno.
  • Distribui “pedaços” de dados por todos os discos lógicos presentes em um diskgroup e assim remove os hot-spots.
  • Sozinho o ASM não realiza qualquer I/O, então não há uma “camada de tradução” do I/O do Oracle para os datafiles nos blocos do disco. Isso reduz a sobrecarga e melhora o desempenho.
  • Não há leituras adiantadas quando usamos ASM, portanto o uso do cache de memória nunca é utilizado pelo banco de dados.
  • Usando o ASM não precisamos de tuning intensivo como ajustar corretamente o tamanho dos fragmentos, ou qualquer tuning em filesystems. Quando criamos um diskgroup no ASM precisamos somente definir o Allocation Unit (AU). Torna-se improvável causar erros de configuração que causam problemas de desempenho se as premissas básicas de configuração do ASM são seguidas.
  • Não causa fragmentação (você pode até pensar que o balanceamento feito pelo ASM é algum tipo de fragmentação, porém os allocation units são grandes o suficiente (normalmente maiores que 1MB) para permitir pequenas buscas em disco de blocos subsequentes (normalmente blocos de 8KB).
  • Não quebra grandes operações de I/O (128KB) em múltiplas menores (4KB ou 8KB) como alguns filesystems fazem. É mais rápido fazer um I/O grande do que vários menores.
  • Nenhum log extra de consistência é necessário, pois isso já é função dos redologs do Oracle Database, então mais uma vez comparando com outros filesystems teríamos um overhead.
  • Podemos administrar o ASM através de ferramentas que o Oracle fornece, então não requer qualquer administração Unix (isso pode ser uma vantagem ou desvantagem dependendo das responsabilidades de cada administrador da corporação).
  • Adicionar ou remover discos no ASM é muito fácil e não requer todo aquele planejamento cuidadoso que se deve ter quando usamos volume managers ou filesystems. Depois de adicionar novos discos, o ASM faz automaticamente o rebalanceamento dos dados nos discos, então todos os discos têm uma utilização igual e isto mais uma vez traz ganhos em desempenho.
  • Roda na maioria dos sistemas operacionais e é independente de plataforma (RHEL, OEL, Solaris, AIX, HP-UX, Windows, …).

Também tem algumas desvantagens:

  • Migrar datafiles de filesystem para o ASM pode necessitar downtime. Isso já não é um problema a partir da versão 12c (12.1.0.1) onde podemos mover datafiles de maneira online, porém para migrar os controlfiles ainda temos que parar o banco de dados.
  • É difícil (acredito que impossível) de ver os conteúdos do ASM por ferramentas do SO. Em alguns casos os dados do ASM podem ser acidentalmente apagados pelos administradores do SO que estejam usando os discos que para eles parecem estar vazios ou sem uso. Mesmo assim temos métodos administrativos para evitar isso.
  • Não podemos fazer backups do conteúdo do ASM simplesmente com comandos do sistema operacional, então precisamos de uma ferramenta integrada ou usar ferramentas nativas do Oracle como o RMAN e o asmcmd.

Abraços,

Franky

Referências