Cognos Auditing Blog - Tipy a triky pro velkoobjemová a velkoobjemová prostředí

Blog Johna Boyera a Mika Norrise.

Úvod

Je důležité, aby funkce Cognos Auditing fungovala, abyste věděli a porozuměli tomu, jak Cognos používá vaše komunita uživatelů, a pomohli vám zodpovědět otázky jako:

• • Kdo používá systém?
  • Jaké přehledy běží?
  • Jaké jsou doby spuštění přehledu?
  • S pomocí dalších nástrojů, jako je MotioCI„Jaký obsah je nepoužitý?

Vzhledem k tomu, jak důležité je udržovat zdravá prostředí Cognos Analytics, bylo o jeho auditovací databázi nad rámec standardní produktové dokumentace napsáno překvapivě málo. Možná je to samozřejmost, ale organizace, které to používají, vědí, že v průběhu času začne dotazování tabulek databáze auditu zpomalovat - zvláště pokud má vaše organizace mnoho uživatelů, kteří používají spoustu sestav a mají hodně historie. A co víc, samotné protokolování aktivity auditu může být zpožděno, protože je zařazováno do fronty, když jej například nelze přidat do databáze dostatečně rychle. Tehdy začnete přemýšlet o výkonu databáze stejně jako u jakékoli jiné operační databáze, která má požadavky na vykazování.

Velké tabulky obvykle zpomalují výkon dotazů. Čím je tabulka větší, tím déle trvá vložení a dotazování. Pamatujte, že tyto tabulky a databáze auditů jsou v podstatě provozní databází; zápisy se dějí často a fungují proti nám, protože je nemůžeme zaměřit pouze na operace čtení, jako byste to dělali s datovým obchodem.

Podobně jako úložiště obsahu musí stav prostředí Cognos také brát v úvahu stav databáze auditů. Neomezený růst databáze auditů se může časem stát problémem a nakonec může mít dokonce dopad na celkový výkon prostředí Cognos. V mnoha organizacích, na které se vztahují externí předpisy, může mít nedostatek úplných záznamů o auditu přistoupení k situaci nedodržování předpisů s vážnými důsledky. Jak se tedy máme vypořádat s tím, že musíme uchovávat tolik dat pro historické účely auditu - v některých případech až 10 let - a přesto získat přehledy, které potřebujeme k udržení životního prostředí a spokojenosti uživatelů s výkonem?

výzva

• • Neomezený růst databáze auditů negativně ovlivňuje zdraví prostředí Cognos
  • Hlášení z databáze auditu se stalo pomalým nebo nepoužitelným
  • Cognos zaznamenává zpoždění záznamů zapisovaných do databáze auditů
  • V databázi auditu dochází místo na disku

To vše znamená, že trpí nejen zprávy, které se spoléhají na databázi auditů, ale často celý systém. Pokud je databáze auditů na stejném serveru jako úložiště obsahu Cognos, bude v tomto prostředí ovlivněn výkon všech věcí, které Cognos má.

Setup

Předpokládáme:

1. 1. Cognos Analytics je nainstalován a spuštěn
   2. Cognos je nakonfigurován pro přihlášení do auditované databáze
   1. • Mějte zavedenou auditní databázi
      • Nastavte příslušné úrovně protokolování auditu v administraci Cognos
      • Záznamy zapisuje do databáze společnost Cognos
   3. Databáze auditu se používá více než rok
   4. Prostředí je velmi aktivní s uživateli a exekucemi
   5. Balíček Audit se používá k zobrazování dat o využití Cognos
   6. Usilujeme o zlepšení výkonu vykazování databáze auditů
   7. Začít znovu nebo mazat staré záznamy není vždy možné

Pokud ještě nemáte Cognos Audit nainstalovaný a nakonfigurovaný, Lodestar Solutions, a Motio partner, má vynikající zveřejnit o povolení auditu v Cognos BI /CA.

Řešení

Existuje několik možných řešení, která se rychle objeví:

1. 1. Snižte objem dat:
   1. • Přesun některých starších dat do jiné databáze
      • Přesun některých starších dat do jiné tabulky ve stejné databázi
   2. Stačí odstranit nebo obloukhive některá data a nedělejte si s tím starosti
   3. Žij s tím. Vykopněte plechovku road a tlačit na správce databáze pro výkon
      vylepšení při současném poutání tím, že nedovolí změny schématu nebo
      indexy

Nebudeme se zabývat možností 3. Možnost 2, vymazání dat, není dobrá volba a doporučil bych zachovat minimálně 18 měsíců v hodnotě. Ale pokud jste tak nakloněni, IBM poskytuje nástroj, AuditDBCleanup (Cognos BI) nebo a skript (Cognos Analytics), který to přesně udělá. Nástroj pro Cognos BI odstraní záznamy na základě časového razítka, zatímco skripty pro Cognos Analytics pouze odstraní indexy a tabulky.

Doporučení, která jsme v této souvislosti udělali klientům, byla oddělit do dvou databází:

1. 1. Audit - živý: obsahuje data za poslední týden
   2. Audit - Historický: obsahuje historické údaje (až N let)

Stručně řečeno, tento proces probíhá každý týden k přesunu nejnovějších záznamů z Audit Live do Audit Historical. Po spuštění tohoto procesu začíná Audit Live znovu jako prázdná břidlice.

1. 1. Live DB je rychlý a těsný, což umožňuje vložení co nejrychleji
   2. Dotazy na audit jsou výhradně směrovány do Historické databáze

Při použití tohoto přístupu nedochází k žádnému implicitnímu „spojování“ živých a historických dat. Tvrdil bych, že to tak asi chcete zachovat.

Ve správě Cognos můžete pro zdroj dat auditu přidat dvě různá připojení. Když uživatel spustí zprávu proti balíčku Audit, zobrazí se výzva k připojení, které chce použít:

Pokud se chcete podívat na živá data auditu, nikoli na historická data auditu, stačí po výzvě vybrat připojení „Audit - živé“ (měla by být výjimkou, nikoli normou.)

Pokud SKUTEČNĚ chcete také poskytnout konsolidovaný pohled na živé i historické, můžete tak učinit, ale mělo by to vliv na výkon.

Můžete například vytvořit 3. databázi s názvem „Audit - konsolidované zobrazení“ a poté pro každou tabulku ve schématu auditu vytvořit identicky pojmenované zobrazení, které je sjednocením SQL mezi tabulkou v živém DB a tabulkou v historická DB. Podobně by toho bylo možné dosáhnout také v modelu Framework Manager, ale klíčovým faktorem by opět byl výkon.

Někteří naši klienti vytvořili konsolidovaný pohled. Domníváme se, že je to pravděpodobně přehnané. V tomto konsolidovaném zobrazení by byl výkon vždy horší a nesetkali jsme se s mnoha případy použití, které používají jak živé datové sady, tak historické. Živý záznam se používá k řešení potíží a Historický pro hlášení trendů.

Od Cognos Analytics 11.1.7 se databáze auditů rozrostla na 21 tabulek. Další informace najdete jinde v databázi auditů, ukázkových zprávách o auditu a modelu Framework Manager. Výchozí úroveň protokolování je Minimální, ale možná budete chtít použít další úroveň, Základní, k zachycení požadavků na použití, správy uživatelských účtů a používání runtime. Jedním ze způsobů, jak můžete udržet výkon systému, je udržování úrovně protokolování na nejnižší požadované úrovni. Je zřejmé, že čím více protokolování server provádí, tím může být ovlivněn celkový výkon serveru.

Klíčovými tabulkami, které většinu správců budou zajímat, je 6 tabulek, které zaznamenávají aktivitu uživatelů a aktivitu hlášení v systému.

• COGIPF_USERLOGON: Ukládá informace o přihlášení uživatele (včetně odhlášení)
• COGIPF_RUNREPORT: Ukládá informace o spuštění sestavy
• COGIPF_VIEWREPORT: Ukládá informace o požadavcích na zobrazení sestavy
• COGIPF_EDITQUERY: Ukládá informace o bězích dotazů
• COGIPF_RUNJOB: Ukládá informace o požadavcích na úlohu
• COGIPF_ACTION: Zaznamenává akce uživatele v Cognos (tato tabulka může růst mnohem rychleji než ostatní)

Předem připravená konfigurace vypadá takto:

Doporučená konfigurace:

Cognos Audit Database - Live obsahuje 1 týden dat auditu. Data starší než 1 týden jsou přesunuta do Cognos Audit Database - Historical.

Řádek z Cognos Audit Database - Live to Cognos Audit Database - Historical v diagramu je zodpovědný za:

• Kopírování dat z živého auditu do historického auditu
• Odstraňte všechny řádky v živém auditu, které jsou starší než 1 týden
• Odstraňte všechny řádky v Historickém auditu, které jsou starší než x let
• Odstraňte všechny řádky v COGIPF_ACTION, které jsou starší než 6 měsíců

Indexy

Různé typy databází mají různé typy indexování. Databázový index je datová struktura přidružená k tabulce (nebo zobrazení), která se používá ke zlepšení doby provádění dotazů při načítání dat z této tabulky (nebo zobrazení). Spolupracujte se svým DBA na vytvoření optimální strategie. Budou chtít znát odpovědi na tyto otázky, aby se mohli nejlépe rozhodnout, které sloupce indexovat. Správce databáze by očividně mohl najít odpovědi na některé nebo všechny tyto otázky bez vaší pomoci, ale chtělo by to nějaký průzkum a nějaký čas:

• Kolik záznamů tabulky obsahují a do jaké velikosti očekáváte jejich růst? (Indexování tabulky nebude užitečné, pokud v tabulce není velký počet záznamů.)
• Víte, které sloupce jsou jedinečné? Povolují hodnoty NULL? Které sloupce mají datový typ celočíselný nebo velký? (Sloupce s číselnými datovými typy, které jsou JEDINEČNÉ a NENÍ NULL, jsou silnými kandidáty na účast v indexovém klíči.)
• Kde jsou dnes vaše hlavní problémy s výkonem? Získávají data? Existují konkrétní dotazy nebo zprávy, které jsou spíše problémem? (To může vést správce databáze k některým konkrétním sloupcům, které lze optimalizovat.)
• Jaká pole se používají při spojování tabulek pro vytváření sestav?
• Jaká pole se používají k filtrování, třídění, seskupování a agregaci?

Není překvapením, že se jedná o stejné otázky, na které by bylo potřeba odpovědět, aby se zlepšil výkon všech databázových tabulek.

Podpora IBM doporučuje vytvoření indexu pro sloupce „COGIPF_REQUESTID“, „COGIPF_SUBREQUESTID“ a „COGIPF_STEPID“ pro následující tabulky ke zlepšení výkonu:

• COGIPF_NATIVEQUERY
• COGIPF_RUNJOB
• COGIPF_RUNJOBSTEP
• COGIPF_RUNREPORT
• COGIPF_EDITQUERY

Plus na dalších méně používaných tabulkách:

• COGIPF_POWERPLAY
• COGIPF_HUMANTASKSERVICE
• COGIPF_HUMANTASKSERVICE_DETAIL

Můžete to použít jako výchozí bod, ale já bych prošel cvičením odpovědí na výše uvedené otázky, abych dospěl k nejlepší odpovědi pro vaši organizaci.

Ostatní úvahy

1. Auditujte model FM. Nezapomeňte, že model Framework Manager, který poskytuje IBM, je založen na výchozích tabulkách a polích. Všechny změny, které provedete v tabulkách přehledů, budou muset být zohledněny v modelu. Snadnost nebo složitost těchto změn - nebo vaše organizační kompetence tyto změny provést - může mít vliv na zvolené řešení.
2. Další pole. Pokud to uděláte, nyní je na čase přidat další pole pro kontextová nebo referenční data, aby se zlepšilo podávání zpráv o auditu.
3. Souhrnné tabulky. Namísto kopírování dat do historické tabulky je zkomprimujte. Data byste mohli agregovat na úroveň dne, aby byla efektivnější pro vytváření přehledů.
4. Pohledy místo tabulek. Jiní říkají: „Takže místo„ aktuální “databáze a„ historické “databáze byste měli mít pouze jednu databázi a všechny tabulky v ní by měly mít předponu„ historické “. Poté byste měli vytvořit sadu zobrazení, jednu pro každou tabulku, kterou chcete zobrazit jako „aktuální“, a nechat každé zobrazení odfiltrovat historické řádky, které nechcete vidět, a nechat projít pouze ty aktuální. “
   https://softwareengineering.stackexchange.com/questions/276395/two-database-architecture-operational-and-historical/276419#276419

Proč investovat do čističky vzduchu?

Pointa je, že s informacemi zde poskytnutými byste měli být dobře připraveni na produktivní konverzaci se svým DBA. Je pravděpodobné, že podobné problémy již dříve řešila.

Navrhované změny v architektuře Cognos Audit Database zlepší výkon jak v přímém reportingu, tak v aplikacích třetích stran, které na něj spoléhají, jako např. MotioJe ReportCard a zásob.

Mimochodem, pokud jste měli ten rozhovor se svým DBA, rádi bychom o tom slyšeli. Rádi bychom také slyšeli, zda jste vyřešili problém špatně fungující databáze auditů a jak jste to udělali.