Verwendet man in seiner Oracle Datenbank Read Only Datafiles, gibt es einige Punkte die man unbedingt beachten sollte. Spätestens wenn man Container Datenbanken einsetzt hat man durch die PDB$SEED Read Only Datafiles und kann dies somit nicht verhindern.
RMAN BACKUP OPTIMIZATION
Wenn man Read Only Datafiles verwendet, sollte man darauf achten, dass BACKUP OPTIMIZATION deaktiviert ist:
RMAN> CONFIGURE BACKUP OPTIMIZATION OFF;
Wenn es aktiviert ist, werden die Read Only Datafiles nur einmal im Backupzyklus (Retention) gesichert, was die Sicherheit bei der Wiederherstellung deutlich reduziert. Auch wenn ein Backup den Status Expired aufweist, wird mit dieser Einstellung kein neues Backup der Read Only Datafiles erstellt.
Resetlogs und Read Only Datafiles
Verwendet man Read Only Datafiles, sollte man diese nach einem OPEN RESETLOGS unbedingt einmal öffnen, damit diese eine neue SCN von der aktuellen Incarnation bekommen. Ein Restore/Recover der Datenbank wäre auch dann noch möglich, wenn die Read Only Datafiles aus einer alten Incarnation sind – sollte man jedoch ein CREATE CONTROLFILE benötigen, landet man in folgendem Oracle Fehler:
ORA-01503: CREATE CONTROLFILE failed
ORA-01210: data file header is media corrupt
ORA-01110: data file : '/u01/app/oracle/oradata/orcl/daten_ro_01.dbf'
ORA-01189: file is from a different RESETLOGS than previous files
ORA-01110: data file 42: '/u01/app/oracle/oradata/orcl/daten_ro_01.dbf'
Damit man im Ernstfall keine Probleme damit hat, raten wir nach einem OPEN RESETLOGS alle Read Only Datafile zu kurz Read/Write zu öffnen, damit diese eine SCN von der aktuellen Incarnation erhalten. Für Tools wie z.b Netapp Snapcenter (oder andere Storage Based Backup Lösungen) verwenden ist dies notwendig, da beim Erstellen eines Clones mit CREATE CONTROLFILE ein neues Controlfile erstellt wird.
Workaround nach einem Create Controlfile mit Read Only Datafiles
Ein Restore mit Read Only Datafiles kann immer spannend werden, aber spätestens wenn das Controlfile neu erstellt wurde funktioniert dies nur mit einem Workaround. Der Workaround ist in folgender Oracle Note beschrieben: Recovering READONLY tablespace backups made before a RESETLOGS Open (Doc ID 266991.1)
Auch wenn die Read Only Datafiles von der gleichen Incarnation sind, kommt es immer wieder zu Problemem beim Recover dieser Files. Aus diesem Grund ist es wichtig diesen Workaround zu kennen:
- Restore vom Controlfile und Datafiles wie gewohnt, hier gibt es keine Besonderheiten
- Vor dem Recover müssen alle Read Only Datafiles OFFLINE genommen werden. Am einfachsten an der SNC bzw. TIME zu erkennen, da diese Files im Vergleich zu den Read Write Datafiles meist eine recht alte SNC bzw. eine alte TIME haben. Das folgende Statement erzeugt die notwendigen ALTER DATABASE Statements.
select 'alter database datafile '||file#||' offline;'
from v$recover_file
where time<sysdate-7;
- Jetzt kann der Recover stattfinden. Leider kann es passieren, dass der RMAN in solchen Konstellationen verwirrt ist und das Recover mit RMAN dann nicht funktioniert. In solch einem Fall raten wir sqlplus zu verwenden, das funktioniert immer!
recover database until cancel using backup controlfile;
- Nach dem Recover kann ein „open resetlogs“ erfolgen
alter database open resetlogs;
- Als nächstes muss man die Read Only Tablespaces identifizieren. Das geht am einfachsten über folgende Abfrage:
select tablespace_name,status from dba_tablespaces where status <>'ONLINE';
- Diese Tablespaces muss man jetzt ONLINE bringen. Der folgende Befehl erzeugt die dazu nötigen ALTER TABLESPACE Statements.
select 'alter tablespace '||tablespace_name||' online;'
from dba_tablespaces
where status <>'ONLINE';
Jetzt prüft Oracle die Datafile und nimmt diese Online, sofern kein Recover benötigt wird. Die Tablespaces bleiben in der ursprünglichen SCN und sind danach wie gewünscht READ ONLY geöffnet.
Hinweise zu DataPatch und PDB$SEED
Beim Patching mittels datapatch wird zumindest die PDB$SEED read-write geöffnet, gepatched und wieder auf Read-Only gestellt. Auf Read-Only Tablespaces hat datapatch keinen Einfluss. Somit ist es wichtig, dass man die PDB$SEED nach einen OPEN RESETLOGS ebenfalls kurz auf Read-Write zu bringen, damit es mit einem späteren CREATE CONTROLFILE kein Problem gibt.