Proven Practice Scenario 2: Cognos SQL and Native SQL. Product(s): IBM Cognos ReportNet and IBM Cognos 8 Area of Interest: Performance
Scenario 2: Cognos SQL and Native SQL. 2 Copyright Copyright 2008 Cognos ULC (formerly Cognos Incorporated). Cognos ULC is an IBM Company. 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. Cognos does not accept responsibility for any kind of loss resulting from the use of information contained in this document. This document shows the publication date. The information contained in this document is subject to change without notice. Any improvements or changes to the information contained in this document will be documented in subsequent editions. This document contains proprietary information of Cognos. All rights are reserved. No part of this document may be copied, photocopied, reproduced, stored in a retrieval system, transmitted in any form or by any means, or translated into another language without the prior written consent of Cognos. Cognos and the Cognos logo are trademarks of Cognos ULC (formerly Cognos Incorporated) in the United States and/or other countries. IBM and the IBM logo are trademarks of International Business Machines Corporation in the United States, or other countries, or both. All other names are trademarks or registered trademarks of their respective companies. Information about Cognos products can be found at www.cognos.com This document is maintained by the Best Practices, Product and Technology team. You can send comments, suggestions, and additions to cscogpp@ca.ibm.com.
Scenario 2: Cognos SQL and Native SQL. 3 Contents 1 INTRODUCTION... 4 1.1 PURPOSE...4 1.2 APPLICABILITY...4 1.3 EXCLUSIONS AND EXCEPTIONS...4 2 THEORY BEHIND THE TECHNIQUE... 4 3 ANALYSING THE EXISTING NATIVE AND COGNOS SQL... 4 4 UPDATING THE EXISTING MODEL... 5 5 REFERENCE FILES... 6
Scenario 2: Cognos SQL and Native SQL. 4 1 Introduction 1.1 Purpose This document outlines how to optimize a specific report by evaluating the difference between the Native and Cognos SQL generated by a specific query. 1.2 Applicability This document applies to all known versions of ReportNet and IBM Cognos 8 available at the time this document was created. 1.3 Exclusions and Exceptions The technique outlined in this paper is suitable for identifying a possible performance issue by analysing the Native and Cognos SQL produced by slow performing query. This approach is scenario specific. 2 Theory behind the Technique When viewing the SQL of a query, a user can either view the Native or the Cognos SQL. The Native SQL is what is being passed to the database. Where the Cognos SQL is the entire SQL used to perform the SQL. In certain scenarios, the native SQL will be a subset of the Cognos SQL which may indicate that the application will do some local processing. If the cause of the local processing can be identified, it may be possible to implement a report or model change to alleviate the local processing requirement. 3 Analysing the Existing Native and Cognos SQL Extract the Native and Cognos SQL for the given query: Native: select "RETURNED_ITEM"."RETURN_REASON_CODE" from "GOSL"."dbo"."RETURNED_ITEM" "RETURNED_ITEM" order by 1 asc select "RETAILER"."RETAILER_CODE" from "GORT"."dbo"."RETAILER" "RETAILER" order by 1 asc Cognos SQL: select 1 as C CubeDetailsItem, XSUM(RETAILER.RETAILER_CODE ) as RETAILER_CODE,
Scenario 2: Cognos SQL and Native SQL. 5 XSUM(RETURNED_ITEM.RETURN_REASON_CODE ) as RETURN_REASON_CODE from GOSL.GOSL.dbo.RETURNED_ITEM RETURNED_ITEM left outer join GORT.GORT.dbo.RETAILER RETAILER on (RETAILER.RETAILER_CODE = RETURNED_ITEM.RETURN_REASON_CODE) group by 1 The native SQL consists of two separate select statements. A closer look reveals that the qualifications are different. This indicates that each of the two columns come from a table in a different schema. The Cognos SQL shows that the query requires a left outer join relationship between the two tables. However, since this relationship is not included in the Native SQL, it is being processed locally. Depending on the size of the tables involved this may impact performance. Due to the different schema qualifications, the tables were imported as two different data sources. These force the application to treat the query as federated. 4 Updating the existing model The model will need to be updated to include both tables under the same data source. This can be done either with an Oracle user which has access to both schemas or via a cross schema view. Once the model has been updated both the Native and Cognos SQL will contain the left outer join. Native: select distinct "RETAILER"."RETAILER_CODE" "RETAILER_CODE", "RETURNED_ITEM"."RETURN_CODE" "RETURN_CODE" from "GORT"."RETAILER" "RETAILER" LEFT OUTER JOIN "GOSL"."RETURNED_ITEM" "RETURNED_ITEM" on "RETAILER"."RETAILER_CODE"="RETURNED_ITEM"."RETURN_REASON_CODE" Cognos: select distinct RETAILER.RETAILER_CODE as RETAILER_CODE, RETURNED_ITEM.RETURN_CODE as RETURN_CODE from OracleSystem..GORT.RETAILER RETAILER left outer join
Scenario 2: Cognos SQL and Native SQL. 6 OracleSystem..GOSL.RETURNED_ITEM RETURNED_ITEM on (RETURNED_ITEM.RETURN_REASON_CODE = RETAILER.RETAILER_CODE) 5 Reference Files The model created for this example is based on the GO Sales Retailers and GO Data Warehouse sample data and model. This new model can exist on separately from the GO Data Warehouse model but depends on the sample database to execute the queries. Follow the instructions available in the User Guides to restore the sample data for this application. MultipleSchema.zip MultipleSchemasOracleUID.zip The published package and report sample (generated using ReportNet 1.1 MR2) are included in the following deployment file. See the Administration and Security Guide for details on importing deployment files. FederatedQueries.zip Includes both the Problem (MultipleSchemas) and the Solution (MultipleSchemasOracleUID)