Axapta - SQL transfer

[Oleksandr]

Цитата:

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

Значит смотрите. Есть два подхода решения проблемы:
1. Лбом сквозь стену.
2. Рациональный.

Первый психологически проще. Можно и прямой запрос написать, и в Аксапте что-то делать.

Второй предполагает выработку оптимального решения. Вы говорите, что у вас за 1 000 000 проводок. Кто-то их поштучно просматривает? Они действительно нужны? М.б. можно свернутые сделать? И как вы их анализируете? М.б. их в OLAP можно перенести? Ну и т.д.

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

Цитата:

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

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

Предположительно, у вас тормозит вставка.

Потом посмотрите, в какую таблицу вы пишете. Там есть индексы (особенно кластерные)?

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

- 56% - собственно запрос while select (хотя если отдельно запустить, без while - исполняется очень бысто)
- 33% - операции над каждой записью, в том числе создание добавление єлемента РекордИнсертЛист
- вставка где-то в оставшихся %

За идеи спасибо!

[macklakov]

Цитата:

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

Да, индексы есть, два, каждый из 5 полей, оба уникальных, и кластерный.

Кластерный индекс на той таблице, которую заполняете?

[Oleksandr]

Цитата:

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

Кластерный индекс на той таблице, которую заполняете?

Да, причем сложный, и это нехорошо, без него попробую

[glibs]

Цитата:

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

...
Да, индексы есть, два, каждый из 5 полей, оба уникальных, и кластерный.
...

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

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

Цитата:

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

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

- 56% - собственно запрос while select (хотя если отдельно запустить, без while - исполняется очень бысто)
- 33% - операции над каждой записью, в том числе создание добавление єлемента РекордИнсертЛист
- вставка где-то в оставшихся %
...

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

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

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

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

[Oleksandr]

Цитата:

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

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

[glibs]

Цитата:

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

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

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

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

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

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

[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)

[Oleksandr]

Цитата:

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

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

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

[macklakov]

Цитата:

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

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

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

[glibs]

Цитата:

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

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

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

Цитата:

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

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

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

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