Re: [oracle_br] RE: Tunning de Queries
Calma gente .. tem desenvolvedor na lista (eu) que gosta de escrever queries com qualidade (pelo menos tento). 2014-02-17 20:14 GMT-03:00 Roland Martins dadim...@yahoo.com.br: Rapaz, o que vemos por aí é a mesma coisa: o desenvolvedor escreve, quem tuna é o DBA. Visão errada esta, vários desenvolvedores sabem ler um plano, questionar estatísticas - de objetos e de sistema, histogramas, influenciar o CBO com hints, mas a qualidade de muitos desenvolvedores é bem ruim (eles ficam ali, escrevendo queries, mexendo nos celulares, sites de compras, viagens internacionais... e o desempenho da query ? Ah, a gente manda pros DBAs, aos 47 do segundo tempo, eles resolvem - e nem sempre do melhor jeito), isso quando o problema já não aparece direto em produção (tem lugares que funciona assim, todos sabemos) e aí é você que tem o pepino pra descascar. Mas, como diz aquele provérbio chinês, é melhor acender uma vela que queixar-se da escuridão. Chiappa está correto. Adiciono o que diz Thomas Kyte (na época do 8i Release 3, mas ainda atual): Here is a short extract from a book I am working on. The short answer is if you want a 10 step guide to tuning a query, buy a piece of software. You are not needed in this process, anyone can put a query in, get a query out and run it to see if it is faster. There are tons of these tools on the market. They work using rules (heuristics) and can tune maybe 1% of the problem queries out there. They APPEAR to be able to tune a much larger percent but that is only because the people using these tools never look at the outcome -- hence they continue to make the same basic mistakes over and over and over. If you want to really be aboe to tune the other 99% of the queries out there, knowledge of lots of stuff -- physical storage mechanisms, access paths, how the optimizer works - thats the only way. of course, read: http://download-west.oracle.com/docs/cd/A87860_01/doc/server.817/a76965/toc.htm from cover to cover and http://download-west.oracle.com/docs/cd/A87860_01/doc/server.817/a76992/toc.htm as well 1.1 Efficient SQL This was probably the hardest part of the book to write - this chapter. That is not because the material is all that complex, rather because I know what people want - and I know what can be delivered. What people want: The 10 step process by which you can tune any query. What can be delivered: Knowledge about how queries are processed, knowledge you can use and apply day to day as you develop them. Think about it for a moment. If there were a 10 step or even 1,000,000 step process by which any query can be tuned (or even X% of queries for that matter), we would write a program to do it. Oh don't get me wrong, there are many programs that actually try to do this - Oracle Enterprise Manager with its tuning pack, SQL Navigator and others. What they do is primarily recommend indexing schemes to tune a query, suggest materialized views, offer to add hints to the query to try other access plans. They show you different query plans for the same statement and allow you to pick one. They offer rules of thumb (what I generally call ROT since the acronym and the word is maps to are so appropriate for each other) SQL optimizations - which if they were universally applicable - the optimizer would do it as a matter of fact. In fact, the cost based optimizer does that already - it rewrites our queries all of the time. These tuning tools use a very limited set of rules that sometimes can suggest that index or set of indexes you really should have thought of during your design. I'll close this idea out with this thought - if there were an N step process to tuning a query, to writing efficient SQL - the optimizer would incorporate it all and we would not be having a discussion about this topic at all. It is like the search for the holy grail - maybe someday the software will be sophisticated enough to be perfect in this regards, it will be able to take our SQL, understand the question being asked and process the question - rather then syntax. To me - writing efficient SQL requires a couple of things: oKnowledge of the physical organization of what I'm asked to query against. That is - the schema. Knowledge that the physical organization was actually designed in order to help me answer my frequently asked questions (refer back to the chapter on designing an efficient schema for advice in that arena) oKnowledge of what the database is capable of doing. If I did not know about skip scan indexes and what they did (we'll cover them below) - I might look at a schema and say ah hah, we are missing an index when in fact we are not. oKnowledge of all of the intricacies of SQL - from the lowly WHERE clause on up to analytics and psuedo columns. Knowledge of what using a particular construct will do to my runtime processing. oAnd most importantly of all - a
[oracle_br] OCP - Usando o Scheduler para automatizar tarefas
Bom dia amigos! Acabei de publicar mais um artigo pra quem deseja estudar pra OCP. http://certificacaobd.com.br/2014/02/18/oracle-ocp-11g-capitulo-14-usando-o-scheduler-para-automatizacao-de-tarefas/ Quem quiser ler os resumos anteriores, tanto da prova de OCP quanto de outras provas de certificação Oracle, pode acessar o link: http://certificacaobd.com.br/resumos-certificacao-oracle/ Abraço! Miltão Equipe Certificação BD
Re: [oracle_br] Problema com DUPLICATE
Leonardo, Como vc resolveu o problema do arquivo BCT?, pois segundo o manual, ele não faz parte do backup, tem que ser recriado. Vc desabilitou o BCT e fez novo backup? Sobre este problema do not restored from a sufficiently old backup, acontece quando dá open resetlogs noredo em recover incompleto, quando não tem os redologfile (tb não vai no backup). No caso de Duplicate, se colocar o NOREDO só dá certo se o banco foi backupeado em MOUNT? Fiquei na dúvida agora. Sempre que vou duplicar, eu prefiro usar um backup de produção já feito, pois eu aproveito para validar o backup de produção (rodado automaticamente). Então eu transfiro os arquivos para o novo servidor e rodo um catalog. Veja este doc, nele tem as sintaxes para operações de duplicate onde é necessário modificar alguns parâmetros. http://docs.oracle.com/cd/E11882_01/backup.112/e10643/rcmsynta020.htm#RCMRF90152 http://docs.oracle.com/cd/E11882_01/backup.112/e10643/rcmsynta020.htm#RCMRF90152 Ederson Elias DBA Oracle http://br.linkedin.com/pub/ederson-elias/24/8b/8b0 Labor improbus omnia vincit
Re: [oracle_br] RE: data guard + flashback
Tudo jóia ? Só para Referência de quem acompanhou a thread, realmente no database 11g temos a moleza do Snapshot Standby, mas esse cara nada mais é do que um Automatizador - pra quem está na versão 10g, eu tinha comigo que era Perfeitamente Possível se fazer o mesmo, simulando a feature, via um DEFER da aplicação de archives no primary, desabilitar o standby, abrir em read/write (como um banco Normal, que nem sabe que já foi um dia standby) , e depois dos testes todos feitos, voltar o database até o exato SCN que estava, reabrir em modo standby e aplicar os archives pendentes : http://jaffardba.blogspot.com.br/2007/12/simulating-11g-snapshot-standby.html tem um exemplo. Eu pra variar Ainda Não Consegui arranjar o tempo pra fazer o teste por mim mesmo, mas em tese, falando pelos conceitos, não teria porque não funcionar, DESDE QUE a pessoa tenha espaço em disco suficiente para manter todos os archives necessários (no primary) E para poder ter um DB_FLASHBACK_RETENTION_TARGET suficiente []s Chiappa
Re: [oracle_br] Problema com DUPLICATE
Ederson, O BCT não dá erro, é apenas um warning. Ele passa tranquilo. Eu estou fazendo o duplicação com os backups já feitos, totalmente desconectado da produção. Sem conexão de target, nem de catalog; usando BACKUP LOCATION para isso. LRezende Em 18 de fevereiro de 2014 12:39, ederson200...@yahoo.com.br escreveu: Leonardo, Como vc resolveu o problema do arquivo BCT?, pois segundo o manual, ele não faz parte do backup, tem que ser recriado. Vc desabilitou o BCT e fez novo backup? Sobre este problema do not restored from a sufficiently old backup, acontece quando dá open resetlogs noredo em recover incompleto, quando não tem os redologfile (tb não vai no backup). No caso de Duplicate, se colocar o NOREDO só dá certo se o banco foi backupeado em MOUNT? Fiquei na dúvida agora. Sempre que vou duplicar, eu prefiro usar um backup de produção já feito, pois eu aproveito para validar o backup de produção (rodado automaticamente). Então eu transfiro os arquivos para o novo servidor e rodo um catalog. Veja este doc, nele tem as sintaxes para operações de duplicate onde é necessário modificar alguns parâmetros. http://docs.oracle.com/cd/E11882_01/backup.112/e10643/rcmsynta020.htm#RCMRF90152 Ederson Elias DBA Oracle http://br.linkedin.com/pub/ederson-elias/24/8b/8b0 Labor improbus omnia vincit
Re: [oracle_br] RE: Tunning de Queries
Sensacional como sempre Chiappa! Eu sou desenvolvedor e na minha equipe TODOS tem que escrever boas queries, se preocupando se a query não vai fazer FTS, não permitindo que o frontend monte queries SEM filtros para campos com índice, sem estar parametrizada (strings embutidas na query) e etc. Uma parte do meu trabalho é justamente de controle de qualidade, verificando se alguém dá bobeira mas como o pessoal é bem treinado, raramento pego algum problema. Com isso, são raros os casos aqui que o DBA precisa apagar incêndio... Saudações e parabéns pelos excelentes comentários!! Josir
Re: [oracle_br] RE: Tunning de Queries
Pessoal Acho que o caminho é este que o Josir comentou: treinamento/capacitação da equipe. Candiuru, se você puder, prepare um treinamento... inicialmente coisa básica: visão geral da arquitetura do banco e erros mais comuns em consultas (SQL) e modelagem. A partir daí, os desenvolvedores começarão a entender as causas dos problemas e, provavelmente, haverá um diálogo melhor entre desenvs. e DBA. Quando não se conhece algo, muitas vezes, há uma postura de negação... com BD, há desenvolvedores dizem é só repositório (aí começam os problemas...). Com uma apresentação/treinamento, você pode trazer os desenvolvedores para o lado do banco de dados. [ ]'s André Santos Em 18 de fevereiro de 2014 14:11, jo...@globo.com escreveu: Sensacional como sempre Chiappa! Eu sou desenvolvedor e na minha equipe TODOS tem que escrever boas queries, se preocupando se a query não vai fazer FTS, não permitindo que o frontend monte queries SEM filtros para campos com índice, sem estar parametrizada (strings embutidas na query) e etc. Uma parte do meu trabalho é justamente de controle de qualidade, verificando se alguém dá bobeira mas como o pessoal é bem treinado, raramento pego algum problema. Com isso, são raros os casos aqui que o DBA precisa apagar incêndio... Saudações e parabéns pelos excelentes comentários!! Josir
Re: [oracle_br] RE: Tunning de Queries
Poxa, Sua empresa é a empresa dos sonhos então.. rs Isso é resultado de conscientização, cultura mesmo, do vamos fazer mas vamos fazer a coisa certa em muitos lugares, as pessoas ignoram o básico, o minimo necessario Só se pode ter medo daquilo do que não se conhece. por isso a postura de negação, como o outro colega comentou 2014-02-18 14:11 GMT-03:00 jo...@globo.com: Sensacional como sempre Chiappa! Eu sou desenvolvedor e na minha equipe TODOS tem que escrever boas queries, se preocupando se a query não vai fazer FTS, não permitindo que o frontend monte queries SEM filtros para campos com índice, sem estar parametrizada (strings embutidas na query) e etc. Uma parte do meu trabalho é justamente de controle de qualidade, verificando se alguém dá bobeira mas como o pessoal é bem treinado, raramento pego algum problema. Com isso, são raros os casos aqui que o DBA precisa apagar incêndio... Saudações e parabéns pelos excelentes comentários!! Josir
