Axapta - SQL transfer

[Oleksandr]

Quote:

Originally Posted by Wamr

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

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

[Oleksandr]

Quote:

Originally Posted by glibs

Ни фига себе... Быстро вставка у вас работать на таком хозяйстве не будет.

Вариант оптимизации — писать в таблицу без индексов, потом копировать в таблицу с индексами. Здесь можно применить и прямой SQL (с RecId уже проблем не будет). Но это очень жесткий (я бы сказал экстремальный) метод.

Ну, зачем себя ограничивать в методах, лишь бы заработало. Универсальностью можно принебречь.

Quote:

Originally Posted by glibs

Это Аксаптовский то профайлер? Забейте на него, если вы запросы к SQL разбираете. Только время потеряете.

Ну я так и понял... Потому что закономерностей в резуьтатах никаких.
У вас тоже такой опыт был?

Quote:

Originally Posted by glibs

Так все-таки, если отказаться от вставки — т.е. прогнать скрипт вхолостую — сколько времени уйдет? Просто секундомером замерить нужно без профайлера.

Т.е. закоментарьте строчки
ttsbegin;
this.writePrognosisLines...
prognosisLineList.insertDatabase();
this.prognosisTotals();
ttscommit;

Если будет долго, то бросайте. Нужно будет разбирать сам select.

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

[glibs]

Quote:

Originally Posted by Oleksandr

...
Ну я так и понял... Потому что закономерностей в резуьтатах никаких.
У вас тоже такой опыт был?
...

У меня много чего было такого :-)

Профайлер — вещь очень полезная, но для поиска недостатков в коде. Как правило, его имеет смысл начинать использовать, если с запросами уже все ОК, и за счет их ускорения не ожидается ощутимого прироста в производительности.

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

Профайлер больше всего подходит для того, чтобы, например, уменьшить время отклика на форме с 3000 миллисекунд до 500 миллисекунд. И для аналогичных задач. При умелом использовании он позволяет помочь обнаружить причину и долго играющего кода. Примером такого кода может быть цикл с очень большим количеством очень мелких обращений к базе (что затруднительно отловить мониторингом запросов с заданной аппертурой).

[belugin]

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

[Oleksandr]

Quote:

Originally Posted by belugin

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

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

[Oleksandr]

Quote:

Originally Posted by Oleksandr

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

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

[zelen]

предлагаю такой вариант:
использовать класс Connection, соответственно делаете конекшны к двум БД типа
LoginProperty dbLoginProperty;
Statement statement;
ResultSet rs;
str _query;
;
// соединяемся с источником данных
dbLoginProperty = NEW LoginProperty();
dbLoginProperty.setDSN(parmODBC);
dbLoginProperty.setServer(parmServ);
dbLoginProperty.setDatabase(parmDBServ);
dbLoginProperty.setUsername(parmLogin);
dbLoginProperty.setPassword(parmPass);
dbConnection = new odbcConnection(dbLoginProperty);
и соответственно настраиваете 2-й конекшн
_query = ваш запрос но уже в сиквельной нотации
statement = DBConnection.createStatement();
rs = statement.executeUpdate(_query);
для ваших внутренних вычислений можно добавить еще такое:
while (resultSet.next())
{
тут че нить вычисляете и пишете в другую БД
strfmt("INSERT INTO () VALUES (%2,%3,%4,%5,%6,%7,%8,%9,%10,%11,%12) ",
rs.getString(1) ... и т.п.
}

еще для оптимизации можно всё это дело создать в пакетном классе на сервере, чтобы он отрабатывал в определенное время!

[zelen]

можно еще так же настроить ваши БД как линкед сервера, чтобы в одном сиквел запросе мона было сразу делать insert to server.db.table (select from linckedServer.db.table)

[macklakov]

Quote:

Originally Posted by zelen

предлагаю такой вариант:
использовать класс Connection, соответственно делаете конекшны к двум БД типа

Зря предлагаете.
1. Если уж пользовать прямое обращение, то лучше использовать стандартные job-ы на SQL-сервере
2. Аксапта не любит когда со стороны лезут в ее базу, даже если на чтение

[glibs]

Quote:

Originally Posted by macklakov

...
Зря предлагаете.
...

С этим абсолютно согласен.

Quote:

Originally Posted by macklakov

...
Аксапта не любит когда со стороны лезут в ее базу, даже если на чтение
...

А вот это уже перебор.

Умеючи, можно и напрямую данные выковыривать. Особенно ОЛАПом.

[Torin]

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

[Oleksandr]

Quote:

Originally Posted by zelen

можно еще так же настроить ваши БД как линкед сервера, чтобы в одном сиквел запросе мона было сразу делать insert to server.db.table (select from linckedServer.db.table)

Ну соб-нно эо и была изначальная идея (тлько хотел все переписать на сиквеле). Так вот, сейчас оказывается что основной "боттлнек" - на sql сервере по время выполнения операций (жрет ЦПУ и память). Сам джойн выпоняется быстро, вставка - тоже.

[Oleksandr]

Quote:

Originally Posted by Torin

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

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

[Oleksandr]

Quote:

Originally Posted by otkudao

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

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

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

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

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

[Oleksandr]

Quote:

Originally Posted by Recoilme

может логичнее select firstOnly firstFast, вместо select firstOnly
Управление опциями SQL запроса

По ссылке - поэксперементировал с buffer size в конфигурации. При значении 2048 было ускорение процентов на 5-10, видимо потому что записи из запроса весьма тяжелые. Не знаю, правда как это может сказатсья на прочей производительности.

[Oleksandr]

Решил немного подытожить, чтобы знания не поропали в дебрях треда .

1. Axapta code profiler нагло врет и жрет ресурсы при больших количествах вызовов/подвызовов и операций с БД . Потратил много времени пытаясь оптимизировать неоптимизируемое, и вообще, пошел по ложному пути. В таких случаях лучше:

• Замерять ручками с помощью timenow() или gettickcount().

• Смотреть кто (Client/AOS/SQL) больше берет ресурсов и в какое время.

• Исползовать SQL trace или сиквельный профайлер для анализа реальных SQL запросов.

Более реальные результаты получились примерно такие:

select < 5% (в зависимости от условий)
операции - 80 %
insert ~ 10%

2. Основной боттлнек был в нагрузке на сиквел сервер при выполнении операций. Все три таблицы из селекта были достаточно тяжелыми (много стринговых полей, и т.д. - отдельное спасибо проектировщикам БД).
Таким образом, добавление field list-a в запросы ускорило обработку в несколько раз (sic) - отдельное спасибо Wamr! Предположительно, сиквелу было легче выделять память, разбивать страницы и т.д.
При этом он не занимал весь 1.25 гиг свободной памяти, хотя при бОльших количествах допускаю возможность своппинга.

3. Время исполнения нелинейно зависит от количества обрабатываемых записей, а выигрыш по времени - условно линейно.

количество зап.                неоптим.             оптим. 
______________________________________________________________
  1000                     15 сек.                  10 сек
  5000                     5 мин 30 сек             2 мин 10 сек
  ...                        ...                           ...
  80К                      > 10 ч                    3 ч 10 мин

4. Вставка занимала относительного немного времени, несмотря на наличие двух уникальных индексов на таблице, одного как кластерного.

-------------------
Еще раз всем спасибо за помощь

[glibs]

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

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

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

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