Zo’n 6 keer uitgevoerd op een ontwikkel-database: restoren via rman naar een bepaalde tijd. 7e keer gaat het restore-gedeelte goed, recovery niet: RMAN-06053, missing log – terwijl die er toch echt is naar mijn bescheiden mening. Database versie 10.2.0.3 op Suse 9.

Gebruikt script:

run{
set until time “to_date(‘20081202 09:00:00′,’YYYYMMDD HH24:MI:SS’)”;
restore database;
recover database;
}

Werkte tot nu toe feilloos.

Volledige foutmelding:

Oracle Error:

ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below

ORA-01194: file 1 needs more recovery to be consistent

ORA-01110: data file 1: ‘/data1/oracle/odin/datafile/system01.dbf’

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of recover command at 12/03/2008 11:01:07

RMAN-06053: unable to perform media recovery because of missing log

RMAN-06025: no backup of log thread 1 seq 5 lowscn 9721501676 found to restore

——————

Het zou kunnen zijn dat ik geen backup meer gemaakt na de vorige restore-actie. Dan zou het een incarnation-verhaal worden, je kan restoren met een andere incarnatie.

Maar daar zou 10g tegen moeten kunnen, en het lijkt het er toch echt op dat ik van de juiste incarnation gebruik maak (V$DATABASE_INCARNATION). In de alert-file staat met welke incarnation deze opent. Datafile-headers staan goed in de controlfile (V$DATAFILE_HEADER).

In ieder geval, met RMAN kwam ik er niet echt uit. Lijkt er op dat de gegevens in de controlfile niet meer overeenkwamen met de datafile. Dan maar terug naar SQL, en gebruik maken van gegevens van de datafiles en een blanko controlfile gebruiken (using backup control file).

En jawel: ‘recover database using backup control file until cancel’ ging feilloos, hoewel minder controle over het tijdstip tot wanneer gerecovered wordt (weet dus niet of ‘until scn’ wel zou werken….). Hierna ‘open resetlogs’ en het draaide allemaal weer. Wat de oorzaak was?  Beetje te haastig, ik wilde de database gewoon open hebben, dus helaas niet verder gekeken. Ik gok toch maar op een incarnatie-bugje.