Home Page for the TeradataForum
 

Archives of the TeradataForum

Message Posted: Fri, 04 Nov 2005 @ 17:00:38 GMT


     
  <Prev Next>  
<<First
<Prev
Next> Last>>  


Subj:   ARCMAIN throughput - limiting factors
 
From:   Anomy Anom

<-- Anonymously Posted: Friday, November 04, 2005 11:07 -->

We use ARCMAIN running on MVS for our database backups. One session per amp, over 100 amps. They go across ESCON channels to a virtual tape subsystem (VTS), which has a big cache in front of a bunch of tape drives (I don't know the details of the config). Currently we are able to achieve about 30 GB per hour with one archive job; we occasionally run two archives concurrently, and our total throughput doubles to about 60 GB per hour.

I'm curious as to what the biggest limiting factor is in the performance of our backups. Resusage shows zero queueing on our ESCON channels. Disk I/O rate is almost nil unless there are queries or other user activity happening on Teradata. No disk bottlenecks. Over the years, I've consistently seen that backups cause very little activity on Teradata.

I suspect there is something with how ARCMAIN is architected, but I'm not sure. Can anyone comment? Sure, I suppose the mainframe or VTS could somehow limit throughput, but the evidence above does not suggest VTS. If two concurrent jobs can push across 60 gig per hour, why can't one job do that? Would appreciate insight from anyone who may know how ARCMAIN really works.

Comment: I'm not interested in suggestions for other solutions for now, we are exploring them but I'm really just trying to understand why we can't get more speed out of our current approach.


Thanks



     
  <Prev Next>  
<<First
<Prev
Next> Last>>  
 
 
 
 
 
 
 
 
  
  Top Home Privacy Feedback  
 
 
Copyright for the TeradataForum (TDATA-L), Manta BlueSky    
Copyright 2016 - All Rights Reserved    
Last Modified: 27 Dec 2016