I forbindelse med en natlig flytning fra en disk til en anden, faktisk for over 5 dage siden, kom der en alarm til morgen, med at overvågningen fik anbefalet at tilføje eller resize datafilen til et tablespace, da der ikke var nok plads til at extente, sådan kort fortalt.

Fejlen har nok været der de sidste 5 dage, men da vores team, ikke er primære på disse, ser vi dem ikke altid. Det er kun hvis der er lidt luft, vi også kigger andres logs igennem.

Undertegnede fik kigget på det, og så 3 mærkelige ting; datafilens navn var MISSING00014 placeret i $ORACLE_HOME/dbs og størrelsen var 0 bytes - så overvågnings scriptet havde jo ret, der var ingen plads at extente.

Kigger man i alert_$ORACLE_SID.log filen ses følgende:

Thu Jul  3 22:54:17 2008
File #14 found in data dictionary but not in controlfile.
Creating OFFLINE file MISSING00014 in the controlfile.

Oracle 11 Administrations guiden har følgende kommentarer nedfældet på deres webside, som beskriver situationen godt.

I vores tilfælde eksisterer MISSING00014 filen fysisk ikke, men den rigtige oprindelige datafile ligger fint i det katalog vi forventer. v$recover_file viser dels at filen er offline og missing.

Man kunne vel vælge at kaste sig ud i noget no mount ud fra en alter database backup controlfile to trace, editere missing entrien til det rigtige filnavn, for herefter at recover database using backup controlfile ? og så herefter en alter database open resetlogs. Tror du det kunne lade sig gøre ?

Det ville dog forudsætte man havde de archives tilgængelige, Oracle måtte syntes til recovery. Da vores setup er en udviklings base, og vi kører no archivelogs, vælger vi at droppe og lave tablespacet igen, for herefter at importere data fra produktion.