Ok, Ok, Ok amigo, acho q estes em PERL eu tenho, eu consegui baixar.. ehehehe,
mas blz.. muito obrigado pela atenção.
qualquer coisa eu dou um grito.. ehehe
Obrigado pela Atenção.
Att,
Welvis Douglas
Msn : [EMAIL PROTECTED]
- Mensagem original
De: jlchiappa [EMAIL PROTECTED]
Para: oracle_br@yahoogrupos.com.br
Enviadas: Segunda-feira, 7 de Maio de 2007 18:50:32
Assunto: Res: Res: [oracle_br] Re: Eventos de Espera.?
Colega, fui checar aqui em casa e o livro que eu tenho é o Optimizing
Oracle Performance , do autor cary Millsap, editora O´Reilly, Primeira
Edição, é esse mesmo que vc quer ? Pois fui checar e ele não veio com
CD algum de scripts, os (poucos) scripts que ele usa - como por
exemplo o script PERL de contagem de geytimeofday na pág. 153, ou os
exemplos de v$ no cap. 08: Fixed view reference - todos estão listados
no próprio livro, quais scripts que vc quer ??? E se vc não quiser
digitar, no Prefácio ele já nos diz que as memas listagens estão
online em http://www.oreilly. com/catalog/ optoraclep/ , é isso ? Ou é
outro o livro a que vc se refere ?
[]s
Chiappa
--- Em [EMAIL PROTECTED] os.com.br, Welvis Douglas Silva Moreto
welvinho18@ ... escreveu
Olá Chiappa, tudo bem ? você conseguiu ver os scripts lá no seu livro?
pois eu tenho o livri em pdf, ai não preciso estar comprando...
ai mando imprimir.. fica mais facíl.
att,
Welvis Douglas
- Mensagem original
De: jlchiappa [EMAIL PROTECTED] ..
Para: [EMAIL PROTECTED] os.com.br
Enviadas: Sexta-feira, 4 de Maio de 2007 14:07:32
Assunto: Res: [oracle_br] Re: Eventos de Espera.?
Ah, pra complementar ficou faltando eu dizer mais algumas
coisas :primeiro, de forma alguma vc deveria estar preocupado com o
fato de aparecerem muitos full scans, NEM SEMPRE um full scan
é mau, nem sempre é bom... O que vc tem que estar preocupado é
com a EFICIÊNCIA, com quantos logical I/Os vc teve que fazer
Assim, se um dado plano está fazendo um full scan MAS vc testou e
sabe que a query vai recuperar poucas linhas E que se usar um índice
y, ou se fazer um hash join ao invés de nested loop, ou o que for, vc
obtém a mesma resposta com qtdade de LIOs menor, ENTÃO SIM esse full
scan é mau, já se vc quer ler uma larga proção da tabela, quer
aplicar paralelismo, não há como se acessar via índice porque alguma
das colunas indexadas não está no WHERE ou não está sendo restringida
por valor algum, AÍ um suculento full scan é ** exatamente ** o que o
dr. recomendou, esse full scan é bom...
Quanto à eficiência, é se assegurar que o scan acessa a MENOR
quantidade de blocos possíveis no MENOR TEMPO : por exemplo se vc
tiver uma high-water mark desnecessariamente alta vc vai ter lotes de
blocos inúteis sendo lidos, se o seu db_file_multiblock_ read não
estiver no máximo aceitável pelo SO + hardware, E/OU se o extent size
não for adequado, vc não está lendo o máximo possível no menor
tempo Da mesma forma, quando eu falei em alteração física em
msg anterior, quero dizer algo do tipo : SE vc deixar a storage como
default quando cria uma tabela, o bd VAI deixar um monte de
espaços vazios à espera de futuros UPDATEs, então a mesma
quantidade de linhas com o default ocupa via de regra MUITO MAIS
blocos do que se vc tivesse não reservado esse espaço, menos blocos
implica em menos I/O...
Outras alterações físicas podem ser ** extremamente ** úteis, por
exemplo : se vc frequentemente precisa recuperar apenas os
relativamente poucos registros dos clientes do estado SP, vc ter um
índice que indexa apenas essa porção dos dados 9via FUCNTION INDEX)
talvez aceleraria ENORMEMENTE , pois ainda que seja necesário um
scan seria feito scan no índice, que seria menor que a tabela por
conter menos dados... da mesma forma, Particionamento, Views
Materializadas, Clusters, tabela ordenadas na hora da criação, GTTs,
IOTs, etc, podem levar a reduções ASSOMBROSAS de I/O, vc TEM que as
conhecer todas E ver em que pontos da sua aplicação essas feats te
ajudam...
[]s
Chiappa
--- Em [EMAIL PROTECTED] os.com.br, jlchiappa jlchiappa@ ..
escreveu
Seguem respostas :
[EMAIL PROTECTED] com.br, Welvis Douglas Silva Moreto welvinho18@
escreveu
... é que aqui eu posso mexer nos Sql's pois temos os fontes dos
programas,.. ..
OK, então a alteração e tunning de SQLs deve ser facilitada aí
mais à frente porém, quando vc diz full scan, aqui se tem muito. e
outros eventos, o que eu quero frisar, deixar CLARO, é que SE O
BANCO está fazendo full scan é PORQUE a aplicação está assim o
exigindo, simples assim, o ponto é que NÂO TEM O QUE MEXER no banco
em si se o ajuste mais grosso do banco está feito, então a
pergunta
que vc tinha feito o que devo mexer no banco para eliminar waits
não tem um sentido, ok ??? O wait é SINTOMA, e e´sintoma CAUSADO
pelos SQLs da aplicação, é neles que vc vai mexer...
O que vc pode fazer se já não o fez a nível