Gunther Oracle APEX und Datenbank Wiki

Aufgabe

Durch ein „ungeschickt“ programmiertes Feature im neuen ORDS 25 hat dieser sich nicht bewährt, nun wurde versucht wieder auf den alten Stand des ORDS zurück zu gehen, leider ist der ORDS aber nicht so recht robust bzgl. eines Rollbacks der Version.

Daher soll nun der Tablespace, der das ORDS Meta Schema enthält, wieder auf den Stand der Vortags gesetzt werden.

Eine Option der Datenbank, die für solche Szenarien genützt werden kann, ist Flashback , allerdings müsste das VOR der Veränderung an der DB bereits aktiv sein und in sehr produktiven Datenbanken ist das Zeitfenster oft recht eng um das wirklich einzusetzen.

Daher soll nun nur der Tablespace mit dem ORDS Schema mit einem automatischen TSPITR (Tablespace Point-in-Time Recovery) mit RMAN zurück gesetzt werden.

Ablauf:

• Prüfen ob Tablespace der Default Tablespace der Datenbank ist - Falls ja auf anderen Tablespace änderen
• Prüfen ob der Tablespace keine Abhängigen zu anderen Tablespaces enthält, falls ja ist der Vorgang nicht durchführbar!
• Kontrollieren ob Backup inkl. Controlfile für den Zeitraum existiert in dem Zurück gesetzt werden soll!
• Datenbank komplett offline per Snapshot oder DB File Copy zur Sicherheit sichern
• Destination für die Auxillary Datenbank anlegen und prüfen ob genug Plattenplatz zur Verfügung steht (SYSTM/SYSAUXUNDO + der zu rücksichernde Tablespace!)
• RMAN im automatischen Mode aufrufen
  • Auxillary Instance wird angelegt
  • Backup der zentralen Tablespaces (SYSTEM/UNDO/SYSAUX) und Ziel Tablespace wird eingespielt
  • Ziel Tablespace wird mit den Archiven auf den richtigen Zeitpunkt recoverd
  • Ziel Tablepace wird mit EXPDB exportiert als Transportable Tablespace
  • Aux Instance wird wieder entfernt
  • Ziel Tablespace wird in der Datenbank per Transportable Tablespace Feature „eingehängt“
• Ziel Tablespace online nehmen

Und drauf achten das nicht durch eine RMAN Sicherung zu viel die benötigte „alte“ Sicherung überschrieben wird!

Der Tablespace darf nicht der DEFAULT_PERMANENT_TABLESPACE sein!

SYS>SELECT property_value FROM DATABASE_PROPERTIES WHERE property_name = 'DEFAULT_PERMANENT_TABLESPACE';
 
PROPERTY_VALUE
-----
USERS

Falls ja, auf einen anderen Tablespace setzen!

SYS>ALTER DATABASE DEFAULT TABLESPACE AUDITLOG;

v$log:

• SEQUENCE# NUMBER Log sequence number
• FIRST_CHANGE# NUMBER Lowest system change number (SCN) in the log
• FIRST_TIME DATE Time of the first SCN in the log

Für das Setzten des können folgende Zeitangaben verwendet werden (aus der Doku):

UNTIL SCN = integer
Specifies an SCN as an upper limit. RMAN selects only files that can be used to recover up to but not including the specified SCN. For example, RESTORE DATABASE UNTIL SCN 1000 chooses only backups that could be used to recover to SCN 1000.
 
UNTIL SEQUENCE = integer THREAD = integer
Specifies a redo log sequence number and thread as an upper limit. RMAN selects only files that can be used to recover up to but not including the specified sequence number. For example, REPORT OBSOLETE UNTIL SEQUENCE 8000 THREAD 1 reports only backups that could be used to recover through log sequence 7999.
 
UNTIL TIME = 'date_string'
Specifies a time as an upper limit. RMAN selects only files that can be used to recover up to but not including the specified time. For example, LIST BACKUP UNTIL TIME 'SYSDATE-7' lists all backups that could be used to recover to a point one week ago.

siehe https://docs.oracle.com/en/database/oracle/oracle-database/23/rcmrf/untilClause.html

Für den Zeitpunkt die SCN und die Log Sequence ermitteln:

 
SELECT timestamp_to_scn(TO_TIMESTAMP('2025-07-16 20:00:00', 'YYYY-MM-DD HH24:MI:SS')) AS scn_at_this_time FROM dual;
 
SCN_AT_THIS_TIME
----------------
        11800788
 
 
 
 
WITH time_period AS (
    SELECT 
        MIN(first_change#) AS min_scn,
        MAX(next_change#) AS max_scn
    FROM 
        v$archived_log
    WHERE 
        first_time <= TO_TIMESTAMP('2025-07-16 20:00:00', 'YYYY-MM-DD HH24:MI:SS')
        AND next_time >= TO_TIMESTAMP('2025-07-16 20:00:00', 'YYYY-MM-DD HH24:MI:SS')
        AND dest_id = 1
        AND archived = 'YES'
)
SELECT 
    al.sequence# AS log_sequence_number,
    al.first_change# AS start_scn,
    al.next_change# AS end_scn,
    TO_CHAR(al.first_time, 'YYYY-MM-DD HH24:MI:SS') AS start_time,
    TO_CHAR(al.next_time, 'YYYY-MM-DD HH24:MI:SS') AS end_time,
    al.name AS archived_log_name,
    (SELECT current_scn FROM v$database) AS current_scn,
    (SELECT resetlogs_change# FROM v$database) AS resetlogs_scn,
    tp.min_scn AS period_min_scn,
    tp.max_scn AS period_max_scn
FROM 
    v$archived_log al,
    time_period tp
WHERE 
    al.first_change# BETWEEN tp.min_scn AND tp.max_scn
    AND al.dest_id = 1
    AND al.archived = 'YES'
ORDER BY 
    al.sequence# DESC;
 
 
LOG_SEQUENCE_NUMBER    START_SCN      END_SCN START_TIME          END_TIME              ARCHIVED_LOG_NAME   CURRENT_SCN   RESETLOGS_SCN PERIOD_MIN_SCN PERIOD_MAX_SCN
------------------- ------------ ------------ ------------------- -------------------   ------------------- ------------- ------       -------------------
117                    12635769     12641314  2025-07-16 21:10:27 2025-07-16 21:20:42   12645239             1            12630222       12635769

Das Backup:

• Komplettes RMAN Backup des Tablespaces VOR dem „Problem“ Zeitpunkt
  • Darauf achten das auch der Controlfile dabei ist! Wie:

    backup current controlfile;
    backup database INCLUDE CURRENT CONTROLFILE;
    backup archivelog all;
    backup current controlfile;

• Alle Archive zwischen letzten Full Backup des Tablespaces

Prüfen:

# SID und Umgebung setzen
rman
CONNECT target /
 
# Tablespace Files anzeigen lassen für die Datei Nummer
Report Schema;
 
RMAN> report schema;
report schema;
USING target DATABASE control file instead OF recovery catalog
Report OF DATABASE schema FOR DATABASE WITH db_unique_name FREE
 
List OF Permanent Datafiles
===========================
File SIZE(MB) Tablespace           RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
...
4    500      USERS                NO      /opt/oracle/oradata/GPIDB/user01.dbf
..
 
 
#Backups anzeigen lassen
 
list backup OF controlfile;
 
...
 Control File Included: Ckp SCN: 12644758
....
 
 
list backup;
 
...
 4       FULL 12644047   16-JUL-25              NO    /opt/oracle/oradata/GPIDB/user01.dbf
...
 
 
list backup OF datafile 4;
..
File LV TYPE Ckp SCN    Ckp TIME  Abs Fuz SCN Sparse Name
  ---- -- ---- ---------- --------- ----------- ------ ----
  4       FULL 12644047   16-JUL-25              NO    /opt/oracle/oradata/GPIDB/user01.dbf
..
 
list backup OF archivelog ALL;
 
 
 List OF Archived Logs IN backup SET 11
  Thrd Seq     Low SCN    Low TIME  NEXT SCN   NEXT TIME
  ---- ------- ---------- --------- ---------- ---------
..
  1    118     12641314   16-JUL-25 12641321   16-JUL-25
  1    119     12641321   16-JUL-25 12641327   16-JUL-25
..

In „list Backup“ die SCN ermitteln zu dem das Backup stattgefunden hat und den Zeitpunkt daraus ableiten:

RMAN> SELECT  scn_to_timestamp(12635583) AS timestamp_value FROM dual;
 
TIMESTAMP_VALUE
-------------------------------
16-JUL-25 09.08.53.000000000 PM

Das ist dann der Zeitpunkt zu dem wir am weitesten zurückgehen können!

Log Nr dazu:

SELECT 
    SEQUENCE# AS log_sequence_number,
    first_change# AS start_scn,
    next_change# AS end_scn,
    TO_CHAR(first_time, 'YYYY-MM-DD HH24:MI:SS') AS start_time,
    TO_CHAR(next_time, 'YYYY-MM-DD HH24:MI:SS') AS end_time
FROM 
    v$archived_log
WHERE 
    12635583 BETWEEN first_change# AND next_change#
    AND dest_id = 1
    AND archived = 'YES';
 

Voraussetzung:

Tablespace ist „Transportable“ Fähig, d.h. das alle Objekte liegen in dem Tablespace !

Test mit:

SET serveroutput ON
 
BEGIN
   DBMS_TTS.TRANSPORT_SET_CHECK('USERS', TRUE,TRUE);
END;
/
 
PL/SQL PROCEDURE successfully completed.
 
SELECT * FROM  TRANSPORT_SET_VIOLATIONS;
 
no ROWS selected

Die Abfrage darf keine Treffer zurück bringen!

Sollen noch andere Objekte gesichert werden?

Prüfen welche Objekte nach dem Restore nicht mehr vorhanden sind:

SELECT OWNER, NAME, TABLESPACE_NAME, 
       TO_CHAR(CREATION_TIME, 'YYYY-MM-DD:HH24:MI:SS') 
       FROM TS_PITR_OBJECTS_TO_BE_DROPPED 
WHERE TABLESPACE_NAME IN ('USERS','TOOLS') 
AND CREATION_TIME > TO_DATE('2025-07-16 20:00:00', 'YYYY-MM-DD HH24:MI:SS')
ORDER BY TABLESPACE_NAME, CREATION_TIME;
 
SELECT OWNER, NAME, TABLESPACE_NAME,
       TO_CHAR(CREATION_TIME,'YYYY-MM-DD:HH24:MI:SS')
       FROM TS_PITR_OBJECTS_TO_BE_DROPPED
WHERE TABLESPACE_NAME IN ('USERS','TOOLS')
AND CREATION_TIME > TO_DATE(TO_CHAR(SCN_TO_TIMESTAMP(11719532),
'MM/DD/YYYY HH24:MI:SS'),
'MM/DD/YYYY HH24:MI:SS')
ORDER BY TABLESPACE_NAME, CREATION_TIME;

Wenn diese sind mit DataPump sichern!

Sind nun die Verausetzugen geben, keine Abhänigkeiten werden befürchtet dann kann es losgehen

Um so eine Restore umzusetzen wird vom RMAN eine eigene Instance gestartet, der Tablespace wird aus dem Backup in eine neue File Location restored und dann recoverd.

prüfen wo wir gerade stehen:

SELECT * FROM v$log WHERE STATUS = 'CURRENT';
 
17 

Dest anlegen:

mkdir /opt/oracle/oradata/auxDest

!! Prüfen ob wir auch eine gute Sicherung haben für einen Fallback der Maschine! Snapshot ziehe etc! !!

rman:

 
RMAN> CONNECT target /
 
RMAN> 
 
RECOVER TABLESPACE users
  UNTIL LOGSEQ 15 THREAD 1
  AUXILIARY DESTINATION '/opt/oracle/oradata/auxDest';

Der Tablepace ist nun offline recoverd

Sicherung anlegen!

RMAN>  BACKUP TABLESPACE users;

Tablespace wieder online nehmen:

RMAN> ALTER TABLESPACE users ONLINE;

Mit der FREE Edition kann das wohl nicht getestet werden, die Free reagiert auf einen anderen SID außer FREE etwas „allergisch“ mit einem ORA-00441: Oracle Free Edition SID violation

RMAN-04014: startup failed: ORA-00441: Oracle Free Edition SID violation. Expected:free vs Actual:jvyo

RMAN-11003: failure during parse/execution of SQL statement: drop tablespace  USERS including contents keep datafiles cascade constraints
ORA-12919: Can not drop the default permanent tablespace

Ist der Tablespace der Default Tablespace:

SYS@GPIDB-apex01>SELECT property_value FROM DATABASE_PROPERTIES WHERE property_name = 'DEFAULT_PERMANENT_TABLESPACE';
 
PROPERTY_VALUE
-----------------
USERS

Doku:

• https://docs.oracle.com/en/database/oracle/oracle-database/19/bradv/performing-rman-tspitr.html