On Thu, 21 Oct 2004 11:53:01 +1000, "Howard J. Rogers"
<hjr_at_dizwell.com> wrote:
>BlindEagle_at_HotMail.com wrote:
>
>> just a personal pref... I would not use a symbolic link. Easy enough to
>> modifty the pfile.
>
>Not for dynamically altering the destination of archives on a 24x7 system
>it's not!
>
>I don't know enough about Unix best practice to work out whether Ed's
>suggestion is evil or saintly. But it seems to me to give some managerial
>capabilities that ye olde spfile/pfile technology lacks, and that's not a
>bad thing.
>
>Again, I don't know what happens in Unix if you modify the link whilst it's
>in use (I wonder if it's a bit like what happens when you delete the
>control files from a currently-running instance.... and the database keeps
>on chugging away perfectly normally).
>
>If there is any suspicion that modifying that link could somehow 'divert' an
>archive mid-stream (ie, corrupt it), then Ed should stick with your advice
>if he cares about his data, no doubt about it.
>
>Regards
>HJR
My understanding of how unix would handle this is pretty limited. I
do know that files are defined not only by their name but by a unique
id called an 'inode.' My understanding is that the file inode is
fixed and unchangeable. That is, even if you rename a file, it's
inode remains the same. I do know that I've seen apps (I believe the
Oracle listener, in writing to its log, is one) that, once they've
begun writing to a file continue to write to that file even if you
rename it in flight. My guess has been that once it had the file
open, it was holding its inode and cared not about its name. So,
would the archivelog process work this way? And does the introduction
of a symbolic link into the equation have any impact? I don't know,
but would be willing to bet a beer (but not much more!) that it does.
Given how fast the typical archivelog gets written (at least in my
limited experience) it would probably be next to impossible to conduct
a controlled test.
Received on Thu Oct 21 2004 - 07:29:31 CDT
