quinta-feira, 23 de agosto de 2012

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 


terça-feira, 7 de agosto de 2012

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