Parallel.ForEach и набор таблиц

@ramonafalls · Регистрация: 05.06.2013

Студворк — интернет-сервис помощи студентам

Здравствуйте. Итак, есть процедура, которая возвращает набор таблиц (10 и больше), которые потом использую для вывода в гриды на форме и для выгрузки в эксель. Изначально запихивала этот набор в DataAdapter, а затем - в DataSet. Но по времени заполнение датасета из адаптера занимает минимум три минуты (для минимального набора таблиц), что видно при отладке. Желая повысить производительность, пытаюсь использовать Parallel.ForEach, но никак не могу понять, как мне правильно определить делегат (в итоге lst не заполняется):

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
SqlCommand ReportPL = new SqlCommand("exec [Analiz_FP] " + plyear + "," + pl_per_b + "," + pl_per_e + ",'" + plkod_lpu + "','" + plprofil + "','" + plsk + "','" + pdisp + "','" + ptip + "','" + pldet + "'," + ppartiya + "," + pmon_b + "," + pmon_e + ",'" + pvid + "'", fp1conn);
                ReportPL.CommandTimeout = 10000000;
                try
                {
 
                    var lst = new List<System.Data.DataTable>();
                     Parallel.ForEach(lst, (datatable) =>
                     {
                         using (SqlDataReader reader = ReportPL.ExecuteReader())
                         {
                             while (reader.Read())
                             {
                                 datatable.Load(reader);
                                 lst.Add(datatable);
                             }
                         }
                     });
lst.ForEach(reportDS_p.Tables.Add);
}
catch{}

Либо я вообще не в той степи, и можно организовать этот цикл по-другому?
Алсо, может, кто-то подскажет более эффективные способы загнать эти таблицы в датасет?

@ramonafalls · 07.07.2017, 14:41 **[ТС]**

Usaga, В режиме отладки я наблюдала отдельно за временем выполнения процедур и за временем заполнения датасета. Отсюда и такие данные. Это не по моим предположения, это реальный тест - три с лишком минуты выполнялась процедура, затем заполнился адаптер, а затем еще около трех минут отладчик висел на da.Fill(ds). В адаптере уже были данные из выполненной процедуры. Значит, это какой-то косяк самого заполнения датасета. Может, он еще какие-то махинации совершает в это время..но мне это кажется бредом.

HF, да, в этой процедуре как раз вызываются процедуры, дающие те самые 12 таблиц. Но, как я уже писала выше, если экзеки даже не пихать в одну процедуру, в коде в VS вызывать каждую и результат каждой записывать отдельно в датасет, то результат по времени выигрывает всего на несколько секунд. Да, процедуры надо пересмотреть, хотя, я на данный момент постаралась уйти от всяких вложенных запросов и операторов типа in, оставив агрегатные функции и джойны(как переработать их, я пока не могу придумать)-все равно, время выполнения не менее 10 сек. Понятно, что 10+процедур -это уже 1,5 минуты и более на выполнение. А тут еще и датасет заполняется столько же или в два раза дольше. так что. хотелось начать с малого и сначала как-то разобраться с датасетом.

Добавлено через 7 минут
Кстати, может ли быть такая задержка в заполнении датасета связана с тем, что все это дело выполняется в отдельном потоке?

@HF · 07.07.2017, 20:13

Есть два решения на две проблемы в случае использования тяжёлых (длительных) процедур, больших таблиц (много строк) и где результат - не одна таблица, а много
1) Биндинг. По рекомендации, требуется перед использованием Fill, отключать все события связанные с привязкой и обработкой, потом биндинг снова подключать.

C#
1
2
3
bindingSource.RaiseListChangedEvents = false // перед загрузкой
// .. Fill
bindingSource.RaiseListChangedEvents = true // после загрузки

2) и конечно же SQL-Plan. То что вы делаете в ManagementStudio полностью отличается от того что делается в адаптерах, т.к. там разные подключения и настройки. Вкратце - из-за того, что база пытается постоянно построить новый план на наш запрос, то происходят очень большие задержки с выдачей результата. Единственным ешением является, но не всегда это помогает: добавить во все процедуры команду

SQL
1
SET ARITHABORT OFF

.

2.1) Я ещё добавлял команду

SQL
1
OPTION (RECOMPILE)

Так как это тоже влияет на статистику и планы. В случае постоянного изменения результатов, база ещё и начинает статистику вычислять и неверно. Так как вызываются разные процедуры (через EXEC), то это как бы накладывает на результат какую-то неведомую злую магию. А эта опция, по сути берёт весь результат, и создаёт конечную одну статистику по всему результату.

Добавлено через 2 минуты
Интернет забит этим вопросом (почему медленно) и ответами связанными с этими двумя командами. Вот даже большая статья на эту тему для очень любопытных: Slow in the Application, Fast in SSMS?

@Usaga · 08.07.2017, 04:39

HF, я ну оооочень сомневаюсь, что процедуры отрабатывают медленно из-за построения плана запроса))) Да и с биндингами, хоть и хороший совет, но не сильно уместный, как мне кажется. ТС заявила, что процедуры отрабатывают несколько минут. Т.е. проблема уже на уровне БД. И явно не в плане запроса.

Тут только профилировать выполнение процедур и смотреть какая (или какие) процедура работает медленно и потом попытаться понять почему.

Всё остальное - рекомендации наугад.

Не по теме:

Но решение с распараллеливаеним, конечно, позабавило) В чём проблема? Да фиг знает! Давай в параллель запрос выполнять)))

Новые блоги и статьи Все статьи Все блоги /
Нейтральные знания ..., ... чистая наука. Пока что-то проходит модерацию на Хабре, стоит развить мысль ... Hrethgir 20.07.2026 К таким радикальным взглядам я конечно в той публикации не приходил, но чтобы скоротать вечер, решил углубиться немного. 1. Почему показания термометра заряжены целью? Цель заложена в самом. . .	Установка нескольких штампов электронной подписи в строго определенных местах файла docx ВладимирСамохин 19.07.2026 (В!) Работа с Электронной подписью - это неотъемлемая часть современного документооборота. Но что делать, если нужно поставить несколько штампов электронной подписи в строго определенных местах. . .	сукцессия 35. Научная статья о проделанной работе anaschu 19.07.2026 Написал в формате латекс и пдф	Вангую, что это не пройдёт модерацию, и на неделе я запущу свой сервер. Hrethgir 19.07.2026 Эта публикация сейчас в песочнице и ждёт приглашения. https:/ / habr. com/ ru/ sandbox/ 295048/ По ссылке 403. Не очень информативно такую ссылку постить. Запись от Usaga размещена Сегодня в 06:46 . . .
сукцессия 33. открытые вопросы от клауде anaschu 19.07.2026 "Что накопилось за эту часть А — тринадцать правок, из которых шесть пришли из ваших вопросов и каждая оказалась реальной ошибкой, а не калибровкой: односторонний симбиоз, отсутствующий листопад,. . .	32 сукцессия anaschu 19.07.2026 сукцессия 28‑мерное ядро стабилизировано Коллеги, фиксирую разбор инженерных правок и их изоморфную проекцию на экономику, меметику и половой отбор. Модель теперь не «подкручивает» сходимость —. . .	сукцессия 31: модель микоризы - это модель ещё нескольких явлений, социальных и экономических anaschu 18.07.2026 Теория «Всего»: апдейт v1. 1. 2 — 28‑мерное ядро стабилизировано Коллеги, фиксирую разбор инженерных правок и их изоморфную проекцию на экономику, меметику и половой отбор. Модель теперь не. . .	сукцессия 30. Массив проверяющих друг друга моделей anaschu 18.07.2026 Архитектура сети взаимопроверяющих моделей микоризной сукцессии (v2. 0) Развитие тензорного ОДУ-ядра и создание кросс-платформенного калибровочного полигона Уважаемые коллеги! В продолжение. . .

@ramonafalls 0 / 0 / 0 Регистрация: 05.06.2013 Сообщений: 21
	07.07.2017, 14:41 [ТС]
	Usaga, В режиме отладки я наблюдала отдельно за временем выполнения процедур и за временем заполнения датасета. Отсюда и такие данные. Это не по моим предположения, это реальный тест - три с лишком минуты выполнялась процедура, затем заполнился адаптер, а затем еще около трех минут отладчик висел на da.Fill(ds). В адаптере уже были данные из выполненной процедуры. Значит, это какой-то косяк самого заполнения датасета. Может, он еще какие-то махинации совершает в это время..но мне это кажется бредом. HF, да, в этой процедуре как раз вызываются процедуры, дающие те самые 12 таблиц. Но, как я уже писала выше, если экзеки даже не пихать в одну процедуру, в коде в VS вызывать каждую и результат каждой записывать отдельно в датасет, то результат по времени выигрывает всего на несколько секунд. Да, процедуры надо пересмотреть, хотя, я на данный момент постаралась уйти от всяких вложенных запросов и операторов типа in, оставив агрегатные функции и джойны(как переработать их, я пока не могу придумать)-все равно, время выполнения не менее 10 сек. Понятно, что 10+процедур -это уже 1,5 минуты и более на выполнение. А тут еще и датасет заполняется столько же или в два раза дольше. так что. хотелось начать с малого и сначала как-то разобраться с датасетом. Добавлено через 7 минут Кстати, может ли быть такая задержка в заполнении датасета связана с тем, что все это дело выполняется в отдельном потоке? 0

@Usaga 14370 / 9471 / 1360 Регистрация: 21.01.2016 Сообщений: 35,738
	08.07.2017, 04:39
	HF, я ну оооочень сомневаюсь, что процедуры отрабатывают медленно из-за построения плана запроса))) Да и с биндингами, хоть и хороший совет, но не сильно уместный, как мне кажется. ТС заявила, что процедуры отрабатывают несколько минут. Т.е. проблема уже на уровне БД. И явно не в плане запроса. Тут только профилировать выполнение процедур и смотреть какая (или какие) процедура работает медленно и потом попытаться понять почему. Всё остальное - рекомендации наугад. Не по теме: Но решение с распараллеливаеним, конечно, позабавило) В чём проблема? Да фиг знает! Давай в параллель запрос выполнять))) 0