This site is currently read-only as we are migrating to Oracle Forums for an improved community experience. You will not be able to initiate activity until January 30th, when you will be able to use this site as normal.

    Forum Stats

  • 3,889,805 Users
  • 2,269,775 Discussions
  • 7,916,823 Comments

Discussions

Make database files on file system undeletable

User51642 Yong Huang
User51642 Yong Huang Houston, TXMember Posts: 183 Bronze Badge
edited Oct 25, 2018 12:49PM in Database Ideas - Ideas

This may be more of an idea for Linux (such as Oracle Linux) than for Oracle database. For those using a file system to store database files (datafiles, redo logfiles, control files), there's always a risk of accidentally deleting them. (Any IT professional with a few years in career have heard of such stories!) Some Linux file systems allow the chattr command to change a file to immutable so the file cannot be deleted or updated. But for Oracle database files, the ideal is to make them undeletable but in-place updatable.

[Update 2018-10]

The manpage for chattr has this statement, "When a file with the 'u' attribute set is deleted, its contents are saved. This allows the user to ask for its undeletion. Note: please make sure to read the bugs and limitations section at the end of this document." This 'u' attribute sounds like a misnomer; it may as well be called "recoverable after deletion", not "undeletable". Anyway, a test on ext* and xfs file systems shows that this attribute has not been implemented. (Fairly new source code of chattr is on github and can be easily compiled.)

On the other hand, the whole idea can simply be implemented from a different angle. Instead of marking a file undeletable, which relies on the support of the underlying file system, we can just modify the rm command. And we don't even need to change the code of rm. Just creating a shell wrapper is enough. Many shops alias rm to 'rm -i' so the user gets a confirmation prompt. But this offers little help due to human nature. (When you're prompted every time, you tend to ignore the prompt altogether.) The correct way is to let all team members know the critical files should be named with a string pattern which is recognized by the wrapper of rm. For example, the wrapper should refuse to delete or at least throw an alert when the file ends with .dbf, or embed "critical" as part of the name of each datafile or redo logfile or any critical file and add the logic to the rm wrapper. Since you rarely try to delete such a file by mistake, the alert of the rm wrapper does serve the purpose. This is a low-tech but feasible solution.

Emad Al-MousaRami_robotAndreas HuberJairo SuarezUser51642 Yong HuangPeter_L_
9 votes

Active · Last Updated