help with excessive WSAECONNRESET causing instability - msgType

Okay, this is for the next time I forget message types.

Client is getting 100's of 

        10054-Error from Host=<145 .47.230.206=""> in recv returned 10054 (WSAECONNRESET): Connection was reset by peer

in the logs, sometimes I care, most times I do not.  I care when the message is important.

So in looking at the 10054's you might get a bunch of these:

3120/7552 Wed Jun 24 07:05:48.441000 netflow.c1686

3120 (pid) in routeOutgoingQueue(), unable to send message: sd=-1, msgId=2989, msgHost=172.30.72.6, msgPort=6091, sendingHost=172.30.72.4, msgType=15501, msgRange=28, krnlName=APP SERVER KERNEL, reqNet=0, resNet=0, reqKrnl=9860, resKrnl=0, msgFlags=0.

What can you tell about the msgType?  This is the important part of this message, because really - this tells you if you can ignore the message or not.

This is defined in jdenet.h - here is some help so 15501 is RTE - don't really care...  let's move on!

See how easy it is...   Remember that anything in /* */ is comments, so that is really a guide.  I think that the internal #defs of all these are in a file that we do not have access to as a client, so thanks for the comments JDE!

   JDEMSGSTARTWFPROC=WORK_FLOW_RANGE_START,  /* 4001 : Start process on server                     */

   JDEMSGCOMPLETEWFACT,                      /* 4002 : Complete activity on server                 */

   JDEMSGWFINTEROP,                          /* 4003 : Workflow Runtime Interop, inbound           */

   JDEMSGWFMONITORING,                       /* 4004 : Extract monitoring info for the jas server  */

   JDEMSGWFMONITORINGACTIONS,                /* 4005 : Monitoring actions from the jas server      */

   JDEMSGWFDESIGN,                           /* 4006 : Extract Graphical Info for the jas server   */

   JDEMSGWFDRILLDOWN,                        /* 4007 : Resolve Local sub proc task --> proc name   */

   JDEMSGWF_XML_SYSTEM_FUNCTION,             /* 4008 : Message System Function                     */

   JDEMSGWFFREEENV                           /* 4009 : Free Environment                            */

/* XMLTransaction - kernel type 15, Range 5001 - 5256 */

  XML_TRANSACTION_MSG = XML_TRANSACTION_RANGE_START,   /* 5001 */

  XML_TRANSACTION_LAST_MSG = XML_TRANSACTION_RANGE_END /* 5256 */

/* XMLList - kernel type 16, Range 5257 - 5512 */

  XML_LIST_MESSAGE = XML_LIST_RANGE_START, /* 5257 :     */

  XML_LIST_LAST_MSG = XML_LIST_RANGE_END   /* 5512 :     */

/* EVN - kernel type 19, Range 12001 - 13000 */

   IE_MSG_SUBSCRIBE=EVN_RANGE_START,   /* 12001 :                           */

   IE_MSG_EVENT,                       /* 12002 :                           */

   IE_MSG_SUBSCRIBE_INTERNAL,          /* 12003 :                           */

   IE_MSG_EVENTLIST,                   /* 12004 :                           */

   IE_MSG_EVENTTEMPLATE,               /* 12005 :                           */

   IE_MSG_EVENTOUT,                    /* 12006 :                           */

   IE_MSG_RELIABLE_EVENT,              /* 12007 :                           */

   IE_MSG_RELIABLE_REPLY_TO_SENDER,    /* 12008 :                           */

   IE_SD_IEO,                          /* 12009 :                           */

   IE_SD_ZEVG,                         /* 12010 :                           */

   IE_SD_SUBSCRIBE,                    /* 12011 :                           */

   IE_MSG_REQUEST_SUBSCRIPTION_INFO,   /* 12012 :                           */

   IE_MSG_DIRECT_ROUTING,              /* 12013 :                           */

   IE_MSG_START_KERNEL,                /* 12014 :                           */

   IE_MSG_LAST     = EVN_RANGE_END     /* 13000 : reserve the final message */

/* IEO - kernel type 20, Range 13001-13256 */

   IEO_MSG_EVENT_INIT = IEO_RANGE_START, /* 13001 :                        */

   IEO_MSG_EVENT_ADD,          /* 13002 :                                  */

   IEO_MSG_EVENT_FINALIZE,     /* 13003 :                                  */

   IEO_MSG_EVENT_INTROSPECT,   /* 13004 : create XML template for an event */

   IEO_MSG_EVENT_GET_TYPES,    /* 13005 : provide list of events           */

   IEO_MSG_RELIABLE_EVENT,     /* 13006 : reliable IEO event               */

   IEO_MSG_RELIABLE_REPLY_TO_SENDER,     /* 13007 : reply to sender of reliable event*/

   IEO_SD_EVG,                           /* 13008 : SDTool connectivity event        */

   IEO_MSG_DIRECT_ROUTING,               /* 13009 : Direct routing                   */

   IEO_MSG_EVENT_LAST = IEO_RANGE_END  /* 13256 : reserve the final message        */

/* XMLDispatch Kernel - kernel type 22, Range 13513-14000.    */

  XMLDispatchMessageType = XMLDISPATCH_RANGE_START,

  eNetProcessXMLDoc = XMLDISPATCH_RANGE_START + 2,

  eNetNotifyTransport,

  eNetResponseTransport,

  eNetSubscribeXMLDoc,

  IE_MSG_RELIABLE_OUT,                /* 13519 :                           */

  XMLDispatchLastMsgType = XMLDISPATCH_RANGE_END

/* XTSKrnl - kernel type 23, Range 14001-14250 */

   XTS_MSG_GET_PROXY_INFO = XTS_RANGE_START,  /* 14001 :           */

   XTS_ENGINE_TRANSFORM,            /* 14002 : used by XTS to JVM          */

   XTS_MGR_TRANSFORM,               /* 14003 : used by XTS to JVM          */

   XTS_COMP_PROCESS_CREATE,         /* 14004 : used by XTS to JVM          */

   XTS_COMP_PROCESS_TRANSFORM,      /* 14005 : used by XTS to JVM          */

   XTS_COMP_PROCESS_DESTROY,        /* 14006 : used by XTS to JVM          */

   XTS_MSG_EVENT_LAST = XTS_RANGE_END /* 14250 : reserve the final message */

/* XMLService - kernel type 24, Range 14251-14500 */

   XMLSERVICE_CALLMETHOD = XMLSERVICE_RANGE_START,        /* 14251 */

   XMLSERVICE_LOADDOCUMENT,                               /* 14252 */

   XMLSERVICE_DELETEDOCUMENT,                             /* 14253 */

   XMLSERVICE_LAST = XMLSERVICE_RANGE_END                 /* 14500 */

/* Client Kernel mesg, type 27, Range 15001 - 15250 */

   CLIENT_MSG_EVENT_NOTIFY  =  CLIENT_KERNEL_RANGE_START, /* 15001 */

   CLIENT_MSG_FORM_INTERCON                               /* 15002 */

/* Ranges for the java kernel */

   JAVA_MSG_TRIGGER = JAVA_APP_SERVER_RANGE_START,

   JAVA_MSG_EVENT_CACHE_CLEAR,

   Java_MSG_SUBSCRIBER_CACHE_CLEAR,

   JAVA_MSG_EVENT_LAST = JAVA_APP_SERVER_RANGE_END /* 15750 : reserve the final message */

/** Metadata - kernel type 30, Range 15751 - 15900 */

   METADATA_XML_TO_BINARY = METADATA_RANGE_START,        /**< 15751 - to convert a metadata XML doc into a platform dep. c-structure.*/

   METADATA_BINARY_TO_XML,                               /**< 15752 - to convert a platform dep. metadata c-structure into an XML doc.*/

   METADATA_PREPARE_UBE_CACHE,                           /**< 15753 - to prepare the persistent UBE cache. */

   METADATA_QUERY_TEST_STATUS = METADATA_RANGE_END - 3,  /**< 15897 - for querying the state of the MD kernel. */

   METADATA_START_TEST_MODE = METADATA_RANGE_END - 2,    /**< 15898 - start test mode to support mdtest test driver. */

   METADATA_END_TEST_MODE = METADATA_RANGE_END - 1,      /**< 15899 - to end test mode. */

   METADATA_LAST = METADATA_RANGE_END                    /**< 15900 */

/* XMLPublisher - kernel type 31, Range 15901 - 16150 */

   XMLP_EXECUTE_REPORT = XMLPUBLISHER_RANGE_START,       /* 15901 Phase 1 publish */

   XMLP_PUBLISH_REPORTDEF,                               /* 15902 Phase 2 publish */

   XMLP_PUBLISH_REPORTDEF_FROM_UBE,                      /* 15903 Phase 2 publish */

   XMLP_NEW_BIP_ENTRY,                                   /* BIP - hardening */

   XMLP_LAST = XMLPUBLISHER_RANGE_END                    /* 16150 */

/* Management Kernel type 32, Range 16151 - 16199 */

   MANAGEMENT_PROCLIST_REFRESH = MANAGEMENT_RANGE_START,        /* 16151 */

   MANAGEMENT_CLEAR_CACHE,                                      /* 16152 Clear Table Cache */

   MANAGEMENT_LAST = MANAGEMENT_RANGE_END                       /* 16199 */

/* Message Ranges for SBF JAVA KERNEL type 33, Range 16201 - 16450 */

/* TEXTSEARCH- kernel type 34, Range 16451 - 16600 */

   TEXT_START_INDEXING = TEXTSEARCH_RANGE_START,

   TEXT_CLEAR_INDEXING,

   TEXT_VERIFY_SES,

   TEXT_VERIFY_FTP,

   TEXT_LAST = TEXTSEARCH_RANGE_END

6604/10708       Wed Jun 10 10:43:33.957000                    xmlrequest.cpp1398

              ICU0000017 - ICU CodePage for 1252 is ibm-1252.

6604/10708       Wed Jun 10 10:55:33.002000                    callsbfmsg.c330

              Did not receive response from BSSV Server. JDENET Error = eTimeOut

Back to my problem now, I see that that UBE is trying to call a BSSV.  This eventually times out (after 12 minutes - yes that's right!!!  Don't ask - honestly) and I can see that the UBE passes the request to the jdesnet kernel, yet this kernel gets the following (immediately after the call).  I think that JDE needs to do some better error handling - because this is NEVER passed back to the UBE - it just times out... haha.

152/8584        Wed Jun 10 10:43:44.282000              netrcv.c486

        10054-Error from Host=<145 .47.230.206=""> in recv returned 10054 (WSAECONNRESET): Connection was reset by peer

So, this is what I'm trying to solve.  I know that this can come up a lot on windows.   I can see that it took 11 seconds between the last known message in the UBE log to this network error - but the UBE generally takes a little while to run.

I know that this error means that the BSSV server forcibly terminated the connection at it's end, and this is picked up by jdesnet with the error above.

What I'm trying to work out is why?  Note that this is not a "cannot connect" - it's connection reset...   My thoughts are that it's trying to use a previously opened connection and this has been swept up by the firewall (every 6 hours of unused connections are removed).

it's very difficult to prove... but I'm getting there.  Perhaps nettrace is next?  If this was AWS, I'd be able to use cloudwatch and solve it quickly.

Anyway, this was a quick helper on msgType and what you can ignore.

Look through EVERYONEs UDO's for a dodgy SQL statement

On the hunt for a rouge SQL statement…

 We have the following clue:

 SELECT SDAN8,SDQTYT,SDPPDJ,SDUORG,SDDCT,SDFRGD,SDDELN,SDPA8,SDADTM,SDTHRP,SDSRP2,SDPRP2,SDUPRC,SDTHGD,SDOPTT,SDFRMP,SDSHPN,SDSO15,SDOORN,SDDMCT,SDRSDJ,SDSQOR,SDLITM,SDMOT,SDCOMM,SDLNTY,SDDOCO,SDDRQT,SDLTTR,SDRFRV,SDEMCU,SDSOBK,SDNXTR,SDDCTO,SDLOTN,SDPRP3,SDDSC1,SDSWMS,SDLNID,SDFUP,SDRCTO,SDFRTH,SDPEFJ,SDSRP5,SDOPDJ,SDPOE,SDPMTN,SDOKCO,SDAITM,SDOPPID,SDKITID,SDUOM2,SDRKCO,SDDRQJ,SDAAID,SDVR01,SDDGL,SDALLOC,SDRSDT,SDLOCN,SDANBY,SDADDJ,SDMCU,SDDOC,SDCNDJ,SDAEXP,SDPRP4,SDPEND,SDZON,SDDVAN,SDUOM,SDNUMB,SDSRP4,SDPMTO,SDPRIO,SDSO16,SDRLLN,SDSHAN,SDPSIG,SDRKIT,SDPDTT,SDKCO,SDPMPN,SDITM,SDCORD,SDCARS,SDIVD,SDSPATTN,SDSRP1,SDTORG,SDUNCS,SDTRDJ,SDPSN,SDOGNO,SDVR02,SDFUC,SDPRP5,SDSOCN,SDKCOO,SDPRP1,SDUOM4,SDSHCCIDLN,SDCRCD,SDOCTO,SDSRP3,SDASN,SDTPC,SDSOQS,SDRLIT,SDPDDJ,SDPNS,SDFEA,SDSFXO,SDDSC2,SDSONE,SDCRR,SDRORN FROM TWEDTA.F4211 WHERE (((((((((((((((((((((SDLITM LIKE :1  ) OR SDLITM LIKE :2  ) OR SDLITM LIKE :3  ) OR SDLITM LIKE :4  ) OR SDLITM LIKE :5  ) OR SDLITM LIKE :6  ) OR SDLITM LIKE :7 ....

 

What can I tell from this?

• Looks like a JDE statement, by the capitals & syntax used
• Counting the (‘s there are 20 different conditions applied, the assumption is that it’s looking only for LITM like – but because I do not have the complete statement – I cannot be sure.
• Seems to have been run more than once
• This is killing the performance of JDE – it’s not using any indexes

So, what can we do to find this?  Firstly, lets make sure that this is NOT someone’s special advanced query.  If someone has saved this, they could run it (automatically) when they launch P42101 (for example).

Advanced queries are stored in F952430, generally in central objects.  The acutual query is stored in a blob, but is pretty easy to read – it’s XML.

UDO tables are explained below:  This is a handy reference table.

User Defined Objects	Object Type (H92|OT)	Runtime Table
One View Reports	ONEVIEW	F952400 - User Generated Contents Detail
EnterpriseOne Pages	E1PAGE	F952400 - User Generated Contents Detail
Composite Pages (from Tools Release 9.2.0.2)	COMPOSITE	F952410 - Composite Page
Images (from Tools Release 9.2.0.2)	IMAGE	F952415 - Image
One View Watchlists	WATCHLIST	F952420 - OneCenter Watchlists Detail
Notifications (from Tools Release 9.2.2.0)	NTF	F952425 - Notification
Advanced Queries	QUERY	F952430 - Advance Query
Personal Forms (from Tools Release 9.2.1)	PERSFORM	F952435 - Dynamic Form Personalization
Form Extensions (from Tools Release 9.2.2.4)	FORMEXTNS	F952439 - Form Extensions
Grid Formats	FORMAT	F952440 - Grid Formats Detail
EnterpriseOne Search (From Tools Release 9.2.1.2)	SEARCH	F952445 - EnterpriseOne Search
Composite Application Framework (CafeOne)	CAFE1	F952450 - CafeOne Layout Table
Schedules (from Tools Release 9.2.2.0)	SCHEDULE	F952455 - Scheduler
Orchestrations	ORCH	F9524810 - Orchestrations
Cross Reference	XREF	F9524820 - Cross Reference
Rule	RULE	F9524830 - Rule
Service Request	SREQ	F9524840 – Service Request
Whitelist	WLST	F9524850 - Whitelist

 

So I developer the query below to look for a clause that has at least 15 conditions.  Here is a hint, if you suspect your user is using the “in” functionality – then it will not be using the like statement!  They need to be using the =’s operator if the user has chosen in.  I can therefore determine that my query above is using like, so there must be many separate conditions specified.  This can only be done with an advanced query (or data selection in a UBE, but I know that this is from the web).

As a template SQL below looks for any advanced query using or more than 15 times…  

Remember I know that there are at least 20 operators, so I started by look at statements that are saved with over 15.  Note that I’m also only looking at those that use an “or” operator by specifying the regex_match for LOGIC=false.   I’m actually counting the “WHERE clause” conditions with my regex.

 

select AQUSER, AQFMNM, AQSFMNM, AQWOBNM, utl_raw.cast_to_varchar2(dbms_lob.substr(AQOMRBLOB,2000,1))

from pd920.f952430

where  regexp_count(utl_raw.cast_to_varchar2(dbms_lob.substr(AQOMRBLOB,2000,1))||utl_raw.cast_to_varchar2(dbms_lob.substr(AQOMRBLOB,2000,2001)), 'SPECIAL_VALUE', 1,'c') >= 15

and regexp_count(utl_raw.cast_to_varchar2(dbms_lob.substr(AQOMRBLOB,2000,1))||utl_raw.cast_to_varchar2(dbms_lob.substr(AQOMRBLOB,2000,2001)), '\/CONDITION', 1,'c') >= 15

and regexp_count(utl_raw.cast_to_varchar2(dbms_lob.substr(AQOMRBLOB,2000,1))||utl_raw.cast_to_varchar2(dbms_lob.substr(AQOMRBLOB,2000,2001)), 'LOGIC="false"', 1,'c') = 1;

 

We can build on this to look for “like” and not like etc etc, but need the entire SQL statement if that is possible.

Anyway, you can see form the above it’s easy to query the UDO’s in bulk and find what we are looking for.

The below is a sample using & and contains… you can see how it’s easy to read.

 

'<?xml version = ''1.0'' encoding = ''UTF-8''?>

<ADVANCED_QUERY AUTOCLEAR="false" AUTOFIND="true" GUID="3ae9c029d8e7412c9f939d99fa6fad3a" LOGIC="true">

   <CONDITION LEFT="qbe0_1.19" OPERATOR="5">

      <VALUE DECIMALFORMAT="." SPECIAL_VALUE_ID="0">100</VALUE>

   </CONDITION>

   <CONDITION LEFT="qbe0_1.20" OPERATOR="4">

      <VALUE SPECIAL_VALUE_ID="0">ee</VALUE>

   </CONDITION>

</ADVANCED_QU

Here are some sample queries and the associated XML’s from JDE UDOs.

 

REM INSERTING into EXPORT_TABLE

SET DEFINE OFF;

I<?xml version = ''1.0'' encoding = ''UTF-8''?>

<ADVANCED_QUERY AUTOCLEAR="false" AUTOFIND="true" GUID="7fffc84b04384edab7622f5539d395c4" LOGIC="false">

   <CONDITION LEFT="qbe0_1.19" OPERATOR="5">

      <VALUE DECIMALFORMAT="." SPECIAL_VALUE_ID="0">1000</VALUE>

   </CONDITION>

   <CONDITION LEFT="qbe0_1.19" OPERATOR="5">

      <VALUE DECIMALFORMAT="." SPECIAL_VALUE_ID="0">500</VALUE>

   </CONDITION>

   <CONDITION LEFT="qbe0_1.19" OPERATOR="5">

      <VALUE DECIMALFORMAT="." SPECIAL_VALUE_ID="0">200</VALUE>

   </CONDITION>

   <CONDITION LEFT="qbe0_1.19" OPERATOR="5">

      <VALUE DECIMALFORMAT="." SPECIAL_VALUE_ID="0">100</VALUE>

   </CONDITION>

</ADVANCED_QUERY>');

 

 

<?xml version = ''1.0'' encoding = ''UTF-8''?>

<ADVANCED_QUERY AUTOCLEAR="false" AUTOFIND="true" GUID="bdee48faf48f4b9a8678540d8514dbac" LOGIC="false">

   <CONDITION LEFT="qbe0_1.48" OPERATOR="2">

      <VALUE SPECIAL_VALUE_ID="0">100</VALUE>

   </CONDITION>

   <CONDITION LEFT="qbe0_1.48" OPERATOR="2">

      <VALUE SPECIAL_VALUE_ID="0">200</VALUE>

   </CONDITION>

   <CONDITION LEFT="qbe0_1.48" OPERATOR="2">

      <VALUE SPECIAL_VALUE_ID="0">300</VALUE>

   </CONDITION>

</ADVANCED_QUERY>');

 

 

<?xml version = ''1.0'' encoding = ''UTF-8''?>

<ADVANCED_QUERY AUTOCLEAR="false" AUTOFIND="true" GUID="5c9eaa0b95fc4bfe91ef0e5328ad45b5" LOGIC="false">

   <CONDITION LEFT="qbe0_1.19" OPERATOR="5">

      <VALUE DECIMALFORMAT="." SPECIAL_VALUE_ID="0">100</VALUE>

   </CONDITION>

   <CONDITION LEFT="qbe0_1.48" OPERATOR="4">

      <VALUE SPECIAL_VALUE_ID="0">000</VALUE>

   </CONDITION>

   <CONDITION LEFT="qbe0_1.48" OPERATOR="4">

      <VALUE SPECIAL_VALUE_ID="0">100</VALUE>

   </CONDITION>

</ADVANCED_QUERY>');

<?xml version = ''1.0'' encoding = ''UTF-8''?>

<ADVANCED_QUERY AUTOCLEAR="false" AUTOFIND="true" GUID="3da0a6e18d6a4c4db7f9016a7334115e" LOGIC="false">

   <CONDITION LEFT="qbe0_41.109" OPERATOR="2">

      <VALUE SPECIAL_VALUE_ID="0">10000</VALUE>

   </CONDITION>

   <CONDITION LEFT="qbe0_41.109" OPERATOR="2">

      <VALUE SPECIAL_VALUE_ID="0">2000</VALUE>

   </CONDITION>

   <CONDITION LEFT="qbe0_41.109" OPERATOR="2">

      <VALUE SPECIAL_VALUE_ID="0">4000</VALUE>

   </CONDITION>

   <CONDITION LEFT="qbe0_41.109" OPERATOR="0">

      <VALUE SPECIAL_VALUE_ID="0">1234</VALUE>

   </CONDITION>

   <CONDITION LEFT="qbe0_41.109" OPERATOR="0">

      <VALUE SPECIAL_VALUE_ID="0">456789</VALUE>

   </CONDITION>

   <CONDITION LEFT="qbe0_41.109" OPERATOR="0">

      <VALUE SPECIAL_VALUE_ID="0">123456</VALUE>

   </CONDITION>

   <CONDITION LEFT="qbe0_41.109" OPERATOR="0">

      <VALUE SPECIAL_VALUE_ID="0">789456</VALUE>

   </CONDITION>

</ADVANCED_QUERY>');

 

<?xml version = ''1.0'' encoding = ''UTF-8''?>

<ADVANCED_QUERY AUTOCLEAR="false" AUTOFIND="true" GUID="f2016ecdb4c147ec843b4f2fdf63cb7f" LOGIC="false">

   <CONDITION LEFT="qbe0_1.48" OPERATOR="12">

      <VALUE SPECIAL_VALUE_ID="0">100</VALUE>

      <VALUE SPECIAL_VALUE_ID="0">200</VALUE>

      <VALUE SPECIAL_VALUE_ID="0">3000</VALUE>

      <VALUE SPECIAL_VALUE_ID="0">4000</VALUE>

   </CONDITION>

</ADVANCED_QUERY>');

 

<?xml version = ''1.0'' encoding = ''UTF-8''?>

<ADVANCED_QUERY AUTOCLEAR="false" AUTOFIND="true" GUID="3ae9c029d8e7412c9f939d99fa6fad3a" LOGIC="true">

   <CONDITION LEFT="qbe0_1.19" OPERATOR="5">

      <VALUE DECIMALFORMAT="." SPECIAL_VALUE_ID="0">100</VALUE>

   </CONDITION>

   <CONDITION LEFT="qbe0_1.20" OPERATOR="4">

      <VALUE SPECIAL_VALUE_ID="0">ee</VALUE>

   </CONDITION>

</ADVANCED_QU

 When logic="TRUE" this seems to be AND

 

You've seen all of the examples above, and you know they query and the syntax.  If you have similar problem queries, this will allow you to troll through the UDO's and do a mail merge with users - telling them that you are going to delete their 20 non indexed OR based text range queries - and DON'T do it again!

 

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!

UBE Visual Performance Analysis

It's hard to determine UBE performance problems - especially when there are long term trends that you need to look into.   There are many scenarios that you need to look at your batch window and determine how the runtimes have been changing over time so that you can make allowances for that.  

We have our ERPInsights suite that can give you easy access to this information.

I'm a bit of a visual person, so I like to see patterns and be able to find problems easily like that.  A table of numbers is good, but give me the above every time.

As they say - a video is worth 1000 pictures, so here is a really quick demo of how you can use the screen.

We are allowing clients to do this as a 1 off - we can take all of your UBE history, build a cube and provide you access to your historical data.  If you'd like to see your data as a 1 off, please reach out and I can let you know the SQL to run (and the amount I'll charge haha) - don't stress, it's super cheap.  Find me on linked in, or send a note to sales at Fusion5.

Note that our main service is keeping the "cube" of data current in the cloud with some software we've written.  Therefore ALL of your WSJ history can be deleted, because we have it safely in the cloud.  Note that we are going to be extending this to any data - therefore allowing you incredible reporting power in the cloud that does not affect your performance.