Ah, o ponto mais importante só pra variar ia esquecendo ... Com certeza, quando vc diz que tem tabelas com duzentas e tantas colunas, é grande a chance aí de vc estar tendo row chaining, em http://asktom.oracle.com/pls/asktom/f? p=100:11:0::::P11_QUESTION_ID:19013375626973 o autor mostra como testar por isso - SE realmente é o seu caso, isso é um argumento pró um aumento no bloco, mas PLEASE, antes de partir pra isso, veja a chance de normalizar um pouco esse modelo, quando se vê tabela com dúzias de colunas de imediato se pensa é em falha de modelo....
[]s Chiappa --- Em oracle_br@yahoogrupos.com.br, "jlchiappa" <[EMAIL PROTECTED]> escreveu > > Não é OLTP o meu banco, mas vamos ver até onde consigo te ajudar . > Por partes : primeiro, embora a Oracle não tenha uma recomendação > exata para isso, a documentação envolvida são os manuais de Concepts > e de Tunning, e no metalink principalmente a nota nro 46757.1 "Notes > on Choosing an Optimal DB BLOCK SIZE" . Depois, tendo os conceitos > referentes à essa atividade bem claros (se não os tem, re-estudo das > fontes citadas), vamos pensar juntos - a vantagem principal de um > bloco maior é que vc popupa I/O, no seguinte esquema : suponha um > banco (ou uma tablespace, no 9i) com blocksize de 8 Kb e uma > aplicação que frequentemente necessita de dados de vários e vários > blocos, se vc precisa (digamos) de dados de dois blocos o bd teve em > tese (ignorando os casos de multiblock read) que fazer dois I/Os, e > já que cada I/O implica (em tese) em espera por seek time, por > rotação de disco, etc, se essa operação fosse feita com blocksize de > 16 Kb vc fez um único I/O, poupou-se algum tempo, às vezes até coisa > de alguns pontos percentuais. > =====>>> PORÉM, notar que estamos falando de economia em cima duma > operação que custa *** MILISEGUNDOS **, obviamente uma aplicação > teria que fazer MUITO e MUITO I/O pra que essa "economia" seja > notável, alguns % de uns tantos milisegundos normalmente é coisa ** > DESPREZÌVEL ** ... > O segundo efeito (também citado e deduzido das docs citadas) é que, > como os caches do bd são criados/mantidos em RAM e controlados via > latches e similares, certamente se vc tiver um bloco maior menos > blocos serão necessários para se controlar a mesma qtdade de RAM, > portanto menos listas de controles, menos latches, etc, seriam > necessários em tese, MAS novamente só mesmo em caches ** enormes ** > vc veria alguma diferença.... E não esquecendo que a cada release o > bd se torna mais eficiente na administração desses caches, o > algoritmo está constantemente melhorando, também.. > > > Então, à vista do acima citado, eu penso que em sendo OLTP nada > disso se aplicaria muito : em OLTP é bem menor que em DW a chance da > aplicação precisar de infos que com bloco maior cairiam no mesmo > bloco (oltp é tipicamente bem aleatória a recuperação de dados), e > ainda por cima em oltp por maior que seja a base atual, tipicamente > vão ser recuperados via índice relativamente POUCO disso, > relativamente pequenas FRAÇõES do todo.... Óbvio ululante, vc VAI > testar antes no seu banco de testes/homologação, principalmente a > chance de se ter os índices em bloco maior, mas acho que muito > provavelmente os seus testes aí serão negativos.... Em sendo CPU o > seu principal problema e sistema oltp (onde são queries relativamente > simples, com poucos dados retornados MAS com enorme massa de usuários > fazendo operações similares) , acho que a estratégia de ataque seria > ** mesmo mesmo ** é na aplicação, se ASSEGURANDO que a aplicação faz > 1 parse e vários executes, usa bind variables, NÃO faz context > switch, NÃO usa & abusa de loops e cursores aonde o processamento > poderia ser feito num SQL só, NÃO chama dentro do SQL functions > PL/SQL... Via de regra essas coisas QUEIMAM CPU , detonam, comem-na > no café da manhã, é a primeira coisa que teria que ser vista... > > []s > > Chiappa > > --- Em oracle_br@yahoogrupos.com.br, "logg" <logg@> escreveu > > > > blz, até aqui tudo bem, > > já tinha visto isto, tanto é que minha suspeita é esta, pois meu > storage é um cavalo e com isto não tenho problemas de I/O , tendo > problemas sim de processamento da maquina, chegando a dar 100% dos 15 > processadores... > > > > > > > > > > De:oracle_br@yahoogrupos.com.br > > > > Para:oracle_br@yahoogrupos.com.br > > > > Cópia: > > > > Data:Sun, 15 Apr 2007 11:05:06 -0300 > > > > Assunto:Re: [oracle_br] Blocagem diferente no Oracle > > > > Acho que este aqui pode ser interessante, > > > > http://www.dba-oracle.com/art_dbazine_9i_multiblock.htm > > > > logg escreveu: > > > > > > Senhores, ja li muito a respeito disso no Oracle, agora oq peço é > a > > > experiência de vcs, alguém utiliza isto em ambiente OLTP?? > > > Tenho um banco grande, coisa de uns 5TR, minhas tabelas estão > > > desnormalizadas, tenho tabelas com coisa de 250 campos e tudo > isto com > > > blocagem default do oracle. A minha idéia seria criar uma > tablespace > > > com uma blocagem maior e mover estas minhas tabelas com grande > > > quantidade de campos para lá para ver se consigo um aumento na > > > performance e diminuindo assim a grande leitura de blocos . > > > Alguém tem alguma documentação sobre este tipo de aplicação em > > > ambiente OLTP ?? > > > > > > vlw > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > -- > > Atenciosamente, > > > > Rodrigo Mufalani > > OCA 10g > > tel.: 91739169 > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > >
