| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Accidentally Delete *.dbf Files, OH NO!!!
Has any one thought of using the sticky bit on the directory to keep =
this from happening:
$ chmod 1700 /path/to/datafiles
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Eric Buddelmeijer
Sent: Tuesday, February 01, 2005 10:30 AM
To: mfontana_at_verio.net; Oracle-L_at_freelists.org
Subject: RE: Accidentally Delete *.dbf Files, OH NO!!!
Michael,
I Like one suggestion earlier in this thread about fuser. I have been =
trying
to get our sa's to incorporate it in some sort of wrapping for rm =
(alias,
link, function or other). Precisely because fuser will tell you if a =
user,
and even which one is using a file. Problem is I can't do it myself =
because
you need root privileges to use fuser, at least on the versions of =
solaris I
have seen (2.8 and 2.9). And the sa's have not found the time to work =
around
that. But there is also a chance fuser will not tell you that the file =
is
being used because it in fact it is not. Oracle might not have each and
every file opened. And the database could be down as well.=20
Having said all that, maybe communication with your colleaques is the =
best
solution. Tell them when you put some essential files in an unlikely =
place.
So they know the files must not be deleted.
Eric.
-----Original Message-----
From: Michael Fontana [mailto:mfontana_at_verio.net]
Sent: Monday, January 31, 2005 6: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
--
http://www.freelists.org/webpage/oracle-l
This electronic message transmission is a PRIVATE communication which =
contains
information which may be confidential or privileged. The information is =
intended=20
to be for the use of the individual or entity named above. If you are =
not the=20
intended recipient, please be aware that any disclosure, copying, =
distribution=20
or use of the contents of this information is prohibited. Please notify =
the
sender of the delivery error by replying to this message, or notify us =
by
telephone (877-633-2436, ext. 0), and then delete it from your system.
--
http://www.freelists.org/webpage/oracle-l
Received on Tue Feb 01 2005 - 12:51:56 CST
 |
 |