Tablespace auf einen früheren Zeitpunkt zurücksetzen (TSPITR)

Befehl

-- 1) Is the tablespace self-contained (SQL, on the target DB):
EXEC DBMS_TTS.TRANSPORT_SET_CHECK(ts_list => 'USERS', incl_constraints => TRUE, full_check => TRUE);
SELECT * FROM transport_set_violations;
-- 2) Objects created AFTER the target time that TSPITR will lose:
SELECT owner, name, tablespace_name,
       TO_CHAR(creation_time,'YYYY-MM-DD HH24:MI:SS') AS created
FROM   ts_pitr_objects_to_be_dropped
WHERE  tablespace_name = 'USERS'
  AND  creation_time > TO_DATE('2026-01-15 03:00:00','YYYY-MM-DD HH24:MI:SS');
# 3) RMAN: with an automatic auxiliary instance
RECOVER TABLESPACE users
  UNTIL TIME "TO_DATE('2026-01-15 03:00:00','YYYY-MM-DD HH24:MI:SS')"
  AUXILIARY DESTINATION '/u03/aux';
# 4) The tablespace is left OFFLINE: take a backup first, then bring it online
BACKUP TABLESPACE users;
ALTER TABLESPACE users ONLINE;

Was es tut

RMAN stellt SYSTEM/UNDO/SYSAUX und den Ziel-Tablespace in einer temporären Hilfsinstanz bis zum gewünschten Zeitpunkt wieder her und hängt ihn dann per Transportable Tablespace wieder in die Zieldatenbank ein; der Rest der Datenbank bleibt aktuell.

Wann einsetzen

Wenn ein fehlerhafter Batchjob oder ein falsches DROP/TRUNCATE nur Daten in einem Tablespace (oder einer in sich konsistenten Gruppe von Tablespaces) beschädigt hat und Flashback-Optionen nicht ausreichen.

Vorsicht

ALLE in diesem Tablespace vorgenommenen Änderungen und alle nach dem Zielzeitpunkt angelegten Objekte gehen verloren. Die Tablespace-Gruppe muss in sich abgeschlossen sein (kein Index/keine Tabelle, Partition, LOB oder FK in einem anderen Tablespace). Für Tablespaces mit SYSTEM-, UNDO- oder SYS-Objekten ist es nicht nutzbar. Nach TSPITR sind frühere Backups dieses Tablespace unbrauchbar; erstelle sofort ein Backup. AUXILIARY DESTINATION braucht freien Platz für SYSTEM+SYSAUX+UNDO+den Ziel-Tablespace.