Archives of the TeradataForum

Message Posted: Thu, 20 Mar 2003 @ 16:45:28 GMT

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

Currently we process 98% of all load/update activity between 1700 and 0700. Preserving the DBC for Query use in the day shift.

We treat sessions as a variable, supplying 6 sessions for less than 1000 input rows, 12 sessions when less than 100,000 rows and 24 sessions for less than 500,000 rows. We have maybe another 20 jobs that process between 500,000 and 30 million rows that we supply 75 sessions. I'm not sure we see any reward to the 75 sessions, I just have never taken the time to tune it down and measure for a sweet spot.

We load from multiple mainframe datacenters and the main datacenter has huge sessions available, but the remote sites are limited to 240 total sessions for all loads/fastexports running out of that site. So it is very important for us not to default to 1 session per amp, as is the default if you do not supply a sessions overide in your JCL script.

The Tenancy issues are solved by running fewer loads than you have load partitions ie increase load partitions to 15 and then only allow 10 or 11 or 12 initiators/ loads to run at once. In our case , we limit the load partitions at our mainframe sites so that the total never exceeds 15, ie 2 at 1 site, 8 at the prime site and 5 at the third site. Even with 15 allowable load partitions, and 700 - 800 different table loads/updates each night , it is hard to keep more than 10 or so load partions active at one time. Job mix is a great thing.

Occasionally , we experience brief ACCESSRIGHTS Locks, but I am fully confident the Security Profile Changes in V2R5 will solve that issue.

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