Performance sur les temps de connection et d'ouverture de session?

Bonjour a tous, je suis confronté depuis peu a des problèmes de temps d'ouverture d'une session sybase.
J'i un ASE 12.5.3 sur du solaris, avec une machine sun bi-pro, 2 Go de ram volumétrie de la base 40 Go...
J'ai regardé qq trucs comme nbr de users connections problème réseau ou prob système mais rien ni fait en plus une fois connecté les requètes lambda s'éxécute aussi vite qu'avant..
Pourriez vous m'indiquer les pistes a investiguer au niveau d'ASE pour voir la ou les options a regarder et/ou modifier pour améliorer ces performances.
Merci par avance a tous!!!;)

Est-ce qu'il y a un "login trigger" définit pour le ou les users utilisés ?

Autrement je ne vois pas vraiment ce qui peut poser problème au niveau d'ASE. Pour info, combien de connexions simultanées, et combiens de nouvelles connexions par unité de temps (p.ex. nombre de nouvelles connexions par heure) ?

Michael

salut Mickael je fais suite a ta réponse.
Je ne suis pas au taf, mais si c'est desz logins trigger les responsable, comment améliorer les choses ??
Merci de ton aide.
A+

Cela dépend évidement de ce que font ces "logins triggers". Puis-ce que ceux-ci sont en fait des proc stockées qui sont appelées au moment du login il est possible que ces procs soient mal optimisées et que cela prolonge anormalement la durée du login.

Evidemment, s'il n'y a pas de "login triggers" alors il faudra chercher ailleur...

Michael

salut, merci mickael, en fait il n'y a pas de loggin trigger, visiblement dans cette boite il n'y a pas de reorg rebuild de fait sur une base qui a toutes ses tables en DOL depuis pres de 4 ans.... Je vais donc commencer par mettre en place cela.
J'espère que cela suffira.
Merci de tes réponsses.
A+

Le "reorg rebuild" ne va en principe pas améliorer le temps de connexion, et n'est pas nécessairement utile pour améliorer la durée de requêtes - en particulier les inserts si le "fillfactor" est mal calculé (on reorg, cela rempli les pages, on insert, et on doit splitter plus de pages que normal...).

Personellement je fais des "reorg compact" pour minimiser le nombre de "forwarded rows", et occasionellement des "reorg rebuild <table> <index>". Comme ces commandes ne prennent pas de locks exclusifs de longue durée sur les tables elles sont plus faciles à implémenter que le "reorg rebuild" pur.

Michael

merci pour ta réponse, je vais voir ce que je peux faire en fonction des infos que tu as fournis..
Sinon une autre question , je devrais peut être créer un autre sujet mais bon... faite moi savoir si c'est que je dois faire.
Bon donc mon autre question est: là ou je suis ils utilisent les "thresholds action" pour gérer les "coups dur" en terme de remplissage des logs. je vais mettre en place les options "pllsort, et autres trunc log ...". Ma question est quel est le plus intéréssant et les raisons d'utiliser plus les "hresholds action" que les options commune des bases ??
Enfin il me semble qu'il éxiste une commande pour générer le .rhrc pour utiliser srvbuild avec un ficier de création.
J'ai deux questions en fait.

Tiens au faite je suis allé chercher sur ton site pour récupérer sqsh, et le nom des fichiers sont en x86 pour sol, est ce que c'est bon pour solaris 10 ??
question con sans doute vu que j'ai pas tester ce que j'ai download.
Merci de tes infos.
A+

A priori je pense que cela mériterait un nouveau sujet, mais bon...

Pour les options par défaut dans une base de prod je suis en faveur d'avoir "abort tran on log full" mis à vrais, mais de laisser "select into" et "truncate log on checkpoint" à faux.

Ensuite, j'ai un job qui fait la save des transactions logs de façon régulière, et aussi une proc threshold action pour intervenir dans le cas où la consommation de syslog est plus importante que d'habitude.

L'option "select into" ne devrait à mon sens être positionnée que quand cela est strictement nécessaire, cad si on veut faire un reorg rebuild, ou une opération de DDL qui la requiert (alter table drop column, par example). Cela permet de controler quand ce genre d'opérations non-loggées sont faite, et de faire un "dump database" complet après pour assurer la recovery de la base.

Pour ce qui est du fichier de resource il y en a un qui est généré lors de l'installation (quand on créé une instance avec le "setup"). Autrement on peut facilement prendre un des fichiers example (dans $SYBASE/$SYBASE_ASE/init/sample_resource_files) et mettre les valeurs qui vont bien. On utilisera la command srvbuildres ensuite pour créer l'instance avec le fichier resource.

Enfin, le binaire sqsh Solaris x86 il devrait marcher sous Solaris 10 aussi.

Michael

merci de tes réponsses rapide..
J'aurais sans doute due faire un autre sujet mais bon, tant pis.
Pour sqsh je vais tenter une install bientot, il faut recompiler le "bignou" je crois.
Quoi qu'il en soit merci a toi.:P