Un bloc de John Boyer i Mike Norris.
introducció
És important que la capacitat d’auditoria de Cognos funcioni per conèixer i entendre com la vostra comunitat d’usuaris utilitza Cognos i ajudar a respondre a preguntes com:
-
- Qui fa servir el sistema?
- Quins informes s'executen?
- Quins són els temps d'execució de l'informe?
- Amb l'ajuda d'altres eines, com ara MotioCI, quin contingut no s’utilitza?
Tenint en compte el crític que és mantenir un entorn saludable de Cognos Analytics, sorprenentment s’ha escrit poc sobre la seva base de dades d’auditoria més enllà de la documentació estàndard del producte. Potser es dóna per fet, però les organitzacions que l’utilitzen saben que, amb el pas del temps, les consultes sobre les taules de la base de dades d’auditoris començaran a disminuir, sobretot si la vostra organització té molts usuaris que publiquen molts informes i tenen molta història. El que és més és que el registre de l'activitat d'auditoria en si mateix es pot retardar perquè s'està fent cua quan no es pot afegir a la base de dades prou ràpidament, per exemple. És llavors quan comenceu a pensar sobre el rendiment de la base de dades tal com ho faríeu amb qualsevol base de dades operativa que tingui requisits d'informes.
Les taules grans solen disminuir el rendiment de les consultes. Com més gran sigui la taula, més temps es triga a inserir i consultar. Recordeu que aquestes taules i la base de dades d'auditoria són bàsicament una base de dades operativa; les escriptures es produeixen amb freqüència i funcionen contra nosaltres, ja que no podem enfocar-les només per fer operacions de lectura com ho faríeu amb un data mart.
Igual que el magatzem de contingut, la salut de l’entorn Cognos també ha de tenir en compte la salut de la base de dades d’auditoria. El creixement il·limitat de la base de dades d'auditoria pot esdevenir un problema amb el pas del temps i, fins i tot, pot afectar fins i tot el rendiment general d'un entorn Cognos. En moltes organitzacions amb regulacions externes, no tenir un registre d'auditoria complet pot fer que es trobin en una situació d'incompliment amb fortes repercussions. Llavors, com ens plantegem haver de mantenir tantes dades amb fins d’auditoria històrica (en alguns casos fins a deu anys), però, tot i així, obtenim els informes que necessitem per mantenir l’entorn i mantenir els usuaris satisfets amb el rendiment?
El Repte
-
- El creixement il·limitat de la base de dades d'auditoria afecta negativament la salut de l'entorn Cognos
- L’informació de la base de dades d’auditories s’ha tornat lenta o inutilitzable
- Cognos experimenta retards en l’escriptura de registres a la base de dades d’Auditoria
- A la base de dades d’Audit s’està quedant sense espai al disc
Tot això significa que no només els informes que depenen de la base de dades d'auditoria són els que pateixen, sinó sovint tot el sistema. Si la base de dades d'auditoria es troba al mateix servidor que el magatzem de contingut de Cognos, el rendiment de totes les coses que Cognos es veurà afectat en aquest entorn.
La configuració
Suposem:
-
- Cognos Analytics està instal·lat i en execució
- Cognos està configurat per registrar-se a una base de dades d'auditoria
-
- Disposar d'una base de dades d'auditoria
- Definiu nivells de registre d'auditoria adequats a l'administració de Cognos
- Cognos està escrivint registres a la base de dades
- La base de dades d’Auditoria fa més d’un any que s’utilitza
- L’entorn és molt actiu amb els usuaris i les execucions
- El paquet Audit s’utilitza per aflorar dades d’ús del Cognos
- Volem millorar el rendiment dels informes de la base de dades d'auditoria
- Reiniciar o suprimir registres antics no sempre és una opció
Si encara no teniu instal·lat i configurat Cognos Audit, Lodestar Solutions, a Motio soci, té un excel·lent enviar en habilitar l'Auditoria a Cognos BI / CA.
La Solució
Hi ha algunes solucions possibles que es presenten ràpidament:
-
- Reduïu el volum de dades mitjançant:
-
- Moure algunes de les dades més antigues a una altra base de dades
- Moure algunes de les dades més antigues a una altra taula de la mateixa base de dades
- Només cal esborrar-lo o arcar-lohive algunes de les dades i no us preocupeu
- Viu amb ell. Pateu la llauna cap avall road i premeu l’administrador de la base de dades per obtenir el rendiment
les millores mentre les emmanilla en no permetre alteracions de l'esquema o
índexs
No tractarem l'opció 3. L'opció 2, suprimir les dades, no és una bona opció i us recomanaria mantenir un valor mínim de 18 mesos com a mínim. Però, si esteu tan inclinat, IBM us proporciona una utilitat, AuditoriaDBCleanup (Cognos BI) o a script (Cognos Analytics) que farà exactament això. La utilitat per a Cognos BI suprimeix registres basats en una marca de temps, mentre que els scripts de Cognos Analytics només suprimeixen els índexs i les taules.
Les recomanacions que vam fer als clients anteriorment sobre això eren separar-les en dues bases de dades:
-
- Auditoria: en directe: conté les dades més recents de la setmana
- Auditoria: històrica: conté dades històriques (fins a N anys)
En resum, el procés s’executa setmanalment per passar els registres més recents d’Audit Live a Audit Historical. Audit Live es torna a iniciar com a pissarra en blanc després que s’executi aquest procés.
-
- El Live DB és ràpid i ajustat, cosa que permet que les insercions passin el més ràpid possible
- Les consultes d’auditoria s’adrecen exclusivament al DB històric
Utilitzant aquest enfocament, no hi ha cap "unió" implícita de les dades en viu i de les dades històriques. Jo diria que probablement voldreu continuar així.
A Cognos Administration, podeu afegir dues connexions diferents per a la font de dades d’auditoria. Quan un usuari executa un informe contra el paquet Audit, se li demana quina connexió vol utilitzar:
Si voleu mirar les dades d’auditoria en directe en lloc de les dades d’auditoria històriques, només heu de triar la connexió “Auditoria - En directe” quan se us demani (hauria de ser l’excepció, no la norma).
Si REALMENT també voleu proporcionar una visió consolidada tant en directe com històrica, podeu fer-ho, però afectaria el rendiment.
Per exemple, podeu crear una tercera base de dades anomenada "Auditoria - Vista consolidada" i, a continuació, per a cada taula de l'esquema d'auditoria: creeu una vista amb el mateix nom que sigui una unió SQL entre la taula del DB actiu i la taula del DB històric. De la mateixa manera, això també es podria aconseguir en el model de Framework Manager, però, de nou, el rendiment seria una consideració clau.
Alguns dels nostres clients han creat una visió consolidada. La nostra opinió és probable que això sigui excessiu. El rendiment sempre seria pitjor en aquesta visualització consolidada i no ens hem trobat amb molts casos d’ús que facin servir tant conjunts de dades en directe com Històric. El Live s'utilitza per a la resolució de problemes i l'historial per a l'informe de tendències.
A partir de Cognos Analytics 11.1.7, la base de dades d'auditoria ha crescut fins a 21 taules. Podeu trobar més informació en altres llocs a la base de dades d’auditoria, exemples d’informes d’auditoria i el model de Framework Manager. El nivell de registre predeterminat és Mínim, però és possible que vulgueu utilitzar el següent nivell, bàsic, per captar sol·licituds d’ús, gestió de comptes d’usuari i ús en temps d’execució. Una manera de mantenir el rendiment del sistema és mantenir el nivell de registre fins al nivell més baix requerit. Viouslybviament, com més registre faci el servidor, més pot afectar-se el rendiment general del servidor.
Les taules clau que més interessaran als administradors són les 6 taules que registren l'activitat de l'usuari i l'activitat d'informes al sistema.
- COGIPF_USERLOGON: emmagatzema informació d’inici de sessió de l’usuari (inclòs el tancament de sessió)
- COGIPF_RUNREPORT: emmagatzema informació sobre les execucions dels informes
- COGIPF_VIEWREPORT: emmagatzema informació sobre les sol·licituds de visualització d'informes
- COGIPF_EDITQUERY: emmagatzema informació sobre les consultes executades
- COGIPF_RUNJOB: emmagatzema informació sobre les sol·licituds de feina
- COGIPF_ACTION: registra les accions dels usuaris a Cognos (aquesta taula pot créixer molt més ràpidament que les altres)
La configuració pròpia de la caixa té el següent aspecte:
Configuració recomanada:
La base de dades d’auditoria Cognos - Live conté 1 setmana de dades d’auditoria. Les dades anteriors a una setmana es traslladen a la base de dades d’auditoria de Cognos: històrica.
La línia de la base de dades d’auditoria de Cognos: de la base de dades d’auditoria en directe a Cognos: la història del diagrama és responsable de:
- Copiar dades de Live Audit a Historical Audit
- Elimineu totes les files de l'auditoria en directe que tinguessin més d'una setmana
- Elimineu totes les files de l'Auditoria històrica que tinguessin més de x anys
- Elimineu totes les files de COGIPF_ACTION que tinguin més de 6 mesos
Índexs
Els diferents tipus de base de dades tenen diferents tipus d’indexació. Un índex de base de dades és una estructura de dades, associada a una taula (o vista), que s’utilitza per millorar el temps d’execució de les consultes en recuperar les dades d’aquesta taula (o vista). Col·laboreu amb el vostre DBA per crear l’estratègia òptima. Voldran conèixer les respostes a preguntes com aquestes per prendre les millors decisions sobre quines columnes indexar. Viouslybviament, l’administrador de la base de dades podria trobar les respostes a algunes o totes aquestes preguntes sense la vostra ajuda, però caldria una mica de recerca i una mica de temps:
- Quants registres tenen les taules i a quina mida esperes que creixin? (La indexació d'una taula no serà útil tret que la taula tingui un gran nombre de registres.)
- Sabeu quines columnes són úniques? Permeten valors NULL? Quines columnes tenen un tipus de dades enter o gran enter? (Les columnes amb tipus de dades numèriques, que són ÚNIQUES i NO NULES, són candidats forts per participar a la clau d'índex.)
- On són els principals problemes de rendiment actuals? Estan recuperant les dades? Hi ha consultes o informes específics que tinguin més problemes? (Això pot conduir l'administrador de la base de dades a algunes columnes específiques que es poden optimitzar.)
- Quins camps s'utilitzen per unir taules per generar informes?
- Quins camps s’utilitzen per filtrar, ordenar, agrupar i agregar?
No sorprèn que es tracti de les mateixes preguntes que caldria respondre per millorar el rendiment de qualsevol taula de bases de dades.
Suport d’IBM recomana creació d'un índex a les columnes "COGIPF_REQUESTID", "COGIPF_SUBREQUESTID" i "COGIPF_STEPID" per a les taules següents per millorar el rendiment:
- COGIPF_NATIVEQUERY
- COGIPF_RUNJOB
- COGIPF_RUNJOBSTEP
- COGIPF_RUNREPORT
- COGIPF_EDITQUERY
A més en altres taules menys utilitzades:
- COGIPF_POWERPLAY
- COGIPF_HUMANTTASKSERVICE
- COGIPF_HUMANTASKSERVICE_DETAIL
Podeu fer-ho servir com a punt de partida, però jo passaria per l'exercici de respondre a les preguntes anteriors per arribar a la millor resposta per a la vostra organització.
altres consideracions
- Auditoria del model FM. Recordeu que el model del Framework Manager que proporciona IBM es basa en les taules i els camps predeterminats. Qualsevol canvi que feu a les taules d'informes haurà de reflectir-se al model. La facilitat o la complexitat d’aquests canvis (o la vostra competència organitzativa per fer aquests canvis) poden afectar la solució que trieu.
- Camps addicionals. Si ho feu, ara és el moment d'afegir camps addicionals per a context o dades de referència per millorar els informes d'auditoria.
- Taules resum. En lloc de copiar només les dades a la taula històrica, comprimeu-les. Podeu agregar les dades al nivell de dia per fer-les més eficients en els informes.
- Vistes en lloc de taules. Altres diuen: "Per tant, en lloc de tenir una base de dades" actual "i una base de dades" històrica ", només heu de tenir una base de dades i totes les taules que hi figuren haurien de tenir el prefix" històric ". A continuació, heu de crear un conjunt de visualitzacions, una per a cada taula que vulgueu veure com a "actual", i que cada vista filtri les files històriques que no voleu veure i que deixin passar només les actuals. "
https://softwareengineering.stackexchange.com/questions/276395/two-database-architecture-operational-and-historical/276419#276419
Conclusió
La conclusió és que, amb la informació que s’ofereix aquí, hauríeu d’estar ben preparats per mantenir una conversa productiva amb el vostre DBA. És probable que hagi resolt problemes similars abans.
Els canvis proposats a l’arquitectura de la base de dades d’auditoria de Cognos milloraran el rendiment tant en els informes directes com en les aplicacions de tercers que en depenguin, com ara Motio'S ReportCard i Inventari.
Per cert, si heu mantingut aquesta conversa amb el vostre DBA, ens encantaria saber-ne. També ens encantaria saber si heu resolt el problema d'una base de dades d'auditoria amb un rendiment baix i com ho heu fet.