|
Publicité ' | ||||||||||||||||||||||||
|
|
#1 |
|
Membre émérite
![]() Développeur informatique Inscription : juin 2004 Messages : 697 ![]() |
Bonjour à tous ! Je suis nouveau avec Birt et je reprends les états élaborés par un collègue.
J'ai une source de données Oracle (serveur sur réseau local). Et à chaque fois que j'ouvre la fenêtre de propriétés d'un jeu de données (peu importe lequel) je dois attendre entre 30 s et 2 mn J'en viens à penser que ce qui est long, c'est la recherche des Users que la fenêtre affiche sous le nom d'"éléments" disponibles, ce dont je n'ai pas besoin, en tous cas en routine. Quelqu'un connaît-il un moyen d'éviter ces temps d'attentes à répétition ? Merci d'avance
__________________
Roland |
|
|
00
|
|
|
#2 |
![]() ![]() Consultante/Formatrice BIRT & Ingénieur Java/J2EE/GWT Inscription : janvier 2005 Messages : 7 299 ![]() |
Bonjour,
Il faudrait voir comment sont composés tes paramètres peut être, tu me dis que ta requête seule ne prend pas autant de temps, as-tu testé via le connecteur que tu utilises ou directement dans un client SQL ou sur le serveur SQL ? /!\ Attention, en prévisualisation, seules les premières lignes du jeu de données sont affichées (voir les préférences de prévisualisation). |
|
|
00
|
|
|
#3 |
|
Membre émérite
![]() Développeur informatique Inscription : juin 2004 Messages : 697 ![]() |
Merci !
- Ma requête ne renvoie qu'une ligne, - Je l'ai testée en direct (dans SQLDeveloper) - Elle ne pose aucun problème de temps en exécution dans Birt Viewer et si on ajoute que la lenteur est la même pour tous les jeux de données de tous les états, cela explique pourquoi je m'oriente vers un problème spécifique à l'ouverture de cette fameuse fenêtre de propriétés de jeux de données A vrai dire, je ne comprends pas pourquoi, alors que ma connexion utilise un user qui n'a des droits que sur un schéma, j'accède à toute une liste de schémas systèmes ou autres utilisateurs...
__________________
Roland |
|
|
00
|
|
|
#4 |
![]() ![]() Consultante/Formatrice BIRT & Ingénieur Java/J2EE/GWT Inscription : janvier 2005 Messages : 7 299 ![]() |
Ah au fait, t'oublies un paramètre. A la première instance du moteur BIRT, il se passe plusieurs secondes pour que celui-ci démarre (tout dépend des performances de ton PC). Et je me demande même s'il ne l'instancierais pas à chaque fois en mode preview pour le détruire une fois la preview affichée.
|
|
|
00
|
|
|
#5 |
|
Membre émérite
![]() Développeur informatique Inscription : juin 2004 Messages : 697 ![]() |
Ma machine est un i5 à 3.33 Ghz avec 4 Go de RAM.
Je n'ai pas bien compris ce qu'il chercherait à instancier. A part ça, je viens d'avoir l'idée d'essayer de créer un nouveau jeu de données (requête de sélection SQL), et j'ai les mêmes temps d'attente à l'ouverture de la fenêtre !
__________________
Roland |
|
|
00
|
|
|
#6 |
![]() ![]() Consultante/Formatrice BIRT & Ingénieur Java/J2EE/GWT Inscription : janvier 2005 Messages : 7 299 ![]() |
Alors une génération BIRT se déroule en plusieurs temps :
Les étapes 2 et 3 sont dans le cas d'un preview faites ensemble. Par contre, l'instanciation lance le moteur de BIRT sur une plateforme OSGi pour ensuite s'en servir. Le lancement d'un tel élément prend un peu de temps. Cependant, lorsque tu gères toi-même ton moteur (avec l'API Java), tu peux faire en sorte qu'il soit instancié une fois pour toutes, et tu le réutilises à chaque fois que tu veux sans le réinstancier à chaque fois. C'est pour cela qu'en prévisualisation, cela peut te paraître un peu lent. (Ceci dit, 30 secondes à 2 minutes, ca me paraît long pour le coup) As-tu le même comportement sur un nouveau rapport ? As-tu le même comportement lorsque tu essayes d'accéder à la base de données exemple (Classic Models) ? |
|
|
00
|
|
|
#7 | |
|
Membre émérite
![]() Développeur informatique Inscription : juin 2004 Messages : 697 ![]() |
Exactement !
Citation:
Par contre, je viens de faire deux essais (les deux avec mon nouvel état vierge) : - connexion à une base Oracle (autre instance sur autre serveur), les temps restent les mêmes; - connexion à une base Firebird (serveur en local) : c'est immédiat.
__________________
Roland |
|
|
|
00
|
|
|
#8 |
|
Membre Expert
![]() ![]() Consultant informatique Inscription : mai 2007 Messages : 893 ![]() |
Tu as soit un problème de réseau, soit un problème via ton driver JDBC si celui-ci n'est pas de type 3 dans ce cas tu risque d'exploser le nombre de connexion à ton serveur Oracle car celle-ci ne seront pas fermées.
|
|
|
00
|
|
|
#9 |
![]() ![]() Consultante/Formatrice BIRT & Ingénieur Java/J2EE/GWT Inscription : janvier 2005 Messages : 7 299 ![]() |
As-tu un autre driver pour te connecter à ta base ?
|
|
|
00
|
|
|
#10 |
|
Membre émérite
![]() Développeur informatique Inscription : juin 2004 Messages : 697 ![]() |
Notre réseau n'est sans doute pas au top, mais d'une part, je n'y peux pas grand-chose
, d'autre part, étant donné les temps constatés via SQLDeveloper, le noeud du problème ne me semble pas être là.En ce qui concerne le driver de classe 3, comment est-ce qu'on reconnait un driver de classe 3 ? J'utilise actuellement un driver contenu dans classes12.zip : oracle.jdbc.OracleDriver(1.0)
__________________
Roland |
|
|
00
|
|
|
#11 |
|
Membre Expert
![]() ![]() Consultant informatique Inscription : mai 2007 Messages : 893 ![]() |
Il y a un lien ici. Par contre je sais plus si c'est type 3 ou 4.
L'idée étant la suivante: si dans ton driver la méthode close ne ferme pas la connexion celle-ci reste ouverte. Tu peux donc lancer tes rapports quelques fois au début mais après tu auras une exception comme quoi il y a plus de connexions disponibles. Si tu n'as pas ce genre de problème, il faut chercher ailleurs |
|
|
00
|
|
|
#12 |
![]() ![]() Consultante/Formatrice BIRT & Ingénieur Java/J2EE/GWT Inscription : janvier 2005 Messages : 7 299 ![]() |
Tu n'aurais pas aussi ce driver par hasard : oracle.jdbc.driver.OracleDriver ?
Si oui, peux-tu essayer avec ? Sinon, il doit se trouver dans le JAR ojdbc14.jar. Pour info : http://www.developpez.net/forums/d77...n-base-oracle/ EDIT : Et plus... http://serverfault.com/questions/104...and-ojdbc6-jar (Il me semble que BIRT est compilé en Java 5) |
|
|
00
|
|
|
#13 |
|
Membre émérite
![]() Développeur informatique Inscription : juin 2004 Messages : 697 ![]() |
Merci à tous les deux pour les liens !
@lazarel : Comme expliqué plus tôt, la lenteur survient, non pas à l'exécution d'un rapport, mais à l'ouverture de la fenêtre de création ou d'édition d'un jeu de données dans RCP Designer, et cela dès la première fois. @BiM : Je viens d'essayer avec ojdbc14.jar et le driver dont tu parlais, même problème. NB : Juste un "détail" que j'ai oublié de préciser : nous sommes en version 2.30 aussi bien pour le Viewer que pour le Designer. Et pour des questions de déploiement chez les clients, il faudra que je fasse avec en tous cas pour un moment
__________________
Roland |
|
|
00
|
|
|
#14 |
|
Membre Expert
![]() ![]() Consultant informatique Inscription : mai 2007 Messages : 893 ![]() |
Tu as cette lenteur si tu veux afficher la prévisualisation des données seulement ?
|
|
|
00
|
|
|
#15 |
|
Membre émérite
![]() Développeur informatique Inscription : juin 2004 Messages : 697 ![]() |
@lazarel
Non, à l'ouverture de la fenêtre, et même en cas de création d'un nouveau jeu, à un moment où la requête n'existe même pas, on a simplement précisé quelle source de données on va utiliser ! Ensuite, la prévisualisation des données répond bien aux délais qu'on peut escompter, suivant la complexité des requêtes. En gros, mon idée, en ouvrant la discussion, c'était : "Le problème est dû au "chargement" de tous les schémas de l'instance. Existe-t-il un moyen de dire au Designer : Inutile de me rechercher tous les schémas, puisque le User sous lequel je me connecte n'a de droits que sur son seul schéma !"
__________________
Roland |
|
|
00
|
|
|
#16 |
|
Membre Expert
![]() ![]() Consultant informatique Inscription : mai 2007 Messages : 893 ![]() |
Dans ce cas, il s'agit d'un problème coté base de données. Tu dois utiliser un utilisateur qui n'a accès et ne doit voir que ce dont il a besoin
![]() Demande à ton DBA |
|
|
00
|
|
|
#17 |
![]() ![]() Consultante/Formatrice BIRT & Ingénieur Java/J2EE/GWT Inscription : janvier 2005 Messages : 7 299 ![]() |
Heu, et normalement, dans ton URI pour accéder à la base de données, tu peux aussi préciser le schéma.
|
|
|
00
|
|
|
#18 |
|
Membre émérite
![]() Développeur informatique Inscription : juin 2004 Messages : 697 ![]() |
@BiM
Je ne pense pas. En fait dans Oracle, les notions de User et Schema se superposent (contrairement à PostgreSQL par exemple). D'après ce que j'en comprends, un schéma n'est que l'ensemble des objets appartenant à un User. @Lazarel Mon User n'a que CONNECT et RESOURCE comme rôles. Difficile de faire moins. En fait, je vois les autres Users, mais pas leurs objets, sauf quelques exceptions (pourquoi, je ne sais pas et n'ai pas beaucoup le temps d'approfondir). Bon, vu qu'il ne semble pas y avoir de solution simple Merci pour vos efforts !
__________________
Roland |
|
|
00
|
|
|
#19 |
![]() ![]() Consultante/Formatrice BIRT & Ingénieur Java/J2EE/GWT Inscription : janvier 2005 Messages : 7 299 ![]() |
Mais l'utilisateur n'est pas obligé d'avoir les droits sur tous les schémas.
Et normalement, en Oracle, tu peux préciser le schéma comme suit : jdbc:oracle:thin:<schema>@<server>:<port>:<SID> (A vérifier tout de même) |
|
|
00
|
|
|
#20 |
|
Membre émérite
![]() Développeur informatique Inscription : juin 2004 Messages : 697 ![]() |
Oui, on peut effectivement, mais c'est juste une manière alternative de passer la paire user/password.
http://www.oracle.com/technetwork/da...281.html#05_04 Je viens de tester, ça ne change absolument rien Quant à avoir les droits sur tous les schémas, non bien sûr, mais les voir, si apparemment, à moins que nos serveurs soient installés d'une manière tout à fait spéciale, mais si c'est le cas, notre DBA l'ignore Ceci dit, je me suis dit que cet affichage était la cause de la lenteur, parce que c'est la seule chose visible qu'il fait à part se connecter à la base, mais c'est peut-être tout à fait autre chose.
__________________
Roland |
|
|
00
|
Copyright © 2000-2012 - www.developpez.com