데모 받기
로그인

Cognos Auditing 블로그 – 대규모 및 대용량 환경을 위한 팁과 요령

by 2021 년 5 월 17 일감사0 코멘트

John Boyer와 Mike Norris의 블로그.

개요

Cognos Auditing 기능이 사용자 커뮤니티에서 Cognos를 사용하는 방법을 알고 이해하고 다음과 같은 질문에 답하는 데 도움이 되도록 하는 것이 중요합니다.

    • 누가 시스템을 사용하고 있습니까?
    • 그들은 어떤 보고서를 실행하고 있습니까?
    • 보고서 실행 시간은 어떻게 됩니까?
    • 다음과 같은 다른 도구의 도움으로 MotioCI, 어떤 콘텐츠가 사용되지 않습니까?

건강한 Cognos Analytics 환경을 유지 관리하는 것이 얼마나 중요한지 고려할 때 표준 제품 설명서 외에 감사 데이터베이스에 대해 작성된 문서는 놀랍게도 거의 없습니다. 아마도 당연하게 여겼지만 이를 사용하는 조직은 시간이 지남에 따라 감사 데이터베이스 테이블 쿼리가 느려지기 시작한다는 것을 알고 있습니다. 특히 조직에 많은 보고서를 실행하고 많은 기록이 있는 경우에는 더욱 그렇습니다. 뿐만 아니라 감사 활동 로깅 자체가 지연될 수 있습니다. 예를 들어 데이터베이스에 빠르게 추가할 수 없는 경우 대기 중이기 때문입니다. 보고 요구 사항이 있는 운영 데이터베이스와 마찬가지로 데이터베이스 성능에 대해 생각하기 시작하는 시점입니다.

큰 테이블은 일반적으로 쿼리 성능을 저하시킵니다. 테이블이 클수록 삽입 및 쿼리하는 데 더 오래 걸립니다. 이러한 테이블과 감사 데이터베이스는 기본적으로 운영 데이터베이스임을 기억하십시오. 쓰기는 자주 발생하며 데이터 마트에서와 같이 읽기 작업에만 집중할 수 없기 때문에 우리에게 불리합니다.

Content Store와 마찬가지로 Cognos 환경의 상태도 감사 데이터베이스의 상태를 고려해야 합니다. 감사 데이터베이스의 무한한 증가는 시간이 지남에 따라 문제가 될 수 있으며 결국 Cognos 환경의 전체 성능에 영향을 미칠 수도 있습니다. 외부 규정이 가중되는 많은 조직에서 전체 감사 기록이 없으면 규정을 준수하지 않는 상황에 처할 수 있으며 큰 반향을 일으킬 수 있습니다. 그렇다면 과거 감사 목적(경우에 따라 최대 10년)을 위해 그렇게 많은 데이터를 유지 관리하면서 환경을 유지 관리하고 사용자가 성능에 만족하도록 유지하는 데 필요한 보고를 계속 받아야 하는 상황을 어떻게 처리해야 할까요?

도전

    • 감사 데이터베이스의 무한한 성장은 Cognos 환경의 상태에 부정적인 영향을 미칩니다.
    • 감사 데이터베이스 보고가 느려지거나 사용할 수 없게 되었습니다.
    • Cognos에서 감사 데이터베이스에 기록을 쓰는 데 지연이 발생함
    • 감사 데이터베이스에 디스크 공간이 부족합니다.

이 모든 것은 감사 데이터베이스에 의존하는 보고서뿐만 아니라 종종 전체 시스템에 문제가 있음을 의미합니다. 감사 데이터베이스가 Cognos Content Store와 동일한 서버에 있는 경우 해당 환경에서 Cognos의 모든 성능이 영향을 받습니다.

설정

우리는 추정하다:

    1. Cognos Analytics가 설치되어 실행 중입니다.
    2. Cognos가 감사 데이터베이스에 기록하도록 구성됨
        • 감사 데이터베이스가 있어야 합니다.
        • Cognos 관리에서 적절한 감사 로깅 수준 설정
        • 레코드가 Cognos에 의해 데이터베이스에 기록되고 있습니다.
    3. 감사 데이터베이스가 XNUMX년 이상 사용되었습니다.
    4. 환경은 사용자와 실행이 매우 활발합니다.
    5. 감사 패키지는 Cognos 사용 데이터를 표시하는 데 사용됩니다.
    6. 감사 데이터베이스 보고 성능을 개선하려고 합니다.
    7. 오래된 레코드를 다시 시작하거나 삭제하는 것이 항상 옵션은 아닙니다.

아직 Cognos Audit을 설치 및 구성하지 않은 경우 Lodestar Solutions, Motio 파트너, 우수한 게시 Cognos BI /CA에서 감사 활성화 시.

솔루션

신속하게 제시되는 몇 가지 가능한 솔루션이 있습니다.

    1. 다음과 같이 데이터 볼륨을 줄입니다.
        • 이전 데이터의 일부를 다른 데이터베이스로 이동
        • 이전 데이터 중 일부를 동일한 데이터베이스의 다른 테이블로 이동
    2. 그냥 삭제 또는 호hive 일부 데이터에 대해 걱정하지 마십시오.
    3. 그것으로 살아라. 캔을 아래로 걷어차 road 성능을 위해 데이터베이스 관리자를 푸시합니다.
      스키마 변경을 허용하지 않거나 수갑을 채우는 동안 개선
      색인

우리는 옵션 3을 다루지 않을 것입니다. 옵션 2, 데이터를 삭제하는 것은 좋은 옵션이 아니며 최소 18개월의 가치를 유지하는 것이 좋습니다. 하지만 그런 경향이 있다면 IBM은 유틸리티를 제공합니다. 감사DB정리 (Cognos BI) 또는 스크립트 (Cognos Analytics)가 바로 그 작업을 수행합니다. Cognos BI용 유틸리티는 타임스탬프를 기반으로 레코드를 삭제하는 반면 Cognos Analytics용 스크립트는 인덱스와 테이블만 삭제합니다.

이에 대해 이전에 고객에게 제안한 권장 사항은 두 개의 데이터베이스로 분리하는 것이었습니다.

    1. 감사 – 라이브 : 가장 최근 주의 데이터를 포함합니다.
    2. 감사 – 기록: 기록 데이터를 포함합니다(최대 N년).

간단히 말해서, 프로세스는 매주 실행되어 가장 최근의 레코드를 실시간 감사에서 감사 기록으로 이동합니다. Audit Live는 이 프로세스가 실행된 후 백지 상태로 다시 시작됩니다.

    1. Live DB는 빠르고 빡빡하여 삽입이 가능한 한 빨리 이루어집니다.
    2. 감사 쿼리는 독점적으로 Historical DB로 전달됩니다.

이 접근 방식을 사용하면 라이브 데이터와 과거 데이터를 암시적으로 "연결"하지 않습니다. 나는 당신이 아마 그런 식으로 유지하기를 원한다고 주장하고 싶습니다.

Cognos Administration에서 감사 데이터 소스에 대해 두 개의 서로 다른 연결을 추가할 수 있습니다. 사용자가 감사 패키지에 대해 보고서를 실행하면 사용할 연결을 묻는 메시지가 표시됩니다.

감사 데이터베이스

과거 감사 데이터가 아닌 라이브 감사 데이터를 보고 싶은 경우에는 메시지가 표시될 때 "Audit – Live" 연결을 선택하기만 하면 됩니다(표준이 아니라 예외여야 함).

또한 라이브 및 히스토리에 대한 통합 보기를 제공하려는 경우 그렇게 할 수 있지만 성능에 영향을 미칠 수 있습니다.

예를 들어 "Audit – Consolidated View"라는 세 번째 데이터베이스를 만든 다음 감사 스키마의 각 테이블에 대해 라이브 DB의 테이블과 역사DB. 마찬가지로, 이는 Framework Manager 모델에서도 달성할 수 있지만 성능이 핵심 고려 사항이 될 것입니다.

일부 고객은 통합 보기를 생성했습니다. 이것은 과잉일 가능성이 높다는 것이 우리의 의견입니다. 이 통합 보기에서는 성능이 항상 더 나쁠 것이며 라이브 데이터 세트와 기록을 모두 사용하는 많은 사용 사례를 접하지 못했습니다. 라이브는 문제 해결에 사용되고 기록은 추세 보고에 사용됩니다.

Cognos Analytics 11.1.7부터 감사 데이터베이스는 21개의 테이블로 확장되었습니다. 감사 데이터베이스, 샘플 감사 보고서 및 Framework Manager 모델에서 더 많은 정보를 찾을 수 있습니다. 기본 로깅 수준은 최소이지만 다음 수준인 기본을 사용하여 사용 요청, 사용자 계정 관리 및 런타임 사용을 캡처할 수 있습니다. 시스템 성능을 유지할 수 있는 한 가지 방법은 로깅 수준을 필요한 가장 낮은 수준으로 유지하는 것입니다. 분명히 서버에서 수행하는 로깅이 많을수록 전체 서버 성능에 더 많은 영향을 줄 수 있습니다.

대부분의 관리자가 관심을 가질 주요 테이블은 시스템에서 사용자 활동 및 보고 활동을 기록하는 6개의 테이블입니다.

  • COGIPF_USERLOGON : 사용자 로그온(로그오프 포함) 정보를 저장합니다.
  • COGIPF_RUNREPORT : 보고서 실행에 대한 정보를 저장합니다.
  • COGIPF_VIEWREPORT : 보고서 보기 요청에 대한 정보를 저장합니다.
  • COGIPF_EDITQUERY : 쿼리 실행에 대한 정보를 저장합니다.
  • COGIPF_RUNJOB : 작업 요청에 대한 정보를 저장합니다.
  • COGIPF_ACTION : Cognos에서 사용자 작업을 기록합니다(이 테이블은 다른 테이블보다 훨씬 빠르게 증가할 수 있음).

기본 구성은 다음과 같습니다.

기본 감사 구성

권장 구성:

권장 감사 구성

Cognos Audit Database – Live에는 1주의 감사 데이터가 포함되어 있습니다. 1주일보다 오래된 데이터는 Cognos Audit Database – Historical로 이동됩니다.

다이어그램의 Cognos Audit Database – Live to 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 아키텍처에서 제안된 변경 사항은 직접 보고와 이에 의존하는 타사 응용 프로그램 모두에서 성능을 향상시킵니다. Motio의 ReportCard 및 인벤토리.

그건 그렇고, DBA와 그런 대화를 나눈 적이 있다면 그것에 대해 듣고 싶습니다. 또한 성능이 좋지 않은 감사 데이터베이스 문제를 해결하고 어떻게 해결했는지 듣고 싶습니다.