Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Как оценить время выполнения MDX запроса (MSAS)?
|
|||
|---|---|---|---|
|
#18+
MSAS 2000/2005, MDX запрос. Нужно определить хотя бы приблизительно СКОЛЬКО ВРЕМЕНИ он будет выполнятся. На форуме "Microsoft SQL Server" этот вопрос подымался относительно SQL-запросов, и на нем ответ - никак. То есть не совсем: если это хранимая процедура - можно извращаться с записью статуса в отдельную таблицу, а оттуда считывать данные, и пр. Но это SQL, а нужно для MDX. Несколько слов зачем. Делаем свой ОЛАП-клиент, и на каждом этапе хотим знать что делается в данный момент, и сколько осталось ждать. Этапы следующие: 1) юзер поменял конфигурацию отчета 2) на сервер пошел сгенерированный MDX 3) MDX выполняется 4) получили результаты выполнения MDX, качаем их на клиента 5) отображаем результаты Проблемным есть этап 3 - неизвестно сколько юзер должен ждать пока MDX запрос выполнится. Пока-что мы просто отображаем диалоговое окно "Executing the request. N seconds passed...", N=1,2,3... и у юзеря через 10 секунд возникает вопрос "сколько еще ждать?". Вот бы в этом окне отобразить "осталось N секунд", но как это узнать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2006, 00:15 |
|
||
|
Как оценить время выполнения MDX запроса (MSAS)?
|
|||
|---|---|---|---|
|
#18+
К сожалению для MDX ответ такой же - никак. Моша ---------------------------------------------------- This posting is provided "AS IS" with no warranties, and confers no rights ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2006, 02:36 |
|
||
|
Как оценить время выполнения MDX запроса (MSAS)?
|
|||
|---|---|---|---|
|
#18+
На каждом OLAP сервере вы можете установить программу, которая бы мониторила trace (можно в указать, что вас интересует только CommandBegin и CommandEnd events чтобы нагрузка от trace была минимальной) и оценивала сколько какой запрос выполняется. Результаты пусть записываются в какую-нибудь базу данных, которая периодически бы вычисляла среднее значение и отклонение (базовые статистики). Клиенты могут контактировать к той "статистической" базе данных и получать информацию о сервере с которым они работают. Информацию нужно передавать группой (вся статистика о сервере) чтобы потом не контактировать каждый раз при выполнении MDX, а доставать из памяти клиента. Зная статистику, можно разумно информировать пользователя. Должно работать для SQL запросов тоже. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2006, 23:59 |
|
||
|
Как оценить время выполнения MDX запроса (MSAS)?
|
|||
|---|---|---|---|
|
#18+
Продолжение мысли... Для мониторящей программы может возникнуть сложность в классификации запросов. Например, структура MDX (или SQL) запроса может быть одна, но в запрос могут быть переданы различные имена (unique names). Текст запроса разный, но тип и структура одна и та же. Писать parser для MDX или SQL нет охоты. Можно получить помощь от клиента. Клиент составляет текст запросов. Он может также вставлять структурированные коментарии о типе запроса, какие-нибудь еще переменные вписанные в MDX и известные разработчику как влияющие на скорость. Затем можно написать parser для комментариев извлекающий тип запроса и дополнительные переменные. Если переменные есть (кроме типа запроса), информацию можно использовать для построения minig model (logistic regression or neural networks, у вас ведь output attribute - ожидаемое время - является continuous, а не destrete (or categorical); хотя можно и другую, ведь data mining алгоритмы умеют превращать continuous в categorical) и запрашивать mining model для анализа. Но это уже более сложная система и надо экспериментировать - даст ли она результаты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2006, 01:02 |
|
||
|
Как оценить время выполнения MDX запроса (MSAS)?
|
|||
|---|---|---|---|
|
#18+
Руку на отсечение не дам, но по-моему, многие прогресс-бары написаны по гораздо более простым алгоритмам :) Типа берем раз в секунду рисуем полосочку. А когда запрос исполнился и что-то вернул - рррраз - и добегаем до конца! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2006, 02:49 |
|
||
|
Как оценить время выполнения MDX запроса (MSAS)?
|
|||
|---|---|---|---|
|
#18+
Если цель - нарисовать полосочку, то да, можно и так. Автор ставил цель уведомления пользователя о том, когда можно ожидать окончание выполнения MDX (в более сложном случае, окончание составления отчета или выполнения задачи). Если это ему так важно (его пользователям так важно) и готовы тратить время (=деньги) на решение именно этой проблемы, то можно рассматривать различные варианты (решения проблемы, а не рисование полосочек). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2006, 03:54 |
|
||
|
Как оценить время выполнения MDX запроса (MSAS)?
|
|||
|---|---|---|---|
|
#18+
Andriy7777Если это ему так важно (его пользователям так важно) и готовы тратить время (=деньги) на решение именно этой проблемы, Хотел бы я видеть заказчика, который на разработку этого готов выложить свои кровные. Сумлеваюся я шибко в сущетвовании таких. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2006, 19:14 |
|
||
|
Как оценить время выполнения MDX запроса (MSAS)?
|
|||
|---|---|---|---|
|
#18+
backfireХотел бы я видеть заказчика, который на разработку этого готов выложить свои кровные. Сумлеваюся я шибко в сущетвовании таких. Вы не поверите, но мои заказчики хотят оценивать время выполнения запросов. И даже платят за это. Я эту тему поднимал здесь и здесь Получается нелинейная зависимость. Основная проблема состоит в том, что процедура принимает разные пользовательские параметры, которые влияют на время выполнения. Кроме того, есть четкая зависимость с железом, индексами и обновлением статистики. Идея посадить долгоиграющие запросы в отдельный black box trace для последующего разбора полетов не нова. Как это не печально, но до сих пор, ни в TSQL, ни в MDX нет нормального estimation engine. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2006, 14:43 |
|
||
|
Как оценить время выполнения MDX запроса (MSAS)?
|
|||
|---|---|---|---|
|
#18+
Ну чтовы MS обладает отличным engine. Берете ресуете палочки раз в секунду, если не успел уложиться, то просто висите на "сделано 98%" У MS масса таких прогресс баров и ничего. Может просто не раздувать проблему и предложить заказчику что-то более полезное типа уведомления о конце запроса звуком? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2006, 14:52 |
|
||
|
Как оценить время выполнения MDX запроса (MSAS)?
|
|||
|---|---|---|---|
|
#18+
ban_ backfireХотел бы я видеть заказчика, который на разработку этого готов выложить свои кровные. Сумлеваюся я шибко в сущетвовании таких. Вы не поверите, но мои заказчики хотят оценивать время выполнения запросов. И даже платят за это. Я эту тему поднимал здесь и здесь Получается нелинейная зависимость. Основная проблема состоит в том, что процедура принимает разные пользовательские параметры, которые влияют на время выполнения. Кроме того, есть четкая зависимость с железом, индексами и обновлением статистики. Идея посадить долгоиграющие запросы в отдельный black box trace для последующего разбора полетов не нова. Как это не печально, но до сих пор, ни в TSQL, ни в MDX нет нормального estimation engine. Если заказчик платит, что ж... всем бы таких заказчиков. Время выполнения запроса - это ведь величина случайная. Ни один сервер не гарантирует Вам выполнение запроса в рассчитанный каким-то образом промежуток времени на 100%. Так что не в MS дело и не в OLAP. Но мой совет Вам - не играйтесь с заказчиками в такие игры, в конечном итоге стоимость реализации того или иного функционала должна всегда быть в разы ниже эффекта от его использования. Скорее всего заказчик просто не представляет сколько это стоит, а Вы рискуете разочаровать и его и себя. Владислав Беляев ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2006, 15:13 |
|
||
|
Как оценить время выполнения MDX запроса (MSAS)?
|
|||
|---|---|---|---|
|
#18+
Тут упоминалось о том, чтобы собирать статистику запросов и в дальнейшем проводить их анализ. Идея конечно супер, но не учтена одна деталь: кубы каждый день наполняются новыми данными. И если какой-либо запрос работал 10 секунд вчера, то тот же запрос не обязательно будет работать столько же времени послезавтра. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2006, 15:33 |
|
||
|
Как оценить время выполнения MDX запроса (MSAS)?
|
|||
|---|---|---|---|
|
#18+
У меня возникла шальная идея - ваш заказчик Майкрософт :)) Владислав Беляев ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2006, 06:37 |
|
||
|
Как оценить время выполнения MDX запроса (MSAS)?
|
|||
|---|---|---|---|
|
#18+
БеляевУ меня возникла шальная идея - ваш заказчик Майкрософт :)) Владислав Беляев :) Не угадали. Судя по времени поста эта идея не давала Вам спать. Просто моя задача имеет частное решение, а уважаемые спорщики склонны обобщать и унифицировать. И все же я согласен, что более правельный способ не предсказывать время выполения, а уведомлять пользователя любым удобным способом о том, что запрос выполнен. Здесь асинхронные обработчики рулят. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2006, 09:32 |
|
||
|
Как оценить время выполнения MDX запроса (MSAS)?
|
|||
|---|---|---|---|
|
#18+
Ihor BobakТут упоминалось о том, чтобы собирать статистику запросов и в дальнейшем проводить их анализ. Идея конечно супер, но не учтена одна деталь: кубы каждый день наполняются новыми данными. И если какой-либо запрос работал 10 секунд вчера, то тот же запрос не обязательно будет работать столько же времени послезавтра. А еще N пользователей, работающих одновременно, процесс совершенно не детерминированный. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2006, 13:04 |
|
||
|
|

start [/forum/topic.php?fid=49&msg=33639435&tid=1870307]: |
0ms |
get settings: |
7ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
50ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
64ms |
get tp. blocked users: |
2ms |
| others: | 219ms |
| total: | 378ms |

| 0 / 0 |
