I am on hpux itanium 11.31...and we run a oracle DB on it. I am testing some backup and restore situation.... first i select some data from the DB.....now i remove some files from the DB where my data is being selected from.....now i select the same data from the DB but i still get my results back.... one would expect my DB would not give me the results as the datafile has been moved at OS level using RM cmd....But futher digging i found that.....the file did NOT actually get deleted.The OS maintains the file while it is held open by any/every process. All I really did was remove the inode entry from the directory file.
so my question is how can i get rid of that inode entry....so when i select the data i would actually get the error saying file is missing....
It's probably better to delete data using the DBMS than by arbitrarily deleting files you don't want the DBMS to use -- that's what the DBMS is there for.
But what's done is done. To remove a deleted file that's in use, stop using it -- i.e., restart the database.
Thanks for the info...yes i do know we can use DBMS to delete the data...but as i mentioned this is to test our restore situation...what if someone removes the files at OS level and we have to do a restored ?
In that case, rejoice -- if someone removes DB files in use, they will still exist, potentially giving you the opportunity to dump data then re-import any changes after you've restored from backup.
On the other hand, it can mean that you may not even notice when a file is deleted, until the next DB restart, when havoc results... Or strange behavior later if it turns out not all of them were open... Files that aren't present in the folder probably won't be backed up either, so hopefully it hasn't been deleted for TOO long...
You still need to restart the DBMS for the files to truly be deleted.
You could restore from backup, restart the db, then truncate the files, perhaps. That would cause way bigger problems than deleting them, since the inode table can't save you from it. Meanwhile..
You didn't plan with this feature in mind, so have started looking for ways to crash it manually -- are you sure it's not time to change your test to fit reality, instead of vice versa? Your test will become "what if I had a hardware failure", not "what if someone deleted these files".
Restarting the database is exactly what you should be doing, since that is when someone cavalierly deleting a file will cause problems, when it will be detected.
There's no way to force-delete the files that doesn't mean either forcibly unmounting a partition or killing the database process in some way, no.