J'ai une procédure stockée où je lis les données de 5 tables. Les données renvoyées par la table numéro 4 sont en fait appelées via l'exécution d'une autre procédure stockée.

Procédure stockée:

    SELECT from tbl_1
    SELECT from tbl_2
    SELECT from tbl_3
    EXEC sproc2 -- returns rows from tbl_4
    SELECT from tbl_5

Fait intéressant, en faisant dataReader.NextResult en C # pour les lignes du tableau 5, je me rends compte qu'il n'y a pas de résultat. Cela n'arrive pas fréquemment, mais j'ai remarqué que cela se produisait plusieurs fois.

L'erreur que je remarque de SqlAzure est

cette limite de ressources de base de données est atteinte.

La procédure stockée entière ne devrait-elle pas s'exécuter dans un seul thread et devrait être immunisée pour limiter les problèmes d'utilisation une fois qu'elle commence à s'exécuter? Ou est-ce à cause de la planification circulaire où SQL Server n'a pas pu redémarrer l'exécution de ma procédure stockée en raison de ressources indisponibles?

1
divyanshm 17 janv. 2017 à 12:23

2 réponses

Meilleure réponse

Donc, après avoir exécuté un tas de requêtes dans le magasin de requêtes et essayé de comprendre ce qui se passe avec ma base de données, voici ce que j'ai compris

  1. Il y avait des requêtes de longue durée que nous exécutions de temps en temps, des requêtes qui nettoyaient et des requêtes qui collectaient des journaux. Malheureusement, ils ont décidé de courir en même temps. Ces requêtes ont reçu une grande mémoire par SQL.

  2. Les requêtes aléatoires ont commencé à expirer et j'ai remarqué qu'elles étaient bloquées avec un type d'attente resource_semaphore_query_compile. Cela signifie que SQL n'avait pas de plan mis en cache pour cette requête et qu'il n'avait même pas assez de mémoire pour compiler à nouveau la requête.

  3. La mémoire totale attribuée à MEMORY_SQLQERESERVATIONS était élevée tandis que celle du cache du plan était faible, c'est ce que j'ai comparé à l'utilisation générale de la mémoire sur le serveur SQL.

Pour résumer, en raison des requêtes en 1, 2 se sont produites et il en a résulté 3.

En ce qui concerne la question que j'avais posée, sproc2 était une grosse requête et était en quelque sorte toujours expulsée du cache du plan.

0
divyanshm 3 févr. 2017 à 05:24

La procédure stockée entière ne devrait-elle pas s'exécuter dans un seul thread

Lorsque vous soumettez une requête à SQL Server, il peut choisir d'exécuter la requête en parallèle en fonction de nombreuses conditions. L'un d'eux est cost Threshold for Parallelism. Donc pour votre première question, la réponse est que cela dépend

FYI .. plusieurs fois, une requête bénéficiera de l'exécution en parallèle, le parallélisme n'est donc pas toujours mauvais.

Venir à votre scénario et demander ...

La procédure stockée entière ne devrait-elle pas s'exécuter dans un seul thread et devrait être immunisée pour limiter les problèmes d'utilisation une fois qu'elle commence à s'exécuter?

SQL Server peut estimer la mémoire requise pour la requête et peut interrompre son exécution (ne démarre même pas), jusqu'à ce qu'il dispose de suffisamment de mémoire pour démarrer.

Mais dans Azure DTU, il y a une combinaison de mémoire, d'E / S, de CPU et n'importe lequel d'entre eux peut atteindre son quota et il n'y a aucun moyen de restreindre une requête pour utiliser des IO et un processeur limités

Ainsi, une requête peut s'arrêter entre entre si l'unité de bureau est fortement contrainte, une fois son temps d'attente écoulé.

Pour résoudre ce problème, Azure propose des informations sur les performances pour en savoir plus sur l'utilisation des DTU par requête, afin de pouvoir les affiner.

Avec un aperçu des performances, vous pouvez obtenir

  1. un aperçu plus approfondi de la consommation des ressources de vos bases de données (DTU).

  2. Les requêtes principales par nombre de CPU / durée / exécution, qui peuvent potentiellement être ajustées pour améliorer les performances.

  3. La possibilité d'explorer les détails d'une requête, d'afficher son texte et l'historique de l'utilisation des ressources.

1
marc_s 2 févr. 2017 à 06:51