Otbi and bicc_psr_technote_v3_final_document

Oracle Fusion
Transactional Business
Intelligence and BI Cloud
Connector Performance
Recommendations
An Oracle White Paper, 3rd Edition
January 5, 2021 | Version 3.0
Copyright © 2021, Oracle and/or its affiliates
Confidential – Public

2 WHITE PAPER | Oracle Fusion Transactional Business Intelligence and BI Cloud Connector Performance Recommendations | Version 3.0
Copyright © 2021, Oracle and/or its affiliates | Confidential – Public
PURPOSE STATEMENT
This document covers performance topics and best practices for Oracle Transactional Business Intelligence (OTBI) and Business
Intelligence Cloud Connector (BICC) for Fusion Applications Release 20A and higher. Most of the recommendations are generic for
OTBI and BICC contents as well as Oracle Business Intelligence Enterprise Edition (OBIEE) technology stack. Release specific topics
will refer to exact version numbers20A and higher. Most of the recommendations are generic for OTBI and BICC contents as well as
Oracle Business Intelligence Enterprise Edition (OBIEE) technology stack. Release specific topics will refer to exact version numbers
Note: The document is intended for BI system integrators, BI report developers and administrators. It covers advanced performance
tuning techniques in OTBI, BICC, OBIEE and Oracle RDBMS. All recommendations must be carefully verified in a test environment
before applied to a production instance.
DISCLAIMER
This document in any form, software or printed matter, contains proprietary information that is the exclusive property of Oracle.
Your access to and use of this confidential material is subject to the terms and conditions of your Oracle software license and service
agreement, which has been executed and with which you agree to comply. This document and information contained herein may not
be disclosed, copied, reproduced or distributed to anyone outside Oracle without prior written consent of Oracle. This document is
not part of your license agreement nor can it be incorporated into any contractual agreement with Oracle or its subsidiaries or
affiliates.
This document is for informational purposes only and is intended solely to assist you in planning for the implementation and upgrade
of the product features described. 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 in this document
remains at the sole discretion of Oracle.
Due to the nature of the product architecture, it may not be possible to safely include all features described in this document without
risking significant destabilization of the code.

TABLE OF CONTENTS
Purpose Statement 2
Disclaimer 2
Introduction 5
Logical SQL Concepts 5
Understanding OTBI Query Execution 5
OTBI and BICC Performance Monitoring and Diagnostics 6
OBIEE Usage Tracking for OTBI and BICC Monitoring 6
Query Log Analysis 6
Guidelines for Analyzing Reports Performance 10
Best Practices for OTBI Dashboards and Reports Design 11
Dashboard Design Recommendations 11
Dashboard Design: Best Practices 11
Dashboard Prompts Recommendations 11
Choice of Logical Entities in Prompts 11
Use Default Prompt Values 12
Logical Aggregate Functions in Prompt Filters 13
Use ‘Calendar’ Inputs in Date Prompts 13
Use Text Field in Prompts 14
Use of Lookup Tables vs. Dimensions in Prompts 17
“OTBI HCM Prompts” Subject Area for Manager Prompts 17
Report Design Recommendations 17
Use Restrictive Filters to Constrain Result Set 17
Use Indexed Logical Attributes in Logical Joins and Filters 18
Eliminate Duplicate and Redundant Filters in Logical SQLs 18
Avoid Fetching Very Large Volumes from Database to OBIEE 18
Limit the Number of Logical Columns and ORDER BY Attributes in Reports 20
Review LOBs Usage in OTBI Reports 21
Reduce Multiple Logical Unions in OTBI Reports 22
Cross Subject Area Reports Considerations 22
Cross Fact Reports Recommendations 22
Use of OTBI Reports as Infolets in FA Embedded Pages 23
Considerations for Using Custom Extensible Attributes and Flex Fields in Logical Filters 24
Considerations for Using Hierarchical Attributes in Logical Filters 24
Employ DESCRIPTOR_IDOF Function in Logical Filters 24
Generated PSQL(s) with a Large Number In-List Values or BIND Variables Optimization 26
CONSTANT_OPTIMIZATION_LEVEL and CONSTANT_CASE_OPTIMIZATION_LEVEL Request Variables 27
Use REPORT_SUM/REPORT_COUNT Instead of REPORT_AGGREGATE Logical Functions 27
Use COUNT Instead of COUNT(DISTINCT) 29
EVALUATE vs. EVALUATE_ANALYTIC Considerations 30
Use of Logical Joins in OTBI Reports 30
Use of OBIEE CACHE Variables for Diagnostics in OTBI Reports 30
Use of OBIS_REFRESH_CACHE in OTBI Reports 30
Use of Database Hints to Optimize Generated Queries Plans 30
Use of MATERIALIZE Hint in Cross Subject Area and Cross Reports 31
Functional Design Patterns Affecting OTBI Reports Performance 32
"Time"."Fiscal Period" Performance Considerations in Financial Reports 32
Required Use of Logical UPPER() Function in Logical Filters 33
"Payroll - Payroll Run Results Real Time" Subject Area Recommendations 33
“Payroll - Payroll Balances Real Time” Subject Area Recommendations 34
Data Security Predicates Impact on OTBI Reports Performance 35
Security Predicate in OTBI: Performance Recommendations 35
Security Materialization in OTBI Reports 36
OTBI Export Limiters and Recommendations 36

ResultRowLimit 36
DefaultRowsDisplayedInDownloadCSV 36
DefaultRowsDisplayedInDownload 37
DefaultRowsDisplayedInDelivery 37
Oracle BI Cloud Connector Performance Considerations 37
BICC OTBI Metadata Independent Mode 37
BICC Performance Recommendations 37
TEMP and UNDO Tablespace Sizing 37
BICC Jobs Design Optimization for Better Performance 38
OTBI Performance Related Errors: Recommendations and Workarounds 39
Conclusion 41

INTRODUCTION
With Oracle Transactional Business Intelligence embedded analytics, role-based dashboards, as well as on-the-fly ad-hoc queries
capabilities, business users have very powerful means for accessing, interpreting and analyzing real-time data in Oracle Fusion
Applications (FA). The end users can put together sophisticated reports with various custom attributes, filters, join conditions and
analytic functions in just few mouse clicks. It is very important to know how to design such dashboards, prompts, reports and ad-hoc
queries in OTBI, ensuring maximum performance and scalability, and minimum impact on Fusion Middleware and Database
resources.
The generated OTBI contents complexity can come from:
Custom dashboards and reports design
Data Security Predicates (DSP)
Functional requirements to report contents
Custom Subject Areas
Customizations and extensibility attributes
Use of cross Subject Areas in a single report
Combination of the mentioned factors above.
Oracle Business Intelligence Cloud Connector (BICC) provides the functionality to extract data from Fusion Applications and loading
into Oracle Universal Content Management (UCM) Server or cloud storage in CSV format. It supports initial and incremental data
extracts, as well as primary keys extracts for tracking deletes.
The document will cover each topic in more details, with examples and recommendations how to improve design and achieve better
performance. Some examples will refer to Advanced Logical SQL options, as well generated physical query patterns and database
query plans, so the targeted audience is expected to know SQL basics and be able to read and understand sample execution plans.
Logical SQL Concepts
OBIEE uses its own internal language to describe reports, prompts, initialization blocks in a form of Logical SQLs (LSQL). Logical SQL
text uniquely identifies a report business logic:
SET VARIABLE QUERY_SRC_CD='Report', SAW_SRC_PATH='/shared/Custom/Sample Report/Manager
Name Query', PREFERRED_CURRENCY='Local Currency';
SELECT "Compensation Manager"."Manager Name") saw_0,
FROM "Compensation - Workforce Compensation Real Time"
WHERE "Compensation Manager"."Manager Name" = 'Joe Doe'
ORDER BY saw_0, saw_1
“SET VARIABLE” defines report type (QUERY_SRC_CD), its stored catalog path (SAW_SRC_PATH) and other attributes.
It also includes any OBIEE hints and directives, defined as query PREFIX values in OBIEE Answers -> Advanced Tab ->
Prefix field. Some of the directives are discussed in this document.
SELECT specifies all queried logical attributes. There may be more than one SELECT clause in Logical SQL.
FROM specifies the queried Subject Area. It may be used as a placeholder, while SELECT clause pull in attributes from
completely different subject area. Refer to the discussion on Cross Subject Area usage and recommendations.
WHERE clause includes logical joins, filters and subqueries.
ORDER BY is automatically generated by OBIEE and includes all select attributes by default.
SELECT and WHERE clauses may contain OBIEE internal functions, logical UNION, MINUS or INTERSECT and other SQL
operands. This document covers a number of techniques, that involve LSQL, so it’s important to read and understand the basic LSQL
concepts.
Understanding OTBI Query Execution
OTBI Metadata Repository (RPD) logical model delivers facts and dimensions on top of Fusion Application Development Framework
(ADF) Business model across multiple Subject Areas (SA) in OBIEE Presentation layer. When a business user designs a report as a
logical star, i.e. joins a logical fact to one or more logical dimensions, OBIEE converts the designed report into a logical SQL (LSQL),
and then generates one or more corresponding physical SQLs (PSQL), which then get executed in a database. OTBI logical facts and
dimensions get expanded into complex joins using ADF View Objects (VO) defined in OTBI RPD Physical layer. BI Server generates

XML queries to BI Broker to translate these FA ADF VOs into SQLs, that ultimately join FA database tables and views, and produces
the PSQL(s), that get executed in Fusion Apps OLTP database.
OTBI AND BICC PERFORMANCE MONITORING AND DIAGNOSTICS
This section provides the recommendations and guidelines for OTBI self-service monitoring and performance optimizations.
OBIEE Usage Tracking for OTBI and BICC Monitoring
OTBI delivered OBIEE Usage Tracking (UT) in database, starting from FA 19B. Every single logical SQL, whether it’s a prompt,
report, ad-hoc query or BICC extract, is being recorded into OBIEE Usage Tracking tables in each FA POD. UT captures all runtime
metrics such as timestamps, timing, row counts, logical and physical SQL text, errors, that can be analyzed for any performance or
usage anomalies, and potential issues or trends detected proactively in the FA environments.
Starting from FA release 20D, OTBI delivers two subject areas that can be used for creating reports to monitor OTBI usage and
performance:
• OTBI Usage Real Time: monitors OTBI usage, including user, analysis and dashboard, and subject area usage trends.
• OTBI Performance Real Time: monitors usage trends and OTBI analysis execution time, execution errors, and database
physical SQL execution statistics.
Refer to Oracle Customer Connect for more details and examples of OTBI Usage Tracking reports.
The example below shows a sample histogram report, combining reports and subject areas. From a quick glance, looking into number
of errors, total runs, and runtime histogram one can prioritize the reports for internal analysis:
Usage Tracking can be used to extract logical SQL text, that uniquely defines each report, and review the business logic,
check for valid filters, joins cross subject areas, etc. LSQL (and not PSQLs) should always be the starting point, as it provides
the important metadata to BI Server to generate PSQLs. Alternatively, you can locate and extract the LSQL in OBIEE
nqquery.log(s) if they are still available on the POD.
Review all runtime metrics, such as “Total time in BI Server”, “Logical Compilation Time”, each PSQL runtime, compute
end-to-end runtime by timestamps, check row counts for each PSQL and the LSQL. Both Usage Tracking and nqquery.log
capture these summaries. Refer to metrics detailed descriptions in the next section.
Since BICC issues LSQLs for its data extracts, the same Usage Tracking can be used for monitoring BICC jobs too. All BICC
LSQLs are executed by a special system user FUSION_APPS_OBIA_BIEE_APPID, that can be used for filtering extracts.
Note that “Total time in BI Server” may not account for the data fetching time. You can use start and end timestamps to
calculate more accurate extracts run time in your monitoring reports.
Query Log Analysis
OBIEE generates detailed diagnostic events with default second trace level [TRACE:2] and records the logs into its nqquery.log. This
trace level is sufficient for most diagnostic activities in FA. Some analyses may require higher trace level 7, that can be set via “SET
VARIABLE LOGLEVEL=7;” prefix. You can set it in OBIEE Answers -> Advanced tab -> Prefix section, when you design or optimize
your report.
Important! Make sure you remove LOGLEVEL=7 from your report prefix after you complete your performance analysis.
The logs are retained on each POD for primary and high availability (HA) node up to 10 days. If you have Administrator role, you can
retrieve the same log from OBIEE Answers by navigating to ‘Administration’ link -> ‘Manage Sessions’ -> Your session link. Below is

the summary example for a single report, extracted from nqquery.log with the detailed explanation of the important metrics and
events:
[2019-01-30T00:30:36.273+00:00] [OracleBIServerComponent] [TRACE:2] [] [] [ecid:
005WA82e9RH66Ut_odl3iY000EXm000_na,0:1:3:2:1:256:3] [tid: efa0700] [messageid: USER-0] [requestid: cec70034] [sessionid:
cec70000] [username: sampleuser@oracle.com] ############################################## [[
-------------------- SQL Request, logical request hash:
d9cd7a2f
SET VARIABLE QUERY_SRC_CD='Report',SAW_DASHBOARD='/shared/Custom/S2S Reports/S2SR Team/AGENTS/ApOps/Daily/Supplier
Registration/Daily Alert - Supplier Registration',SAW_DASHBOARD_PG='Strategic Buyer Review',SAW_SRC_PATH='/shared/Custom/S2S
Reports/S2SR Team/AGENTS/ApOps/Daily/Supplier Registration/Strategic Buyer Review',PREFERRED_CURRENCY='Document Currency';SELECT
0 s_0,
"Supplier Qualification - Qualifications and Assessments Real Time"."Qualification Area Question"."Responder Type" s_1,
"Supplier Qualification - Qualifications and Assessments Real Time"."Qualification Detail"."Qualification Evaluation Date"
s_2,
"Supplier Qualification - Qualifications and Assessments Real Time"."Qualification Detail"."Qualification Finalization Date"
s_3,
"Supplier Qualification - Qualifications and Assessments Real Time"."Qualification Detail"."Qualification Outcome" s_4,
"Supplier Qualification - Qualifications and Assessments Real Time"."Qualification Evaluated By"."Email Address" s_5,
"Supplier Qualification - Qualifications and Assessments Real Time"."Qualification Owner"."Buyer Email Address" s_6,
"Supplier Qualification - Qualifications and Assessments Real Time"."Qualification Owner"."Buyer Name" s_7,
"Supplier Qualification - Qualifications and Assessments Real Time"."Qualification Response Detail"."Acceptance Date" s_8,
"Supplier Qualification - Qualifications and Assessments Real Time"."Qualification Response Detail"."Response Date" s_9,
"Supplier Qualification - Qualifications and Assessments Real Time"."Qualification Supplier Profile"."Supplier Name" s_10,
"Supplier Qualification - Qualifications and Assessments Real Time"."Qualification Supplier Profile"."Supplier Number" s_11,
DESCRIPTOR_IDOF("Supplier Qualification - Qualifications and Assessments Real Time"."Qualification Area Question"."Responder
Type") s_12
FROM "Supplier Qualification - Qualifications and Assessments Real Time"
WHERE
(("Qualification Response Detail"."Acceptance Date" IS NOT NULL) AND ("Qualification Detail"."Qualification Outcome" IS NULL)
AND (DESCRIPTOR_IDOF("Supplier Qualification - Qualifications and Assessments Real Time"."Qualification Area
Question"."Responder Type") = 'INTERNAL'))
ORDER BY 1, 7 ASC NULLS LAST, 8 ASC NULLS LAST, 5 ASC NULLS LAST, 10 ASC NULLS LAST, 3 ASC NULLS LAST, 4 ASC NULLS LAST, 6 ASC
NULLS LAST, 9 ASC NULLS LAST, 12 ASC NULLS LAST, 11 ASC NULLS LAST, 2 ASC NULLS LAST, 13 ASC NULLS LAST
FETCH FIRST 500001 ROWS ONLY
]]
cec70000] [username: sampleuser@oracle.com] -------------------- General Query Info: [[
Repository: Star, Subject Area: Core, Presentation: Supplier Qualification - Qualifications and Assessments Real Time
]]
cec70000] [username: sampleuser@oracle.com] -------------------- Sending query to database named
oracle.apps.fscm.model.analytics.applicationModule.FscmTopModelAM_FscmTopModelAMLocal (id: <<1158231996>> SQLBypass Gateway),
connection pool named Connection Pool, logical request hash d9cd7a2f, physical request hash ed5d81bd: [[
<?xml version="1.0" encoding="UTF-8" ?>
<ADFQuery mode="SQLBypass" queryid="1547096721-2023840527" locale="en">
<Parameters>
<Parameter><Name><![CDATA[AOL_LANGUAGE]]></Name><Value><![CDATA[en]]></Value></Parameter>
<Parameter><Name><![CDATA[OTBI_CDS_ENABLED]]></Name><Value><![CDATA[false]]></Value></Parameter>
</Parameters>
<Projection>
<Attribute><Name><![CDATA[QualificationQualEvaluationDate]]></Name><ViewObject><![CDATA[FscmTopModelAM.PrcPoqPublicVi
ewAM.QualificationResponsesPVO]]></ViewObject></Attribute>
<Attribute><Name><![CDATA[QualificationQualCompletedDate]]></Name><ViewObject><![CDATA[FscmTopModelAM.PrcPoqPublicVie
wAM.QualificationResponsesPVO]]></ViewObject></Attribute>
...
...
...
</ViewCriteriaRow>
</ViewCriteria>
</DetailFilter>
</ADFQuery>
]]
cec70000] [username: sampleuser@oracle.com] -------------------- Sending query to database named
oracle.apps.fscm.model.analytics.applicationModule.FscmTopModelAM_FscmTopModelAMLocal (id: <<1158232468>> SQLBypass Gateway),
connection pool named Connection Pool, logical request hash d9cd7a2f, physical request hash 174c60f0: [[
<?xml version="1.0" encoding="UTF-8" ?>
<ADFQuery mode="SQLBypass" queryid="1782285574-110497155" locale="en">
<Parameters>
<Parameter><Name><![CDATA[AOL_LANGUAGE]]></Name><Value><![CDATA[en]]></Value></Parameter>
<Parameter><Name><![CDATA[OTBI_CDS_ENABLED]]></Name><Value><![CDATA[false]]></Value></Parameter>
</Parameters>
<Projection>
<Attribute><Name><![CDATA[Meaning]]></Name><ViewObject><![CDATA[FscmTopModelAM.AnalyticsServiceAM.LookupValuesTLPVO]]
></ViewObject></Attribute>
<Attribute><Name><![CDATA[LookupCode]]></Name><ViewObject><![CDATA[FscmTopModelAM.AnalyticsServiceAM.LookupValuesTLPV
O]]></ViewObject></Attribute>

...
...
...
</ViewCriteriaRow>
</ViewCriteria>
</DetailFilter>
</ADFQuery>
]]
cec70000] [username: sampleuser@oracle.com] -------------------- Sending query to database named FSCM_OLTP (id: <<1158231989>>),
connection pool named Connection Pool, logical request hash d9cd7a2f, physical request hash d91d1d65: [[
WITH
SAWITH0 AS (select T2521292.C277165028 as c3,
T2521292.C440229984 as c4,
T2521292.C104108913 as c5,
T2521292.C168651775 as c6,
T2521292.C398378115 as c7,
T2521292.C527336469 as c8,
T2521292.C402205937 as c9,
T2521292.C248158144 as c10,
T2521292.C203825585 as c11,
T2521292.C323161287 as c12,
T2521292.C464440102 as c13,
T2521292.C410075615 as c15
from
(SELECT V228191905.QUAL_EVALUATION_DATE AS C277165028,
...
...
...
from
SAWITH3 D901)
select D1.c1 as c1, D1.c2 as c2, D1.c3 as c3, D1.c4 as c4, D1.c5 as c5, D1.c6 as c6, D1.c7 as c7, D1.c8 as c8, D1.c9 as c9,
D1.c10 as c10, D1.c11 as c11, D1.c12 as c12, D1.c13 as c13 from ( select distinct 0 as c1,
D1.c2 as c2,
D1.c3 as c3,
D1.c4 as c4,
D1.c5 as c5,
D1.c6 as c6,
D1.c7 as c7,
D1.c8 as c8,
D1.c9 as c9,
D1.c10 as c10,
D1.c11 as c11,
D1.c12 as c12,
D1.c13 as c13
from
SAWITH4 D1
order by c7, c8, c5, c10, c3, c4, c6, c9, c12, c11, c2, c13 ) D1 where rownum <= 500001
]]
005WA82e9RH66Ut_odl3iY000EXm000_na,0:1:3:2:1:256:5:3] [tid: 16620700] [messageid: USER-18] [requestid: cec70034] [sessionid:
cec70000] [username: sampleuser@oracle.com] -------------------- Sending query to database named FSCM_OLTP (id: <<1158231989>>
pre query 0), connection pool named Connection Pool, logical request hash d9cd7a2f, physical request hash e9e71988: [[
BEGIN fnd_session_mgmt.attach_session('80A2F84E0AAE4340E05302313D0A7036'); END;
]]
005WA82e9RH66Ut_odl3iY000EXm000_na,0:1:3:2:1:256:5:3] [tid: 16620700] [messageid: USER-18] [requestid: cec70034] [sessionid:
cec70000] [username: sampleuser@oracle.com] -------------------- Sending query to database named FSCM_OLTP (id: <<1158231989>>
post query 0), connection pool named Connection Pool, logical request hash d9cd7a2f, physical request hash d90563e6: [[
BEGIN fnd_session_mgmt.detach_session; END;
]]
005WA82e9RH66Ut_odl3iY000EXm000_na,0:1:3:2:1:257] [tid: efa0700] [messageid: USER-34] [requestid: cec70034] [sessionid:
cec70000] [username: sampleuser@oracle.com] -------------------- Query Status: Successful Completion
cec70000] [username: sampleuser@oracle.com] -------------------- Rows 2, bytes 65544 retrieved from database query id:
<<1158231996>> SQLBypass Gateway
cec70000] [username: sampleuser@oracle.com] -------------------- Physical query response time 0.210 (seconds), id <<1158231996>>
SQLBypass Gateway
<<1158232468>> SQLBypass Gateway
cec70000] [username: sampleuser@oracle.com] -------------------- Physical query response time 0.080 (seconds), id <<1158232468>>
SQLBypass Gateway
<<1158231989>>

cec70000] [username: sampleuser@oracle.com] -------------------- Physical query response time 23.964 (seconds), id
<<1158231989>>
cec70000] [username: sampleuser@oracle.com] -------------------- Physical Query Summary Stats: Number of physical queries 3,
Cumulative time 24.254, DB-connect time 0.002 (seconds)
cec70000] [username: sampleuser@oracle.com] -------------------- Rows returned to Client 46
cec70000] [username: sampleuser@oracle.com] -------------------- Logical Query Summary Stats: Elapsed time 24.322, Total time in
BI Server 24.321, Response time 24.322, Compilation time 0.352 (seconds), Logical hash d9cd7a2f
Highlighted are the important fields and metrics to check for. Note the more critical fields are printed in bold below:
[requestid] uniquely identifies all events for a single report execution in nqquery.log
[username] captures the user that issued the report
<Logical request hash: value> uniquely identifies the report’s signature, which is its logical SQL text. It’s stamped at the
beginning and the end of the report log.
Start and end timestamps can be used to calculate the total time, that includes the data fetch time. This calculation is very
important for reports, producing large row counts, or BICC extracts extracting and uploading the data. OBIEE will keep its
cursor open and wait for its consumer, BICC for example, until it fetched all the records. This ‘fetch’ time may not be
reflected in ‘Total Time in BI Server’.
SAW_DASHBOARD and SAW_DASHBOARD_PG define the catalog path for the stored dashboard and dashboard page
name, hosting a report.
SAW_SRC_PATH is the catalog path for the customer’s report.
Logical SQL starts with <SET VARIABLE> clause, that includes OBIEE directives and variables, defined in Advanced Prefix
section. Refer to more details on VARIABLEs in sections below. The logical SQL text defines the report business logic for
the defined report.
BI Server generates two types of physical queries (PSQLs), and prints complete XML or SQL text:
− XML ADFQuery type, that connects to WLS connection pool, and each ADFQuery associated with its unique ID
<<…>> SQLBypass Gateway.
− Database SQL type, that connects to Oracle database, also associated with its unique ID <<…>>. Note it does not
have SQLBypass Gateway, it is executed against (CRM/HCM/FSCM/GRC)_OLTP database.
− BI Server issues pre- and post- SQLs to connect to FA Database, attaching and then detaching via FND API. Note
that the detach call is logged with much later timestamp, though it comes right after the attach call in the log.
BI Server prints several summary lines at the end of the report execution:
− Each <Physical query response time (seconds)> is OBIEE reported time for a single query, issued to WLS
connection pool to read ADF SQL query block, or to FA DB to retrieve the results from database. You can identify
the query by its OBIEE SQL ID. Note, that query response time would not reflect consumer wait time to fetch the
data.
− Each Physical query <Rows> retrieved from WLS or %_OLTP (DB) connection pools.
− < bytes retrieved> is OBIEE estimated fetched amount of data, based on maximum row size. This metric helps to
measure the volume impact from heavy reports or BICC extracts data fetching.
<Physical Query Summary Stats> shows:
− <Number of physical queries> is the total number of XML ADFquery and DB SQLs, in the example total 3 reflects
2 ADFQueries and one Oracle DB SQL
− <Cumulative time> is the sum of all PSQL queries. Note that the queries are run in parallel, so the sum would not
be representative of the total time spent in WLS or Oracle DB.
− <DB-connect time> is the time to establish DB connection, typically a tiny fraction of total time.
− <Rows returned to Client> is the number of rows, produced by the report.
<Logical Query Summary Stats> shows:
− <Elapsed time> is the lifetime of OBIEE cursor. It is not the representative metric for report runtime.
− <Total Time in BI Server> is the best runtime metric to use for measuring report runtime. It includes all runtimes
from all XML queries, DB SQLs as well as Logical SQL compilation time. Remember that it does not include the
data fetching waits from clients such as BICC. So, you need to rely on timestamps to compute the total time for
such heavy jobs.
− <Compilation Time> is another important metric, that includes BI Server time on XML ADFQueries, post-
processing time in BI Server, when it joins multiple PSQL result sets or applying non-pushed functions to the data.
This metric should be very closely watched in FA OBIEE env.
The End timestamp completes with the same unique Logical hash value <…>.

Guidelines for Analyzing Reports Performance
When analyzing query log for reports performance, use the following guidelines:
1. Review Logical SQL for <SET VARIABLE> clause to check for any non-standard variables and directives. They are defined in
Advanced tab in Prefix section.
Important! The VARIABLE values could have significant impact on SQL generation logic. They should not be applied unless
you understand the impact and would like to change the report generation to improve report’s performance. This document
provides the guidance and explanation of the critical variables, that may be applicable to OTBI reports.
2. Logical SQL (LSQL) text is very important source for analysis, such as use of logical attributes, logical functions, lack or
presence of comprehensive filters in a report, implicit use of cross Subject Areas, etc. You cannot rewrite the generated
Physical SQL in DB, you can use LSQL to change the generation logic and improve your report performance. In some case you
may consider using Advanced tab option and manually rewrite logical SQL text.
Important! Always start from inspecting your logical SQL text. Do not rush to optimize your PSQL test or tune its query
execution plan in database. Logical SQL should be carefully scrutinized, before moving next to PSQL analysis.
3. Review physical SQL(s), generated by OBIEE. Note, that OBIEE may generate more than one physical SQL for your report, so
use the query log or Usage Tracking stats to identify the most expensive PSQL for your review. Remember, that you cannot
manually rewrite the physical SQL text, but you can use database query explain plan to ensure the DB optimizer picking the
correct joins order, pushing predicates, applying filtering, etc. In some cases, you may want to influence the SQL query plan
by applying database hints to your report. This option is covered in detail in the document.

BEST PRACTICES FOR OTBI DASHBOARDS AND REPORTS DESIGN
OTBI Analytics is extensively integrated into Fusion Applications. The end users can execute the analytic reports directly embedded
into Fusion UI pages, run custom dashboards with many OTBI reports, use dashboard prompts for BI Publisher queries, execute
integration reports using Web Services APIs, etc. The power users can run ad-hoc queries directly from OBIEE Answers or use BI
Cloud Connector (BICC) to extract the data from FA VOs, available from BICC Admin Console’s enabled offerings. This chapter will
discuss high level recommendations for using OTBI in Fusion.
Dashboard Design Recommendations
This chapter covers the best practices and guidelines for designing OTBI Dashboards. Dashboards proper design will help to minimize
performance workload and improve end user experience in Fusion Applications environments.
Dashboard Design: Best Practices
4. Design your landing dashboard page very carefully, as it will be used the most and shall not generate performance overhead
from any heavy reports.
5. OBIEE Dashboards allow creating multiple pages. When designing multi-page dashboard, do not put too many pages per
dashboard. Typically, dashboards consolidate functional report contents in five pages or less. All pages should be visible and
clearly labeled for end users to pick the right page without unnecessary clicking every single page (and triggering reports
execution).
6. Define reasonable number of reports per dashboard page. Avoid scrolling in your pages. Typically having six reports or less
allows utilizing the dashboard space and presenting the relevant information. OBIEE will execute the reports in parallel, so a
single dashboard page with many reports could generate significant workload.
Important! If you put a large number of reports on the same dashboard, OBIEE would make multiple calls to BI Broker to
translate ADF VOs into SQL queries in parallel. Such high concurrent load would manifest in longer XML queries to generate
ADF VO SQL definitions, adding to the reports total runtime, causing higher resource usage on WLS servers that host BI
Broker, and impacting regular UI flows in FA.
7. Carefully design dashboard reports, find the optimal balance between complexity of a single report versus number of reports
on a dashboard page.
8. Consolidate reports with similar report logic on the same dashboard page into as few items as possible.
9. Consider placing reports with drastically different runtimes on separate dashboard pages.
10. Do the due diligence to group the logical reports together on the same dashboard page to improve the usability and minimize
unnecessary clicks through other dashboards and pages, as every single page click would trigger more report executions.
11. DO NOT include long running reports on commonly used dashboard pages and do not embed them into FA UI pages. Instead,
build such reports as the links off the dashboards or UI pages to limit their execution by interested parties only. You may
consider using BI Delivers for scheduling and delivering such reports to the targeted users instead of running them online.
12. Design your dashboard as much interactive as possible, using column selectors, drill downs and guided navigation.
13. Avoid using filters, that are based on the output from other reports on a dashboard.
14. Use sub-totals and grand totals in reports wisely. Each total value results in additional level of aggregation and may have
impact on report performance.
Dashboard Prompts Recommendations
OTBI Dashboard Prompts, which select List of Values (LOV), often produce their own LSQLs, that generate PSQLs to render the
desired values. Poorly designed prompts could result in very heavy, slowly performing PSQLs, producing long lists of values,
consuming significant resources on both BI and Database tiers, and causing frustration to end users. Review the following guidelines
for dashboard prompts design below.
Choice of Logical Entities in Prompts
Design dashboard prompts to generate efficient logical queries. Explore the alternative options to pull Prompt values from less heavy
logical entities such as dimensions and lookups instead of facts. Additionally, you can explore alternative subject areas for your
prompts.
Example 1. To create a prompt with a list of direct and indirect employees in your reporting hierarchy, consider selecting the names
from Resource Hierarchy and apply a filter by login. That will result in more optimal LSQL with a single logical dimension:
SELECT

0 s_0,
"Sales - CRM Resource"."Resource Hierarchy"."Current Base Resource Name" s_1
FROM "Sales - CRM Resource"
WHERE
("Resource Hierarchy"."User Organization Hierarchy Based Login"
= VALUEOF(NQ_SESSION."USER_PARTY_ID"))
The less efficient option to query data from two separate dimensions would add an implicit logical fact to the generated query and
take much longer to extract the values for the same prompt:
SELECT
"Sales - CRM Resource"."Employee"."Employee Name" s_1
FROM "Sales - CRM Resource"
WHERE
("Resource Hierarchy"."User Organization Hierarchy Based Login"
= VALUEOF(NQ_SESSION."USER_PARTY_ID"))
Example 2. Rather than use “Sales – CRM Asset Contact” SA for querying all employees for a specific sales country the implementer
could retrieve the same list of values much faster from “Sales – CRM Asset”:
SELECT
0 s_0,
"Sales - CRM Asset Contact"."Contact"."Full Name" s_1
FROM "Sales - CRM Asset Contact"
ORDER BY 1, 2 ASC NULLS LAST
Vs. less optimal LSQL for the same prompt:
SELECT
0 s_0,
"Sales - CRM Asset"."Contact"."Full Name" s_1
FROM "Sales - CRM Asset"
ORDER BY 1, 2 ASC NULLS LAST
Example 3. Avoid querying large HCM transactional tables and fetch all employee records when retrieving " Supervisor Full Name" in
your HCM prompts. The following LSQL restricts the data to fetch only department managers and delivers better performance:
SELECT
"Department"."Supervisor Full Name",
"Department"."Department Name"
FROM "Workforce Management - Worker Assignment Real Time"
While the original query would hit a large HCM transaction table, fetching all employee data for all Department Managers and worse
performance:
SELECT
"Department"."Supervisor Full Name"
FROM "Workforce Management - Worker Assignment Event Real Time"
ORDER BY 1
Use Default Prompt Values
Always define default values for your prompts.

Pick the value as default, which is most commonly selected by end users.
Use a dummy value if you cannot identify the most common one. Then the reports would produce no data until the end users
choose the right values.
Consider customizing ‘No Results’ message in the report(s) Analysis Properties to tell users to choose the right prompt values.
For example:
Logical Aggregate Functions in Prompt Filters
Avoid using aggregate functions in logical filters, as they may not be pushed to physical tables. For example, the use
MAX("Activity"."Actual Start Date") would not be pushed to the physical table ZMM_ACTY_ACTIVITY below:
SELECT "Customer"."Customer Unique Name" saw_0 FROM "Sales - CRM Sales Activity"
WHERE MAX("Activity"."Actual Start Date") BETWEEN timestamp '2017-01-01 0:00:00' AND
timestamp '2017-01-24 00:00:00' ORDER BY saw_0 FETCH FIRST 65001 ROWS ONLY
The generated PSQL shows two WITH factored subqueries, with MAX(d1.c3) pushed into the second WITH query block, and the
MAX filter value applied in the HAVING clause instead of filtering the records directly from ZMM_ACTY_ACTIVITIES table.
WITH sawith0 AS (
SELECT ...
FROM zmm_acty_activities activitypeo
... ) t1931714
),sawith1 AS (
SELECT
MAX(d1.c3) AS c2,
d1.c1 AS c3
FROM sawith0 d1
GROUP BY d1.c1
HAVING MAX(d1.c3) BETWEEN TO_DATE('2017-01-01 00:00:00','YYYY-MM-DD HH24:MI:SS') AND
TO_DATE('2017-01-24 00:00:00','YYYY-MM-DD HH24:MI:SS')
)...
WHERE ROWNUM <= 65001
If you have the functional requirement to employ such aggregated filters, then consider adding non-aggregated filters as well to
constrain the result set in your query.
Note, the same recommendation applies to prompts as well as regular reports with aggregate logical filters.
Use ‘Calendar’ Inputs in Date Prompts
Consider using ‘Calendar’ input instead of generating a ‘Choice List’.
The ‘Choice List’ would result in more expensive LSQL, querying database:
SET VARIABLE QUERY_SRC_CD='ValuePrompt';SELECT "Person"."Person Date Of Birth" saw_0 FROM
"Workforce Management - Person Real Time" ORDER BY saw_0 FETCH FIRST 65001 ROWS ONLY

compared to the use of more efficient ‘Calendar’ input below:
Use Text Field in Prompts
Consider using ‘Text Field’ in User Input when you build prompts using complex logical model, such as secure logical hierarchies. If
you implement such prompts via ‘Choice List’, you may end up with very expensive hierarchical PSQL without any filters, running for
a long time and not scaling for multiple business users. The ‘Text Field’ Prompts should comply with security requirements and have
input validation before OBIEE run the prompt LSQL and corresponding PSQL. You can ensure such validation by implementing a
hidden second prompt. Refer to the example for implementing ‘Text Field’ prompt based on Compensation Manager Hierarchy.
For example, the ‘Choice List’ Prompt using Compensation Manager Hierarchy would result in the following logical SQL without any
constraining logical filters:
SELECT "Compensation Manager"."Manager Name" saw_0,
DESCRIPTOR_IDOF("Compensation - Workforce Compensation Real Time"."Compensation
Manager"."Manager Name") saw_1 FROM "Compensation - Workforce Compensation Real Time"
ORDER BY saw_0 FETCH FIRST 65001 ROWS ONLY
Such query could take time to run, especially with multiple levels of the hierarchy. The same prompt can be designed to use Text Field
Input and the second hidden prompt, validating the input using the security, enforced for this hierarchy in OTBI:
1. Create a ‘Text Input’ Prompt for Compensation Manager Prompt
− Prompt for: Presentation Variable (p_open_txt)
− Label: Compensation Manager
− User Input: Text Field
− Variable Data Type: Default (Text)
− Default selection: SQL Results
− Enter SQL Statement to generate the list of values:
SELECT "Compensation Manager"."Manager Name"
WHERE "Worker"."Person ID" = VALUEOF(NQ_SESSION.PERSON_ID_HCM) FETCH FIRST 1 ROWS ONLY
Refer to the screenshot below:

2. Create Hidden ‘Choice List’ Prompt
Compensation Manager Prompt (Hidden) validates the value, entered into the ‘Text Field’ Prompt example above. The validated
Display Value is passed into another presentation variable p_val_var. Even though it is defined having ‘Choice List’, it will have a
single value, because the logical SQL will have an added filter in it.
− Prompt for Column: "Compensation Manager"."Manager Name"
− Label: Manager Name
− Choice List Values: SQL Results
SELECT "Compensation Manager"."Manager Name" FROM "Compensation - Workforce Compensation
Real Time" Where "Compensation Manager"."Manager Name" = '@{p_open_txt}{" "}' FETCH FIRST
1 ROWS ONLY
− Default selection: SQL Results
SELECT "Compensation Manager"."Manager Name" FROM "Compensation - Workforce Compensation
Real Time" WHERE "Compensation Manager"."Manager Name" = '@{p_open_txt}{" "}' FETCH
FIRST 1 ROWS ONLY
Set a variable: Presentation Variable (p_val_var)

3. Update the Prompted Filter for an affected report to depend on the variable p_val_var:
To prevent rendering incorrect result from entering blank values, space(s) or ‘%’ in the ‘Text Field’ prompt, add "AND
@{p_open_txt}['@']{' '} is prompted" to the report criteria as in the sample report below:
Criteria Filter Details:
"Compensation Manager"."Manager Name" IN (@{p_val_var}['@']{' '})
AND @{p_open_txt}['@']{' '}
And the generated logical SQLs include the logical filer for Manager Name:

SET VARIABLE QUERY_SRC_CD='DashboardPrompt'; SELECT "Compensation Manager"."Manager Name"
Where "Compensation Manager"."Manager Name" = 'Joe Doe' FETCH FIRST 1 ROWS ONLY
SET VARIABLE QUERY_SRC_CD='DisplayValueMap',PREFERRED_CURRENCY='Local Currency';SELECT
DESCRIPTOR_IDOF("Compensation Manager"."Manager Name") saw_0,
"Compensation Manager"."Manager Name" saw_1,
DESCRIPTOR_IDOF("Compensation - Workforce Compensation Real Time"."Compensation
Manager"."Manager Name") saw_2
WHERE "Compensation Manager"."Manager Name" = 'Joe Doe' ORDER BY saw_0, saw_1
Use of Lookup Tables vs. Dimensions in Prompts
OTBI prompts may deliver better performance, if forced to use lookup tables over dimensions. OBIEE allows ‘SET VARIABLE
OBIS_VALUE_PROMPT_LOOKUP_DIRECT_ACCESS=1;’ to influence OBIEE’s choice of using lookup table (value 1). Such option
applies to Prompt related LSQLs only (QUERY_SRC_CD =ValuePrompt or DisplayValueMap, that can be seen in nqquery.log) with
columns traced to a single Lookup table.
Important! Make sure you verify functional equivalency and carefully benchmark the use of the variable in your prompt in test
before you enable it in a production environment.
“OTBI HCM Prompts” Subject Area for Manager Prompts
When you build prompts to pull ‘Manager’ values in your HCM OTBI contents, “HCM OTBI Prompts” should be your first choice
before exploring other options. This subject area has been designed to simplify HCM ‘Manager’ prompts design and deliver improved
performance.
The example below uses a prompt query to retrieve Manager Name:
SELECT
"Manager"."Name"
FROM
"Workforce Management - Worker Assignment Event Real Time"
ORDER BY 1
Instead, you can use "OTBI HCM Prompts" to select Manager Name from "Assignment Manager List" unsecured dimension:
SELECT
"Assignment Manager List Unsecured"."Manager Name",
descriptor_idof("Assignment Manager List Unsecured"."Manager Name")
FROM
"OTBI HCM Prompts"
Report Design Recommendations
OBIEE offers maximum ease and flexibility in creating various reports with complex measures and computations. OTBI logical model
is optimized to deliver fast performance for customer reports and ad-hoc queries in Answers. There may be cases however, when
poorly designed reports with unnecessarily sophisticated logic generate very heavy database SQLs and deliver sub-optimal
performance. Review the guidelines and recommendations below for ensuring fast performance and keep them in mind when you
build your reports in OTBI.
Use Restrictive Filters to Constrain Result Set
1. When you create an OBIEE report, always pick effective logical filters, that produce the desired numbers and prevent
generating very high row counts. The end users may not even be aware that their reports fetch large volumes and start drill
downs or switch to other reports after reviewing the first set of records.

Important! Do not create open ended reports with weak filters or no filters in place. If needed, use default values, which can
be passed as filter values to such reports.
2. To prevent reports with runaway row counts, OTBI uses the default limit to fetch first 75,000 rows (the value varies by FA
POD shapes), thereby yielding better performance. This limit is less effective than logical filters, since it is pushed down to
database by appending ROWNUM <= 75001 to WHERE clause. As the result, it is applied as the very last step in the SQL
execution plan, compared to filter predicates, employed in much earlier steps in the query plans.
3. Another common pattern comes from row explosion when database optimizer picks SQL execution plan, that joins
participating tables with one of its steps producing row explosion, even though the final SQL result remains small. Such
intermediate row explosion would directly affect SQL performance, causing heavy database I/O. It is not simple to detect and
diagnose such impact, as OBIEE would not report database logical reads. Such analysis could be possible only by generating
SQL execution plan by DBAs with direct database access. Applying effective filters could directly influence the database
optimizer’s choice of SQL execution plan, allowing it to correctly estimate join cardinalities and pick more efficient execution
path without row explosion. There are more techniques and options, discussed in this document how to influence the query
execution plan in OTBI reports.
4. You may also consider other technologies such as BI Cloud Connector (BICC) or HCM Extract in HCM Cloud to extract much
larger volumes instead of pulling the same numbers via OTBI.
5. Avoid using function(s) on a filter, unless there is a corresponding function-based index for the mapped column in database.
6. Always choose ID columns for your logical filters, or use DESCRIPTOR_IDOF on a filter, so that OBIEE pick the appropriate
ID column in the physical query. Refer to the section discussing use of DESCRIPTOR_IDOF for more details.
7. Note, there still may be valid functional reasons for fetching larger row counts in OTBI reports and exporting them into other
formats.
Use Indexed Logical Attributes in Logical Joins and Filters
It is important to identify and use logical attributes in WHERE Clause that are mapped to database columns with supporting
indexes in place. While you can use virtually every single presentation column for logical joins or filters, do the due
diligence to find out the indexed columns, when designing your reports.
Some presentation attributes may transform into complex calculations, or map to database functions and other expressions,
coming from OTBI logical model or ADF VO transient attributes. Unless you confirm the availability of supporting
function-based indexes, that match the identified expression or function, avoid using those in your logical WHERE clause.
You can use the ‘Administration’ link -> ‘Manage Sessions’ -> ‘Your test report’ link in OBIEE Answers to check the
generated physical SQL and identify the mapped physical columns and their expression.
Review periodically Oracle Customer Connect for FA “Data Lineage” guides, posted after every FA release to understand the
logical business model, trace presentation attributes to physical tables and their columns, and check for existing indexes to
ensure OTBI reports fast performance.
Eliminate Duplicate and Redundant Filters in Logical SQLs
1. The use of duplicate logical filters can cause additional performance impact, resulting in unnecessary joins to physical tables,
and generating sub-optimal execution plans in database. For example:
AND (TIMESTAMPDIFF(SQL_TSI_DAY, MAX("Activity"."Actual End Date"), NOW()) > 90)
AND ("Activity"."Actual End Date" < VALUEOF("CURRENT_DAY")))
The second logical filter on "("Activity"."Actual End Date" < VALUEOF("CURRENT_DAY")))" results in an extra join to the
calendar table. This redundant logic can be safely removed from the report.
2. Filters must be applied once, when you are using reports as filters. A logical filter should be removed from all ‘filter’ reports, if
the same filter is already defined in the main ‘sub-query’ report. By eliminating such redundancy, you will end up with less
complicated and better performing generated PSQL.
Avoid Fetching Very Large Volumes from Database to OBIEE
There are several types of reports which could trigger fetching larger amounts of data from database to OBIEE for subsequent data
manipulation on OBIEE tier and providing the final results:
Reports containing logical functions, which cannot be pushed into database. For example, the use of LENGTH() or RAND() in
logical SQL definition may result in BI Server generating multiple sub-requests with corresponding PSQLs, executing the
PSQLs in database, fetching ALL records to OBIEE tier and ‘stitching’ the results there. Consider using CHAR_LENGTH()
instead of LENGTH() to avoid breaking a physical SQL into multiple.

Note: starting from version 12c OBIEE changed LENTGH() logic. It now pushes the logic into SQL generated query in
database and does not trigger generating multiple PSQLs.
Reports with cross facts are implicitly joined via Full Outer Join (i.e. BI Server joins logical sub-requests and picks full outer
join in its execution plan), may benefit from using PERF_PREFER_INTERNAL_STITCH_JOIN feature (that has been turned
on in RPD), that is forcing BI Server to break a report into multiple sub-requests, generate multiple PSQLs and fetch ALL
records for ‘stitching’ on OBIEE tier. To avoid the overhead from fetching too much data to BI Server, make sure you use
effective filters in such reports.
Reports containing CLOBs, and poorly constrained, may produce significant load on the system from fetching large volumes.
Certain reports logic may trigger implicit post processing on OBIEE tier, which requires fetching ALL rows from database to
OBIEE. The best indicator for such scenario would be a logical SQL with ‘FETCH FIRST X rows’ (default 75,000) having a
single physical SQL without ‘where rownum < X’ rows. For example, a logical SQL has:
SELECT
0 s_0,
...
IFNULL("General Ledger - Journals Real Time"."- Lines"."Journal Line Accounted Amount
Debit",0)
-IFNULL("General Ledger - Journals Real Time"."- Lines"."Journal Line Accounted
Amount Credit",0) s_43,
REPORT_AGGREGATE(IFNULL("General Ledger - Journals Real Time"."- Lines"."Journal Line
Accounted Amount Debit",0)
-IFNULL("General Ledger - Journals Real Time"."- Lines"."Journal Line Accounted
Amount Credit",0) BY ... s_44,
REPORT_SUM("General Ledger - Journals Real Time"."- Lines"."Journal Line Accounted
Amount Credit" BY ... s_45,
Amount Debit" BY ... s_46
FROM "General Ledger - Journals Real Time"
WHERE
...
However, the generated PSQL didn’t have WHERE ROWNUM <75001:
WITH sawith0 AS (
SELECT
...
FROM
sawith1 d1
ORDER BY ...;
As the result the report was failing with the error:
[nQSError: 43113] Message returned from OBIS.
[nQSError: 43119] Query Failed: [nQSError: 46168] RawFile::checkSoftLimit failed because
a temporary file exceeds the limit (10240 MB) specified by the NQ_LIMIT_WRITE_FILESIZE
environment variable.
The analysis of the report execution plan in the log (requires loglevel=7) shows:
ifnull(sum_SQL99(D1.c43 by ...) as c45 [for database 0:0,0],
sum_SQL99(D1.c42 by ...) as c46 [for database 0:0,0],
sum_SQL99(D1.c43 by ...) as c47 [for database 0:0,0]
Child Nodes (RqJoinSpec): <<...>> [for database 0:0,0]
...
Child Nodes (RqJoinSpec): ...
...
RqList <<...>> [for database 3023:1418642:FSCM_OLTP,57]
sum(D1.c32 by ...) as c1 [for database 3023:1418642,57],
sum(D1.c34 by ...) as c2 [for database 3023:1418642,57],

Per OBIEE logical query execution plan, REPORT_AGGREGATE got transformed into SUM_SQL99 and executed in OBIEE. In this
example the replacement of REPORT_AGGREGATE with REPORT_SUM results in all three functions pushed into the database:
RqList <<...>> [for database 3023:1418642:FSCM_OLTP,57]
sum(D1.c46) over (partition by D1.c17, ...) as c46,
sum(D1.c47) over (partition by D1.c17, ...) as c47,
sum(D1.c48) over (partition by D1.c17, ...) as c48
And the use of ROWNUM filter in the generated PSQL:
WITH sawith0 AS (
SELECT
...
FROM
SAWITH3 D1 ) D1 where rownum <= 75001
As the result of fetching too much data to BI Server, you may run into the TEMP file size limit (default 10Gb) on OBIEE tier and get
nQSError:46168 error, as shown in the example above:
[nQSError: 46168] RawFile::checkSoftLimit failed because a temporary file exceeds the
limit (10240 MB) specified by the NQ_LIMIT_WRITE_FILESIZE environment variable.
NQ_LIMIT_WRITE_FILESIZE is an important limiter, defining the upper value for TEMP space size on OBIEE tier, enforced in
Fusion Applications. Its larger value may be justified only for those customers who execute Cloud Extractor and require higher
OBIEE TEMP usage. The same error message, observed during OTBI reports execution is an indicator of too much data, pushed to
OBIEE, and the need to review the report design and logic.
Limit the Number of Logical Columns and ORDER BY Attributes in Reports
If you design a report with multiple logical columns, make sure you review its generated logical SQL and carefully inspect its logical
ORDER BY clause. Typically, the generated ORDER BY list includes all applicable columns, and with many of them included into the
report, as in the example below, that produced 116 ORDER BY attributes. As the result, the generated SQL’s execution plan would
have very expensive SORT operation across multiple columns. If your report produces very large row count, the very last SORT
operation could cause additional unnecessary overhead.
Carefully inspect ORDER BY generated clause, and use ‘Advanced’ tab to edit LSQL, pruning the ORDER BY clause to the
list of logical columns, which address the report functional requirements.
Consolidate logical attributes from as few subject areas as possible to mitigate or eliminate the complexity from the use of
cross SAs.
DO NOT load your report with a large number of logical columns, as they may get converted into fairly complex physical
expressions, causing poor report performance.
Remove the logical columns, excluded in ‘Edit View’, unless they are included in your report for a reason.
The example below shows such bad design of a report with both large number of columns and heavy ORDER by clause:
SELECT
0 s_0,
"Environment Health and Safety - Incidents Real Time"."Incident Event Additional
Details"."Incident Event Created By" s_1,
Details"."Incident Event Creation Date" s_2,
Details"."Incident Event Last Update Date" s_3,
Details"."Incident EventLast Update Login" s_4,
...
...
SORTKEY("Environment Health and Safety - Incidents Real Time"."Injury or
Illness"."Activity Description") s_114,
SORTKEY("Environment Health and Safety - Incidents Real Time"."Vehicle
Incident"."Third Party Details") s_115

FROM "Environment Health and Safety - Incidents Real Time"
WHERE
((DESCRIPTOR_IDOF("Environment Health and Safety - Incidents Real Time"."Incident Event
Details"."Incident Event Type") = '...') AND
(DESCRIPTOR_IDOF("Environment Health and Safety - Incidents Real Time"."Near Miss"."Type
of Near Miss") = '...') AND
("Incident Event Details"."Incident Event Completed Date" = date '2017-07-14'))
ORDER BY 1, 20 ASC NULLS LAST, 87 ASC NULLS LAST, 19 ASC NULLS LAST, 18 ASC
NULLS LAST, 86 ASC NULLS LAST, 16 ASC NULLS LAST, 15 ASC NULLS LAST, 17 ASC
NULLS LAST, 109 ASC NULLS LAST, 77 ASC NULLS LAST, 110 ASC NULLS LAST, 116
ASC NULLS LAST, 78 ASC NULLS LAST, 79 ASC NULLS LAST, 111 ASC NULLS LAST, 80
ASC NULLS LAST, 5 ASC NULLS LAST, 6 ASC NULLS LAST, 4 ASC NULLS LAST
Even though the report included effective logical filters, it failed during physical SQL parsing running into 1Gb PGA Heap size limit,
enforced in the database:
State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error
has occurred. [nQSError: 43113] Message returned from OBIS. [nQSError: 43119] Query
Failed: [nQSError: 17001] Oracle Error code: 10260, message: ORA-10260: limit size
(1048576) of the PGA heap set by event 10261 exceeded at OCI call OCIStmtExecute.
[nQSError: 17010] SQL statement preparation failed. (HY000)
Review LOBs Usage in OTBI Reports
Some OTBI Presentation Subject Areas have attributes, mapped to physical database columns of Large Object(LOB) data type,
character (CLOB) or binary (BLOB). Review the following guidelines for CLOBs usage in your reports:
FA does not initialize OBIS_MAX_FIELD_SIZE variable, so by default OBIEE applies 32,678 bytes limit to the maximum
size of any field, including CLOBs. If you attempt to fetch a larger, than 32Kb file size, it would come blank in OTBI.
Reports with CLOB attributes in SELECT clause may result in up to 70% longer performance, compared non-CLOB reports.
You should expect observing slower performance with CLOB reports, fetching larger row counts.
OBIEE does not support logical MINUS for reports with CLOBs attributes.
Use of CLOBs may cause failures with logical UNIONs, DISTINCT, GROUP BY and ORDER BY clauses.
Exclude CLOB attributes in filters and join predicates.
When you design a report containing CLOBs, make sure you enforce effective filters including the use of their default
values.
Important! Do not use non-pushed logical functions with CLOBs, as such combination could result in many more rows
fetched to OBIEE for the additional processing.

The CLOB misuse cases above would result in Oracle Database error:
ORA-00932: inconsistent datatypes: expected - got CLOB
Reduce Multiple Logical Unions in OTBI Reports
OBIEE provides very flexible logic to combine the results based on unions, intersection, and minus (or difference) operations. The
users can produce sophisticated analysis using logical UNION or UNION ALL by pulling the logical attributes from the same or
multiple subject areas. However, such flexibility comes with the cost, as multiple logical UNIONs further complicate the generated
physical SQL, significantly increase the query parsing time and overall runtime. Follow the guidelines below for designing UNION
based reports:
Limit the number of logical UNIONs to 5 or less
If possible, combine logical UNIONs into a single logical SELECT for the same subject area
Avoid joining many cross subject areas via logical UNIONs
Apply restrictive filters inside each logical UNION.
You may try to use ‘SET VARIABLE OBIS_DBFEATURES_IS_UNION_SUPPORTED =0;‘ in report prefix to break LSQL
with logical UNION and UNION ALL into multiple PSQLs.
Important! Make sure you carefully benchmark use of prefix variable OBIS_DBFEATURES_IS_UNION_SUPPORTED=0
with your logical UNION reports before you implement it in your production environment.
Cross Subject Area Reports Considerations
Cross Subject Area (SA) Reports include logical columns from more than one Subject Area (SA), referenced in SELECT, FROM or
WHERE logical clauses:
Explicit Cross SA pattern: reports reference multiple SAs explicitly in FROM clause
Implicit Cross SA: reports use a single SA in FROM clause and more referenced SAs in fully qualified attributes in SELECT
or WHERE clauses.
The most common implicit Cross SA pattern is shown below:
-- Select attributes from two SAs
SELECT “Subject Area1”.”attribute1” s_1,
“Subject Area2”.”attribute1” s_2,
…
FROM “Subject Area1” WHERE …;
-- Select attributes from one SA, but applying filters from the second SA:
SELECT “Subject Area1”.”attribute1” s_1,
“Subject Area1”.”attribute1” s_2,
…
FROM “Subject Area1” WHERE “Subject Area2”.”attribute1”=…;
Important! Refer to Oracle White Paper “Guidelines for creating Cross Subject Area Transactional BI Reports in Fusion”( Doc ID
1567672.1) for the detailed explanations and guidelines for using Cross SA in your reports.
This section covers additional recommendations for addressing performance related topics for using Cross SAs in OTBI reports.
1. Limit the use of Cross Subject Areas to as few as possible in your reports.
a. Every single SA adds the complexity to the generated PSQL, and results in significant overhead in both SQL structure,
security predicates, and as the result very complex execution plans.
b. There have been a number of cases, when the users unintentionally introduced 5-10 subject areas in a single report.
Avoid introducing more than three SAs in a single report, if you can.
c. Inspect the logical attributes, used from multiple SAs and verify if you can extract the same or functionally equivalent
logical columns from the primary SA instead.
2. Cross SA reports form the largest category of the queries, failing with “ORA-10260: limit size (1048576) of the PGA heap
size”. Such error cannot be worked around and requires the use of advanced logical SQL to address such reports functional
requirements.
Cross Fact Reports Recommendations

Cross Fact or Cross Star reports reference more than one logical fact from the single subject area in OTBI reports. The table below
provides two examples, showing the difference between cross subject and cross fact queries:
the left column shows the case with implicit cross subject areas, highlighted in green and blue
the right column shows LSQL with cross facts, using two facts (highlighted in blue and red) from the same subject area (Sales
– CRM Pipeline).
TWO CROSS SAS REPORT TWO CROSS FACTS REPORT
Typically produces LEFT OUTER JOIN in sub-requests Typically produces FULL OUTER JOIN in sub-requests
SELECT "Workforce Management - Worker Assignment
Real Time"."Worker"."Assignment Number" s_1,
"Workforce Management - Worker Assignment Real
Time"."Worker"."Employee First Name" s_2,
"Workforce Management - Employment Contract Real
Time"."Employment Contract Details"."Type" s_3
FROM "Workforce Management - Worker Assignment Real
Time"
WHERE (DESCRIPTOR_IDOF("Workforce Management -
Worker Assignment Real Time"."Worker"."Assignment
Status Type") IN ('ACTIVE', 'SUSPENDED'))
ORDER BY 1
SELECT "Sales - CRM
Pipeline"."Employee"."Employee Name" s_1,
"Sales - CRM Pipeline"."Pipeline Detail
Facts"."Closed Opportunity Line Revenue" s_2,
"Sales - CRM Pipeline"."Resource Quota
Facts"."Resource Quota" s_3
FROM "Sales - CRM Pipeline"
WHERE ("Time"."Enterprise Quarter" = VALUEOF
("CURRENT_ENTERPRISE_QUARTER"))
ORDER BY 1
OTBI logical model design uses several categories of dimensions:
common OTBI dimensions, shared across multiple pillars such as Financials, HCM, etc.
common Pillar dimensions that apply to all subject areas within each pillar
common Fact dimensions that apply to two or more logical facts within each subject area
local Fact dimensions that are specific to a logical fact in the subject area.
Review the recommendations below for designing and optimizing your cross fact OTBI reports:
Select at least one metric from each fact to ensure report consistency. You may select and exclude them Edit View not to
show in your report.
Select at least one common dimension, shared by participating facts, otherwise OBIEE would generate cartesian product and
create wrong resultset.
Select common fact dimension attributes, that OBIEE will use to join cross facts. If you don’t need in your report, you can
select these attributes in the report but exclude them in Edit View.
Carefully design filters to apply them to all facts in cross fact reports. Remember that a filter on a local fact dimension
applies to one logical fact only. With no additional filters to the other fact(s), the report would result in slower performance.
Consider using fewer (than more) logical facts in a single report. Adding more facts into a single report would complicate
the report design, generate more complex SQL with security predicates applying to ALL facts, and affect the report
performance.
Check for any possibly redundant SYS_OP_MAP_NONNULL in generated PSQLs. Typically, cross fact queries produce Full
Outer Join (FOJ) between Fact VOs. Such join may result in equi-joining NULLs, that produces SYS_OP_MAP_NONNULL
in PSQL. SYS_OP_MAP_NONNULL generation can be eliminated by unchecking ‘nullable’ property in RPD for a joining
logical column, if it references a NOT NULL column in database.
Cross fact reports with implicit Full Outer Joins may benefit from using ‘SET VARIABLE
OBIS_DBFEATURES_IS_PERF_PREFER_INTERNAL_STITCH_JOIN=1; SELECT ….”, breaking a single PSQL into multiple
database queries.
Use of OTBI Reports as Infolets in FA Embedded Pages
Reports, designed in OTBI, can be embedded as infolets into FA product pages. Infolets allow customers to draw their quick attention
to a metric or attribute and further analyze it using more detailed analytic reports. However, such infolets could become a source of
performance overhead in your FA environment, if designed inefficiently. Typically, OTBI infolets will score much higher usage,
compared to OTBI reports and dashboards, that are used by targeted audience. The UI users may or may not be interested in getting
any inputs from such OTBI reports, and yet trigger executing them every time they navigate through such UI pages. Review the
following recommendations for using OTBI infolets in FA:
Review OTBI Usage Tracking reports for the scale and usage of Infolets in your environment.

Make sure you design very compact reports, using effective date filters, performing optimal aggregations on a small resultset.
Mind the use functional contents that add complex (or custom) data security predicates to OTBI infolets.
Avoid using Cross Subject area reports or any other complex design patterns, offered by OTBI for infolets. Stick to using
Single Subject Area only.
Avoid using filters, based on other reports, via IN or SET operators.
Ensure restrictive and index-supported filters, to avoid aggregation of fact measures over a wide data set.
Avoid using a detailed report as a filter for an infolet, for maintaining functional consistency. Instead, create two separate
reports with shared filters using 'saved filters'. Such approach will reduce the complexity of the infolet report, while
maintaining the desired consistency, and reduce development overhead for any changes, as you need to modify a single filter
in one place to update the changes in both reports.
Avoid consolidating all infolets on a single page. Instead have multiple tabs and keep the non-critical infolets on the second
page. This will improve user experience and also ensure that all infolet queries are not fired in parallel, thereby reducing the
concurrent load on the system.
Avoid disabling OBIPS Cache via setting “SET VARIABLE OBIS_REFRESH_CACHE=1;” in your infolets. The variable would
consider entries in OBIPS cache as stale and reseed it every time you navigate to the page with infolets. The higher frequency
of OTBI infolet reports usage would result in every single page navigation skipping OBIPS cache and causing more
performance overhead to your environment. Refer below to the recommended variable usage.
Considerations for Using Custom Extensible Attributes and Flex Fields in Logical Filters
OTBI supports the use of custom flexible attributes in its logical model for extending the functionality and flexibility in BI
Transactional reporting. Review the following considerations when employing such custom attributes in your reports:
1. Extensible attributes are NOT indexed in Fusion database. If you design a logical report and apply a filter using such extensible
attribute, database optimizer would pick full table scan access path in the absence of any other filters or join predicates.
2. If you define extensible attributes inside the logical View Objects, which get generated as correlated sub-queries in PSQL, and
choose to use them as logical filters, you may run into the database error “ORA-01652: unable to extend temp segment by 128
in tablespace FUSION_TEMP”. When optimizer generates an execution plan for PSQL with such correlated sub-query, it first
joins all the required tables, retrieving all the values for extensible attribute and only then does it apply filters to it. Even if
you use an extensible attribute, mapped to an indexed physical column, its index would be of very little use. To speed up
reports with such design consider applying additional filters, which help to reduce the volumes of the interim joins.
Considerations for Using Hierarchical Attributes in Logical Filters
Logical filters on hierarchical attributes can add significant complexity and performance overhead to your reports. You may work
around the hierarchical columns in WHERE clause by picking other columns from the same logical object(s). For example, a report
referencing “Hierarchy.level1 Department” attribute in WHERE clause may be replaced with “Department Name” without affecting
the functional design. The Department hierarchy provides the structure of a department tree and it is usually traversed from the top
using the Tree name. The use of “Department Name” eliminates the generated SQL complexity and significantly improves report’s
performance.
Employ DESCRIPTOR_IDOF Function in Logical Filters
OBIEE’s double-column functionality in RPD allows to associate two logical columns in the logical layer:
A descriptor or display column, which contains the actual display values. For example, “Customer Country” shows Country
Names.
A descriptor ID or code column, which contains the code values, uniquely identifying display values, consistent across users
or locales. For example, “Country Code” maps to the Country IDs.
The double column feature allows to:
Define language independent filters
Change display values without rewriting the actual analyses
Handle the queries, which use LOB data types
Utilize indexes on ID columns and get improved performance for your queries.
Carefully review Logical filters in your report’s logical SQL as well as the corresponding Physical filters in its generated physical SQL
and verify whether you can replace a filter on a "description" column with the filter on its direct "code" / "ID" column. The
“description” columns may not be indexed, while their corresponding ID columns typically have indexes defined. The switch from
“description” to ID columns will reduce complexity of the physical SQL and utilize available indexes on CODE/ID columns.
Note, Descriptor_IDOF can be used ‘Equal’ and ‘IN’ filters but not with ‘LIKE’ comparison.

Refer to the example below, showing Descriptor_IDOF in RPD for “Sales - CRM Pipeline"."Customer"."Country Code", defined as a
Descriptor Id Column for "Sales – CRM Pipeline"."Customer". "Customer Country":
The use of DESCRIPTOR_IDOF helps to address additional performance cases:
1. DESCRIPTOR_IDOF function will result in producing a physical SQL with generated execution plan, where the filter value
will get applied to (most likely indexed) ID column from a dimension table earlier in the plan execution steps, compared to
less optimal plan with the filter on a lookup table. For example, the modified LSQL:
SELECT
0 s_0,
"Sales - CRM Pipeline"."Customer"."Account Active Flag" s_1,
"Sales - CRM Pipeline"."Customer"."Corporate Account Name" s_2,
"Sales - CRM Pipeline"."Customer"."Customer City" s_3,
"Sales - CRM Pipeline"."Customer"."Customer Country" s_4,
...
FROM "Sales - CRM Pipeline"
WHERE (("Customer"."Customer Name" LIKE 'A%')
AND ((DESCRIPTOR_IDOF("Customer"."Customer Country") = 'CA')
OR (DESCRIPTOR_IDOF("Customer"."Customer Country") = 'MX')))
ORDER BY 1,
6 ASC NULLS LAST
FETCH FIRST 75001 ROWS ONLY ;
Such logic will replace “NVL(D2.c1 , D1.c14) IN ('Canada', 'Mexico'))” with “D1.c14 IN ('CA', 'MX')” predicate and produce
the physical SQL pattern below:

. . .
FROM SAWITH2 D1
LEFT OUTER JOIN OBICOMMON0 D2
ON D1.c14 = D2.c2
WHERE --( NVL(D2.c1 , D1.c14) IN ('Canada', 'Mexico'))
D1.c14 IN ('CA', 'MX')
2. DESCRIPTOR_IDOF may affect the number of generated physical SQLs for report’s LSQL.
If you design a report with a logical filter containing a lookup, it may cause OBIEE to generate more than one physical SQL
and affect the report performance. If you need to apply such filters on a lookup, then use Descriptor ID Column in the filter.
For example, the logical query example below has the following logical filters:
FROM "Workforce Goals - Goal Status Overview Real Time"
WHERE
(("Business Unit"."Status" = 'Active') AND
(YEAR("Performance Goals"."Start Date") = 2014) AND
(DESCRIPTOR_IDOF("Workforce Goals - Goal Status Overview Real Time"."Worker"."Assignment
Status")=1)
AND ("Worker"."Person Type" ='Employee'))
BI Server will generate two physical SQLs, triggered by ("Business Unit"."Status" = 'Active'), instead of one:
Rows 1, bytes 128 retrieved from database query id: <<9201501>>
Physical query response time 0.108 (seconds), id <<9201501>>
Rows 359525, bytes 2395073904 retrieved from database query id: <<9200121>>
Physical query response time 224.454 (seconds), id <<9200121>>
Physical Query Summary Stats: Number of physical queries 12, Cumulative time 237.783, DB-
connect time 0.001 (seconds)
Rows returned to Client 359411
Logical Query Summary Stats: Elapsed time 279.306, Response time 260.537, Compilation
time 14.639 (seconds)
Since OBIEE didn’t ship all the logic to the database, it had to wait for both PSQL results before merging them on its tier.
You can rewrite the logical query to use DESCRIPTOR_IDOF and end up with all the logic shipped to database in a single
PSQL:
FROM "Workforce Goals - Goal Status Overview Real Time"
WHERE
((DESCRIPTOR_IDOF("Business Unit"."Status") = 'ACTIVE') AND
(YEAR("Performance Goals"."Start Date") = 2014) AND
(DESCRIPTOR_IDOF("Workforce Goals - Goal Status Overview Real Time"."Worker"."Assignment
Status")=1)
AND ("Worker"."Person Type" ='Employee'))
Generated PSQL(s) with a Large Number In-List Values or BIND Variables Optimization
There two most common cases, that result in generating PSQLs with large number of in-list values or BIND variables, and that may
lead to slower performance or report failures:
1. OBIEE may generate two or more physical SQLs, with one of them listing internal BIND variables, that it uses to pass the
values from another PSQL. It may be the result of using lookups and employing BIND variables to pass in the values between
lookup(s) and main generated query:
…
T2510675.C36361321 as c2
from
(SELECT V483283710.MEANING AS C61309499, V483283710.LOOKUP_CODE AS C36361321,
V483283710.LOOKUP_TYPE AS C319008066 FROM HCM_LOOKUPS V483283710 WHERE ( (
(V483283710.LOOKUP_TYPE = 'HRG_PERF_GOAL_CATEGORY' ) )
)) T2510675
where ( T2510675.C36361321 in (:PARAM1, :PARAM2, :PARAM3, :PARAM4, :PARAM5, :PARAM6,
:PARAM7, :PARAM8, :PARAM9, :PARAM10, :PARAM11, :PARAM12, :PARAM13,:PARAM14, :PARAM15,
:PARAM16, :PARAM17, :PARAM18, :PARAM19, :PARAM20) )

order by c2
Depending on the number of queried logical attributes in LSQL SELECT, this list could be very long, and cause performance
overhead or result in the error:
[nQSError: 46168] …temporary file exceeds the limit (10240 MB) specified by the
NQ_LIMIT_WRITE_FILESIZE environment variable.
Review your logical SQL for presence of any non-pushed functions, such as LENGTH, RAND, or non-default OBIEE
directives, passed into ‘SET VARIABLE’ clause, and if found, consider removing from the report’s LSQL.
Additionally, review the business logic to reduce the number of lookups, used in the report.
2. OBIEE may generate several PSQLs, with one returning very large number of actual values, that get passed into another
PSQL:
…AND ( NOT ( (V222235898.PARTY_NAME = 'Joe Doe' ) ) ) )) T2906423
where ( T2906423.C47764773 in (
3000000001.0, 3000000002.0, 3000000003.0, 300000004.0, 300000004.0, 300000005.0,
300000006.0, 300000007.0, 300000008.0, 30000009.0, 300000010.0, 300000011.0, 300000012.0,
300000013.0, 300000014.0, 300000015.0, 300000016.0, 300000017.0, 300000018.0,
300000019.0, ...
Oracle has the internal limit on the number of in-list values. Besides, such large lists cause very poor SQL performance. It and
cause the following error:
[nQSError: 42029] Subquery contains too many values for the IN predicate. (HY000)
Such behavior comes from the use of lookup in WHERE clause in the logical SQL. To work around such behavior, you can
either use DESCRIPTOR_IDOF (only for equi-join) or include the lookup attribute into LSQL SELECT clause. Alternatively,
you may replace the use of lookup filter with any available ID or Code attributes from queried facts or dimensions.
CONSTANT_OPTIMIZATION_LEVEL and CONSTANT_CASE_OPTIMIZATION_LEVEL Request
Variables
If you observe your report’s logical SQL having computations using logical constants or logical CASE, then consider initializing the
session variables CONSTANT_OPTIMIZATION_LEVEL=1 and/or CONSTANT_CASE_OPTIMIZATION_LEVEL=1 via ‘SET
VARIABLE’ prefix in Advanced SQL tab to enable expression optimization. It may improve performance of logical reports with CASE
WHEN filters.
The constants values are:
0 – No constant expression optimization. This is the default value.
1 - BI Server performs internal constant expression evaluation early during the query processing and they are all converted
into actual literal values. Any errors during constant evaluation would result in no constant being rewritten.
2 - This value makes the constant optimization aggressive. When faced with any error during a constant evaluation, BI
Server would skip the failing constant expression and rewrite the others.
CONSTANT_OPTIMIZATION_LEVEL helps in such cases as in the examples below:
1+2*(5 + valueof(NQ_SESSION.int_var))
upper('abc' || valueof(NQ_SESSION.varchar_var)) || left('def', 2)
'ABC'||' '||'DEF'
Use REPORT_SUM/REPORT_COUNT Instead of REPORT_AGGREGATE Logical Functions
If REPORT_AGGREGATE perform such calculation as SUM, COUNT, etc., you can safely replace it with REPORT_SUM, or
REPORT_COUNT (other corresponding calculations) to ensure better performance of your reports. REPORT_AGGREGATE may
force BI Server to generate multiple logical sub-requests, and create more than one PSQL, with all the complexity of fetching large
volumes of data and performing logical joins on OBIEE tier.

Note, when you build PIVOT reports with the use of aggregate functions, BI Server will not push them into database, but perform on
its tier in memory. With more columns and rows in your PIVOT reports such aggregations could take longer time. Review and, if
possible, reduce ‘BY’ clause in your AGGREGATE functions to simplify the aggregation.
Important! DO NOT use an empty ‘BY’ clause, that may get generated in your report, since OBIEE would include all queried
attributes into the aggregate clause in physical SQL. The use of empty ‘BY’ clause may result in generating more than one physical
SQL.
In the example below the original LSQL contains a mix of REPORT_SUM and REPORT_AGGREGATE:
SELECT ...
REPORT_AGGREGATE(IFNULL("General Ledger - Journals Real Time"."-Lines"."Journal Line
Accounted Amount Debit",0)-IFNULL("General Ledger - Journals Real Time"."-
Lines"."Journal Line Accounted Amount Credit",0) BY SUBSTRING("General Ledger - Journals
Real Time"."-Account"."Concatenated Segments" FROM 16 FOR 4),SUBSTRING("General Ledger -
Journals Real Time"."-Account"."Concatenated Segments" FROM 21 FOR 6),SUBSTRING("General
Ledger - Journals Real Time"."-Account"."Concatenated Segments" FROM 28 FOR
5),SUBSTRING("General Ledger - Journals Real Time"."-Account"."Concatenated Segments"
FROM 34 FOR 5),SUBSTRING("General Ledger - Journals Real Time"."-Account"."Concatenated
Segments" FROM 40 FOR 5),SUBSTRING("General Ledger - Journals Real Time"."-
Account"."Concatenated Segments" FROM 46 FOR 2),SUBSTRING("General Ledger - Journals Real
Time"."-Account"."Concatenated Segments" FROM 49 FOR 5), SUBSTRING("General Ledger -
Journals Real Time"."-Account"."Concatenated Segments" FROM 4 FOR 5),SUBSTRING("General
Ledger - Journals Real Time"."-Account"."Concatenated Segments" FROM 10 FOR
5),SUBSTRING("General Ledger - Journals Real Time"."-Account"."Concatenated Segments"
FROM 1 FOR 2)... s44,
REPORT_SUM("General Ledger - Journals Real Time"."- Lines"."Journal Line Accounted Amount
Credit" BY SUBSTRING("General Ledger - Journals Real Time"."- Account"."Concatenated
Segments"
FROM 1 FOR 52),"General Ledger - Journals Real Time"."Approval Status"."Approval Status
Description","General Ledger - Journals Real Time"."- Line Details"."Line Effective
Date","General Ledger - Journals Real Time"."- Line Details"."Line Period Name","General
Ledger - Journals Real Time"."- Line Details"."Line Number","General Ledger - Journals
Real Time"."- Line Details"."Line Description","General Ledger - Journals Real Time"."-
Line Details"."Line Type","General Ledger - Journals Real Time"."- Line Details"."Line
Currency Code","General Ledger - Journals Real Time"."Time"."Fiscal Year Number","General
Ledger - Journals Real Time"."- Journal Category"."User Journal Category Name","General
Ledger - Journals Real Time"."- Journal Category"."Description","General Ledger -
Journals Real Time"."- Journal Source"."User Journal Source Name","General Ledger -
Journals Real Time"."- Journal Source"."Source Journal Source Description","General
Ledger - Journals Real Time"."- Ledger Set".
"Ledger Set Name","General Ledger - Journals Real Time"."- Ledger"."Ledger
Name","General Ledger - Journals Real Time"."- Ledger"."Chart Of Account","General Ledger
- Journals Real Time"."- Header Details"."Header Balance Type Flag","General Ledger -
Journals Real Time"."- Header Details"."Encumbrance Type","General Ledger - Journals Real
Time"."- Header Details"."Header Close Acct Seq Value","General Ledger - Journals Real
Time"."- Header Details"."Header Description","General Ledger - Journals Real Time"."-
Header Details"."Journal Legal Entity","General Ledger - Journals Real Time"."- Header
Details"."Header Doc Sequence Name","General Ledger - Journals Real Time"."- Header
Details"."Header Local Doc Sequence Value","General Ledger - Journals Real Time"."-
Header Details"."Header Status","General Ledger - Journals Real Time"."- Header
Details"."Header Doc Sequence Value","General Ledger - Journals Real Time"."- Header
Details"."Header posting Account Seq Value", 0,
"General Ledger - Journals Real Time"."Posting Status"."Posting Status Description")
s_45,
Amount Debit" BY SUBSTRING("General Ledger - Journals Real Time"."-
Account"."Concatenated Segments"
FROM 1 FOR 52), "General Ledger - Journals Real Time"."Approval Status"."Approval Status
Description",... s_46,
REPORT_AGGREGATE(IFNULL("General Ledger - Journals Real Time"."- Lines"."Journal Line
Accounted Amount Debit",0) - IFNULL("General Ledger - Journals Real Time"."-
Lines"."Journal Line Accounted Amount Credit",0) BY SUBSTRING("General Ledger - Journals
Real Time"."- Account"."Concatenated Segments"
FROM 1 FOR 52),"General Ledger - Journals Real Time"."Approval Status"."Approval Status
Description",... s_44

Otbi and bicc_psr_technote_v3_final_document

Otbi and bicc_psr_technote_v3_final_document

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Otbi and bicc_psr_technote_v3_final_document

Similar to Otbi and bicc_psr_technote_v3_final_document (20)

Recently uploaded

Recently uploaded (20)

Otbi and bicc_psr_technote_v3_final_document