An Oracle JD Edwards Enterpriseone Performance and Tuning Paper 8/2007

UBE Performance and Tuning
An Oracle JD Edwards EnterpriseOne

Performance and Tuning Paper
8/2007
PURPOSE STATEMENT
This document provides considerations when reviewing system performance relative to

your JD Edwards EnterpriseOne system. Many factors can influence performance and
your results may differ depending on many different variables.
This document is intended for information purposes only, and may not be incorporated
into any contract. It is not a commitment to deliver any material, code, or functionality,
and should not be relied upon in making purchasing decisions. The development,
release, and timing of any features or functionality described for Oracle’s products
remains at the sole discretion of Oracle. Updates and enhancements are provided in
accordance with Oracle’s Technical Support Policies at:
www.oracle.com/support/collateral/oracle-technical-support-policies.pdf
UBE Performance and Tuning¡ Page i

UBE basics............................................................................................................................................ 1
General considerations for long running UBEs ......................................................................... 1
Concurrency.......................................................................................................................................... 2
Pre-Payroll UBE (R07200)............................................................................................................. 3
Sales Order Update (R42800)........................................................................................................ 3
Material Requirements Planning (R3482 / R3483) .................................................................... 4
Troubleshooting tips for MRP Performance issues: ............................................................. 4
UBE QUEUES .................................................................................................................................... 6
Multi-CPU machines....................................................................................................................... 6
Parallelism, concurrency, and multiple CPUs......................................................................... 6
Multi-threaded Queues ................................................................................................................... 7
UBE Subsystems.................................................................................................................................. 7
Platform Specifics.......................................................................................................................... 10
iSeries Memory Pools............................................................................................................... 10
Configuration...................................................................................................................................... 11
iSeries SQL packages .................................................................................................................... 12
Oracle Update Statistics................................................................................................................ 12
Important JDE.INI settings related to UBEs........................................................................... 13
Data Close to Processing ............................................................................................................. 13
The key issues:........................................................................................................................... 13
More details on data on iSeries, processing on other platform ..................................... 15
Qaqqini ........................................................................................................................................... 15
UBE logging and debugging ............................................................................................................ 16
Skewed extrapolations .................................................................................................................. 18
Last but not least: the ‘debug’ factor…...................................................................................... 19
UBE Performance and Tuning ¡ Page ii

UBE BASICS
This paper is intended to provide guidance on improving the runtime and throughput of EnterpriseOne batch
processes (UBE), primarily via configuration techniques and use case methodology. Performance items related to
coding and design of UBEs are not addressed here.
Oracle JD Edwards EnterpriseOne UBEs differ from interactive applications in a number of important ways:
A UBE is a distinct and separate process which ends when the UBE ends.
(Subsystem UBEs function differently; see that section)
Call Object Kernels, on the other hand, run a particular business function then continue to process,
waiting for the next incoming request from an interactive program to run a business function. They
keep running until the Enterprise Server is stopped or until ab-ending.
A UBE runs only one thread of execution for one user’s UBE, while a call object kernel runs business functions
for many users, possibly in a true multi-threaded architecture.
In terms of CPU usage, UBEs are like lap swimmers, while the CPUs are like lanes in the pool. One UBE wants
one CPU, and wants it for the duration of its run. It does not “share” well with other processes.
Call Object kernels, conversely, are like children jumping in and out of the pool. A Call Object Kernel uses the
CPU in spurts, but does not generally monopolize it for extended periods.
General considerations for long running UBEs

Because UBEs consume such a large percentage of a CPU:
©Copyright Oracle 2007. All rights reserved. UBE Performance and Tuning ¡ Page 1
Be conscious of business cycles and time windows when large UBE jobs are run.
Plan to avoid running large UBEs when heavy interactive processing is running.
Run large UBEs during downtimes (such as nights or weekends).
CONCURRENCY
The single biggest impact item for increasing UBE throughput – and perhaps the most underutilized - is
concurrency.
Many commonly used UBEs are capable of being broken up by data selection into multiple versions which are run
simultaneously. It is crucial that the data selections of the individual versions be non-overlapping to avoid data
corruption or data inconsistency.
These versions can then be run concurrently in a queue capable of running multiple UBEs.
Important: Any long running UBE, even if it’s not mentioned in this document, should be viewed as a
possible candidate for concurrency.
This depends on a number of factors:

The ability to specify data selection which does not overlap across versions.
The ability to divide the work into concurrent versions with reasonably equal streams.
Whether there is a need to combine the work across all the versions into a "grand total" of some sort,
or summarize results in a single report.
Whether the individual units of work across versions are independent of one another.
Important: If a server exists with multiple CPUs, try running more than one job to achieve substantial
throughput increases.
Multiprocessor servers are ubiquitous, especially within Oracle JD Edwards EnterpriseOne implementations, but
few programs ever utilize more than one processor at a time.
Running UBEs concurrently will make use of your multi-CPU hardware to maximize throughput. Multiple CPUs
do not make a job run faster; they allow more jobs to be run at the same time. See the section on UBE Queues for
more details.
Some common UBEs are routinely run concurrently:
Common Concurrent UBEs
UBE Suite Additional Information
R42800 Sales Order Load balancer in Oracle JD Edwards

EnterpriseOne 8.9
R3482 / R3483 MRP Uses a special system-based
implementation
R07200 Payroll Pre-Payroll
R12855 Fixed Assets User Defined Depreciations
Pre-Payroll UBE (R07200)

Each Employee’s figures are separate calculations independent of all others. Multiple employees may be processed
at the same time, it is not necessary to perform the calculations serially. This enables the concurrent solution to
increase throughput.
Following are two examples of UBEs which are commonly run as multiple concurrent versions for throughput
reasons, and for which Oracle ships features and functionality specific to these applications to aid in creating the
concurrent versions.
Sales Order Update (R42800)

The runtime window of Update Customer Sales (R42800) can be an issue with customers. The advice given to
customers usually includes the creation of multiple versions to run concurrently, and to eliminate time consuming
processing options.
Starting in version 8.10, this UBE has a load balancer feature. This is a simple pre-processor which automates the
process of creating the data selections for the individual versions so that they contain approximately equal levels of
processing. The Load Balancer also checks some of the most time consuming Sales Order Update Processing
Options.
Below are the processing options for the Load Balancer. The user specifies the number of versions, the tolerance
percentage for how much the data processed by the various version should vary, whether to evaluate processing
options, in addition to the base Sales Order Update version to be used.
Please refer to JD Edwards EnterpriseOne Sales Order Management 8.12 Implementation Guide, "Setting Processing
Options for Update Customer Sales (R42800)" for more information.
Material Requirements Planning (R3482 / R3483)

Another UBE which typically runs long enough to create issues in runtime window is Material Requirements
Planning (MRP – R3482 / R3483).
Oracle provides a parallel processing solution specific to MRP which employs Oracle JD Edwards EnterpriseOne
subsystems. Refer to the figure above in the description which follows.
It works well in situations where MRP cannot be divided into separate concurrent MRP runs because there is no
clear division between ownership of the supply and demand that MRP consumes.
Parallel processing manages Low Level Code processing requirements, creating a level break that assures
processing has completed for each low level code before beginning the next. All items must be processed at the
current level before moving to the next to accurately calculate the demand at the next level.
This is accomplished by launching multiple concurrent MRP subsystem versions and loading the Subsystem Job
Master Table (F986113) with items having the same Low Level Code. The number of subsystem versions
launched can be configured based on how many CPUs are available. The more subsystems, the greater the level of
concurrency.
When the UBE job is submitted in parallel processing mode, the UBE starts adding records for each item at the
first low-level code (LLX=1) to the Subsystem Job Master Table (F986113).
Once the table F986113 is loaded, each subsystem will read a record from F986113 and plan the item. So if the
user is running parallel processing with 3 subsystems, then each subsystem will read a record from F986113.
Subsystem 1 will plan item A (LLX=1) , subsystem 2 will plan item B (LLX = 1) and subsystem 3 will plan item C
(LLX=1). The UBE ensures that all items which are getting processed by each subsystem belong to same low level
code. Once all the items at the current low level code (LLX=1) are processed, the UBE deletes the F986113
records and increments the low level code value to 2 (LLX=2). This process is repeated until highest low level
code is planned. After all the records are processed, the subsystem jobs are terminated.
One customer reduced a 15 hour serial MRP run to a 4-hour parallel run by using the subsystem-based parallel
processing.
See the section "UBE Subsystems" for other uses of subsystem jobs.
Please refer to JD Edwards EnterpriseOne Tools 8.96 Development Tools: Report Design Aid Guide, "Working with
Subsystem Jobs" for more information.
Troubleshooting tips for MRP Performance issues:
Certain steps can be followed to increase the performance of MRP batch processes:
1. Set the planning horizon in R3482/R3483 to a value only as long as the business requires.
(See related solution 200782880 R3482/R3483 processing options).
2. Make sure the planning fence (F4102) is set to a maximum value no greater than the horizon.
3. Change the data selection and processing options. Carefully choose the data selection and set the appropriate
values for the processing options (PO) in order to cut down on unneeded processing. Narrow down the data
being processed through data selection. Several POs affect R3483 performance. Set the appropriate values
according to your needs.
a. R3482/3 performance tab
i. PO 2 should be blank if not using the print code.
ii. PO 3 should be blank, unless there is a special business need to have messages and time
series records for Phantoms.
iii. PO 4 can limit the number of work orders (WO’s) processed by using the status.
iv. PO 5 should not be set to “1”, unless you are using rate schedules.
b. R3483 multi-facility tab
i. PO 1 Process Each Branch should be blank.
ii. PO 2 should include a Date Branch to prevent multiple hits to the shop floor calendar. (See
related solution: 200782880 R3482/R3483 Processing Options).
4. Set the variable INITIAL_BRANCH_COUNT in BSFN B3401270.h when running R3483. The value could
affect performance. It is set to a default value of 50, but can be changed to the maximum number of branch
plants you are processing. This ensures that memory is not allocated for more branches than you are actually
processing.
5. Delete the Supply/Demand inclusion rules that are not being used.
6. Creating your own quantity type UDC (34/QT) may help MRP processing time by reducing the number of
calculations made by R3483. The F3413 Time Series Table has by far the greatest number of records written by
R3483. Elimination of some of those records that you will not use may help MRP Performance.
The standard MRP 34/QT Quantity Type table contains many quantity types calculated by R3483, and some
business models may not need all the quantity types provided in the standard table.
One possibility is to create a table with the relevant quantity types that you will be using. For example, if you
are not using Repetitive Manufacturing, or Rate Schedules, then eliminate the quantity types for Kanban, and
Rate Schedules. There are limitations in using the ATP and CATP lines, since MRP is a snapshot, and in a
dynamic environment, will only be valid at the end of the MRP run. Therefore, you might consider eliminating
those quantity types as well.
Important: Do not modify the standard 34/QT table. Create your own UDC table, copy the 34/QT, and then
delete the quantity types that you do not need. Then in the processing option in R3483 calling for quantity type table
(now populated with QT) enter your new value. MRP will then make the calculations for the quantity types relevant
only to your business model, and save valuable processing time.
7. Purge the F4801 table of closed work orders and the F4211 table of closed sales orders.
8. Contact GSC to receive a custom code change document to suppress the generation of the time series if the
time series is not used in your business model. This is will significantly improve performance.
9. Call GSC to receive a custom code change to avoid table caching of the F4101, F4102 and F4801 tables. This
should be done only if the MRP program is running out of memory, as this will actually reduce throughput.
UBE QUEUES
UBE queues are created and configured via the P986130 application. Their purpose is to control the total number
of simultaneous UBEs running on the system and to maintain data integrity by controlling which UBEs run
concurrently.
Queues can be configured so that only one UBE jobs can be running at a given time, or so that multiple jobs can
be running at the same time. A common misconception about UBE throughput is the notion that: “We’ll just add
more queues and things will run faster.” However - the number of concurrent UBEs which can be running on a system
is limited by CPUs.
The rule of thumb is one CPU will support 1-2 UBEs.
On newer processors, such as the Power 5 iSeries processor, this could be a bit higher. Refer to the following link
to an IBM whitepaper with UBE benchmark results on a Power5 iSeries processor:
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP100511
For example, if you have a 2 CPU machine, you cannot run 20 concurrent UBEs just because you set up queues
with a max concurrency of 20. That is like saying: “My bank account can’t be overdrawn…I still have more checks.” You
must have the CPU capacity to support the potential number of concurrent UBEs in the queues you have created.
This is often a badly overlooked fact in machine sizing effort leading to unpleasant surprises in real machine
capacity come go-live.
Important: The single biggest limiting factor in sizing an E1 Enterprise server which is most commonly
overlooked is the number of concurrent UBEs.
Multi-CPU machines
Another misconception is in the impact of multi-CPU machines.
Important: A single UBE job will not run any faster on an 8-CPU machine than on a one-CPU machine.
This is because one UBE job (in general) will utilize only one CPU.
Parallelism, concurrency, and multiple CPUs
There are many misconceptions about parallelism, concurrency, and multiple CPUs. A multi-CPU machine is to a
single-CPU machine as a multi-lane road is to a single-lane road. A single car traveling on a multi-lane road cannot
carry any more passengers than when on a single-lane road.
A multi-lane road will allow more of the same cars to travel at the same time.
Important: Software will not run faster on a multi-CPU machine unless you use the CPUs.
Multiple CPUs do not cause a single UBE to run faster; they allow more UBEs to be run simultaneously.
Multi-threaded Queues
The term "multi-threaded queue" is a commonly-used moniker but is inaccurate. UBEs are single-threaded
processes. They are not multi-threaded and neither are UBE queues. The term "threaded" should never be used in
association with UBEs. When the term “multi-threaded queue” is used, it means that more than one UBE job can
be running in the queue at a given time. “Concurrent queue” is a more accurate name.
This spurious naming convention leads to confusion between UBE processing and Business Function processing.
Call Object kernel jobs, starting in Tools Release 8.95 (8.96 on iSeries), are true multi-threaded processes - or
rather they can be configured that way. Multi-threaded call object kernels allow more than one business function to
run in a call object kernel at a time. It does this via threading within the kernel job. This helps eliminate processing
delays which can occur in business functions called from interactive applications.
UBEs processing is completely and totally unrelated to call object kernels. Call Object Kernels are used for running
interactive business functions and do not impact the performance of UBEs in any way, shape, or form. UBEs do
not make use of call object kernels to run Business functions. They call BSFNs in place, within the UBE process.
Note: One common problem in queue design is that short UBEs get stuck in a “single threaded” queue behind a
UBE which takes hours. A solution to this issue is to create dedicated queues for short jobs and other queues for
longer jobs. This allows short running jobs to process quickly and move out of the queue, allowing other jobs to
process.
UBE SUBSYSTEMS
Subsystems were mentioned previously in the context of the MRP parallel processing solution, but Oracle JD
Edwards EnterpriseOne subsystem UBEs in general have different purposes. A subsystem in EnterpriseOne is a
special type of UBE report. The subsystem table F986113 contains the following information:
• Report Name
• Report Version
• Report Interconnect values
The Work with Subsystems application (P986113) is used to start subsystem jobs
A subsystem report, once started, will loop continuously reading records from F986113 until explicitly stopped.
Unlike a non-subsystem UBE, it does not end when the UBE processing ends.
• A new record in F986113 indicates a new subsystem report to be run.
• Subsystems are server only –subsystem job cannot be run on the client.
Subsystem Capabilities within EnterpriseOne
Normal UBE Process UBE Subsystem Process

Flow Flow
Start
Subsystem
Load Specs / Init Is Subsystem is still Active?
Yes No
No- Subsystem
Fetch Next Record From

Subsystem Table (F986113)
-- each record has individual
Run report interconnect values.
Subsystem
No Subsystem
No-
Unload Specs / Free
The advantages of subsystem processing are the following:

Elimination of startup time for small reports.
o Report specs are opened and read and the environment is initialized once only - when the
subsystem process first starts.
o For normal UBEs, this can be a 15-30 second process.
o For small reports, this can be much longer than the processing time of the report itself.
A UBE is a candidate for subsystem processing if:
o It is a very short running job
o It is run many times a day.
o User needs a “one-click” solution to run the report.
Note: Hard-copy reports are commonly implemented as subsystems.

Oracle JD Edwards EnterpriseOne ships subsystem versions of a number of such UBEs. Here are some common
examples – if you are running any of the following UBE, you should consider the possibility of running the
subsystem version:
UBE Version Description

R0007Z1I XJDE0002 Process Inbound Work Day Calendar - Subsystem
R004201 XJDE0002 Authorize Prepayment Transactions Subsystem
R004202 XJDE0002 Settle Prepayment Transactions Subsystem
R00460 XJDE0001 Interoperability Generic Outbound Subsystem UBE
R01010Z ZJDE0002 Batch Address Book Upload - Subsystem
R011110Z ZJDE0002 Contact Information - Subsystem Version
R03010Z ZJDE0002 Customer Master Batch Upload Subsystem Version
R04010Z ZJDE0002 Supplier Master Batch- Subsystem
R04110Z2 ZJDE0002 Voucher Batch Processor Subsystem Version
R09110Z ZJDE0005 Batch Journal Entry Subsystem Version
R09110ZS ZJDE0003 Store & Forward Subsystem Version
R09801 ZJDE0011 G/L Post Subsystem Version
R1201Z1I XJDE0002 Inbound Subsystem Asset Master Processor
R1201Z1O XJDE0002 Outbound Subsystem Asset Master Processor
R30006Z1I ZJDE0002 Process Inbound Work Centers - Subsystem
R3002Z1I ZJDE0002 Process Inbound BOM Transactions - Subsystem
R3003Z1I ZJDE0002 Process Inbound Routing - Subsystem
R30161Z1I XJDE0002 Inbound Kanban Subsystem Transaction
R31113Z1I ZJDE0002 Inbound Inventory Issues Subsystem Version
R31114Z1I XJDE0002 Inbound Completion Processor Subsystem Version
R31122Z1I XJDE0002 Hours & Quantities Inbound Subsystem Version
R31410 XJDE0005 Gen/Print Configured W.O's (Subsystem)
R3411 XJDE0002 Initiate Subsystem Processing
R3411 XJDE0003 Subsystem Message Processing
R3460Z1I XJDE0002 Forecast Transaction Inbound - Subsystem
R37470 ZJDE0002 Test Results Worksheet - Subsystem
R37900 ZJDE0002 Certificate of Analysis Extract - Subsystem
R40211Z ZJDE0002 Batch Transaction Editor in Subsystem
R4101Z1I ZJDE0002 Item Master Unedited Transaction Subsystem
R4210IC ZJDE0001 Create Intercompany Sales Order - Subsystem Mode
R4210Z XJDE0002 Sales Order Batch Trans. Editor - SUBSYSTEM
R42500 ZJDE0003 Batch Ship Confirm - SUBSYSTEM MODE
R42520 RIS0003 Print Pick Slips - Subsystem
R42520 XJDE0006 Print Pick Slips - Subsystem
R42565 XJDE0016 Send Order E-mail - Subsystem
R42565 ZJDE0002 Print Invoice in Subsystem
R42950 ZJDE0005 subsystem submission of Price Cost Update
R42997 XJDE0001 Inventory Commitment - Subsystem
R43092Z1I XJDE0002 Receipt Routing Transactions Inbound - Subsystem
R4311Z1I XJDE0002 Subsystem Inbound Purchase Order Batch
R43500 XJDE0009 Print Purchase Orders- Subsystem Job
R45100 XJDE0002 Assign, Recalculate and Reassign - Subsystem
R46171 XJDE0009 Parallel Processing Subsystem Pick Version
R46171 XJDE0007 Warehouse Subsystem Processing
R47011 XJDE0002 EDI Inbound Purchase Order Edit/Update - Subsystem
R47016ZO XJDE0002 Outbound POE Processor Subsystem
R470412 XJDE0002 EDI Inbound Invoice/Match (Subsystem)
R47071 XJDE0002 EDI Inbound Edit/Update-Subsystem
R47121 XJDE0002 Product Activity Data Edit/Create Subsystem
R47127O XJDE0002 Outbound Prod. Act. Data Subsystem-Update As Sent
R4942Z1I ZJDE0002 Shipment Creation - Subsystem Version
Reports which run in 1-2 minutes have been reduced to 10-20 seconds when the subsystem version is used
Platform Specifics
The following recommendations are specific to the platform that Oracle JD Edwards EnterpriseOne is run on.
iSeries Memory Pools
These are a HUGE factor in UBE performance on the iSeries platform.
Important: You should assign a pool for use by UBEs only. Do not assign any other non-UBE work to this
pool.
See the previous analogy where UBEs are compared to “lap swimmers”, while others jobs continuously jump in
and out of the pool. This is especially true of the memory pool on iSeries.
If the UBE is memory limited, more memory will result in a faster job. If there is a high degree of paging in the
UBE pool exhibited in Work With User Jobs (see the picture below), then the UBE would likely benefit from
increased pool size
UBE jobs want to use about 500K per job – as a guideline. Some jobs will use much more memory than this, some
will use less.
Some actual examples of improvements seen a customer for a memory-constrained UBE include:
With a 1.5 GB UBE pool: 26k records per hour was achieved
With a 3.5 GB UBE pool: 39k records per hour was achieved
Below is another example of how UBE runtime was reduced by increasing the UBE memory pool. This was for a
UBE run with a high degree of concurrency and upwards of 10 concurrent jobs:
6 GB pool: 81 minutes
10 GB pool: 54 minutes
20 GB pool: 20 minutes (Optimal size)
Note
Memory Paging
Pools Stats
CONFIGURATION
Some common “low-hanging fruit” items for gaining throughput from UBEs
Data selection – Reduce the amount of rows processed to prevent a UBE from running many unnecessary
iterations.
Processing Options - are often many and complex. Some UBEs, such as Sales Order Update (R42800), have
upwards of 100 separate options.
One simple setting can add lots of processing to the program.
Review every single one as one of the first steps in diagnosing UBEs which are running more slowly
than desired.
Determine that the UBE is not performing unneeded calculations or excess functionality as a result of
unneeded setting.
It is crucial to know your application thoroughly
Some examples of features which may not be needed:
Advanced Pricing
Advanced Cost Accounting
Advanced Preferences
Flex Accounting
Transportation
Purging and archiving of large transactional tables -- many of the larger tables should have their content
archived to history as often as business needs will allow. Large tables with unneeded historical data lead to longer
search and insert times for these tables.
Some examples:
F4801 – Work Order Master File
R01131P - Purge Completed Tasks UBE
F4211 – Sales Order Entry
F42119 – Sales Order History
F0911 – General Ledger
F0911P – General Ledger History
iSeries SQL packages

A SQL package stores the access plan for a prepared SQL which has been previously executed. The extended
dynamic SQL support allows a prepared SQL statement to be stored on the iSeries system.
SQL packages should be deleted and automatically re-created every two weeks and when:
A major change occurs
Table size changes dramatically
New indexes are added
Packages become corrupt
Note: The appearance of strange SQL errors in the jde.log may be an indication of package corruption.
The SQL optimizer needs to be rerun.

The following are a few additional details regarding iSeries SQL packages.
New indexes will not be used until you delete SQL packages.
Deleted packages will be re-generated by OS/400.
Do not delete packages beginning with “Q”. These are iSeries system packages which will require
IBM assistance to refresh.
Oracle Update Statistics

Oracle statistics should be kept up to date and run regularly. If this is not done, the optimizer can make poor
decisions about which indexes to use. This can have a large impact on performance, especially on long running
UBEs.
In one case, a UBE was running for days but after updating the statistics on the Oracle database, the run
completed in less than one hour.
Queries have been reduced from multiple seconds to a few milliseconds.
So how often is “regularly”? It depends. The more often your data and its composition changes, the more often
statistics should be run. It takes time to run, and it needs proper scheduling.
Each database and each Oracle JD Edwards EnterpriseOne implementation will have different requirements for
updating statistics.
Performance improvements will vary and depend on a wide number of variables including table size, the query
being run, and when statistics were last updated.
Important JDE.INI settings related to UBEs
[DB SYSTEM SETTINGS]

SQL Package Library
This is for iSeries only. If this is set to ‘2’, then you change it to ‘1’ or a ‘0’ for daily use. A value of ‘2’ is only
intended for running Oracle JD Edwards EnterpriseOne table conversion UBEs (TCs). It is common for this to
be overlooked following installations or upgrades. A value of ‘2’ will not cause functional problems, but UBEs will
run more slowly since SQL Packages must be recreated each time a given UBE is run. Slower performance will be
noticed most particularly on shorter-running UBEs. Changing this value requires deleting packages and re-starting
the Oracle JD Edwards EnterpriseOne services.
Here are the meanings and performance implications of the settings in 8.9 and beyond:
• SQL Package Library=2. When TCs need to be run, normal UBEs will run slower since the SQL packages
do not get reused. They will be re-built each time the UBE is run, and are named for the job number (for
example, T123456). Maintenance is required on a recycling of EnterpriseOne Services by deleting SQL
packages using the commands below:
o DLTSQLPKG QRECOVERY/T*
o DLTSQLPKG QRECOVERY/OW*
• SQL Package Library=1. UBE packages will be named “Rnnnnn” and all UBEs will reuse their SQL packages. You
will need to delete any old UBE SQL packages in QRECOVERY using the following command:
o DLTSQLPKG QRECOVERY/R*
Note: No UBEs can be running on the server while the SQL packages are being deleted.
• SQL Package Library=0. Puts Kernel and UBE SQL Packages in the System Library such as E812SYS.
This is especially helpful if one is running multiple instances of EnterpriseOne on one iSeries machine.
Data Close to Processing

When the enterprise server code and the database are on the same machine, better UBE performance often results.
This is less true if both machines are on the same subnet, connected by a high speed connection, and the operating
systems on the two machines are the same.
The key issues:
Important: When the data is far from the machine processing it, network latency due to database I/O is a
factor. Also, when the database server and the processing server are running different operating systems,
translation and middleware overhead between the two unlike systems is often a huge factor.
Slower performance between unlike systems is especially true if one of the machines is an iSeries. The integrated
nature of the DB2 database with the iSeries operating system gives iSeries a particular advantage; the DBMS is not
an application, it is actually part of the operating system. However, if an UBE is run on a Windows machine with
the data residing on iSeries, then this unique advantage is gone, and a large performance penalty will result. The
overhead of the ODBC layer and the QZDASOINIT processing will result in a much longer runtime in the
Windows + iSeries configuration than if both data and processing were on the iSeries.
Please see the diagrams below which depict the iSeries+iSeries and iSeries+Windows scenarios.
It is not recommended to:
• Map BSFNs or UBEs to a Windows server to save CPU cycles on a massive iSeries box.
• Use a large and expensive iSeries box exclusively as a database server.
Other considerations include:
• If the real concern is to reduce the CPU usage on the iSeries machine, then the “Logic on Windows + Data
on iSeries” approach might be a prudent one. However, realize that the UBE in question will run two or three
longer in this configuration.
• The size and CPU capacity of servers, as well as the speed of the link between machines, will determine the
level of degradation.
Important: Most software tends to perform better the fewer resources it requires from remote or different
systems. Configurable Network Computing (CNC) allows data and logic to be distributed, but tradeoffs still exist.
instance
DB2
BSFN call
UBE jdenet_k
Call Object
Kernel
OCM
LOCAL QZDASOINIT – 7 jobs per user
BSFN CALL runs

LOCALLY: ODBC QZDASOINIT jobs:
- memory and
resource intensive
DB I/O across the network
- X-lation overhead of
network via ODBC layer
ODBC LOTS of “chattiness”
One Network roundtrip
for each DB I/O
ODBC
Direct I/O via ER MUST use ODBC -

But there is usually not nearly as much as BSFN-generated I/O
More details on data on iSeries, processing on other platform
Master Business Functions (MBFs) called from within most UBEs are large and can have literally thousands of
database I/O. In fact, most Oracle JD Edwards EnterpriseOne I/O occurs in C business functions.
If the BSFNs are not running on iSeries, then each I/O is a network roundtrip. This leads to a great deal of latency
due to “network chattiness”. There is also the ODBC and QZDASOINIT overhead.
If this BSFNs logic is run on iSeries:
• Thousands of database I/O calls now occur locally to the iSeries via DBDR (for OneWorld XE) or XDA
(Oracle JD Edwards EnterpriseOne 8.9 or higher).
• The XDA and DBDR calls happen via service program APIs called from the UBE job. No extra system jobs
are required, so there is no additional middleware overhead. Also, no ODBC layer and no QZDASOINIT
jobs are involved.
• Network latency is dramatically reduced.
• Memory consumption is dramatically reduced since QZDASOINT jobs are not used.
Note: A UBE runs three times slower in the "Logic on Windows + Data on iSeries" configuration compared to
the configuration where both data and logic reside on the iSeries.
Qaqqini
Some iSeries SQL configuration file settings impact the processing of UBEs such as:
• OPTIMIZATION_GOAL=*ALLIO
This setting works best for long UBEs processing large rowsets.
• OPTIMIZATION_GOAL=*FIRSTIO
This setting will slow down long UBEs, but works best for interactive queries.
UBE LOGGING AND DEBUGGING
Some suggestions to improve performance include changing logging settings.
• DO NOT use a UBE debug setting higher than ‘0’ when generating debug logs for performance analysis
using the Performance Workbench tools.
[UBE]
UBEDebugLevel=0
Values of ‘1’ or greater generate a large amount UBE-specific data without timestamps. This data is not
useful for performance, can skew the timings, and is disk space intensive. Much smaller logs will result if
this setting is greater than zero.
The UBEDebugLevel parameter can also be specified at runtime when launching UBEs via Batch
Versions, eliminating the need to change the server JDE.INI, which affects all other UBEs:
1. Check this box 2. Set this to ‘0’
Same as: Same as:
[DEBUG]
Output=FILE [UBE]
UBEDebugLevel=0
DO use this setting in the server JDE.INI

[DEBUG]
DumpLPDS=0
Setting this to ‘1’ (default) will cause data structures for each BSFN call to be dumped to the debug log at
entry and exit. This data is usually not useful for performance, can skew the timings, and is disk space
intensive. Much smaller logs will result if this setting is = 0
• DO NOT bounce the server after changing the server JDE.INI settings if running a UBE. It is not necessary.
• Each Oracle JD Edwards EnterpriseOne process reads the JDE.INI separately, so a UBE
launched after a JDE.INI change is made will read those changes.
• DO NOT capture a 2 minute log file to troubleshoot a problem with a 2 hour UBE.
• A robust enough sample of the code is needed to determine what’s happening
• See the “Skewed Extrapolations” section.
Important: A debug log is only as good as the use case which is used to generate it.
• DO NOT run a server UBE on the fat client for the purpose of capturing logs. Get a server log.
• Many essential components of UBEs are disabled on the client and work only on the server.
This invalidates the UBE profile in the log. Some examples of functionality which does not work
on the client include the following:
• Buffered Inserts
• JDB Caching via API
• Subsystems
• The data will be across the network if the job is run on the client, leading to much more latency.
• Client side logs contain other threads of execution related to the interactive client which make
the debug log confusing and difficult to read.
• Starting with Oracle JD Edwards EnterpriseOne 8.11, the fat client is no longer a supported
environment for running applications other than the development tools.
• ALWAYS look at jde.log FIRST
• The jde.log is the error log, and is often the source of low-hanging fruit which will save a lot of
time by circumventing a lot of painstaking analysis.
• Example: large numbers of “Duplicate Key INSERT” errors or other SQL failures are
commonly found in failing or poor performing UBEs. This can lead directly to the discovery of
data or configuration problems
Skewed extrapolations
In particular with long running UBEs, the first few minutes of the run are spent in startup and initialization tasks
which are not repeated.
• There may be also a time-consuming data selection query at the start of the run that is not repeated.
• Throughput numbers will often not be accurate if extrapolated from only a few minutes.
• Data caching may also increase the throughput over a period of time.
• In long running UBEs, throughput for hour #2 is often greater than hour #1
It is not recommended to measure the throughput of a UBE until startup overhead is complete:
Begin End
Startup Data UBE Completion (60:00):

(1:00) : Selection Throughput may increase during
- InitEnv (:30) : the first portion of normal UBE
- Load specs Long execution – due data being cached
running
query or
Missing
Index
Startup overhead: Normal UBE processing:
Throughput = Throughput =
0 records per minute!!! 1000 records per minute
…for the first 1:30 …after startup period
In the above example:

• If the throughput was measured after only 2 minutes:
500 records are processed, so the throughput is calculated to be 250 records per minute.
• If the throughput was measured after 60 minutes:
58000 records processed, so the throughput is calculated to be 967 records per minute.
So with a runtime of only 2 minutes, the data sample is dominated by startup overhead.
Important: Use a large enough data sample when measuring UBE throughput
Last but not least: the ‘debug’ factor…

Is debug logging turned on? At least 2-3 times per year, customer UBE issues are caused by debug logging which
has been inadvertently left ON.
[DEBUG]
Output=FILE
;Output=NONE
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
oracle.com
Copyright © 2006, Oracle. All rights reserved.

This document is provided for information purposes only and the
contents hereof are subject to change without notice.
This document is not warranted to be error-free, nor subject to any
other warranties or conditions, whether expressed orally or implied
in law, including implied warranties and conditions of merchantability
or fitness for a particular purpose. We specifically disclaim any
liability with respect to this document and no contractual obligations
are formed either directly or indirectly by this document. This document
may not be reproduced or transmitted in any form or by any means,
electronic or mechanical, for any purpose, without our prior written permission.
Oracle, JD Edwards, PeopleSoft, and Retek are registered trademarks of
Oracle Corporation and/or its affiliates. Other names may be trademarks
of their respective owners.
This document is for informational purposes only and may not be incorporated
into a contract or agreement.

An Oracle JD Edwards Enterpriseone Performance and Tuning Paper 8/2007

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

An Oracle JD Edwards Enterpriseone Performance and Tuning Paper 8/2007

Uploaded by

Copyright:

Available Formats

UBE Performance and Tuning

An Oracle JD Edwards EnterpriseOne

This document provides considerations when reviewing system performance relative to

UBE Performance and Tuning¡ Page i

UBE Performance and Tuning ¡ Page ii

General considerations for long running UBEs

This depends on a number of factors:

R42800 Sales Order Load balancer in Oracle JD Edwards

Pre-Payroll UBE (R07200)

Sales Order Update (R42800)

Material Requirements Planning (R3482 / R3483)

Troubleshooting tips for MRP Performance issues:

Parallelism, concurrency, and multiple CPUs

Subsystem Capabilities within EnterpriseOne

Normal UBE Process UBE Subsystem Process

Fetch Next Record From

Unload Specs / Free

The advantages of subsystem processing are the following:

Note: Hard-copy reports are commonly implemented as subsystems.

UBE Version Description

iSeries Memory Pools

These are a HUGE factor in UBE performance on the iSeries platform.

iSeries SQL packages

 The SQL optimizer needs to be rerun.

Oracle Update Statistics

Important JDE.INI settings related to UBEs

[DB SYSTEM SETTINGS]

Data Close to Processing

The key issues:

LOCAL QZDASOINIT – 7 jobs per user

BSFN CALL runs

Direct I/O via ER MUST use ODBC -

More details on data on iSeries, processing on other platform

DO use this setting in the server JDE.INI

Startup Data UBE Completion (60:00):

In the above example:

Last but not least: the ‘debug’ factor…

Copyright © 2006, Oracle. All rights reserved.

You might also like

The SQL optimizer needs to be rerun.