Re: rman backup slow
Date: Sat, 31 Jan 2009 16:42:59 -0800 (PST)
Message-ID: <103462.57569.qm_at_web38908.mail.mud.yahoo.com>
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_at_gmail.com>
To: ORACLE-L <oracle-l_at_freelists.org> 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_at_gmail.com> 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
-- http://www.freelists.org/webpage/oracle-lReceived on Sat Jan 31 2009 - 18:42:59 CST