SQL> desc v$asm_diskgroup
Name Null? Type
----------------------------------------- -------- ----------------------------
GROUP_NUMBER NUMBER
NAME VARCHAR2(30)
SECTOR_SIZE NUMBER
BLOCK_SIZE NUMBER
ALLOCATION_UNIT_SIZE NUMBER
STATE VARCHAR2(11)
TYPE VARCHAR2(6)
TOTAL_MB NUMBER
FREE_MB NUMBER
REQUIRED_MIRROR_FREE_MB NUMBER
USABLE_FILE_MB NUMBER
OFFLINE_DISKS NUMBER
COMPATIBILITY VARCHAR2(60)
DATABASE_COMPATIBILITY VARCHAR2(60)
SQL> select GROUP_NUMBER, NAME, STATE from v$asm_diskgroup;
GROUP_NUMBER NAME STATE
------------ ------------------------------ -----------
1 ORADATA MOUNTED
0 ORADATA1 DISMOUNTED
SQL> ALTER DISKGROUP ALL DISMOUNT;
Diskgroup altered.
SQL> select GROUP_NUMBER, NAME, STATE from v$asm_diskgroup;
GROUP_NUMBER NAME STATE
------------ ------------------------------ -----------
0 ORADATA DISMOUNTED
0 ORADATA1 DISMOUNTED
SQL> ALTER DISKGROUP ALL MOUNT;
Diskgroup altered.
SQL> select GROUP_NUMBER, NAME, STATE from v$asm_diskgroup;
GROUP_NUMBER NAME STATE
------------ ------------------------------ -----------
1 ORADATA MOUNTED
0 ORADATA1 MOUNTED
Essa semana estou em um cliente aqui do interior fazendo uma instalação Oracle RAC 11gr1 no AIX 6.1.
Todos os pré reqs feitos, tudo configura e pronto para instalar. Foi lindo ver o runcluvfy mostrar que toda configuração realizada estava “successful”.
A surpresa foi ao executar o runInstaller, um erro de compilação java muito estranho apareceu:
O erro é disparado devido a variável de ambiente JAVA_COMPILER. Para que o Java trabalhe sem problemas com o runInstaller, essa variável deve estar setada para NONE.
export JAVA_COMPILER=NONE
Quem é gerente de TI já sabe, como é difícil encontrar pessoas qualificadas na TI, isso não tem sido diferente com produtos Oracle. A preocupação com isso tem sido tanta que vários parcerias envolvendo universidades, empresas e instituições que estão traçando planos para criar e aperfeiçoar profissionais.
Veja mais detalhes no site da ItWeb.
Parte 1 - Introdução
Parte 2 - Criação e configuração da VM
Parte 3 - Criação do Oracle Linux
Parte 4 - Configuração do Oracle Linux
Parte 5 - Configuração do Oracle Linux II
Parte 6 - Clonagem da VM e criação dos disk image
Parte 7 - Configuração dos discos ASM e OCFS2
Parte 8 - Instalação do Oracle Clusterware
Parte 9 - Aplicação do Patch 10.2.0.5 no Oracle Clusterware
Parte 10 - Instalação Oracle Database 10g
Parte 11 - Aplicação do Patch 10.2.0.5 no Oracle Database
Parte 12 - Criação do Listener e ASM em modo cluster
Parte 13 - Criação do banco de dados
…
Arregace as mangas … hora de instalar o Oracle RAC 10g.
Durante as próximas semanas, estarei escrevendo sobre a instalação do Oracle RAC 10g Release 2 utilizando VirtualBox para simular as máquinas do cluster. Estaremos fazendo toda a instalação, desde o linux como parâmetros de kernel, memória, instalação de pacotes até a aplicação do patch 10.2.0.5 e os PSU’s recomendados pela Oracle.
No final dessa série do artigo também vamos aprender como adicionar e remover um nó e mudar os IP’s virtual/privado/public do cluster.
Veja a lista abaixo, dos softwares necessários para a instalação. Observe que os softwares abaixo são todos em x86, mais nada impede de você instalar x86-64, claro … mudando assim os pré requisitos na instalação do cluster/banco para essa versão.
- VirtualBox 4.0.8
- Oracle Database 10g R2
- Oracle Clusterware 10g R2
- Oracle Enterprise Linux 5 (qualquer update)
- Patch 8202632: 10.2.0.5.0 Patch Set
Lembro aqui, que essa instalação é somente para aprendizado e testes. Para instalações em produção e ambiente de desenvolvimento deve-se obrigatoriamente ler todo o manual antes de começar a instalação.
Não tem porque você aprender apanhando. Banco de dados não é aparelho eletrônico que você aprende fuçando, tem que arregaçar as mangas e estudar!
Segue a documentação oficial da Oracle sobre a instalação do Banco e Cluster Oracle 10g Release 2 para Linux x86:
- http://download.oracle.com/docs/cd/B19306_01/install.102/b15660/toc.htm
- http://download.oracle.com/docs/cd/B19306_01/install.102/b14203/toc.htm
Cuidem de sua infra estrutura e de seus backups ou você pode ficar sem banco de dados !
ORA-00600: internal error code, arguments: [kccpb_sanity_check_2], [2101], [2100], [0x0], [], [], [], []
Início da história … a noite anterior o erro, houve um corte de energia sem motivo aparente e os no-breaks pra variar não aguentaram, decorrer da história já deu até para imaginar … Banco danificado!
Já no outro dia verificando como estava a saúde do ambiente depois do impacto, aparentemente tudo normal. Sistema Operacional Linux Red Hat Enterprise 5 trabalhando, nenhum erro nos logs apesar da queda
Hora de checar o banco, bem nele, que as coisas começam a piorar …
Ao executar um simples startup do banco, para desespero de todos, um ORA-600 é disparado na tela. O interessante que o erro não sinalizava nada no meta link pela versão de banco 10.2.0.3.
Verificando o alert log do banco foi fácil perceber que o problema estava sendo disparado bem na hora de ler os controlfiles. Pensei, que algum controlfile devia estar corrompido. Teria sido muito mais fácil se os controlfiles estivessem multiplexados … tirava o ruim, copiava um novo de um bom e pronto, é … teria sido rápido … mais eles não estavam multiplexado. Tudo estava um um group ASM chamado DATA de um único disco.
Como havia backup horas antes do problema e tudo o archive necessário até aquele momento, a operação de recuperação do banco foi tranquila apesar do susto e nem muito demorada apesar do tamanho do banco. Foi simplesmente restaurado o controlfile de um backup controlfile, feito o recover do banco e aplicado os archives até o momento da queda. Nenhum dado perdido, nenhuma informação deixada para atrás … assim é o Oracle : )
RMAN> restore controlfile from '/backup/bkp_controlfile.ctl'; RMAN> recover database;
Apesar de todo o susto, no final foi deu tudo certo para esse ambiente, mais nem sempre é assim. Já vi empresas perderem muito dinheiro por não terem cuidado simples, como validação de backup e manutenção em seus equipamentos (no-breaks, gerados, etc …). Ter uma infra estrutura e uma equipe técnica preparada e pronto para atender, faz muita diferença na hora resolver problemas e catástrofes como essas.
Simulando o erro:
SQL> create table t ( id number); Table created. SQL> alter table test add constraint pk_name primary key (id); Table altered.
Observe que sempre que é criado uma constraint do tipo Primary Key um Unique Index é criado automaticamente, ele está implícito na cláusula da criação da constraint.
Isso é muitas vezes esquecido, o que leva muitos a tentar criar um index para a coluna PK obtendo o erro ORA-01408
SQL> create index idx_name on t(id); create index idx_name on t(id) * ERROR at line 1: ORA-01408: such column list already indexed
Simulando a criação manual de um Index Unique
SQL> alter table t drop constraint pk_name; Table altered. SQL> alter table t add constraint pk_name primary key(id) using index (create index idx_name on t(id)); Table altered. SQL> select index_name from dba_indexes where table_name='T'; INDEX_NAME ------------------------------ IDX_NAME



