Difficult to say for sure, but it will flatten out eventually, usually after around 30 days or so, unless you have irregular backup schedules or, for example rebuild machines with different server names a lot. I will explain why this is a factor if this affects you, but will not go into details at this point as it is kinda long to explain.
If it's hanging during report generation, this would normally point to either a resource issue (either Disk I/O or SQL has sucked up all your memory and CPU), or indicate that the indicies need to be rebuilt (which is what the SQL maintenance plan does). I would suggest this is run weekly on a Sunday (unless you run backups then).
Avoid running reports or maintenance when you know it will clash with the daily prune job. The prune job will usually be very disk I/O intensive (as it is when a merge is done), so running a report or maintenance at the same time is not advisable and can be counter-productive.
To debug this further, you could run tracing in SQL on the asdb database when the report is running. It would give you an idea of what SQL is doing at the time it 'hangs' and if it is a factor (it will show what SQL statements and T-SQL commands are being issued to SQL and if ARCserve is waiting on SQL, or whether ARCserve has just got itself in a mess.
There is an alternative to all the merging and pruning in that you could use Catalog DB. What this means is that although the session information will be available in the DB (and therefore it works with rotations), the actual session detail (files/directories/db's backed up) do not get automatically merged into the database, but are held on disk in compressed .cat form, and only merged to the DB if you actually require the detail for a point and click restore.
Catalog DB is an on/off thing configured in server admin, and I think there is a chapter on it in the admin guide - but don't quote me on it
See if anything from this longer than I planned post helps and we'll go from there.
