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

  • From: "Parker, Matthew" <matthewp@xxxxxxxxxx>
  • To: <mfontana@xxxxxxxxx>, <Oracle-L@xxxxxxxxxxxxx>
  • Date: Mon, 31 Jan 2005 15:38:36 -0800

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 =

Have fun restoring systems.

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx =
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Michael Fontana
Sent: Monday, January 31, 2005 3:23 PM
To: Oracle-L@xxxxxxxxxxxxx
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 =


Other related posts: