(by the way, the answer seems to be dbms_file_transfer, so google up) Alan.- On Fri, Jun 3, 2011 at 11:43 AM, Guillermo Alan Bort <cicciuxdba@xxxxxxxxx>wrote: > I think your problem is you need to take the archivelogs out of ASM, the > naming issue can be resolved simply enough by mv afterwards (or not). Now, I > know you can move datafiles and controlfiles easily enough out of ASM > without using RMAN. I'm not so sure about archivelogs. > > Check out the discussion in this same list about this: > //www.freelists.org/post/oracle-l/ASM-is-single-point-of-failure > > Cheers > Alan.- > > > > On Fri, Jun 3, 2011 at 10:36 AM, Martin Bach < > development@xxxxxxxxxxxxxxxxx> wrote: > >> Hi all, >> >> >> >> A bit of a funny question which has been raised today. Oracle 11.2.0.2.2 >> RAC with ASM on Linux. >> >> >> >> Let’s assume for a moment that you have a production cluster with a disk >> group +ARCH used as the FRA. The archived redo logs follow the naming >> convention shown here: >> >> >> >> thread_*threadNumber*_seq_*sequenceNumber*.*fileID.incarnation* >> >> >> >> An example is thread_1_seq_94.348.752827039 >> >> >> >> Thread and sequence number are self explanatory. The rest of the file name >> is composed of the file_number and file_incarnation as shown in v$asm_file, >> i.e. you could find this file in asm by querying >> >> >> >> SQL> select * from v$asm_file where file_number = 348 and incarnation = >> 752827039; >> >> >> >> So far so good. Now what I need to do is copy these files from the >> production cluster to another cluster and apply them to a clone of the >> production database to roll it forward. >> >> >> >> The question really is: do you know of a simple enough way to transform >> the files from their FRA naming convention into the %t_%s_%r.dbf format? >> RMAN cannot be used unfortunately, and it’s too long a story to tell here. >> >> >> >> Ideally I’ll run a shellscript which transforms >> thread_1_seq_94.348.752827039 into 1_94_12345623432.dbf >> >> >> >> Thanks in advance for any pointers! >> >> >> >> Martin >> > >