Блог аўдыту Cognos - парады і рэкамендацыі для асяроддзяў з вялікім аб'ёмам

Блог Джона Бойера і Майка Норыса.

Увядзенне

Важна, каб магчымасці аўдыту Cognos працавалі, каб ведаць і разумець, як Cognos выкарыстоўваецца вашай супольнасцю карыстальнікаў, і дапамагаць адказваць на пытанні, напрыклад:

• • Хто выкарыстоўвае сістэму?
  • Якія справаздачы яны вядуць?
  • Які час выканання справаздачы?
  • З дапамогай іншых інструментаў, напрыклад MotioCI, які кантэнт не выкарыстоўваецца?

Улічваючы, наколькі важна падтрымліваць здаровую сераду Cognos Analytics, надзіва мала было напісана пра яе базу аўдыту за межамі стандартнай дакументацыі па прадукце. Магчыма, гэта ўспрымаецца як само сабой разумеецца, але арганізацыі, якія яго выкарыстоўваюць, ведаюць, што з часам запыты ў табліцы базы дадзеных аўдыту пачнуць запавольвацца - асабліва калі ў вашай арганізацыі шмат карыстальнікаў, якія працуюць з вялікай колькасцю справаздач і маюць вялікую гісторыю. Больш за тое, сама рэгістрацыя аўдытарскай дзейнасці можа затрымлівацца, таму што яна ставіцца ў чаргу, калі яе немагчыма дадаць у базу дадзеных, напрыклад, досыць хутка. Вось тады вы пачынаеце думаць аб прадукцыйнасці базы дадзеных, як і з любой аперацыйнай базай дадзеных, якая мае патрабаванні да справаздачнасці.

Вялікія табліцы звычайна запавольваюць прадукцыйнасць запытаў. Чым больш табліца, тым больш часу патрабуецца на ўстаўку і запыт. Памятайце, што гэтыя табліцы і База дадзеных аўдыту - гэта ў асноўным аператыўная база дадзеных; запісы адбываюцца часта і працуюць супраць нас, таму што мы не можам засяродзіць іх толькі на аперацыях чытання, як гэта было б з дадзеных.

Гэтак жа, як і захоўванне кантэнту, здароўе асяроддзя Cognos таксама павінна ўлічваць здароўе базы дадзеных аўдыту. Неабмежаваны рост базы дадзеных аўдыту з часам можа стаць праблемай і ў канчатковым выніку нават паўплываць на агульную прадукцыйнасць асяроддзя Cognos. У многіх арганізацыях, у якіх дзейнічаюць знешнія правілы, адсутнасць поўнага аўдыту можа паставіць іх у сітуацыю невыканання з сур'ёзнымі наступствамі. Такім чынам, як мы ставімся да таго, каб захоўваць столькі дадзеных для гістарычных мэтаў аўдыту - у некаторых выпадках да 10 гадоў - але ўсё ж атрымліваць неабходную справаздачнасць для падтрымання асяроддзя і задавальнення карыстальнікаў прадукцыйнасцю?

Выклікі

• • Неабмежаваны рост базы дадзеных аўдыту негатыўна ўплывае на стан здароўя асяроддзя Cognos
  • Справаздача з базы дадзеных аўдыту стала павольнай або непрыдатнай для выкарыстання
  • Cognos адчувае затрымкі пры запісе запісаў у базу дадзеных аўдыту
  • У базы дадзеных аўдыту заканчваецца месца на дыску

Усё гэта азначае, што пакутуюць не толькі справаздачы, якія абапіраюцца на базу даных аўдыту, але часта і ўся сістэма. Калі база даных аўдыту знаходзіцца на тым жа серверы, што і захоўванне змесціва Cognos, у гэтым асяроддзі паўплывае на прадукцыйнасць усіх рэчаў Cognos.

Настройка

Мы мяркуем:

1. 1. Cognos Analytics усталяваны і працуе
   2. Cognos настроены для ўваходу ў базу дадзеных аўдыту
   1. • Мець базу аўдыту
      • Усталюйце адпаведныя ўзроўні рэгістрацыі аўдыту ў адміністрацыі Cognos
      • Cognos запісвае запісы ў базу дадзеных
   3. База дадзеных аўдыту выкарыстоўваецца больш за год
   4. Асяроддзе вельмі актыўнае з карыстальнікамі і выкананнямі
   5. Пакет Audit выкарыстоўваецца для апрацоўкі дадзеных аб выкарыстанні Cognos
   6. Мы імкнемся палепшыць справаздачнасць базы дадзеных аўдыту
   7. Пачаць або выдаляць старыя запісы не заўсёды магчыма

Калі вы гэтага яшчэ не зрабілі, усталюйце і наладзьце Cognos Audit, Lodestar Solutions, a Motio партнёр, мае выдатнага пошта аб уключэнні аўдыту ў Cognos BI /CA.

Рашэнне

Ёсць некалькі магчымых рашэнняў, якія хутка прадстаўляюцца:

1. 1. Паменшыць аб'ём дадзеных:
   1. • Перамяшчэнне некаторых старых дадзеных у іншую базу дадзеных
      • Перамяшчэнне некаторых старых дадзеных у іншую табліцу ў той жа базе дадзеных
   2. Проста выдаліце ​​або вырабіце дугуhive некаторыя дадзеныя і не хвалюйцеся з гэтай нагоды
   3. Жыві з гэтым. Збіце банку ўніз road і націсніце Адміністратар базы дадзеных для прадукцыйнасці
      паляпшэнні, надзеўшы на іх кайданкі, не дазваляючы змяняць схему або
      Індэксы

Мы не збіраемся разбірацца з варыянтам 3. Варыянт 2, выдаленне дадзеных, не з'яўляецца добрым варыянтам, і я б рэкамендаваў трымаць мінімум 18 месяцаў. Але, калі вы так схільныя, IBM прапануе ўтыліту, АўдытDBCleanup (Cognos BI) або а скрыпт (Cognos Analytics), якая будзе рабіць менавіта гэта. Утыліта для Cognos BI выдаляе запісы на аснове пазнакі часу, а сцэнары для Cognos Analytics проста выдаляюць індэксы і табліцы.

Рэкамендацыі, якія мы давалі кліентам па гэтым пытанні, былі падзеленыя на дзве базы дадзеных:

1. 1. Аўдыт - жывы: змяшчае даныя за апошнюю тыдзень
   2. Аўдыт - гістарычны: змяшчае гістарычныя дадзеныя (да N гадоў)

Карацей кажучы, працэс запускаецца штотыдзень, каб перамясціць апошнія запісы з Audit Live у Audit Historical. Пасля запуску гэтага працэсу Audit Live пачынаецца з чыстага ліста.

1. 1. Live DB хуткі і шчыльны, што дазваляе ўстаўляць як мага хутчэй
   2. Аўдытарскія запыты накіроўваюцца выключна ў Гістарычную БД

Выкарыстоўваючы гэты падыход, няма ўтоенага "злучэння" жывых дадзеных і гістарычных дадзеных. Я б сцвярджаў, што вы, напэўна, хочаце так і застацца.

У Адміністрацыі Cognos вы можаце дадаць два розныя злучэнні для крыніцы дадзеных аўдыту. Калі карыстальнік запускае справаздачу супраць пакета аўдыту, ён атрымлівае запыт аб тым, якое злучэнне ён хоча выкарыстоўваць:

Калі вы хочаце паглядзець на дадзеныя аўдыту ў прамым эфіры, а не на гістарычныя дадзеныя аўдыту, вы проста выбіраеце злучэнне "Аўдыт - у прамым эфіры", калі будзе прапанавана (гэта павінна быць выключэннем, а не нормай.)

Калі вы сапраўды хочаце таксама даць кансалідаванае ўяўленне аб жывым і гістарычным, вы можаце зрабіць гэта, але гэта паўплывае на прадукцыйнасць.

Напрыклад, вы можаце стварыць трэцюю базу дадзеных пад назвай «Аўдыт - кансалідаваны выгляд», а затым для кожнай табліцы ў схеме аўдыту: стварыць ідэнтычна названы выгляд, які ўяўляе сабой аб'яднанне SQL паміж табліцай у рэальнай БД і табліцай у гістарычная БД. Сапраўды гэтак жа гэтага можна дасягнуць у мадэлі Framework Manager, але, зноў жа, прадукцыйнасць будзе ключавым фактарам.

Некаторыя з нашых кліентаў стварылі кансалідаваны погляд. Мы лічым, што гэта, верагодна, залішне. У гэтым кансалідаваным выглядзе прадукцыйнасць заўсёды была б горшай, і мы не сутыкаліся са шматлікімі выпадкамі выкарыстання, якія выкарыстоўваюць як наборы дадзеных Live, так і Historical. Live выкарыстоўваецца для ліквідацыі непаладак, а Historical - для паведамлення аб трэндах.

Па дадзеных Cognos Analytics 11.1.7, база даных аўдыту павялічылася да 21 табліцы. Дадатковую інфармацыю можна знайсці ў іншым месцы ў базе даных аўдыту, узорах аўдытарскіх справаздач і мадэлі Framework Manager. Узровень рэгістрацыі па змаўчанні - Мінімальны, але вы можаце выкарыстоўваць наступны ўзровень, Basic, каб зафіксаваць запыты на выкарыстанне, кіраванне ўліковымі запісамі карыстальнікаў і выкарыстанне падчас выканання. Адзін са спосабаў захавання прадукцыйнасці сістэмы - падтрымліваць мінімальны ўзровень рэгістрацыі. Відавочна, што чым больш запісваецца сервер, тым больш можа паўплываць на агульную прадукцыйнасць сервера.

Ключавыя табліцы, якія будуць цікавыя большасці адміністратараў, - гэта 6 табліц, якія рэгіструюць актыўнасць карыстальнікаў і справаздачнасць у сістэме.

• COGIPF_USERLOGON: Захоўвае інфармацыю для ўваходу ў сістэму (уключаючы выхад з сістэмы)
• COGIPF_RUNREPORT: Захоўвае інфармацыю аб выкананні справаздач
• COGIPF_VIEWREPORT: Захоўвае інфармацыю аб запытах прагляду справаздач
• COGIPF_EDITQUERY: Захоўвае інфармацыю аб выкананні запыту
• COGIPF_RUNJOB: Захоўвае інфармацыю аб запытах на працу
• COGIPF_ACTION: Запісвае дзеянні карыстальніка ў Cognos (гэтая табліца можа расці значна хутчэй, чым іншыя)

Канфігурацыя "скрынка" выглядае так:

Рэкамендуемая канфігурацыя:

База дадзеных аўдыту Cognos - Live змяшчае 1 тыдзень дадзеных аўдыту. Дадзеныя старэйшыя за 1 тыдзень перамяшчаюцца ў Базу дадзеных аўдыту Cognos - Гістарычная.

Радок з базы дадзеных аўдыту Cognos - База даных аўдыту Cognos - Гістарычная на дыяграме адказвае за:

• Капіраванне дадзеных з жывога аўдыту ў гістарычны аўдыт
• Выдаліце ​​ўсе радкі ў жывым аўдыце, старэйшыя за 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_HUMANTASKSSERVICE
• COGIPF_HUMANTASKSERVICE_DETAIL

Вы можаце выкарыстоўваць гэта як адпраўную кропку, але я хацеў бы адказаць на пытанні вышэй, каб атрымаць лепшы адказ для вашай арганізацыі.

іншыя меркаванні

1. Аўдыт FM -мадэлі. Памятайце, што мадэль Framework Manager, якую дае IBM, мадэлюецца з табліц і палёў па змаўчанні. Любыя змены, якія вы ўносіце ў табліцы справаздачнасці, павінны быць адлюстраваны ў мадэлі. Лёгкасць або складанасць гэтых змяненняў - ці ваша арганізацыйная кампетэнцыя ўносіць гэтыя змены - могуць паўплываць на рашэнне, якое вы вылучыце.
2. Дадатковыя палі. Калі вы збіраецеся гэта зрабіць, самы час дадаць дадатковыя палі для кантэкстных або даведачных дадзеных для паляпшэння справаздачнасці аб аўдыце.
3. Зводныя табліцы. Замест таго, каб проста капіраваць дадзеныя ў гістарычную табліцу, сцісніце яе. Вы можаце аб'яднаць дадзеныя на дзённы ўзровень, каб зрабіць іх больш эфектыўнымі для справаздачнасці.
4. Прагляды замест табліц. Іншыя кажуць: «Такім чынам, замест таго, каб мець« бягучую »базу дадзеных і« гістарычную », у вас павінна быць толькі адна база дадзеных, а ўсе табліцы ў ёй павінны мець прэфікс« гістарычны ». Затым вы павінны стварыць набор праглядаў, па адным для кожнай табліцы, якую вы хочаце бачыць як "бягучую", і кожнаму прагляду адфільтраваць гістарычныя радкі, якія вы не хочаце бачыць, і прапусціць толькі бягучыя ".
   https://softwareengineering.stackexchange.com/questions/276395/two-database-architecture-operational-and-historical/276419#276419

заключэнне

Выснова заключаецца ў тым, што з прадстаўленай тут інфармацыяй вы павінны быць добра падрыхтаваны да прадуктыўнай размовы з вашым DBA. Хутчэй за ўсё, што раней яна вырашала падобныя праблемы.

Прапанаваныя змены ў архітэктуры базы дадзеных аўдыту Cognos палепшаць прадукцыйнасць як у прамой справаздачнасці, так і ў дадатках іншых вытворцаў, якія на яе абапіраюцца, напрыклад Motio'S ReportCard і інвентар.

Дарэчы, калі б вы мелі такую ​​размову з вашым DBA, мы хацелі б пачуць пра гэта. Мы таксама хацелі б даведацца, калі вы вырашылі праблему з дрэнна выкананай базай дадзеных аўдыту і як вы гэта зрабілі.