Comment exécuter la procédure stockée 1000 fois

J'ai une procédure stockée que j'utilise pour remplir une table avec environ 60 colonnes. Je genereated 1000 déclarations exec qui ressemblent à ceci:Comment exécuter la procédure stockée 1000 fois

exec PopulateCVCSTAdvancement 174, 213, 1, 0, 7365 
exec PopulateCVCSTAdvancement 174, 214, 1, 0, 7365 
exec PopulateCVCSTAdvancement 175, 213, 0, 0, 7365

Chaque fois que la procédure stockée sera insérait allant de 1 à 3 000 dossiers (habituellement environ 2 000 dossiers). Le "serveur" exécute le matériel de bureau avec 4 Go de mémoire disponible sur un serveur OS. Le problème que j'ai est qu'après les 10-15 premières exécutions d'une moyenne de 1-2 secondes à chaque fois, les prochaines 10-15 semblent ne jamais finir. Est-ce que je fais cela correctement? Comment dois-je faire cela?

Merci! Top 10 serveurs:

LAZYWRITER_SLEEP 
SQLTRACE_INCREMENTAL_FLUSH_SLEEP 
REQUEST_FOR_DEADLOCK_SEARCH 
XE_TIMER_EVENT 
FT_IFTS_SCHEDULER_IDLE_WAIT 
CHECKPOINT_QUEUE 
LOGMGR_QUEUE 
SLEEP_TASK 
BROKER_TO_FLUSH 
BROKER_TASK_STOP

Source

2010-12-31 O.O

Vous devez savoir ce qu'est le goulot d'étranglement. Que disent les waitstats DMV? –

Il y a plus de 400 lignes dans cette table. Quelque chose de spécifique je devrais poster? –

les chiffres sont cumulatifs, prenez donc un instantané dans une table temporaire, puis effectuez l'action qui génère la longue attente, puis comparez les deux pour voir quels types d'attente ont le plus augmenté. (Ou juste réinitialiser les chiffres dans le DMV à 0 avec DBCC SQLPERF ("sys.dm_os_wait_stats", CLEAR); 'si vous n'avez aucun outil de surveillance en s'appuyant dessus) –

Tourné la cause était d'un bogue dans ma procédure stockée lors de l'exécution de certains paramètres.

Spécifiquement, j'avais un cte que j'ai rejoint à une autre table, cependant, certains des critères de jointure du cte contenaient des valeurs nulles et l'ont fait durer éternellement. Un simple isnull() dans les critères de sélection cte a résolu le problème. Merci à tout ce qui a aidé.

P.S. Il a fallu 4 minutes pour courir une fois que je l'ai enveloppé dans une transaction.

Source

2011-01-02 20:39:09

envelopper dans une transaction - il charge beaucoup plus rapide

Source

2010-12-31 21:27:21 sethvargo

D'accord, mais je ne vois pas pourquoi cela expliquerait la différence de temps soudaine (sauf si un point de contrôle a peut-être lancé?) –

La transaction n'a eu aucun effet –

(parlant pour mysql), lors de l'emballage dans une transaction, la requête est entièrement construite et puis exécuté (son optimisé autant que possible). – sethvargo

pensées au hasard:

Assurez-vous que la taille de votre base de données est assez grand pour prendre autogrow sur l'équation. La croissance par défaut est de 10% et il est possible que vous développiez la base de données. Ceci s'applique à la fois au MDF et au LDF.
En plus de vérifier la taille de LDF, changer le modèle de récupération à tout aussi simple pour la durée de la charge
Vous pouvez avoir le paramètre renifler. Pouvez-vous ajouter le optimise for unknown allusion à la procédure stockée

Source

2010-12-31 21:42:34 gbn

Bons conseils. Trouvé le journal a été fixé à 10 pour cent de croissance automatique. Vérification sur les autres maintenant. –

Était déjà réglé sur simple. J'ai également ajouté avec recompiler à la sp. –

Comment exécuter la procédure stockée 1000 fois

Répondre

Questions connexes