Ebsom Dbim PDF

A Case Study of Using Oracle
Database In-Memory with Oracle

EBS Order Management
ORACLE WHITE PAPER | JULY 2015
1 | A CASE STUDY OF USING ORACLE DATABASE IN-MEMORY WITH ORACLE EBS ORDER MANAGEMENT
Table of Contents
Introduction.......................................................................................................................................................................................... 3
Setting up Database In-Memory for E-business suite.......................................................................................................................... 3
Order Management Use cases:............................................................................................................................................................. 3
Query from Order Organizer:...........................................................................................................................................................3
Observation:................................................................................................................................................................................. 6
Initialize Credit Summaries Table:...................................................................................................................................................6
Observation:................................................................................................................................................................................. 9
Order Import:................................................................................................................................................................................... 9
Observation:............................................................................................................................................................................... 13
2 | A CASE STUDY OF USING ORACLE DATABASE IN-MEMORY WITH ORACLE EBS ORDER MANAGEMENT
Introduction
The purpose of this white paper is to publish the results from various test cases performed on certain Order management use
cases after enabling In-Memory column store feature of Oracle database 12C. Three performance intensive use cases have been
selected for this case study and numerous tests have been performed by changing the data that is loaded into In-Memory column
store, keeping all other database parameters constant. This paper publishes the results of those tests and also provides
recommendations about what data needs to be loaded into In-Memory.
Setting up Database In-Memory for E-business suite.

For comprehensive overview of Oracle In-Memory column store feature, refer toOracle Database In-Memory white paper.
For recommendations and guidelines for effective use of Oracle Database In-Memory options with E-Business suite, please refer
to the Using Oracle Database In-Memory with Oracle E-Business Suite (2025309.1) white paper.
Order Management Use cases:

All of the use cases discussed in this document have been performed with 1 million order lines in oe_order_lines_all table.
Query from Order Organizer:

The Order Organizer enables you to manage existing orders and returns in yoursystem. When you open the Order Organizer, the
Find window is displayed. It enables you to enter search criteria to locate an order or a group of orders. For example, you could
find your recent orders, orders past their requested shipment date, orders on a particular hold, or orders for an important customer.
The Find window has the following tabs: Quote/Order Information, Line Information, Advanced, Holds
Information, Scheduling. The fields in these tabs enable you to enter or selectvalues which are used as the criteria for finding and
displaying orders.
As is evident, these forms are exceptionally flexible, with several tabs as well as a huge number of fields that can be queried either
individually or collectively. While this degree of flexibility enables easy mapping to business functions, it will typically result in
performance issues if a user only queries a non-indexed column, or a column with poor selectivity. If the Order Organizer is always
used and queried in a particular way, associated indexes could be added. However, as mentioned earlier, adding indexes for
every queryable field to allow the maximum functionality is inadvisable due to the maintenance overhead. While it may speed up
queries in this form, it could have a significant negative impact on associated processes.
Having some fields indexed and others not may be perceived as inconsistent response times by users without the knowledge of
the underlying schema. A very common problem that we see is a user report that says “The system is slow today”. It may well be
the case that they actually ran a different set of queries using different combinations of fields, some of which are indexed and
some that are not. This is one of the main issues when an Oracle E-Business Suite user reports that the Order Organizer Find
Window occasionally “freezes”.
3| A CASE STUDY OF USING ORACLE DATABASE IN-MEMORY WITH ORACLE EBS ORDER MANAGEMENT
For the current use case we have chosen one such attribute “Shipment Priority(shipment_priority_code)” which is not an indexed
column in oe_order_lines_all table.
Baseline Run(with no tables or columns loaded into in-memory):
This run was performed without loading any tables/columns into in-memory.Total time taken by order organizer to query orders
based on shipment priority was 166.85 seconds and top most query took 142.04 seconds.
SELECT HEADER_ID
FROM
OE_ORDER_HEADERS OE_ORDER_HEADERS_V WHERE EXISTS (SELECT 'X' FROM
OE_ORDER_LINES OE_ORDER_LINES_V WHERE ( OE_ORDER_LINES_V.HEADER_ID=
OE_ORDER_HEADERS_V.HEADER_ID AND SHIPMENT_PRIORITY_CODE=
:SHIPMENT_PRIORITY_CODE))
call count cpu elapsed disk query current rows

------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.02 0.02 0 0 0 0
Execute 1 0.02 0.01 0 0 0 0
Fetch 9 1.46 142.00 35717 259595 0 8
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 11 1.50 142.04 35717 259595 0 8
Misses in library cache during parse: 1

Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 65 (recursive depth: 1)
Rows Row Source Operation

------- ---------------------------------------------------
8 HASH JOIN SEMI (cr=259595 pr=35717 pw=0 time=92635097 us cost=21973 size=16569 card=789)
8 NESTED LOOPS SEMI (cr=259595 pr=35717 pw=0 time=92635080 us cost=21973 size=16569 card=789)
49992 STATISTICS COLLECTOR (cr=2270 pr=0 pw=0 time=218018 us)
49992 TABLE ACCESS FULL OE_ORDER_HEADERS_ALL (cr=2270 pr=0 pw=0 time=233948 us cost=632 size=41630 card=4163)
8 TABLE ACCESS BY INDEX ROWID BATCHED OE_ORDER_LINES_ALL (cr=257325 pr=35717 pw=0 time=141720200 us cost=9 size=1650
card=150)
860650 INDEX RANGE SCAN OE_ORDER_LINES_N1 (cr=93730 pr=5136 pw=0 time=21434917 us cost=2 size=0 card=25)(object id 68084)
0 TABLE ACCESS FULL OE_ORDER_LINES_ALL (cr=0 pr=0 pw=0 time=0 us cost=9 size=1650 card=150)
In-Memory run with oe_order_lines_all and oe_order_headers_all loaded completely into in-memory
This run was performed after loading both oe_order_lines_all and oe_order_headers_all tables completely into in-memory. Total
time taken by order organizer to query orders based on shipment priority was3.86 seconds and top most query took 3.23
seconds.
SELECT HEADER_ID
FROM

------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 9 3.22 3.23 0 713878 0 8
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 11 3.22 3.23 0 713878 0 8


------- ---------------------------------------------------
8 HASH JOIN RIGHT SEMI (cr=713878 pr=0 pw=0 time=3235044 us cost=5952 size=16569 card=789)
32 JOIN FILTER CREATE :BF0000 (cr=713875 pr=0 pw=0 time=111199 us cost=5887 size=8734 card=794)
32 TABLE ACCESS IN-MEMORY FULL OE_ORDER_LINES_ALL (cr=713875 pr=0 pw=0 time=111053 us cost=5887 size=8734 card=794)
8 JOIN FILTER USE :BF0000 (cr=3 pr=0 pw=0 time=1050 us cost=65 size=41630 card=4163)
8 TABLE ACCESS IN-MEMORY FULL OE_ORDER_HEADERS_ALL (cr=3 pr=0 pw=0 time=1033 us cost=65 size=41630 card=4163)
In-Memory run with 4 columns of oe_order_lines_all and full oe_order_headers_all loaded into
in-memory
This run was performed after loading 4 columns (Line_id, header_id, org_id and shipment_priority_code) of oe_order_lines_all
table, and complete oe_order_headers_all table into in-memory.Line_id from oe_order_lines_all has been loaded since it is the
primary key of oe_order_lines_all table and will help improve performance. Total time taken by order organizer to query orders
based on shipment priority was 0.67 seconds and top most query took 0 seconds.
SELECT HEADER_ID
FROM

------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 9 0.00 0.00 0 24 0 8
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 11 0.00 0.00 0 24 0 8


------- ---------------------------------------------------
In-Memory run with 4 columns of oe_order_lines_all and 2 columns of oe_order_headers_all (only
where clause columns) into in-memory.
This run was performed after loading 4 columns(Line_id, header_id, org_id and shipment_priority_code) from oe_order_lines_all
table, which are part of where clause and 2 columns(Header_id and org_id) from oe_order_headers_all, which are part of where
clause into in-memory Total time taken by order organizer to query orders based on shipment priority was0.77 seconds and top
most query took 0.05 seconds.
SELECT HEADER_ID
FROM

------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.02 0.02 0 0 0 0
Execute 1 0.01 0.02 0 2 0 0
Fetch 9 0.00 0.00 0 24 0 8
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 11 0.03 0.05 0 26 0 8


------- ---------------------------------------------------
Observation:
Based on the above test case results we see that minimum time was taken by order organizer whenoe_order_headers_all is loaded
completely into in-memory and where clause columns from oe_order_lines_all are loaded into in-memory (.67 seconds). However
time taken was almost same (.77seconds) when only where clause columns from bothoe_order_lines_all and oe_order_headers_all
tables are loaded into in-memory. Since the difference in time is minimal and since loading just two columns from
oe_order_headers_all into in-memory consumes much less in-memory space compared to loading completeoe_order_headers_all
into in-memory, it is recommended to load only where clause columns into in-memory. If space is not a constraint, then full
oe_order_headers_all table can be loaded as well.
Initialize Credit Summaries Table:

Order Management enables you to periodically rebuild a credit exposure image (orders, invoices and payments) for all
customers or customer sites for all possible credit rule definitions. When you submit the Initialize Credit Summaries Table
concurrent program, changes to customer or customer site credit exposure are calculated and updated, based upon your
exposure setup for each credit check rule defined. Exposure information is stored in a summary table so that the credit
check process can refer to summary credit data as opposed to real time transactional data, reducing the effort needed to
evaluate credit standing.
Since this program gathers and manipulates data across various entities, it is prone to performance issues, the intensity of
which depends on data volumes in each system.
Baseline Run: With no tables loaded into in-memory:
This run was performed without loading any tables/columns into in-memory.Total time taken by the program was 1877.17
seconds and top most query took 792.75 seconds.
INSERT INTO OE_INIT_CREDIT_SUMM_GTT (LINE_ORDERED_QUANTITY ,

LINE_UNIT_SELLING_PRICE, ORDER_INVOICE_TO_ORG_ID, RL_AMOUNT,
RL_QUANTITY_ORDERED, ORDER_ORG_ID , ORDER_TRANSACTIONAL_CURR_CODE,
LINE_SCHEDULE_SHIP_DATE , LINE_REQUEST_DATE , ORDER_REQUEST_DATE,
.
.
FROM OE_ORDER_LINES_ALL L , OE_ORDER_HEADERS_ALL
H , HZ_CUST_SITE_USES_ALL SU , HZ_CUST_ACCT_SITES_ALL S , HZ_CUST_ACCOUNTS
CA , HZ_CUST_SITE_USES_ALL SU_L , HZ_CUST_ACCT_SITES_ALL S_L ,
HZ_CUST_ACCOUNTS CA_L , RA_INTERFACE_LINES_ALL RL WHERE H.HEADER_ID =
L.HEADER_ID AND H.BOOKED_FLAG = 'Y' AND RL.ORIG_SYSTEM_BILL_CUSTOMER_ID =
CA.CUST_ACCOUNT_ID AND NVL(RL.INTERFACE_STATUS, '~') <> 'P' AND
RL.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND RL.INTERFACE_LINE_ATTRIBUTE1 =
H.ORDER_NUMBER AND NVL( L.INVOICED_QUANTITY, 0 ) <> 0 AND SU.SITE_USE_ID =
H.INVOICE_TO_ORG_ID AND SU.CUST_ACCT_SITE_ID = S.CUST_ACCT_SITE_ID AND
CA.CUST_ACCOUNT_ID = S.CUST_ACCOUNT_ID AND SU_L.SITE_USE_ID =
L.INVOICE_TO_ORG_ID AND SU_L.CUST_ACCT_SITE_ID = S_L.CUST_ACCT_SITE_ID AND
CA_L.CUST_ACCOUNT_ID = S_L.CUST_ACCOUNT_ID AND EXISTS ( SELECT /*+
no_unnest */ NULL FROM OE_PAYMENT_TYPES_ALL T WHERE T.CREDIT_CHECK_FLAG =
'Y' AND NVL(T.ORG_ID,-99) = NVL(H.ORG_ID, -99) AND L.PAYMENT_TYPE_CODE IS
NOT NULL AND T.PAYMENT_TYPE_CODE = L.PAYMENT_TYPE_CODE UNION ALL SELECT /*+
NULL AND H.PAYMENT_TYPE_CODE IS NOT NULL AND T.PAYMENT_TYPE_CODE =
H.PAYMENT_TYPE_CODE UNION ALL SELECT /*+ no_unnest */ NULL FROM
OE_PAYMENT_TYPES_ALL T WHERE T.CREDIT_CHECK_FLAG = 'Y' AND NVL(T.ORG_ID,-99)
= NVL(H.ORG_ID, -99) AND L.PAYMENT_TYPE_CODE IS NULL AND
H.PAYMENT_TYPE_CODE IS NULL )

------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.05 0.05 0 7 0 0
Execute 1 178.80 792.69 735598 10159275 55323 618396
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 2 178.86 792.75 735598 10159282 55323 618396
In-memory run with full tables loaded into in-memory:
This run has been performed by loading the tables ONT.OE_PAYMENTS,ONT.OE_PRICE_ADJUSTMENTS

ONT.OE_ORDER_LINES_ALL ONT.OE_PAYMENT_TYPES_ALL , ONT.OE_ORDER_HEADERS_ALL ,
AR.HZ_CUST_SITE_USES_ALL , AR.HZ_CUST_ACCT_SITES_ALL ,AR.HZ_CUST_ACCOUNTS
,AR.RA_INTERFACE_LINES_ALL completely into in-memory. Total time taken by the program was 533.94 seconds and top most
query took 186.01 seconds.
.
.

------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.08 0.08 0 7 1 0
Execute 1 185.93 186.15 0 8490803 55347 618396
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 2 186.01 186.24 0 8490810 55348 618396
In-memory run with columns loaded into in-memory:

This run has been performed after loading the following columns into in-memory.Total time taken by the program was 446.27
seconds and top most query took 175.59 seconds.
OE_PAYMENTS COMMITMENT_APPLIED_AMOUNT,HEADER_ID,LINE_ID
OE_PRICE_ADJUSTMENTS CREDIT_OR_CHARGE_FLAG,ARITHMETIC_OPERATOR,OPERAND,APPLIED_FLAG,
HEADER_ID,LINE_ID,PRICE_ADJUSTMENT_ID,ADJUSTED_AMOUNT,PARENT_ADJ
USTMENT_ID, LIST_LINE_TYPE_CODE
OE_ORDER_LINES_ALL ORDERED_QUANTITY,UNIT_SELLING_PRICE,SCHEDULE_SHIP_DATE,REQUEST_D
ATE,TAX_LINE_VALUE,TAX_VALUE,shipment_priority_code,INVOICE_TO_ORG_ID,LI
NE_CATEGORY_CODE,INVOICED_QUANTITY,PAYMENT_TYPE_CODE,LINE_ID,HE
ADER_ID,ORG_ID,OPEN_FLAG,CHARGE_PERIODICITY_CODE,CANCELLED_FLAG
OE_PAYMENT_TYPES_ALL ORG_ID,PAYMENT_TYPE_CODE,CREDIT_CHECK_FLAG
OE_ORDER_HEADERS_ALL INVOICE_TO_ORG_ID,HEADER_ID,BOOKED_FLAG,ORDER_NUMBER,ORG_ID,PAY
MENT_TYPE_CODE,TRANSACTIONAL_CURR_CODE,REQUEST_DATE,CREATION_D
ATE,ORDER_CATEGORY_CODE
HZ_CUST_SITE_USES_ALL SITE_USE_ID,CUST_ACCT_SITE_ID
HZ_CUST_ACCT_SITES_ALL CUST_ACCOUNT_ID,CUST_ACCT_SITE_ID
HZ_CUST_ACCOUNTS PARTY_ID,CUST_ACCOUNT_ID, ORG_ID
RA_INTERFACE_LINES_ALL ORIG_SYSTEM_BILL_CUSTOMER_ID,INTERFACE_STATUS,INTERFACE_LINE_CON
TEXT,INTERFACE_LINE_ATTRIBUTE1,INTERFACE_LINE_ATTRIBUTE6,QUANTITY_
ORDERED,AMOUNT,INTERFACE_LINE_ATTRIBUTE11
.
.

------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.10 0.10 0 7 0 0
Execute 1 175.30 175.48 0 4847491 55258 618397
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 2 175.41 175.59 0 4847498 55258 618397
Observation:
For initialize credit summaries program, loading just columns used in where and select clauses from the tables involved
proved to be more performance friendly that loading full tables into in-memory. So it is recommended to load only
columns into in-memory instead of full tables.
Order Import:
Order Import is an Order Management Open Interface that consists of open interface tables and a set of APIs. Order
Import can import new, changed, and completed sales orders or returns from other applications such as a legacy system.
The orders may come from any source such as EDI transactions that are processed by the Oracle e-Commerce
Gateway or internal orders created for internal requisitions developed in Oracle Purchasing or returns. Order Import
features include validation and defaulting, processing constraint checks, applying and releasing of order holds, scheduling
of shipments, then ultimately inserting, updating or deleting the orders in the base Order Management tables. Order
Management checks all the data during the import process to ensure its validity within Order Management. Valid
transactions are then converted into orders with lines, reservations, price adjustments, and sales credits in the base Order
Management tables. Most customers import huge volumes of data using this program and if lots of orders are being
imported, this program can take a lot of time to complete. We have seen lot of issues till date where customer reported that
Order Import program takes more than 10 hours to complete.
In the current case study Order Import has been run to import 10000 lines.
Baseline Run: With no tables loaded into in-memory:

This run was performed without loading any tables/columns into in-memory.Total time taken by Order Import program to import
10000 lines is 2131.35 seconds and top most query took 311.51 seconds.
SELECT 'N'
FROM
OE_ORDER_LINES L WHERE L.LINE_NUMBER = :B3 AND L.HEADER_ID = :B2 AND
L.LINE_ID <> :B1 AND ( L.ITEM_TYPE_CODE = 'STANDARD' OR (
L.TOP_MODEL_LINE_ID = L.LINE_ID AND L.ITEM_TYPE_CODE = 'MODEL'))

------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 20000 1.10 1.06 0 0 0 0
Fetch 20000 307.43 310.45 9 223289050 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 40001 308.54 311.51 9 223289050 0 0

Number of plan statistics captured: 6
Rows (1st) Rows (avg) Rows (max) Row Source Operation

---------- ---------- ---------- ---------------------------------------------------
0 0 0 TABLE ACCESS BY INDEX ROWID BATCHED OE_ORDER_LINES_ALL (cr=11152 pr=0 pw=0 time=18961 us cost=11
size=30 card=1)
10000 10000 10000 INDEX RANGE SCAN OE_ORDER_LINES_N1 (cr=40 pr=0 pw=0 time=16631 us cost=3 size=0 card=25)(object
id 68084)
In-memory run with oe_order_lines_all table loaded into in-memory:

This run has been performed after loading oe_order_lines_all table completely into in-memory. We expected that doing so will
reduce the time taken by above query considerably if optimizer goes for in-memory scan onoe_order_lines_all table instead of
index range scan. However even after loading the table completely into in-memory optimizer preferred index range scan over in-
memory scan and the time taken by top most query came down from 311.51 seconds to 298.28 seconds, which is not necessarily
due to in-memory. Also, total time taken by order import to import 10000 lines was2567.12, which is higher than that of the
baseline run.
SELECT 'N'
FROM

------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 20000 1.14 1.01 0 1 0 0
Fetch 20000 297.14 297.26 0 222900000 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 40001 298.29 298.28 0 222900001 0 0


---------- ---------- ---------- ---------------------------------------------------
size=30 card=1)
id 68084)
In-Memory run with 47 tables loaded completely into in-memory:

From the order import trace file we have seen that there are lot of update statements, which in-fact select from other tables before
inserting data. We were under the impression that loading the tables involved in such select statements into in-memory will reduce
the time taken to select and hence reduce the overall time taken by the DMLs as well. We identified 47 such tables and loaded all
of those into in-memory. Following tables were loaded completely into in-memory:
APPLSYS.AD_EVENTS
APPLSYS.AD_EVENT_VERSIONS
APPLSYS.FND_LANGUAGES
APPLSYS.FND_LOOKUP_TYPES
AR.HZ_CUST_ACCOUNT_ROLES
AR.HZ_CUST_ACCT_SITES_ALL
AR.HZ_CUST_SITE_USES_ALL
AR.HZ_LOCATIONS
AR.HZ_PARTIES
AR.HZ_PARTY_SITES
AR.HZ_RELATIONSHIPS
AR.HZ_ROLE_RESPONSIBILITY
MRP.MRP_ATP_SCHEDULE_TEMP
INV.MTL_DEFAULT_CATEGORY_SETS
INV.MTL_INTERORG_SHIP_METHODS
INV.MTL_ITEM_CATEGORIES
INV.MTL_PARAMETERS
INV.MTL_RESERVATIONS
ONT.OE_ACTIONS_IFACE_ALL
ONT.OE_AK_OBJECTS_EXT
ONT.OE_CREDITS_IFACE_ALL
ONT.OE_HOLD_DEFINITIONS
ONT.OE_ITEM_ORDERABILITY
ONT.OE_ITEM_ORDERABILITY_RULES
ONT.OE_LOTSERIALS_IFACE_ALL
ONT.OE_PC_ASSIGNMENTS
ONT.OE_PC_CONDITIONS
ONT.OE_PC_CONSTRAINTS
ONT.OE_PRICE_ADJS_IFACE_ALL
ONT.OE_PRICE_ADJUSTMENTS
ONT.OE_PRICE_ATTS_IFACE_ALL
ONT.OE_PROCESSING_MSGS_TL
ONT.OE_SETS
ONT.OE_TRANSACTION_TYPES_ALL
PO.PO_REQUISITION_HEADERS_ALL
PO.PO_REQUISITION_LINES_ALL
AR.RA_RULES
APPLSYS.WF_ACTIVITIES
APPLSYS.WF_ACTIVITY_TRANSITIONS
APPLSYS.WF_ITEM_ACTIVITY_STATUSES
APPLSYS.WF_ITEM_ATTRIBUTE_VALUES
APPLSYS.WF_PROCESS_ACTIVITIES
APPLSYS.WF_RESOURCES
WSH.WSH_DELIVERY_DETAILS
WSH.WSH_REGIONS
WSH.WSH_REGION_LOCATIONS
WSH.WSH_ZONE_REGIONS
After the tables are loaded into in-memory total time taken by Order Import program to import 10000 lines was3170.99 seconds
and top most query took 326.46 seconds. This performance degradation is likely due to limited system resources to
accommodate a large number of table rows and columns stored in-memory.
SELECT 'N'
FROM

------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 20000 0.97 1.11 0 1 0 0
Fetch 20000 321.00 325.36 0 222940000 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 40001 321.97 326.47 0 222940001 0 0


---------- ---------- ---------- ---------------------------------------------------
size=30 card=1)
id 68084)
It should also be noted that one particular query which took 2.72 seconds in baseline run took 134.76 seconds after
loading tables into in-memory
Baseline Query:
INSERT INTO MSC_REGIONS_TEMP (SESSION_ID, PARTNER_SITE_ID, REGION_ID,

REGION_TYPE, ZONE_FLAG, PARTNER_TYPE) SELECT DISTINCT :B5 , :B3 ,
A.REGION_ID, A.ZONE_LEVEL, :B6 , :B4 FROM WSH_REGIONS A, WSH_ZONE_REGIONS B,
MSC_REGIONS_TEMP C WHERE A.REGION_ID = B.PARENT_REGION_ID AND
A.REGION_TYPE = 10 AND A.ZONE_LEVEL IS NOT NULL AND B.REGION_ID =
C.REGION_ID AND C.SESSION_ID = :B5 AND C.PARTNER_SITE_ID = DECODE(:B1 , :B4
, :B3 , :B2 ) AND C.PARTNER_TYPE = :B1

------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 10000 2.58 2.72 0 120016 0 0
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 10001 2.58 2.72 0 120016 0 0
---------- ---------- ---------- ---------------------------------------------------
0 0 0 LOAD TABLE CONVENTIONAL MSC_REGIONS_TEMP (cr=12 pr=0 pw=0 time=241 us)
0 0 0 HASH UNIQUE (cr=12 pr=0 pw=0 time=229 us cost=6 size=35 card=1)
0 0 0 HASH JOIN SEMI (cr=12 pr=0 pw=0 time=161 us cost=5 size=35 card=1)
0 0 0 NESTED LOOPS SEMI (cr=12 pr=0 pw=0 time=151 us cost=5 size=35 card=1)
5 5 5 STATISTICS COLLECTOR (cr=5 pr=0 pw=0 time=88 us)
5 5 5 MERGE JOIN CARTESIAN (cr=5 pr=0 pw=0 time=72 us cost=4 size=27 card=1)
1 1 1 INDEX RANGE SCAN MSC_REGIONS_TEMP_U1 (cr=3 pr=0 pw=0 time=17 us cost=3 size=17
card=1)(object id 887175)
5 5 5 BUFFER SORT (cr=2 pr=0 pw=0 time=44 us cost=1 size=50 card=5)
5 5 5 TABLE ACCESS BY INDEX ROWID BATCHED WSH_REGIONS (cr=2 pr=0 pw=0 time=35 us cost=1 size=50
card=5)
5 5 5 INDEX RANGE SCAN WSH_REGIONS_N2 (cr=1 pr=0 pw=0 time=14 us cost=0 size=0 card=5)(object
id 68672)
0 0 0 INDEX RANGE SCAN WSH_ZONE_REGIONS_N1 (cr=7 pr=0 pw=0 time=31 us cost=1 size=9472
0 0 0 INDEX FULL SCAN WSH_ZONE_REGIONS_N1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=9472
********************************************************************************
In-Memory Run:
INSERT INTO MSC_REGIONS_TEMP (SESSION_ID, PARTNER_SITE_ID, REGION_ID,

REGION_TYPE, ZONE_FLAG, PARTNER_TYPE) SELECT DISTINCT :B5 , :B3 ,
A.REGION_ID, A.ZONE_LEVEL, :B6 , :B4 FROM WSH_REGIONS A, WSH_ZONE_REGIONS B,
MSC_REGIONS_TEMP C WHERE A.REGION_ID = B.PARENT_REGION_ID AND
A.REGION_TYPE = 10 AND A.ZONE_LEVEL IS NOT NULL AND B.REGION_ID =
C.REGION_ID AND C.SESSION_ID = :B5 AND C.PARTNER_SITE_ID = DECODE(:B1 , :B4
, :B3 , :B2 ) AND C.PARTNER_TYPE = :B1

------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 10000 134.26 134.76 13 10480003 0 0
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 10001 134.26 134.76 13 10480003 0 0

---------- ---------- ---------- ---------------------------------------------------
0 0 0 LOAD TABLE CONVENTIONAL MSC_REGIONS_TEMP (cr=1048 pr=4 pw=0 time=67141 us)
0 0 0 HASH UNIQUE (cr=1048 pr=4 pw=0 time=67126 us cost=7 size=35 card=1)
0 0 0 NESTED LOOPS (cr=1048 pr=4 pw=0 time=67033 us cost=6 size=35 card=1)
1027 1027 1027 HASH JOIN (cr=17 pr=3 pw=0 time=13734 us cost=5 size=25 card=1)
1 1 1 STATISTICS COLLECTOR (cr=3 pr=0 pw=0 time=28 us)
1 1 1 INDEX RANGE SCAN MSC_REGIONS_TEMP_U1 (cr=3 pr=0 pw=0 time=14 us cost=3 size=17
1027 1027 1027 TABLE ACCESS BY INDEX ROWID BATCHED WSH_ZONE_REGIONS (cr=14 pr=3 pw=0 time=7460 us cost=2
size=64 card=8)
1027 1027 1027 INDEX RANGE SCAN WSH_ZONE_REGIONS_N2 (cr=4 pr=0 pw=0 time=1224 us cost=1 size=0
0 0 0 TABLE ACCESS IN-MEMORY FULL WSH_ZONE_REGIONS (cr=0 pr=0 pw=0 time=0 us cost=2 size=64
card=8)
1027 1027 1027 INDEX UNIQUE SCAN WSH_REGIONS_U1 (cr=4 pr=0 pw=0 time=3744 us cost=0 size=0 card=1)(object
id 68673)
0 0 0 TABLE ACCESS BY INDEX ROWID WSH_REGIONS (cr=1027 pr=1 pw=0 time=26669 us cost=1 size=10
card=1)
Observation:
It is not recommended to go for in-memory column store for Order Import. Order Import performs lots of row by row
processing and in cases where row by row processing is predominant loading tables/columns into in-memory column store
does not prove to be beneficial.
Orac
Worldwide Inquiries
Phone: +1.650.506.7000
Fax: +1.650.506.7200
Corporation, World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065, USA
Copyright © 2015, Oracle and/or its affiliates. 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 and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and
are trademarks or registered trademarks of SPARC International, Inc. AMD,Opteron, the AMD logo, and the AMD Opteron logo are
trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registeerd trademark of The Open Group.0115
A case study of using Oracle database In-Memory with Oracle EBS Order Management
July 2015
Authors: Suneela Pothula
Contributing Authors: Rakesh Moharana, Srecko Bartl
CONNECT WITH US
blogs.oracle.com/oracle
facebook.com/oracle
twitter.com/oracle
oracle.com

Ebsom Dbim PDF

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

Ebsom Dbim PDF

Uploaded by

Copyright:

Available Formats

A Case Study of Using Oracle

Database In-Memory with Oracle

Setting up Database In-Memory for E-business suite.

Order Management Use cases:

Query from Order Organizer:

Baseline Run(with no tables or columns loaded into in-memory):

call count cpu elapsed disk query current rows

Misses in library cache during parse: 1

Rows Row Source Operation

call count cpu elapsed disk query current rows

Misses in library cache during parse: 0

Rows Row Source Operation

call count cpu elapsed disk query current rows

Misses in library cache during parse: 0

Rows Row Source Operation

call count cpu elapsed disk query current rows

Misses in library cache during parse: 1

Rows Row Source Operation

Initialize Credit Summaries Table:

INSERT INTO OE_INIT_CREDIT_SUMM_GTT (LINE_ORDERED_QUANTITY ,

call count cpu elapsed disk query current rows

In-memory run with full tables loaded into in-memory:

This run has been performed by loading the tables ONT.OE_PAYMENTS,ONT.OE_PRICE_ADJUSTMENTS

call count cpu elapsed disk query current rows

In-memory run with columns loaded into in-memory:

HZ_CUST_ACCOUNTS PARTY_ID,CUST_ACCOUNT_ID, ORG_ID

call count cpu elapsed disk query current rows

Baseline Run: With no tables loaded into in-memory:

call count cpu elapsed disk query current rows

Misses in library cache during parse: 0

Rows (1st) Rows (avg) Rows (max) Row Source Operation

In-memory run with oe_order_lines_all table loaded into in-memory:

call count cpu elapsed disk query current rows

Misses in library cache during parse: 1

Rows (1st) Rows (avg) Rows (max) Row Source Operation

In-Memory run with 47 tables loaded completely into in-memory:

call count cpu elapsed disk query current rows

Misses in library cache during parse: 1

Rows (1st) Rows (avg) Rows (max) Row Source Operation

INSERT INTO MSC_REGIONS_TEMP (SESSION_ID, PARTNER_SITE_ID, REGION_ID,

call count cpu elapsed disk query current rows

INSERT INTO MSC_REGIONS_TEMP (SESSION_ID, PARTNER_SITE_ID, REGION_ID,

call count cpu elapsed disk query current rows

Rows (1st) Rows (avg) Rows (max) Row Source Operation

Redwood Shores, CA 94065, USA

You might also like