O que significa o erro ORA-01652 unable to extend temp segment?

O ORA-01652 indica que a tablespace TEMP não tem espaço suficiente para operações de sort, hash join ou criação de índices temporários. As causas mais comuns são: queries complexas que exigem sorts grandes, sessões que seguram espaço temp sem liberar, ou tablespace TEMP subdimensionada para o volume de dados. A solução imediata é adicionar um datafile temporário ou aumentar o existente com AUTOEXTEND.

Como liberar espaço em uma tablespace Oracle sem adicionar disco?

Existem várias estratégias: identificar e remover objetos obsoletos (tabelas de log antigas, tabelas temporárias abandonadas), fazer purge da recycle bin com PURGE DBA_RECYCLEBIN, mover tabelas com muitos blocos vazios usando ALTER TABLE MOVE, rebuildar índices fragmentados, e comprimir tabelas históricas. Antes de qualquer ação, identifique os maiores consumidores de espaço com DBA_SEGMENTS para agir cirurgicamente.

Devo usar AUTOEXTEND em tablespaces de produção?

Sim, mas com limites. O AUTOEXTEND evita paradas inesperadas por falta de espaço, mas deve ter um MAXSIZE definido para não consumir todo o disco. A prática recomendada é AUTOEXTEND ON com MAXSIZE adequado ao ambiente, combinado com alertas de monitoramento que avisam quando o uso atinge 80-85%. Isso dá tempo para planejar a expansão antes que vire emergência.

Tablespace Oracle Cheia: Diagnóstico e Solução Rápida

Poucos problemas em Oracle causam tanto pânico quanto o "tablespace cheia". A aplicação começa a dar erro, inserts falham, batch jobs abortam, e de repente o telefone não para de tocar. Os erros mais comuns que você vai ver no alert.log e na aplicação são:

ORA-01652: unable to extend temp segment — tablespace TEMP sem espaço
ORA-01653: unable to extend table — tablespace de dados sem espaço
ORA-01654: unable to extend index — tablespace de índice sem espaço
ORA-30036: unable to extend segment by 8 in undo tablespace — UNDO sem espaço

Todos indicam o mesmo problema fundamental: uma tablespace atingiu seu limite. Neste guia, vou te mostrar como diagnosticar rapidamente qual tablespace está cheia, o que está consumindo espaço, e como resolver — tanto a emergência imediata quanto a prevenção definitiva.

1. Diagnóstico: qual tablespace está cheia?

Primeiro, uma visão geral do uso de todas as tablespaces:

SQL — Uso de espaço por tablespace

      SELECT tablespace_name,

        ROUND(used_space * 8192 / 1024 / 1024 / 1024, 2) AS used_gb,

        ROUND(tablespace_size * 8192 / 1024 / 1024 / 1024, 2) AS total_gb,

        ROUND(used_percent, 1) AS pct_used

      FROM dba_tablespace_usage_metrics

      ORDER BY used_percent DESC;

Tablespaces acima de 90% são críticas. Acima de 95%, é emergência — podem travar a qualquer momento.

2. Quem está consumindo o espaço?

Depois de identificar a tablespace problemática, descubra os maiores consumidores:

SQL — Top 20 objetos por tamanho em uma tablespace

      SELECT owner, segment_name, segment_type,

        ROUND(bytes / 1024 / 1024 / 1024, 2) AS size_gb

      FROM dba_segments

      WHERE tablespace_name = '<TABLESPACE_NAME>'

      ORDER BY bytes DESC

      FETCH FIRST 20 ROWS ONLY;

Preste atenção em:

Tabelas de log/auditoria que crescem indefinidamente sem purge
Tabelas de interface/staging que deveriam ser limpas periodicamente
Índices enormes que podem estar fragmentados e ocupando mais espaço que o necessário
LOBs (Large Objects) que frequentemente são os maiores consumidores escondidos

3. Solução emergencial: ganhar espaço imediato

Se a aplicação já está falhando, você precisa ganhar espaço agora. Aqui estão as ações em ordem de velocidade e segurança:

3.1. Adicionar datafile

A forma mais rápida e segura de ganhar espaço. Não mexe em nenhum dado existente:

SQL — Adicionar datafile a uma tablespace

      ALTER TABLESPACE USERS ADD DATAFILE

        '/u01/app/oracle/oradata/orcl/users02.dbf'

        SIZE 10G AUTOEXTEND ON NEXT 1G MAXSIZE 30G;

Para tablespace TEMP:

SQL — Adicionar tempfile

      ALTER TABLESPACE TEMP ADD TEMPFILE

        '/u01/app/oracle/oradata/orcl/temp02.dbf'

        SIZE 5G AUTOEXTEND ON NEXT 512M MAXSIZE 20G;

3.2. Habilitar AUTOEXTEND no datafile existente

Se o datafile não tem autoextend e há espaço no disco:

SQL — Verificar autoextend dos datafiles

      SELECT file_name, tablespace_name,

        ROUND(bytes/1024/1024/1024, 2) AS size_gb,

        ROUND(maxbytes/1024/1024/1024, 2) AS max_gb,

        autoextensible

      FROM dba_data_files

      WHERE tablespace_name = '<TABLESPACE_NAME>'

      ORDER BY file_name;

SQL — Habilitar autoextend

      ALTER DATABASE DATAFILE

        '/u01/app/oracle/oradata/orcl/users01.dbf'

        AUTOEXTEND ON NEXT 1G MAXSIZE 30G;

3.3. Purgar a Recycle Bin

Tabelas "dropadas" vão pra recycle bin e continuam ocupando espaço. Se tem objetos lá, liberar é instantâneo:

SQL — Verificar e limpar recycle bin

      -- Verificar tamanho da recycle bin

      SELECT SUM(space) * 8192 / 1024 / 1024 AS recycle_mb

      FROM dba_recyclebin;

      -- Limpar tudo

      PURGE DBA_RECYCLEBIN;

Dica de especialista: Em bancos de produção com anos de uso, já encontrei recycle bins ocupando dezenas de gigabytes. É o "espaço invisível" que todo mundo esquece. Uma consulta rápida pode liberar espaço sem risco nenhum.

4. Casos especiais: TEMP e UNDO

Tablespace TEMP cheia (ORA-01652)

A TEMP é usada para sorts, hash joins e operações temporárias. Quando enche, geralmente é porque uma query grande está consumindo tudo:

SQL — Quem está consumindo espaço na TEMP

      SELECT s.sid, s.serial#, s.username, s.sql_id,

        ROUND(u.blocks * 8192 / 1024 / 1024, 1) AS temp_mb

      FROM v$session s

      JOIN v$sort_usage u ON s.saddr = u.session_addr

      ORDER BY u.blocks DESC;

Se uma sessão está consumindo GBs de TEMP, provavelmente é uma query mal otimizada que precisa de tuning — sort em tabela grande sem índice, cartesian join acidental, ou query sem predicado adequado.

Tablespace UNDO cheia (ORA-30036)

A UNDO guarda as versões anteriores dos dados para rollback e read consistency. Causas comuns de UNDO cheia:

Transação grande sem commit — um UPDATE em milhões de linhas sem commit intermediário
UNDO_RETENTION muito alto para o tamanho da tablespace
Sessão "esquecida" com transação aberta há horas

SQL — Verificar uso da UNDO

      SELECT tablespace_name, status,

        ROUND(SUM(bytes) / 1024 / 1024 / 1024, 2) AS size_gb

      FROM dba_undo_extents

      GROUP BY tablespace_name, status

      ORDER BY tablespace_name, status;

Os status são: ACTIVE (transação em andamento, não pode liberar), UNEXPIRED (dentro do undo_retention, prefere não liberar) e EXPIRED (pode ser reutilizado).

5. Liberando espaço sem adicionar disco

Quando não tem como adicionar mais storage, estas são as alternativas:

5.1. Identificar e remover objetos obsoletos

SQL — Tabelas que não recebem DML há mais de 6 meses

      SELECT owner, table_name, last_analyzed,

        ROUND(num_rows * avg_row_len / 1024 / 1024, 1) AS est_mb

      FROM dba_tables

      WHERE tablespace_name = '<TABLESPACE_NAME>'

        AND last_analyzed < SYSDATE - 180

      ORDER BY num_rows * avg_row_len DESC NULLS LAST

      FETCH FIRST 20 ROWS ONLY;

5.2. Reorganizar tabelas fragmentadas

Tabelas que recebem muitos DELETE ficam com blocos vazios que não são liberados automaticamente. O ALTER TABLE MOVE reorganiza e recupera esse espaço:

SQL — Mover tabela para recuperar espaço

      ALTER TABLE schema.tabela MOVE;

      -- ATENÇÃO: rebuild dos índices é obrigatório após MOVE

      ALTER INDEX schema.idx_tabela REBUILD;

Atenção: ALTER TABLE MOVE invalida todos os índices da tabela e requer espaço temporário adicional (aproximadamente o tamanho da tabela). Faça em janela de manutenção e confirme que tem espaço antes de executar. No Oracle 12c+, você pode usar MOVE ONLINE para evitar lock exclusivo.

5.3. Comprimir tabelas históricas

Tabelas de histórico ou auditoria que raramente são modificadas podem ser comprimidas:

SQL — Comprimir tabela

      ALTER TABLE schema.historico MOVE COMPRESS;

      ALTER INDEX schema.idx_historico REBUILD;

Compressão básica pode reduzir o tamanho em 50-70% para tabelas com dados repetitivos.

6. Prevenção: nunca mais ser pego de surpresa

Resolver a emergência é metade do trabalho. A outra metade é garantir que não aconteça de novo:

Monitoramento com alertas — Configure scripts ou Oracle Enterprise Manager para alertar quando qualquer tablespace atingir 80% e 90%. Isso dá tempo de agir antes da crise.
AUTOEXTEND com MAXSIZE — Todas as tablespaces de produção devem ter AUTOEXTEND ON com MAXSIZE definido. Evita paradas por falta de espaço mas não deixa o banco consumir todo o disco.
Política de retenção de dados — Tabelas de log, auditoria e interface precisam de purge automatizado. Se a aplicação não faz, crie jobs Oracle pra fazer.
Review periódico de espaço — Uma vez por mês, rode os SQLs deste artigo e identifique tendências de crescimento. Planejar é mais barato que apagar incêndio.
Estratégia de backup alinhada — FRA (Fast Recovery Area) é uma tablespace especial. Monitore-a junto com as demais. FRA cheia é uma das causas mais comuns de banco travado.

Script de monitoramento rápido: O SQL de diagnóstico da seção 1 deste artigo pode ser agendado como um job Oracle que envia e-mail quando qualquer tablespace ultrapassar 85%. Se precisar de ajuda pra configurar, fale com a gente.

7. Quando escalar para suporte especializado

Se a tablespace encheu e você não sabe o que está causando o crescimento, ou se o problema volta toda semana mesmo depois de adicionar espaço — o problema não é espaço. É arquitetura, design de tabelas, ou queries que geram lixo de dados desnecessário.

Nesses casos, o ideal é uma análise profunda que envolve tuning das queries que mais consomem espaço, revisão do modelo de dados e implementação de particionamento para tabelas que crescem indefinidamente. Se o banco travou e a operação parou, nosso S.O.S. DBA resolve a emergência em tempo real — 24/7.

Tablespace cheia e operação parada?

Nossa equipe resolve a emergência agora e implementa monitoramento para prevenir recorrência.

Chamar especialista agora Chamar no WhatsApp

Fernando Camacho Bohm

Oracle Certified Professional desde 2001. Fundador da Fábrica de Dados. 25 anos administrando bancos Oracle em ambientes de missão crítica — de 9i a 23ai, de on-premise a cloud.