Comment répondre aux raisons pour lesquelles nous avons soudainement besoin d'index ou de requêtes à modifier

Je suis DBA junior avec 3 ans d'expérience. Notre travail consiste à affiner les requêtes ou à informer les développeurs qu'un code particulier doit être réécrit ou que des index sont nécessaires.

Une question simple que l'équipe de développement pose fréquemment est: "Hier, ça s'est bien passé, qu'est-ce qui a changé soudainement?" et on nous demandera de vérifier le côté infrastructure. La première réaction à tout problème semble toujours être de blâmer au maximum l'infrastructure qui est toujours la première chose à valider.

Comment devons-nous répondre aux questions «qu'est-ce qui a changé» de l'équipe de développement? Avez-vous déjà fait face à la même situation? Si c'est le cas, partagez votre expérience.

Comment répondre à ce qui a changé de question par dev?

C'est une question très courante non seulement avec DEV, elle s'applique à toutes les équipes informatiques et commerciales.

Qu'est ce qui a changé ? ==> peut être répondu par des faits et des chiffres.

Les faits se réfèrent par exemple à

• augmenter le nombre d'utilisateurs qui accèdent à la base de données?
• Un changement dans le paramètre de configuration du serveur?
• Maintenance de la base de données - mise à jour des statistiques, réorganisation / reconstruction des index non effectuée? Pour cette raison, les plans ne sont pas générés correctement!
• La quantité de données a augmenté?
• Des modifications ont été apportées côté réseau, le système d'exploitation a été corrigé et / ou un nouveau service pack ou CU pour le serveur SQL a été déployé - sans effectuer un test de régression complet de votre cycle d'activité d'application ?
• Le SAN sous-jacent est devenu soudainement lent?

Des chiffres peuvent être dérivés si vous avez des données à afficher. Par exemple :

• Il est essentiel de basaliser votre serveur dans cette situation. Cela allégera le jeu du blâme puisque vous pouvez soutenir les faits avec des chiffres solides.
• Commencez à collecter des données à l'aide de DMV ou de sp_whoisactive dans une table, afin que les données soient conservées après un redémarrage du serveur SQL.

(vous devez vous entraîner en fonction de votre environnement et de vos besoins, de la fréquence de collecte des données / des données à collecter et de la durée de conservation) ou (vous pouvez investir dans un logiciel tiers comme sqlsentry ou le gestionnaire de diagnostic d'idera qui fera le travail ci-dessus pour vous) .

Eh bien, vous pourriez obtenir un plan différent parce que:

• le plan aurait pu être expulsé de la cache, en raison de:
  • un redémarrage du service
  • effacement manuel du cache du plan
  • un redémarrage ou un basculement de service
  • un changement par inadvertance, par exemple certains sp_configurechangements peuvent vider le cache
  • certains changements apportés aux objets, index, statistiques ou autres dépendances sous-jacents ont déclenché une recompilation
• vous pourriez simplement obtenir un plan différent de celui des autres utilisateurs ou des appels précédents car:
  • le texte de la requête peut ne pas être identique (cela inclut la sensibilité à la casse et les espaces, sans parler des différentes colonnes, des critères de jointure, des filtres, etc.)
  • la requête peut être exécutée par différents utilisateurs avec différentes options de définition (ou différents schémas par défaut, si un objet du plan n'a pas de nom complet, y compris le schéma )
• la requête et le plan peuvent être identiques, mais vous pouvez obtenir des performances différentes car:
  • le plan a été mis en cache à l'aide de différents paramètres, et ce plan n'est pas optimal pour l'ensemble de paramètres actuel (ce qui est communément appelé "reniflage de paramètres")
  • la quantité de données basée sur les paramètres ou simplement en raison d'un changement de données entre-temps est significativement différente
  • les données ont suffisamment changé pour modifier le moyen le plus efficace d'accéder aux données, mais pas assez pour déclencher des mises à jour ou des recompilations de statistiques (recherche d'un problème clé croissant ainsi que d'un algorithme de statistiques automatiques)
  • les données ont été supprimées du pool de tampons et doivent maintenant être lues à partir du disque
  • il y a plus de simultanéité, de blocage ou d'autres contraintes sur les ressources nécessaires pour satisfaire la requête

Je passe en revue beaucoup de ces éléments plus en détail ici:

• Plans multiples pour une requête "identique"

Si ceux-ci fonctionnent sur des environnements différents, j'ai une série de choses à vérifier ici:

• Différents plans pour les serveurs "identiques"

En outre, il est important de garder à l'esprit que la création d'un index ou la modification de la requête n'est peut-être pas la raison directe pour laquelle une requête fonctionne soudainement mieux - parfois c'est simplement parce que ces changements ont vraiment généré un nouveau plan et / ou invalidé celui qui existait déjà .

Comme d'habitude, Aaron Bertrand et Kin ont fourni d'excellentes réponses. Cependant, les deux réponses contiennent un fil conducteur. Si vous analysez l'une ou l'autre des réponses, vous verrez que la raison pour laquelle XYZ ne fonctionne pas comme cela a fonctionné hier n'est pas à cause de quelque chose que vous / ils / la personne X a fait. La raison pour laquelle les choses ont changé est que la base de données a décidé de faire les choses différemment pour des raisons XYZ.

Une base de données est une entité vivante et respirante . Les bases de données prendront des décisions et changeront d'avis en raison d'une combinaison d'hypothèses, de statistiques et d'autres outils heuristiques. Ceci est radicalement différent de la plupart des programmes de couche application (l'apprentissage automatique étant une exception notable).

_{Je vais utiliser des références militaires parce que je ne peux pas penser à quelque chose de mieux en ce moment. Une métaphore plus générale serait appréciée (sans jeu de mots).}

Dans la plupart des applications, le programmeur agit comme un instructeur de forage. Ils indiquent exactement à l'ordinateur ce qu'il faut faire, dans quel ordre et parfois pendant combien de temps. Programmer une base de données, c'est plus comme agir en tant que commandant. Vous lui dites ce que vous voulez qu'il fasse à un niveau élevé, et offrez des conseils si nécessaire. La base de données se charge de déterminer la meilleure façon d'exécuter le plan en fonction des renseignements actuels, comme les officiers subalternes et les sous-officiers.

En faisant clairement cette distinction dans l'esprit des autres programmeurs, ils commenceront, espérons-le, à voir que vous n'avez pas de pouvoirs dicturaux comme ils le font sur leur environnement. Vous guidez la base de données vers la solution et, parfois, la base de données se dérobe pour de bonnes ou de mauvaises raisons. Rappelez-leur qu'en fin de compte, peu importe pourquoi * la base de données a déraillé, mais ce que nous pouvons faire pour la ramener.

_{* Je reconnais que «pourquoi» est très précieux pour la prévention, l'apprentissage, etc. futurs, mais il semble que le PO soit confronté à la résistance de personnes qui n'essaient pas d'apprendre ou d'aider le problème.}