Obrigado Chiappa, me deu uma boa luz. Estou migrando atualmente o BD p 11g em servidor novo, e quero mapear os grandes consumidores de undo p evitar problemas futuros.
Abcs Em 07/12/2012 16:18, "J. Laurindo Chiappa" <jlchia...@yahoo.com.br> escreveu: > ** > > > Ah, e um detalhe importante, antes que alguém pergunte : como a informação > de qual bloco foi alterado (e vai ter a alteração registrada no undo) é ** > interna ** do RDBMS, ele não externaliza isso num formato diretamente > consumível por nós ... Ele agrupa isso em "arrays" , os change vectors, que > depois são montados em "registros" , que são inseridos em blocos (undo > block) - até é possível se recuperar essa informação (principalmente via > dumps, quem tiver curiosidade pode consultar o livro mais recente do > Jonathan Lewis de internals), e sabendo-se qual bloco tá sendo alterado > consultar a DBA_EXTENTS e decsobrir a qual segmento (e portanto a qual > objeto) o bloco sendo alterado pertence, mas na prática não é viável se > fazer isso num enrome volume de undo blocks sendo lidos e causando demora , > então o seu melhor approach é mesmo tentar "cercar" as transações, como eu > disse na msg anterior.... > > []s > > Chiappa > > --- Em oracle_br@yahoogrupos.com.br, "J. Laurindo Chiappa" <jlchiappa@...> > escreveu > > > > Colega, veja que o UNDO *** não *** existe para "proteger um objeto", e > sim para desfazer os bytes alterados num BLOCO : é IRRELEVANTE para esse > "desfazimento" os objetos que o bloco contem/continha, então isso NÃO FICA > registrado diretamente, okdoc ??? O que interessa pro RDBMS é que num > instante do tempo (SCN) o bloco X que continha a partir da posição tal o > valor "ABC" foi alterado para "ZYZ", só .... Mesmo o SQL que causou essa > alteração TRANQUILAMENTE já pode ter ido pro espaço - por exemplo, vc tem > uma sessão 1 que fez montes de DMLs nas tabelas A, B e C há muito tempo > atrás, digamos, e nesse momento (sem ter encerrado a transação, digamos) > está fazendo outras operações longas (cursores / processamento slow by > slow, estou de Olho em vcs) - NADA impede de, num banco altamente > movimentado, dos DMLs já TEREM SAÍDO do cache de SQLs, okdoc ?? Também DE > FORMA ALGUMA há um registro que indique 'ah, esse SQL X implicou a criação > dos blocos de undo u1,u2,u3 e esse SQL Y implicou a criação dos blocos de > undo tal e qual, jóia ?? Simplesmente Não Existe esse relacionamento, isso > não é auditado/gravado pelo database .... E nem vou falar, mas É Claro que, > cfrme sabemos, mesmo os SQLs Recursivos e/ou internos do RDBMS são feitos > em tabelas (internas, mas em TABELAS físicas, via de regra) e portanto > GERAM undo (e redo !!) e/ou pode SIM precisar ler blocos de undo para > consistência de dados , ok ?? > > > > O que Existe e é registrado no database é a TEMPO EXATO em que a > transação começou (o SCN) - lógico, já que a consistência de dados no RDBMS > Oracle para um dado statement é POR TEMPO - e a TRANSAÇÃO que está > gerando/usando um determinado bloco de undo, isso fica registrado na > V$TRANSACTION , veja lá as colunas de START e de UBA (Undo Block > Address).... Outra informação CRUCIAL que fica registrada na V$TRANSACTION > são os blocos/registros de undo que a transação gerou (colunas USED_UBLK e > USED_UREC) : isso é importante porque, para demorar tanto quanto vc diz, a > leitura de blocos de undo deve estar acontecendo em ENormes quantidades, > então certamente deve valer a pena ISOLAR as transações com mais undo > gerado, Muito provavelmente são essas que vc vai ter que tunar para > "resolver" os waits/as leituras por/de undo que vc cita... É sobre os SQLs > ainda é CLARO, porém, que se forem sessões dedicadas (e PERMANENTES, ** sem > ** pool de conexão no meio!), o(s) SQL(s) que causaram/geraram undo pode(m) > não estar presente(s), mas a SESSÃO vai estar, e vc pode fazer JOIN da > V$TRANSACTION com a V$SESSION via colunas taddr e addr , aí sabendo juntar > as transações grandes com a sessão, pelas colunas de login date, osuser, > username, module, blablabla, vc deve ser capaz de IDENTIFICAR quem criou as > sessões e por aí chegar aos programas/módulos/aplicativos que devem ser > tuneados/reagendados/whatever... > > > > Outra fonte de informação é a V$UNDOSTAT, ela te dá uma noção de o > quanto o teu undo está sendo usado... > > > > Já sobre a leitura, os blocos de undo são lidos Exatamente tal e qual os > blocos de dados (se for I/O físico e de um ou de poucos blocos é sequential > read, e se for I/O multiblock é scattered read, e se for I/O em memória > isso fica registrado em estatísticas do sistema, ok ? > > > > Assim, eu diria para vc : > > > > a) consulte no seu banco quais são os datafiles de undo, e aí procure no > trace desse SQL os eventos de leitura cujas colunas P1 se referem á esses > datafiles > > > > b) consulte repetidas vezes as v$ de waits, nos eventos relacionados com > undo E nos relacionados com leitura > > > > c) monitore frequentemente apelas views de sessão/transação/undo (cfrme > http://oracledisect.blogspot.com.br/2008/05/who-is-using-your-undo-space.html) > quem e como está usando o seu undo, criando "muitos" blocos/registros > > > > ==> a idéia de a) e b) é tentar MENSURAR se realmente no grande esquema > das coisas esses undo blocks estão mesmo te interferindo, e o quanto > > > > Aí, com as indicações acima todas, tente como eu disse acima, localizar > pelas v$ adequadas as transações/sessões que historicamente criaram/geraram > muito undo, essas provavelmente serão suas principais suspeitas de causar o > "problema" , E SE for comprovado por a) + b + c) que Realmente é algo que > Importa e vale a pena, são elas que vc vai ter que > tunar/reagendar/whatever.... > > > > []s > > > > Chiappa > > > > > > --- Em oracle_br@yahoogrupos.com.br, Hevandro Veiga <hevandro83@> > escreveu > > > > > > Senhores, > > > Alguém sabe se é possível saber qual o objeto está sendo protegido por > > > determinado segmento de undo? > > > > > > Ex.: a query está demorando horas, ao executar o trace percebo que o > maior > > > tempo gasto é lendo segmentos de undo. > > > Como saber qual objeto a quero esta lendo e descobrir qual a outra > > > sessão/transação está usando este objeto? > > > > > > Atc > > > Hevandro > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] ------------------------------------ -------------------------------------------------------------------------------------------------------------------------- >Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira >responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ -------------------------------------------------------------------------------------------------------------------------- >Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure » >Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: >http://www.oraclebr.com.br/ ------------------------------------------------------------------------------------------------------------------------ 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: oracle_br-unsubscr...@yahoogrupos.com.br <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
