Fala Pessoal,Acabei de ler um post muito interessante sobre o suposto apagao de talentos, tenho visto cada vez mais esse suposto apagao se referir a area de banco de dados e eu discordo muito disso, esse post excelente do Fabio Luiz retrata perfeitamente a minha visao sobre o assunto, vale a pena dar uma lida.http://blog.jumping.com.br/2012/05/o-mito-do-apagao-de-talentos/?goback=%2Egde_148535_member_117679150Abracos ! Fala pessoal, o 11g tem um recurso interessante que e habilitar o log de comandos DDLs no alert.log, para habilitar e bem simples basta alterar o parametro ENABLE_DDL_LOGGING para true, segue abaixo um pequeno step by step que altera o parametro e cria alguns objetos para teste.COLUMN DESCRIPTION FORMAT A30COLUMN VALUE FORMAT A30SET LINESIZE 120SQL> select value,isdefault,isses_modifiable, issys_modifiable,isbasic,description from v$parameter where name='enable_ddl_logging';VALUE ISDEFAULT ISSES ISSYS_MOD ISBAS DESCRIPTION------ --------- ----- --------- ----- -------------------FALSE TRUE TRUE IMMEDIATE FALSE enable ddl loggingSQL> alter system set ENABLE_DDL_LOGGING=true ;System altered.SQL> conn hudson/c402d92ConnectedSQL> create table t_hudson as select * from user_tables;Table created.SQL> grant select on t_hudson to public;Grant succeeded.SQL> alter table t_hudson read only;Table altered.SQL> drop table t_hudson ;Table dropped.Apos a alteracao do parametro vamos verificar se foi gerado o log no alert.log:[oracle@rjhud trace]$ tail -f alert_centro.logMon Nov 21 15:58:43 2011SMCO started with pid=31, OS id=5981Mon Nov 21 16:08:37 2011ALTER SYSTEM SET enable_ddl_logging=TRUE SCOPE=SPFILE;ALTER SYSTEM SET enable_ddl_logging=TRUE SCOPE=BOTH;Mon Nov 21 16:09:41 2011create table t_hudson as select * from user_tablesMon Nov 21 16:10:09 2011alter table t_hudson read onlydrop table t_hudsonPara maiores informacoes sobre o parametro e so consultar o link: http://download.oracle.com/docs/cd/E14072_01/server.112/e10820/initparams078.htm Fala pessoal vou falar de um assuntoque sempre gera alguma discussao nos ambientes em que esse assunto foilevantadoUltimamente tenho percebido certopadrao dizendo que nenhuma tabela pode ter mais de seis indices ou sete indicesem alguns clientes. Entao algumas instrucoes SQL podem executar bem, mas algumas podemnao executar tao bem assim e se precisarmos de mais indices nao podemosadicionar porque ja existem 6 indices entao algum teria que morrer para criarmais.Entendendo que muitas vezes algunsindices podem ser redundantes, podemos pensar no indice IDX_OMT_NAME_ID_01 em(COL1, COL2), IDX_OMT_NAME_ID_02 em (COL1, COL2,COL3), e IDX_OMT_NAME_ID_03 em (COL1,COL2,COL3,COL4).Nesses casos e comum que alguns DBAs pensem em dropar osprimeiros dois indices porque eles sao redundantes, ou seja, eles tem as mesmascolunas principais e na mesma ordem, como IDX_OMT_NAME_ID_03. Mas dropar indices redundantes pode causar problemascom a selecao de uma tabela de conducao de um join. (No post sobre metodos dejoin eu falo sobre tabelas de conducao ou driving tables).Quando temos muitos indices em umatabela, nao vamos obter um impacto grande em questoes de desempenho isso seestamos falando de sistemas OLTP, porque apenas algumas linhas sao processadas uma unica transacao, e o impacto de varios indices de emuma atualizacao geralmente nao e tao grande se comparado a ao desempenho de umaconsulta.Agora um numero alto de indices emuma tabela pode ser extremamente prejudicial para ambientes com grande numerode processos batch de atualizacao, ou seja com um numero alto de insets,updates e deletes.Veja um leve comparativo: Quantidade Linhas Quantidade de Indices Tempo 1000 0 00:00:00.41 10000 0 00:00:02.99 10000 1 00:00:05.88 10000 3 00:00:07.82 20000 5 00:00:59.69 Da para imaginar o problema quandotemos uns 8 indices de uma tabela com alguns GB