Re: rman backup slow
- From: Robert Freeman <robertgfreeman@xxxxxxxxx>
- To: p4cldba@xxxxxxxxx, ORACLE-L <oracle-l@xxxxxxxxxxxxx>
- Date: Sat, 31 Jan 2009 16:42:59 -0800 (PST)
Do a backup without the catalog. Does it go faster? You can start by just
testing the backup of a specific datafile with and without the catalog, rather
than the whole database. I'd do one that is big enough to give you a decent
backup run time.
Has this database gotten bigger over time or is it's size static? Is the
increased run time of the backup related to any increase in database size?
Are you just backing up to one disk device? Are you using one channel or
multiple channels? What is the disk IO rate for writes in ms? Are you getting
the throughput you need on your disks.
I would not change the parameters you are talking about just yet. It would be
much smarter to figure out for sure what is causing your problem before you
change lots of parameters and potentially make the problem even worse.
I assume that your system does ASYNC IO? Correct? I would not go the SYNC IO
path as you are suggesting by setting disk_asynch_io to false.
RF
Robert G. Freeman
Author:
OCP: Oracle Database 11g Administrator Certified Professional Study Guide
(Sybex)
Oracle Database 11g New Features (Oracle Press)
Portable DBA: Oracle (Oracle Press)
Oracle Database 10g New Features (Oracle Press)
Oracle9i RMAN Backup and Recovery (Oracle Press)
Oracle9i New Features (Oracle Press)
Other various titles out of print now...
Blog: http://robertgfreeman.blogspot.com
The LDS Church is looking for DBA's. You do have to be a Church member in
good standing. A lot of kind people write me, concerned I may be breaking
the law by saying you have to be a Church member. It's legal I promise! :-)
________________________________
From: Prasad <p4cldba@xxxxxxxxx>
To: ORACLE-L <oracle-l@xxxxxxxxxxxxx>
Sent: Friday, January 30, 2009 9:45:46 PM
Subject: Re: rman backup slow
my apologies for the late response. To answer this . not it is not a new
database . it has been in production since last couple of years. it hosts a
application which has lot of LONG RAW data . it is right now 170GB . out of
which the LONG RAW table only occupies 80GB. The RMAN backup is taken
connected to recover catalog . The backup goes to disk . right now the
cursor_sharing is set to similar . The most significant wait I see is disk
async i/o . This is a solaris server with vxfs and it do not support async i/o
.
The puzzling factor is the select on x$dual which just sits silently for hours.
and the entire backup duration goes beyond 10 hour .
This is what we are planning to do increase the db_writer_process from 1 to 4
and set the disk_asynch_io to false ( i gues the default is TRUE) . would
appreciate your thoughts on this change .
because of the sensitivity of the application ( it is a highly visible
production database) it is a bit hard to find time to take a no catalog
backup and also do any tracing experiment . but i guess it seems unavoidable
.
hopefully I didnt miss to provide any information asked. please feel free to
let me know if any further information will assist finding solution.
Thanks again .
thanks
Prasad
On Jan 30, 2009, at 1:10, Prasad <p4cldba@xxxxxxxxx> wrote:
All,
we have a 170G db on 9.2.0.7(solaris 9) . and I see that it currently is
taking nearly 10 hour+ to do a rman backup . when I see this in grid control I
see the rman session keeps waiting on this sql .
SELECT
TO_CHAR(SYSDATE,:"SYS_B_0",:"SYS_B_1"),TO_CHAR(SYSDATE,:"SYS_B_2",:"SYS_B_3"),
TO_CHAR(SYSDATE,:"SYS_B_4",:"SYS_B_5") FROM X$DUAL
anyone has any similar situation . appreciate any suggestion.
Thanks in advance
thanks
Prasad
Other related posts:
