Discussion :

[dany_dane]

Bonjour(Nouveau sur le forum),

Voila je suis face à une grosse base de données sous Sybase, et je dois refaire le modèle de données de la base en supprimant les tables et procédures stockées non utilisés sachant qu'il y a un traitement quotidien sur la base. J'ai entendu parlé d'un outils qui me permettais de voir les statistique d'utilisation des tables et procédures de la base ou un truc du genre, un outils interne ou autre qu'on pouvait lancer.
Existe-il vraiment un outils de ce genre la? Sinon avez vous une autre alternative à me proposer.

Merci par avance

[mpeppler]

Pour les tables, et pour autant qu'on soit en 12.5.0.3 ou plus récent, on peut utiliser la table master..monOpenObjectActivity (qui fait partie des tables "MDA") pour estimer le taux d'utilisation. je souligne le terme "estimer" parce que les données dans cette table sont remisent à zero lors du redémarrage du data server, et peuvent aussi être effacées si les variables de config "number of open objects" et "number of open indexes" sont trop petites.

Pour les procs c'est nettement plus compliqué. Un outil comme sqlbrowser (www.sqlbrowser.com) peut faire une analyse statique de tout le code SQL sur le serveur, ce qui donne de l'information sur les dépendances entre les objets. Ensuite, il est possible en utilisant la table master..monSysStatement (aussi une table MDA) de déterminer les statements qui sont exécutés. A nouveau - cette utilisation donne une estimation, et n'est pas complètement triviale à mettre en oeuvre.

On peut aussi utiliser l'auditing et auditer toutes les executions de proc stockées.

Michael

[dany_dane]

Merci bien pour ta réponse, je vais vérifier tout ça.

Si j'ai bien compris, tant que la base n'est pas redémarré les stats dans master..monOpenObjectActivity sont correctes?

Oue je peux localiser "number of open objects" et "number of open indexes" pour vérifier que leur taille n'est correcte?

Concernant l'auditing des proc stockées, tu parles bien de modifier tous les procs en faisaint en sorte qu'ils font un insert sur une table qui sert de log à chaque que la proc est èxécuté?

[mpeppler]

Pour vérifier la valeur de "number of open ..." - sp_monitorconfig 'all', et voir la colonne "max used" et "num reuse".

Pour l'auditing - non - on peut mettre en place l'audit Sybase (via la base sybsecurity) et ensuite mettre en marche l'auditing de l'exec de procs stockées (via sp_audit 'exec_procedure', 'all', 'all', 'on').

Mais effectivement, si tu as un nombre relativement restreint de procs qui sont soupçonnées de ne plus être utilisées alors on peut aussi ajouter du logging à la proc même...

Michael

[dany_dane]

Bonjour, Merci pour ces infos
J'ai pu tester quelques un de tes scripts dans les tutos.
Cependant j'avais des question : Y-a il une requête permettant de connaître la date du dernier démarrage du dataserver?
En effet je ne contrôle pas ce niveau d'utilisation des bases.

La colonne OptSelectCount de monOpenObjectActivity me donne bien le nombre de fois que l'index à été lu pour l'objet?
DOnc je peux en déduire que sur chaque utilisation du "select" sur une table passe obligatoirement pas la lecture de l'index associé?


La différence entre OptSelectCount UsedCount(qu'est que l'optimiseur)?

[mpeppler]

Une façon de voir quand le serveur a été démarré:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
select crdate from master..sysdatabases where name = 'tempdb'

puisque la base tempdb est re-créée au démarrage.

Sur monOpenObjectActivity - IndId 0 représente la table elle même (cad un table scan). IndId 1 est le "Clustered" index.

OptSelectCount: nombre de fois que cet index à été pris en compte par l'optimiseur.
UsedCount: nombre de fois que cet index a été effectivement utilisé

La différence peux venir d'un chemin d'optimisation qui change en cours d'execution.

[dany_dane]

Merci pour ces infos, ça règle tout mon problème.
Une ultime question, j'ai une table qui comporte environ 10 million de données, je tente de supprimer(ou désactiver) un trigger sur cette table mais je n'y arrive pas.
J'ai laisser tourner toute la nuit et le matin rien,j'ai deja eu le temps d'être deconnecté.
AUrait-tu un moyen de pro pour palier à ce problème sans supprimer la table.

[mpeppler]

Si c'est vraiment un trigger, alors c'est soit:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
drop trigger <nom_du_trigger>

ou alors (desactivation temporaire):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
alter table <nom table> disable trigger

[dany_dane]

bonjour,
Juste un point pour les OptSelectCount UsedCount, si j'ai bien compris ces attributs comptabilisent uniquement les indexes ayant été sollicités dans une CLAUSE WHERE d'un select?
Donc je ne pourrais pas avoir d'informations sur les autres tables qui ne disposent pas d'indexes ou de requetes sans clause WEHERE? Si Oui existe t-il un autre moyen ou pas?

[mpeppler]

Si l'optimiseur choisi de faire un table scan alors le OptSelectCount, etc. est incrémenté pour l'IndId 0, cad la table elle même.

Michael

[dany_dane]

Bonjour,

En faite je n’ai pas très bien compris ce dernier point.
Ce que je retiens c’est que lorsque qu’il n’y a aucun index sur une table ou que les indexes de la table ne satisfont pas à la requête (ex : select * from client where age=20 , et que la colonne age n’est pas indexée), la requête utilise nécessairement un table scan pour analyser toute la table. Dans ce cas la, les indicateurs optselectcount et usecount ne sont pas impactés. Est-ce exact ?
Si oui, est-ce qu’il y a d’autres indicateurs permettant de connaître le nombre de table scan sur les tables.

Merci par avance.

[mpeppler]

Non - OptSelectCount et UsedCount sont impactés, pour la ligne où IndID = 0, cette ligne correspondant à la table elle même, et non pas à l'un des indexes.

Michael