In this case you can also follow the first option also without any problem i.e the option to move the archive logs to some other location say forexample /tmp. Now before starting the recovery first SET LOGSOURCE "/tmp" and issue the recovery command ( Recover automatic tablepsace users) using sqlplus . OR You can also mention the archivelog path in recovery command using sqlplus . For example below is for tablepspace level recovery Recover automatic tablespace users from "/tmp" On Fri, May 16, 2014 at 3:43 AM, Ingrid Voigt <GiantPanda@xxxxxxx> wrote: > Thanks everybody who replied. > > Restore and recovery were successfully finished an hour ago. > > Best regards > Ingrid > > > > -------- Original Message -------- > Subject: Urgent - change log_archive_dest_1 during recovery? > Date: Thu, 15 May 2014 11:21:01 +0200 > From: Ingrid Voigt <giantpanda@xxxxxxx> > Reply-To: giantpanda@xxxxxxx > To: oracle-l@xxxxxxxxxxxxx <oracle-l@xxxxxxxxxxxxx> > > > Hi, > > (this is a current production recovery and not a test). > > We are doing RMAN PITR for a database with more than 7000 archivelogs to be > recovered. (Restore was successful, recovery is currently running). > > log_archive_dest_1 is probably not big enough to take all these > archivelogs at the > same time. We have come up with two options to prevent it from filling up: > > 1) Change the archivelog destination to another disk during recovery > - will this even work? > 2) Move / delete archivelogs that have already been recovered > (v$recovery_progress has this info). - Will this do anything bad other than > possibly confusing the next backup? > > Are there other options? > > We have about three hours to make a decision, so I'd very much appreciate > your quick feedback... > > > > > > > > > > > > -- > //www.freelists.org/webpage/oracle-l > > > -- *--* *BR* *Sumit Tyagi* *+91-7829543355*