ASM New Features 11g

Poisé galera, lá vamos nós! Hoje vou aproveitar que estou passando por experiências com o ASM num ambiente RAC Extended 11gR2 e comentar algumas mais importantes New Features do ASM. Alguns buxos também apareceram e tivemos que resolver também. O ASM (Automatic Storage Management) é um grande recurso da Oracle que foi desenvolvido com o intuito de facilitar a administração de volumes físicos para serem utilizados pelo banco de dados. Possui vários recursos interessantes como espelhamento de discos, striping, etc. e alguns novos na versão 11g.

Quando você cria um diskgroup no ASM da primeira vez na versão 11g ele cria como padrão compatível com 10g (10.1), ou seja, os atributos COMPATIBLE.ASM e COMPATIBLE.RDBMS estão 10.1 e desta forma tais novos recursos não seriam habilitados. Creio que o Oracle faz isso para permitir que você utilize numa possível migração 10g>11g recursos como Transportable Tablespace ou afins. O atributo COMPATIBLE.ASM permite que novos recursos do ASM sejam utilizados e o COMPATIBLE.RDBMS é comparada com o valor do parâmetro "compatible" da instância do banco de dados que está ligado àquele diskgroup. Há uma dependência entre os dois atributos onde o COMPATIBLE.RDBMS não pode estar numa versão superior ao do COMPATIBLE.ASM. Se você não for utilizar recursos como Transportable Tablespaces ou afins para realizar uma migração de banco de dados ou vai utilizar aquele mesmo diskgroup pra armazenar bancos de dados 10g e 11g, é recomendável que estes atributos sejam modificados para 11.1 ou 11.2 dependendo da versão. Depois dos atributos modificados você poderá usufruir dos novos recursos.

Para alterar os atributos:


SQL> alter diskgroup DATA set attribute 'compatible.asm'='11.2';
SQL> alter diskgroup DATA set attribute 'compatible.rdbms'='11.2';

OBS: Depois de atualizado o valor não pode ser retornado para um versão anterior.


Para mudar o comportamento padrão na criação dos Diskgroups:


SQL> alter system set "_asm_compatibility"='11.2' scope=spfile sid='*';
SQL> alter system set "_rdbms_compatibility"='11.2' scope=spfile sid='*';


Restart das instâncias ASM e pronto.
  • Privilégio novo: SYSASM:

Esse novo privilégio faz com que algumas rotinas administrativas do ASM fiquem mais restritas. Para executar rotinas como gerenciamento de diskgroups, etc será necessário entrar com esse privilégio:


$ sqlplus / as sysasm


  • Fast Mirror Resync:
No 10g quando algum disco do diskgroup era perdido por algum motivo, ele já era excluído de imediato. Após repor o disco era necessário adicioná-lo novamente e a operação de rebalanceamento se iniciava. No 11g o disco é posto OFFLINE e o ASM mantém as informações dos extents para enviar àquele disco quando o problema for resolvido. Quando o disco ficar OK basta executar o comando "ALTER DISKGROUP dg_name ONLINE ALL;" para repor todos os discos que estavam offline em online novamente. O processo de rebalanceamento será muito mais rápido. Por padrão você tem 3.6Horas para repor este disco antes que ele seja eliminado, mas isso é outro atributo que pode ser alterado.
  • Prefered Read;
Um recurso bem interessante. Parâmetros são definidos em cada instância ASM, útil quando o ambiente é RAC Extended (Um nó em um site e outro nó em outro site),  que irão priorizar a leitura do FAILGROUP daquele DISKGROUP, ou seja, o storage do site 1 terá preferência de leitura no site 1 e no site 2 leitura preferencial do storage 2. Isso otimiza bastante o desempenho em leitura evitando "round-trips", ou seja, voltas e voltas para entregar um dado. Imagine uma sessão de um usuário que está no site 1 que é aberta no site 2, executa uma consulta que traz dados do storage do site 1 (o Oracle não sabe diferenciar onde é mais perto), o dado sai do site 1 para o site 2 e volta pro site 1 entregando o resultado para a sessão. Pense numa viagem!
Para habilitar o recurso:


SQL> alter system set asm_preferred_read_failure_groups='DATA.SITE1','FLASH.SITE1' sid='+ASM1';
SQL> alter system set asm_preferred_read_failure_groups='DATA.SITE2','FLASH.SITE2' sid='+ASM2';



  • Suporte para large allocation units (AUs);

O ASM agora suporta unidades de alocações de até 64MB. Unidades maiores podem ser vantajoso quando o ambiente é DataWarehouse onde há aplicações que utilizam leitura sequencial.

  • Rolling upgrade e patching*;

Na versão 11g do ASM é possível realizar atualizações e correções com o ambiente no ar. Este recurso de chama Rolling Migration e requer que o Clusterware esteja na versão mais nova no ambiente.
Antes de começar é preciso colocar as instâncias no modo Rolling Migration:


SQL> ALTER SYSTEM START ROLLING MIGRATION TO 11.2.0.2;




Este comando não executa exatamente a migração, ele prepara as instâncias ASM no cluster para a migração. Este estado não persiste se as instâncias falharem durante o processo.

Para verificar o estado do ambiente ASM (Normal ou Rolling Migration) execute a consulta:


SQL> SELECT SYS_CONTEXT('sys_cluster_properties', 'cluster_state') FROM 
DUAL;

Quando estiver em "Rolling Migration" cada instância ASM pode ser desligada e atualizada. Quando o software for atualizado em uma instância, ela pode ser reiniciada e os diskgroups montados. Desta forma uma instância ficará numa versão mais nova que as demais no ambiente, isso só é permitido no estado "Rolling Migration".


Resumindo, os passos para execução do processo de Rolling Migration são:
1. Tenha certeza que o software para a nova versão está instalado em todos os nós.
2. Tenha certeza que o Clusterware está na versão mais alta.
3. Tenha certeza que as instâncias ASM estão na mesma versão Oracle.
4. Tenha certeza de que não há operações de rebalanceamento em execução (v$asm_operation). Se tiver, aguarde a conclusão.
5. Coloque o cluster ASM em "Rolling Migration".
6. Desligue uma instância ASM.
7. Inicie uma instância ASM do ORACLE_HOME com o novo software.
8. Repita os passos 4 e 5 até que todas as instâncias ASM sejam atualizadas.
9. Quanto o software estiver atualizado em todas as instâncias, desabilite o modo Rolling Migration:

SQL> ALTER SYSTEM STOP ROLLING MIGRATION;

* Trecho retirado do livro (traduzido e com adaptações):
LONG, R.; VALLATH, M.; VENGURLEKAR, N. Oracle Automatic Storage Management. Oracle Press,  New York, p.60-61, 2007

Até mais!

Comentários

Postagens mais visitadas deste blog

ALTER USER IDENTIFIED BY VALUES

Evitando FULL TABLE SCANS quando usar IS NULL em cláusulas WHERE

Restore no RMAN falha com "ORA-01180: can not create datafile 1"