Pros params específicos do CBO (ie, optimizer_nnn) um bom seria o clássico paper "The Search for Intelligent Life in the Cost-Based Optimizer", online em http://www.evdbt.com/papers.htm . Pra testes de comportamento/tunning do CBO, o indicado é o não menos citado "A look under the hood of CBO: the 10053 event" em www.hotsos.com na seção Library - enquanto estiver por lá aproveita e veja também o "Why a 99% + Database Buffer Cache Hit Ratio is Not Ok", tem muito a ver com otimização em geral, mas se aplica bem em DW. Pros parâmetros *mult* (em especial o db_file_multiblock_read_count, se for banco 9i só ele), http://www.ixora.com.au/ tem o script pra vc testar o valor máximo aplicável, e na minha apresentação no ENPO eu demonstrei que além disso multiblock read só acontece SE o extent estiver de tamanho apropriado, também. []s Chiappa --- Em oracle_br@yahoogrupos.com.br, "Tecnico - consulting" <[EMAIL PROTECTED]> escreveu > > Chiappa, > > Quanto a questão que vc comentou sobre CBO > > >os de performance do CBO (em especial os *multi* ), tem q questão do > >gerenciamento das tablespaces e dos extents..... > > Vc tem algum notes sobre este assunto ?? > > > Edson Almeida Junior > > > > > -----Mensagem original----- > De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] > Em nome de jlchiappa > Enviada em: quarta-feira, 20 de julho de 2005 13:08 > Para: oracle_br@yahoogrupos.com.br > Assunto: [oracle_br] Re: Melhoria na Configuração de Servidor Oracle DW > > > Além de NOLOGGING, em se falando de DW torna-se URGENTE a > investigação de DIRECT/APPEND mode e de bulk/array processing - este > último em especial. Tipicamente em DW a carga é feita a partir de um > arquivo-texto, e se o processo for linha-a-linha , tipo : > > FOR linhas do arquivo LOOP > le uma linha > envia um INSERT pro banco > END LOOP; > > isso não voa. E pior ainda, se for : > > FOR linhas do arquivo LOOP > le uma linha > envia um INSERT pro banco > commit; > END LOOP; > > aí o negócio já foi pra cucuia, mesmo. > > A maneira típica de se fazer carga com essas opções (ie, direct, > parallel, array, sem tentar manter índices pois foram desabilitados, > etc) é pelo sqlloader, ele tem opções pra isso. > > Quanto ao INIT : sim, ele não me parece numa rápida olhada muito > apropriado. > > Pontos que eu questionaria com o DBA : > > > open_cursors=500 > > SE vc estiver processando em paralelo, pode meio que tranquilamente > abrir mais que isso, eu chutaria uns 1500 pelo menos... > > > > > ########################################### > > # MTS > > ########################################### > > dispatchers="(PROTOCOL=TCP)(SER=MODOSE)", > > "(PROTOCOL=TCP)(PRE=oracle.aurora.server.GiopServer)", > > "(PROTOCOL=TCP)(PRE=oracle.aurora.server.SGiopServer)" > > MTS & DW, água & óleo, coisas que POSITIVAMENTE não se misturam.... > > > > > ########################################### > > # Miscellaneous > > ########################################### > > compatible=9.0.0 > > é bd 9.2.x.y ?? Se sim, salvo recomendação EXPRESSA do fabricante, eu > ATIVARIA as features, colocando = 9.2.x.y > > db_name=dw > > > ########################################### > > # Processes and Sessions ########################################### > > processes=200 > > meio pequeno isso... > > > > > ########################################### > > # Redo Log and Recovery ########################################### > > > fast_start_mttr_target=300 > > negativo, eu colocaria fast_start_mttr_target=0 e > log_checkpoint_interval=numerobemgrande, num dw normalmente não há > sentido em se ter logs frequentes, já que qquer coisa vc re- processa > o arquivo de carga.... > > > > > ########################################### > > # Sort, Hash Joins, Bitmap Indexes > > ########################################### > > hash_area_size=12048576 > > sort_area_size=15048576 > > eu vi mais abaixo que vc tem workarea=MANUAL, então o que tá valendo > são esses caras aí de cima. 12 Mb pra sort e 15 Mb pra hash num DW é > ** piada **, por natureza um DW faz poucos SQLs mas monstruosos, com > LOTES de sorts e hash.... Eu diria PELO MENOS uns 128 Mb pra sort e > 256 pra hash... > > > > ########################################### > > # System Managed Undo and Rollback Segments > > ########################################### > > undo_management=AUTO > > undo_retention=1200 # Tempo no qual os dados processados > > serão retidos 1200 = 20 minutos > > 20 minutos não é muito pouco não ??? Tipicamente num DW é comum vc > ter queries que duram MUITO MAIS q isso > > > > > job_queue_processes = 30 > > 30 job slaves , ou seja, 30 processos além dos demais ??? Carácoles, > quantas CPU vc tem pra dar conta disso tudo ??? > > > > pga_aggregate_target = 12719430400 > > meio estranho, pga_aggregate setado mas workarea_size = manual, o que > vc quis obter com isto ??? > > > > ====>> E ainda faltam aqui os params de paralelismo, os de > performance do CBO (em especial os *multi* ), tem q questão do > gerenciamento das tablespaces e dos extents..... > > []s > > Chiappa > > > > > > ______________________________________________________________________ > > Histórico: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ > Falar com os Moderadores:([EMAIL PROTECTED]) > Dorian Anderson Soutto - Fernanda Damous - Alisson Aguiar > ______________________________________________________________________ > Links do Yahoo! Grupos
______________________________________________________________________ Histórico: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ Falar com os Moderadores:([EMAIL PROTECTED]) Dorian Anderson Soutto - Fernanda Damous - Alisson Aguiar ______________________________________________________________________ Links do Yahoo! Grupos <*> Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ <*> Para sair deste grupo, envie um e-mail para: [EMAIL PROTECTED] <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
