Tava olhando outra coisa, achei
http://www.informit.com/articles/article.aspx?p=26950&seqNum=6 que
afirma que a coluna é a maxquerylen, confira lá...
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, "jlchiappa" <[EMAIL PROTECTED]> escreveu
>
> Aliás, agora que eu vi, a gente tá falando em "Transação" pra cá e pra
> lá bem imprecisamente, na verdade o que queremos é o tempo decorrido
> pros SQLs, Transação é outra coisa ... Sim, em tese vc poderia obter
> isso pela coluna ELAPSED_TIME da V$SQl, ** mas ** não podemos esquecer
> que as views V$SQLnn são a contraparte do CACHE DE SQL, e que (como
> qquer cache) rapidamente com a chegada de novos SQLs os velhos são
> ELIMINADOs pra dar lugar aos novos, é fácil vc perder uma entrada dum
> SQL demorado num banco ativo... Mais confiável nesse sentido penso que
> seriam a V$UNDOSTAT e relacionadas - não tenho 9i aqui comigo mas iirc
> elas possuem colunas indicativas de tempo de query/sql, cheque a
> documentação delas...
>
>
> []s
>
> Chiappa
> --- Em oracle_br@yahoogrupos.com.br, "Alvaro Luiz Mansor Neto"
> <alvaro_mansor@> escreveu
> >
> > Me corrija se estiver errado Chiappa.
> > Consigo medir o tempo máximo da transação fazendo o seguinte SELECT:
> > *
> >
> > SELECT* * *FROM* V$SQL *ORDER* *BY* ELAPSED_TIME *DESC* ;
> > Só q *o resultado de ELAPSED*_*TIME* é *5325303171e* o CPU_TIME esta *
> > 3802640000.*
> > Abraço
> > Alvaro
> >
> >
> >
> > Em 16/09/08, Alvaro Luiz Mansor Neto <alvaro_mansor@> escreveu:
> > >
> > > Ok. I understood. rsrs ...
> > > A respeito do segundo email...
> > >
> > > "então pergunto, SERÁ que em pico de uso não está chegando quase
> no limite
> > > de espaço ?? "
> > > Não sei mesmo. Vou aumentar o espaço da tablespace para não correr
> esse
> > > risco.
> > >
> > > E vc ** REALMENTE ** mediu pra ver que a sua maior transação é
> INFERIOR a
> > > 1800 segundos ???
> > > Eu REALMENTE não medi ... Vc ja poderia me ensinar como faço para
> saber
> > > qual o maior tempo de resposta das minhas transações?
> > > Abração. Vlw !!!!
> > > Alvaro
> > >
> > >
> > >
> > >
> > > Em 16/09/08, Alvaro Luiz Mansor Neto <alvaro_mansor@> escreveu:
> > >>
> > >> Chiappa.
> > >> Minha tablespace de UNDO está com 2GB e meu UNDO_RETENTION esta
> com 1800 (
> > >> seg ). Eu não sabia q a V$WAITSTAT é CUMULATIVA, sabendo disso ja
> fico mais
> > >> seguro. Contanto, escrevi esse email pq li no livro ( manual do
> DBA 9i, pag
> > >> 278 ) q a regra para se calcular os Segmentos de Rollback (
> manualmente ) é:
> > >> Pegar o número máximo de sessões já conectadas desde a
> inicialização (
> > >> select sessions_highwater from v$license ) e dividir por 4 ( pois
> nem sempre
> > >> o banco esta com o máximo de usuários conectados ), ou seja, se o
> valor de
> > >> sessions_highwater for 100 então é necessário a criação de 25
> Segmentos de
> > >> Rollback para dar suporte aos usuários. Contanto tenho somente 11
> segmentos
> > >> na v$rollstat ( todos online ) para o valor de 260 na
> sessions_highwater, ou
> > >> seja, manualmente teria q criar 65 Segmentos de Rollback, me
baseando
> > >> nisso achei q tinha alguma coisa errada nos segmentos gerenciados
> > >> automaticamente. Más vlw pela aula.
> > >> Abraço
> > >> Alvaro
> > >>
> > >>
> > >> Em 15/09/08, jlchiappa <jlchiappa@> escreveu:
> > >>>
> > >>> Seguem respostas e comments abaixo de cada item :
> > >>>
> > >>> ]--- Em oracle_br@yahoogrupos.com.br
> <oracle_br%40yahoogrupos.com.br>,
> > >>> "Alvaro Luiz Mansor Neto" questão.
> > >>> > Tenho um banco Oracle9i ( 9.2.0.8 ), com uma tablespace de
> UNDO e o
> > >>> > parametro de inicializacao UNDO_MANAGEMENT=AUTO, como
sabemos o BD
> > >>> deveria
> > >>> > gerenciar os Segmentos de Undo ( "Segmentos de Rollback" qdo
> > >>> > UNDO_MANAGEMENT=MANUAL ), ou seja, ele cria e gerencia
> > >>> automaticamente os
> > >>> > Segmentos certo ?
> > >>>
> > >>> Sim, apenas lembro que NÃO BASTA vc setar UNDO_MANAGEMENT e
> achar que
> > >>> tudo vai acontecer magicamente : se vc NÂO tiver espaço
> suficiente na
> > >>> tablespace de undo, OBVIAMENTE ele não vai conseguir criar
> extents, ok
> > >>> ? Da mesma forma , um UNDO_RETENTION pequeno pode levar a reuso
> > >>> prematuro dos extents, yes ? Então é ter o undo auto ** E **
ter uma
> > >>> tablespace de undo decente (em produção intensa não é incomum
termos
> > >>> algumas dezenas de Gbs de tablespace de UNDO), *** E *** ter o
> > >>> retention ao menos idêntico ao tempo da maior transação
> rotineira, ok ?
> > >>>
> > >>> > Más em tuning de Segmentos de Undo, ensina que *usando a
> V$WAITSTAT,
> > >>> podemos
> > >>> > ver o transações em espera de Segmentos de Undo, ou seja, qq
valor
> > >>> diferente
> > >>> > de 0 (zero) quer dizer q há transações em espera de segmentos
> livres. O
> > >>> > resultado desse SQL no meu banco é o seguinte;
> > >>> >
> > >>> > select
> > >>> > **class*, *count* *from* v$WAITSTAT *where* *class* *in*
> > >>> > ('undo header','undo block','system undo header',
> > >>> > 'system undo block');
> > >>> >
> > >>> > system undo header 0
> > >>> > system undo block 0
> > >>> > undo header 17
> > >>> > undo block 0
> > >>> >
> > >>> > *Ou seja,* estou tendo eventos em espera de Segmentos de Undo
> > >>> livres certo
> > >>> > ? A pergunta é :
> > >>> > Pq o BD não esta gerenciando automáticamente esse segmentos,
> ou seja,
> > >>> > deixando ONLINEs mais Segmentos de UNDO, para ficarem
> disponível para
> > >>> as
> > >>> > transações não ficarem em espera?
> > >>>
> > >>> Colega, veja vc, é absolutamente IMPOSSÍVEL para o banco ele
> ADIVINHAR
> > >>> que daqui a alguns segundos vai haver montes de transação e
portanto
> > >>> tem que criar mais extents - o mecanismo dessas coisas
> automáticas SÓ
> > >>> PODE SER reativo, ie : QUANDO o banco ver que estão
acontecendo ele
> > >>> REAGE criando mais extents, "roubando" extents de transações
> > >>> encerradas... Assim sendo, um ou outro wait PODE SIM ocorrer,
> > >>> evidentemente que nem sempre o tempo de reação é mais rápido do
> que o
> > >>> pedido das transações, em especial quando há uma CHUVA delas em
> pouco
> > >>> tempo, sim ? Então NEM SEMPRE zero é o alvo desse wait, nem
sempre o
> > >>> undo automático o ELIMINA : o que o undo automático objetiva é que
> > >>> espera por undo seja mínima EM RELAÇÂO AOS OUTROS WAITS, confere
> ?? Aí
> > >>> nos chegamos na última peça do quebra-cabeça, qual seja :
> > >>>
> > >>> a) a V$WAITSTAT é CUMULATIVA, ela reflete o que aconteceu desde o
> > >>> startup do banco - um valor mais alto NÂO QUER DIZER que neste
> > >>> instante vc está tendo problemas, o aumento pode ter ocorrido há
> > >>> MUITAS HORAS atrás : ou seja, ter poucas dezenas de waits num
> banco de
> > >>> está há MUITAS e MUITAS horas, dias e dias, de pé, é uma coisa, o
> > >>> mesmo número num banco que ligou há pouco é bem mais preocupante
> > >>>
> > >>> e
> > >>>
> > >>> b) um número qquer de estat de performance POR SI SÓ é INÓCUO, não
> > >>> cheira NEM fede, não serve pra COISA ALGUMA : ele TEM que ser
> > >>> contextualizado, no caso vc TEM QUE comparar esses 17 waits
(número
> > >>> RIDICULAMENTE PEQUENO via de regra num bd de produção, aliás)
com os
> > >>> OUTROS waits .
> > >>>
> > >>> ==> Ou seja, SE o wait por undo é coisa de dezenas (como é o seu
> caso)
> > >>> MAS os outros waits são muito muito maiores, coisa de muitas
> centenas
> > >>> ou milhares, OK, o undo auto está funcionando. Já SE o número de
> waits
> > >>> por undo é bem próximo ou mesmo superior aos demais (não acho
> que seja
> > >>> o caso, num banco Prod 17 waits é café pequeno a maioria das
vezes),
> > >>> mas enfim se um dado wait sobressai comparativamente aí sim vale a
> > >>> pena fazer algo, no caso de wait por undo com management auto,
> talvez
> > >>> passar para MANUAL e já criar uma montão de segments, talvez o
> > >>> algoritmo de AUTO não esteja conseguindo reagir rapido a um
flood de
> > >>> transações....
> > >>>
> > >>> []s
> > >>>
> > >>> Chiappa
> > >>>
> > >>> elas são na maioria
> > >>> >
> > >>> > PS: O parametro de inicialização esta setado como SESSIONS=665.
> > >>> >
> > >>> > Abraço a todos
> > >>> >
> > >>> > Alvaro
> > >>> >
> > >>> >
> > >>> > [As partes desta mensagem que não continham texto foram
removidas]
> > >>> >
> > >>>
> > >>>
> > >>>
> > >>
> > >>
> > >
> >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
>
