Primeiramente gostaria de agradecer a todos pelas respostas.
Em segundo lugar, gostaria de comentar sua mensagem, Chiappa. Concordo com vc que podemos fazer muito pouco sem termos um DBA para levantar todas as análises que vc sugeriu, mas já estou no olho do furacão, fui escalado pra tentar resolver esse problema e uso da minha posição pra fazer o possível, mas a minha grande dificuldade tem sido ter uma idéia do que seria melhor para o Oracle em teremos de Storage, se usar Raid 5, 10, 0+1, ou se deveria usar ASM. Ambos aplicam a metodologia SAME, certo? Enfim, fui convencido pelo BAARF que RAID 5 não seria o ideal para esse caso já que nosso problema tem sido desempenho, e como ele traz um overhead de escrita, descartamos essa hipótese. Trabalho agora com a hipótese de utilizar os 4 discos em Raid 10 (ou 0+1) com todos os arquivos do SO, mais os datafiles sendo distribuídos pelos discos, ainda com ganho de segurança pelo mirroring. Outra hipótese seria utilizar um disco para SO + aplicação e os outros 3 deixar para o Oracle gerenciar com ASM. Não tenho experiência com ASM e isso me dificulta a decidir qual seria mais viável. Chiappa ou alguém da lista, poderia me dar uma sugestão do que fazer nesse caso? O gargalo principal é desempenho, mas a vantagem de redundância do RAID 10 também conta como um ponto importante. O ASM me permite alguma forma de redundância? Há algum acréscimo considerável de performance? Chiappa, quanto aos outros pontos que vc levantou: 1) Tenho certeza que eles não fizeram todo o tunning SQL possível, com uma análise bem rasa tenho achado indicadores importantes, como gravações excessivas em arquivos de índices, etc, mas isso é o que a equipe de desenvolvimento me passou. Como disse, não sou DBA e não tenho a obrigação de encontrar todos esses erros, tenho apenas que fazer o possível para melhor o desempenho do Oracle em termos de I/O, o que encontrar de errado quanto às queries já é lucro pra eles... 2) Quando disse que gostaria de utilizar LVM para evitar problemas com partição lotada por escrita indiscriminada da aplicação, eu estava me referindo a aplicação que solicita o I/O, não o Oracle. A aplicação nesse caso coleta informações de elementos externos e faz uso intensivo de escrita em períodos pré-determinados, somando-se a isso o cliente gera relatórios que fazem muita leitura em alguns períodos do dia, muitas vezes essas tarefas são realizadas ao mesmo tempo, por isso tenho um tempo de resposta muito lento. Fiz a pergunta quanto ao LVM pois já vi gente falando que isso pode gerar uma complexidade desnecessária dependendo do layout de storage adotado. Se eu tiver os 4 discos em Raid, tenho que tipo de implicações usando LVM? Nesse caso seria melhor eu esquecer do LVM e fazer uma grande partição com todos os datafiles (que seriam distribuídos por todos os discos em stripping)? 3) Passei esses dias analisando o desempenho da máquina e notei que o backup está sendo feito pelo cliente durante o dia, na verdade eles começam de noite, mas há troca de fita e é finalizado perto da hora do almoço. Um dos indicadores negativos que o ADDM me aponta é escrita excessiva em arquivo de log, essa pode ser uma das causas? Quanto de perda de performance pode ser devida a essa estratégia de backup? Devo argumentar isso com o cliente? Pessoal, realmente muito obrigado pela ajuda. Abraços Heber Blain Gonçalves _____ De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de jlchiappa Enviada em: terça-feira, 22 de maio de 2007 13:10 Para: oracle_br@yahoogrupos.com.br Assunto: [oracle_br] Re: Opinião para melhorar desempenho Colega, alguns comentários : a) sem um DBA experiente presente, vc vai poder fazer MUITO, mas MUITO POUCO mesmo, tunning e quetais simplesmente DEMANDAM que um profissional do tipo esteja trabalhando junto com os desenvolvedores, sem isso fica DISTANTE a sua chance de sucesso (não só pela dificulade de analisar e descobrir os melhores ajustes do banco, MAS também o DBA é o elemento que introduz as "novas" tecnologias de banco aos desenvolvedores : assim, um DBA experiente não deixaria de mostrar aos desenvolvedores tabelas GTTs, índices bitmap e de função, funções analíticas, sintaxes extendidas de SELECT (como WITH cluase por exemplo) e muitos mais, que aí sim seriam avaliadas pelos desenvolvedores e se cabíveis implementadas.... Aqui no cliente é um sistema DW, os programadores fizeram algumas queries caírem de 10 horas para meia hora usando GTTs, por exemplo, mas óbvio, primeiro eu tive que explicar pra eles o que é, como usa, não se foge disso.... b) "o pessoal de desenvolvimento já fez todo o tuning sql possível" : cara, dica geral e genérica : confie DESCONFIANDO quando o pessoal diz que já fez todo o tunning possível, de modo geral isso NÂO é a exata representação da verdade.... Pra vc ter uma idéia do nível de tunning que foi feito, peça pro analista : 1. mostrar o TKPROF (ou ao menos os EXPLAIN PLANs e/ou AUTOTRACEs !!) das principais queries do aplicativo, rodando num hardware o mais parecido possível com a Produção, e com volumes o mais parecidos que for possível e 2. mostrar no código-fonte deles AONDE os cursores são fechados, mostrar que REALMENTE eles estão usando BIND VARIABLES, fazendo array processing, etc e 3. veja a quantidade de stored PL/SQL usada, e a quantidade de SQL dinâmico usada ==> SE essas coisas não existirem, e ou se para 3. as respsotas não forem respectivamente MUITO e POUCO, ou se o analista fizer "hã ???", com uma cara abobada, quando vc perguntar delas, pode ter CERTEZA que NÂO, absolutamente NÂO FOI FEITO todo o tunning possível. Vc diz que os índices são "enormes", o pessoal CONHECE sobre compactação ? realmente FOI verificado que não há índices redundantes ??? Um índice seletivo, que indexe apenas PARTE dos dados via FBI, isso foi pensado/analisado ???? c) sobre I/O, primeiro temos que dizer que o bd Oracle absolutamente *** NÂO TEM *** um "parâmetro" que diga pra ele fazer mais ou menos I/O, se hoje vc está fazendo lotes e lotes de I/O e isso está interferindo na performance, COM CERTEZA o bd está fazendo esse I/O em ** resposta ** à um pedido da aplicação, novamente se toca no item b. aqui... Logicamente, até mesmo indiretamente a aplicação pode exigir I/O desnecessário (por exemplo, erradamente não fazendo operações NOLOGGING onde e quando indicado, aí NÃO TEM COMO o banco fazer algo diferente do que foi pedido, ok ? Só alterando a aplicação, MESMO... Quanto ao RAID-5, sim, em http://www.baarf. <http://www.baarf.com/> com/ é mais do que suficientemente mostrado que o RAID-5 acrescenta SIM um overhead de gravação, que SE é exigida performance absolutamente TOP vc necessariamente deveria fugir dele como o diabo da cruz, MAS isso sempre tem que ser avaliado no local - afinal, isso tem custo, muitas vezes não há verba nem justificativa para tal, aí vc vai ter que se virar com RAID-1 ou, se for exigido maior ênfase na segurança, é RAID- 5 nos datafiles (já que eles são gravados EM BACKGROUND, em muitos casos de menor porte o overhead aí é aceitável), MAS tomando o cuidado de tirar do RAID-5 os arquivos que são INTENSAMENTE gravados pelo Oracle, como log files por exemplo, aí alguns discos ficariam fora do RAID-5 e seriam espelhados à parte. d) LVMs : neste ponto, primeira coisa acho MUITO difícil "aumentar a segurança caso tenha um LV corrompido ou se houver um erro na aplicação e essa começar a escrever indiscriminadamente no datafile", já que, pela ordem, aplicação NENHUMA pode EM CASO ALGUM escrever em datafile NENHUM, NUNCA, a regra crucial no bd Oracle é que ELE e APENAS ELE SOMENTE escreve em datafiles, E pra segurança, também não vejo muita utilidade, pois corrupção num hardware server-class é algo MUITO raro, que só se explica por bug em software /firmaware ou pau em hardware, e ambos se ocorrerem tem ENORMES chances de afetarem múltiplos volumes, realmente não vejo qual segurança a mais ou a menos vc ganhou... Quanto à performance, SE todos os LVMs apontam pra discos do mesmo raid, mantidos pelas mesmas controladoras, REALMENTE também não vejo aonde vc ganharia ou perderia performance com isso, EXCETO SE o teu software de gerenciamento faça (por exemplo) uma LISTA de LVMs, ou que mantenha algum tipo de cache diferenciado por lvm, ou coisa no estilo, senão realmente não vejo.... []s Chiappa --- Em [EMAIL PROTECTED] <mailto:oracle_br%40yahoogrupos.com.br> os.com.br, Heber Blain Gonçalves <[EMAIL PROTECTED]> escreveu > > Olá, pesesoal, > > Tenho nível de conhecimento apenas operacional (instalação, > configuração básica, ...) de Oracle, mas agora estou participando de > um projeto em que não existe um DBA e precisamos resolver um problema > de performance de uma aplicação, a qual está sendo migrada para um > novo servidor. Estou sendo responsável por montar a arquitetura da > solução, mas estou bastante inseguro se o que estou propondo pode ou > não ajudar a melhorar a performance do lado da Infra-estrutura. (o > pessoal de desenvolvimento já fez todo o tuning sql possível, o > problema tem sido realmente IO em excesso para a máquina que não > suportava). > > A nova solução compreende um hw comprado pelo cliente, um Servidor > Dell com 4 HDs de 165 Gb e provavelmente uma controladora RAID, não > tenho acesso de que máquina específica estamos tratando, então > trabalho com essa suposição. > > Abaixo descrevo como pretendo montar a arquitetura desse servidor, por > favor, gostaria que comentassem se a idéia que tenho está correta e se > algo mais pode ajudar. > > - RAID 5 > > Estou pensando em dispor os 4 HDs no esquema de RAID 5, pois acredito > que esse tem um ótimo custo benefício, tendo redundância (segurança > também é um requisito), e aumentando as taxas de leitura pelo > paralelismo, já que os dados estarão distribuídos nos 4 discos. Mas e > quanto as operações de escrita? Existe um overhead por causa da > paridade ou isso tem pouco impacto? > > - LVM > > Já considerando que tenho um RAID 5, existe alguma vantagem em > distribuir os datafiles em diferentes volumes lógicos num VG? Por > exemplo: além das partições do SO, poderia ter particionado /LVdata1 > /LVdata2 e /LVdata3, cada um tendo uma parcela dos datafiles do banco. > Eu sei que isso pode me aumentar a segurança caso tenha um LV > corrompido ou se houver um erro na aplicação e essa começar a escrever > indiscriminadamente no datafile que encheria a partição. Se tive > apenas uma partição, nesse caso, com certeza todo o sistema estaria > comprometido, certo? Mas e quanto a performance, há algum ganho/perda > de desempenho em se utilizar LVM? > > - ÍNDICES > > Outro ponto diz respeito aos arquivos de índices, que no caso dessa > aplicação são enormes. Existe alguma best practice quanto a eles? > Deveria deixá-los num LV a parte? > > - PARTITIONING > > Essa foi uma sugestão dos DBAs do cliente, existe uma tabela que pode > ser facilmente particionada pelo campo mês. A minha dúvida aí reside > se nesse esquema de particionamento são criados vários arquivos, um > pra cada partição, ou se tudo se resume a um datafile. Se forem vários > arquivos, tenho vantagem em distribuí-los pelos diferentes LVs? (Se > não fosse usar RAID 5, a pergunta seria: teria vantagem em > distribuí-los nos vários discos?) > > Qualquer idéia ou comentário será muito bem-vindo !!! > > Obrigado, > ********************************************************************** Informação transmitida destina-se apenas à pessoa a quem foi endereçada e pode conter informação confidencial, legalmente protegida e para conhecimento exclusivo do destinatário. Se o leitor desta advertência não for o seu destinatário, fica ciente de que sua leitura, divulgação ou cópia é estritamente proibida. Caso a mensagem tenha sido recebida por engano, favor comunicar ao remetente e apagar o texto de qualquer computador. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by person or entity other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *************************************************** [As partes desta mensagem que não continham texto foram removidas]
