Axapta - SQL transfer

[macklakov]

Цитата:

Сообщение от Oleksandr

while selec a join b join c //возвращает под сотню тысяч записей.
{
while (bla bla ) // несколько повторов на одну запись
{
someoperation();
recordinsertlist.ins();
}
recordinsertlist.insertdatabse();
}

Почему у Вас recordinsertlist.insertdatabse(); внутри while select?

Цитата:

Сообщение от Oleksandr

времени занимает до 80-ти часов,

Цитата:

Сообщение от Oleksandr

Последний раз было 1.1М записей...

3 строки в секунду? Что-то очень медленно, через COM с такой скоростью грузится. Что именно там происходит?

[Wamr]

while selec a join b join c
У вас используются все поля из 3х таблиц? Если нет, то лучше их указать в запросе

[Oleksandr]

Цитата:

Сообщение от Wamr

while selec a join b join c
У вас используются все поля из 3х таблиц? Если нет, то лучше их указать в запросе

Многие. Но в принципе может быть поиожет, таблички нелегкие, почему-то сразу не подумал об этом.

[Oleksandr]

Цитата:

Сообщение от Oleksandr

Многие. Но в принципе может быть поиожет, таблички нелегкие, почему-то сразу не подумал об этом.

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

[macklakov]

а что с памятью творится? prognosisLineList на миллион записей не начинает на диск кэшироваться?

[Oleksandr]

Цитата:

Сообщение от macklakov

а что с памятью творится? prognosisLineList на миллион записей не начинает на диск кэшироваться?

Не знаю, на серваке не смотрел локально сиквел жрал дето 500 МБ и все, это правда неполная загрузка, в принципе из-за своппинга тоже может тормозить.

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

Ладно, всем спасибо за советы, попробую поэксперементировать еще, сообщу

[Wamr]

Цитата:

Систем монитор, кстати, говорит что количество селектов соотв. количеству записей...

а у вас там в join временная табличка не попала случайно

[Oleksandr]

Цитата:

Сообщение от Wamr

а у вас там в join временная табличка не попала случайно

Нее, все постоянные

[belugin]

Еще можно попробовать вставлять не целиком, а порциями по 500-1000 строк - иногда длинные транзакции тормозят

[Oleksandr]

Цитата:

Сообщение от belugin

Еще можно попробовать вставлять не целиком, а порциями по 500-1000 строк - иногда длинные транзакции тормозят

Да, это вариант. И предположително от большого объема рекординсертлист в памяти может быть своппинг.

[Torin]

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

[Oleksandr]

Цитата:

Сообщение от Torin

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

Проблема не в селекте, уже выяснил. Он исполняется буквадьно пару минут. Основная нагрузка - потом на сиквел вервере, при обработке.

[glibs]

А что там у вас внутри тогда такое?

Чтение из базы или запись? Или просто математика?

Индексы оптимально подобраны? Запросы оптимизированы? Обращений к базе много за один вызов writePrognosisLines() происходит? Запросы с джоинами или простые? Если с джоинами, то forceplaceholders стоит? Сортировка или группировка есть?

Попробуйте искусственно добавить условие в запрос с основным циклом, чтобы он отработал, например, 3 раза. И посмотрите профайлером, куда уходит время внутри writePrognosisLines().

[Oleksandr]

Цитата:

Сообщение от otkudao

елки-палки! так вы в 2-х звенке пытаетесь разогнаться? так быстро не будет работать никогда!

Выносите ВСЕ операции с БД
- в трехзвенку,
- на серверную часть,
- в методы с префиксом server (чтобы выполнялись исключительно на сервере.) Если класс (вот не помню, джоб, кажется, только клиентски по исполнению может быть, тогда перенесите методы в класс...) не позволяет своим методам выполняться на сервере, выносите эти методы в static (+ server).

Ускорение (был опыт с отчетами) может достигать десятков раз!

Весь функционал - в одном классе - наследнике RunBaseBatch. Запускается периодически на батч-сервере (только в 2-звенке можно, насколько помню ?).

С отчетами - да, они частично на клиенте исполняются вроде.