Eu ja tive um problema no oracle 9i que todo dia aparecia um monte de
deadlocks no meu alert.log
do tipo SSX , pesquisando nos foruns da Oracle e no metalink descobri que o
problema era exatamente este,
falta de um indice na FK.
apos a criação do indice nunca mais deu deadlock.
2008/1/29 Andre Santos [EMAIL PROTECTED]:
Rafael
Tenho a mesma opinião. É bom avaliar esses itens.
Porém também é importante saber das escovações de bits dos
especialistas:
Ask Tom - Indexes on foreign keys
http://asktom.oracle.com/pls/asktom/f?p=100:11:626949234877112P11_QUESTION_ID:292016138754
[ ]
André
Em 29/01/08, Rafael Uchôa [EMAIL PROTECTED]rafaeluchoa%40yahoo.com.br
escreveu:
Acredito que são estilos de projeto, ou seja, tem vantagens e
desvantagens nas duas abordagens.
Se o seu problema é seleção, criar indexes é muito importante, se o seu
problema são processos que incluem, alteram e excluem registros, indexes
serão um problema.
Outro problema de indexes, quando o seu problema é seleção, são quando
eles se tornam grandes demais. Problemas que estou enfrentando hoje, o
CBO está sempre escolhendo um TABLE FULL ao invés de usar os indexes.
Estamos pensando em particionamento, limpeza de tabelas de histórico, e
outras estratégias.
Welvis Douglas escreveu:
Então, aqui na empresa estou assumindo o lugar de outro dba.. ai
quando fui fazer uma manuteção com a supervisão dele.. estava para
criar uma indice para FK, ai perguntei para ele... e ele disse que
isso tbm não precisa mais...
bom resumindo, 4 pessoas que conheço DBA's falaram que é mito, porem
aqui onde eu trabalho eles tem essa cultura...
sacou,
eu tenho tabela aqui com mais de 20GB, um indice desse deve ser bem
grandinho.. né...
poderia diminurir um certo espaço.. , mas como é um problema
cultural...
fazer o que.. kk
abraço
- Original Message -
From: Andre Santos
To: oracle_br@yahoogrupos.com.br
oracle_br%40yahoogrupos.com.broracle_br%40yahoogrupos.com.brmailto:
oracle_br%40yahoogrupos.com.br
Sent: Tuesday, January 29, 2008 3:18 PM
Subject: Re: [oracle_br] Criação de Índices em Chaves Estrangeiras
Welvis
Será que é mito mesmo?
Já li algumas coisas referentes a lock para verificação de
integridade
referencial, que seria melhor caso houvesse um índice na FK.
Precisaríamos verificar... vou tentar pesquisar algo a respeito.
De qualquer forma, o que o Adriano mencionou sobre o maior custo num
INSERT
com 10 índices é verdade.
Pessoalmente, acho que é melhor analisar os casos em que seria melhor
ter um
índice (e não criá-los indiscriminadamente para todas as FK's).
[ ]'s
André
Em 29/01/08, Welvis Douglas [EMAIL PROTECTED]welvis%40stcruz.com.br
welvis%40stcruz.com.br
mailto:welvis%40stcruz.com.br escreveu:
Meu amigo, quando eu fiz o curso do 10g em 2005, a pessoa que deu o
curso disse que esse era um mido to oracle 8.
...
att,
Welvis Douglas
- Original Message -
From: Adriano de Oliveira
To: oracle_br@yahoogrupos.com.br
oracle_br%40yahoogrupos.com.broracle_br%40yahoogrupos.com.br
mailto:oracle_br%40yahoogrupos.com.br
oracle_br%40yahoogrupos.com.br
Sent: Tuesday, January 29, 2008 11:05 AM
Subject: [oracle_br] Criação de Índices em Chaves Estrangeiras
Olá pessoal, bom dia.
Sei que a criação de índices em chaves estrangeiras é indicada
para se ter uma boa performance no banco.
Mas deve-se criar para todas as chaves estrangeiras ou tem que
se ter uma análise delas e escolher as chaves mais consultadas, etc?
Por exemplo, se eu tiver uma tabela com 10 chaves estrangeiras
(hipoteticamente),
se eu criar um índice para cada chave estrangeira, pode ser que o
select
se torne rápido, porém um insert, ou update vai ficar mais lento
pela
atualização
dos 10 índices.
Qual a opinião de vcs?
[]'s
Adriano
[As partes desta mensagem que não continham texto foram removidas]
[As partes desta mensagem que não continham texto foram removidas]
[As partes desta mensagem que não continham texto foram removidas]
[As partes desta mensagem que não continham texto foram removidas]
___
Yahoo! Mail - Sempre a melhor opção para você!
Experimente já e veja as novidades.
http://br.yahoo.com/mailbeta/tudonovo/
[As partes desta mensagem que não continham texto foram removidas]
[As partes desta mensagem que não continham texto foram removidas]
