2015-02-10 2 views
0

У меня есть система с пакетным выполнением хранимой процедуры 10 раз.Порядок выполнения SQL-процедур

exec procedure 1 
 
exec procedure 2 
 
exec procedure 3 
 
exec procedure 4 
 
... 
 
exec procedure 10

процедура предназначена для накопления нарастающим итогом, основанный на идентификатор записи в целевой таблице.

Когда я запустил эту партию, я получу результаты, которые не синхронизированы. Итоговый итог должен быть просто текущим итогом предыдущей строки, а также значением текущей строки.

Когда я запускаю одну и ту же партию с оператором GO между ними, выполнение занимает намного больше времени, но выполняется правильно.

Есть ли какой-либо намек (например, «MAXDOP 1»), который можно сделать в этой ситуации, чтобы заставить процедуры выполнять и выполнять в порядке, не выходя из синхронизации?

Следует добавить, что вызываемая хранимая процедура вызывает несколько процедур. Если это имеет какое-либо отношение к решению.

+0

Возможно, редактирование самой процедуры было бы лучше? Трудно сказать, не зная больше о том, что происходит –

+0

Очевидно, что выполнение процедур распараллеливается по умолчанию, поэтому они быстро заканчиваются, но их порядок выглядит хаотичным. И, очевидно, вставка GO между ними гарантирует, что они будут исполняться по порядку, чего вы хотите, но тогда не будет параллелизма, поэтому им потребуется больше времени для запуска. Пожалуйста, выберите либо заказ, либо скорость, вы не можете иметь оба. –

+0

Возможный дубликат [Сохраненная процедура - принудительное исполнение заказа] (http://stackoverflow.com/questions/2682960/stored-procedure-forcing-execution-order) –

ответ

0

Я сделал немного больше испытаний на этом, и похоже, что мои первоначальные мысли были неправильными. Я провел несколько тестов с партиями с помощью операторов GO, и даже тогда только несколько записей в пакете будут обновлять их балансы, но остальные не будут синхронизированы. Похоже, что когда я делал свои первоначальные тесты, первые 10 записей обновлялись должным образом, но я ничего не заметил в этом разделе, так как остальные значения были уже правильными до более поздней части набора данных.

Похоже, что это внутренняя проблема процедуры, а не повторное выполнение процедуры. Странная часть заключается в том, что мы никогда не сталкивались с этой проблемой в одноядерной системе, которая до сих пор оставляет мне мысль, что это проблема параллелизма, но, скорее всего, внутренняя процедура.

Извините за то, что потратил время.

Смежные вопросы