RES: [oracle_br] Re: ORA-01652: unable to extend temp
Chiappa, Aumentei a TEMP, mais ainda continua o erro, existe algo a mais que pode ser feito? SQL select FILE_NAME,TABLESPACE_NAME,BYTES/1024/1024 from DBA_TEMP_FILES; FILE_NAMETABLESPACE_NAME BYTES/1024/1024 -- --- /d004/oradata/prod/temp01.dbfTEMP 1 /d004/oradata/prod/temp02.dbfTEMP 1 /d004/oradata/prod/temp03.dbfTEMP 1 /d004/oradata/prod/temp04.dbfTEMP 10240 /d004/oradata/prod/temp05.dbfTEMP 10240 A SORT_AREA_SIZE e PGA_AGGREGATE_TARGET esta conforme abaixo, não sei se pode ajudar alguma coisa. SQL show parameter sort_area_size; NAME TYPEVALUE --- -- sort_area_size integer 65536 SQL show parameter pga_aggregate_target; NAME TYPEVALUE --- -- pga_aggregate_target big integer 1500M Grato, Ednilson Silva De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome de J. Laurindo Chiappa Enviada em: terça-feira, 27 de novembro de 2012 15:14 Para: oracle_br@yahoogrupos.com.br Assunto: [oracle_br] Re: ORA-01652: unable to extend temp Sim, a msg : ORA-01652: unable to extend temp segment by 128 in tablespace TEMP é bem Clara quanto ao esgotamente da tablespace TEMP - se for o caso, vc até pode obter dados sobre o consumo real de tempspace consultando na hora que dá essa msg a v$sort_segment/v$sort_usage, OU tendo uma trigger de erro que faz e automatiza a consulta para vc, OU então (se tiver a Licença necessária) vc pode obter o histórico recente de utilização de tempspace via DBA_HIST_TEMPSTATXS e relacionadas, MAS a msg de erro não deixa muita margem ao diagnóstico de aumento do espaço de tablespace Sobre o quanto e o que aumentar : o que importa é o total de espaço (e não a qtdade de tempfiles, isso é largamente Irrelevante),e pelo que vejo vc tem hoje no total 3 GB - isso é o tamanho de um pendrive, é (num ambiente que Possui utilização) um tamanho que se pode considerar pequeno Eu diria para vc passar para pelo menos 10 GB essa tablespace e monitorar o consumo a partir daí, sendo Irrelevante se vc adicionar o espaço faltante em um, dois ou x tempfiles, desde Que o seu SO/hardware/ambiente permita arquivos de qquer tamanho []s Chiappa --- Em oracle_br@yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br , Ednilson Silva ednilson.silva@... escreveu Pessoal, Tenho um banco aqui 10.2.0.4 em Red Hat 5.7 64 Bits, que tem uma rotina em crontab para executar o comando abaixo: exec dbms_stats.gather_schema_stats(ownname = 'HOMO',estimate_percent=20); E não esta concluindo dá o erro abaixo: SQL BEGIN dbms_stats.gather_schema_stats(ownname = 'HOMO',estimate_percent=20); END; * ERROR at line 1: ORA-01652: unable to extend temp segment by 128 in tablespace TEMP ORA-06512: at SYS.DBMS_STATS, line 13591 ORA-06512: at SYS.DBMS_STATS, line 13937 ORA-06512: at SYS.DBMS_STATS, line 14015 ORA-06512: at SYS.DBMS_STATS, line 13974 ORA-06512: at line 1 SQL select * from dba_tablespaces where tablespace_name = 'TEMP'; TABLESPACE_NAME BLOCK_SIZE INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS MAX_EXTENTS PCT_INCREASE MIN_EXTLEN STATUS CONTENTS LOGGING FORCE_LOGGING EXTENT_MANAGEMENT ALLOCATION_TYPE PLUGGED_IN SEGMENT_SPACE_MANAGEMENT DEF_TAB_COMPRESSION RETENTION BIGFILE -- -- -- --- --- --- -- - - - - - --- -- --- --- --- TEMP 8192 1048576 1048576 1 0 1048576 ONLINE TEMPORARY NOLOGGING NO LOCAL UNIFORM NO MANUAL DISABLED NOT APPLY NO SQL SELECT tablespace_name, file_name, bytes FROM dba_temp_files WHERE tablespace_name = 'TEMP'; TABLESPACE_NAME FILE_NAME BYTES --- -- -- TEMP /d004/oradata/prod/temp01.dbf 1048576000 TEMP /d004/oradata/prod/temp02.dbf 1048576000 TEMP /d004/oradata/prod/temp03.dbf 1048576000 Criando mais um tempfile irá resolver meu problema? Grato, Ednilson Silva [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas]
RES: [oracle_br] Re: ORA-01652: unable to extend temp
Bem, pelo que eu vi vc aumentou para coisa de 50 GB (5 datafiles de 10 GB) a sua TEMP : na média de databases que se vê pelaí, isso até deveria ser suficiente, mas até pode acontecer de ainda ser insuficiente, ESPECIALMENTE se vc tem alguma tabela de dezenas de GB a ordenar para se coletar estatísticas (já vi casos de uma tabela até 2,5x o seu tamanho em área temp para ordenação e quetais) - assim, se pergunta, QUAL o tamanho (em bytes, não em linhas) das maiores tabelas desse schema que vc está coletando estats ?? SE for alguma coisa especialmente grande, na casa de umas tantas dezenas de GBs, pode ser que um aumento ainda maior da temp seja necessário, verifique SE não for isso , eu diria que vc tem 2 possibilidades aí,colega : a) Outras rotinas consumindo temp area na hora que vc roda a coleta : como eu disse antes, para vc averiguar se é isso, OU consulte/monitore o consumo real de temp area com as views apropriadas imediatamente antes E durante a coleta, E/OU se vc tiver permissão/direito use as views de historic data (active session history) e AWR para descobrir o consumo histórico recente, E/OU tenha uma trigger de database error que faça uma ou ambas as coisas quando der o erro de unable to extend b) bug na DBMS_STATS.GATHER_SCHEMA_STATS, consumindo muito mais que o necessário : pesquise a SUA versão no metalink e/ou abra um Chamado no Suporte para ver há bug cujos sintomas são similares ao seu... É de bom tomo também vc TESTAR fazendo a coleta com DBMS_STATS.GATHER_TABLE_STATS (usando um scriptizinho sql*plus que te gere os comandos todos, ninguém é doido para digitar os trocentos comandos de coleta para as trocentas tabelas do schema) - INCLUSIVE, isso pode até te Acelerar a coleta talvez, se vc tiver diversos scripts rodando simultaneamente, cada um coletando de uma parte da lista de objetos do schema... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Ednilson Silva ednilson.silva@... escreveu Chiappa, Aumentei a TEMP, mais ainda continua o erro, existe algo a mais que pode ser feito? SQL select FILE_NAME,TABLESPACE_NAME,BYTES/1024/1024 from DBA_TEMP_FILES; FILE_NAMETABLESPACE_NAME BYTES/1024/1024 -- --- /d004/oradata/prod/temp01.dbfTEMP 1 /d004/oradata/prod/temp02.dbfTEMP 1 /d004/oradata/prod/temp03.dbfTEMP 1 /d004/oradata/prod/temp04.dbfTEMP 10240 /d004/oradata/prod/temp05.dbfTEMP 10240 A SORT_AREA_SIZE e PGA_AGGREGATE_TARGET esta conforme abaixo, não sei se pode ajudar alguma coisa. SQL show parameter sort_area_size; NAME TYPEVALUE --- -- sort_area_size integer 65536 SQL show parameter pga_aggregate_target; NAME TYPEVALUE --- -- pga_aggregate_target big integer 1500M Grato, Ednilson Silva De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome de J. Laurindo Chiappa Enviada em: terça-feira, 27 de novembro de 2012 15:14 Para: oracle_br@yahoogrupos.com.br Assunto: [oracle_br] Re: ORA-01652: unable to extend temp Sim, a msg : ORA-01652: unable to extend temp segment by 128 in tablespace TEMP é bem Clara quanto ao esgotamente da tablespace TEMP - se for o caso, vc até pode obter dados sobre o consumo real de tempspace consultando na hora que dá essa msg a v$sort_segment/v$sort_usage, OU tendo uma trigger de erro que faz e automatiza a consulta para vc, OU então (se tiver a Licença necessária) vc pode obter o histórico recente de utilização de tempspace via DBA_HIST_TEMPSTATXS e relacionadas, MAS a msg de erro não deixa muita margem ao diagnóstico de aumento do espaço de tablespace Sobre o quanto e o que aumentar : o que importa é o total de espaço (e não a qtdade de tempfiles, isso é largamente Irrelevante),e pelo que vejo vc tem hoje no total 3 GB - isso é o tamanho de um pendrive, é (num ambiente que Possui utilização) um tamanho que se pode considerar pequeno Eu diria para vc passar para pelo menos 10 GB essa tablespace e monitorar o consumo a partir daí, sendo Irrelevante se vc adicionar o espaço faltante em um, dois ou x tempfiles, desde Que o seu SO/hardware/ambiente permita arquivos de qquer tamanho []s Chiappa --- Em oracle_br@yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br , Ednilson Silva ednilson.silva@ escreveu Pessoal, Tenho um banco aqui 10.2.0.4 em Red Hat 5.7 64 Bits, que tem uma rotina em crontab para executar o comando abaixo: exec
RES: [oracle_br] Re: ORA-01652: unable to extend temp
Fabricio, É uma rotina que esta agendada para ser executada de madrugada e durante o dia fica complicado para executar ela. Mas executei sua query e ate o momento não trouxe nada, vou ficar monitorando durante o dia. Grato, Ednilson Silva -Mensagem original- De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome de Fabricio Pedroso Jorge Enviada em: quarta-feira, 28 de novembro de 2012 11:23 Para: oracle_br@yahoogrupos.com.br Assunto: Re: [oracle_br] Re: ORA-01652: unable to extend temp Caro Ednilson, use a seguinte query pra monitorar quem está consumindo a TEMP. A partir daí é possível ver o que pode ser feito para tentar reduzir seu uso, se for possível: * SELECT b.TABLESPACE, ROUND(((b.blocks * p.VALUE) / 1024 / 1024), 2) used_size_mb, a.SID, a.serial#, a.username, a.osuser, a.program, a.status, s.SQL_TEXT FROM v$session a, v$sort_usage b, v$process c, v$parameter p, V$SQL S WHERE p.NAME = 'db_block_size' AND a.saddr = b.session_addr AND a.paddr = c.addr AND a.sql_id = s.SQL_ID ORDER BY b.TABLESPACE, b.segfile#, b.segblk#, b.blocks;* Em 28 de novembro de 2012 10:55, Ednilson Silva ednilson.si...@jbs.com.brescreveu: ** Chiappa, Aumentei a TEMP, mais ainda continua o erro, existe algo a mais que pode ser feito? SQL select FILE_NAME,TABLESPACE_NAME,BYTES/1024/1024 from SQL DBA_TEMP_FILES; FILE_NAME TABLESPACE_NAME BYTES/1024/1024 -- --- /d004/oradata/prod/temp01.dbf TEMP 1 /d004/oradata/prod/temp02.dbf TEMP 1 /d004/oradata/prod/temp03.dbf TEMP 1 /d004/oradata/prod/temp04.dbf TEMP 10240 /d004/oradata/prod/temp05.dbf TEMP 10240 A SORT_AREA_SIZE e PGA_AGGREGATE_TARGET esta conforme abaixo, não sei se pode ajudar alguma coisa. SQL show parameter sort_area_size; NAME TYPE VALUE --- -- sort_area_size integer 65536 SQL show parameter pga_aggregate_target; NAME TYPE VALUE --- -- pga_aggregate_target big integer 1500M Grato, Ednilson Silva De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome de J. Laurindo Chiappa Enviada em: terça-feira, 27 de novembro de 2012 15:14 Para: oracle_br@yahoogrupos.com.br Assunto: [oracle_br] Re: ORA-01652: unable to extend temp Sim, a msg : ORA-01652: unable to extend temp segment by 128 in tablespace TEMP é bem Clara quanto ao esgotamente da tablespace TEMP - se for o caso, vc até pode obter dados sobre o consumo real de tempspace consultando na hora que dá essa msg a v$sort_segment/v$sort_usage, OU tendo uma trigger de erro que faz e automatiza a consulta para vc, OU então (se tiver a Licença necessária) vc pode obter o histórico recente de utilização de tempspace via DBA_HIST_TEMPSTATXS e relacionadas, MAS a msg de erro não deixa muita margem ao diagnóstico de aumento do espaço de tablespace Sobre o quanto e o que aumentar : o que importa é o total de espaço (e não a qtdade de tempfiles, isso é largamente Irrelevante),e pelo que vejo vc tem hoje no total 3 GB - isso é o tamanho de um pendrive, é (num ambiente que Possui utilização) um tamanho que se pode considerar pequeno Eu diria para vc passar para pelo menos 10 GB essa tablespace e monitorar o consumo a partir daí, sendo Irrelevante se vc adicionar o espaço faltante em um, dois ou x tempfiles, desde Que o seu SO/hardware/ambiente permita arquivos de qquer tamanho []s Chiappa --- Em oracle_br@yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br , Ednilson Silva ednilson.silva@... escreveu Pessoal, Tenho um banco aqui 10.2.0.4 em Red Hat 5.7 64 Bits, que tem uma rotina em crontab para executar o comando abaixo: exec dbms_stats.gather_schema_stats(ownname = 'HOMO',estimate_percent=20); E não esta concluindo dá o erro abaixo: SQL BEGIN dbms_stats.gather_schema_stats(ownname = 'HOMO',estimate_percent=20); END; * ERROR at line 1: ORA-01652: unable to extend temp segment by 128 in tablespace TEMP ORA-06512: at SYS.DBMS_STATS, line 13591 ORA-06512: at SYS.DBMS_STATS, line 13937 ORA-06512: at SYS.DBMS_STATS, line 14015 ORA-06512: at SYS.DBMS_STATS, line 13974 ORA-06512: at line 1 SQL select * from dba_tablespaces where tablespace_name = 'TEMP'; TABLESPACE_NAME BLOCK_SIZE INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS MAX_EXTENTS PCT_INCREASE MIN_EXTLEN STATUS CONTENTS LOGGING FORCE_LOGGING EXTENT_MANAGEMENT ALLOCATION_TYPE PLUGGED_IN SEGMENT_SPACE_MANAGEMENT DEF_TAB_COMPRESSION RETENTION BIGFILE -- -- -- ---
RES: [oracle_br] Re: ORA-01652: unable to extend temp
Chiappa, Tenho uma tabela de 180G e duas outras de 50G, são as maiores do banco em apenas um schema. No momento estou sem acesso ao Metalink, a empresa ainda esta renovando contrato. No DBMS_STATS.GATHER_SCHEMA_STATS, tem como não executar numa determinada tabela? Não existe nenhuma outra rotina concorrendo com o DBMS_STATS.GATHER_SCHEMA_STATS de madrugada. Grato, Ednilson Silva De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome de J. Laurindo Chiappa Enviada em: quarta-feira, 28 de novembro de 2012 12:43 Para: oracle_br@yahoogrupos.com.br Assunto: RES: [oracle_br] Re: ORA-01652: unable to extend temp Bem, pelo que eu vi vc aumentou para coisa de 50 GB (5 datafiles de 10 GB) a sua TEMP : na média de databases que se vê pelaí, isso até deveria ser suficiente, mas até pode acontecer de ainda ser insuficiente, ESPECIALMENTE se vc tem alguma tabela de dezenas de GB a ordenar para se coletar estatísticas (já vi casos de uma tabela até 2,5x o seu tamanho em área temp para ordenação e quetais) - assim, se pergunta, QUAL o tamanho (em bytes, não em linhas) das maiores tabelas desse schema que vc está coletando estats ?? SE for alguma coisa especialmente grande, na casa de umas tantas dezenas de GBs, pode ser que um aumento ainda maior da temp seja necessário, verifique SE não for isso , eu diria que vc tem 2 possibilidades aí,colega : a) Outras rotinas consumindo temp area na hora que vc roda a coleta : como eu disse antes, para vc averiguar se é isso, OU consulte/monitore o consumo real de temp area com as views apropriadas imediatamente antes E durante a coleta, E/OU se vc tiver permissão/direito use as views de historic data (active session history) e AWR para descobrir o consumo histórico recente, E/OU tenha uma trigger de database error que faça uma ou ambas as coisas quando der o erro de unable to extend b) bug na DBMS_STATS.GATHER_SCHEMA_STATS, consumindo muito mais que o necessário : pesquise a SUA versão no metalink e/ou abra um Chamado no Suporte para ver há bug cujos sintomas são similares ao seu... É de bom tomo também vc TESTAR fazendo a coleta com DBMS_STATS.GATHER_TABLE_STATS (usando um scriptizinho sql*plus que te gere os comandos todos, ninguém é doido para digitar os trocentos comandos de coleta para as trocentas tabelas do schema) - INCLUSIVE, isso pode até te Acelerar a coleta talvez, se vc tiver diversos scripts rodando simultaneamente, cada um coletando de uma parte da lista de objetos do schema... []s Chiappa --- Em oracle_br@yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br , Ednilson Silva ednilson.silva@... escreveu Chiappa, Aumentei a TEMP, mais ainda continua o erro, existe algo a mais que pode ser feito? SQL select FILE_NAME,TABLESPACE_NAME,BYTES/1024/1024 from DBA_TEMP_FILES; FILE_NAME TABLESPACE_NAME BYTES/1024/1024 -- --- /d004/oradata/prod/temp01.dbf TEMP 1 /d004/oradata/prod/temp02.dbf TEMP 1 /d004/oradata/prod/temp03.dbf TEMP 1 /d004/oradata/prod/temp04.dbf TEMP 10240 /d004/oradata/prod/temp05.dbf TEMP 10240 A SORT_AREA_SIZE e PGA_AGGREGATE_TARGET esta conforme abaixo, não sei se pode ajudar alguma coisa. SQL show parameter sort_area_size; NAME TYPE VALUE --- -- sort_area_size integer 65536 SQL show parameter pga_aggregate_target; NAME TYPE VALUE --- -- pga_aggregate_target big integer 1500M Grato, Ednilson Silva De: oracle_br@yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br ] Em nome de J. Laurindo Chiappa Enviada em: terça-feira, 27 de novembro de 2012 15:14 Para: oracle_br@yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br Assunto: [oracle_br] Re: ORA-01652: unable to extend temp Sim, a msg : ORA-01652: unable to extend temp segment by 128 in tablespace TEMP é bem Clara quanto ao esgotamente da tablespace TEMP - se for o caso, vc até pode obter dados sobre o consumo real de tempspace consultando na hora que dá essa msg a v$sort_segment/v$sort_usage, OU tendo uma trigger de erro que faz e automatiza a consulta para vc, OU então (se tiver a Licença necessária) vc pode obter o histórico recente de utilização de tempspace via DBA_HIST_TEMPSTATXS e relacionadas, MAS a msg de erro não deixa muita margem ao diagnóstico de aumento do espaço de tablespace Sobre o quanto e o que aumentar : o que importa é o total de espaço (e não a qtdade de tempfiles, isso é largamente Irrelevante),e pelo que vejo vc tem hoje no total 3 GB - isso é o tamanho de um pendrive, é (num ambiente que Possui utilização) um tamanho que se pode considerar pequeno
RES: [oracle_br] Re: ORA-01652: unable to extend temp
Segue : Tenho uma tabela de 180G e duas outras de 50G Opa, pode ser isso : de repente uma tabela de 180 GB que precise ser ordenada, sofrer a criação de uma hash table para hash join ou coisas do tipo pode Sim consumir mais do que os seus 50 GB de temp area numa query complexa, como são as de coleta de estatística, sim SE vc tiver o espaço disponível, experimente temporariamente deixar a temp tablespace com algumas centenas de GBs, pra ver se dá diferença... No momento estou sem acesso ao Metalink, a empresa ainda esta renovando contrato. Isso é um prob sério - como a falha acontece numa rotina interna do RDBMS, só o Suporte Oracle que pode te confirmar/negar a possibilidade de bug, Além do que se houver patch disponível é só lá no metalink que vc pode baixar Tente acelerar o mais possível essa renovação, e nesse meio-tempo d~e uma goolgada e veja se um DBA de outra Empresa do mesmo grupo que a sua, ou da matriz, coisas do tipo, pode fazer ao menos umas Consultas mais precisas/aprofundadas no metalink, em vc fornecendo os detalhes técnicos todos pra ele... No DBMS_STATS.GATHER_SCHEMA_STATS, tem como não executar numa determinada tabela? afaik Não Tem Não - em tese vc poderia usar as funções de LOCK de estatísticas na package DBMS_STATS para que essa tal tabela não sofra coleta, mas é so - pela GATHER_SCHEMA_STATS em si afaik não tem como... INCLUSIVE, esse foi um dos motivos que me levaram a *** abandonar *** esse cara completamente há muitos anos, junto com outros (tais como o fato de que as Mesmas Opções - de porcentual, de tipo/tamanho de histogramas, todas enfim - que vc indicou na gather_schema_stats vão ser usadas IGUALMENTE para o schema inteiro : se há tabelas grandes onde vc quer um % diferente, ou uma Ordem de coleta diferente, etc, Não Tem Como Então eu faço como eu disse, crio um scriptzinho sql*plus que me gera a lista de comandos DBMS_STATS.GATHER_TABLE_STATS para cada tabela, aí eu posso o customizar do jeito que preciso... Não existe nenhuma outra rotina concorrendo com o DBMS_STATS.GATHER_SCHEMA_STATS de madrugada Vc tem COMPLETA, TOTAl e ABSOLUTA certeza disso ??? Vc realmente MONITOROU ou está confiando na palavra de alguém Absolutamente não é Impossível que oficialmente a janela X deveria ser reservada para a tarefa Y *** mas *** aí aquele analistazinho ishperto ou aquele usuário importante vai lá e dispara algo sem vc saber nesse período, E/OU que a tarefa Y que começou antes da janela não terminou e que ela esteja rodando/consumindo temp area quando começa a janela das estatísticas... == Minha recomendação não muda : vc DEVERIA, se não o fez quando deu o erro, ter algum tipo de MONITORAMENTO e AUDITORIA DO CONSUMO da temp durante esse período da coleta, yep ??? Confiar desconfiando, esse é o lema do DBA... []s Chiappa OBS : espero que esteja CLARO para vc que as views tipo V$SORT_SEGMENT , V$SORT_USAGE , V$SESSION e relacionadas só registram a situação DO MOMENTO : assim, se vc rodar alguma consulta de consumo de temp AGORA, fora da janela, e não ver nada, absolutamente Não É Impossível que a consulta não mostrou nada porque agora não tem consumo/concorrência, MAS que na madrugada lá TENHA SIM, okdoc ??? Então consultas do ipo TEM QUE SER EXECUTADAS primeiro imediatamente Antes da coleta, E depois algumas vezes durante , okdoc ? Só assim vc vai ver a situação Real... --- Em oracle_br@yahoogrupos.com.br, Ednilson Silva ednilson.silva@... escreveu Chiappa, Tenho uma tabela de 180G e duas outras de 50G, são as maiores do banco em apenas um schema. No momento estou sem acesso ao Metalink, a empresa ainda esta renovando contrato. No DBMS_STATS.GATHER_SCHEMA_STATS, tem como não executar numa determinada tabela? Não existe nenhuma outra rotina concorrendo com o DBMS_STATS.GATHER_SCHEMA_STATS de madrugada. Grato, Ednilson Silva De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome de J. Laurindo Chiappa Enviada em: quarta-feira, 28 de novembro de 2012 12:43 Para: oracle_br@yahoogrupos.com.br Assunto: RES: [oracle_br] Re: ORA-01652: unable to extend temp Bem, pelo que eu vi vc aumentou para coisa de 50 GB (5 datafiles de 10 GB) a sua TEMP : na média de databases que se vê pelaí, isso até deveria ser suficiente, mas até pode acontecer de ainda ser insuficiente, ESPECIALMENTE se vc tem alguma tabela de dezenas de GB a ordenar para se coletar estatísticas (já vi casos de uma tabela até 2,5x o seu tamanho em área temp para ordenação e quetais) - assim, se pergunta, QUAL o tamanho (em bytes, não em linhas) das maiores tabelas desse schema que vc está coletando estats ?? SE for alguma coisa especialmente grande, na casa de umas tantas dezenas de GBs, pode ser que um aumento ainda maior da temp seja necessário, verifique SE não for isso , eu
RES: [oracle_br] Re: ORA-01652: unable to extend temp
Opa Ederson, Irei testar da forma que você indicou abaixo também. Grato, Ednilson Silva De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome de ederson2001br Enviada em: quarta-feira, 28 de novembro de 2012 15:37 Para: oracle_br@yahoogrupos.com.br Assunto: RES: [oracle_br] Re: ORA-01652: unable to extend temp Alô Edinilson, Permita minha opinião, uma outra ótica para sua questão. A sua rotina que está estourando a TEMP é esta que atualiza as estatísticas do schema e vc quer não executá-la para uma determinada tabela? Para estes casos, na sintaxe do GATHER_SCHEMA_STATS tem o parâmetro estimate_percent que geralmente fica em dbms_stats.auto_sample_size, mas vc pode colocar um valor fixo, 5 por exemplo, indicando que é para analizar as amostras de apenas 5% das linhas das tabelas e desta forma, não vai mais processar os 180G da sua tabela, apenas 9G (que representa 5%). --atualizar stats do schema exec dbms_stats.gather_schema_stats( - ownname = 'SEUSCHEMA', - options = 'GATHER AUTO', - estimate_percent = dbms_stats.auto_sample_size, - method_opt = 'for all columns size repeat', - cascade = true, - degree = 15 - ) Outra forma, seria vc executar para uma tabela específica: --atualizar estatisticas de uma só tabela EXECUTE DBMS_STATS.GATHER_TABLE_STATS(ownname = 'SEUSCHEMA', - tabname = 'TAB_PARCELAS_CONTRATO_MUTUO', - method_opt = 'FOR ALL INDEXED COLUMNS SIZE SKEWONLY', - granularity = 'ALL', - cascade = TRUE, - degree = DBMS_STATS.DEFAULT_DEGREE, - estimate_percent = 5); Ederson Elias DBA Oracle http://br.linkedin.com/pub/ederson-elias/24/8b/8b0 --- Em oracle_br@yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br , Ednilson Silva ednilson.silva@... escreveu Chiappa, Tenho uma tabela de 180G e duas outras de 50G, são as maiores do banco em apenas um schema. No momento estou sem acesso ao Metalink, a empresa ainda esta renovando contrato. No DBMS_STATS.GATHER_SCHEMA_STATS, tem como não executar numa determinada tabela? Não existe nenhuma outra rotina concorrendo com o DBMS_STATS.GATHER_SCHEMA_STATS de madrugada. Grato, Ednilson Silva [As partes desta mensagem que não continham texto foram removidas]
RES: [oracle_br] Re: ORA-01652: unable to extend temp
Chiappa, Obrigado pelas dicas, gerei um script para fazer DBMS_STATS.GATHER_TABLE_STATS de todas as tabelas e saquei a tabela de 180G, coloquei para executar hoje a noite todas as tabelas do schema. Grato, Ednilson Silva De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome de J. Laurindo Chiappa Enviada em: quarta-feira, 28 de novembro de 2012 15:04 Para: oracle_br@yahoogrupos.com.br Assunto: RES: [oracle_br] Re: ORA-01652: unable to extend temp Segue : Tenho uma tabela de 180G e duas outras de 50G Opa, pode ser isso : de repente uma tabela de 180 GB que precise ser ordenada, sofrer a criação de uma hash table para hash join ou coisas do tipo pode Sim consumir mais do que os seus 50 GB de temp area numa query complexa, como são as de coleta de estatística, sim SE vc tiver o espaço disponível, experimente temporariamente deixar a temp tablespace com algumas centenas de GBs, pra ver se dá diferença... No momento estou sem acesso ao Metalink, a empresa ainda esta renovando contrato. Isso é um prob sério - como a falha acontece numa rotina interna do RDBMS, só o Suporte Oracle que pode te confirmar/negar a possibilidade de bug, Além do que se houver patch disponível é só lá no metalink que vc pode baixar Tente acelerar o mais possível essa renovação, e nesse meio-tempo d~e uma goolgada e veja se um DBA de outra Empresa do mesmo grupo que a sua, ou da matriz, coisas do tipo, pode fazer ao menos umas Consultas mais precisas/aprofundadas no metalink, em vc fornecendo os detalhes técnicos todos pra ele... No DBMS_STATS.GATHER_SCHEMA_STATS, tem como não executar numa determinada tabela? afaik Não Tem Não - em tese vc poderia usar as funções de LOCK de estatísticas na package DBMS_STATS para que essa tal tabela não sofra coleta, mas é so - pela GATHER_SCHEMA_STATS em si afaik não tem como... INCLUSIVE, esse foi um dos motivos que me levaram a *** abandonar *** esse cara completamente há muitos anos, junto com outros (tais como o fato de que as Mesmas Opções - de porcentual, de tipo/tamanho de histogramas, todas enfim - que vc indicou na gather_schema_stats vão ser usadas IGUALMENTE para o schema inteiro : se há tabelas grandes onde vc quer um % diferente, ou uma Ordem de coleta diferente, etc, Não Tem Como Então eu faço como eu disse, crio um scriptzinho sql*plus que me gera a lista de comandos DBMS_STATS.GATHER_TABLE_STATS para cada tabela, aí eu posso o customizar do jeito que preciso... Não existe nenhuma outra rotina concorrendo com o DBMS_STATS.GATHER_SCHEMA_STATS de madrugada Vc tem COMPLETA, TOTAl e ABSOLUTA certeza disso ??? Vc realmente MONITOROU ou está confiando na palavra de alguém Absolutamente não é Impossível que oficialmente a janela X deveria ser reservada para a tarefa Y *** mas *** aí aquele analistazinho ishperto ou aquele usuário importante vai lá e dispara algo sem vc saber nesse período, E/OU que a tarefa Y que começou antes da janela não terminou e que ela esteja rodando/consumindo temp area quando começa a janela das estatísticas... == Minha recomendação não muda : vc DEVERIA, se não o fez quando deu o erro, ter algum tipo de MONITORAMENTO e AUDITORIA DO CONSUMO da temp durante esse período da coleta, yep ??? Confiar desconfiando, esse é o lema do DBA... []s Chiappa OBS : espero que esteja CLARO para vc que as views tipo V$SORT_SEGMENT , V$SORT_USAGE , V$SESSION e relacionadas só registram a situação DO MOMENTO : assim, se vc rodar alguma consulta de consumo de temp AGORA, fora da janela, e não ver nada, absolutamente Não É Impossível que a consulta não mostrou nada porque agora não tem consumo/concorrência, MAS que na madrugada lá TENHA SIM, okdoc ??? Então consultas do ipo TEM QUE SER EXECUTADAS primeiro imediatamente Antes da coleta, E depois algumas vezes durante , okdoc ? Só assim vc vai ver a situação Real... --- Em oracle_br@yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br , Ednilson Silva ednilson.silva@... escreveu Chiappa, Tenho uma tabela de 180G e duas outras de 50G, são as maiores do banco em apenas um schema. No momento estou sem acesso ao Metalink, a empresa ainda esta renovando contrato. No DBMS_STATS.GATHER_SCHEMA_STATS, tem como não executar numa determinada tabela? Não existe nenhuma outra rotina concorrendo com o DBMS_STATS.GATHER_SCHEMA_STATS de madrugada. Grato, Ednilson Silva De: oracle_br@yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br ] Em nome de J. Laurindo Chiappa Enviada em: quarta-feira, 28 de novembro de 2012 12:43 Para: oracle_br@yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br Assunto: RES: [oracle_br] Re: ORA-01652: unable to extend temp Bem, pelo que eu vi vc aumentou para coisa de 50 GB (5 datafiles de 10 GB) a sua TEMP : na média de databases que se vê pelaí, isso até deveria ser suficiente, mas até pode
RES: [oracle_br] Re: ORA-01652: unable to extend temp
Chiappa Muito obrigado, já criei um novo tempfile de 17G, irei colocar a rotina para executar essa noite. O banco esta com 700GB. Ednilson Silva De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome de J. Laurindo Chiappa Enviada em: terça-feira, 27 de novembro de 2012 15:14 Para: oracle_br@yahoogrupos.com.br Assunto: [oracle_br] Re: ORA-01652: unable to extend temp Sim, a msg : ORA-01652: unable to extend temp segment by 128 in tablespace TEMP é bem Clara quanto ao esgotamente da tablespace TEMP - se for o caso, vc até pode obter dados sobre o consumo real de tempspace consultando na hora que dá essa msg a v$sort_segment/v$sort_usage, OU tendo uma trigger de erro que faz e automatiza a consulta para vc, OU então (se tiver a Licença necessária) vc pode obter o histórico recente de utilização de tempspace via DBA_HIST_TEMPSTATXS e relacionadas, MAS a msg de erro não deixa muita margem ao diagnóstico de aumento do espaço de tablespace Sobre o quanto e o que aumentar : o que importa é o total de espaço (e não a qtdade de tempfiles, isso é largamente Irrelevante),e pelo que vejo vc tem hoje no total 3 GB - isso é o tamanho de um pendrive, é (num ambiente que Possui utilização) um tamanho que se pode considerar pequeno Eu diria para vc passar para pelo menos 10 GB essa tablespace e monitorar o consumo a partir daí, sendo Irrelevante se vc adicionar o espaço faltante em um, dois ou x tempfiles, desde Que o seu SO/hardware/ambiente permita arquivos de qquer tamanho []s Chiappa --- Em oracle_br@yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.com.br , Ednilson Silva ednilson.silva@... escreveu Pessoal, Tenho um banco aqui 10.2.0.4 em Red Hat 5.7 64 Bits, que tem uma rotina em crontab para executar o comando abaixo: exec dbms_stats.gather_schema_stats(ownname = 'HOMO',estimate_percent=20); E não esta concluindo dá o erro abaixo: SQL BEGIN dbms_stats.gather_schema_stats(ownname = 'HOMO',estimate_percent=20); END; * ERROR at line 1: ORA-01652: unable to extend temp segment by 128 in tablespace TEMP ORA-06512: at SYS.DBMS_STATS, line 13591 ORA-06512: at SYS.DBMS_STATS, line 13937 ORA-06512: at SYS.DBMS_STATS, line 14015 ORA-06512: at SYS.DBMS_STATS, line 13974 ORA-06512: at line 1 SQL select * from dba_tablespaces where tablespace_name = 'TEMP'; TABLESPACE_NAME BLOCK_SIZE INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS MAX_EXTENTS PCT_INCREASE MIN_EXTLEN STATUS CONTENTS LOGGING FORCE_LOGGING EXTENT_MANAGEMENT ALLOCATION_TYPE PLUGGED_IN SEGMENT_SPACE_MANAGEMENT DEF_TAB_COMPRESSION RETENTION BIGFILE -- -- -- --- --- --- -- - - - - - --- -- --- --- --- TEMP 8192 1048576 1048576 1 0 1048576 ONLINE TEMPORARY NOLOGGING NO LOCAL UNIFORM NO MANUAL DISABLED NOT APPLY NO SQL SELECT tablespace_name, file_name, bytes FROM dba_temp_files WHERE tablespace_name = 'TEMP'; TABLESPACE_NAME FILE_NAME BYTES --- -- -- TEMP /d004/oradata/prod/temp01.dbf 1048576000 TEMP /d004/oradata/prod/temp02.dbf 1048576000 TEMP /d004/oradata/prod/temp03.dbf 1048576000 Criando mais um tempfile irá resolver meu problema? Grato, Ednilson Silva [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas]
