ASMCMD> cp /app/oracle/backup/mydb1/DF.2105.2105.784545123 +DATA/mynewdb1/datafile/DF.2105 copying /app/oracle/backup/mydb1/DF.2105.2105.784545123 -> +DATA/mynewdb1/datafile/DF.2105 ASMCMD> cd +DATA/mynewdb1/datafile/ ASMCMD> ls -al WARNING:option 'a' is deprecated for 'ls' please use 'absolutepath' Type Redund Striped Time Sys Name ... N DF.2105 => +DATA/ASM/DATAFILE/DF.2105.401.784554241 ... ASMCMD> pwd +DATA/mynewdb1/datafileAccording to Oracle this is expected behaviour.
However files transferred to ASM via the database ONNN background process set the context to which to store the files and are placed in the "correct" location. For example using RMAN connected to the target database:
RMAN> restore controlfile from '/app/oracle/backup/db1/Current.312.769340147'; Starting restore at 23-SEP-12 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=242 instance=MYNEWDB1 device type=DISK channel ORA_DISK_1: copied control file copy output file name=+DATA/mynewdb1/control01.ctl output file name=+DATA/mynewdb1/control02.ctl Finished restore at 23-SEP-12 RMAN>To copy a file without it ending up being an alias to the generic location use RMAN which will communicate with ASM via the ONNN process and place it in the appropriate location for the database.
On a semi-related note, why did Oracle consider "ls -absolutepath" was better than "ls -al"? "ls -al" had fewer keystrokes.
ASMCMD> ls -al WARNING:option 'a' is deprecated for 'ls' please use 'absolutepath'