Cognos 審計博客 – 適用於大型和高容量環境的提示和技巧

約翰·博耶 (John Boyer) 和邁克·諾里斯 (Mike Norris) 的博客。

簡介

讓 Cognos Auditing 功能運作以了解和了解您的用戶社區如何使用 Cognos 並幫助回答以下問題非常重要：

• • 誰在使用系統？
  • 他們正在運行什麼報告？
  • 報表運行時間是多少？
  • 在其他工具的幫助下，例如 MotioCI，什麼內容沒用？

考慮到維護健康的 Cognos Analytics 環境的重要性，令人驚訝的是，除了標準產品文檔之外，幾乎沒有關於其審計數據庫的文章。 也許，這是理所當然的，但使用它的組織知道，隨著時間的推移，查詢審計數據庫表會開始變慢——尤其是如果您的組織有很多用戶運行大量報告並且有很多歷史記錄。 更重要的是，審計活動日誌記錄本身可能會延遲，因為它正在排隊，例如，無法足夠快地將其添加到數據庫中。 那是您開始考慮數據庫性能的時候，就像處理任何具有報告要求的操作數據庫一樣。

大表通常會降低查詢性能。 表越大，插入和查詢所需的時間就越長。 請記住，這些表和審計數據庫基本上是一個操作數據庫； 寫入頻繁發生並且對我們不利，因為我們不能像使用數據集市那樣將它們集中在讀取操作上。

與內容存儲非常相似，Cognos 環境的健康狀況也必須考慮審計數據庫的健康狀況。 隨著時間的推移，審計數據庫的無限增長可能會成為一個問題，最終甚至可能影響 Cognos 環境的整體性能。 在許多有外部法規強加於他們的組織中，沒有完整的審計記錄會使他們陷入不合規的境地，並帶來嚴重的後果。 那麼我們如何處理為了歷史審計目的而必須維護如此多的數據——在某些情況下長達 10 年——但仍然獲得我們需要的報告來維護環境並讓用戶對性能感到滿意？

面臨的挑戰

• • 審計數據庫的無限增長正在對 Cognos 環境的健康產生負面影響
  • 審計數據庫的報告變得緩慢或無法使用
  • Cognos 在將記錄寫入審計數據庫時遇到延遲
  • 審計數據庫磁盤空間不足

所有這一切意味著不僅依賴審計數據庫的報告受到影響，而且通常整個系統都會受到影響。 如果審計數據庫與 Cognos 內容存儲在同一台服務器上，那麼 Cognos 在該環境中的所有性能都會受到影響。

在setUp

我們猜測：

1. 1. Cognos Analytics 已安裝並正在運行
   2. Cognos 配置為登錄到審計數據庫
   1. • 有一個審計數據庫到位
      • 在 Cognos 管理中設置適當的審計日誌記錄級別
      • Cognos 正在將記錄寫入數據庫
   3. 審計數據庫已使用一年多
   4. 用戶和執行環境非常活躍
   5. Audit 包用於顯示 Cognos 使用數據
   6. 我們正在尋求提高審計數據庫報告性能
   7. 重新開始或刪除舊記錄並不總是一種選擇

如果您還沒有安裝和配置 Cognos Audit，Lodestar Solutions， Motio 合作夥伴，擁有出色的 發表 在 Cognos BI /CA 中啟用審計。

解決方案

有一些可能的解決方案會很快出現：

1. 1. 通過以下方式減少數據量：
   1. • 將一些較舊的數據移動​​到另一個數據庫
      • 將一些較舊的數據移動​​到同一數據庫中的另一個表
   2. 只需刪除或圓弧hive 一些數據，不要擔心
   3. 和它一起生活。 把罐子踢下來 road 並推動數據庫管理員的性能
      改進，同時通過不允許更改架構或
      指標

我們不會處理選項 3。選項 2，刪除數據，不是一個好的選擇，我建議至少保留至少 18 個月的價值。 但是，如果您願意，IBM 提供了一個實用程序， 審計數據庫清理 (Cognos BI) 或 腳本 (Cognos Analytics) 就可以做到這一點。 Cognos BI 實用程序根據時間戳刪除記錄，而 Cognos Analytics 腳本僅刪除索引和表。

我們之前就此向客戶提出的建議是分成兩個數據庫：

1. 1. 審計 – 實時：包含最近一周的數據
   2. 審計 – 歷史：包含歷史數據（最多 N 年）

簡而言之，該流程每週運行一次，將最新的記錄從“實時審計”移至“審計歷史”。 在此過程運行後，Audit Live 會以空白狀態重新開始。

1. 1. Live DB 快速而緊湊，允許盡可能快地進行插入
   2. 審計查詢專門針對歷史數據庫

使用這種方法，實時數據和歷史數據沒有隱含的“拼接”。 我認為您可能希望保持這種狀態。

在 Cognos Administration 中，您可以為審計數據源添加兩個不同的連接。 當用戶針對 Audit 包運行報告時，系統會提示他們選擇要使用的連接：

如果您想查看實時審計數據而不是歷史審計數據，則只需在提示時選擇“審計 – 實時”連接（應該是例外，而不是常態。）

如果您真的還想提供實時和歷史的綜合視圖，您可以這樣做，但它會影響性能。

例如，您可以創建一個名為“Audit – Consolidated View”的第三個數據庫，然後，對於 Audit 模式中的每個表：創建一個同名視圖，它是實時數據庫中的表和數據庫中的表之間的 SQL 聯合。歷史數據庫。 同樣，這也可以在 Framework Manager 模型中實現，但同樣，性能將是一個關鍵考慮因素。

我們的一些客戶已經創建了一個統一的視圖。 我們認為這可能是矯枉過正。 在這種合併視圖中，性能總是會更差，而且我們還沒有遇到許多同時使用實時數據集和歷史數據集的用例。 Live 用於故障排除，而Historical 用於趨勢報告。

從 Cognos Analytics 11.1.7 開始，審計數據庫已增長到 21 個表。 您可以在其他地方找到有關審計數據庫、示例審計報告和 Framework Manager 模型的更多信息。 默認日誌級別為 Minimal，但您可能希望使用下一個級別 Basic 來捕獲使用請求、用戶帳戶管理和運行時使用情況。 維護系統性能的一種方法是將日誌記錄級別保持在所需的最低級別。 顯然，服務器完成的日誌記錄越多，服務器的整體性能受到的影響就越大。

大多數管理員會感興趣的關鍵表是 6 個表，它們記錄了系統中的用戶活動和報告活動。

• COGIPF_USERLOGON ：存儲用戶登錄（包括註銷）信息
• COGIPF_RUNREPORT ：存儲有關報告執行的信息
• COGIPF_VIEWREPORT ：存儲有關報告查看請求的信息
• COGIPF_EDITQUERY ：存儲有關查詢運行的信息
• COGIPF_RUNJOB ：存儲有關作業請求的信息
• COGIPF_ACTION ：記錄 Cognos 中的用戶操作（此表可能比其他表增長得更快）

開箱即用的配置如下所示：

推薦配置：

Cognos Audit Database – Live 包含 1 週的審計數據。 超過 1 週的數據將移至 Cognos 審計數據庫 – 歷史。

圖中從 Cognos Audit Database – Live 到 Cognos Audit Database – Historical 的行負責：

• 將數據從實時審計複製到歷史審計
• 刪除實時審核中超過 1 週的所有行
• 刪除歷史審計中超過 x 年的所有行
• 刪除 COGIPF_ACTION 中超過 6 個月的所有行

指數

不同的數據庫類型有不同的索引類型。 數據庫索引是一種數據結構，與表（或視圖）相關聯，用於在從該表（或視圖）檢索數據時縮短查詢執行時間。 與您的 DBA 合作制定最佳策略。 他們會想知道這些問題的答案，以便對要索引的列做出最佳決策。 顯然，數據庫管理員可以在沒有您幫助的情況下找到部分或所有這些問題的答案，但這需要一些研究和一些時間：

• 這些表有多少條記錄，您希望它們增長到多大？ （除非表有大量記錄，否則索引表將沒有用。）
• 您知道哪些列是唯一的嗎？ 他們允許 NULL 值嗎？ 哪些列的數據類型是整數或大整數？ （具有數字數據類型且為 UNIQUE 和 NOT NULL 的列是參與索引鍵的強候選者。）
• 您今天的主要性能問題在哪裡？ 他們在檢索數據嗎？ 是否有更成問題的特定查詢或報告？ （這可能會將數據庫管理員引導到可以優化的某些特定列。）
• 哪些字段用於連接表以進行報告？
• 哪些字段用於過濾、排序、分組和聚合？

毫不奇怪，這些問題與提高任何數據庫表的性能需要回答的問題相同。

IBM 支持 建議 為以下表在列“COGIPF_REQUESTID”、“COGIPF_SUBREQUESTID”和“COGIPF_STEPID”上創建索引以提高性能：

• COGIPF_NATIVEQUERY
• COGIPF_RUNJOB
• COGIPF_RUNJOBSTEP
• COGIPF_RUNREPORT
• COGIPF_EDITQUERY

加上其他較少使用的表：

• COGIPF_POWERPLAY
• COGIPF_HUMANTASKSERVICE
• COGIPF_HUMANTASKSERVICE_DETAIL

您可以以此為起點，但我會通過回答上述問題來為您的組織找到最佳答案。

其他注意事項

1. 審計 FM 模型。 請記住，IBM 提供的 Framework Manager 模型是基於默認表和字段建模的。 您對報告表所做的任何更改都需要反映在模型中。 這些更改的難易程度或複雜程度——或者您進行這些更改的組織能力——可能會影響您選擇的解決方案。
2. 附加字段。 如果您打算這樣做，現在是時候為上下文或參考數據添加其他字段以改進審計報告。
3. 匯總表。 與其只是將數據複製到歷史表中，不如對其進行壓縮。 您可以將數據聚合到日級別，以提高報告效率。
4. 視圖而不是表格。 其他人說，“所以，與其有一個‘當前’數據庫和一個‘歷史’數據庫，你應該只有一個數據庫，並且其中的所有表都應該以‘歷史’為前綴。 然後，您應該創建一組視圖，針對您希望看到為“當前”的每個表，並讓每個視圖過濾掉您不想看到的歷史行，只讓當前行通過。”
   https://softwareengineering.stackexchange.com/questions/276395/two-database-architecture-operational-and-historical/276419#276419

結論

最重要的是，根據此處提供的信息，您應該做好與 DBA 進行富有成效的對話的充分準備。 很有可能她以前解決過類似的問題。

Cognos Audit Database 架構中的擬議更改將提高直接報告以及依賴它的 3rd 方應用程序的性能，例如 Motio“ ReportCard 和庫存。

順便說一下，如果您已經與 DBA 進行過這樣的對話，我們很想听聽。 我們也很想知道您是否解決了性能不佳的審計數據庫的問題以及您是如何解決的。