Home Page for the TeradataForum
 

Archives of the TeradataForum

Message Posted: Mon, 08 Apr 2003 @ 02:42:01 GMT


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


Subj:   NetVault - Windows 2000 Archive Question
 
From:   Tom Stanek

I'm stumped.

I am looking at a regularly scheduled database archive that is being executed via NetVault. Summarized DBC.ACCTG data shows that the process is CPU skewed, i.e. parallelism is about 36%. However, disk I/O is almost perfectly parallel, about 97%. Based on my limited experience with Arcmain, this doesn't seem right. FYI, parallelism is computed by taking the max vproc cpu and dividing by the average vproc cpu (it seems like everyone does it just a little bit different.). The CPU consumption numbers are as follows:

Minimum AMP CPU:        212
Maximum AMP CPU:        1269
Average AMP CPU:        462

I don't have the detail for each AMP because it runs on Saturday and DBC.ACCTG is cleared every night. (That's probably the next step unless someone comes up with an answer.)

A detailed examination shows that the data tables being archived, about 1500, show no significant skewing of the data. All but 10 are at least 80% parallel and the ones below this level are all smaller than 10 MB. The system has four nodes and NetVault is running on one of the nodes. Looking at ResUsageSPMA shows that the node with NetVault is much more consumptive of CPU than the other nodes. This seems reasonable, although I was surprised to see that while the other 3 nodes' CPU Busy percent ranged from 2-10%, the node with NetVault often exceeded 50%. The backup is normally the only process running on the system.

To the best of my knowledge, the only other thing that NetVault is doing from a Teradata perspective is updating the $NETVALUT_CATALOG.CATALOG table. I know that NetVault is inserting a row into the catalog table for every database name, tablename combination. The PI on this NUPI SET table is EventNum and databasename. Although that causes hash collisions, I wouldn't expect it to cause that much additional overhead for these PI inserts. The highest hash collision count I saw was 144 rows, using the HASH functions.

I could change the PI of the NetVault table to be more selective, but I am hesitant do so because I can't predict with certainty what NetVault would do. I can't image it being a problem, and given that it is part of the NetVault software, I'm not comfortable with that solution. Can anyone give me some direction or insight on this one?


Regards,

Thomas F. Stanek
TFS Consulting, Inc.
www.tfsconsulting.com



     
  <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