Почему такое расхождение в скорости выполнения

[Владимир Максимов]

У меня в SQL - профайлере получились такие результаты:

-) Statment
exec sp_cursorfetch 180150002, 2, 1, 1
exec sp_cursor 180150002, 40, 1

Всего, около 2000 команд общей продолжительностью 5 секунд

-) While select
exec sp_cursorfetch 180150001, 2, 1, 8

Всего около 125 команд общей продолжительностью 0.5 секунд

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

Тогда возвращаемся к тому, с чего началась данная тема:

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

-) Создать таблицу на сервере
-) Выполнить хранимую процедуру сервера по наполнению этой таблицы
-) Средствами Axapta сделать выброс из этой таблицы в текстовый файл

Правда в такой идеологии 2 большие проблемы:
-) Конвертация Query в синтаксис MS SQL
-) Генерация значений RecID в таблице

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

Вобщем теперь понятно, что происходит. Спасибо.

[ATimTim]

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

Может дело не в родных или не родных таблицах, а в суммарном объеме данных, возвращаемых курсором (кол-во строк * объем данных в строке)?
P.S Создал две тестовые таблицы (отличные друг от друга по структуре) и сделал по ним выборки посредством select * from ....(не while ) (в аксапте) - по одной получил количество отбираемых курсором строк 24, по другой 32 ...

[Vadik]

Statement по умолчанию фетчит по одной записи
Аксапта по умолчанию фетчит по (Buffer size / Record size) записей

Buffer size настраивается в конфигурационной утилите ( по умолчанию 24 Kb )

[Ruff]

Модераторы!
Кажется, эту ветку пора в "Полезное".

[bucken]

Цитата:

Изначально опубликовано Владимир Максимов
Тогда возвращаемся к тому, с чего началась данная тема:

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

-) Создать таблицу на сервере
-) Выполнить хранимую процедуру сервера по наполнению этой таблицы
-) Средствами Axapta сделать выброс из этой таблицы в текстовый файл

Правда в такой идеологии 2 большие проблемы:
-) Конвертация Query в синтаксис MS SQL
-) Генерация значений RecID в таблице

1) Конвертация не есть проблема - от сиквела можно получить запрос(в SQL синтаксисе). Посмотрите событие по созданию курсора, я не помню какое оно точно называется. Там вы и увидите создаваемы запрос. Тобишь супер проблем тут нет. Потом просто распарсить его. И потом вытянуть нужные таблицы. Или может вообще не парсить. Опредялять запрос - как ключ. План запроса при первом query.next().
Это так на вскидку.. может я ошибаюсь, гуру меня поправят.

2) А вот и самое главное на мой взгляд - зачем такие заморочки вообще? Вы говорите у вас 125 запросов по 0.5 секунды - может ваш запрос такой плохой изначально? 0.5 секунды это долговато ... может есть смысл оптизировать запрос? И еще такое мнение стоит ли в этом случае вообще вмешивать в работу аксапты как организма. Ведь это серьезная доработка. Ладно... я чето в демогогию ушел....

[xonix]

Мне тоже непонятны такие заморочки с выгрузкой. Нафига? Напишите, что с этим делается потом? И как часто операция выполняется. Раз в день можно и подождать, чем неделю на разработку тратиться.
Если это выгрузка в ЛПБ, то хрен с ними, пусть хоть 20 минут делается - один раз в день ведь..
Вот все программеры такие - все стремяться производительность улучшать, размер кода сокращать. А вы пользователя спросите, что ему надо? Рассказывая, что и сколько будет стоить и какие последствия таких нестандартных извращений.. (там ещё же и секюрити надо будет привинчивать в общем случае... ).

Если это для аналитики какой - вообще не парьтесь. MS Analysis services форева..
Еженощная перепрокачка - и наутро кубы + супербыстродействие + куча тулов для визуализации..

Короче, первый вопрос - НАФИГА?

[Владимир Максимов]

Цитата:

Изначально опубликовано xonix
Вот все программеры такие - все стремяться производительность улучшать, размер кода сокращать. А вы пользователя спросите, что ему надо? Рассказывая, что и сколько будет стоить и какие последствия таких нестандартных извращений.. (там ещё же и секюрити надо будет привинчивать в общем случае... ).

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

Цитата:

Изначально опубликовано xonix
Короче, первый вопрос - НАФИГА?

Это аналитика. Отчеты. Выполнение их стандартными средствами AXAPTA занимает часы и дни. Через хранимые процедуры MS SQL - несколько минут (с учетом формирования файла EXCEL через буфер обмена)

Цитата:

Изначально опубликовано xonix
Если это для аналитики какой - вообще не парьтесь. MS Analysis services форева..
Еженощная перепрокачка - и наутро кубы + супербыстродействие + куча тулов для визуализации..

Насчет кубов - не знаю. По ним 2 принципиальных вопроса:

1) Как учитывать компанию (отчет по одной компании)? Не только физическую, но и виртуальную? Сейчас я просто определяю DataAreaId для каждой таблицы, используемой в ХП в текущей компании и передаю их как параметры. А как это сделать для кубов?

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

2) Как там с правами доступа? В смысле, далеко не все отчеты предназначены для общего употребления (скорее наоборот).

Ну, и вопрос обучения пользователей по работе с кубами.

[uvi]

Цитата:

-) Создать таблицу на сервере
-) Выполнить хранимую процедуру сервера по наполнению этой таблицы
-) Средствами Axapta сделать выброс из этой таблицы в текстовый файл

Правда в такой идеологии 2 большие проблемы:
-) Конвертация Query в синтаксис MS SQL
-) Генерация значений RecID в таблице

Подход конечно интересный, но не осуществимый. Вы не сможете создать массив данных на сервере без аксапты, т.к. не сможете сгенерировать корректный RecId.

Один из способов - воспользоваться view: если посмотреть какой скрипт генерирует аксапта для view содержащего агрегатные поля, то можно увидеть, что там жёстко подставляется 1 вместо RecId.

Таким образом на view можно только предварительно подготовить данные, т.е. если вас не устраивают возможности аксапты по формированию запросов, можно на уровне SQL сервера заменить срипт сгенерированный аксаптой на свой. А дальше на основе этого view строить выборки для отчётов.

[Андре]

Цитата:

Подход конечно интересный, но не осуществимый.

Почему ? Например вот здесь я привел один из примеров того, как это можно сделать.