Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: datafile permissions

RE: datafile permissions

From: <>
Date: Wed, 6 Jul 2005 09:55:42 -0700
Message-ID: <65C0D8935651CB4D96E97CEFAC5A12B94447B7@wafedixm10.corp.weyer.pri>

Right, absolutely nothing happens once the process has an open file descriptor!!

-----Original Message-----
From: Reidy, Ron [] Sent: Wednesday, July 06, 2005 4:47 AM
To:; Khemmanivanh, Somckit;; Subject: RE: datafile permissions

So, to test it out, change the C program to perform more writes. Run it in the debugger and during the writes, chmod 000. What happens?

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

From: on behalf of Sinardy
Sent:	Tue 7/5/2005 11:45 PM
To:	Khemmanivanh, Somckit;;
Subject: Re: datafile permissions
Your test is good, just if you "accidentally" chmod 000 *.dbf during online and batch job is still running what will happen to the db? This is what I believe his manager try to prevent. Anyway technically you are right.

  Not to harp on this too much but I'm really failing to see how this is such a risky task? He's going from mode 600 to 640.

  You can run this test yourself to see that there shouldn't be any issues with doing this.

  1. create a test file rm skf touch skf chmod 600 skf ll skf
    -rw------- 0 Jul 5 22:16 skf
  2. As a control run the supplied C program I whipped up to test. All it does is open the file and write a bunch text to it

  It will create a file exactly 99999999 bytes in size

  ll skf
-rw------- 99999999 Jul 5 22:17 skf

  Below is the code (compile and run it)

  #include <stdio.h>
  int main ()
    FILE * myf;
    int counter = 0;

    myf = fopen ("skf","wt");
    if (myf != NULL)

       while ( counter < 99999999)
        fputs ("t", myf);


  3) Delete the skf file and recreate it with mode 600 for the run with the chmod in it.
--Run the program in 1 session and in another session run the
following commands.

  ll skf; chmod 640 skf; ll skf
-rw------- 6062080 Jul 5 22:18 skf
  ^^^--Note the mode is 600 from the first ll skf commnd

-rw-r----- 6193152 Jul 5 22:18 skf
  ^^^--Note the mode has changed to 640 with the chmod comand (this while the other program is still writing to the file)

  4) Now recheck the file after it's all complete.   ll skf
-rw-r----- 99999999 Jul 5 22:19 skf

  Does anyone see any flaws with this test???   Thanks!

[] On Behalf Of Sinardy   Sent: Tuesday, July 05, 2005 9:31 PM
  To:;   Subject: Re: datafile permissions

  If someone is writing to the file then you revoke the access using OS command which is it can be done with Unix I believe your manager forsee this will corrupt the datafile.

  Anyway, if I am asked to perform such harderning change, I will request for down time. For may be 1 hour, stop applications, shutdown, chmod, startup, switch log file, test, star application. not only datafile offline.

  PS: I know that 640 should be ok but chmod during online is quite a risky task.


    Hi All,

    Sun OS 2.9
    oracle 9i

    In what state the datafiles should be when i want to change the OS file permissions

    from 600 to 640

    chmod 640 *.dbf

    I put the tablespace offline. is that enough?, or should i make the datafiles offline withi

    alter database datafile 'filename' offline;

    I had a fight with my manager. He asked me to put the datafiles offline using alter database.

    But Just i put the tablespace offline and did that. Just want to make sure what is

    the right way (precautiion to be taken) for this task ?

    Thanks in advance,

    Do You Yahoo!?
    Tired of spam? Yahoo! Mail has the best spam protection around

This electronic message transmission is a PRIVATE communication which contains
information which may be confidential or privileged. The information is intended
to be for the use of the individual or entity named above. If you are not the
intended recipient, please be aware that any disclosure, copying, distribution
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.

Received on Wed Jul 06 2005 - 11:59:31 CDT

Original text of this message