Oui, il existe plusieurs façons de suivre toutes les requêtes que Sybase reçoit.
Cependant, compte tenu de la deuxième partie de votre question, si je comprends bien, vous devez (1) comprendre ce que votre requête fait (2) surveiller votre SPID actif dans le contexte d'autres SPID actifs et ... si cela ne suffit pas, (3) surveiller le serveur; pas trace, et toutes les requêtes. Par conséquent je vais aller dans cela et différer répondre aux éléments de traçage disponibles dans Sybase.
Votre connexion à ASE est un ID de processus serveur ou spid.
SET showplan et noexec SET et exécuter votre requête. Cela donnera un très bon aperçu de ce que votre SQL est en train de faire, sous les couvertures. Ceci est une exigence essentielle , quelque chose que chaque développeur devrait connaître, et demandé avant le test. Chaque fois que vous avez l'impression que votre requête est lente, vérifiez toujours les E/S en cours: SET STATISTICS IO ON.
sp_who; sp_lock; et regarder votre spid cochant, suspendu, en attente de verrous, bloqué, quels autres spids le tiennent, etc. Ceci est l'ensemble de base que chaque développeur devrait utiliser, tout le temps. Sp_sysmon surveille le serveur (entier). Il peut être utilisé de deux façons: comme un outil de surveillance continue, par exemple saisir une heure complète de statistiques, qui est la base pour la configuration du serveur changements; et comme un instantané, par exemple. saisir un instantané 5 minutes du serveur lorsque votre processus est en cours d'exécution et lorsque ce n'est pas le cas, et examiner les différences . Généralement c'est pour les administrateurs de base de données expérimentés, pas les développeurs, et vous avez besoin de sa_role.
Tout est dans les manuels, à la fois en ligne et PDF.
Sept heures est un temps très long, donc vous devez utiliser un curseur ou similaire, et le traitement des lignes individuelles plutôt que ensembles. Vérifiez régulièrement les tâches par lots (vidages, mises à jour, réorganisations) pesant au bout de 7 heures; certains d'entre eux tiennent des verrous de table.Bien sûr, si le serveur fonctionne sur Windoze, toutes sortes de choses étranges, de fuites de mémoire vers le haut, sont tarif standard; rebondir la boîte chaque semaine au moins.
Avec cet ordre de charge de traitement, vous devez garder à l'oeil le votre journal des transactions et l'utilisation de tempdb.
Hi PerformanceDBA, Merci pour la réponse incroyablement détaillée! Je n'ai pas eu l'occasion d'essayer toutes les 3 tactiques que vous m'avez données, mais sp_who et sp_lock étaient exactement ce que je cherchais. Malheureusement, cela ne m'a pas aidé à résoudre mon problème. Cependant, il m'a dit que les spids dans Sybase étaient dans l'état de sommeil recv. Mon programme attendait également quelque chose de Sybase, entraînant une impasse, et donc le "comportement étrange". Si ce n'est pas trop de problèmes, j'ai une autre question à vous poser: Y a-t-il un moyen de tracer le client Sybase ASE? (pas la DB) Pour l'instant je vais essayer Ribo. – Jdcc
S'ils sont dans l'impasse, ils attendent une ressource qui peut être facilement identifiée; ils ne seront pas "recv sommeil" ce qui signifie dormir, en attendant de recevoir un paquet du client. Vérifiez la colonne AWAITING COMMAND & sp_lock * au moment *. Ribo est une méthode de traçage; méfiez-vous des volumes de sortie. L'autre est l'audit. Les deux ont un coût de main-d'œuvre d'installation, mais l'audit est configurable. – PerformanceDBA
Oui, mes processus sont définitivement dans les états "RECV sleep" et "AWAITING COMMAND". sp_lock ne montre rien lié à mes processus. Je devine que mon client et mon serveur finissent par attendre l'un sur l'autre plutôt que d'être bloqués par un verrou réel. S'il n'y a pas de trace sur le client ASE, alors je devrai surveiller ce que mon programme envoie au client, et le SQL que mon client envoie au serveur. Je vais essayer l'audit, car il semble qu'il n'utilise pas une approche d'homme-dans-le-milieu. Je ne savais pas qu'il était configurable, donc merci pour cette info :) – Jdcc