Slow RMAN backup

Hi all,
I´m using Oracle 9.2.0.4 on Linux Red Hat 9 with 2GB RAM
and 2 HD SATA (160GB and 80GB).
I have a database with 19GB.
I´ve started the full backup at 2007-07-04 22:00 and the backup finished at
2007-07-05 11:00.
The configuration of RMAN is:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/oracle_5/oradata/devdb/backup/rman/control/%F';
CONFIGURE DEVICE TYPE DISK PARALLELISM 2;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 2;
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 2;
CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 1000 M RATE 2000000;
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/oracle_5/oradata/devdb/backup/rman/snapcf_devdb.f';the script used is:
replace script sunday_backup
        resync catalog;
        allocate channel c1 type disk;
        setlimit channel c1 kbytes 2097150 maxopenfiles 32 readrate 200;
        set maxcorrupt for datafile 1,2,3,4,5,6 to 0;
        backup
                   incremental level 0 cumulative
                   skip inaccessible
                   tag sunday_level_0
                   format '/oracle_5/oradata/devdb/backup/rman/db_%d.%t.%p.%c.bkp',
                          '/s/devdb/db_%d.%t.%p.%c.bkp'
                   database;
        sql 'alter system archive log current';
        backup
                   skip inaccessible
                   format '/oracle_5/oradata/devdb/backup/rman/al_%d.%t.%p.%c.bkp',
                          '/s/devdb/al_%d.%t.%p.%c.bkp'
                   archivelog all
                   delete input;
        release channel c1;
        delete noprompt obsolete;
}What can I do to increase the performance and reduce the time to perform the backup.

you can also think of adding more channels...
metalink notes
Subject: RMAN Performance Tuning Diagnostics
Doc ID: Note:311068.1
Note 237083.1 Using V$BACKUP_ASYNC_IO / V$BACKUP_SYNC_IO to Monitor RMAN Performance
Note 247611.1 "Known RMAN Performance Problems".

Similar Messages

Slow rman backup and slow database

Hello all,
Whenever I run rman backup to sbt_tape, the complete database becomes slow. Also RMAN takes more than 12 hours to complete.
RMAN script is:
run {
allocate channel t1 type 'sbt_tape' parms 'ENV=(TDPO_OPTFILE=/usr/tivoli/tsm/client/oracle/bin64/tdpo.opt)';
sql 'alter system switch logfile';
backup incremental level 2 tag 'db_level2_backup'
format'%d/INC2/%t/%s/%p'
database diskratio=0;
backup
format '%d/LOG_INC2/%t/%s/%p'
archivelog all
delete all input;
release channel t1;
}The AWR shows following "Top 5 timed events"
Event                                      Waits     Time(s)     Avg Wait(ms)     % Total Call Time     Wait Class
db file sequential read                    817,467     17,419         21                         28.6         User I/O
CPU time                                  14,294                              23.5
log file sync                            141,642     8,570         61                         14.1          Commit
enq: TX - row lock contention              3,371     7,171       2,127                          11.8         Application
log file parallel write                     149,486     5,356         36                           8.8           System I/OWhat can be done? Can anyone tell what wrong is happening here?
Database is 10.2.0.4
OS is AIX 5.3
SGA_TARGET is 6G
PGA_AGGREGATE_TARGET is 2G
Total physical RAM is 12G
EBiz application is running in the same server
Regards,
SA

On my server, we needed to adjust the vmm on aix for oracle to run best. Before I did that it was really slow.
http://www.ibm.com/developerworks/aix/library/au-aixoracle/index.html
Specifically these as outlined in the document linked above:
Listing 3. Changing the default setting for the lru_file_repage parameter using vmo
root@lpar21ml16ed_pub[] > vmo -o lru_file_repage=0
Setting lru_file_repage to 0
root@lpar21ml16ed_pub[] >
Setting this to 0 tells the VMM that you want to steal only file pages and not computational pages. As this will change if the numperm < minperm or > maxperm, we will make maxperm high and minperm very low. Years ago, before the lru_file_repage parameter was introduced, we used to make maxperm low. If we did this now, we would stop the application caching programs that are currently running.
Listing 4 shows how we'll set these parameters:
Listing 4. Setting the minperm, maxperm and maxclient parameters
vmo -p -o minperm%=5
vmo -p -o maxperm%=90
vmo -p -o maxclient%=90
We also want to take a look at minfree and maxfree. When the pages on our free list fall below minfree, the VMM will start to steal pages, which we don't want to happen until the free list has beefed up the number in maxfree. The values should be similar to the ones shown in Listing 5.
Listing 5. Setting the minfree and maxfree parameters
vmo -p -o minfree=960
vmo -p -o maxfree=1088
Edited by: user455434 on Oct 12, 2010 1:14 PM

Rman backups slowly

Hi,
We backup our oracle database to tsm server using rman through TSM. The backup takes about 3 minutes. Topas shows that the disks containing datafiles are very busy(about 90%), Readch is about 160m, top processes are lrud and aioserver. lrud process takes up about 20% cpu.
==========================================================================
System configuration: lcpu=4 mem=7680MB
kthr memory page faults cpu
r b avm fre re pi po fr sr cy in sy cs us sy id wa
1 0 1341070 323795 0 1 0 7080 30662 0 960 3947 2357 11 10 76 3
0 0 1341073 323821 0 0 0 18953 65907 0 5343 2777 5995 3 24 73 0
0 0 1341073 323756 0 0 0 19642 62385 0 5806 3876 6715 3 26 71 0
2 0 1341074 323805 0 0 0 18866 122816 0 5922 3565 7077 3 26 71 0
5 0 1341074 323745 0 0 0 17989 73069 0 5876 2864 6816 3 24 73 0
3 0 1341074 323794 0 0 0 18738 78024 0 5791 3771 6654 3 25 72 0
2 0 1341074 323769 0 0 0 17000 139139 0 5727 3447 6659 3 24 73 0
0 0 1341074 323711 0 6 0 14675 308433 0 5786 3540 6547 3 22 73 1
0 0 1341070 323803 0 0 0 14297 477320 2 6041 3509 6097 3 24 74 0
2 0 1341070 323802 0 0 0 16128 61138 0 7030 3428 6506 3 23 74 0
0 0 1341070 323770 0 0 0 16992 132824 0 6864 2668 6035 3 25 72 0
2 0 1341070 323777 0 0 0 19456 80078 0 6516 3575 5742 3 26 71 0
1 0 1341071 323736 0 0 0 19541 44201 0 6226 3417 5540 3 25 72 0
0 0 1341071 323784 0 0 0 16175 81816 0 5083 2695 4925 2 22 75 0
2 0 1341070 323847 0 0 0 14650 103203 0 3799 3640 4368 2 21 76 0
0 0 1341070 323754 0 0 0 13062 35588 0 3840 3123 4335 2 18 80 0
0 0 1341071 323711 0 0 0 14421 33350 0 5155 2555 5829 2 20 78 0
1 0 1341072 323788 0 0 0 15051 38281 0 5819 3679 6734 3 22 76 0
0 0 1341075 323824 0 0 0 15013 63271 0 5885 3318 6946 3 22 75 0
1 0 1341073 323777 0 0 0 14799 86901 0 5838 2678 6819 3 23 75 0
kthr memory page faults cpu
r b avm fre re pi po fr sr cy in sy cs us sy id wa
0 0 1341072 323804 0 0 0 15130 55187 0 5898 3643 6823 3 22 75 0
0 0 1341072 323800 0 0 0 14848 40871 0 5894 3313 6843 3 21 76 0
0 0 1341072 323854 0 0 0 15030 65990 0 5926 2659 6705 2 22 75 0
1 0 1341072 323757 0 0 0 18591 103796 0 6394 3738 6566 3 27 70 0
0 0 1341072 323777 0 0 0 17940 57273 0 6409 3091 6006 3 24 73 0
1 0 1341072 323743 0 0 0 18398 57154 0 6890 2547 6148 3 24 73 0
1 0 1341069 323649 0 0 0 17310 85715 0 6227 3423 5500 3 24 73 0
4 0 1341069 323733 0 0 0 26198 106064 0 6325 3201 5706 3 30 66 1
1 0 1341070 323532 0 0 0 30520 149981 0 5259 2604 5073 3 35 62 0
0 0 1341070 323585 0 0 0 40458 153252 0 4106 3520 4558 3 39 58 0
0 0 1341067 323501 0 0 0 43409 195787 0 3619 2991 4053 3 41 56 0
1 0 1341069 323692 0 0 0 50948 214097 0 5152 2666 5637 4 48 49 0
0 0 1341071 323689 0 0 0 51202 158777 0 5647 3733 6379 4 48 48 0
0 0 1341074 322772 0 0 0 52618 222345 0 5666 3394 6567 4 50 45 0
6 13 1341073 323746 0 0 0 45521 235212 0 14984 850 27754 2 73 3 22
0 11 1341071 323730 0 0 0 44784 828817 2 12666 1876 22631 2 69 5 24
1 7 1341072 323793 0 0 0 43535 254540 0 13997 1547 24971 2 70 3 25
2 14 1341071 323804 0 0 0 45865 219003 0 12473 908 23468 2 69 4 25
1 1 1341075 323789 0 0 0 44456 175438 0 13592 1785 24081 2 69 5 24
1 7 1341075 323736 0 0 0 45665 147529 0 15600 1550 27193 2 73 3 22
kthr memory page faults cpu
r b avm fre re pi po fr sr cy in sy cs us sy id wa
3 13 1341074 323711 0 0 0 44915 196143 0 13172 831 23717 2 68 4 25
0 4 1341074 323464 0 0 0 47081 205553 0 13477 1842 23942 2 71 4 23
3 0 1341076 322764 0 0 0 47123 153689 0 13458 1602 24078 2 70 4 24
1 7 1341075 323790 0 0 0 45925 207603 0 14407 852 25255 2 72 3 24
0 14 1341075 323851 0 0 0 43262 193764 0 14559 1521 26005 2 70 4 23
1 11 1341074 323834 0 0 0 55925 243470 0 2516 2000 9047 3 56 18 23
1 0 1341074 323772 0 0 0 56664 266906 0 2055 973 6256 2 56 17 24
1 11 1341073 322774 0 0 0 56645 264452 0 2472 1688 6809 3 56 16 25
2 7 1341072 323725 0 0 0 56679 259652 0 2488 1980 7141 3 56 15 26
1 12 1341072 323212 0 0 0 46596 795450 2 2214 891 5433 2 54 17 27
3 1 1341069 323276 0 0 0 56065 324469 0 2409 2134 6600 3 60 13 24
0 2 1341082 323823 0 0 0 56799 271413 0 2087 2121 7589 3 56 18 24
1 10 1341082 322863 0 0 0 56883 227047 0 3221 1072 9399 3 59 16 23
0 1 1341082 323167 0 0 0 53678 218700 0 1827 1738 6232 2 52 19 26
0 1 1341082 323302 0 0 0 46302 168013 0 1860 1902 6617 2 45 23 30
1 8 1341081 323842 0 3 0 49937 184776 0 2756 1043 8127 2 53 17 28
2 8 1341080 323322 0 0 0 50682 208350 0 2074 1617 7707 2 52 17 29
2 12 1341080 323716 0 0 0 50667 199451 0 2617 1950 8501 2 53 16 29
1 1 1341080 323728 0 0 0 55968 199068 0 2159 981 7801 2 54 16 27
0 4 1341082 323787 0 0 0 54052 187569 0 2850 1627 7588 2 55 15 27
kthr memory page faults cpu
r b avm fre re pi po fr sr cy in sy cs us sy id wa
1 0 1341081 323716 0 0 0 54517 236595 0 2192 1247 6628 3 55 17 25
3 10 1341082 323795 0 0 0 49300 221695 0 2453 1596 7474 2 50 19 29
0 5 1341082 322981 0 0 0 53371 263864 0 2475 1640 6981 2 54 17 26
10 4 1341082 322974 0 0 0 56363 843346 2 1937 1239 6175 2 58 16 24
0 2 1341082 323662 0 0 0 50072 222453 0 2603 1646 7008 2 52 18 27
3 1 1341078 323845 0 0 0 48705 235183 0 2110 1570 7536 2 49 20 28
0 2 1341079 323708 0 0 0 47744 173912 0 2745 1170 7571 2 50 18 30
2 0 1341080 322736 0 0 0 52503 197162 0 2926 2764 8070 3 55 14 27
1 1 1341078 322660 0 0 0 54685 220478 0 2121 1616 7116 2 55 15 27
1 1 1341077 323780 0 0 0 49784 207631 0 2464 1176 7228 2 51 17 29
1 8 1341077 323809 0 0 0 54587 227612 0 2390 1688 7061 2 56 16 25
1 1 1341076 322759 0 0 0 56282 216411 0 2473 1714 6726 3 57 16 24
6 6 1341074 323229 0 0 0 57798 206629 0 2191 1376 6850 3 57 17 24
But if we backup the database to local disks, the backup lasts only 1 minutes. Topas shows that Readch is about 30m.
=========================================================================
kthr memory page faults cpu
r b avm fre re pi po fr sr cy in sy cs us sy id wa
3 1 1346096 319044 0 0 0 15411 39566 0 550 1224 1384 1 18 61 20
0 1 1346099 318940 0 0 0 16443 106765 0 556 1673 1403 1 21 59 19
2 0 1346098 318949 0 0 0 17237 48476 0 581 555 1474 1 19 59 21
1 1 1346102 318935 0 0 0 16361 40913 0 563 1211 1468 1 18 60 20
1 1 1346102 318954 0 0 0 21171 45571 0 615 1767 1706 1 23 56 20
0 1 1346096 319031 0 0 0 19673 95635 0 527 505 1416 1 22 57 20
2 0 1346095 318992 0 0 0 22072 84596 0 574 1307 1677 1 24 55 20
1 0 1346096 318938 0 0 0 16136 41121 0 468 1654 1323 1 18 60 20
1 1 1346096 318944 0 0 0 17601 44046 0 500 563 1361 1 19 60 20
0 1 1346097 318803 0 0 0 15712 93689 0 456 1152 1291 1 19 60 20
2 1 1346099 318986 0 0 0 15661 60958 0 479 1707 1429 1 19 60 20
1 1 1346098 319030 0 0 0 16198 38227 0 482 991 1326 1 18 59 21
11 0 1346099 318924 0 0 0 15998 43314 0 515 1259 1364 1 18 61 19
3 0 1346097 319001 0 0 0 14935 40394 0 448 1619 1325 1 18 59 22
1 0 1346103 318927 0 0 0 15941 90931 0 477 521 1328 1 19 60 19
0 1 1346099 319052 0 0 0 16338 60353 0 458 1140 1259 1 19 61 20
0 1 1346099 318965 0 0 0 14640 39725 0 487 1743 1351 1 18 60 21
2 2 1346098 318925 0 0 0 15950 47318 0 472 497 1306 1 18 62 19
3 0 1346102 318932 0 0 0 14989 76385 0 475 1253 1292 1 18 61 20
2 0 1346095 318932 0 0 0 15791 86242 0 454 1645 1304 1 19 60 19
OS is AIX 5308. The version of oracle is 10.2.0.4.
Please help me.
Thanks.

Siko Lee wrote:
Topas shows the readch is about 160m when backup uses tsm, but the backup lasts for 3 minutes. However, readch is about 30m when backup to local disks, and it only last for 1 minutes. What is the extra read when backup uses tsm?CHeck this metalink note.
*Slow RMAN backup and restore using TSM [ID 1072800.1]*

RMAN backup slow

Hi,
I have a Production Database (10204) running on HP Unix (B.11.11).
Daily morning 6AM, a full RMAN backup runs. The db size is only around 225GB. But it takes 4.5 hours to complete.
The syntax which I use is given below.
RMAN> run {
     allocate channel ch1 type "sbt_tape";
     allocate channel ch2 type "sbt_tape";
     allocate channel ch3 type "sbt_tape";
send
'NB_ORA_CLIENT=jjcprd04-back.backup.ncsus.jnj.com,NB_ORA_POLICY=JJCPRD04-RMAN';
     backup
     format 'bk_%s_%p_%t'
     (database include current controlfile);
     sql 'alter system archive log current';
     backup
     format 'arch_%d_%s_%p_%t'
     (archivelog all delete input );
Is there a way to increase the speed of this backup? Currently the backup is way too slow as it takes 4.5 hours to copy 225GB of data!
Thanks!

I'll start by stating that backups directly to tape are generally quite slow.
I'd still recommend moving to disk backups though... and just archiving it to a tape...Hi Jony,
You can of course backup to disk. Thats a common solution. But you have to deal with space more than everything. In addition to that backing up to disk does not free you from moving/copying your data - depending on your backup strategy - to a long-term storage.
So you have two different and not conjunct backup operations: the rman backup itself and the job which backups the rman area to another media.
In recovery cases you might end up with RMAN requesting older backupsets which are not on disk anymore. This will most probably lead to recovery failures and manual intervention which is not desirable in recovery scenarios.
Another point is the control of the data flow. Backing up via a MML (i.e. "to tape") does not necessarily mean "to tape". Instead it means "to the backup software" which is responsible for managing the backup data. Common scenarios involve backing up the full backups via SAN directly to tape and backing up the archivelogs or incremental backups over LAN which will be stored by the backup software on a hard disk and later copied and/or moved on to tape. The data flow (to SAN / to disk / whereever) is solely controlled by the backup software.
The advantage here is one continuous backup and restore job. The backup software deals with "where is my saveset located" and requests automatically the needed tapes or disks in recovery scenarios. This makes recoveries far more flexible and comfortable.
Regarding the throughput i have set up a rather large OLTP database ( 12 TB currently) which is backed up with EMC Networker. Full backups are written via SAN directly to tape. The average speed with four LTO-3 drives is approx. 550 MB/s (the tape drives compress the data in hardware; the database itself is text-only and seems rather good compressable). I guess thats not too bad.
you can also compress the BACKUPSETS (this generates a little more CPU but less network IO)He said he is on HP-UX. These kind of CPUs tend to be not that fast. Using compression is an option worth testing but there is another point to test when doing compressed backups: The RESTORE TIME.
Ronny Egner
My Blog: http://blog.ronnyegner-consulting.de

RMAN backup using OSB too slow

Hi all,
We are exploring Oracle Secure Backup in our environment as legato networker alternative. But RMAN backup in OSB is very slow due to sbt wait event(sbtwrite2). it can backup 5GB/hour. We think this not normal behavior. we have checked network throughput between media server and client server. It can send 50 GB data by 30 min.Could you please help us to resolve the problem.
Thanks,

Hello,
What OS do you use? This is a Windows OS or UNIX ? Above all, we need more information about the Hardware and the others plans that ran in this environment.It can be also competition from other jobs.
Kind regards,
Bruno Reis

RMAN backups are slow with TSM

Hi,
I encountered a problem using RMAN with TSM to backup a database. It seems that the RMAN channel doesn't use the entire bandwidth to the TSM (or whatever) and is idle most of the time. This makes the database backup really slow.
As a comparison, we backup also filesystem and SQL Server, they both use very few channels and each channel backup about X5 more data per second than Oracle. For example, SQL Server uses 5 channels to the TSM, and we get a total of around 100MB/s. When we configure Oracle to backup using 5 channels we get about 20MB/s and we see that the SQL Server is writing to the TSM all the time while Oracle is idle a large portion of the time.
Any ideas? Known configuration issues?
I hope I'm clear about the problem.
Thanks,
Liron

Hi,
Thanks for everybody for your responses, I'll try to sum the answers here:
1. Yes, we backup the filesystem, and everything works fine. The problem is only with RMAN backups
2. Resources are not an issue, it happens on strong and weak servers (and several O/S as well)
3. Database versions are not the issue, it happens on 10.2 as well as 11.2
My feeling is that this has something to do with the integration, either oracle setting or TSM setting, but I can't be sure until I solve this.
For those of you who backup with TSM, did you notice that filesystem / SQL Servers are being backed up faster? Did you check the Oracle wait events and TSM status while you run the backup?
Thanks
BTW Girish, great comment, I wish I had all the answers... :)

RMAN-backup slow perform

I have one 10g SE database running on Linux x86_64; I have migrated this database resently with upgrade;
I used export-import utilities for perform this task;
Some information about this database:
OS version: "Linux xxx.qqq.ru 2.6.18-194.3.1.el5 #1 SMP Sun May 2 04:17:42 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux"
SQL> select * from v$version;
BANNER
Oracle Database 10g Release 10.2.0.4.0 - 64bit Production
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for Linux: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
I noticed that rman perform backup operation too long; For example here I place piece of rman log from one database backup operation:
executing script: backup_db_nfs
allocated channel: nfs
channel nfs: sid=1275 devtype=DISK
Starting backup at 31-07-10 04:00:04
channel nfs: starting full datafile backupset
channel nfs: specifying datafile(s) in backupset
input datafile fno=00028 name=/db/u12/oradata/billing/excellent_02.dbf
input datafile fno=00030 name=/db/u12/oradata/billing/excellent_04.dbf
input datafile fno=00032 name=/db/u12/oradata/billing/excellent_06.dbf
input datafile fno=00034 name=/db/u12/oradata/billing/excellent_08.dbf
input datafile fno=00029 name=/db/u11/oradata/billing/excellent_03.dbf
input datafile fno=00031 name=/db/u11/oradata/billing/excellent_05.dbf
input datafile fno=00033 name=/db/u11/oradata/billing/excellent_07.dbf
input datafile fno=00035 name=/db/u11/oradata/billing/excellent_09.dbf
channel nfs: starting piece 1 at 31-07-10 04:00:05
channel nfs: finished piece 1 at 31-07-10 04:34:21
piece handle=/db/backup/billing/rman_nfs/full_20100731.BILLING.2615.1.1 tag=BACKUP_DB_NFS comment=NONE
channel nfs: starting piece 2 at 31-07-10 04:34:21
channel nfs: finished piece 2 at 31-07-10 05:08:36
piece handle=/db/backup/billing/rman_nfs/full_20100731.BILLING.2615.2.1 tag=BACKUP_DB_NFS comment=NONE
channel nfs: starting piece 3 at 31-07-10 05:08:36
channel nfs: finished piece 3 at 31-07-10 07:38:43
piece handle=/db/backup/billing/rman_nfs/full_20100731.BILLING.2615.3.1 tag=BACKUP_DB_NFS comment=NONE
channel nfs: backup set complete, elapsed time: 03:38:38
channel nfs: throttle time: 3:###:42
channel nfs: starting full datafile backupset
channel nfs: specifying datafile(s) in backupset
input datafile fno=00036 name=/db/u12/oradata/billing/excellent_10.dbf
input datafile fno=00038 name=/db/u12/oradata/billing/excellent_12.dbf
input datafile fno=00040 name=/db/u12/oradata/billing/excellent_14.dbf
input datafile fno=00042 name=/db/u12/oradata/billing/excellent_16.dbf
input datafile fno=00037 name=/db/u11/oradata/billing/excellent_11.dbf
input datafile fno=00039 name=/db/u11/oradata/billing/excellent_13.dbf
input datafile fno=00041 name=/db/u11/oradata/billing/excellent_15.dbf
input datafile fno=00043 name=/db/u11/oradata/billing/excellent_17.dbf
channel nfs: starting piece 1 at 31-07-10 07:38:43
channel nfs: finished piece 1 at 31-07-10 08:13:18
piece handle=/db/backup/billing/rman_nfs/full_20100731.BILLING.2636.1.1 tag=BACKUP_DB_NFS comment=NONE
channel nfs: starting piece 2 at 31-07-10 08:13:18
channel nfs: finished piece 2 at 31-07-10 08:47:24
piece handle=/db/backup/billing/rman_nfs/full_20100731.BILLING.2636.2.1 tag=BACKUP_DB_NFS comment=NONE
channel nfs: starting piece 3 at 31-07-10 08:47:24
channel nfs: finished piece 3 at 31-07-10 11:17:20
piece handle=/db/backup/billing/rman_nfs/full_20100731.BILLING.2636.3.1 tag=BACKUP_DB_NFS comment=NONE
channel nfs: backup set complete, elapsed time: 03:38:37
channel nfs: throttle time: 3:###:59
channel nfs: starting full datafile backupset
channel nfs: specifying datafile(s) in backupset
input datafile fno=00044 name=/db/u12/oradata/billing/excellent_18.dbf
input datafile fno=00046 name=/db/u12/oradata/billing/excellent_20.dbf
input datafile fno=00047 name=/db/u12/oradata/billing/index_all_02.dbf
input datafile fno=00049 name=/db/u12/oradata/billing/index_all_04.dbf
input datafile fno=00045 name=/db/u11/oradata/billing/excellent_19.dbf
input datafile fno=00048 name=/db/u11/oradata/billing/index_all_03.dbf
input datafile fno=00050 name=/db/u11/oradata/billing/index_all_05.dbf
input datafile fno=00052 name=/db/u11/oradata/billing/index_all_07.dbf
channel nfs: starting piece 1 at 31-07-10 11:17:20
channel nfs: finished piece 1 at 31-07-10 12:16:46
piece handle=/db/backup/billing/rman_nfs/full_20100731.BILLING.2655.1.1 tag=BACKUP_DB_NFS comment=NONE
channel nfs: starting piece 2 at 31-07-10 12:16:46
channel nfs: finished piece 2 at 31-07-10 14:55:53
piece handle=/db/backup/billing/rman_nfs/full_20100731.BILLING.2655.2.1 tag=BACKUP_DB_NFS comment=NONE
channel nfs: backup set complete, elapsed time: 03:38:33
channel nfs: throttle time: 3:###:02
channel nfs: starting full datafile backupset
channel nfs: specifying datafile(s) in backupset
input datafile fno=00051 name=/db/u12/oradata/billing/index_all_06.dbf
input datafile fno=00053 name=/db/u12/oradata/billing/index_all_08.dbf
input datafile fno=00055 name=/db/u12/oradata/billing/index_all_10.dbf
input datafile fno=00057 name=/db/u12/oradata/billing/index_all_12.dbf
input datafile fno=00054 name=/db/u11/oradata/billing/index_all_09.dbf
input datafile fno=00056 name=/db/u11/oradata/billing/index_all_11.dbf
input datafile fno=00058 name=/db/u11/oradata/billing/index_all_13.dbf
input datafile fno=00060 name=/db/u11/oradata/billing/index_all_15.dbf
channel nfs: starting piece 1 at 31-07-10 14:55:53
channel nfs: finished piece 1 at 31-07-10 18:34:30
piece handle=/db/backup/billing/rman_nfs/full_20100731.BILLING.2674.1.1 tag=BACKUP_DB_NFS comment=NONE
channel nfs: backup set complete, elapsed time: 03:38:37
channel nfs: throttle time: 3:###:44
channel nfs: starting full datafile backupset
channel nfs: specifying datafile(s) in backupset
input datafile fno=00019 name=/db/u12/oradata/billing/excellent_big_02.dbf
input datafile fno=00021 name=/db/u12/oradata/billing/excellent_big_04.dbf
input datafile fno=00068 name=/db/u12/oradata/billing/support_excl_04.dbf
input datafile fno=00024 name=/db/u11/oradata/billing/excellent_big_07.dbf
input datafile fno=00026 name=/db/u11/oradata/billing/excellent_big_09.dbf
input datafile fno=00012 name=/db/u13/oradata/billing/pay_assist_01.dbf
input datafile fno=00004 name=/db/u13/oradata/billing/users_01.dbf
input datafile fno=00023 name=/db/u12/oradata/billing/excellent_big_06.dbf
input datafile fno=00025 name=/db/u12/oradata/billing/excellent_big_08.dbf
input datafile fno=00027 name=/db/u12/oradata/billing/excellent_big_10.dbf
channel nfs: starting piece 1 at 31-07-10 18:34:30
channel nfs: finished piece 1 at 31-07-10 21:59:27
piece handle=/db/backup/billing/rman_nfs/full_20100731.BILLING.2695.1.1 tag=BACKUP_DB_NFS comment=NONE
channel nfs: backup set complete, elapsed time: 03:24:57
channel nfs: throttle time: 3:###:13
channel nfs: starting full datafile backupset
channel nfs: specifying datafile(s) in backupset
input datafile fno=00059 name=/db/u12/oradata/billing/index_all_14.dbf
input datafile fno=00061 name=/db/u12/oradata/billing/index_all_16.dbf
input datafile fno=00063 name=/db/u12/oradata/billing/index_all_18.dbf
input datafile fno=00065 name=/db/u12/oradata/billing/index_all_20.dbf
input datafile fno=00062 name=/db/u11/oradata/billing/index_all_17.dbf
input datafile fno=00064 name=/db/u11/oradata/billing/index_all_19.dbf
input datafile fno=00015 name=/db/u12/oradata/billing/monitor_01.dbf
channel nfs: starting piece 1 at 31-07-10 21:59:27
channel nfs: finished piece 1 at 01-08-10 00:50:14
piece handle=/db/backup/billing/rman_nfs/full_20100731.BILLING.2712.1.1 tag=BACKUP_DB_NFS comment=NONE
channel nfs: backup set complete, elapsed time: 02:50:47
channel nfs: throttle time: 2:###:07
channel nfs: starting full datafile backupset
channel nfs: specifying datafile(s) in backupset
input datafile fno=00002 name=/db/u12/oradata/billing/undotbs_01.dbf
input datafile fno=00011 name=/db/u12/oradata/billing/index_all_01.dbf
input datafile fno=00009 name=/db/u12/oradata/billing/mviewlog_01.dbf
input datafile fno=00008 name=/db/u11/oradata/billing/support_excl_01.dbf
input datafile fno=00010 name=/db/u11/oradata/billing/excellent_01.dbf
input datafile fno=00067 name=/db/u11/oradata/billing/support_excl_03.dbf
input datafile fno=00007 name=/db/u11/oradata/billing/tpcctab_01.dbf
input datafile fno=00013 name=/db/u11/oradata/billing/tpchtab_01.dbf
input datafile fno=00005 name=/db/u13/oradata/billing/web_01.dbf
input datafile fno=00006 name=/db/u13/oradata/billing/alien_users_01.dbf
channel nfs: starting piece 1 at 01-08-10 00:50:14
channel nfs: finished piece 1 at 01-08-10 02:08:00
piece handle=/db/backup/billing/rman_nfs/full_20100801.BILLING.2729.1.1 tag=BACKUP_DB_NFS comment=NONE
channel nfs: starting piece 2 at 01-08-10 02:08:00
channel nfs: finished piece 2 at 01-08-10 03:40:46
piece handle=/db/backup/billing/rman_nfs/full_20100801.BILLING.2729.2.1 tag=BACKUP_DB_NFS comment=NONE
channel nfs: backup set complete, elapsed time: 02:50:32
channel nfs: throttle time: 2:###:12
channel nfs: starting full datafile backupset
channel nfs: specifying datafile(s) in backupset
input datafile fno=00016 name=/db/u12/oradata/billing/excellent_big_01.dbf
input datafile fno=00017 name=/db/u12/oradata/billing/monitor_lob_01.dbf
input datafile fno=00066 name=/db/u12/oradata/billing/support_excl_02.dbf
input datafile fno=00020 name=/db/u11/oradata/billing/excellent_big_03.dbf
input datafile fno=00022 name=/db/u11/oradata/billing/excellent_big_05.dbf
input datafile fno=00069 name=/db/u11/oradata/billing/support_excl_05.dbf
input datafile fno=00001 name=/db/u13/oradata/billing/system_01.dbf
input datafile fno=00003 name=/db/u13/oradata/billing/sysaux_01.dbf
input datafile fno=00018 name=/db/u13/oradata/billing/excl_addition_01.dbf
input datafile fno=00014 name=/db/u13/oradata/billing/arm_xml_01.dbf
channel nfs: starting piece 1 at 01-08-10 03:40:46
channel nfs: finished piece 1 at 01-08-10 06:02:03
piece handle=/db/backup/billing/rman_nfs/full_20100801.BILLING.2742.1.1 tag=BACKUP_DB_NFS comment=NONE
channel nfs: backup set complete, elapsed time: 02:21:17
channel nfs: throttle time: 2:###:51
Finished backup at 01-08-10 06:02:03
Size of this database:
SQL> select sum(user_bytes)/1024/1024/1024 from dba_data_files;
SUM(USER_BYTES)/1024/1024/1024
456.025085
I have another database that runs on the same hardware platform, eith the same configuration, and under the same OS. and oracle instance has the same configuration (except oracle version: there is 9.2.0.8);
Size of this, database is ~700Gb, and this database load is heavier that database with slow rman;
But on this database rman makes full-db backup in 10 hours, usually;
I read note 360443.1, and I checked - how long rman perform full database backup with validate option;
This time, practicaly, is equal database backup time ~24 hours;
Almost all database datafiles are splaced on disk array - stripe 10 and /db/u11 and /db/u12 - are mount points of two partitions created on this disk array;
/db/u13 - this is raid 5;
Now I wish to know in details - where time is spent and my question is: can anybody suggest me - what should I do for find it;

Instance configuration
audit_file_dest      /var/log/oracle/billing/audit
audit_sys_operations      TRUE
audit_trail      OS
background_dump_dest      /var/log/oracle/billing/bdump
compatible      10.2.0.3.0
control_files      /db/u11/oradata/billing/ctrl00.ctl, /db/u12/oradata/billing/ctrl01.ctl, /db/u00/oradata/billing/ctrl02.ctl, /db/u13/oradata/billing/ctrl03.ctl
core_dump_dest      /var/log/oracle/billing/cdump
db_block_checking      TRUE
db_block_checksum      TRUE
db_block_size      8192
db_cache_advice      ON
db_cache_size      24696061952
db_file_multiblock_read_count      64
db_keep_cache_size      3221225472
db_name      billing
db_recycle_cache_size      3221225472
db_writer_processes      4
disk_asynch_io      FALSE
dispatchers      (protocol=tcp)(listener=mts_1522)(dispatchers=2), (protocol=tcp)(listener=mts_1523)(dispatchers=2)
filesystemio_options      DIRECTIO
global_names      FALSE
java_pool_size      1342177280
job_queue_processes      10
large_pool_size      536870912
lock_sga      TRUE
log_archive_dest      /db/archive/billing
log_archive_format      %T_%S_%r.arclog
log_buffer      144326144
log_checkpoint_interval      10000
log_checkpoints_to_alert      TRUE
log_checkpoint_timeout      0
max_dispatchers      5
max_dump_file_size      100M
max_shared_servers      350
nls_date_format      DD.MM.RR
nls_language      AMERICAN
nls_numeric_characters      .,
nls_territory      RUSSIA
open_cursors      1500
open_links      17
open_links_per_instance      34
optimizer_index_caching      90
optimizer_index_cost_adj      15
optimizer_mode      RULE
pga_aggregate_target      24696061952
processes      1200
query_rewrite_enabled      TRUE
remote_login_passwordfile      EXCLUSIVE
resource_limit      TRUE
session_cached_cursors      900
sessions      1500
sga_max_size      38654705664
sga_target      38654705664
shared_pool_size      3221225472
shared_servers      150
shared_server_sessions      1000
star_transformation_enabled      FALSE
timed_statistics      TRUE
undo_management      AUTO
undo_retention      10800
undo_tablespace      UNDOTBS1
user_dump_dest      /var/log/oracle/billing/udump
workarea_size_policy      AUTO
You can see here that parameter filesystemio_options      has value DIRECTIO;
This is becouse last week I had accident on this database and, as result, I had to turn off async io for oracle;
All time before, since database mirgate moment, this parameter had value SETALL, and disk_asynch_io parameter had value true;
And rman has kept his inappropriate behaviour since this time (e.g.: since database mirgate);

RMAN backups running slow with Catalog , Running fine using control file.

I am facing a weird scenario
RMAN backups are running fine with Control file but are failing using Catalog
There are other databases configured on the same catalog and they are running fine leaves us to suspect this is issue with Database.
Can you please suggest what need to be checked in such scenario
DB: 11.2.0.2
OS: Aix 6.1
Catalog : 11.2.0.2

Hi,
Basically its not only with backups, simple list incarnation also taking a lot of timeDo sql tracing on your catalog session and target db session while running the 'list incarnation' command for your problem dbs and a normal dbs.
Regards,
Tycho

RMAN backups running slow after catalog cleanup.

Database: Oracle 10.2.0.4 on HP
I have a catalog database that is the catalog for 4 production databases on different servers. Recently I cleaned up the catalog using below statements in a script and cleaned up old records.
Crosscheck backup; crosscheck copy;
Delete force no prompt expired backupset completed before 'SYSDATE - 800';
Deleted anywhere from 5000 to 15,000 backupsets depending on the database.
A week later I am noticing that the backups are taking longer than they use to before. No significant change to the size of the databases. Was I supposed to do anything else after cleanup? or any ideas or pointers please??
Thank you!

Hi 860412,
Normallly the overhead of DML on the catalog is not the issue for slow running backups.
Can you do a test to run a backup without using the catalog and do a resync in a separate step?
Do you have something like OEM to check the performance of both the catalog and the target during the backup?
Regards,
Tycho

Rman backup is too slow

Hi
I have oracle database (11gR1) 64 bit installed on Windows 2003 R2 64 bit server. MY DB size is almost 152 GB and its running in archive log mode. When i run RMAN online backup , Its taking too much time almost it has taken 22 Hours and still its running , I am not sure why it is consuming this much time ..
I am using below RMAN script ...
run {
allocate channel ch1 type disk;
backup FILESPERSET 32
format 'F:\RMAN_BACKUP\%d_t%t_s%s_FULL' tag Full_DATABASE_07_july_13
(database)
CURRENT CONTROLFILE SPFILE;
SQL "alter system archive log current";
backup FILESPERSET 200
format 'F:\RMAN_BACKUP\ARC_%d_%s_%t'
(archivelog all);
release channel ch1;
Kindly help me and whats wrong in this please tell me . Also tell me if any other information needed ..
Thanks & Regards,
Vikash Jain

hi, Till now RMAN backup not completed for single time so i cant tell how long it takes.
I tried with parallelism 2 also but it is also not working.
CONFIGURE DEFAULT DEVICE TYPE TO disk;
# backup goes to disk
CONFIGURE DEVICE TYPE disk PARALLELISM 2;
# three channels used in parallel
CONFIGURE CONTROLFILE AUTOBACKUP ON;
#controlfile and spfile take backup automatically
CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT 'F:\RMAN_BACKUP\%d_t%t_s%s_FULL' MAXPIECESIZE 10G; # 1st channel
CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT 'F:\RMAN_BACKUP\%d_t%t_s%s_FULL' MAXPIECESIZE 10G; # 2nd channel
run {
      allocate channel chnnel1 type disk;
    allocate channel chnnel2 type disk;
backup database tag Full_DB_090713_With_CH_02;
SQL "alter system archive log current";
    backup archivelog all format 'F:\RMAN_BACKUP\ARC_%d_%s_%t';
release channel chnnel1;
release channel chnnel2;
this also having below error ..
RMAN-03009: failure of backup command on chnnel1 channel at 07/12/2013 10:38:31
ORA-19502: write error on file "D:\APP\ADMINISTRATOR\PRODUCT\11.1.0\DB_1\DATABASE\86OEH1S5_1_1", block number 1476225 (block size=8192)
ORA-27072: File I/O error
OSD-04008: WriteFile() failure, unable to write to file
O/S-Error: (OS 112) There is not enough space on the disk.
channel chnnel1 disabled, job failed on it will be run on another channel
released channel: chnnel1
released channel: chnnel2
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on chnnel2 channel at 07/12/2013 10:42:08
ORA-19502: write error on file "D:\APP\ADMINISTRATOR\PRODUCT\11.1.0\DB_1\DATABASE\87OEHG94_1_1", block number 1476097 (block size=8192)
ORA-27072: File I/O error
OSD-04008: WriteFile() failure, unable to write to file
O/S-Error: (OS 112) There is not enough space on the disk.
I checked there is enough space on F drive but still its showing the above error , Also i cant see backup pieces in "F:\RMAN_BACKUP\" location ... I am sure whats wrong with the above script ...
Thanks & Regards,
Vikash Jain

Rman backup command hangs for datafile ,works with archivelogs backup.

Issue is archivelogs backup is going fine ,But when we go for datafile backup its hanging there from oracle side as not able to give file handle.
RMAN session started with debug it gives only
DBGRPC: ENTERED krmqgns [expect.cpp/673]
16:00:40.19 DBGRPC: krmqgns: looking for work for channel default (krmqgns) [expect.cpp/673]
16:00:40.19 DBGRPC: krmqgns: commands remaining to be executed: (krmqgns) [expect.cpp/673]
16:00:40.19 DBGRPC: CMD type=backup cmdid=1 status=STARTED [expect.cpp/673]
16:00:40.19 DBGRPC: 1 STEPstepid=1 cmdid=1 status=STARTED [expect.cpp/673]
16:00:40.19 DBGRPC: krmqgns: no work found for channel default (krmqgns) [expect.cpp/673]
16:00:40.19 DBGRPC: (krmqgns) [expect.cpp/673]
16:00:40.19 DBGRPC: EXITED krmqgns with status 1 [expect.cpp/673]
16:00:40.19 DBGRPC: krmxpoq - returning rpc_number: 17 with status: STARTED16 for channel sqlbt_ch1 [expect.cpp/673]
16:00:40.19 DBGRPC: krmxr - sleeping for 10 seconds [expect.cpp/673]
Is any body seen this type of message from rman.
Thanks
Shirish

OK. Did you miss the second Oracle document?
RMAN Debug For Backup Shows "krmxr: sleeping for x seconds" [ID 458259.1]
Also a ton of information here :
RMAN backup database as copy from file system to ASM diskgroup very slow
and here :
RMAN Error > Please assist!
and here :
RMAN and Amazon Web Services
http://oravdba.blogspot.com/2011_01_01_archive.html
Best Regards
mseberg

Alter system flushed shared pool in RMAN backup

Hi,
I am trying to take RMAN backup of 11.2.0.1 Database in IBM AIX 6.1 server.
The RMAN is hanging .
Though the backup gets completed, The channels allocated doesnt get released and the RMAN gets hanging.
In earlier RMAN backup Scripts,
the DBA was using alter system flush shared pool in RMAN backup script and the backup was getting succesful.
Now my question is , is using ALTER SYSTEM FLUSH SHARED POOL have any performance impact on the database.
Regards,
TEJAS

TEJAS_DBA wrote:
Hi,
I am trying to take RMAN backup of 11.2.0.1 Database in IBM AIX 6.1 server.
The RMAN is hanging .
Though the backup gets completed, The channels allocated doesnt get released and the RMAN gets hanging.Are you setting the large pool? If you don't, then rman uses the shared pool. Read about tuning rman performance in the docs.
>
In earlier RMAN backup Scripts,
the DBA was using alter system flush shared pool in RMAN backup script and the backup was getting succesful.
Now my question is , is using ALTER SYSTEM FLUSH SHARED POOL have any performance impact on the database.Yes, you are allowing the components in there to be loaded in the random order of whatever is called first. This may have a good impact if you had some fragmentation in there, or it could be mildly bad if everything was well sorted, or it could be very bad if you are unlucky or have some pattern of invalidations or should be pinning something or who-knows-what. It generally is considered not a good thing to do as a habit. You wind up with [url http://tkyte.blogspot.com/2012/05/another-debugging-story.html]rainy Monday scenarios.
Edit: I notice there are some bugs, including very slow performance when using a catalog. When you say hang, how long are you waiting? Have you considered current patches?
Edited by: jgarry on Aug 8, 2012 11:09 AM

GZIP RMAN BACKUP

Dear All
We are running Oracle 10g(10.2.0.4) on Solaris 10
I want to gzip up my rman backups, which are to disk.
How do I add the command to my script so after end of backup it starts gzipping it.
Please find the script below
export ORACLE_BASE=/app/oradataerp/oraprod
export ORACLE_HOME=/app/oradataerp/oraprod/db/tech_st/10.2.0
export ORACLE_SID=PROD
export LD_LIBRARY_PATH=${ORACLE_HOME}/lib
export PATH=${ORACLE_HOME}/bin:${ORACLE_HOME}/lib:${PATH}
export DATE=`/usr/bin/date +%Y%m%d`
rman target sys/***** nocatalog msglog /nfs-bkp-erp/PROD-ERP/PROD-DB/RMAN.${DATE}.log <<EOF
crosscheck archivelog all;
#backup database format '/nfs-bkp-erp/PROD-ERP/PROD-DB/PROD_t%t_s%s_p%p%c';
#backup current controlfile format '/nfs-bkp-erp/PROD-ERP/PROD-DB/PROD_cntrl_t%t_s%s_p%p%c';
#delete noprompt archivelog All complEted before 'SYSDATE-10';
crosscheck backup;
#delete expired archivelog all;
delete obsolete;
crosscheck backup;
EXIT
EOF;
Regards
Musaddaq

When using compression, you will need to actually test to see which backup compression gives you the best compression/performance. Higher compression = slower performance, Lower compression ratio = more performance.
To make your life a lot easier when trying to do backups, make sure you do rman backup to disk, then sweep these backups to tape. The restore would then be much faster.

Rman Backup of External Disk

Hi
We have an 3 Oracle 11.1 database on 3 different servers with Windows 2003.
We have a high speed USB External hard drive of Disk space about 2 TB .
I wanted to know is it a good idea to take a Rman backup every night on this external drive from all the three databases by sharing this drive .
Later this backs are manually copied to tapes.
Thanks

Hi,
You can take the backup but it will be very slow ( not like local harddisk)
You will see the significate wait event RMAN backup & I/O in AWR report.
You need crosscheck or validate the backup once its written to harddisk and again that may take more time
what i suggest is try it and if you are facing any problem , then don't continue.
Kind Regards,
Rakesh jayappa
Edited by: Rakesh jayappa on Sep 15, 2010 11:20 PM

Rman backup to disk 2 Minutes; Backup to tape hours

Solaris 10
Oracle 10gR2
MML Netbackup 6.0
I have the following scenario
Rman backup to disk < 2 Minutes; Backup to tape takes hours
and occassionaly fails with a media manager layer error.
Any suggestions to speed up the backup to tape?

A backup of under 2 minutes . . . not very big.
A backup to tape of hours?
I don't think that is your problem . . . I think you need to check and see if your tapes are valid. If Oracle fails at the end of a backup to tape, it sounds like the tapes are 'bad'.
If the tapes are good: Then look at why it is so slow - I would 'guess' network backup.
Can you backup to disk and then send them to tape?
Solaris 10
Oracle 10gR2
MML Netbackup 6.0
I have the following scenario
Rman backup to disk < 2 Minutes; Backup to tape takes
hours
and occassionaly fails with a media manager layer
error.
Any suggestions to speed up the backup to tape?

Slow RMAN backup

Similar Messages

Maybe you are looking for