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:
Para mudar o comportamento padrão na criação dos Diskgroups:
Restart das instâncias ASM e pronto.
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:
Para habilitar o recurso:
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.
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:
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:
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:
- Prefered Read;
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
Comentários
Postar um comentário