Re: RMAN backup fails - unable to open file

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_at_gmail.com]
> Sent: Tuesday, June 26, 2012 4:43 PM
> To: Joel Slowik
> Cc: oracle-l_at_freelists.org
> 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_at_cps92.com<mailto:jslowik_at_cps92.com>> 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?

--
http://www.freelists.org/webpage/oracle-l