Ce que l’Administrateur de la Base de données Entend

Ce que l’Administrateur de la Base de données Entend

Imaginez cette scène: Il est un peu après 17 heures un vendredi et un message de discussion apparaît de mon programmeur d’application « préféré ». Quelque chose ne fonctionne pas correctement. Oui, c’est le message. « Quelque chose » ne fonctionne pas correctement. C’est tout.

« OK”, dis-je. « Qu’est—ce que vous essayez de faire-donnez-moi un peu plus de détails pour que je puisse vous aider, et combien de temps allez-vous être là pour résoudre ce problème?”

« Oh, je rentre à la maison maintenant, mais j’ai pensé que vous pourriez peut-être jeter un coup d’œil aux choses” est la réponse.

Ce n’est pas une exagération des types de situations qui apparaissent régulièrement. Bien sûr, ce ne sont peut-être pas les mots exacts, mais je parierais que la plupart des administrateurs de bases de données ont reçu ce type de demande. Alors, que faut-il faire dans ce type de situation?

Eh bien, la première chose à remarquer est que ce n’est sûrement pas un problème urgent. Si c’était urgent, alors personne ne partira pour le week-end, n’est-ce pas? Le deuxième point à retenir, et probablement le plus important, est qu’une manière plus formelle de demander des services de DBA est probablement nécessaire. Si le demandeur doit remplir un ticket de service avec les détails du problème avant que l’équipe DBA puisse l’aider, la probabilité d’obtenir des détails plus utiles augmente.

Remarquez que j’ai dit « probabilité » et non « certitude ».” Et cela m’amène à une autre conversation amusante programmeur/DBA. Vous voyez, ce développeur avait des problèmes pour faire fonctionner son programme. Et pour être juste envers lui, c’était un scénario complexe avec plusieurs environnements, plusieurs SGBD et plusieurs programmes appelant d’autres programmes.

Mais ensuite, il a partagé sa « sortie de trace » avec moi qu’il utilisait pour aider à résoudre son problème. Cette sortie était essentiellement un tas d’instructions d’AFFICHAGE dans son programme. Maintenant, ne vous méprenez pas, je n’ai aucun problème avec ce type de test et de débogage; cela peut être très utile pour suivre ce qui se passe réellement. Mais c’était là, sa  » trace de sortie” me fixant en face, ressemblant à quelque chose comme ça:

Premier enregistrement lu à partir du fichier d’entrée: clé 00001
Appel au programme ABC001
ERREUR

Oui, la trace de sortie « utile » affichait le mot erreur. Oh, oui, c’était en majuscules donc ça doit être une grave erreur, non? Alors, j’ai dit “  » Oui, on dirait que vous avez une erreur là-bas.” Je veux dire, que pourrais-je dire de plus, n’est-ce pas?

La conclusion ici est que le code d’erreur ou le message réel est nécessaire. S’il s’agissait d’un problème SQL, affichez le SQLCODE. Avec plus de détails comme celui-ci, le développeur pourrait peut-être résoudre le problème sans demander l’aide du DBA.

Ce qui m’amène à une autre chose que les DBA entendent fréquemment de la part des développeurs: “Je reçois toujours ce SQLCODE-xxx lorsque j’exécute mon programme. Qu’est-ce qui ne va pas?” Je n’ai pas mis de code spécifique, mais il y en a beaucoup de communs(-805, -913, -104, -305, -904). Je parie que chaque DBA sait ce que signifient ces valeurs SQLCODE dès le début de leur tête.

Voici la chose, cependant. Les SQLCODEs sont faciles à rechercher. Il suffit de le taper dans un moteur de recherche dans votre navigateur Internet et il est là, grand comme la vie. Il n’y a absolument aucune raison pour qu’un programmeur d’application ne recherche pas d’abord le code SQLCODE et ne lise pas la description pour comprendre quel est le problème. Et ensuite d’essayer de le résoudre eux-mêmes avant de demander de l’aide.

En tant que DBA, je suis plus que disposé à aider avec un sourire sur mon visage lorsque le programmeur demande quelque chose comme “J’ai un -904 et je sais que cela signifie que ce à quoi j’essaie d’accéder n’est pas disponible. Mais je ne sais pas pourquoi. Voici l’instruction SQL que j’essayais d’exécuter lorsque j’ai reçu ce message.” Tellement mieux que “Je reçois un -904, que dois-je faire?”

Et cela m’amène à une autre tactique utile pour les administrateurs de bases de données. Créez des documents d’explication/d’aide pour ces codes SQLCODEs courants qui apparaissent encore et encore. Et puis, lorsque vous recevez une demande d’aide pour ce type de problème, dirigez simplement le demandeur vers le document. Cela peut économiser beaucoup de temps et d’efforts de DBA.

Ensuite, il y a le problème de performance qui est présenté de cette manière: « Cette requête s’exécute rapidement tous les jours depuis que nous l’avons créée et elle existe depuis quelques années maintenant. Mais quand je le lance aujourd’hui, il dure longtemps, puis expire. Qu’as-tu fait?”

Oui, qu’a fait le DBA, pas ce qui a changé avec la requête. Place à la méthode Socratique.

“Avez-vous changé quelque chose à propos de la requête?”

“Je ne pense pas.”

« Qu’en est-il des données? Y en a-t-il plus?”

« Pourrait être wait attendez une minute”

« Quelle clause WHERE?”

“Celui du produit.”

« OK, donc vous exécutez la requête pour chaque produit de l’entreprise?”

“Oui. Cela pourrait-il ralentir l’exécution de la requête?”

« Vous voulez dire accéder à 6 millions de produits au lieu de 1? Oui, cela pourrait ralentir les choses.”

Veuillez donc être gentil lorsque vous envisagez de contacter votre DBA pour obtenir de l’aide. Essayez d’abord de résoudre le problème vous-même. Examinez toute documentation que les administrateurs de base de données ont mise à votre disposition pour vous aider à examiner et à résoudre vous-même les problèmes avant d’abandonner. Assurez-vous de documenter tout ce que vous avez fait et d’avoir cela prêt à partager avec le DBA lorsque vous contactez. Et veuillez fournir des messages d’erreur significatifs.

L’objectif est que les développeurs et les administrateurs de bases de données fonctionnent en équipe. Plus vous pouvez faire en tant que développeur pour minimiser le fait de dire les mêmes vieilles choses au DBA, mieux c’est. Lorsque vous travaillez pour fournir des informations utiles et significatives pour aider à diagnostiquer un problème, vous découvrirez que vous résolvez les choses vous-même plus souvent. Et lorsque vous impliquez le DBA, vous constaterez qu’il est généralement plus heureux et plus en mesure d’aider rapidement.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.