That's what I was going to suggest. Look at v$session for any RMAN program, and check v$backup for STATUS=ACTIVE Chris Taylor "Quality is never an accident; it is always the result of intelligent effort." -- John Ruskin (English Writer 1819-1900) Any views and/or opinions expressed herein are my own and do not necessarily reflect the views of Ingram Industries, its affiliates, its subsidiaries or its employees. -----Original Message----- From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Ingrid Voigt Sent: Tuesday, June 26, 2012 4:14 PM To: jslowik@xxxxxxxxx Cc: oracle-l@xxxxxxxxxxxxx Subject: Re: RMAN backup fails - unable to open file Hi, please check for another backup process. I've seen cases where an old RMAN backup would hang, not release its file and not finish; the database session remained open (could be identified by v$session.logon_time). If this happened the next backup could not get the file. (These were archivelog backups, not datafiles.) Best regards Ingrid On 26.06.2012 22:58, Joel Slowik wrote: > Hi Paul, > Thanks. I did run process explorer: > A Process Explorer search (during and after an attempted backup or backup > verify) for the data file shows 14 handles on the file, all the handles are > the same oracle.exe PID. This was run for > 'D:\ORACLE\ORADATA\MPDEV1\USERS01.DBF' > > When I search process explorer for 'D:\ORACLE\ORADATA\MPDEV1\' I have 452 > matching items but again, all are the same oracle.exe PID. > > The only issue with the data file not accessible theory is that when I try to > run a backup validate manually, the data file is definitely there and online > as far as I can tell. > > There are no external backup tools running that takes .DBF files from that > drive. > > From: Paul Drake [mailto:bdbafh@xxxxxxxxx] > Sent: Tuesday, June 26, 2012 4:43 PM > To: Joel Slowik > Cc: oracle-l@xxxxxxxxxxxxx > Subject: Re: RMAN backup fails - unable to open file > > Joel, > > Sysinternals.com > > Process utilities. > > download the utility Process Explorer. > extract it. run it. > > examine the existing handles for the directory 'D:\ORACLE\ORADATA\MPDEV1\' > (top menu bar, select "Handle". Populate it with the file path.) > Document the offending process(es). Kill them. > > Reconfigure the offending processes OR revoke privileges used to access those > files so that anything above read/list is no longer granted. > > Document this so that they next time they change the backup software client > you can resend the same document. > > Note: this could be a lower level issue such as an iSCSI storage LUN not > being accessible but as you listed the path as "D:\oracle\oradata" that is > less likely. > > This sounds like you need to generate backup sets out to staging directories > so that the backup software client can pick up a copy of the staged backup > sets. > In any event, if you want the backup software to be able to directly > overwrite the database files during a restore, you likely have to suffer this > type of outage. > One fix is to not allow the backup software to directly access the database > files but to instead have it access staged backup sets generated via RMAN or > user scripts. > Another work-around is for the backup software client to execute a script to > shutdown the database instance prior to generating a cold full backup. > In this case another script would be executed to start the OS service to > restart the respective Oracle database instance that was closed for cold > backup. > > hth. > > Paul > > On Tue, Jun 26, 2012 at 4:16 PM, Joel > Slowik<jslowik@xxxxxxxxx<mailto:jslowik@xxxxxxxxx>> wrote: > Server: Windows 2000 service pack 4 > Oracle database version: 10.2.0.3.0 Enterprise Edition RMAN version: > 10.2.0.3.0 Database type: development When I bounce the database this > issue is resolved. But this issue continues to come back up after a day or > two. > > I would initially think this is due to a virus scanner or some other software > like that running at the same scheduled time but the issue occurs when I run > the backup manually as well. > > A Process Explorer search (during and after an attempted backup or backup > verify) for the data file shows 14 handles on the file, all the same > oracle.exe PID. Interestingly there is no actual data from any particular > schema in that data file. > > I'm not seeing any other errors anywhere else that I can think of. > > " > RMAN-00571: > =========================================================== > RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS > =============== > RMAN-00571: > =========================================================== > RMAN-03009: failure of backup command on ORA_DISK_1 channel at > 06/26/2012 15:48:04 > ORA-01114: IO error writing block to file 4 (block # 1) > ORA-01110: data file 4: 'D:\ORACLE\ORADATA\MPDEV1\USERS01.DBF' > ORA-27091: unable to queue I/O > ORA-27041: unable to open file > OSD-04002: unable to open file > O/S-Error: (OS 32) The process cannot access the file because it is being > used by another process. > > Recovery Manager complete. > " > > > Any ideas? -- //www.freelists.org/webpage/oracle-l -- //www.freelists.org/webpage/oracle-l