puisque nous sommes entre français, alors parlons français, ce sera plus simple !
donc, pour mieux expliquer mon problème : si je redémarre les process ingres et qu'ensuite j'exécute mon programme qui fait pas mal d'accès, c'est ok : il y a une seule fois le 'define query' pour chaque requête différente que l'on fait dans le programme.
au bout de quelques jours, ce n'est plus la même chose : les define query se refont plusieurs fois pour la même requête.
est ce que ce problème peut venir de problèmes de lock, de réorganisation de tables ou autres ?
savez vous comment gérer les variables liés aux locks ?
merci de votre réponse
-------------------------
Followup To
Question -
to improve the performances of applications, i use 'repeated select' in my programs.
when the application runs, the define query is done more than one time for the same query. it should be done one time only.
do you know why ?
Answer -
Hello,
First, sorry to answer a little in late ...
"repeated select" only tell to the dbms to store the QEP in it's memory. So when the query is defined the second time, DBMS do not have to recalculate it. It was true only and only if the same query is running (do not hope the "repeated" run along the same table thru differents query's (ie differents where clause).
In the past with an other DBA whe made a loop program (Embeded/C) to "mesure" performance of our information system. The loop consist to a "repeated select" on the main and bigget table with a blank key (to ensure each time the DBMS scan all the table) and then output the elaps time of the query. The first run take seconds (2 ou 3), and the others less than one.
Hope this is clear (i'am french so my english could be sometimes a little poor :-) and help you,
Jean-Pierre ZUATE
Answer Bonjour,
Faire un lien entre la répétition des "define query" et les locks, j'ai un peu de mal à priori. Quelques questions pour vous ...
- Votre programme se connecte une fois le lundi (par exemple) et c'est en fin de semaine que vous voyez qu'il y a plusieurs define ?
- Comment vous voyez ça ? Quelle trace utilisez vous, etc.
- Dans quel langage est écrit votre programme ?
- Vous faites un lien entre le nombre de fois où le define apparaît et les performances ?
Sinon effectivement il peu y avoir un lien entre le nombre de verrous (locks) et l'organisation d'une table. Plus elle est désorganisée (donc plus il y a de pages d'overflow, colonne overflow_pages de iitables), plus la consommation de verrous sera importante pour accéder à la même donnée (on pose un verrou par page d'index, feuille, data, etc.). Attention : si la structure est HASH, l'overflow dépend surtout de la répartition de la clé (plus les valeurs de clé sont linéaires moins il y a d'overflow).
Les ressources pour controler les verrous sont les suivantes :
* niveau session : voir l'ordre SQL "SET LOCKMODE" qui donnera la stratégie en lecture (nolock, shared, exclusive), le niveau (row, page, table), le timeout, et surtout le maxlocks. Maxlocks est le nombre de verrous au delà duquel Ingres escalade au niveau table. Ces paramètres, depuis IngresII 2.0, existent aussi dans CBF (DBMS Server, paramètres system_readlock, system_maxlocks) et définissent ses valeurs pour les connexions qui utilisent ce moteur.
* niveau système : dans CBF il y a un ligne "locking system" où vous allez définir le "per_tx_limit" (nbre de verrous par transaction). Dès que ce nombre est atteint et qu'on en réclame un autre, la session tombe en "out of locks"
