none
Combien de requête par milliseconde ? RRS feed

  • Discussion générale

  • Bonjour,

    Je me tourne vers la communauté car je ne trouve pas de réponse à mes questions sur le(s) web/blog/forum.

    Il s'agit d'un souci de concurrence d'accès, ou au moins ca y ressemble beaucoup.

    J'ai plusieurs postes capable d'interroger un webservice lui même executant des select et update sur une base sql serveur 2005, il existe donc plusieurs instance de ce webservice executant chacun plusieurs select et update en cascade.

    Le souci est le suivant, lorsque deux requêtes select sont lancées à la même milliseconde, parfois le résultat de l'une d'entre elle est vide pourtant le select devrait fonctionner (en théorie il ne sert a rien sauf pour sécuriser l'update qui suit).

    Après plusieurs essais j'en arrive à passer par une procédure stockée qui diminue grandement les erreurs mais mon serveur étant bombardé de requête, le souci subsiste.

    La seule parade que j'ai trouvé et d'utiliser l'isolation WITH(NOLOCK) pour ma requête select, j'utilise le mot "parade" car je n'ai aucune erreur dans le journal SQL qui me permet de confirmer qu'il s'agit la bien d'une solution à mon problème.

    Je me pose la question à savoir quels sont les limites de SQL Server Express 2005 à ce niveau ?

    Quelques indices/pistes ne serait pas de refus pour connaitre l'origine de ce souci.

    Merci bien ;)

    jeudi 30 août 2012 14:02

Toutes les réponses

  • Suite à un nouveau test je suis forcé de contater sur l'utilisation de WITH(NOLOCK) ne suffit pas, je continue mes recherches.

    Merci.


    • Modifié LaurentHD vendredi 31 août 2012 14:56
    vendredi 31 août 2012 14:55
  • Bonjour,

    Le comportement décrit  indique une impasse (DEADLOCK).

    Vous devez  enregistrer les exceptions  (en utilisant TRY CATCH dans le WebService ou même dans la procédure stockée) qui apparent pendant l’exécution de  la  procédure stockée et vérifier exactement le type d’erreur.


    Aurel BERA, Microsoft
    Microsoft propose ce service gratuitement, dans le but d'aider les utilisateurs et d'élargir les connaissances générales liées aux produits et technologies Microsoft. Ce contenu est fourni "tel quel" et il n'implique aucune responsabilité de la part de Microsoft.

    jeudi 6 septembre 2012 14:02
    Modérateur
  • Bonjour,

    Pour pouvoir vous aider plus efficacement, pourriez-vous nous fournir des informations complémentaires qui pourraient être utiles pour cerner l'origine ( ou les origines ) de votre problemè ?

    - 1 la version complète de votre SQL Server ( le dernier service pack installé )

    - 2 la mémoire configurée pour l'ensemble des requètes ( elle est de toute façon limitée à 1 GO pour les versions Express )

    - 3 avez-vous activée la réplication ?

    -  4 utilisez-vous le Reporting Service ?

    - 5 avez-vous activé la propriété AutoUpdateStaticEnabled ?

    - 6 la taille d'augmentation pour les fichiers data ( .mdf et peut-etre .ndf ) et log transaction ( .lfd , 1 seul suffit ). Si cette augmentation est trop faible et donc trop fréquente, if y a une requète Windows d'augmentation, opération très lourde et bloquante, le temps nécessaire à cette augmentation étant inclus dans le timeout de la commande , cela pourrait déclencher un timeout de la commande ( la valeur par défaut du timeout est de 30 secondes )

    - 7 la structure de la table ( CREATE TABLE complet + les index/clés serait utile pour comprendre ce qui se passe )

    Attention, la mise à jour de la table n'est pas instantanée, les modifications/créations sont d'abord stockées dans le journal de transactions et ultérieurement écrites réellement dans la base de données ( le temps de latence peut dépendre de la charge des disques et processeurs ). C'est pour cela qu'il est recommander de mettre les fichiers data et log sur des disques physiques différents.

    Le temps total d'une requéte est très difficile à définir puisque dépendant de beaucoup de paramètres. De plus, SQL Server Express ne peut en aucun cas utitldser plus de 1 GO de mémoire ( même pour 2012 )

    Dans mes applications , quand je fais un INSERT/DELETE , c'est toujours par l'intermédiaire d'une procédure stockée qui inclut le l'INSERT/UPDATE suivi d'un SELECT dont je renvoie les valeurs dans les paramètres de la procédure stockée ( définis comme étant InputOutput )

    Je pense que le post de LaurentHD est très pertinent. Dans toutes mes applications, j'insère mes commans dans des groupes TRY/CATCH  et je traite séparément la SQLException que je traite dans une méthode spécifique en renvoyant un message d'erreur comprenant toutes les propriétés définies dans SqlException ( sauf Data dont je n'ai pas pu trouver une utilité pour le moment ). Je pourrais poster cette méthode ( en VB ou VC# ) si elle vous interesse.Pour moi, il faut toujours implémenter un tratement complet des exceptions dans n'importe application sinon on regrettera le temps perdu lors de l'inclusion de ce traitement.

    http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlexception_properties(VS.90).aspx

    Depuis la sortie de SQL Server 2008, j'ai abandonné SQL Server 2005 surtout que la 2005 est très difficile à upgrader ( incompatibilté bien connue de SSMSEE impossible à upgrade et empechant tout upgrade vers une version 2008 ou ultérieure ).

    Il y a d'autres explications à votre problème car tout dépend de la charge du processeur ( plus exactement du socket ) et des disques et des renseignements que vous fournirrez. Par contre, vouloir en 1 ms obtenir un update/delete/insert me semble peu réaliste

    Nous attendons votre feedback pour essayer de vous aider plus efficacement.

    Bonne journée

     


    Mark Post as helpful if it provides any help.Otherwise,leave it as it is.

    vendredi 7 septembre 2012 15:57
  • Bonjour,

    Avez vous simplement testé le read_committed_snapshot à ON sur la BD ?

    Au sujet des deadlocks, activez des TF, tel les 1222 et 1204 afin de savoir de quoi il en retourne.

    Christophe


    Christophe LAPORTE - Independent Consultant & Trainer - SQL Server MVP-MCM

    samedi 15 septembre 2012 14:27
  • Tu dis qu'il y a des soucis de concurrence mais de quel type ? Tu as des timeout ? Des deadlocks ?

    Active les TF concernant les deadlocks ou tu peux créer des événements qui peuvent t'aider à identifier les blocages de sessions / requêtes par exemple ou encore remonter les deadlocks également.

    Tu aurais éventuellement le code ou la procédure TSQL qui te poserait souci ?

    ++


    MCDBA | MCITP SQL Server 2005 / SQL Server 2008 | LPI Linux 1

    lundi 17 septembre 2012 13:02
    Modérateur
  • Bonjour,

    Nous changeons le type de votre question à « Discussion générale » parce que vous n’êtes pas revenu avec les informations sollicitées. Si vous avez plus de temps pour réexaminer la question et fournir plus d'informations, n'hésitez pas à modifier le type du thread à « Question ». Si le problème est résolu, s’il vous plaît partagez la solution avec nous afin que la réponse puisse être trouvée et utilisée par d'autres membres de la communauté ayant des questions similaires. Merci !

    Cordialement,


    Aurel BERA, Microsoft
    Microsoft propose ce service gratuitement, dans le but d'aider les utilisateurs et d'élargir les connaissances générales liées aux produits et technologies Microsoft. Ce contenu est fourni "tel quel" et il n'implique aucune responsabilité de la part de Microsoft.

    mercredi 19 septembre 2012 13:48
    Modérateur
  • - 6 la taille d'augmentation pour les fichiers data ( .mdf et peut-etre .ndf ) et log transaction ( .lfd , 1 seul suffit ). Si cette augmentation est trop faible et donc trop fréquente, if y a une requète Windows d'augmentation, opération très lourde et bloquante, le temps nécessaire à cette augmentation étant inclus dans le timeout de la commande , cela pourrait déclencher un timeout de la commande ( la valeur par défaut du timeout est de 30 secondes )

    Attention, la mise à jour de la table n'est pas instantanée, les modifications/créations sont d'abord stockées dans le journal de transactions et ultérieurement écrites réellement dans la base de données ( le temps de latence peut dépendre de la charge des disques et processeurs ). C'est pour cela qu'il est recommander de mettre les fichiers data et log sur des disques physiques différents.

    Le temps total d'une requéte est très difficile à définir puisque dépendant de beaucoup de paramètres. De plus, SQL Server Express ne peut en aucun cas utitldser plus de 1 GO de mémoire ( même pour 2012 )

    Dans mes applications , quand je fais un INSERT/DELETE , c'est toujours par l'intermédiaire d'une procédure stockée qui inclut le l'INSERT/UPDATE suivi d'un SELECT dont je renvoie les valeurs dans les paramètres de la procédure stockée ( définis comme étant InputOutput )


    Mark Post as helpful if it provides any help.Otherwise,leave it as it is.

    Bonjour,

    Pour les fichier MDF/NDF, il est possible de passer outre la phase de zéroing en donnat au compte de service le droit Perform Maintenance Volume Task, ce qui peut effectivement diminuer le temps d'exécution de la requête. De la même manière, ne jamais configurer AutoShrink a ON sur une BD en production (fragmentation interne et externe). Donnez a votre LDF une taille suffisante, pensez à votre modèle de récupération et à vos backups. La structure du fichier LDF va aussi avoir un impact sur les performances. Trop de VLFs peuvent nuire.. Essayer de garder leur nombre < 50.

    L'écriture physique dans les fichiers de data est dépendante du CHEKPOINT, dont la seule préoccupation est le recovery interval. Il n'a pas connaissance de la charge des disques et n'est donc aps influencé par celle ci. par contre, effectivement, si vos disques ne sont aps performants, la durée (et non pas la latence) d'écriture des dirty pages dans les fichiers de données sera plus longue.

    J'aurais préféré la clause OUTPUT à un SELECt sur les données...

    Les temps d'exécution des requêtes sont comptabilisés (sys.dm_exec_query_stats et sys.dm_exec_procedure_stats), enfin un certain temps ...

    LaurentHD : Comme l'ad dit David, on attend toujours les infos avec les traceflag. Donen aussi le résultat d'une requête sur les waits. fais nous apsser els fichier .trc présents dans le répertoire LOG de ton instance.

    Bonne journée

    Christophe


    Christophe LAPORTE - Independent Consultant & Trainer - SQL Server MVP-MCM

    lundi 24 septembre 2012 08:50