Performance Business Object

[roxise]

Bonjour à tous,
J'ai un énorme problème de performance du serveur BO, saturation récurente plus ou moins quotidienne lors du lancement de rapports financiers qui sont vraiment très lourds "en terme de nombre de lignes / périodes etc...", je voudrais parvenir à donner une optimisation sur les rapports afin d'y remédier enfin soulager un tout petit peut, qu'elle est la meilleurs méthode et la plus efficasse possible.
pour info : 2 à 300 users / attaque de base directe "donc exécution en temps réel des rapports BO/ lancement de rapports BI en temps réel, capacité RAM à 8 GO et serveurs très puissants DEL, de ma part le temps de mettre en place une datawerhouse résoudra le problème car l'alimentation n'est pas quotidienne et travail en agrégation sauf pour les rapports afinés au détail

merci à tous c'est vraiment urgent

[doc malkovich]

Quelle version ? Rapports deski ou webi ?
Quel SGBD ?

[roxise]

bonjour,
Pour la version c'est la v3 avec oracle 10g

[doc malkovich]

il faut voir :
- la complexité des rapports : nb de lignes ramenées, nb de requêtes ...
- la performance des requêtes : combien de temps elles durent ?
- le paramétrage du serveur : nb de documents traités en // ? en cluster ? la cpu est elle à 100% ? la ram aussi ?

je n'ai pas compris quand tu dis

de ma part le temps de mettre en place une datawerhouse résoudra le problème car l'alimentation n'est pas quotidienne et travail en agrégation sauf pour les rapports afinés au détail

tu veux dire quoi ?

[roxise]

bonjour,
En mettant en oeuvre une datawerhouse cela résolue tout ces problème, car son utilité est bien de tarvailler en agrégation donc pas de niveau de détail ce qui réduit énormément en terme de temps d'exécution soulage aussi la base.
Aussi le faite de travailler en temps réel en sachant que les tables sont attaquées par plusieurs utilisateurs, des interfaces comptables, des rapports BI, nombre de connexions des users etc... alourdi énormément les performance par contre avec DWH c'est pas le cas car elle est isolée d'une part d'autres parts l'alimentation est au maxi quotidienne mais plutôt hebdomadaires pour certains rapports. Donc cette méthode est plus pratique mais toujours avec ses inconveniants. Dans le cas ou on a besoin explicitement d'avoir des données au détail par exemple ou en temps réel on se réfère au serveur de production "avec temps réel" donc il ne sera pas exploiter de la même manière que si que tu n'avais pas de DWH.

cordialement

[doc malkovich]

Tu as un Dataware actuellement ou tu n'en as pas ?
Le problème se pose uniquement sur le serveur de détail "en temps réel" c'est ça ?

[roxise]

On est en phase de mise en oeuvre mais pour l'instant rien de rien.

crldt

[roxise]

Envoyé par doc malkovich

Tu as un Dataware actuellement ou tu n'en as pas ?
Le problème se pose uniquement sur le serveur de détail "en temps réel" c'est ça ?

Non c'est pas évident ce n'est qu'une fine partie du problème car je sais que sa consomme, mais pour le reste des rapports qui sont en consolider!!

[doc malkovich]

Tu peux répondre pour :

il faut voir :
- la complexité des rapports : nb de lignes ramenées, nb de requêtes ...
- la performance des requêtes : combien de temps elles durent ?
- le paramétrage du serveur : nb de documents traités en // ? en cluster ? la cpu est elle à 100% ? la ram aussi ?

[roxise]

bonjour,
pour le nombre de ligne c'est du stile de 20 000 et + pour certains rapport en détail, pour ne aller plus fort peut être tu risquera d'être étonner, la base comporte pratiquement 1 ou deux millions de lignes sur la table FCT avec presque 600 000 clt .
pour certains rapport très complexe, la durée est de l'ordre de 2 à 3 heures exemple pour les créances et qui consomme énormément d'espace en dehors des rapports comptable !
on a des serveurs vraiment très puissants de marque DEL avec 1 capacité de 8 GO de RAM je pense que c'est largement suffisant.

crldt

[TomDuBouchon]

Bonjour,

Le problème c'est que les performances peuvent être améliorées à bien des niveaux.

Déjà, tu as tout le côté matériel... Mais laissons cela de côté.
Ensuite, il y a une ENORME partie sur l'administration Oracle : nombres de users simultanés, locks, partitionage des tables, etc...
Je ne suis pas un spécialiste de l'administration Oracle, loin de là, car c'est un vrai métier... Il doit donc y avoir encore beaucoup d'autres façons d'optimiser les ressources.
Après, il y a le schéma de la BDD. Est-ce que toutes les listes de valeurs sont obtenues avec des tables de référence et pas des tables de fait ? par exemple...
Enfin, côté BO. Là il y a deux aspects :

• Côté Designer, il faut voir à optimiser le schéma... Créer des univers moins gros, gérer des contextes, créer des hiérarchies de tables pour utiliser les @aggregate_aware par exemple.
  Ce qui est important surtout, c'est de déterminer si la lenteur provient des postes utilisateur ou de la BDD. Dans le premier cas, il vaudra mieux écrire ses objets avec des fonctions de BDD. Par ex :
  
  Code :

  count(TABLE.CHAMP)

  Dans le second cas, il vaut mieux essayer de faire calculer BO pour soulager la BDD, dans ce cas on essaie de faire avec les fonctions de projections uniquement.
• Côté Reporter : TESTER... et voilà, entre l'utilisation de plusieurs requêtes ou une seule, du nombre de variables, du nombre de tableaux par onglet, de rapport globalement plus léger (informations dispatchées sur plusieurs rapports) etc...

[doc malkovich]

Tom a donné les grandes lignes

Dans ton cas, je rajouterais de voir les DBA. Les volumétries ne m'inquiètent pas, mais des exécutions de 2/3 heures sont anormales.
Essayes d'alléger les rapports, de revoir les requêtes.
Tu peux aussi voir les DBA pour créer des index.

Sinon comme dit Tom tu peux créer des tables agrégées et utiliser les fonctions @Aggregate_Aware ou sous Oracle les vues matérialisées.

[PAYASS59]

Bonjour,

Juste pour retirer un problème :

Les "statistiques" oracle sur la base de données sont-elles bien calculées ?

Le paramétrage de cette fonctionnalité sur une base de données a diminué mes temps de réponse par 5 pour certaines requêtes....

[roxise]

bonjour,
merci à tous, mais TOM ce que tu viens d'évoquer est déjà appliqué (aggrégation, variable de calcul sous désigner etc...) sauf pour le coté univers c'est vrai qu'il est énorme et très complexe mais c'est impossible de faire mieux, car j'ai essayé à titre d'exemple, de développer des univers pour des besoins spécifiques mais vraiment très restrin mais cela donne le même résultats jusqu'à deux heures d'exécution pour certains rapports, je tiens aussi à noter que qq tables avoisinent les 22 GA et plus (c'est des tables qui traces tous les mouvements ou opérations).
ce que viens de mentionner PAYASS tout à fait d'accord les statistiques oracle ne sont pas toujours fiable, par exemple il te calcul un temps d'exécution d'un batch ou une requête mais il se trompe souvent essaye par exemple toad of oracle.
crldt

[TomDuBouchon]

Dans ce cas, demande à ton DBA Oracle de créer des partitionages sur les tables très lourdes...

Par exemple, si tu sors tes rapports principalement sur l'année en cours, demande un partitionage sur l'année. Du coup, BO n'attaquera que la table de l'année en cours et n'ira chercher les autres données que si cela est nécessaire.

Ensuite, demande lui également de créer des index sur les champs utilisés pour tes jointures dans ton univers, ainsi que sur les champs utilisés en condition de requêtes très très lourdes.