Archives of the TeradataForum

Message Posted: Wed, 05 Mar 2003 @ 19:34:35 GMT

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

Steve,

Regarding the RP weightings, keep in mind that the entire PSF algorithm is relatively based. By that I mean that the RP weights are "high" only relative to each other. The relative difference between the weightings is what's important. Therefore, in the instance where you have two partitions, the effect would be the same whether you had 100 and 75 or 1000 and 750. There would no difference in the way the system behaves.

As far as moving things out of the default partition (RP0), that's typically a good thing to do but it is not necessary. I typically like to keep RP0 for system work and, optionally, for very predictable, high priority work such as application that does OLTP processing or canned reporting. With RP0 containing only system work, you could comfortably make the RP0:RP1 weighting ration 2:1 (i.e. 100 vs. 50) or even higher. Just remember that the more extreme the weighting differential, the more important it is to ensure that ONLY system work runs in default. Otherwise, a very poorly written query that inadvertently gets in RP0 that is relatively highly weighted could have a dramatic impact on system performance. Also, if you haven't switched the DBS Control setting to have rollback occur at the same priority as the executing transaction, this could also impact performance in a way you might not have intended.

Migrating in phases is certainly doable. Just appreciate the fact that, all things being equal, as you migrate work from RP0 to RP1, the performance characteristics of the work that got to RP1 first will probably degrade somewhat. Although that's somewhat of a guess without knowing specifically what your workloads look like.

An alternative approach might be to set the weight of both partitions to be the same (i.e. RP0 100, RP1 100), migrate out the workloads to RP1, then change the RP weights accordingly. As the work migrates, the system should behaveas if everything was in the same partition because, essentially, everything would be prioritized the same. And then you could more heavily weight the system work if that's your desired end state.

In response to your last question, I'm not sure I understand the question, but I'll give it a shot. Every partition has 8 performance groups numbered 0-7. All you can really do is assign a name and an allocation group to them. IN V2R4, the order is important. Specifically, PG 0 should have the lowest weight and 7 should have the highest. I believe that restriction is lifted in V2R5. In reality though, there are really only 4 user PGs per partition (the even numbered ones), with the others being "system performance groups". So...I think what would work best is to assign your allocation groups to all the performance groups in a partition in a manner similar to how the default partition is set up. In other words, treat the performance group as even-odd pairs.

Yikes... I guess I rambled on a bit. I haven't contributed to the list in a while so I guess I had to make up for the lost time. I hope this answers at least some of your questions

Regards,

Thomas F. Stanek
TFS Consulting, Inc.

www.tfsconsulting.com

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