2010-09-29 123 views
1

我們剛剛將Cognos reportnet中的報告遷移到Cognos 8.4,報告現在太慢了。慢Cognos報告

報告只是有嵌套超過週期/季度/半區/年

報表設計聚集列表內交叉表:

  • 的mainqueryitem(queryitem)獲得通過手動SQL 數據。
  • 手冊sql有4個查詢inturn 聯合。
  • 所有4個查詢是剛剛選擇 來自不同表的接合(沒有 組/排序/過濾器)。
  • PlanningLevel(queryitem)從mainqueryitem獲取 數據。 (例如:if mainqueryitem.name = 'Black' then mainqueryitem.quantity else null 所有PlanningLevel的DataItems使用上述格式)
  • 報告頁面由一個 交叉嵌套列表 內部的(分段)。
  • 該列表與主查詢關聯 。
  • 交叉表與計劃級別 相關聯。
  • 交叉表也包含集合 。
  • 提示頁面包含一個 多選列表。

該報告甚至更小的提示值非常緩慢。

然後,我改變了屬性「OverrideDimInfo」到「否」 PlanningLevel queryitem從ReportNet遷移時有一些DimensionInfos已經(不知道這是什麼)

然後報告跑得更快了不小的。的標準(< 1分鐘)。 (400倍更快) 但更多沒有。的選項/標準(> 2),報告仍然較慢。 (選擇最大的報告 - 所有標準最多3.5小時)

當在最大報告的蟾蜍中運行時,mainqueryitem sql需要5分鐘執行<。 最大的報告需要3.5小時,在reportnet中以分鐘運行。

任何想法如何提高性能?

回答

2

我在8.4中觀察到的一件事情是,當使用嵌套在列表對象中的交叉表對象時,與主從關係結合在一起的是,您的主查詢(與列表關聯)應儘可能有限且簡單。我不知道您的情況,但通常包含主查詢的列表的目的是根據維屬性將交叉表結果分割成組,並且詳細查詢更復雜幷包含事實信息。在這種情況下,Cognos不會執行2個查詢來提取Cognos服務器上的所有數據和格式(如所期望的那樣),而是針對每個分組引發單獨的查詢。有時,您可以通過儘可能簡化主查詢來獲得性能方面的改進。很多時候,人們只會複製詳細查詢,將其重命名爲主數據,並在不做任何修改的情況下返回到詳細查詢。擺脫主查詢中不需要的任何內容。這可能不是您的情況,但我們在我們的報告中多次觀察到此行爲,並且調整主查詢通常會有所幫助。

根據報表的構建方式,使用列表節段時可能遇到的另一個問題(不確定這是否意味着分段),是因爲Cognos有時會爲每個節啓動重複查詢。您可以通過從菜單中選擇「工具>顯示生成的SQL/MDX」來查看執行了多少個查詢。

+0

嘿Jamey,謝謝你的迴應。生成的sql是正確的。我也嘗試從模型(FM)檢索數據,但徒勞無功。最後,最終在預計算聚合和創建物化視圖並從中獲取數據。現在報告在幾分鐘內運行。 – Amsakanna 2010-12-15 19:11:41