RE: Accidentally Delete *.dbf Files, OH NO!!!

1. Normally I tell the SA they are not responsible for database = filesystems and oh by the way I will run them to 100%, which means you = do not need to monitor them or worry about them.
2. As long as you allow root access to the uninitiated you will have = problems. Maybe if they have to restore the datafiles or the database = instead of you, then they will feel the pain and not make such a = mistake. Having someone removing files as root, especially without = checking to see if the file is open, they should be fired.
3. You can try all the tricks in the world (aliases, moving the commands = to an alternate location, actually recompiling the command so that it = doesn't let things happen), but without competent and professional = people, you had better get used to restoring files, since it appears for = you that the same people that would do all those alternate things, would = know about them and work around them, thinking they are doing the right = thing.

Have fun restoring systems.

-----Original Message-----

From: oracle-l-bounce_at_freelists.org =
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Michael Fontana Sent: Monday, January 31, 2005 3:23 PM
To: Oracle-L_at_freelists.org
Subject: Accidentally Delete *.dbf Files, OH NO!!!

I have been working with Solaris for several years now. We have had a = rare but particularly debilitating problem where certain people who will = remain nameless, in an effort to "clean up" disk space, have nailed a = .dbf file or two. I know I should have the solution to this on close at = hand, but I seem to recall this was difficult, if not impossible, on = other Unix platforms (such as AIX), because the file would be "locked" = or "in use", and the nefarious "rm" command would fail. Alas, Solaris = is all too willing to comply when asked. =20

Is there something that can be done, at the OS or Oracle level, to = prevent such a thing? Needless to say, the "whackers" are using root to = enter the command, so changing permissions would accomplish little. = They are already set to only allow "oracle" write access.

Any help or even ridiculing chuckles and admonitions would be greatly = appreciated.

--

http://www.freelists.org/webpage/oracle-l
--

http://www.freelists.org/webpage/oracle-l Received on Mon Jan 31 2005 - 18:41:48 CST