Re: [oracle_br] Re: Tablespace UNDO aumentando de tamanho em pouco tempo
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) Increment10240 KB Maximum File Size Value 32767 MB Outros Parametros: transactions_per_rollback_segment 5 undo_managementAUTO undo_retention900 undo_tablespaceUNDOTBS2 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 -, 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 oracle_br@yahoogrupos.com.br, 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/oracle_br@yahoogrupos.com.br/ --__ 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
[oracle_br] Re: Tablespace UNDO aumentando de tamanho em pouco tempo
OK : a hipótese original era que o increment de algum dos datafiles 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 oracle_br@yahoogrupos.com.br, 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) Increment10240 KB Maximum File Size Value 32767 MB Outros Parametros: transactions_per_rollback_segment 5 undo_managementAUTO undo_retention900 undo_tablespaceUNDOTBS2 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 -, 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 oracle_br@yahoogrupos.com.br, Fernandes Rocha [EMAIL PROTECTED] escreveu Muito bom dia a todos... Informacoes do Ambiente: Sistema Operacional: Sun OS 5.9 - Solaris 9 -
[oracle_br] Re: Tablespace UNDO aumentando de tamanho em pouco tempo
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 oracle_br@yahoogrupos.com.br, 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/oracle_br@yahoogrupos.com.br/ --__ 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!.
