It IS a standard practice [but not mandatory] to use soft-links to give meaningful
file-names to raw devices in an OPS/RAC database.

Why do you think that the link would break "for some reason" ? A link to an
NFS-mounted file can break if the NFS-mount fails but surely not a link to a local
device. It would only break if someone or some job/script on the server modified
or removed it -- but then you run the same risk even with regular file system
database files. [e.g. redo-log files which are created as "redo01.log" and a
CRON job or an new SA decides to issue the "rm *.log" command].

If you have a link to a device, I would think that writing to the link would write
to the device. The underlying device is still a "character-device" for the raw
datafile.

Hemant

At 09:34 AM 07-02-03 -0800, you wrote:
Resending. Any takers?

----- Forwarded by Rajesh Rao/JPMCHASE on 02/07/03 11:51 AM -----




Rajesh
Rao/JPMCHASE@ To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
CHASE cc:
Sent by: Subject: Using Soft Links for Datafiles
root@fatcity.
com




February 06,
2003 04:23 PM
Please
respond to
ORACLE-L








We are in the process of creating a 9.2 RAC database. And we are being
forced to follow a standard whereby, all files are to be in a directory
structure, say /local. No standards have yet been defined, if one were
using raw volumes. And since we will be using raw volumes for the
datafiles, to enforce the standards, we are being asked to create symbolic
links from /local datafiles to the raw volumes. To convince them otherwise,
I have seemed to dug up two issues.

1. For some reason, if the link breaks or is removed while the databases
are up and running, its akin to taking a datafile offline, which would
neccesitate a recovery.
2. While doing a restore, RMAN would restore the files to the link
directory and not to the actual raw volume.

Does this hold water? Anyone has other ideas or gotchas with using symbolic
links for datafiles? Or Am I just being paranoid?

"I commonly use links for raw datafiles. Doing so aids the adoption of
meaningful naming conventions" - Steve Adams

Thanks
Raj




--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author:
INET: [EMAIL PROTECTED]

Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).




--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author:
INET: [EMAIL PROTECTED]

Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
Hemant K Chitale
My web site page is :  http://hkchital.tripod.com


--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Hemant K Chitale
 INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

Reply via email to