Menu de navegação

[leandrolbsParticipante]

Pessoal, boa tarde.

seguinte, em um cliente estou com uma tablespace TEMP a TEMP01.dbf com 28gb…

O sistema não utiliza nd esta tablespace, queria saber se procede:

SQL> create temporary tablespace temp2 tempfile ‘‘ size 100M extent management local uniform size 6M;

SQL> alter database default temporary tablespace temp2;
SQL> drop tablespace TEMP;

depois excluir o arquivo na MÃO…

Terei problemas?, quais os riscos?

[leandrolbsParticipante]

https://profissionaloracle.com.br/blogs/ … ablespace/

achei este belissimo post, alguem já teve a experiencia?…

[vieriParticipante]

Como verificou que o sistema não usa sua totalidade?

se ela está nesse valor provavelmente alguem aumentou, em função de problemas antigos.

Se não tiver com problema de espaço, não existe porque diminui-lá.

Uma área temporária grande é uma garantia que não haverá erros na criação de grandes indices, operações de ordenação.. etc..

O fata não está em uso no momento não significa que está espaço está inutil.

[leandrolbsParticipante]

Cara, to com 7mb livre agora!… =/

[leandrolbsParticipante]

deu certo….

script:

create temporary tablespace newtemp tempfile 'C:oracleproduct10.2.0oradataORAJRTEMP02.dbf' SIZE 500M AUTOEXTEND ON NEXT 64M MAXSIZE UNLIMITED ;

--= ok

alter database default temporary tablespace newtemp;

--== ok

drop tablespace temp including contents and datafiles;

--== ok

alter tablespace newtemp rename to temp;

--== ok

select name from v$tempfile;
select tablespace_name, file_name from dba_temp_files;

--==ok


[David SiqueiraParticipante]

Boa Leandro,

Sugiro que monitore essa tablespace TEMP nos próximos dias, porque se ela cresceu até 28Gb é provavel que algum processo de relatórios ou alguma query de teste, que use muitas clausulas de agregação ( count, avg, sum, etc) possam, estar gerando esses segmentos excessivos de sort, e por isso vale monitorar.

Até porque você reduziu ela ao extremo..rs..

Fica aqui a dica.

Abraço e parabéns pelo sucesso na implementação.

[vieriParticipante]

ela não irá estourar por causa do auto-extend,
mas se algum processo usar masis do que 500M
de sua área temporário, irá ficar muito lento en função do Wait Event,
Hight Water Mark Contention.

Concordo com o explanado pelo DRBS,
acho que vc se preocupou mais em
e realizar o procedimento de resize da área temporário do que com
a saúde do paciente ” o banco de dados” e entender o problema com uma visão mais ampla.

sugiro da uma olhada geral no alert, a partir do dia que o procedimento foi realizado até hoje…

[leandrolbsParticipante]

O sistema estava rodando a 6anos normalmente… então achei “normal” o “resize” da tablespace, mais em 10 dias voltou a ocorrer o “estouro” do tamanho me deixando com 7mb livre novamente, e novamente efetuei o “resize”.

Em questão de lentidão, não ocorreu… está normal mesmo com o tamanho reduzido, porem agora estou visualizando diariamente as execuções, pois deve existir algum modulo do sistema que gera informações nessa tablesapce.

obrigado pela atenção de todos, e descobrindo algo, volto a postar aqui para que sirva de expl. para outros..

vlw

[David SiqueiraParticipante]

Atente a data do estouro e questione seus desenvolvedores ou seus usuários finais sobr eos processos que rodam nesses dias em especial.

Isso esta com cara de relatório de sistema com periodos muito grandes, ou querys com Aggregated clausules excessivas, ou até mesmos os bons e velhos FTS’s ( Full table Scan ).

Verifique isso veja se consegue pegar a query em questão e propor melhorias para ela, uma criação de indice, menor utilização de Sort ( se possivel ), criação de processos alternativos pra onerar menos sua TEMP.

Segue um script que eu peguei pra monitorar quem usa mais TEMP :

set pages 100
set lin 1000
accep usr prompt "Digite o nome do Usuário (Banco)...:"
accep osr prompt "Digite o Nome do Usuario (OS)......:"

set hea on
col PHYRDS format a9
col PHYWRTS format a9
col READTIM format a9
col WRITETIM format a9
col name format a35 wra
ttitle "Disk Balancing Report"

select name
, round(phyrds/1024)||'K' as phyrds
, round(phywrts/1024)||'K' as phywrts
, round(readtim/1024)||'K' as readtim
, round(writetim/1024)||'K' as writetim
from gv$filestat a, gv$dbfile b
where a.file# = b.file#
and upper(b.name) like '%TMP%' or upper(b.name) like '%TEMP%'
order by name,readtim desc;

clear col
ttitle off

var x number
var b number
var s number
var z varchar2(60);
set feed off
execute :x := dbms_utility.get_parameter_value('db_block_size',:b,:z);
execute :x := dbms_utility.get_parameter_value('sort_area_size',:s,:z);
set feed on

col Tablespace format a15

SELECT tablespace_name "Tablespace",
current_users "Usuario|Corrente",
total_extents "Total|Extensoes",
used_extents "Extensoes|Usadas",
free_extents "Extensoes|Livres",
max_used_size "Espaco|MaximoUsado",
extent_size "Tamanho|Extensao",
(:b+:s)/1024 "Tamanho|Ideal",
:b "Tamanho|Bloco"
FROM gv$sort_segment;

col Usuario format a15;

break on username on sid on Tablespace
compute sum of Blocos on Tablespace
compute sum of kblocks on Tablespace
compute sum of Extensoes on Tablespace
compute sum of Blocos on report
compute sum of kblocks on report
compute sum of Extensoes on report

SELECT s.inst_id,
s.username "Usuario",
s.osuser "Os|User",
s.sid "Sid",
u.tablespace "Tablespace",
u.contents "Contents",
u.extents "Extensoes",
u.blocks "Blocos",
blocks*:b/1024 kblocks
FROM gv$session s, gv$sort_usage u
WHERE s.saddr=u.session_addr
and s.username like upper(nvl('%&usr%',s.USERNAME))
and s.osuser like upper(nvl('%&osr%',s.OSUSER));

Abraço!!!!

[Autor]

Posts