Seguem alguns coments e adendos : --- Em oracle_br@yahoogrupos.com.br, "Jemerson Dutra" <[EMAIL PROTECTED]> escreveu > > 5 DISCOS > SCSI 1OK RPM
ok, 10k RPMs é o padrãozão em hds SCSI, normal . Só tinha perguntado porque já vi uns hds com menos (7500, tipicamente) serem oferecidos, e não era disco refurbished, era novo mesmo! Blz. > Independentes Como eu disse, talvez um array ajudasse, mas já que é uma opção cara e que implica em re-feitura de ambiente, em princípio vamos deixá-la pra uma próxima, se mais nada ajudar. > 1 controladora SCSI Esse ponto pode pegar, por melhor que seja a controladora, não é certo que ela consiga atender simultaneamente e eficientemente os vários "pedidos" dos vários discos, que provavelmente devem ser simultâneos ou quase. Bem, os testes que vc vai fazer vão dar dicas a respeito, se o select em tabelas independentes do sistema demorar demais, a gente pensa mesmo é em subsistema de I/O afogado, de repente os discos ficm "esperando" disponibilidade da controladora, mas antes de palpitar vamos ver no que resultam os testes... Já que vc vai fazer mesmo, seria legal vc fazer uma vez com o banco startado mas sem sistema rodando, uma vez com o sistema ativo mas com poucos (ou nenhum) usuários conectados, e finalmente uma outra vez em uso normal. Lembre também que o que nos interessa aqui é tentar "validar" a hipótese de hardware de I/O com probs (talvez de dimensionamento), então a idéia é tentar minimizar a influência de outras fatores, como caches e rede, assim o teste deveria ser executado DIRETAMENTE no sqlplus do servidor Oracle, conectando como sqlplus userdonodastabelas/senha (sem o @string, queremos conexão local), , peça um SET TIME ON TIMING ON no sqlplus, e antes de cada execução manda um ALTER TABLESPACE nomedatablespaceondeestãoastabs OFFLINE e um ALTER TABLESPACE nomedatablespaceondeestãoastabs ONLINE , pra que seja feito basicamente só PIO (não estamos zerando utilização de caches, óbvio, já que forçosamente cada bloco após lido por um SELECT ** tem que ** ir pro cache e cada bloco tem n registros), mas estamos diminuindo a "participação" do cache nesse timing. > > MULTIBLOCK_READ ??? (chiappa, novamente onde vejo exatamente qual o > maximo permitido pelo meu servidor?) Existem outras maneiras, mas como normalmente isso é uma quantidade de blocos que totaliza 1Mb, ou coisa do tipo, pra vc saber é testar, vc cria uma tablespace LMT uniform size de 10Mb, cria nela uma tabela qquer com PCTFREE 1 PCTUSED 99 e com várias centenas de milhares de linhas, e faz um trace 10046 level 12 de uma sessão fazendo SELECT /*+ FULL */ * from nomedatabela, isso resulta num arquivo .TRC que entre muitas outras vai ter linhas do tipo : WAIT #3: nam='db file scattered read' ela= 249287 p1=41 p2=4234 p3=nnn nnn é a quantidade de blocos que ele pôde ler duma vez, db_file_multiblock_read_count deve ter o maior dos nnn que vc achar no arquivo. > > > TABLESPACE LMT system-allocated Imagino que sejam TODAS as tablespaces (dados, índices, etc) lmt system-alloc, certo ? ok, isso já elimina de cara a chance de fragmentação , então . Para explicar uma eventual ineficiência em I/O resta a possibilidade de high-water muito alto, ou PCTFREE/PCTUSED incorretos, mas vamos por partes , vamos ver os testes antes de avançar por aí. > > LOGS: > 6 REDOLOGS DE 50MB NESSE DISCO 5 (O MAIS ACESSADO) essa info é importante, os log files estão no disco que está sendo mais acessado, hmmm. Será que não são eles que estão causando esse acesso todo ? Além do log_checkpoint_interval (que iirc vc já disse que estava com 10000, e eu sugeri aumentar isso), como estão os demais (ie, log_checkpoints_to_alert e log_checkpoint_timeout) ?? Será que está havendo troca de log files constantemente ? Normalmente isso fica registrado no alert_nn.log do servidor, veja lá... A idéia normalmente é vc ter um arquivo de log bem grande (se hoje vc está com 50 Mb, tente recriá-los com 200 Mb), e ter um log_checkpoint_interval muito grande e log_checkpoint_timeout como zero, para tentar influenciar a qtdade de redo, o manual "Oracle9i Database Performance Tuning Guide and Reference" no cap. 17 - Configuring Instance Recovery Performance no link "Reducing Checkpoint Frequency to Optimize Runtime Performance" fala um pouco disso... > > TEMP: > 2 DATAFILES DE 500MB NESSE DISCO 5 ( O MAIS ACESSADO) datafiles ou tempfiles ????? DEVERIA ser tempfiles, deveria ser tablespace lmt (suponho que seja), e tira isso desse disco mais acessado, bota num outro menos, talvez no que tem o SO... > > select * from v$sga; > NAME VALUE > -------------------- ---------- > Fixed Size 741816 > Variable Size 536870912 > Database Buffers 50331648 > Redo Buffers 2191360 Como tinha dito em outra msg, sobe aí o block buffer pra coisa da centena de Mbs. > > vou colar mais tarde o resultado do teste das tabelas. > > Jemerson > Obs: acrescentei mais 2 gb de ram e a maquina deu uma melhorada nada > absurdo mas o suficiente para diminuir a pressao. Cara, se vc subiu a RAM experimente subir bem aí também o sort_area_size, pra algumas dezenas de Mbs talvez. Não lembro se vc estava setando hash_area_size ou não, se estiver remova esse param que ele assume 2x sort-area_size, é suficiente normalmente. Vamos ver se isso te ajuda, e não deixe de mandar os testes, especificando em que situação foi executado cada um, o select usado e os scripts de CREATE e de INSERTs das tabelas, pra se preciso a gente reproduzir também e termos uma base de comparação entre máquinas. []s Chiappa -------------------------------------------------------------------------------------------------------------------------- Atenção! As mensagens deste grupo são de acesso público e de inteira responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ --------------------------------------------------------------------------------------------------------------------------__________________________________________________________________ Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine __________________________________________________________________ O grupo Oracle_br não aceita anexos. Quando oferecer algum arquivo, tenha o link do mesmo para evitar trafego(pedidos) desnecessário. 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
