IBM Cognos 10 Dynamic Query Cookbook

Guideline
The IBM Cognos 10 Dynamic

Query Cookbook
Product(s): IBM Cognos 10
Area of Interest: Infrastructure
The IBM Cognos 10 Dynamic Query Cookbook 2
Copyright and Trademarks

Licensed Materials - Property of IBM.
© Copyright IBM Corp. 2010
IBM, the IBM logo, and Cognos are trademarks or registered trademarks of
International Business Machines Corp., registered in many jurisdictions worldwide.
Other product and service names might be trademarks of IBM or other companies. A
current list of IBM trademarks is available on the Web at
http://www.ibm.com/legal/copytrade.shtml
While every attempt has been made to ensure that the information in this document
is accurate and complete, some typographical errors or technical inaccuracies may
exist. IBM does not accept responsibility for any kind of loss resulting from the use of
information contained in this document. The information contained in this document
is subject to change without notice.
This document is maintained by the Best Practices, Product and Technology team.
You can send comments, suggestions, and additions to cscogpp@ca.ibm.com.
Business Analytics
Contents
1 INTRODUCTION ............................................................................................ 5
1.1 PURPOSE ..............................................................................................................5
1.2 APPLICABILITY .......................................................................................................5
1.3 EXCLUSIONS AND EXCEPTIONS ....................................................................................5
2 INTRODUCTION TO THE IBM COGNOS 10 DYNAMIC QUERY MODE ............ 5
2.1 QUERY OPTIMIZATION..............................................................................................5
2.2 PERFORMANCE IMPROVEMENT THROUGH BALANCED LOCAL PROCESSING FACILITIES .................. 6
2.3 SECURITY-AWARE CACHING .......................................................................................6
2.4 NEW DATA INTERFACES LEVERAGING 64 BIT PROCESSING .................................................. 6
2.5 EASE OF MAINTENANCE WITH QUERY VISUALIZATION........................................................ 6
3 THE IBM COGNOS 10 ARCHITECTURE .......................................................... 7
3.1 ARCHITECTURAL DIAGRAM OF COMPATIBLE QUERY MODE .................................................. 7
3.1.1 Basic Request Flow of a Compatible Query ............................................................8
3.2 ARCHITECTURAL DIAGRAM OF DYNAMIC QUERY MODE .................................................... 11
3.2.1 Basic Request Flow of a Dynamic Query .............................................................. 12
4 CONFIGURING IBM COGNOS 10 DYNAMIC QUERY MODE DATA SOURCE
CONNECTIVITY....................................................................................................... 15
4.1 UNDERSTANDING HOW IBM COGNOS 10 CONNECTS TO ORACLE ESSBASE ............................ 15
4.2 STEP BY STEP EXAMPLE OF CONFIGURING THE ORACLE ESSBASE CONNECTIVITY FOR USE WITHIN
IBM COGNOS 10.............................................................................................................. 16
4.3 ORACLE ESSBASE DATA SOURCE SPECIFIC IBM COGNOS 10 CONFIGURATION SETTINGS........... 17
4.3.1 Treat Nulls as Zeros within Calculations............................................................... 17
4.4 UNDERSTANDING HOW IBM COGNOS 10 CONNECTS TO SAP BW ...................................... 18
4.5 STEP BY STEP EXAMPLE OF CONFIGURING THE SAP BW CONNECTIVITY FOR USE WITHIN IBM
COGNOS 10 (64 BIT ONLY) ................................................................................................. 18
4.6 SAP BW DATA SOURCE SPECIFIC IBM COGNOS 10 CONFIGURATION SETTINGS ..................... 18
4.6.1 Treat Nulls as Zeros within Calculations............................................................... 19
4.7 UNDERSTANDING HOW IBM COGNOS 10 CONNECTS TO IBM COGNOS TM1 ......................... 19
4.8 STEP BY STEP EXAMPLE OF CONFIGURING THE IBM COGNOS TM1 CONNECTIVITY FOR A WINDOWS
INSTALL OF IBM COGNOS 10............................................................................................... 20
4.9 IBM COGNOS TM1 DATA SOURCE SPECIFIC IBM COGNOS 10 CONFIGURATION SETTINGS ........ 22
4.9.1 UseNonEmptyOnDataQueryThreshold ................................................................. 22
4.9.2 UseProviderCrossJoinThreshold .......................................................................... 23
5 IBM COGNOS 10 FRAMEWORK MANAGER AND DYNAMIC QUERY MODE
DATA SOURCES....................................................................................................... 24
5.1 CREATE A PROJECT, DATA SOURCE CONNECTION, AND PACKAGE FOR ORACLE ESSBASE ............ 24
5.2 CREATE A PROJECT, DATA SOURCE CONNECTION, AND PACKAGE FOR SAP BW ...................... 28
5.3 CREATE A PROJECT, DATA SOURCE CONNECTION, AND PACKAGE FOR IBM COGNOS TM1 ......... 32
6 IBM COGNOS 10 ADMINISTRATION........................................................... 36
6.1 ADMINISTRATION FEATURES SPECIFIC TO DYNAMIC QUERY MODE ...................................... 36
6.1.1 Status Tab ........................................................................................................ 36
6.1.2 Configuration Tab.............................................................................................. 36
7 IBM COGNOS 10 CACHING ......................................................................... 45
7.1 ONLINE ANALYTICAL PROCESSING (OLAP) CACHE ......................................................... 45
7.1.1 A Practical OLAP Cache Example......................................................................... 47
7.2 CONTEXT DEPENDENCY........................................................................................... 50
7.3 TO CACHE OR NOT TO CACHE .................................................................................. 51
8 TRANSITIONING FROM COMPATIBLE TO DYNAMIC MODE ....................... 52
Business Analytics
8.1 OLAP SCENARIOS ................................................................................................. 52

8.1.1 Nonadjacent Nesting of Levels from the same Hierarchy ....................................... 52
8.1.2 Nesting Levels from the Same Hierarchy in a different Hierarchical order than Defined
by theMetadata............................................................................................................ 54
8.1.3 Same Hierarchy on Multiple Edges ...................................................................... 56
8.1.4 Using % of Each Column Total within IBM Cognos Analysis Studio......................... 58
9 DEBUGGING AND TROUBLESHOOTING THE DYNAMIC QUERY MODE ....... 60
9.1 QUERY EXECUTION TRACE ....................................................................................... 60
9.1.1 Enabling the Query Execution Trace.................................................................... 60
9.2 QUERY PLANNING TRACE ........................................................................................ 61
9.2.1 Enabling the Query Plan Trace............................................................................ 61
9.3 CHANGING THE DEFAULT LOG OUTPUT DIRECTORY ........................................................ 62
9.4 IBM COGNOS DYNAMIC QUERY ANALYZER ................................................................... 62
9.4.1 Installing the IBM Cognos Dynamic Query Analyzer .............................................. 63
9.4.2 IBM Cognos Dynamic Query Analyzer Configuration ............................................. 63
9.4.3 Running a Report and Viewing the Remote Logs using the IBM Cognos Dynamic
Query Analyzer ............................................................................................................. 69
9.4.4 Dynamic Query Analyzer in Action: A Suppression Case Study .............................. 74
9.5 SUBMITTING A DYNAMIC QUERY MODE TEST CASE TO IBM COGNOS SUPPORT ...................... 79
Business Analytics
1 Introduction
1.1 Purpose
This document is intended to provide a single point of reference for
techniques and product behaviours when dealing with the Dynamic Query
Mode delivered with IBM Cognos 10.
1.2 Applicability
The techniques and product behaviours outlined in this document apply to:
• IBM Cognos Business Intelligence 10.1 build 4707.541
1.3 Exclusions and Exceptions

The techniques and product behaviours outlined in this document may not be
applicable to future releases.
2 Introduction to the IBM Cognos 10 Dynamic Query

Mode
The Dynamic Query Mode is an enhanced Java based query mode which
offers the following key capabilities.
• Query optimizations to address query complexity, data volumes and
timeliness expectations with improved query execution techniques.
• Significant improvement for complex OLAP queries through intelligent
combination of local and remote processing and better MDX
generation.
• Security-aware caching.
• New data Interfaces leveraging 64 bit processing.
• Ease of maintenance with query visualization.
2.1 Query Optimization

The optimization of the queries is achieved through the advanced application
of strict query planning rules. These planning rules incorporate the next
generation planning approach which is more streamlined and produces higher
quality and faster to execute queries. The query planning process is also in
itself optimized to make better use of metadata and expression level caches,
including plan caches which provide higher application throughput.
Business Analytics
2.2 Performance Improvement through Balanced Local Processing

Facilities
The Dynamic Query Mode makes intelligent, rules based and system load
based decisions on which parts of a query should be executed locally in the
application server versus remotely in the database server. This ensures that
users have the highest functionality possible regardless of whether the
underlying data source supports the business intelligence report intent. In
addition the Dynamic Query Mode contains a fine grained metadata and cell
data cache which is trickle fed and a higher cache hit ratio than was
previously possible. In addition the queries which are sent to remote data
sources are further optimized by the execution layer based on cache content
and advanced null suppression logic.
2.3 Security-Aware Caching

The caching logic available in Dynamic Query Mode is able, when connected
to secured metadata sources, to determine the secured access capabilities of
each user as they access the data source. This information is then used to
optimize the memory usage and internal representation of that user’s secured
view of the data source metadata. Security can also be setup so that entire
OLAP dimensions can be shared providing cache reuse and performance
gains.
2.4 New Data Interfaces Leveraging 64 bit Processing

The Dynamic Query Mode is a fully 64 bit capable environment for data
access. It permits the use of 64 bit data source drivers and can leverage the
64 bit address space for query processing, metadata caching and data
caching.
2.5 Ease of Maintenance with Query Visualization

Query visualization allows system administrators to analyze the queries
generated by the Dynamic Query Mode and visually see how they will be
processed. These visualizations include cost based information derived from
the query execution. This information permits the rapid identification of
model and query optimizations which could be applied in order to achieve
better performance.
Business Analytics
3 The IBM Cognos 10 Architecture

3.1 Architectural Diagram of Compatible Query Mode
Figure 1 The Compatible Query Mode Architecture
As seen in the picture above, the query mode architecture consists of several
layers. When a report request is received from one of the authoring studios,
the report viewer, or from any other source like the IBM Cognos Software
Development Kit (SDK), it will first be processed by the Query Planning layer.
The upper part of the Query Planning layer is the Query Framework (QFW).
QFW will inspect the report request and determine if it contains one or more
queries, and where the queries should be processed. OLAP style queries, like
those against SAP BW, Oracle Essbase and IBM Cubing Services type data
sources, will go to the OLAP query planner. Relational style queries against IBM
DB2, Oracle, Teradata type data sources will go to the relational query planner.
Dimensionally Modeled Relational (DMR) style queries go to the DMR query
planner.
Business Analytics
Each query planner will generate the appropriate query language and send the
request on to their respective query execution layer. For OLAP, the query
planner generates an MDX (Multidimensional Expressions) query and sends it
to the multidimensional data service (MDDS), for relational; it generates SQL
and sends it to the universal data access (UDA) module. For DMR, first a cube
build request is processed which will create and load a temporary cube, then a
new OLAP style query is generated and sent to be processed against that
temporary cube. The lowest layer of the architecture represents the individual
data source types and data sources that IBM Cognos BI supports. Queries
processed through MDDS or UDA will be converted to a query language dialect
that the data source understands and then sent to the data source using either
a direct proprietary interface, or through generic interfaces like ODBC or XMLA.
3.1.1 Basic Request Flow of a Compatible Query
Below is a list of acronyms and their meaning as used when describing the request
flows for various scenarios.
• MQP (Metadata Query Planner) - internal component that prepares
and executes metadata queries
• RQP (Relational Query Planner) - internal component that prepares
and executes relational queries (SQL) against databases
• OQP (OLAP Query Planner) - an internal component that prepares and
executes OLAP queries (MDX) against OLAP data sources
• PCODP (PowerCube/PC OLAP Data Provider) - internal component
that processes MDX and metadata queries against PowerCubes
• PPDS PCA (PowerPlay Data Service / PowerCube Adapter) - internal
libraries for PowerCube data access
• QF (Query Framework) - internal libraries for infrastructure and
integration of metadata queries, data queries, local data processing,
and result sets
• QFS (Query Framework Service) - internal API provided by QF
• QF Planner - converts from V5 Query to SQL or MDX using model
information
• QF Provider - executes and retrieves results corresponding to a query
(V5, SQL, MDX, or metadata)
• RSVP (Report Server) - BIBus service that calls QFS to execute
queries, plans layout and renders reports
• QS - Query Studio
• V5 Query - QF query consisting of data items and result (structure)
definitions
• V5 RS - QF query result set
Business Analytics
3.1.1.1 IBM Cognos 8 Query Studio Metadata Tree Request Flow
The following example outlines the request flow for populating the left had
metadata tree when first opening IBM Cognos 8 Query Studio.
Figure 2 IBM Cognos Query Studio Request Flow
• RSVP opens a session with QFS and sends a metadata request (2)
see qfs_commands.log:
<qs:command><connection><QFProviderType
value="MQProvider"/>...
• QFS hands the request to MQP according to the provider API (3)
see MQProvider_commands.log
• MQP open a session with QF and sends it requests directed at
PowerCubeODP provider (4,5)
see QFS_Commands.log:
<command><connection><dataSourceType
value="PowerCubeODP"/>...
• MQP Prepares metadata response based on PCODP responses (a,b)
and returns it to QFS (c)
• QFS hands the response back to RSVP (d)
Business Analytics
3.1.1.2 IBM Cognos 8 Query Studio Data Query Request Flow
The following example outlines the request flow for retrieving data when a
column is dragged from the left hand metadata tree into the list.
Figure 3 IBM Cognos Query Studio Data Request Flow
• RSVP opens a session (2) with QFS

see QFS_Commands.log
• RSVP sends a V5 Query request to QFS (2)
<connection><QFProviderTypevalue="QueryFrameworkServic
e"/> …
• QFS loads the default Provider as configured in qfs_config.xml
<defaultProvider value="CoordinationPlanner"/>
and hands it the query according to the provider API
• Coordination Planner calls the following query planning/providers to
prepare the V5 query (4~8): RefinerProvider, NoDataModeProvider,
MasterDetailProvider, ZeroSuppressionProvider, MDOperationProvider,
ReporterModeProvider, OlapQueryProvider
• All these providers respond with empty response (or the input query),
signaling that they don’t support any piece of the query except
Refiner (which modified the query) and OQP
• OQP responds with a a prepared query in the providerQuery
<providerQuery name="Query.0"
provider="OlapQueryProvider">
• Coordination Planner inspect the prepare responses from all providers
in the planning sequence and determines that only OQP is involved in
execution phase. It calls OQP to execute the prepared query (9)
• OQP sends a query to QFS directed at PowerCubeODP (10,11)
• PCODP RSAPI is returned to QFS, which hands it back to OQP (a,b,c)
• OQP Post Processing takes place and an RSAPI is returned to QFS,
which hands it back to RSVP (d,e)
Business Analytics
3.2 Architectural Diagram of Dynamic Query Mode
Figure 4 The Dynamic Query Mode Architecture
The architecture for the Dynamic Query Mode, although allowing for a very
similar flow of requests, is significantly different from the Compatible Query
Mode. The client layer at the top shows a systems management client which
interacts with the query mode to show metrics and statistics, and also to
change configuration settings such as logging for a running query.
The planning layers have been consolidated into a single one, called the
Transformation Layer. The transformation layer itself does not implement
any query planning logic, it merely provides an execution environment for
query transformations, which are kept in separate libraries called
transformation libraries. This provides for keeping the planning logic separate
from the planning layer. The transformation libraries provide query planning
logic for all supported OLAP queries and also support all functionality that the
query framework provides in the Compatible Query Mode.
Business Analytics
The Execution Layer supplies similar query execution capabilities to MDDS

and UDA in the Compatible Query Mode, but again consolidated into a single
mode. It can execute any query request, independent of the type of query or
target data source, and is able to execute SQL, MDX and XML all within a
single environment. This is in part enabled by the hybrid result set (HResult)
format which allows a single query result in memory to be presented in both
an OLAP style with axes, dimensions and cells) and a relational style (tabular,
row and columns). With HResult the execution mode can combine MDX and
XML in a single run tree, allowing for much higher flexibility and query
performance.
Figure 5 The Pieces of a Dynamic Query Mode Result
The data source adapter layer is very similar to that of the Compatible Query
Mode with the exception of interfaces used.
3.2.1 Basic Request Flow of a Dynamic Query

The Compatible Query Mode consists of a number of individual components
that each have a specific purpose and that together implement the query
planning and processing functionality. The Dynamic Query Mode only has two
major components, the transformation layer, and the execution layer,
although there are supporting components like the metadata framework etc.
Both modes share the same environment and work on the same query
objects called the plan tree and the run tree.
Business Analytics
A report request coming in to the Dynamic Query Mode will initially be

parsed into a plan tree. The parsing process will convert the incoming V5
query spec and any potentially embedded SQL or MDX queries into a tree
representation. The tree will have two main branches, the V5Query
(describing what the user wants to see) and the V5QueryResultSet (QRD)
which describes how the user wants to see the results (list or crosstab).
Figure 6 A Query Tree Representation
With the tree in place, the planning process can begin. The transformation
layer will apply an inference process (similar to forward-chaining) and check
for each node in the plan tree to see which query transformations apply to
that node. The query transformations implement the logic that can transform
an IBM Cognos query spec into a MDX query that a target data source can
understand.
This is done in several passes and potentially several iterations per pass until
all possible transformations have been applied.
During this process the transformation layer connects to the IBM Cognos 10
Content Manager through the metadata framework to look up model
information that applies to the query being processed.
When all transformations have been applied, the plan tree has morphed into
a run tree, and is now ready for execution.
Business Analytics
Figure 7 A simple MDX Run Tree
The run tree is at the heart of query execution and can consist of many
different types of run tree nodes. Nodes can be SQL execution nodes, MDX
execution nodes, local processing nodes, decoration nodes, and many more.
Results flow from the bottom of the run tree (leaf nodes) to the top (XTree
node) where the result is represented in RSAPI (Resultset API) format and
can be sent to the report service for rendering.
In the example above an MDX query (green nodes) is sent to an MDX data
source for execution. The results returned will go through some decoration
nodes (decoration is an internal process that allows the mode to distinguish
between different parts of a query result), then a node that will flatten the
result (MDX results are multidimensional by nature) and finally a sort node
which will process the flattened result and sort it. This is the simplest form of
an OLAP style query.
Business Analytics
4 Configuring IBM Cognos 10 Dynamic Query Mode Data

Source Connectivity
The IBM Cognos 10 Dynamic Query Mode is supported against the following
data sources.
• Oracle Essbase
• SAP BW
• TM1
Please be sure to reference the conformance page located at http://www-
01.ibm.com/support/docview.wss?uid=swg27014782 for a complete and up
to date listing of supported data sources.
Identical to IBM Cognos 8, IBM Cognos 10 requires that the data source
client connectivity is installed on all IBM Cognos 10 Framework Manager and
Report Server machines that are to perform data access. For the OLAP
sources listed above, IBM Cognos 10 will use the same data source
connectivity install for both dynamic and compatible queries. The following
sections will explain each data source connectivity type in more detail.
4.1 Understanding How IBM Cognos 10 Connects to Oracle Essbase

Both IBM Cognos 10 Compatible Query Mode and Dynamic Query Mode use
the same Oracle Essbase client install. The IBM Cognos 10 Compatible Query
Mode use the grid API from the Oracle Essbase bin directory whereas the IBM
Cognos 10 Dynamic Query Mode uses JAR files located in the Oracle Essbase
JavaAPI lib directory. Both types of files are located using the Oracle Essbase
environment variables created by the Oracle Essbase client install. The table
below outlines the file names and environment variables used by each of the
IBM Cognos 10 query modes.
Oracle Essbase 9.3.X Oracle Essbase 11.1

Environment Connectivity File Environment Connectivity File
Variable Name(s) Variable Name(s)
IBM Cognos ARBORPATH Essapinu* ESSBASEPATH Essapinu*
10 Compatible
Query Mode
IBM Cognos ARBORPATH Ess_es_server.jar ARBORPATH Ess_es_server.jar
10 Dynamic Ess_japi.jar Ess_japi.jar
Query Mode
Cpld14.jar
When IBM Cognos 10 connects to an Oracle Essbase 9.3.X data source, it will
use the ARBORPATH for both query modes to locate the client libraries.
However, when using IBM Cognos 10 against an Oracle 11.1 data source,
Compatible Query Mode queries will use the ESSBASEPATH, while Dynamic
Query Mode queries will use the ARBORPATH. Typically the ESSBASEPATH
and ARBORPATH will be set to the same location within the Oracle Essbase
install.
Business Analytics
4.2 Step by Step Example of Configuring the Oracle Essbase Connectivity

for use within IBM Cognos 10
The following section will provide the step by step instructions for configuring
the Oracle Essbase connectivity for use with a Windows install of IBM Cognos
10. This section assumes that the Oracle Essbase client was successfully
installed.
1. From the Start\Run menu type in cmd and hit the enter key. This will
bring up a command prompt window.
2. Within the command prompt window, type in Esscmd and press the enter
key. If the Oracle Essbase client was installed successfully, the Oracle
Essbase command prompt should launch and display the version.
Figure 8 ESSCMD Command Window Displaying the Oracle Essbase

Version
3. If the Oracle Essbase release version is 11.1 no further configuration is

required. If the release version is 9.3.X then proceed to the next step.
4. Locate the c10\configuration\qfs_config.xml file and make a backup
copy.
5. Open the original qfs_config.xml file using a text editor.
6. Locate the following section:

<provider name="DB2OlapODP" libraryName="essodp111"
connectionCode="DO">
7. Remove the comment tags from the essodp93 provider.

8. Comment out the essodp111 provider. Once completed the entry should
now represent the following:
<provider name="DB2OlapODP" libraryName="essodp93"
connectionCode="DO">

9. Save the changes and close the file.
Business Analytics
10. The changes to this file will be picked up once a Stop and Start is done on
the IBM Cognos 10 service.
4.3 Oracle Essbase Data Source Specific IBM Cognos 10 Configuration

Settings
The following section discusses any IBM Cognos 10 configuration settings
within the eb.properties file which are available when using Oracle Essbase as
a data source.
4.3.1 Treat Nulls as Zeros within Calculations
Impacts: The result of calculations on data items that contain null data
values.
Usage: This parameter controls whether or not null data values are treated as
zeros when used in calculations. If the parameters are enabled, 100 + null
would result in 100. If the parameters are disabled, 100 + null would result
in null.
By default, these parameters are disabled.
Interoperability with other parameters: None
Setting this parameter: This parameter is available within the

C10/configuration/xqe/eb.properties file as the following section.
null.plus.operator=null
null.minus.operator=null
null.multiply.operator=null
null.divide.numerator=null
null.divide.denominator=null
null.modulo.dividend=null
null.modulo.divisor=null
To enable this feature, change the null values to zero. A completed entry
would represent the following.
null.plus.operator=zero
null.minus.operator=zero
null.multiply.operator=zero
null.divide.numerator=zero
null.divide.denominator=zero
null.modulo.dividend=zero
null.modulo.divisor=zero
These changes will be picked up once the IBM Cognos 10 service is restarted.
After the restart, this change will affect all queries against any Essbase data
source through IBM Cognos 10. In a distributed environment, this change
will need to be made on all IBM Cognos 10 servers performing data access.
Business Analytics
4.4 Understanding How IBM Cognos 10 Connects to SAP BW

Since both IBM Cognos 10 query modes use the same SAP BW client and the
same librfc32 client library, no additional configuration is required beyond the
actual install of the SAP BW client. The only exception to this is covered by
the following section.
4.5 Step by Step Example of Configuring the SAP BW Connectivity for use
within IBM Cognos 10 (64 bit only)
When IBM Cognos 10 is installed as a 64 bit application, Compatible Query

Mode queries will require the 32 bit librfc32 client library and Dynamic Query
Mode queries will require the 64 bit librfc32 client library. Since both 32 and
64 bit libraries have the same name, the only way to tell them apart visually
is by their file size.
The following section provides the steps required to enable SAP BW
connectivity for both Compatible Query Mode and Dynamic Query Mode
queries when IBM Cognos 10 is installed as a 64 bit application.
1. Obtain both the 32 bit and 64 bit librfc client libraries from the SAP BW
Administrator.
Figure 9 Image Displaying the 32 and 64 Bit Librfc Client Library
2. Copy the 32 bit library into the C10\bin directory.

3. Copy the 64 bit library into the C10\bin64 directory.
4. These client libraries will be picked up once the IBM Cognos 10 service is
stopped and started.
4.6 SAP BW Data Source Specific IBM Cognos 10 Configuration Settings

within the bw.properties file which are available when using SAP BW as a
data source.
Business Analytics
4.6.1 Treat Nulls as Zeros within Calculations

Impacts: The result of calculations on data items that contain null data
values.
Usage: This parameter controls whether or not null data values are treated as
zeros when used in calculations. If the parameters are enabled, 100 + null
would result in 100. If the parameters are disabled, 100 + null would result
in null.
By default, these parameters are disabled.
Interoperability with other parameters: None

C10/configuration/xqe/bw.properties file as the following section.
null.plus.operator=null
null.minus.operator=null
null.multiply.operator=null
null.divide.numerator=null
null.divide.denominator=null
null.modulo.dividend=null
null.modulo.divisor=null
To enable this feature, change the null values to zero. A completed entry
would represent the following.
null.plus.operator=zero
null.minus.operator=zero
null.multiply.operator=zero
null.divide.numerator=zero
null.divide.denominator=zero
null.modulo.dividend=zero
null.modulo.divisor=zero
These changes will be picked up once the IBM Cognos 10 service is restarted.
After the restart, this change will affect all queries against any SAP BW data
source through IBM Cognos 10. In a distributed environment, this change
will need to be made on all IBM Cognos 10 servers performing data access.
4.7 Understanding How IBM Cognos 10 Connects to IBM Cognos TM1

For this data source, only the IBM Cognos 10 windows install require the
installation of the IBM Cognos TM1 client. The IBM Cognos 10 UNIX installs
contain the IBM Cognos TM1 client software as part of the install package.
This means no additional configuration or installs are required and the IBM
Cognos 10 should be able to connect to IBM Cognos TM1 out of the box. On
windows, IBM Cognos 10 uses a registry setting created by performing a
custom install of only the IBM Cognos TM1 client from the IBM Cognos TM1
server install media to locate the TM1API.dll. This dll in turn enables IBM
Cognos 10 to connect to the cubes on an IBM Cognos TM1 server.
Business Analytics
4.8 Step by Step Example of Configuring the IBM Cognos TM1

Connectivity for a Windows Install of IBM Cognos 10
The following section provides the steps required to enable IBM Cognos TM1
connectivity for both Compatible Query Mode and Dynamic Query Mode
queries when IBM Cognos 10 is installed on a Windows operating system.
1. After downloading the IBM Cognos TM1 9.5.1 Server install package,
extract the contents of the archive to a directory.
2. Within the directory created in the previous step, double click on the
setup.exe to initiate the installation procedure.
3. Once the upgrade warning message has been thoroughly read, press the OK
button to continue.
4. Click Next.
5. If the license agreement is acceptable, select the I accept… radio button and
then click the Next button to continue with the install.
Figure 10 IBM Cognos TM1 Install Screen Displaying the TM1

Component Selected.
6. From the available product selection, ensure the TM1 product is selected
before clicking the Next button.
7. Thoroughly read the .Net Framework warning button before clicking the OK
button.
Business Analytics
Figure 11 IBM Cognos TM1 Install Screen Displaying the Install Path
and the Custom Install Selection
8. Choose an install path outside of the IBM Cognos 10 directory structure. For
this example the Install to directory will be C:\Program Files\Cognos\TM1.
9. From the available menu option, select the Custom Installation type and click
the Next button to proceed.
Figure 12 IBM Cognos TM1 Install Screen Displaying the TM1 OLEDB
Provider Selected for Install
10. From the available install components, ensure that all the components except
the TM1 OLEDB Provider are omitted from the install.
Business Analytics
Figure 13 IBM Cognos TM1 Install Screen Displaying that no Items are
Required for TM1 Client Configuration
11. Clear all the settings and click the Next button.
12. Click the Install button to finish the install.
13. This client library will be picked up once the IBM Cognos 10 service is stopped
and started.
4.9 IBM Cognos TM1 Data Source Specific IBM Cognos 10 Configuration
Settings
within the qfs_config.xml file which are available when using IBM Cognos
TM1 as a data source.
4.9.1 UseNonEmptyOnDataQueryThreshold
Impacts: Member fetches for IBM Cognos 10 reports using the Dynamic
Query Mode.
Usage: This parameter controls the decision on whether or not to apply a
NON EMPTY clause on member requests when the number of tuples exceeds
the set threshold. Applying the NON EMPTY clause allows the MDX to only
return members that have measure data. If no measure is projected in the
MDX, the default measure is assumed.
By default, this parameter is set to 0 which disables this feature. A value of 1

is used to enable this feature.
Interoperability with other parameters: When enabled, this parameter is used

in conjunction with the UseProviderCrossJoinThreshold parameter.

C10/configuration/qfs_config.xml file under the TM1OlapODPXQE provider.
<parameter name="UseNonEmptyOnDataQueryThreshold" value="1"/>
Business Analytics
Changes to this file are picked up once IBM Cognos 10 is restarted and are
applied globally on per IBM Cognos 10 install basis.
4.9.2 UseProviderCrossJoinThreshold
Impacts: Member fetches for IBM Cognos 10 reports using the Dynamic
Query Mode.
Usage: This parameter controls the decision on when the NON EMPTY clause
is applied to the query MDX. If the number of tuples, calculated by using the
Cartesian product, exceeds the set threshold; the NON EMPTY clause is
applied to the query. The application of the NON EMPTY clause, alters the
query from returning all members, to just returning those that have measure
values.
By default, this parameter is set to 0 which disables this feature. A value of
greater than one is used to enable this feature. The ideal value for this
setting will vary on per environment basis, however a good starting point
would be 10000 tuples.
Interoperability with other parameters: This parameter is used in conjunction

with the UseNonEmptyOnDataQueryThreshold parameter.

C10/configuration/qfs_config.xml file under the TM1OlapODPXQE provider.
<parameter name="UseProviderCrossJoinThreshold" value="10000"/>
Changes to this file are picked up once IBM Cognos 10 is restarted and are
applied globally on per IBM Cognos 10 install basis.
Business Analytics
5 IBM Cognos 10 Framework Manager and Dynamic

Query Mode Data Sources
In IBM Cognos 10 Framework Manager, when a package is published to IBM
Cognos 10, modelers can decide which query mode will be used when running
reports against that package. If you wish to switch the query mode for a
package, you must republish the package with the desired setting.
Packages must only contain supported Dynamic Query Mode data sources to
enable Dynamic Query Mode. If unsupported data sources are included in the
package, an error message will be received when trying to publish the package.
In order to take advantage of the IBM Cognos 10 Dynamic Query Mode, ensure
your IBM Cognos 10 environment is configured for connectivity to the supported
data sources. Please see section 4 for more details.
The following topics in this section will illustrate how to configure each
supported Dynamic Query Mode data source and how to publish packages that
use the new query service.
Data source connections can be created in either IBM Cognos Connection or

through IBM Cognos 10 Framework Manager. In these examples, IBM Cognos
10 Framework Manager will be used; however, the configuration steps are the
same.
5.1 Create a Project, Data Source Connection, and Package for Oracle
Essbase
Ensure the Oracle Essbase client is installed and configured on the IBM Cognos
10 Framework Manager machine and any IBM Cognos BI servers for
connectivity to Oracle Essbase.
Oracle Essbase data sources must be published to IBM Cognos 10 through
Framework Manager.
1. Open IBM Cognos 10 Framework Manager, and then click Create a new
project.
2. In the Project name box, type the desired name, in this case Oracle
Essbase - GO Sales will be used, and then click OK.
The Select Languages dialog box appears.
3. Select the desired design language, in this case English will be selected, and
then click OK.
The Metadata Wizard appears.
4. Ensure Data Sources is selected, and then click Next.
5. Click the New button to create a new data source connection.
6. In the New Data Source wizard, click Next, in the Name box, type Oracle
Essbase, and then click Next.
7. Under Type, select Oracle Essbase.
Business Analytics
Figure 14 New Data Source Wizard
8. Click Next.
9. Based on the information provided by the Oracle Essbase administrator, type

in the Server name and configure the Signon credentials.
Figure 15 New Data Source Wizard – Signon
10. Click Test the connection, and then click Test.

On the results page of the connection test, notice the results under the
Type/Query Mode column.
Business Analytics
Figure 16 Test the connection – results
Compatible is the Compatible Query Mode and Dynamic is the new

Dynamic Query Mode.
11. Click Close, click Close again, and then click Finish.
12. Click Close.
The new data source appears in the list.
Figure 17 Metadata Wizard - Select Data Source
The next step will be to import a cube and publish it to IBM Cognos 10.
13. Ensure the Oracle Essbase data source that was created is selected, click
Next, and then locate and select the desired cube.
14. Click Next, and then select the desired language for the cube and how
attribute dimensions should be presented.
Figure 18 Metadata Wizard - Select Locales
Business Analytics
15. Click Next, leave the Create a default package option selected, and then
click Finish.
16. In the Name box, type an appropriate name for the package, in this case
Oracle Essbase - GO Sales will be used, click Finish, and then click Yes to
open the Publish Package wizard.
17. Follow the wizard instructions making the appropriate configurations required
and click Next until the Options screen is reached.
Notice the Use Dynamic Query Mode option.
Figure 19 Publish Wizard – Options
18. Select the Use Dynamic Query Mode option, click Publish, and then click
Finish.
The package is now available in IBM Cognos 10 and will use the Dynamic
Query Mode for reports. In IBM Cognos Connection, the type of query mode
used by the package can be verified in the package properties.
Figure 20 Package Properties
Business Analytics
5.2 Create a Project, Data Source Connection, and Package for SAP BW
Ensure the SAP GUI is installed and configured on the IBM Cognos Framework
Manager machine and any IBM Cognos BI servers for connectivity to SAP BW.
See section 4.4 for more details.
An SAP BW package can be published directly from IBM Cognos Connection or
through Framework Manager. However, importing SAP BW metadata into
Framework Manager allows for additional modelling and testing before the
package is published. In this example, Framework Manager will be used. For
information on publishing SAP BW packages directly in IBM Cognos
Connection, please see the IBM Cognos 10 Administration and Security Guide.
project.
2. In the Project name box, type the desired name, in this case SAP BW - GO
Sales will be used, and then click OK.
then click OK.
6. In the New Data Source wizard, click Next, in the Name box, type SAP
BW, and then click Next.
7. Under Type, select SAP BW.
8. Click Next.
9. Based on the information provided by the SAP BW administrator, select the
SAP logon type, type in the Application server name, System number,
Client number and provide the security signon configuration.
Business Analytics

The results appear as shown below.
Figure 23 Test the connection – results
Compatible is the Compatible Query Mode and Dynamic is the new Dynamic
Query Mode.
12. Click Close.
Business Analytics
The next step will be to import SAP BW metadata.

13. Ensure the SAP BW data source that was created is selected, click Next, and
then locate and select the desired reporting objects (InfoQuery, InfoCube,
etc) for import.
14. Click Next, add the desired languages, and then click Next.
Figure 25 Metadata Wizard - Select Languages to import
15. On the Generate Dimensions screen, select how you want to display object
names and organize the dimensions.
Figure 26 Metadata Wizard - Generate Dimensions
16. Click Next to import the metadata, and then click Finish.
Business Analytics
17. In the Project Viewer, expand the new namespace created for the SAP BW
metadata and notice all the dimensions and key figures have been imported.
Figure 27 Project Viewer
For more information about working with SAP BW metadata, please refer to
the IBM Cognos 10 Framework Manager User Guide.
In the next steps, a package will be created and published.
18. In the Project Viewer, right-click Packages, point to Create, and then
click Package.
SAP BW - GO Sales will be used, click Next, and then select the objects to
include in the package.
Figure 28 Create Package - Define objects
20. Click Next, click Finish, and then click Yes to open the Publish Package
wizard.
22. Select Use Dynamic Query Mode.
Business Analytics
Figure 29 Publish Wizard - Options
23. Click Publish, and then click Finish.

Query Mode for reports and analyzes.
5.3 Create a Project, Data Source Connection, and Package for IBM
Cognos TM1
Ensure the IBM Cognos TM1 client is installed and configured on the IBM
Cognos Framework Manager machine and any IBM Cognos BI servers for
connectivity to TM1. See section 4.7 for more details.
IBM Cognos TM1 packages must be published through IBM Cognos 10
Framework Manager.
project.
2. In the Project name box, type the desired name, in this case IBM Cognos
TM1 - GO Sales will be used, and then click OK.
then click OK.
6. In the New Data Source wizard, click Next, in the Name box, type IBM
Cognos TM1, and then click Next.
7. Under Type, select IBM Cognos TM1.
Business Analytics
8. Click Next.
9. Based on the information provided by the IBM Cognos TM1 administrator,
type in the Administration Host, Server Name, and Signon credentials.
The Administration Host is the name of the physical machine hosting
the IBM Cognos TM1 server(s). The Server Name refers to the name
of the cube being served by an IBM Cognos TM1 server on the
administration host machine.
Business Analytics
Compatible is the Compatible Query Mode and Dynamic is the new Dynamic
Query Mode.
The results appear as shown below.
Figure 32 Test the connection - results
12. Click Close.
The next step will be to import the cube and publish it to IBM Cognos 10.
13. Ensure the IBM Cognos TM1 data source that was created is selected, click
Next, and then select the cube for import.
Figure 34 Metadata Wizard - Select Cube
14. Click Next, add if required, select each dimension and the Alias tables
language you wish to import.
Business Analytics
Figure 35 Metadata Wizard - Select Locales
15. Click Next, leave the Create a default package option selected, and then
click Finish.
IBM Cognos TM1 - GO Sales will be used, click Finish, and then click Yes
to open the Publish Package wizard.
18. Select Use Dynamic Query Mode.
Figure 36 Publish Wizard - Options
19. Click Publish, and then click Finish.

Query Mode for reports and analyzes.
Business Analytics
6 IBM Cognos 10 Administration

6.1 Administration Features Specific to Dynamic Query Mode
With the introduction of Dynamic Query Mode, new elements are available in
IBM Cognos 10 Administration to configure, tune, and troubleshoot the new
query service. The following sections will identify the new UI elements and
briefly describe each.
6.1.1 Status Tab
In IBM Cognos 10 Administration, metrics for the Query Service can be seen
on the Status tab under System. Navigate to the QueryService service in the
Scorecard pane to view metrics as well as Logging and Tuning settings.
Figure 37 IBM Cognos Administration - Status tab - System
The Scorecard pane indicates which servers, dispatchers, and services are
available and allows for administrative tasks such as starting and stopping the
service or setting properties.
The Metrics pane displays statistics and just as with other services, certain
metrics have configurable thresholds. They are edited by clicking the Edit icon
(pencil) to the right of each metric.
The Settings pane indicates how the selected item in the Scorecard pane is
configured. The Logging and Tuning settings can be edited in this section as
well by clicking on the Set properties icon in the top right corner of the
Settings pane. They can also be edited in the Dispatchers and Services
section under the Configuration tab, which is discussed in the next section.
6.1.2 Configuration Tab
On the Configuration tab, there are four locations pertaining to the Dynamic
Query Service.
Business Analytics
• Data Source Connections for configuring data sources including

supported Dynamic Query Mode data sources
• Content Administration for scheduling Query service
administration tasks
• Dispatchers and Services for configuring the QueryService service
• Query Service Caching to immediately perform cache tasks
Data Source Connections

As shown earlier, Data Source Connections under the Configuration tab is
where data sources are created for IBM Cognos 10.
Figure 38 IBM Cognos Administration - Configuration tab - Data Source

Connections
Supported data sources for Dynamic Query Mode will indicate a successful
connection through the Dynamic Query service when testing the connection.
Figure 39 Test the connection - results
Business Analytics
Content Administration
Content Administration under the Configuration tab now has a New Query
service administration task icon as shown below.
Figure 40 IBM Cognos Administration - Configuration tab - Content

Administration
The tasks available for this new feature are the ability to clear the Dynamic
Query cache (to avoid using outdated data) or to write the cache state (for
cache use analysis) to a file on the IBM Cognos 10 server(s).
For IBM Cognos TM1, there is no caching on the IBM Cognos 10 side;
therefore these tasks do not apply to that data source.
Each task can be scheduled and configured as required.
Figure 41 New Query Service Administration Task Wizard
Here you can specify a specific data source, catalog and cube name, or use
the * character to clear all items for any of the entries above.
Business Analytics
For example, to write the cache state file for an Oracle Essbase cube, the
settings would be similar to what is shown below.
Figure 42 New Query Service Administration Task Wizard
Notice cube and catalog name are the same.
Note: To find the correct syntax to enter for these tasks, once you have run
a report against the data source in question, you can use the Write cache
state feature (discussed in the Query Service Caching section to follow) to
write the cache state file for all caches. In that file you can see the
appropriate syntax for Data source, Catalog, and Cube for the data source
you are concerned with and enter it in the task wizard.
The Write the cache state setting will write a time-stamped XML file showing
the state of specified caches, which can be helpful to verify caches are being
cleared and for troubleshooting purposes under the guidance of IBM Cognos
development.
The XML file is written to the <C10 Install Location>/logs/XQE directory. The
filename has the following format:
SALDump_prefix_datasource name_category name_cube

name_timestamp.xml
Example:
SALDump_Essbase_GODB_GODB_1281624776529.xml
Business Analytics
Sample file output:

<?xml version="1.0" encoding="UTF-8" ?>
<xqeCacheMetric>
<dataSource type="EB">
Essbase
<catalog>
GODB
<cube>
GODB
<model>/content/package[@name='Essbase']/model[last()]</model>
<status>Active</status>

<totalrequests>591</totalrequests>
<cachehitcount>587</cachehitcount>
<cachemisscount>4</cachemisscount>

<dimension>[Order Method]</dimension>
<dimension>[Product]</dimension>
<dimension>[Retailer Geography]</dimension>
<dimension>[Retailer]</dimension>
<dimension>[Sales Staff]</dimension>
<dimension>[Sales Territory]</dimension>
<dimension>[Time]</dimension>
</cube>
</catalog>
</dataSource>
</xqeCacheMetric>
When these administration tasks are run, all server groups are affected. In
other words, depending on the task run, each IBM Cognos 10 report server
will either have its cache cleared for the specified data source, or have the
cache state file written to its local logs/XQE directory.
Again, in a practical application, the cache state file can be used to validate
cache clearing as shown below.
<?xml version="1.0" encoding="UTF-8" ?>

<xqeCacheMetric>No cached cube found matching the criteria: dataSource
name = Essbase catalog name = GODB cube name =
GODB</xqeCacheMetric>
Business Analytics
Dispatchers and Services

In Dispatchers and Services under the Configuration tab, there is now a
QueryService item which is used to configure settings for the Dynamic Query
Mode.
Figure 43 IBM Cognos Administration - Configuration tab - Dispatchers and

Services
The service includes the following configurable settings.
Figure 44 QueryService - Properties
The Advanced settings and Audit logging level are standard settings for all
services. Advanced settings allow for additional service settings provided by
IBM for specific and typically less common scenarios.
Business Analytics
• Enable query execution trace?

Enables or disables a query execution trace. Enabling the query
execution trace setting will write information such as the native MDX
to a run tree log within the <cognos_install_dir>/logs/XQE directory.
Profiler information is also written to capture execution and waiting
time metrics for query constructs. Since a log is generated for each
report that is executed, the log file adheres to the following naming
convention.
timestamp_reportName/runtreeLog.xml
timestamp_reportName/profilingLog-#.xml
As an example, executing a report called top_sales would result in a

log file named 2010-05-10_11h33m700s_top_sales/runtreeLog.xml
and one or several profiler logs named 2010-09-
10_11h33m700s_top_sales/profilingLog-0.xml, 2010-09-
10_11h33m700s_top_sales/profilingLog-1.xml, …etc.
Some report execution requires executing sub-queries. Sub-queries

execution trace is stored under a separate directory within the main
report directory. The sub-query directory contain the same logging
elements as the main report, runTreeLog.xml and profilingLog-#.xml.
If executing the report top_sales- requires the execution of one or

more sub-queries, the trace for those sub-queries is stored in 2010-
09-10_11h33m700s_top_sales/subqueries
These files can be analyzed with the Dynamic Query Analyzer which is
covered in Section 9.4 of this book.
• Enable query planning trace?

Enables or disables query plan tracing, also known as a plan tree,
which captures the transformation process of a query. You can use
this information for advanced understanding of the decisions and rules
that are executed to produce an execution tree. The query planning
trace is logged for every query that is executed using Dynamic Query
Mode. The planning trace logs are located on the report server
servicing the request in the following location:
<C10 Install Location>/logs/XQE/reportName/plantreeLog.xml
Since planning logs are large, there may be an impact on query

performance when this setting is enabled.
Business Analytics
• Disable query plan caching?

Specifies whether the service caches query plans for possible re-use.
Caching the query plan takes additional resources and may not be
suitable for your environment. For example, if the environment does
not have a lot of CPU power and the nature of the end user requests
are most likely different each time, using the Query Plan Cache would
not make sense.
• Idle connection timeout

Specifies the number of seconds to maintain an idle data source
connection for re-use. The default setting is 300. Valid entries are 0 to
65535. Lower settings reduce the number of connections at the
expense of performance. Higher settings may improve performance
but raise the number of connections to the data source.
• Write model to file?

Specifies if the query service should write the model to a file when a
query is executed. The file is used only for troubleshooting purposes,
under the guidance of Customer Support. The file is written to the
following location:
<C10 Install Location>/logs/model/packageName.txt
Query Service Caching

It may be necessary to clear the cache manually if the data source data
changes infrequently or if it is required to clear the cache in between
automatically scheduled cache clearing.
The Query Service Caching section under the Configuration tab allows for
manual Dynamic Query cache clearing and writing the cache state to file for
one or more server groups.
Figure 45 IBM Cognos Administration - Configuration tab - Query Service

Caching
For more information on server groups, please see the IBM Cognos 10
Administration and Security Guide.
Business Analytics
Again, the Write cache state feature will write a time-stamped XML file to the
<C10 Install Location>/logs/XQE directory showing the state of all caches.
The filename in this instance has the following format:
SALDump_all_all_all_timestamp.xml
In a distributed installation, each report server that has a cache will write the
cache state file to its local logs directory.
Business Analytics
7 IBM Cognos 10 Caching

While most releases of IBM Cognos BI have some level of caching, this latest
release has increased the offering and ensures the implementation will allow
performance improvements unparalleled by its predecessors. This capability is
pertinent to SAP BW and Oracle Essbase data sources.
The main purpose of the cache is to leverage previously executed results for
reuse and whenever possible; avoid roundtrips to the database. The
performance benefits of the cache will be noticeable when:
• reports are re-executed with small modifications
• analysis is performed within the same cube
• repetitive master detail requests are performed for large reports
The cache loading mechanism is performed as requests are received and
executed.
7.1 Online Analytical Processing (OLAP) Cache

IBM Cognos v8.2 to v8.4 leveraged a metadata/data fetch concept when
querying certain data sources. With the level of complexity of reports
currently being authored, a greater local processing control yielded
performance benefits. Alternatively, some data sources still leveraged
remote type approach where processing was pushed down to the respective
databases.
The basic principle behind the local processing approach, which is the default
DQM behaviour for Oracle Essbase and SAP BW, is to retrieve the basic raw
data from the underlying data source and process everything else locally.
While generalized here since some level of aggregation, filtering, and other
simple functions may still be sent to the data source, the local approach
ensures we avoid pitfalls occasionally incurred when trying to push complex
native SQL/MDX to the querying data source resulting in poor performance.
At this time, only the local processing approach leverages the secured cache.
The local approach to OLAP reporting is broken down into two simple steps:
metadata and data fetch. When a report is executed, we initially retrieve all
members requested (metadata), either by level and/or unique member
inclusion, and then utilize the retrieved members in order to construct the
MDX used for data retrieval (facts). As these calls are performed, for both
metadata and data requests, each results returned is cached and can
potentially be reutilized when further requests are made within the same
context.
Business Analytics
The concept of context is important to understand in the realm of the

secured cache. It identifies a result based on what was requested. For
example the context will be built using who the query was executed by,
which cube was queried, which particular year was used for filtering, etc… In
essence, anything that narrows the scope of a result which is also sent to the
data source will be considered a context. If any subsequent requests are
made within the same context, the cached results will be used. The context
may affect both metadata and data cache.
SAP BW data sources can still leverage remote processing. This method relies
on the underlying data source to process the entire MDX requests (minus
some exceptions). This capability can be leveraged by changing the query
processing to “Database Only” as explained in the next paragraph. Some
reports lend themselves very well to this type of processing – for example
simple grouped lists report such as target reports for drill-through. In these
scenarios, since the report complexity is greatly reduced, the entire request
will benefit from avoiding the metadata fetch portion and simply retrieve the
data and present it to the user. However, this result will not leverage the
cache and cannot be reused.
In order to force the behaviour of a particular mode (local vs remote) on a

query by query basis, a query hint must be changed. Within Report Studio,
simply select the query in question, then, in the left hand pane, select the
desired “Processing” under query hints. The default option will follow the
server’s default behaviour, “Database only” will force remote behaviour, and
“Limited Local” will force local behaviour. Please note this change is only
feasible in Report Studio at this time. All other studios will use the default
local approach processing.
Figure 46 IBM Cognos Report Studio Query Properties
Business Analytics
7.1.1 A Practical OLAP Cache Example

We are interested in building a report retrieving all product sales for all
customers within each sales region for 2009. A list report is created by
nesting and grouping three dimensions – Sales region, Customer,
Product. We are interested in two measures, Quantity purchased and Unit
Price. Since we are only interested in last year’s results, we also add a slicer
for Year 2009. The report is then executed.
Figure 47 IBM Cognos Report Studio Simple List Report
The reporting mode will fetch sequentially all members for sales regions,
customers, and products and store the results in the cache.
Business Analytics
Figure 48 IBM Cognos Report Studio Report Displaying how the Column
Map to the Metadata Cache
It will then use the enumerated members to construct an MDX statement in

order to retrieve the nested members with the measures requested.
Figure 49 Image Showing the MDX Required for the Data Request
Business Analytics
The simplified constructed MDX will then be sent to the data source to
retrieve the fact data. The result set will initially be stored in the cache to
subsequently produce the desired output.
Figure 50 Image Showing the MDX Required for the Data Request and how
it Links Back to the IBM Cognos Report Studio Report
Business Analytics
Two phases took place here, the metadata phase to extract all requested
members, and a second phase fetching those members with fact data.
At this time, if the report author adds a calculation (i.e. Quantity x Unit Price),
given the calculation involves the same members and the same measures,
the reporting mode can reuse the metadata and data from the previous
request therefore bypassing the data source in order to produce the desired
output. This is possible given what is requested from the database does not
change since calculations are processed locally.
Figure 51 Image displaying the Request Flow using the Cache for a
Calculation
Alternatively, if the user then decides to add another measure from the data
source, we will be able to reuse the metadata (first phase) but will need to
re-execute the data fetch (second phase) given a new measure has been
added.
While this example oversimplifies the cache, the demonstrated principle

remains.
7.2 Context Dependency

As mentioned earlier, the cache is also context dependant. In the example
given above, the year, although not included/projected in the report, serves
as a context as it is used in a slicer. The data retrieved is in context of year
2009. Filtering on a different year or adding another filter would offer a new
cache context at which time the previous cache may not be reusable.
Business Analytics
Another important context is the user. Each data source may/can have the
possibility of securing their data based on proprietary authorization rules and
techniques. Therefore, user X may be entitled to view all data while user Y
may be limited to view a limited portion of the data. As a result, each user id
becomes a context of there own and metadata/data cannot be shared
amongst them.
7.3 To Cache or Not to Cache

It should be noted that not all data requests will be cached. Some types of
requests/results would not benefit from being cached. For example, very
large batch type reports which results in hundreds or thousands of pages
would spend more time writing results to the cache then it would take re-
executing the same request subsequent times. As well, some queries perform
well when executed on the underlying data source and may not benefit from
using the cache.
The Dynamic Query Mode must determine whether a result can be stored in
the cache using a number of data points collected at runtime. These include
the density of a result set, size of a result set, amount of time taken to
execute the MDX, etc… By default, we will only cache tuples potentially
smaller then 150,000. This limit is conservative and can easily be increased to
15,000,000 or even 150,000,000. Please note that this number relates to the
potential size of the result which is calculated by multiplying all included
members from each dimension by all members of the other dimensions. For
example, if a report is authored by nesting Regions by Products for one given
measure and ten (10) regions exist and ten (10) products exist, then the
potential result is 100 (10 x 10 x 1).
This setting can be increased by opening bw.properties (SAP BW) or
eb.properties (Essbase) and increasing the following setting:
lolap.tupleStorageThreshold=150000
Other configurations exist but should not be tampered with unless specifically
recommended by Customer Support or IBM Cognos Development as they use
pre-determined metrics to write and read from the cache which were
predetermined as per local testing.
From a performance perspective, please note that each result is stored in
context of all dimensions in the published package. While many factors affect
read/write performance from the cache, having a high number of dimensions
will have a negative impact on cache performance. Some considerations
should be taken into account when creating packages for consumers and limit
the dimension choice to what is really required. This may not be noticeable
for most packages but is worthwhile mentioning.
Business Analytics
8 Transitioning from Compatible to Dynamic Mode

Although every effort was made to allow users to effortlessly transition
reports from Compatible Query Mode to Dynamic Query Mode; there may be
scenarios where reports behave differently when migrated. These differences
can be explained by the fact that the Dynamic Query Mode applies clear
behaviour rules consistent with the behaviour of related constructs to all
applicable cases. In cases where these rules cannot be applied, the report
will fail with an error message identifying the underlying issue. The following
section discusses these cases in more detail.
8.1 OLAP Scenarios

8.1.1 Nonadjacent Nesting of Levels from the same Hierarchy
When using OLAP based packages, reports with nonadjacent levels from the
same hierarchy will produce the following error:
XQE-PLN-0212 The report nests more than one level from the same
hierarchy but they are not adjacent to each other. Please make levels
from the same hierarchy adjacent.
The following case study will step a user through the transition of a report in
which the Report Author utilizes a levels from the same hierarchy in a
nonadjacent format. A crosstab projects the Sales region, Product line, and
the Country respectively on the rows of the crosstab. The Years are projected
on the column. The Quantity is the measure of the crosstab. The report
layout is depicted below:
Figure 52 A Crosstab Projects the Sales region, Product line, and the
Country respectively on the rows of the crosstab. The Years are projected
on the column.
The Sales region and Country are levels from the same hierarchy, where the
Sales region is a higher level than the Country:
Business Analytics
Figure 53 An Image of the Metadata Layout displaying Sales region and

Country as levels.
When executed in Compatible Query Mode, the report will display the
following output:
Figure 54 The projected Crosstab with Data Values.
If the package of the report above is republished with the Dynamic Query
Mode enabled and the report is re-executed, the user will be presented with
the following error message:
XQE-PLN-0212 The report nests more than one level from the same
hierarchy but they are not adjacent to each other. Please make levels
from the same hierarchy adjacent.
In order to execute this report with no error, the Dynamic Query Mode
requires levels from the same hierarchy be adjacent in the same hierarchical
order. The example report above can be rearranged to run with the Dynamic
Query Mode by nesting the Country immediately next to the Sales region
(Sales region and Country are not split by the Product line):
Business Analytics
Figure 55 Crosstab Projection Showing the Levels in Order.
Figure 56 Projected Crosstab with Levels in Order and Data.
8.1.2 Nesting Levels from the Same Hierarchy in a different Hierarchical

order than Defined by the Metadata
When using OLAP based packages, reports which project levels from the
same hierarchy in a different order than defined by the hierarchal structure of
the metadata will produce the following error:
XQE-PLN-0213 The report nests levels from a hierarchy which breaks the
hierarchy level order. Please nest levels according to hierarchy level
order.
Business Analytics
which the Report Author utilizes levels from the same hierarchy in a different
order than defined by the hierarchal structure. A crosstab projects Country
and Sales region respectively on the rows. The Years are projected on the
column, The Quantity is the measure. The report layout is depicted below:
Figure 57 A crosstab projects Country and Sales region respectively on the

rows. The Years are projected on the column, The Quantity is the measure.
As can be seen above, the Sales region is nested under the Country. This
order of nesting doesn’t agree with the order defined by the Sales regions
hierarchy as shown below:
Figure 58 Metadata View Showing Sales Region and Country as Levels.
When executed in Compatible Query Mode, the report will display the
following output:
Figure 59 The Projected Crosstab with Data.
Business Analytics
XQE-PLN-0213 The report nests levels from a hierarchy which breaks the
hierarchy level order. Please nest levels according to hierarchy level
order
requires levels nested in the same order as specified by the hierarchy. The
example report above can be rearranged to run with Dynamic Query by
nesting the Country under the Sales region:
Figure 60 Projected Crosstab with the Levels Rearranged.
Figure 61 Projected Crosstab with Levels Rearranged Populated with Data.
8.1.3 Same Hierarchy on Multiple Edges

When using OLAP based packages, reports which project levels from the
same hierarchy on different edges of the crosstab, rows and columns, will
produce the following error:
XQE-PLN-0215 The report has levels from the same hierarchy on multiple
edges. Please place levels from a single hierarchy on only one edge
Business Analytics
which the Report Author utilizes levels from the same hierarchy on multiple
edges. Consider the following crosstab:
Figure 62 Crosstab with Sales region is projected on the row edge and
Country is projected on the column edge.
Sales region is projected on the row edge and Country is projected on the
column edge. When executed in Compatible Query Mode, the report will
display the following output:
Figure 63 Crosstab with Data on a Diagonal Skew.
XQE-PLN-0215 The report has levels from the same hierarchy on multiple
edges. Please place levels from a single hierarchy on only one edge.
requires levels nested in the same order as specified by the hierarchy on a
single edge. The example report above can be rearranged to run with
Dynamic Query Mode by nesting the Country under the Sales region on the
rows:
Figure 64 Crosstab rearranged to run with Dynamic Query Mode by nesting

the Country under the Sales region on the rows.
Business Analytics
Figure 65 Crosstab rearranged to run with Dynamic Query Mode by nesting

the Country under the Sales region on the rows with Data.
8.1.4 Using % of Each Column Total within IBM Cognos Analysis Studio
When using an OLAP based package to create an Analysis Studio report
where two levels of the same hierarchy are on the same edge and the option
to show values as '% of Each Column Total' has been selected.
The scenario below walks a user through creating the analysis. It also
illustrates the difference in outputs of running the same report in both query
modes.
When executed in Compatible Query Mode, the report displays the following
output.
Figure 66 Crosstab with Percentage of Children adding up to 100% for the

Parent.
Business Analytics
If the package of this report is republished with the Dynamic Query Mode
enabled and the report is re-executed
Figure 67 Crosstab with Percentage of Children adding up to 100% for All

Parents.
In Dynamic Query Mode this will return the percentage of each value versus
in Compatible Query Mode returns the total for the children of the default
member (typically root member).
Currently the results returned by the Dynamic Query Mode cannot be
overridden by a report re-design. Should the Compatible Query Mode results
be required, this particular style of report would be excluded as a candidate
for a move to the Dynamic Query Mode.
Business Analytics
9 Debugging and Troubleshooting the Dynamic Query

Mode
The Dynamic Query Mode offers several tracing capabilities that can help in
troubleshooting query related issues. Trace settings for the Dynamic Query
Mode are accessible through the IBM Cognos Administration Portal via the
properties of the QueryService service. By default, the trace files are written
to the C10 install <cognos_install_dir>/logs/XQE. However the trace output
directory can be configured through a configuration file change.
9.1 Query Execution Trace

Enabling the query execution trace setting will write information such as the
native MDX to a run tree log within the <cognos_install_dir>/logs/XQE
directory. Profiler information is also written to capture execution and
waiting time metrics for query constructs. Since a log is generated for each
convention.
timestamp_reportName/runtreeLog.xml
timestamp_reportName/profilingLog-#.xml
As an example, executing a report called top_sales would result in a log file

named 2010-09-10_11h33m700s_top_sales/runtreeLog.xml and one or
several profiler logs named 2010-09-10_11h33m700s_top_sales/profilingLog-
0.xml, 2010-09-10_11h33m700s_top_sales/profilingLog-1.xml.
Some report execution requires executing sub-queries. Sub-queries execution
trace is stored under a separate directory within the main report directory.
The sub-query directory contain the same logging elements as the main
report, runTreeLog.xml and profilingLog-#.xml.
If executing the report top_sales- requires the execution of one or more sub-
queries, the trace for those sub-queries is stored in 2010-09-
10_11h33m700s_top_sales/subqueries
9.1.1 Enabling the Query Execution Trace

The following section outlines how to enable the Query Execution Trace.
1. Within a browser, go to the IBM Cognos Administration portal.
2. Click on the Configuration tab.
3. Select the Dispatchers and Services link.
4. Select the dispatcher link.
5. Within the list if available services, locate the QueryService and click
Properties.
Business Analytics
6. Click on the Settings tab to display the categories illustrated below:
Figure 68 IBM Cognos Administration with Query Execution Trace Enabled.
7. Within the Tuning category, locate the Enable query execution

trace?
8. To enable the trace, check the checkbox on the right hand side and
click the OK button. The trace configuration change will be picked up
automatically within 15 seconds.
9.2 Query Planning Trace

Enabling the query planning trace setting will write information related to the
transformation of the query to the plan tree log within the
<cognos_install_dir>/logs/XQE directory. Since a log is generated for each
convention.
timestamp_reportName/plantreeLog.xml
As an example, executing a report called top_sales would result in a log file
named 2010-05-10_11h33m700s_top_sales/plantreeLog.xml.
Although this trace is particularly useful when attempting to determine what
decisions were made by the Dynamic Query Mode to build the execution
plan; care should be taken as the resultant log files are large and may impact
overall query performance.
9.2.1 Enabling the Query Plan Trace
The following section outlines how to enable the Query Plan Trace.
Properties.
Business Analytics
6. Click on the Settings tab to display the categories illustrated below.
Figure 69 IBM Cognos Administration Properties of the QueryService.
7. Within the Tuning category, locate the Enable query planning

trace?
9.3 Changing the Default Log Output Directory

To change the log file output to a different location, a change needs to be
made to the xqe.config.xml file located within the
<cognos_install_dir>/configuration directory. To do this:
1. Locate and backup the existing ../configuration/xqe.config.xml file.
2. Using a text editor open the original file and locate the following
section:

3. Remove the comments and add the new physical location for the log
files. For this example the new physical location will be in the D:\logs
directory. When completed, the finished entry should represent the
following:
<logsFolder value="D:\logs\"/>
4. Save the changes and close the file.
5. The change will be picked up once the IBM Cognos 10 service is
stopped and started.
9.4 IBM Cognos Dynamic Query Analyzer

The IBM Cognos Dynamic Query Analyzer (DQA) is a utility that provides a graphical
interface for the execution tree logs produced by Dynamic Query Mode queries. This
graphical interface allows a Report Administrator to easily identify all the individual
Business Analytics
pieces of a Dynamic Query Mode query. This easy to use overview is paramount for
simplifying the troubleshooting of Dynamic Query Mode query performance.
9.4.1 Installing the IBM Cognos Dynamic Query Analyzer
The IBM Cognos Query Analyzer (DQA) can be installed into an existing IBM Cognos
10 install or into its own directory. The following section will step a user through the
installation of the DQA into its own directory.
1. Initiate the install by double clicking the issetup executable.
2. Select a language and click the Next button.
3. If the license agreement is acceptable, select the I agree radio button
and click the Next button.
4. Choose an installation directory and click the Next button. For this
example the install path will be C:\Program Files\IBM\cognos\C10.
5. If prompted to create the directory, click the Yes button.
6. Ensure that the Dynamic Query Analyzer Component is selected,
and then click the Next button.
7. Click the Next button to add the DQA to the windows shortcuts.
8. Click the Next button to the installation summary screen. This will
initiate the installation sequence.
9. Click the Finish button to complete the install.
9.4.2 IBM Cognos Dynamic Query Analyzer Configuration

9.4.2.1 Configuring IBM Cognos Dynamic Query Analyzer Access to IBM
Cognos 10 Content
The DQA has the ability to execute IBM Cognos 10 reports from within its
user interface. In order to do this, the DQA will need to be configured to
point to a running IBM Cognos 10 system. The following section will provide
a step by step on this configuration.
1. From the windows menu, select Start\All Programs\IBM Cognos

10\IBM Cognos Dynamic Query Analyzer.
Figure 70 IBM Cognos Dynamic Query Analyzer Initial View.
Business Analytics
2. From the available Menu, select Window\Preferences.
Figure 71 IBM Cognos Dynamic Query Analyzer Peference View.
3. Within the left hand pane, select the Server property.
Figure 72 IBM Cognos Dynamic Query Analyzer Server Properties.
4. Within the right hand Server section provide the host and the port of
the IBM Cognos server which contains the reports to be analyzed.
5. If the IBM Cognos 10 application has security applied, select a
Namespace from the drop down list, and supply a valid user id
(Name) and password
6. Once completed, click the Apply button to apply the configuration.
Business Analytics
7. Click the OK button to return to the initial view.
Figure 73 IBM Cognos Dynamic Query Analyzer Initial View.
8. From the Windows menu select Show View.

9. Within the show view dialog box, select Navigation\Content Store
and click OK.
10. If the configuration applied earlier was correct, the IBM Cognos 10
content from that server should now be displayed within the Content
Store pane as illustrated below.
Figure 74 IBM Cognos Dynamic Query Analyzer Content Store View.
Business Analytics
9.4.2.2 Configuring IBM Cognos Dynamic Query Analyzer to Access Logs

on a Remote System
The IBM Cognos Dynamic Query Analyzer has the ability to both, read logs
from a physical drive location, and to read remote logs through an http
connection. The following section will step a user through the setup required
to access the logs through an http connection from a single server IBM
Cognos 10 windows install.
1. On the IBM Cognos 10 server, launch the Internet Information

Services(IIS) console.
2. Within the left hand navigation pane, navigate to servername\Web
Sites\Default Web Site.
3. Click on the Default Web Site to highlight it, then right-click.
4. From the available menu, select New\Virtual Directory.
5. Click the Next button.
6. Within the Virtual Directory Creation wizard, provide an alias of
XQElogs and click the Next button.
7. Press the Browse button located at the right hand side of the dialog
box.
8. Within the Browse for folder dialog box, traverse the directory
structure to the <install_dir>\ibm\cognos\c10\logs\XQE
directory. Click the OK button to accept the path.
Figure 75 Virtual Directory Creation Wizard with Path to the Logs\XQE

folder.
9. Click the Next button to continue.
Business Analytics
10. Ensure that the Read and Browse permission are set, and then click
the Next button.
Figure 76 Virtual Directory Creation Wizard Access Permissions set to

Read and Browse.
11. Click the Next button, then Finish to complete the virtual directory
creation.
12. Launch DQA by selecting Start\All Programs\IBM Cognos
10\IBM Cognos Dynamic Query Analyzer.
Figure 77 IBM Cognos Query Analyzer Main View.
Business Analytics
13. From the available Menu, select Window\Preferences.
Figure 78 IBM Cognos Query Analyzer Preference View.

14. Within the left hand pane, select the Server property.
Figure 79 IBM Cognos Query Analyzer Server Properties View.
15. Within the Remote Log Access section, provide the Logs directory
URL to the previously created virtual directory.
If the previously created virtual directory was secured by the IIS
Administrator, provide a valid Name(UID) and Password. Typically,
these credentials are actual server credentials which may be different
from the IBM Cognos 10 Namespace credentials.
16. Click the Apply button to confirm the changes, before clicking OK.
Business Analytics
9.4.3 Running a Report and Viewing the Remote Logs using the IBM
Cognos Dynamic Query Analyzer
With the configuration of the IBM Cognos Dynamic Query Analyzer complete,
the following section will provide the steps required to:
• Enable the Query Execution Trace on the IBM Cognos 10 system.
• Run a report from within IBM Cognos Query Analyzer.
• View the remote logs produced by the report Run.
9.4.3.1 Enabling the Query Execution Trace
The following section outlines how to enable the Query Plan Trace.
Properties.
6. Click on the Settings tab to display the categories illustrated below.
Figure 80 IBM Cognos Administration QueryService Properties.
Business Analytics
7. Within the Tuning category, locate the Enable query execution

trace?
Figure 81 IBM Cognos Administration Execution Trace Enabled on the

QueryService Properties.
9.4.3.2 Running a Report within IBM Cognos Query Analyzer
1. Launch IBM Cognos Dynamic Query Analyzer.

2. From the Windows menu select Show View.
Business Analytics
3. Within the show view dialog box, select Navigation\Content Store

and click OK. The bottom Content Store pane should now display the
IBM Cognos 10 Public Folder contents as illustrated below.
Figure 82 IBM Cognos Dynamic Query Analyzer Content Store View

Showing a Profile Trace.
4. Within the Content Store pane, locate a report and double click on it.
For this example, the report was called R1 located under the package
named Basic.
Business Analytics
5. Once the report finishes executing, the results will be displayed within
DQA as illustrated below.
Figure 83 IBM Cognos Dynamic Query Analyzer Displaying the Results

of a Report.
9.4.3.3 Viewing the Execution Plan (Runtree) Log within IBM Cognos
Dynamic Query Analysis
1. Within the bottom Content Store pane, traverse the IBM Cognos 10
structure to the report executed in the previous section. For this
example the report will be located under the Basic package as report
R1.
2. Under the R1 report, a folder with a date should now be visible,
expand this folder to display the Profile 0 object.
Business Analytics
Figure 84 IBM Cognos Dynamic Query Analyzer with a Profile Selected.

3. Double-click on the Profile 0 object. When the screen finishes
loading, the runtree log will be display in a graphical view.
Figure 85 IBM Cognos Dynamic Query Analyzer displaying Graphical

Display of a Profile.
Business Analytics
9.4.4 Dynamic Query Analyzer in Action: A Suppression Case Study

The following section will provide a working tutorial on how the Dynamic
Query Analyzer can be used to performance tune a report.
In this case study a user has created a crosstab report against the Great
Outdoors sample cube provided for Oracle Essbase. The crosstab report
consists of Quantity as the Measure, Product as the row edge and Order
Method nested under Retailer on the column edge. When creating the
report, the user also selected suppression for the rows and columns from the
available toolbar items. For the purpose of this case study the report was
saved as EssbaseVisualNullSupp under the GODB Essbase package.
Figure 86 IBM Cognos Report Studio Report with a Crosstab.

When this report’s runtree object (profile 0) is viewed within the Dynamic
Query Analyzer, it will display as per the following screen capture.
Figure 87 IBM Cognos Dynamic Query Analyzer Displaying the Graphical

Display for the Profile of the Crosstab.
Business Analytics
Within the Graph view for this particular scenario, two items stick out. The
first item is the XV5Suppress node located at the top of the screen and the
MDX timing nodes located at the bottom of the screen. These nodes are
outlined on the screen capture below.
Figure 88 IBM Cognos Dynamic Query Analyzer showing the Timing on the
MDX nodes.
The XMDXSelect node is the node which will display the pieces of the actual
MDX query used to satisfy the report request. The scale icon beside node is
used as a visual representation of the performance of the node. The actual
properties of the node are displayed by clicking on the node itself in the
graph view.
<XMdxSelect id = "349" totalElapsedTime = "13623889552" ownElapsedTime
= "11372194645" totalCPUTime = "6093750000" ownCPUTime = "4984375000"
cellProperties = "null" cubeName = "GODB.GODB">
</XMdxSelect>
The properties pane of this node reveals the time spent in the actual node
and the total elapsed time. In this particular case, the time spent in the node
itself was 11372 ms and the cumulative time for the node and its children
was 13623 ms.
Business Analytics
The V5Suppress node is evoked by the application of the Suppress\Rows

and Columns on the report. By clicking on the physical node itself in the
graph, the following properties are displayed.
<XV5Suppress id = "417">
<SuppressSpec EdgeNum = "1" nulls = "true" divByZero = "true" zero =
"true" overflow = "true">
</SuppressSpec>
<SuppressSpec EdgeNum = "0" nulls = "true" divByZero = "true" zero =
"true" overflow = "true">
</SuppressSpec>
</XV5Suppress>
Based on the fact that there are two EdgeNum entries and nulls, divByZero
and overflow are all set to true, the properties confirm that a user applied
zero, divide by zero, overflow and null suppression on both the rows and
columns.
At this point, it would be time to ask the report author whether or not they
actually need the divByZero, zero and overflow suppression, or whether or
not they just wanted to suppress nulls. Another good question to ask would
be whether suppression was actually needed on both the rows and columns.
The report author replies back with the statement that only null suppression
is required on both columns and rows. The report author made the change
to the report and saved it as EssbaseVisualJustNullSupp on the same
package. When the runtree plan (Profile 0) for this report is viewed in the
Dynamic Query Analyzer, it should represent the following screen capture.
Business Analytics
MDX nodes.
This time the XMDXSelect displays the following properties:

</XMdxSelect>
In this particular run, the time spent in the node itself was 9753 ms and the
cumulative time for the node and its children was 8441 ms.
The V5Suppress node now displays the following:

<XV5Suppress id = "417">
<SuppressSpec EdgeNum = "1" nulls = "true" divByZero = "false" zero
= "false" overflow = "false">
</SuppressSpec>
<SuppressSpec EdgeNum = "0" nulls = "true" divByZero = "false" zero
= "false" overflow = "false">
</SuppressSpec>
</XV5Suppress>
Business Analytics
For this report run only nulls are being suppressed on both the row and
column edge of the crosstab. Since the requirement is to only suppress nulls,
the visual null suppression can be replaced by the Null suppression on the
actual query. The report author receives this request and makes the desired
change. The report is saved out as EssbaseQueryNullSupp under the same
package. When the runtree plan (Profile 0) for this report is viewed in the
Dynamic Query Analyzer. The graph should represent the following screen
capture.
MDX nodes after the change.
This time the XMDXSelect displays the following properties:

</XMdxSelect>
In this particular run, the time spent in the node itself was 9639 ms and the
cumulative time for the node and its children was 8358 ms.
Notice that since visual suppression has been removed from the report, the
V5Suppress node is no longer present in the graph view.
Business Analytics
9.5 Submitting a Dynamic Query Mode Test Case to IBM Cognos Support
In addition to what IBM Cognos support requests for query related support
incidents, the following items should be submitted for a Dynamic Query Mode
query diagnosis:
1. A detailed description of the query problem, along with the desired
query output or expected query behaviour.
2. Data source information such as:
• Data Source Type (Oracle Essbase, SAP BW, TM1)
• Data Source Version
• Connection Sting
• Connectivity Client Version
3. Package deployment and report specifications
4. Configuration/XQE properties file for the specific data source type.
5. Configuration/qfs_config.xml file.
6. IBM Cognos 10 Framework Manager model
7. Query Execution Trace
8. Query Planning Trace
Business Analytics

IBM Cognos 10 Dynamic Query Cookbook

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

IBM Cognos 10 Dynamic Query Cookbook

Încărcat de

Drepturi de autor:

Formate disponibile

Guideline

The IBM Cognos 10 Dynamic

Copyright and Trademarks

© Copyright IBM Corp. 2010

8.1 OLAP SCENARIOS ................................................................................................. 52

1.3 Exclusions and Exceptions

2 Introduction to the IBM Cognos 10 Dynamic Query

2.1 Query Optimization

2.2 Performance Improvement through Balanced Local Processing

2.3 Security-Aware Caching

2.4 New Data Interfaces Leveraging 64 bit Processing

2.5 Ease of Maintenance with Query Visualization

3 The IBM Cognos 10 Architecture

Figure 1 The Compatible Query Mode Architecture

3.1.1.1 IBM Cognos 8 Query Studio Metadata Tree Request Flow

Figure 2 IBM Cognos Query Studio Request Flow

3.1.1.2 IBM Cognos 8 Query Studio Data Query Request Flow

Figure 3 IBM Cognos Query Studio Data Request Flow

• RSVP opens a session (2) with QFS

3.2 Architectural Diagram of Dynamic Query Mode

Figure 4 The Dynamic Query Mode Architecture

The Execution Layer supplies similar query execution capabilities to MDDS

Figure 5 The Pieces of a Dynamic Query Mode Result

3.2.1 Basic Request Flow of a Dynamic Query

A report request coming in to the Dynamic Query Mode will initially be

Figure 6 A Query Tree Representation

Figure 7 A simple MDX Run Tree

4 Configuring IBM Cognos 10 Dynamic Query Mode Data

4.1 Understanding How IBM Cognos 10 Connects to Oracle Essbase

Oracle Essbase 9.3.X Oracle Essbase 11.1

4.2 Step by Step Example of Configuring the Oracle Essbase Connectivity

Figure 8 ESSCMD Command Window Displaying the Oracle Essbase

3. If the Oracle Essbase release version is 11.1 no further configuration is

7. Remove the comment tags from the essodp93 provider.

4.3 Oracle Essbase Data Source Specific IBM Cognos 10 Configuration

Setting this parameter: This parameter is available within the

4.4 Understanding How IBM Cognos 10 Connects to SAP BW

When IBM Cognos 10 is installed as a 64 bit application, Compatible Query

Figure 9 Image Displaying the 32 and 64 Bit Librfc Client Library

2. Copy the 32 bit library into the C10\bin directory.

4.6 SAP BW Data Source Specific IBM Cognos 10 Configuration Settings

4.6.1 Treat Nulls as Zeros within Calculations

Setting this parameter: This parameter is available within the

4.7 Understanding How IBM Cognos 10 Connects to IBM Cognos TM1

4.8 Step by Step Example of Configuring the IBM Cognos TM1

Figure 10 IBM Cognos TM1 Install Screen Displaying the TM1

By default, this parameter is set to 0 which disables this feature. A value of 1

Interoperability with other parameters: When enabled, this parameter is used

Setting this parameter: This parameter is available within the

Interoperability with other parameters: This parameter is used in conjunction

Setting this parameter: This parameter is available within the

5 IBM Cognos 10 Framework Manager and Dynamic

Data source connections can be created in either IBM Cognos Connection or

Figure 14 New Data Source Wizard

9. Based on the information provided by the Oracle Essbase administrator, type

Figure 15 New Data Source Wizard – Signon

10. Click Test the connection, and then click Test.

Figure 16 Test the connection – results

Compatible is the Compatible Query Mode and Dynamic is the new

Figure 17 Metadata Wizard - Select Data Source

Figure 18 Metadata Wizard - Select Locales

Figure 19 Publish Wizard – Options