Re: rman backup slow

From: Prasad <p4cldba_at_gmail.com>
Date: Fri, 30 Jan 2009 20:45:46 -0800
Message-ID: <666b99c70901302045u264e74bcx7db800dc743559a7_at_mail.gmail.com>



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-l
Received on Fri Jan 30 2009 - 22:45:46 CST

Original text of this message