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 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
> > 10000
> >
> > /d004/oradata/prod/temp02.dbf TEMP
> > 10000
> >
> > /d004/oradata/prod/temp03.dbf TEMP
> > 10000
> >
> > /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.... 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 <mailto:oracle_br%40yahoogrupos.com.br>
> oracle_br@yahoogrupos.com.br < <mailto:oracle_br%40yahoogrupos.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]
> >
>
>
>
>
>
> [As partes desta mensagem que não continham texto foram removidas]
>
