Re: rman backup slow

From: Prasad <p4cldba_at_gmail.com>
Date: Sun, 1 Feb 2009 14:10:19 -0800
Message-ID: <666b99c70902011410h1f6d20e5j3815d1710cd7c98a_at_mail.gmail.com>



Mark,

I see the x$dual wait while rman does the backup archivelog delete all input as part of the db backup . Here is a output from v$sql

  1* SELECT * FROM V$SQL WHERE HASH_VALUE=4913485 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

       24562           1392        2008          0
1             0
           13         13         13               0          1
2009-01-30/21:00:57             0          13          0           0
            13            3 CHOOSE                  0               0
                0             0 00000402D5A1F648 00000402FBA79CC0    4913485
     3957808902            0
backup archivelog: ORA_DISK_1                                     1350560595
0000024 FINISHED                                                  1605141510
                  0
                                                                      10000
        4092           0 00000402FF203628          6 N VALID

                 0 2009-01-30/21:00:57 N

but I think the real culprit is disk async IO wait . because everytime I start taking the backup the statspack shows it as the top wait .

I did a level 12 trace . and here is the last 5% backup . I see there are so many sleeping for 10 sec wait .not very sure how to proceed from here :)

command backup:95.1% complete, time left 00:01:08 DBGRPC: krmxpoq: xc=4308834080, action="0000012 STARTED", col_l=15, ind=0, sid=15
DBGRPC: krmxr: callback returned TRUE, skipping sleep DBGRPC: krmxpoq: xc=4308834080, action="0000012 STARTED", col_l=15, ind=0, sid=15
DBGRPC: krmxr: sleeping for 10 seconds DBGRPC: krmxpoq: xc=4308834080, action="0000012 STARTED", col_l=15, ind=0, sid=15
DBGRPC: krmxr: sleeping for 10 seconds DBGRPC: krmxpoq: xc=4308834080, action="0000012 STARTED", col_l=15, ind=0, sid=15
DBGRPC: krmxr: sleeping for 10 seconds DBGRPC: krmxpoq: xc=4308834080, action="0000012 STARTED", col_l=15, ind=0, sid=15
DBGRPC: krmxr: sleeping for 10 seconds DBGRPC: krmxpoq: xc=4308834080, action="0000012 STARTED", col_l=15, ind=0, sid=15
DBGRPC: krmxr: sleeping for 10 seconds DBGRPC: krmxpoq: xc=4308834080, action="0000012 STARTED", col_l=15, ind=0, sid=15
DBGRPC: krmxr: sleeping for 10 seconds DBGRPC: krmxpoq: xc=4308834080, action="0000012 STARTED", col_l=15, ind=0, sid=15
DBGRPC: krmxr: sleeping for 10 seconds DBGRPC: krmxpoq: xc=4308834080, action="0000012 STARTED", col_l=15, ind=0, sid=15
DBGRPC: krmxr: sleeping for 10 seconds DBGRPC: krmxpoq: xc=4308834080, action="0000012 STARTED", col_l=15, ind=0, sid=15

DBGRPC:   krmxpod: xc=4308834080 has finished remote rpc #12
DBGRPC:   krmxr: xc=4308834080 chid=ORA_DISK_1 calling peicnt
DBGRPC:   krmxrpc: xc=4308834080 kpurpc2 rc=0 db=target
proc=DBMS_BACKUP_RESTORE.BACKUPPIECECREATE DBGRPC: krmxrpc: xc=4308834080 finishing RPC #12 to target DBGIO: Type %Comp Blocks Tot Blocks Blksize ElpTime(s) IO Rt(b/s) Name
DBGIO: ---- ----- ---------- ---------- ---------- ---------- ----------

DBGIO: IN 100.0 1048576 1048576 8192 1405 0
/rad/u4/oradata/casemt/casemt01.dbf

DBGIO: OUT 1040398 8192 1405 3009233
/rad/ora_bkup/rman/CASEMT_5213_1_6776

78395.dmp
DBGIO: AGG 1048576 8192 1405 0 channel ORA_DISK_1: finished piece 1 at 01-FEB-09 channel ORA_DISK_1: finished piece 1 at 01-FEB-09 piece handle=/rad/ora_bkup/rman/CASEMT_5213_1_677678395.dmp comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:23:35
DBGRPC:   krmxr: xc=4308834080 finished step
DBGRPC:   ENTERED krmqgns on [02/01/2009 12:23:30]
DBGRPC:    krmqgns: looking for work for channel default (krmqgns)
DBGRPC:    krmqgns: commands remaining to be executed: (krmqgns)
DBGRPC:    CMD type=backup id=1 status=STARTED
DBGRPC:              1 STEP id=1 status=FINISHED
DBGRPC:    krmqgns: no work found for channel default (krmqgns)
DBGRPC:     (krmqgns)


thanks
pk

--
http://www.freelists.org/webpage/oracle-l
Received on Sun Feb 01 2009 - 16:10:19 CST

Original text of this message