RE: RMAN backup fails - unable to open file
- From: Joel Slowik <jslowik@xxxxxxxxx>
- To: "'Taylor, Chris David'" <ChrisDavid.Taylor@xxxxxxxxxxxxxxx>, "'GiantPanda@xxxxxxx'" <GiantPanda@xxxxxxx>
- Date: Wed, 27 Jun 2012 17:17:58 +0000
Hm, Nothing in v$backup with a status of active. I did find one session in
v$session pertaining to RMAN and that was from my testing earlier yesterday.
This issue was occurring before that and when I killed the session and tried to
run a backup again the error still occurred.
I am trying to get more information about any other backup system in place from
the sys admin however as far as I am aware the only backup that I know the sys
admin runs is a tape backup at 8pm; that process does not have any locks on the
files I am working with at this point.
-joel
-----Original Message-----
From: Taylor, Chris David [mailto:ChrisDavid.Taylor@xxxxxxxxxxxxxxx]
Sent: Wednesday, June 27, 2012 8:03 AM
To: 'GiantPanda@xxxxxxx'; Joel Slowik
Cc: 'oracle-l@xxxxxxxxxxxxx'
Subject: RE: RMAN backup fails - unable to open file
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
________________________________
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: