Thanks. Tried this and it eventually does catch up. But this is not the 
correct solution to the problem. It masks the real issue ie the Informix 
Module generates a job for each log. The processing of this job is the 
real reason the log backups are slow (even for disk).

In reviewing how ONBAR works, it opens 1 connection to NBU and ships the 
  logs sequentially to it. It is the same onbar process that delivers 
every log, not separate ones. But NBU treats each log as a separate 
request and generates a job for it.

Can you imagine a STREAM for a FS and each file is a separate request 
and therefore a separate job? I have to escalate this.

But thanks for this. It is a workaround.

Justin Piszcz wrote:
> 
> 
> On Fri, 27 Mar 2009, Larry Mascarenhas wrote:
> 
>> Hello,
>>
>> I'm running backups on Informix7 DBs. We're able to stream the DB
>> backups using parallelism 4 and get good throughput (100MB/s, yes
>> megabytes/sec, it is a SAN Media Server). A 300Gig DB takes less than 1
>> hour.
>>
>> However (I know ;)), when it backs up the LOGS (all backups go to tape,
>> I don't have Disk backups), each log comes in as a separate request.
>> Each log is therefore a separate job. So the time taken to process this
>> request is greater than the time to backup each log. ie each log is
>> 100MB and the time taken is <2secs (when the resource is allocted and
>> ready), but it takes 1+min to create the job/assign the resource/and
>> begin writing. This is resulting in my never being able to catch up with
>> the rate of logs generation although the amount to be backed up is
>> minimal eg 30logs is just 3Gig, but takes approx 30mins and by that time
>> 10 more logs are created. I am using media_unmount_delay so the tapes
>> are not re-mounting for every request.
>>
>> I cannot increase the size of the LOGS as this would affect replication
>> and recoverability (double whammy). This is Symantec's recommendation.
>>
>> I'm looking for experiences that people have had to speed up the
>> Informix backups.
>>
>> Thanks.
>>
>> -- 
>>
>> Larry Mascarenhas
>> LMascare AT comcast DOT net
>> _______________________________________________
>> Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
>> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>>
> 
> Why not use a Disk Staging Unit if the logs are small enough?
> 
> Send to disk first -----> then shoot to tape?
> 
> Justin.
> 

-- 

Larry Mascarenhas
LMascare AT comcast DOT net
_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu