I'have just read orange book "Local AMP backup". This book gives guidelines to optimize ARCMAIN jobs according to the so-called "local AMP feature".
We use ARCMAIN via NETBACKUP and TARA on our database (2 nodes/60 AMPs/V15.00) with the same scripting method for years and i wonder why those recommendations are ignored:
TASM is governing by default the number of sessions for ARC utility jobs (16 sessions) and every day we can observe Archive jobs running with very irregular speed rates,
as a small-sized configuration would do when bottlenecks and high traffic are slowing archive process.
Shall we consider local AMP backup and changing parameters apart TASM (how many streams ?) and in relation with TASM (how many sessions ?).
In particular, is the "as many sessions as AMP" a good recommendation ?
Thanks for sharing,
As described in the Orange Book, optimal number of sessions will depend on a number of things - including not just nodes and AMPs but how many media servers there are, and how many concurrent backup streams your configuration will support. And Local AMP Backup can be tricky to achieve. The good news is that this matters mainly for large configurations (multiple media servers) backing up large tables (hundreds or thousands of GB each).
Each session can only back up from one AMP at a time, so if you use 16 sessions for 60 AMPs, the sessions are balanced across the nodes, and the data balanced across the AMPs, you would get 3 iterations of 16 AMPs at a time and a final iteration for the remaining 12 AMPs. So I would consider increasing from 16 to 20. Whether 30 or 60 would be better than 20 depends on the details of your BAR configuration and your backup jobs (e.g. do you ever run multiple backups concurrently?).
Yes, we run up to 6 jobs simultaneously ! first one job and 5 more jobs start one hour later.
We have one BAR server ( 2 media servers) and we use only one stream.
The whole daily archive size is around 10 TO.
The fact is that production jobs are going on in the same time: as soon as a database Hut lock is released we can see BTEQ and MLOAD sessions starting.
One more observation: Archive log in TARA shows sessions freezing at some time, that is why we put a rule in viewpoint to abort ARC sessions at 1h30 AM.