Cognos 审计博客 – 适用于大型和高容量环境的提示和技巧

by 2021 年 5 月 17 日审计0评论

约翰·博耶 (John Boyer) 和迈克·诺里斯 (Mike Norris) 的博客。

介绍

让 Cognos Auditing 功能发挥作用以了解和了解您的用户社区如何使用 Cognos 并帮助回答以下问题非常重要:

    • 谁在使用系统?
    • 他们正在运行什么报告?
    • 报表运行时间是多少?
    • 在其他工具的帮助下,例如 MotioCI,什么内容没用?

考虑到维护健康的 Cognos Analytics 环境的重要性,令人惊讶的是,除了标准产品文档之外,几乎没有关于其审计数据库的文章。 也许,这是理所当然的,但使用它的组织知道,随着时间的推移,查询审计数据库表的速度会开始变慢——尤其是当您的组织有很多用户运行大量报告并拥有大量历史记录时。 更重要的是,审计活动日志记录本身可能会延迟,因为它正在排队,例如,无法足够快地将其添加到数据库中。 那时您开始考虑数据库性能,就像处理任何具有报告要求的操作数据库一样。

大表通常会降低查询性能。 表越大,插入和查询所需的时间就越长。 请记住,这些表和审计数据库基本上是一个操作数据库; 写入频繁发生并且对我们不利,因为我们不能像使用数据集市那样将它们集中在读取操作上。

与内容存储非常相似,Cognos 环境的健康状况也必须考虑审计数据库的健康状况。 随着时间的推移,审计数据库的无限增长可能会成为一个问题,最终甚至可能影响 Cognos 环境的整体性能。 在许多有外部法规强加于他们的组织中,没有完整的审计记录会使他们陷入不合规的境地,并产生严重的影响。 那么我们如何处理为了历史审计目的而必须维护如此多的数据——在某些情况下长达 10 年——但仍然获得我们需要的报告来维护环境并让用户对性能感到满意?

挑战

    • 审计数据库的无限增长对 Cognos 环境的健康产生负面影响
    • 审计数据库的报告变得缓慢或无法使用
    • Cognos 在将记录写入审计数据库时遇到延迟
    • 审计数据库磁盘空间不足

所有这一切意味着不仅依赖审计数据库的报告受到影响,而且通常整个系统都会受到影响。 如果审计数据库与 Cognos 内容存储库位于同一台服务器上,那么 Cognos 在该环境中的所有性能都会受到影响。

在setUp

我们猜测:

    1. Cognos Analytics 已安装并正在运行
    2. Cognos 配置为登录到审计数据库
        • 有一个审计数据库到位
        • 在 Cognos 管理中设置适当的审计日志记录级别
        • Cognos 正在将记录写入数据库
    3. 审计数据库已使用一年多
    4. 用户和执行环境非常活跃
    5. Audit 包用于显示 Cognos 使用数据
    6. 我们正在寻求提高审计数据库报告性能
    7. 重新开始或删除旧记录并不总是一种选择

如果您还没有安装和配置 Cognos Audit,Lodestar Solutions, Motio 合作伙伴,拥有出色的 发表 在 Cognos BI /CA 中启用审计。

解决方案

有一些可能的解决方案会很快出现:

    1. 通过以下方式减少数据量:
        • 将一些较旧的数据移动到另一个数据库
        • 将一些较旧的数据移动到同一数据库中的另一个表
    2. 只需删除或圆弧hive 一些数据,不要担心
    3. 和它一起生活。 把罐子踢下来 road 并推动数据库管理员的性能
      改进,同时通过不允许更改架构或
      指标

我们不会处理选项 3。选项 2,删除数据,不是一个好的选择,我建议至少保留至少 18 个月的价值。 但是,如果您愿意,IBM 提供了一个实用程序, 审计数据库清理 (Cognos BI) 或 脚本 (Cognos Analytics) 就可以做到这一点。 Cognos BI 实用程序根据时间戳删除记录,而 Cognos Analytics 脚本仅删除索引和表。

我们之前就此向客户提出的建议是分成两个数据库:

    1. 审计 – 实时:包含最近一周的数据
    2. 审计 – 历史:包含历史数据(最多 N 年)

简而言之,该流程每周运行一次,将最新的记录从“实时审计”移至“审计历史”。 在此过程运行后,Audit Live 会以空白状态重新开始。

    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 进行过这样的对话,我们很乐意听到。 我们也很想知道您是否解决了性能不佳的审计数据库的问题以及您是如何解决的。