AIX

Perhaps it would have been useful to know this. I now suggest you look at network settings. If there is a mismatch between the speeds of the switch port and the NIC then you might hit trouble, of if there is an extra step across the network (even a change of subnet on the same physical switch) that can slow bulk data transfer down too.

There are more things to consider now. I too would not expect it to read any indices for a backup done. I think it should read the object definitions and the full tables.

Can you explain more about your network between the LPARs, the device managing the backup and the recipient that gets the data?

If these are not run concurrently, is there anything else with a very high data volume being transferred over the network around the same time?



Robin

Oooo. RMAN.

ugh.
[story]
There is a sort of scripting language that is used to set up parameters for an RMAN backup. If you set "threads" to a high value (usually more than 4) you can get I/O saturation on most types of I/O devices, as well as signficant cpu usage.

Our DBA set threads to 20 on our one huge customer db. Incremental backups at 0400 completely ate the server and squashed all of our DB batch jobs for about two hours every night. On Saturday morning when full backups ran, all 16 cpus were nearly maxed out, nobody could work on the system until the backup was over - like 6 hours later. A refresh of the TEST db took 40+ hours. In this case the TEST server was hammered into oblivion.

It took several months to get the DBA to decide RMAN tuning was indeed the problem.
One change and all the system issues went away.
[/story]

I would strongly suggest that if your DBA does not know RMAN to open a support ticket with Oracle and get competent help.

I suspected network issues between LPAR2 db server and net-backup server, but the full backup of LPAR2 which runs on the weekend completes in the same time as LPAR1. This specific performance issue is only noticed for RMAN incremental backup. I also verified, it's the same RMAN script runs on LPAR1 & LPAR2, and the RMAN logs are having same contents on both sides. Pasting below the topas output taken while the incremental backup running.

Thanks

---------- Post updated at 10:13 AM ---------- Previous update was at 10:07 AM ----------

Apologize, format issues, pasting down again.

Code:

CPU                   LPAR1      LPAR2
user%                  12.7        6.4
kern%                  11.2        6
wait%                    1.1       3.8
idle%                    75         83.9
Physc                   2.91       1.34
Entc%                 36.43      16.73
  
Network           LPAR1          LPAR2
BPS                 30.7M          6.41M
I-Pkts               2.43k          825.2
O-pkts              21.8k          4.62K
B-in                  395k           116K
B-out              30.3M           6.30M
  
Disk           LPAR1             LPAR2
Busy%            8                10.7
BPS               3.14G           944M
TPS               6.79K           2.39K
B-Read           3.14G           942M
B-write           1.14M          2.32M
  
FileSystem   LPAR1          LPAR2
BPS             784M           250M
TPS             2.24K           2.13K
B-Read        784M            250M
B-write        428K             269K

Too bad you ignore constantly to use/try out nmon - it would be a help for you or others/anybody else in the future too.
Anyway, there are big differences in the BPS disk and FS paragraphs about up to 2-3 times between LPAR 1 and 2. Maybe have a test with dd or something else going somewhat direct to the storage (SAN?) to check if has the same performance for both LPARs.
Also check back with the storage/SAN guys, if they can see if there is more traffic on the port for LPAR 2 than LPAR 1, throttling it's IO.

Your output does not show anything about current memory situation including paging space. That would also be visible in a nmon output.
I remember that especially RMAN used lots of paging space in my former environment.


Btw.: Please do not just post an update with new formatting but correct the garbage post you have left next time, thanks