Hello,

When we upgraded our database from 11.2.0.1 to 11.2.0.2, we have
discoverd that Oracle is not honoring symbolic links--the symbolic
links get overwritten directly when there is a media failure,
datafiles missing or deleted.

In our environment, we use symbolic links under /oracle/data/SID/dbf
to point to /packages/data/dbf ....

Have you encountered this problem and found a simple workaround? We
are opening a case with Oracle.

thanks,

Joseph

On Nov 4, 4:05*pm, Joseph210 <lee... (AT) gmail (DOT) com> wrote:
Can you give a more complete example including specifics and error
messages encountered etc?

I am using symbolic links in my environment with 11.2.0.3.0 ( 64 bit
linux on OL 5.7 ) and not seeing any problems with rman restore
processing etc.

I use symbolic links to point to my asm disks ( things like /storage/
test_dg1/disk1 ==> /dev/emcpowerax ) and results are just peachy so
far for me.

Joseph:

I guess I forgot to say on my original reply that my testing of rman
recoveries including some symbolic links to ASM disks also has worked
just fine under 11.2.0.2.x before moving up to 11.2.0.3.0 ...

More details please.

On Nov 6, 4:40*pm, John Hurley <hurleyjo... (AT) yahoo (DOT) com> wrote:
We are hp-ux itanium 11.31 OS with Oracle 11.2.0.2. My college tested
this on linux/aix boxes as well.

we are not using ASM disks, just file system.
I have tested some basic senarios when Oracle honors symbolic links or
not:
as long as there are existing oracle datafiles in destination dir, it
does honor symbolic links (you can copy almost any Oracle datafile to
all the other datafiles).
But if we deleted the datafiles in destination dir, rman cannot
restore them with ORA-01116: error in opening database file 1
ORA-01110: data file 1: '/oracle/data/jl11g202/jl11g202/system01.dbf'
ORA-27041: unable to open file
HPUX-ia64 Error: 2: No such file or directory.

When we touch the destination file with 0 bytes, rman restores but
overwrite the symbolic link itself instead of following/honorning the
symbolic link (this is only 11.2.0.2 behavior -- when you create a
datafile, it did not honor symbolic link, either. Oracle provided a
fix, so it is ok now; but rman restore have this issue still).

So my workaround is to copy any Oracle datafile to the missing one(s),
then rman restore honors the symbolic links (except controlfile -- its
symbolic links are overwritten).

Thanks for sharing your info -- it is good to know this seems to be
resoved with 11.2.0.3 (?) or ASM environment.

Joseph

Joseph:

## More details please.

# We are hp-ux itanium 11.31 OS with Oracle 11.2.0.2. My college
tested this on linux/aix boxes as well. we are not using ASM disks,
just file system. I have tested some basic senarios when Oracle
honors symbolic links or not:

So if you are using a real cooked file system what is the reason for
symbolic links to your datafiles/controlfiles etc?

In my environment we use EMC storage and I want to provide a level of
separation between the disks that ASM thinks it is using and the emc
provided storage. It gets to be a long story but using emc power path
you end up with some "weird" dev ( device ) names like /dev/
emcpowerxx . Besides that at points you may want to have snapshots
and/or clones etc that you might bring up as the database.

I setup my environment so that I can switch things around easily ...
we use /storage/asm_diskgroupname/disk# as a symbolic link into the
real emc device names. When I point asm over to a disk I tell it the
disk is ( for example ) /storage/dev_dg1/disk3 ... and have that disk3
be the symbolic link over to a real emc device name/disk.

Why exactly are you trying to use symbolic links in your environment?

HPUX is always a little dicey these days in Oracle maintenance and
bugs and stuff. Used to be rock solid but those days seem kind of
distant now.

If you have a reproducible test case with symbolic links on both HPUX
and linux I would get that volleyed over to Oracle support as an SR.
Even just a reproducible test case on HPUX I would get that opened up.

Yes I am sure that there are quite a bit of fixes in 11.2.0.3 ( versus
11.2.0.2.? ) ... but not sure how many of them might be relevant to
what you think you are running into.