RE: RMAN backup fails - unable to open file

  • From: Joel Slowik <jslowik@xxxxxxxxx>
  • To: 'Paul Drake' <bdbafh@xxxxxxxxx>
  • Date: Tue, 26 Jun 2012 20:58:20 +0000

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?
________________________________
Confidentiality Note: This electronic message transmission is intended only for 
the person or entity to which it is addressed and may contain information that 
is privileged, confidential or otherwise protected from disclosure. If you have 
received this transmission, but are not the intended recipient, you are hereby 
notified that any disclosure, copying, distribution or use of the contents of 
this information is strictly prohibited. If you have received this e-mail in 
error, please contact Continuum Performance Systems at 
{203.245.5000<tel:203.245.5000>} and delete and destroy the original message 
and all copies.

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




--
http://www.completestreets.org/faq.html
http://safety.fhwa.dot.gov/ped_bike/docs/pamanual.pdf
________________________________
Confidentiality Note: This electronic message transmission is intended only for 
the person or entity to which it is addressed and may contain information that 
is privileged, confidential or otherwise protected from disclosure. If you have 
received this transmission, but are not the intended recipient, you are hereby 
notified that any disclosure, copying, distribution or use of the contents of 
this information is strictly prohibited. If you have received this e-mail in 
error, please contact Continuum Performance Systems at {203.245.5000} and 
delete and destroy the original message and all copies.

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


Other related posts: