Alert! Onde foi parar o alert log no 11g?

De acordo com a nota metalink - 438148,1, começando com a versão 11g, o arquivo de log de alerta - alert log file - agora é escrito também no formato XML. O local padrão de ambos arquivos fica na ADR (repositório de diagnóstico automático - traduzido).

O ADR é definido usando o parâmetro de inicialização DIAGNOSTIC_DEST. Se este parâmetro for omitido, o local padrão será </u01/app/oracle/diag/rdbms/.../...>.

Em resumo, sua localização segue o padrão: ADR: ADR_BASE / diag / product_type / product_id / instance_id

Além disso, dentro do diretório home ADR estão os seguintes subdiretórios:
 
Alert - O alert.log no formato XML.
Trace- alert.log e traces files
cdump - Core Dump

O alert.log formatado em XML terá a nomencaltura "log.xml"

Quer simplificar ainda mais??

Execute a consulta abaixo no  seu banco de dados:

SQL>  show parameter background

e o resultado será...

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
background_core_dump                 string      partial
background_dump_dest                 string      /oracle/app/oracle/diag/rdbms/PROD/PROD/trace 

Quando fazer Rebuild de um índice - index rebuild

Depois de sofrer um pouco com a indisponibilidade do sistema devido a árdua tarefa de fazer rebuilds em índices no banco de dados Oracle, decidi escrever sobre este assunto.

Afinal, qual é a frequência que devemos fazer index rebuild?

É de importância fundamental fazer a reconstrução dos índices de uma tabela... para manter o dba ocupado!

Isso mesmo. Na imensa maioria das vezes, fazer index rebuild somente piora a situação. Vejam os motivos para evitar esta desnecessária perda de tempo (do DBA) e de performance (do Banco de Dados):

1) Os espaços entre linhas deletadas nos índices são reaproveitados através de novos inserts na tabela;
2) Uma tabela com várias linhas deletadas apresenta fragmentação também no índice. Mas para resolver o problema devemos primeiro fazer o rebuild da tabela;
3) Um rebuild numa tabela cria um rebuild implícito nos seus índices;

E tem mais:

O processo de rebuild consome muito recurso na geração de estatísticas
•Estas estatistics resultam em problema de  locking nas tabelas
•Index rebuilds geram uma enorme quantidade de overheads no Redo log
•Index rebuilds (feitos online) exigem locks que impactam na performance (resolvido na versão 11g)
•A performance do banco pode piorar após a execução de index rebuilds
•Index rebuilds podem gerar o erro ORA-123 em queries longas

Sobre a constante tarefa de fazer rebuild em índices, vejam o que os experts em Oracle tem a dizer:

A grande maioria dos índices não requerem rebuilds. Os principais mitos sobre index rebuild são:
•Índice do tipo B-tree indexes ao longo do tempo ficam desbalanceados
•Linhas deletadas dentro dos índices não são aproveitadas
•Se um índice passa de 3 níveis ele fica ineficiente
•Se um índice tem um fator de clusterização ruim ele precisa sofrer rebuild
•Para se ter excelente performance os índices precisam ser regularmente reconstruídos





Quem quiser saber mais (e dar umas risadas) leia no link abaixo uma explicação bem humorada no site asktom.oracle.com (em inglês):

Outras referências:

When Should You Rebuild an Index?

How to predict Index blevel and when to rebuild

Index-internals: Rebuilding the Truth

ORA-12640, ORA-21561: Falha na geração do OID

Erro ORA-12640 ou ORA-21561? Você já teve este problema no seu site?

No ambiente Windows, estávamos enfrentando um erro que impedia novas conexões no banco de dados. O erro era ORA-12640: "Authentication adapter initialization failed" - Falha na autenticação.

Nosso ambiente é complexo e com um eleavado número de conexões.

Após alguma pesquisa, descobri que bastava substituir o parâmetro SQLNET.AUTHENTICATION_SERVICES, no arquivo SQLNET.ORA, de NTS para NONE. Pronto! Nunca mais eu veria este erro, certo?

Na verdade eu troquei 6 por meia dúzia. Depois dessa mudança passei a receber o erro ORA-21561: Falha na geração do OID. Como resolver esta situação?

Veja as dicas abaixo:

Causa: O problema ocorre devido a um aumento no volume de conexões no banco de dados. O Windows estava com um valor baixo para o parâmetro SharedSection heap.

Solução:
1) Altere o parâmetro no arquivo sqlnet.ora no servidor do banco de dados

• SQLNET.AUTHENTICATION_SERVICES=NONE

2) No servidor de aplicação vá para: Iniciar (Start) do Windows entre em executar (RUN) digite:

• regedit 

3) No editor da registry do Windows vá para:

• \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems\

4) Clique com o botão direito na chave "windows" e altere o valor:
De:

• %SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,3072,512 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off MaxRequestThreads=16

Para:

•  %SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,3072,1024 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off MaxRequestThreads=16

Este terceiro valor do parâmetro SharedSection que estava em 512 representa o desktop heap para cada estação que conecta ao windows. No nosso caso o valor 1024 resolveu o problema, mas você deve fazer testes e ajustar conforme sua necessidade.
  Veja mais sobre o parâmetro SharedSection no site da Microsoft:
http://support.microsoft.com/kb/184802 


Sucesso!


Luis Adelson.

Como Acessar um Banco de Dados Sem Senha

É possível acessar um banco de dados sem a password do esquema?

Podemos simplesmente alterar a senha do esquema. Contudo, podem existir aplicativos associados àquela antiga senha. Neste caso, você irá habilitar-se ao esquema temporariamente, executar a atividade que precisa e logo em seguida retornar a senha antiga.

Na sequência abaixo coloco dois exemplos de como fazer este procedimento.

SQL> CONNECT / as sysdba
Connected.

SQL> SELECT password FROM dba_users WHERE  username='SCOTT';
PASSWORD
--------------- ---------------
F894844C34402B67

SQL> ALTER USER scott IDENTIFIED BY anything;
User altered.

SQL> CONNECT scott/anything
Connected.

OK, we're in. Let's quickly change the password back before anybody notices.

SQL> ALTER USER scott IDENTIFIED BY VALUES 'F894844C34402B67';
User altered. 

Uma forma mais simples é usa a query que irá gerar o SQL do comando para retornar a senha antiga:

Script:

SQL> SELECT 'ALTER USER '||USERNAME||' IDENTIFIED BY VALUES '''||PASSWORD||''';'
  FROM DBA_USERS, GLOBAL_NAME
 where username in ('USR_PGEPLANO');

 

SQL> ALTER USER scott IDENTIFIED BY VALUES 'F894844C34402B67'; 

Para descontrair...

Sucesso!

Luis Adelson 

Como habilitar ARCHIVE no Oracle RAC

1. Entre em um dos nós (por exemplo: racnode1) e desabilite a opção de cluster da instância, isto é, altere o atributo cluster_database para FALSE:
   
   

   $ sqlplus "/ as sysdba" SQL> alter system set cluster_database=false scope=spfile sid='racdb1';

2. Tire todo mundo do ar (Shutdown all instances):
   
   

   $ srvctl stop database -d racdb

3. Volte novamente a sua instância que você alterou o atributo de cluster e inicie o banco em MOUNT:
   
   

   $ sqlplus "/ as sysdba" SQL> startup mount

4. Agora habilite o modo archive:
   
   

   SQL> alter database archivelog;

5. Volte novamente o atributo de cluster para verdadeiro:
   

   SQL> alter system set cluster_database=true scope=spfile sid='racdb1';

6. Tire a instância do ar:
   
   

   SQL> shutdown immediate

7. Agora pode por tudo no ar usando o comando srvctl:
   
   

   $ srvctl start database -d racdb

8. Se o serviço estiver fora do ar, use o comando srvctl para por novamente ativo:
   
   

   $ srvctl start service -d racdb

   
   
9. Entre na instância local e veja se o banco está em modo archive:
   
   
   

   $ sqlplus "/ as sysdba" SQL> archive log list Database log mode Archive Mode Automatic archival Enabled Archive destination USE_DB_RECOVERY_FILE_DEST Oldest online log sequence 83 Next log sequence to archive 84 Current log sequence 84

Após estes procedimentos, cada instância do RAC poderá arquivar seus redologs!


Abraços e Sucesso!


Luis Adelson

Como mover uma TABLESPACE num ambiente Oracle RAC ASM

Usar comandos ASM num ambiente RAC é uma coisa muito chatinha... (pra dizer o mínimo). Não podemos reclamar, afinal é isso que nos mantem empregados ;-).

Bom, depois de suar muito, descobri como copiar arquivos entre diskgroups num ambiente Oracle RAC ASM. Vejam estas dicas muito fáceis!

Como mover datafiles entre diskgroups:
1) Coloque a tablespace offline (indisponível para uso):
     SQL> ALTER TABLESPACE exemplo OFFLINE;
2) Entre na ferramenta RMAN do Oracle:
     [oracle@rac1 racdb]$ rman target / nocatalog
3) Copie os datafiles para o diskgroup desejado:
     copy datafile '+DG_DISK3/sysdb/datafile/datafile1.dbf' to '+DG_DISK1'; (estamos movendo do diskgroup 3 para o diskgroup 1)
4) Anote o nome que será gerado para o datafile no diskgroup de destino (ver passo3)
5) Renomeie o datafile para o nome que o RMAN gerou no passo 3
     alter database rename file '+DG_DISK3/sysdb/datafile/datafile1.dbf' to 'nome do rman passo 3';
6) Repita os passos acima para copiar outros datafiles, se for preciso;
7) Coloque as tablespaces online:
     SQL> ALTER TABLESPACE exemplo ONLINE;

Simples, não é mesmo? Mas e se você quiser mover a tablespace SYSTEM ou a SYSAUX? Aqui é que a porca torce o rabo...

Nada de muito complicado, mas será preciso tirar o banco de dados do ar e somente funcionará se seu banco estiver no modo archive. Veja como fazer:

Como mover tablespace SYSTEM e SYSAUX para outro DISKGROUP (RAC com ASM)

1) Identifique a localização da tablespace SYSTEM e do seu respectivo datafile:
    SQL> select ts.name,df.name from v$datafile df,v$tablespace ts where ts.ts#=df.ts# and ts.name='SYSTEM';
2) Entre na ferramenta RMAN do Oracle:
     [oracle@rac1 racdb]$ rman target / nocatalog
3) Copie o datafile para o novo diskgroup:
     RMAN> backup as copy tablespace system format '+DG_DISK1';
4) Tire o banco de dados do ar:
     RMAN> shutdown immediate;
5) Reinicie o banco com a opção MOUNT:
    RMAN> startup mount;
6) Informe a nova localização do datafile:
    RMAN> switch tablespace system to copy;
7) Execute a recuperação do banco de dados:
    RMAN> recover database;
8) Abra o banco:
    RMAN> alter database open;

Para a tablespace SYSAUX a sequencia é a mesma, ok?

Felizmente na versão 11g já existe um opção para copiar arquivos dentro do próprio ASM. A coisa tá melhorando...


Abraços e Sucesso!

Luis Adelson
PS. As vezes fico sem escrever porque acho que alguns artigos são simples demais. Vocês poderiam sugerir algum assunto para ser dismitificado aqui?