Alert Entry for Missing Data File

Question

I am trying a simple recovery scenario: deleting a data file of a normal tablespace when the database is running, and the data file has been backed up.
Before shutdown, checkpoint completes normally (I guess Oracle still keeps the file inode handle). When I select from dba_data_files, error occurred:
SQL> alter system checkpoint;
System altered.
SQL> select count(*) from dba_data_files;
select count(*) from dba_data_files
ERROR at line 1:
ORA-01116: error in opening database file 10
ORA-01110: data file 10: '/u01/oradata/data01.dbf'
ORA-27041: unable to open file
Linux Error: 2: No such file or directory
Additional information: 3To my surprise, nothing was recorded in the alert log. And no trace files generated in udump. And Oracle refused to restore the datafile when it was running.
Message appeared in alert log when I try to shutdown the database. After shutdown abort (Oracle refused to shutdown immediate) and restart instance, I was able to restore and recover the data file.
Is this the expected behaviour? If so, how would you detect missing datafiles when db is running?
Oracle: 9.2.0.6, OS: RHEL3

Answer 1

1. It wasn't detected by the checkpoint caused by a switch logfile because the file isn't actually missing. As others -inded you!- have said, on Unix/Linux, you can delete a file at any time, but if the file is in use, the inodes remain allocated and the process using it continues to see it very much as there. Because, at the inode level, it absolutely IS still there! Incidentally, it was pointless telling you to do a switch logfile, because as far as datafiles are concerned, that doesn't do anything the alter system checkpoint command does that you'd already tried.
I used to do demos of how to recover from the total loss of a controlfile in Oracle University classes: I'd do a flurry of rm *.ctl commands, and then dramatically issue the checkpoint command... and nothing at all happened. Very demoralising first time I did it. Issue a startup force, however, and at that point the inodes are released, the files really are deleted and the startup falls over in the nomount state. Bouncing the instance was the only way I could get the database to protest about the removal of a datafile, too.
2. No, if a file went missing in a way that Oracle could detect, it wouldn't matter if the file was empty, because it cares about the presence/absence of the datafile headers. They have to be updated, even if nothing else does.
3. It would only be in the alert log if SMON detected the lost file at startup (one of its jobs is, explicitly, to check for the existence of all files mentioned in the control file). CKPT wouldn't raise an alert, because as far as it's concerned, nothing's wrong. The inodes are still held, after all. Your attempts to create tables and so on inside the lost file do generate display errors because (I think) at that point it's your server process that is attempting to do things to the file, not CKPT or other pre-existent, permanently-running background processes.
4. It's specific to Unix, anyway, of which Linux is a variant.