Re: Using symbolic links for data files ??

From: Michael P. Vergara <vergara_at_nosc.mil>
Date: Tue, 20 Dec 1994 16:48:26 GMT
Message-ID: <1994Dec20.164826.15129_at_nosc.mil>


In article <1994Dec19.152251.487_at_cho006>, Chris Little <little_c_at_cho006.cho.ge.com> wrote:
>Running Oracle 7.0.16 on HP-UX 9.04
>
>By default, the oracle installer places data files in the
>$ORACLE_BASE/data/SID directory, but the Installation Guide
>implies that data files should be distributed across multiple
>devices and that the directory $ORACLE_BASE/data/SID should
>be empty.
>
>My intention is create symbolic links in this directory which
>point to data files distributed across multiple disks. This way,
>if I need to move a file, I can take the tablespace offline,
>move the file, modify the link, and bring the tablespace back
>online again, without having to ALTER TABLESPACE RENAME DATAFILE...

>
>This approach would also seem beneficial for backup and recovery
>because all symbolic links for a database are in a single directory.
>
>Has anybody out there done this, or does anybody see a problem with
>this? I would be grateful for any helpful comments and advice.
>

When I do this, I use 'setenv' environment variables, such as <host>_ORADATA_<number>, as in merlin_ORADATA_1, merlin_ORADATA_4, etc where the number is an ordinal number used for uniqueness.

These environment variables are defined system-wide, so everybody has access. To change the location of a data file, I shut down the database, move the file, redefine the setenv definition, and start the database back up.

This method has the additional feature of working in Unix, VMS, and MS-DOS environments. The method of definition varies by platform, and the method of reference varies by platform, but the general procedure works.

HTH...

--
============================================================================
Mike Vergara           |   Be good...and you will be lonesome
vergara_at_nosc.mil       |                                       Jimmy Buffett
Opinions expressed are not necessarily those of anyone else but me.  So there.
Received on Tue Dec 20 1994 - 17:48:26 CET

Original text of this message