Change of database, how to measure the performance improvements in JDE

I have a client that is going though some major database changes next weekend, and I really want to know how I can tell them what an awesome change it was!  There are a couple of challenges with quantification of performance:

1. It's a development environment.  No regular scheduled jobs, ad hoc changes - difficult to get consistency for the compare.
2. It's a managed environment (the client outsources everything to multiple parties), so again it's hard to see the actual improvements
3. They are moving from SE to EE, this change makes things harder to evaluate
4. I don't have access to the machines.

All of the above does create some challenges, this is what I plan to compare:

• full package build time.  I appreciate that this has not real impact on end user performance, but it a great database barometer.  It does a shed load of I/O with the database and generally is I/O bound.  We all know that JDE is an I/O beast (damn you database agnostic design - or praise you)...  So it is a good litmus test.  The number itself (build time) means nothing in a vaccuum, but if it's doubled or halved after the system more - that means something!
• high I/O UBEs.  If you do not have ERPInsights, look at the F986114 and one of the columns is number of rows processed in the main loop. 

• Rows Processed

  Alias: PWPRCD

  The number of rows processed by main driver section of the batch job.

Armed with the above, you could do a quick SQL - work out the jobs that process a shed load of data and then run them in the non production environments (at least once... at least!!) and then run them after the upgrade, so you'll know if there is a change.

If you have ERPInsights, it's much easier.

You can use the compare period functionality.  Choose the correct environment and it will compare every job between the "before" and "after"  -giving your a birds eye view of the performance change.

• Interactive performance compare:  The final and oft thought most important metric is how much quicker all of the web pages are after the database change.  You can use a stopwatch before and after - this is probably not going to assist.  You can use OATS (which I like) to script some scenarios.  Fusion5 use ERPInsights

We can do a period compare for all pages, and then see what individual pages might be faster or slower before and after the upgrade!  Nice.

Of course you will report on CPU utilisation and IOPs and seek times...  But real user data is where the rubber hits the road!