Cognos est-il fait pour des données agrégées ou détalliées?

[hittony]

Bonjour,

Niveau: développeur d'1 an d'expérience
Version: 8.4

- On m'a dit que Cognos est fait pour des données agrégées, dès qu'il s'agit de données détaillées, il arrive à ses limites : volumétrie de résultats trop importante. Cela est peut-être aussi lié au SGBD ou au format de sortie.
- Ou encore, des analyses sur les dimensions sans les faits engendrent des requêtes générées erronées (Cognos ne peut pas générer une requête sans passer par une table de faits).
- En fin, il est également difficile de faire des analyses croisées avec des données externes. (Il me semble que Go Office pourrait y remédier, c'est à confirmer.)

Cognos devrait (enfin, je crois) pouvoir répondre à presque tout type de besoin pourvu que les packages de FW soient correctement et intelligemment conçus.

En résumé, je voudrais entamer une discussion sur la limite de Cognos et ses spécificités par rapport à d'autres outils de restitution.

Je compte sur vous, à bientôt

[Sunchaser]

Bonsoir,

Envoyé par hittony

On m'a dit que

Mais qui est ce "on" ? Que je le pende
Ce n'est pas sérieux, aurais-je envie de dire. Mais il me viens a l'esprit que rien n'est parfait dans ce bas monde, et surtout - chose qui sera plus en rapport avec la discussion - l'utilisation que je fais (ou plutôt qui m'a été demandé / inculqué, bien que j'adhère a 100 % a la logique que nous appliquons vu nos besoins particuliers) de Cognos ne me permets pas d'avoir eu a côtoyer ce genre de problème possible.

Je serais donc curieux de voir les réponses éventuelles de personnes ayant eu a traiter de gros volumes de données.

Lorsqu'on te dit:

Envoyé par hittony

dès qu'il s'agit de données détaillées, il arrive à ses limites : volumétrie de résultats trop importante.

Quel exemple précisément ? Quel phénomènes ou symptômes ?
A chaque fois que j'entends ça, j'ai envie de dire qu'il faut aller voir ce qu'il y a derrière, c'est a dire les données et toute la logique qui est derrière.

En tout cas, pour le moment, en termes de "reporting" / rendu, c'est le meilleur outil que j'ai eu a utiliser. Je doute qu'il y ait beaucoup de produits qui permettent d'aller aussi loin aussi "facilement".

[ElPoune]

Bonjour,

Il est évident que plus le nombre de lignes qui doit retourner sur le serveur Cognos est important plus le temps de production d'un rapport est long. Plus les agrégations sont faites sur le coté Cognos plus le temps est long aussi. Si les déterminants ne sont pas bien définis, la partie SQL pour agréger sur la base de données ne fera pas un travail aussi performant.

On a fait un test ici nous avons une table de mesure test avec 20 millions de lignes et 4 dimensions composer de 2 à 4 niveaux par dimension. Lorsque nous ne définissons pas les déterminants pour les groupements le temps et en moyenne de 20% plus élevé pour avoir un résultat. Avec les déterminants bien définis, avec les dimensions où le tri est défini dans la dimension. Le temps de production du même rapport est incroyable.

Ce que l'on a conclu et qu'une partie de la solution pour avoir un temps rapide est de balancer le travail entre la base de données et Cognos. On a fait nos tests avec un DBA qui nous redonnait tout les select qui était passé vers la bd avec leurs statistiques c-i-e, du moment ou le select arrive jusqu'à ça conclusion le nombre de lignes lues traité les index utilisés, etc., etc. Quand nous déplacions le maximum de travail coté BD, les SQL prenaient entre 2 ou 3 % de plus de temps. Mais le temps global de production de rapport diminuait lui de prêts de 20-25% et dans certain cas de 50% en ajustant ou créant les index appropriés. On a fait nos tests sur un seul serveur Cognos et toujours quand nous étions les seuls sur ce serveur ou sur la BD.
Je ne peux pas dire que si nous avions Cognos sur plusieurs serveurs en Load Balancing que le résultat serait aussi important, mais pour l'instant, et en suivant ce que l'on a eu comme résultat nous avons pris le chemin suivant pour optimiser les rapports les plus lents :

- Valider que sur la BD le sql soit performant
- créer ou modifier des index existants
- Valider le modèle dans FrameWorkManager
- Valider les déterminants
- Avoir un bon DBA disponible..Sans doute le plus important

Nous devons maintenant passer à une étape ou nous aurons entre 6-8 serveur Cognos pour justement augmenter le load balancing...On vas donc refaire les tests et je vous en reparlerai à ce moment.

Bonee journée Jacques

[hittony]

[sovop]

Bonjour ElPoune,

merci pour les precieuses informations et statistiques que tu viens de donner.

J'ai voulu juste demander:
- qu'est-ce qu'il faut faire pour passer d'une utilisation d'un seul serveur TM1 à plusieurs serveurs en load balancing?

- est-ce qu'il faut acheter une licence supplimentaire d'IBM ou juste refaire la configuration et ajuster certaines parametres?

- est-c qu'une seule machine (local ou remote) suffit pour ca ou a-t-on besoin de plusieurs machines?

J'utilise Cognos TM1 9.5.1, TM1 architect, TM1 Web, TM1 Perspective, TM1 Admin Server, TM1 Server, IIS 6.0 et ASP.NET 3.5


Merci pour votre aide