estivesse absurdamente alto, daí quando houvesse crescimento seria
em "pulos" enormes, mas não, se todos estão MESMO como 10240 KB (ie,
10 Mb) não é isso : vc não deu a info de tablespace em si (ie,
EXTENTs, STORAGE, EXTENT MANAGEMENT, etc) mas se é uma tablespace de
undo é praticamente certo que é LMT system-allocated, também não deve
ser isso. Então vou teorizar que NÃO houve aumento irreal, o que
houve foi mesmo transação/ões que geraram mais undo, seja por causa
de concorrência maior, duração maior, qtdade de DMLs/registros
envolvidos maior, o que vc vai fazer é : corrigir o MAXSIZE de cada
datafile pra que fique de um tamanho que, mesmo na pior das hipóteses
onde todos os arqs cresçam, vc ainda tenha espaço pra isso no disco
(normalmente alguma coisa na casa dos Gbs, uns 4 ou 6 Gb talvez), e
MONITORAR (tanto consultando frequentemente a V$UNDOSTAT e a
v$sysstat como executando o script abaixo diversas vezes durante a
execução das transações), até num JOB automático que te avise se
crescer muito, o consumo de undo das transações, pra detectar quem
está consumindo muito a mais, mas como disse em cima do cenário
mostrado a suposição é que não há nada a fazer no banco, é a
APLICAÇÃO que está gerando undo a mais...
[]s
Chiappa
-- script mostra undo blocks & records por sessão conectada c/
transações
column sid format 999
column segment_name format a15
select b.segment_name, a.username, a.sid, a.serial#, c.used_ublk,
c.used_urec,c.START_UBAFIL, c.START_UBABLK, c.START_UBAREC , b.status,
b.TABLESPACE_NAME, b.SEGMENT_ID, b.FILE_ID, b.BLOCK_ID
from v$session a, dba_rollback_segs b, v$transaction c
where b.segment_id = c.xidusn
and a.taddr = c.addr
/
--- Em [email protected], "Fernandes Rocha"
<[EMAIL PROTECTED]> escreveu
>
> Muito boa tarde e muito obrigado pelas informacoes Chiappa...
>
>
> Voce tem razao, NÃO é a tablespace que esta' "parametrizada como
autoextend", e sim CADA DATAFILE.
>
>
> Seguem abaixo as informacoes que voce me solicitou:
>
>
> Tamanho original da tablespace de UNDO 1.5 GB, foi para 5.2 GB.
>
>
> Informacoes do Datafile (Storage):
>
>
> Automatically extend datafile when full (AUTOEXTEND)
>
> Increment 10240 KB
>
> Maximum File Size Value 32767 MB
>
>
> Outros Parametros:
>
>
> transactions_per_rollback_segment 5
>
> undo_management AUTO
>
> undo_retention 900
>
> undo_tablespace UNDOTBS2
>
>
>
> Desde ja' agradeco o apoio...
>
>
>
>
> Um forte abraco.
>
>
> Fernandes
> [EMAIL PROTECTED]
>
> OFS RJ Ltda.
> Drogaria Moderna.
>
> http://www.drogariamoderna.com.br
>
>
> "Somente depois de esgotados todos os recursos naturais, o homem
sabera' que o dinheiro nao se come".
>
> * Autor desconhecido.
>
>
>
>
>
>
>
> On Mon, 29 May 2006 14:07:37 -0000, jlchiappa wrote
> > Bom, primeiro não entendi a relação desse seu 20480 Kb (sendo,
> > aproximadamente, mil Kb = 1 Mb, isso quer dizer cerca de 20 Mb)
com
> > os dois Gb que vc diz que cresceu : esses 20 Mb são o extent size
(se
> > não for UNDO gerenciado auto), são o increment size, ou são o
que,
> > EXATAMENTE ??? Acho que seria legal vc informar aí o
undo_management
> > que vc está usando (praticamente certo que deve ser AUTO em sendo
bd
> > 10g, mas enfim), o tamanho da tablespace, o undo_retention, E o
> > tamanho originalmente criado/o increment/ o maxsize de CADA
DATAFILE
> > (já que, ao contrário do que vc afirma, NÃO é a tablespace que
> > é "parametrizada como autoextend", isso é um atributo DE CADA
> > DATAFILE, certo ?
> >
> > Isso posto : o uso da tablespace de undo é decorrência da geração
de
> > undo, e geração de undo é TOTALMENTE consequência de DMLs
enviados
> > pela aplicação, então SE vc quer diminuir uso da tablespace de
undo ,
> > é alterar a aplicação para gerar MENOS undo - onde possível
> > trabalhando com NOLOGGING, diminuindo DMLs, etc. A idéia de se
pedir
> > a info dos datafiles acima é verificar se não há alguma aberração
do
> > tipo quando houver incremento esse incremento ser dum tamanho
> > absurdo, mas se não for isso não há muito o q fazer nesse
sentido, em
> > especial sendo a tablespace de undo automático LMT system-
allocated...
> >
> > Pra vc identificar historicamente onde foi consumido mais undo vc
> > pode consultar a V$UNDOSTAT, e pra vc checar quanto de undo já
foi
> > consumindo nesse exato momento , vc pode usar um script tipo :
> >
> > column sid format 999
> > column segment_name format a15
> > select b.segment_name, a.username, a.sid, a.serial#, c.used_ublk,
> > c.used_urec,c.START_UBAFIL, c.START_UBABLK, c.START_UBAREC ,
b.status,
> > b.TABLESPACE_NAME, b.SEGMENT_ID, b.FILE_ID, b.BLOCK_ID
> > from v$session a, dba_rollback_segs b, v$transaction c
> > where b.segment_id = c.xidusn
> > and a.taddr = c.addr;
> >
> > []s
> >
> > Chiappa
> >
> > --- Em [email protected], "Fernandes Rocha"
> > <[EMAIL PROTECTED]> escreveu
> > >
> > > Muito bom dia a todos...
> > >
> > >
> > > Informacoes do Ambiente:
> > >
> > > Sistema Operacional: Sun OS 5.9 - Solaris 9 - Plataforma 64
Bits...
> > >
> > > Versao do Oracle: Oracle 10g - 10.1.0.2.0
> > >
> > >
> > > Problema:
> > >
> > >
> > > Observei agora pela manha que a minha tablespace UNDO cresceu
cerca
> > de 2 GB neste fim de semana, para ser mais exato no
> > > sabado, ou seja, praticamente dobrou seu tamanho. Ela estava
> > parametrizada com (AUTOEXTEND) de 20480 KB, alterei agora
> > > para 10240 KB, tendo em vista o fato de neste momento eu estar
com
> > limitacao de espaco em disco, (isto brevemente sera'
> > > resolvido), com a diminuicao do autoextend eu teria
supostamente um
> > tempo maior para tomar decisao caso fique sem espaco
> > > em disco, ela demoraria mais tempo para extender, obviamente
isto
> > refletira' nos usuarios, mas...
> > >
> > >
> > > Gostaria de saber se alguem tem alguma sugestao em relacao a
> > TUNNING, para que eu possa implementar para impedir ou
> > > retardar o crescimento tao rapido desta tablespace ???
> > >
> > >
> > >
> > > Desde ja' agradeco.
> > >
> > >
> > > Um forte abraco.
> > >
> > >
> > > Fernandes
> > > [EMAIL PROTECTED]
> > >
> > > OFS RJ Ltda.
> > > Drogaria Moderna.
> > >
> > > http://www.drogariamoderna.com.br
> > >
> > >
> > > "Somente depois de esgotados todos os recursos naturais, o
homem
> > sabera' que o dinheiro nao se come".
> > >
> > > * Autor desconhecido.
> > >
> >
> > ------------------------------------------------------------------
--------------------------------------------------------
> > Atenção! As mensagens deste grupo são de acesso público e de
inteira responsabilidade de seus remetentes.
> > Acesse: http://www.mail-archive.com/[email protected]/
> >
> --------------------------------------------------------------------
------------------------------------------------------
__________________________________________________________________
> >
> > Este Grupo recebe o apoio da SQL Magazine -
www.devmedia.com.br/sqlmagazine
> > __________________________________________________________________
> > O grupo Oracle_br não aceita anexos. Quando oferecer algum
arquivo, tenha o link do mesmo para evitar
> > trafego(pedidos) desnecessário.
> >
> > Yahoo! Grupos, um serviço oferecido por:
> >
> > PUBLICIDADE
> >
> > ------------------------------------------------------------------
-----
> > 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:
> > [EMAIL PROTECTED]
> >
> > * O uso que você faz do Yahoo! Grupos está sujeito aos Termos do
Serviço do Yahoo!.
>
--------------------------------------------------------------------------------------------------------------------------
Atenção! As mensagens deste grupo são de acesso público e de inteira responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/[email protected]/
--------------------------------------------------------------------------------------------------------------------------__________________________________________________________________
Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine
__________________________________________________________________
O grupo Oracle_br não aceita anexos. Quando oferecer algum arquivo, tenha o link do mesmo para evitar trafego(pedidos) desnecessário.
| Yahoo! Grupos, um serviço oferecido por: | |
|
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:
[EMAIL PROTECTED]
- O uso que você faz do Yahoo! Grupos está sujeito aos Termos do Serviço do Yahoo!.
